Страницы объявлений недвижимости в ИИ-поиске: почему они скрыты

Порталы недвижимости следуют стандартному плану AEO. У них есть FAQ schema на посадочных страницах. У них есть разметка LocalBusiness на главной странице. Они пишут разговорный контент, нацеленный на низкочастотные запросы. И большинство из них всё равно не появляются, когда кто-то спрашивает у движка ИИ «2-комнатные квартиры рядом с университетом в [город]».

Причина структурная, а не косметическая. Страницы объявлений - это не контентные страницы. Тактики AEO, разработанные для редакционного контента, неприменимы к инвентарю объявлений. Это руководство написано для операторов платформ объявлений: порталов недвижимости, сайтов аренды жилья для отпуска, маркетплейсов квартир. Не для индивидуальных агентов. Эта проблема отличается от проблемы видимости отелей, но первопричина та же: отсутствующий слой гео-данных.

Почему стандартные советы по AEO не работают для страниц объявлений

Стандартные советы по AEO звучат примерно так: пишите разговорный контент, добавляйте FAQ schema, нацеливайтесь на низкочастотные вопросы, выстраивайте тематический авторитет. Это верно для редакционного контента: блог-постов, руководств и посадочных страниц. Полное руководство по AEO для местных предприятий хорошо охватывает эти тактики.

Страницы объявлений не отвечают на вопросы уровня категории. Они представляют конкретные сущности: трёхкомнатную квартиру в конкретном месте с конкретными атрибутами, доступную по конкретной цене. Движки ИИ извлекают сущности, а не тексты.

Когда пользователь спрашивает Perplexity «аренда рядом с Парком де ла Вийет дешевле 1500 евро», ИИ выполняет географическое сопоставление сущностей. Он ищет сущности объявлений с подтверждённым местоположением в пределах разрешимой географической зоны, ценой в указанном диапазоне как структурированным атрибутом и машиночитаемыми связями с запрошенным ориентиром или районом.

Блок FAQ на вашей странице объявления не помогает ИИ выполнить это сопоставление. Схема LocalBusiness на вашей главной странице не помогает ему найти отдельное объявление, расположенное на две страницы глубже в вашей URL-структуре. Сущность, которая должна быть машиночитаемой, - это сама страница объявления.

Что движкам ИИ действительно нужно от страницы объявления

Конкретный тип схемы. На schema.org есть типы, разработанные для инвентаря объявлений: RealEstateListing, Apartment, SingleFamilyResidence, House, LodgingBusiness, VacationRental. Использование общего типа LocalBusiness или Article на страницах объявлений помещает их в неправильную категорию сущностей для запросов о недвижимости.

Цена и доступность как структурированные данные. Вложенный Offer внутри типа объявления предоставляет движкам ИИ структурированные атрибуты цены и доступности, необходимые для сопоставления объявлений с запросами, включающими ценовые ограничения. Цена, присутствующая только в видимом тексте страницы, не является запрашиваемым атрибутом.

Гео-данные. Этот слой отсутствует практически в каждой реализации, и он подробно рассматривается в следующем разделе.

Три пробела в гео-данных

Пробел 1: Нет координат на самой странице объявления

Точные GeoCoordinates с latitude и longitude не менее чем до четырёх десятичных знаков должны присутствовать в JSON-LD самой страницы объявления. Строки адресов не являются заменой. Распространённая ошибка - применять geo только к схеме LocalBusiness на уровне сайта на главной странице. Отдельные страницы объявлений нуждаются в собственных координатах. Каждое объявление является отдельной географической сущностью. Как правильно реализовать это для любого типа объявления описано в руководстве по JSON-LD schema.

Пробел 2: Нет связи containedInPlace

containedInPlace связывает объявление с сущностями района, округа и города, которые его географически содержат. Это делает объявление доступным для запросов на уровне района, а не только на уровне адреса.

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

"containedInPlace": {
  "@type": "Place",
  "name": "Prenzlauer Berg",
  "containedInPlace": {
    "@type": "City",
    "name": "Berlin"
  }
}

Пробел 3: Нет данных о ближайших местах

Запросы вроде «квартиры рядом с S-Bahn» или «дома рядом с хорошими школами» требуют, чтобы у объявления были структурированные связи с ближайшими географическими объектами. Предложения в описании вашего объекта недостаточно. Та же информация в виде структурированной сущности Place, связанной через amenityFeature, с координатами остановки транспорта и атрибутом расстояния, является запрашиваемой.

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

Большинство систем управления объектами и баз данных объявлений хранят то, что вводят операторы: адрес, цена, количество комнат, фотографии. Они создавались для людей, просматривающих портал. Координаты, границы районов и данные ближайших POI не являются стандартными полями, потому что программное обеспечение для объявлений никогда не разрабатывалось для предоставления машиночитаемого географического контекста системам поиска ИИ.

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

Полная структура схемы для страницы объявления

{
  "@context": "https://schema.org",
  "@type": "Apartment",
  "name": "3-room apartment, Prenzlauer Berg",
  "description": "Bright 3-room apartment, 78 sqm, renovated kitchen, south-facing balcony.",
  "numberOfRooms": 3,
  "floorSize": { "@type": "QuantitativeValue", "value": 78, "unitCode": "MTK" },
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "Kastanienallee 42",
    "addressLocality": "Berlin",
    "postalCode": "10435",
    "addressCountry": "DE"
  },
  "geo": {
    "@type": "GeoCoordinates",
    "latitude": 52.5384,
    "longitude": 13.4132
  },
  "containedInPlace": {
    "@type": "Place",
    "name": "Prenzlauer Berg",
    "containedInPlace": { "@type": "City", "name": "Berlin" }
  },
  "amenityFeature": [
    {
      "@type": "LocationFeatureSpecification",
      "name": "S-Bahn Prenzlauer Allee",
      "value": true,
      "description": "350m, approximately 4 minutes walk"
    },
    {
      "@type": "LocationFeatureSpecification",
      "name": "Grundschule am Kollwitzplatz",
      "value": true,
      "description": "600m, approximately 7 minutes walk"
    }
  ],
  "offers": {
    "@type": "Offer",
    "price": 1450,
    "priceCurrency": "EUR",
    "availability": "https://schema.org/InStock"
  }
}

Теперь это объявление является разрешимой географической сущностью. Его можно найти по запросам по районам, по близости, по ценовым ограничениям и по количеству комнат. Объявление без слоя гео-данных может быть найдено только если ИИ случайно сопоставит его строку адреса с запрошенным местоположением, что ненадёжно.

Разница между AEO для агентов и AEO для порталов

Индивидуальные агенты, занимающиеся AEO, решают другую проблему: видимость бренда и контента, руководства по районам, FAQ-контент. Операторы порталов решают проблему масштабирования инвентаря. Каждая страница объявления нуждается в собственных гео-данных, встроенных на уровне страницы. Это требует систематического конвейера данных, а не контентной стратегии.

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