Факторы цитирования ИИ: три уровня (домен, schema, геоданные)

Большинство руководств по ранжированию в ИИ-поиске охватывают два уровня: domain authority и schema markup. Эти руководства не ошибаются, но они неполны таким образом, что это конкретно вредит страницам объявлений, порталам недвижимости, платформам аренды жилья для отпуска и любому сайту, инвентарь которого основан на местоположении.

Третий уровень — geo data. Он наименее задокументирован, чаще всего отсутствует и именно он определяет, смогут ли ваши страницы вообще отвечать на запросы, привязанные к конкретному месту. Понимание того, что AEO на самом деле означает — это отправная точка, но данное руководство углубляется в структурные факторы, определяющие, будут ли отдельные страницы процитированы.

Уровень 1: Авторитет домена и сущности

Авторитет домена — это входное требование, а не сигнал ранжирования. Думайте о нём как о пороге. Страницы с доменов ниже примерно DA 20-30 редко появляются в пулах цитирования ИИ для конкурентных запросов, независимо от качества контента. Выше этого порога корреляция сырого DA с частотой цитирования ослабевает.

То, что заменило его как основной сигнал выше порога DA, — это авторитет сущности: насколько чётко и последовательно модели ИИ понимают, что представляет собой ваш сайт, что он охватывает и кому служит.

Согласованная идентичность сущности в интернете. Название вашей организации, адрес, URL и категория должны выглядеть одинаково на вашем собственном сайте в схеме, в бизнес-профиле Google, в отраслевых директориях и источниках цитирования. Несоответствие NAP напрямую фрагментирует идентичность вашей сущности на несколько слабых представлений вместо одного сильного.

Тематическая согласованность. Модели ИИ оценивают, есть ли у вашего сайта чёткий, последовательный тематический кластер. Сайт с 30 статьями в одной узкой нише является более авторитетной сущностью в этой нише, чем сайт с тем же DA, распределённым по 20 несвязанным темам.

Ссылки sameAs. Свойство sameAs в вашем JSON-LD связывает вашу сущность с её представлениями на Wikidata, Crunchbase, LinkedIn и других авторитетных графах. Модели ИИ используют их для подтверждения того, что сущность, о которой они рассуждают, — это та же, что описана в нескольких источниках. Полное руководство по реализации LocalBusiness JSON-LD охватывает правильную структуру.

Если ваш домен преодолел порог DA, улучшение авторитета сущности принесёт больше пользы для цитирования ИИ, чем дополнительное наращивание ссылок.

Уровень 2: Schema Markup

Schema markup — это уровень коммуникации между вашими страницами и системами поиска ИИ. Страницы со структурированными данными цитируются значительно чаще, чем страницы без схем. Обзоры Google AI Overviews предпочитают страницы со структурированными данными, и прирост отбора существенен для конкурентных запросов.

Большинство реализаций останавливаются на полях, которые удовлетворяют Rich Results Test Google, что не то же самое, что удовлетворить системы цитирования ИИ.

Что большинство реализаций делают правильно: @type, name, description, url, openingHours, telephone, address, FAQ schema.

Что большинство реализаций упускают для страниц объявлений: Типы схем, разработанные для инвентаря объявлений, требуют других свойств, чем типы, обсуждаемые в большинстве руководств.

Для страниц объявлений о недвижимости, аренде жилья для отпуска и гостиничном бизнесе соответствующими типами являются RealEstateListing, LodgingBusiness, Hotel, VacationRental, Apartment и SingleFamilyResidence, каждый вложен с Offer для цен и доступности. Эти типы выполняют свою функцию для поиска ИИ только в сочетании с правильными свойствами местоположения.

Ошибка FAQ Schema

FAQ schema ценна для редакционного контента. Она точно сообщает движкам ИИ, на какой вопрос отвечает тот или иной контент. Страницы объявлений не являются редакционным контентом. Объявление об объекте не отвечает на общий вопрос об аренде жилья для отпуска. Оно представляет конкретную сущность в конкретном месте. FAQ schema не помогает движку ИИ сопоставить это объявление с «2-комнатная квартира рядом с метро». Правильная схема для страниц объявлений — реляционная к сущностям, а не Q&A-образная.

Уровень 3: Geo Data (недокументированный уровень)

Модели ИИ, отвечающие на запросы, привязанные к конкретному месту («аренда жилья рядом с Йеллоустоном», «квартиры в 10 минутах от центра»), выполняют неявное геопространственное сопоставление. Они разрешают географические отношения между запрошенным местоположением и сущностями в своём пуле поиска. Чтобы это сопоставление работало, ваши страницы объявлений должны явно кодировать эти отношения в структурированных данных.

Точные GeoCoordinates на каждой странице объявления

Свойство geo типа GeoCoordinates с latitude и longitude не менее чем до четырёх десятичных знаков — это базовый сигнал. Без него движки ИИ геокодируют вашу строку адреса, что даёт сбой при любом несоответствии и обеспечивает значительно более низкую точность. Большинство реализаций, которые вообще включают geo, применяют его только к схеме LocalBusiness на уровне сайта, а не к отдельным страницам объявлений. Каждая страница объявления должна быть собственной разрешимой географической сущностью.

"geo": {
  "@type": "GeoCoordinates",
  "latitude": 48.8566,
  "longitude": 2.3522
}

containedInPlace: связывание объекта с географической иерархией

Свойство containedInPlace связывает ваше объявление с сущностями района, округа, города и региона, которые его географически содержат. Именно так движки ИИ отвечают на запросы вроде «квартиры в Марэ», а не просто «квартиры по [адресу улицы]». Без него объект существует как адрес, но не как член какой-либо именованной географической сущности.

"containedInPlace": {
  "@type": "Place",
  "name": "Le Marais",
  "containedInPlace": {
    "@type": "City",
    "name": "Paris"
  }
}

Близлежащие сущности Place: транспорт, школы, достопримечательности

Когда пользователь запрашивает «аренду рядом с метро», ИИ ищет явные машиночитаемые отношения между объектом и транспортной инфраструктурой. Предложение в вашем описании «5 минут пешком до метро Линии 4» ничего не даёт для поиска ИИ. Та же информация, структурированная как сущность Place, связанная через amenityFeature, — доступна для поиска.

Почему базы данных объявлений не содержат эти данные изначально

Большинство систем управления недвижимостью и баз данных объявлений хранят то, что вводят операторы: адрес, цена, количество спален, фотографии. Они создавались для людей, просматривающих портал, а не для машиночитаемого географического контекста. Mapping API восполняет этот пробел. Geocoding API конвертируют адреса в точные координаты. POI API возвращают остановки транспорта, школы, парки и достопримечательности в заданном радиусе. Результаты напрямую соответствуют типам schema.org и могут быть встроены в JSON-LD страниц объявлений в масштабе.

Как выглядит закрытие всех трёх пробелов

Страница объявления, хорошо работающая в поиске ИИ:

1. Размещена на домене с согласованной идентичностью сущности, ссылками sameAs и чётким тематическим кластером
2. Использует наиболее конкретный применимый тип схемы, вложенный с Offer для цен
3. Включает GeoCoordinates на самой странице объявления, containedInPlace, связывающий его с сущностями района и города, и структурированные данные ближайших сущностей Place для транспорта, школ и достопримечательностей

Большинство страниц объявлений охватывают части Уровня 1 и базовые части Уровня 2. Почти ни одна не охватывает Уровень 3. Именно страницы, охватывающие все три, появляются в ответах ИИ на запросы, привязанные к конкретному месту.

Только 1,2% местных предприятий в настоящее время появляются в рекомендациях ИИ-поиска. В среднем это не те, у кого наибольший авторитет домена. Это те, кто закрыл все три пробела.