Разметка Schema.org под цитирование нейросетями

Что разметка дает и чего не дает

Разметка Schema.org в формате JSON-LD - это блок в коде страницы, где каждое значение подписано. Название организации, телефон, цена товара, дата обновления статьи. Парсер не гадает, что означает число 4990 в верстке: он читает свойство price и значение при нем.

Разночтения она снимает. На карточке товара могут стоять три числа подряд, и человек по верстке разберет, где старая цена, где новая, а где рассрочка. Машина по верстке не разберет ничего. Свойства price, priceCurrency и availability описывают товар так, что прочитать их иначе нельзя.

Дальше графы знаний. Google, Bing и Яндекс держат постоянные базы фактов о компаниях, и разметка Organization с адресом, телефоном и профилями в других сервисах - один из источников, откуда эти факты берутся. Модель, отвечающая пользователю, нередко берет сведения о компании из такой базы, а не из свежего обхода сайта. Обход мог не случиться вовсе.

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

Обязательным условием цитирования разметка не служит. В руководстве по AI-функциям Google указывает: специальной разметки под AI Overviews и режим AI Mode не требуется, а та, что стоит на сайте, должна соответствовать видимому содержимому. В Ahrefs проверяли это экспериментом: добавили разметку и прироста цитирований не получили - по AI Overviews вышел небольшой минус, по ChatGPT и AI Mode разницы не нашли. Условия замера и размер выборки в публикации не раскрыты, поэтому точную цифру мы не тиражируем, а направление принимаем как есть. Такой результат неудобен тем, кто продает разметку отдельной услугой под AI-поиск. Модель читает текст, и текст решает больше.

Слабую страницу разметка не поднимает. Текст отвечает мимо запроса - блок FAQPage вокруг него ничего не исправит.

Со структурой то же самое. Заголовки, короткие абзацы, прямой ответ в первых строках раздела - то, что система режет на фрагменты и цитирует. Как устроены сами ответы ассистентов, показано в статье что такое AEO, а на вопрос, почему сайт не попадает в ответы ChatGPT, мы отвечали отдельно.

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

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

Пять типов, с которых начинают

Порядок внедрения мы держим один и тот же: сначала компания, потом содержимое страниц, потом коммерческие сущности. Так у сайта появляется опора, к которой можно цеплять остальное.

Organization

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

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://example.com/#organization",
  "name": "Aqua Service",
  "url": "https://example.com",
  "logo": "https://example.com/img/logo.png",
  "telephone": "+7 700 000 00 00",
  "address": {
    "@type": "PostalAddress",
    "addressLocality": "Almaty"
  },
  "sameAs": ["https://www.youtube.com/@aquaservice"]
}

Свойство sameAs собирает профили компании в один узел и не дает системе спутать вас с однофамильцами. Тема большая, ей посвящена отдельная статья про сущность бренда.

Что пропускают: logo со ссылкой на картинку, которой давно нет, и разные написания названия на главной, в футере и в разметке. Для парсера это три разные компании.

Есть свойства, до которых доходят редко, хотя стоят они одной строки: foundingDate, numberOfEmployees, contactPoint с разделением по типу обращения - поддержка, продажи, пресса. Короткая карточка превращается в описание, из которого граф знаний берет больше фактов. Группу компаний описывают через parentOrganization и subOrganization, иначе система либо склеит юрлица в одно, либо разведет их как несвязанные.

Article и Person

Заголовок, автор, дата публикации, дата обновления, издатель. При отборе источников системы учитывают свежесть и авторство, поэтому статья без даты и без имени проигрывает статье с ними при прочих равных.

Свойства, которые заполняем всегда: headline, datePublished, dateModified, author в виде объекта Person со ссылкой на страницу автора, publisher с указанием на узел организации.

Промахи здесь типовые. author строкой вместо объекта - тогда автор остается текстом, а не сущностью. И dateModified, который проставили один раз при запуске и не трогают четвертый год. Дата, застывшая в прошлом, работает против страницы.

Person без страницы автора дает мало: имя в шапке, дальше пустота. Другое дело автор с отдельной страницей, где описан опыт, и с sameAs на профили в других сервисах: он становится сущностью, которую система узнает в следующий раз. Для тем про здоровье, деньги и право разница ощутима: там репутация автора влияет на отбор источника сильнее, чем оформление текста.

Подтип берите по содержимому: BlogPosting для заметок блога, NewsArticle для новостей, TechArticle для документации и технических руководств. Общий Article подойдет везде, но уточнить тип ничего не стоит.

Product и Offer

Название, артикул, цена, валюта, наличие, рейтинг, отзывы. Google не перестал показывать расширенные результаты по товарам, так что здесь разметка окупается напрямую.

Заполняем: name, sku или gtin, вложенный offers с price, priceCurrency, availability, при наличии отзывов - aggregateRating и review.

Место, где код и страница расходятся почти у всех: цена. Разметка тянется из старой выгрузки, на витрине показывается акционная, а Google требует, чтобы они совпадали. Второе типовое расхождение - aggregateRating с рейтингом, посчитанным по отзывам, которых на странице нет.

aggregateRating требует ratingValue и reviewCount либо ratingCount, и эти числа пользователь должен видеть на той же странице. Магазины выводят рейтинг картинкой или подгружают отзывы скриптом уже после загрузки. А в код кладут число из базы. Формально данные верные. Для проверяющего робота страница и разметка все равно расходятся, и весь блок отправляется в ошибки.

Реже заполняют brand объектом, gtin13 или mpn для сопоставления товара с каталогами производителей, shippingDetails и hasMerchantReturnPolicy с условиями доставки и возврата. Последние два Google принимает и на уровне организации целиком - магазину с большим каталогом это снимает часть работы по карточкам.

LocalBusiness

Адрес, телефон, часы работы, зона обслуживания, категория бизнеса. Вместо общего LocalBusiness берите точный подтип из словаря: Dentist, Restaurant, AutoRepair. Чем точнее тип, тем меньше домыслов на стороне системы.

Ставим address объектом PostalAddress, openingHoursSpecification расписанием, areaServed списком городов или районов, geo координатами.

Филиалы описывают по одному узлу на адрес: у каждого свой идентификатор @id, и все они цепляются к головной организации через parentOrganization. Страница контактов со списком из восьми городов и одним блоком LocalBusiness внутри дает системе ровно один адрес. Остальные семь остаются текстом, который никто не разбирает.

Часы работы задаются свойством openingHoursSpecification с днями недели и временем, а не строкой «пн-пт с 9 до 18». Строку прочитает человек. Машина возьмет ее как есть и ничего с ней не сделает.

Есть еще адрес и телефон: они должны сходиться на сайте, в картах и в каталогах. Разметка тут только один из носителей данных, и если в справочниках стоит старый номер, правильный telephone в JSON-LD ситуацию не спасет. Разбор целиком - в статье про NAP и цитирования.

FAQPage

Пары вопрос-ответ. В списке этот тип идет последним, потому что за прошедший год потерял почти все, ради чего его ставили. Устаревших советов вокруг него сейчас больше, чем вокруг остальных четырех вместе.

7 мая 2026 года Google снял расширенные результаты FAQ: блоки с раскрывающимися вопросами в выдаче больше не показываются, о чем сказано прямо в справке по FAQPage. В июне 2026 из Search Console пропал отчет по этому типу и поддержка в Rich Results Test, в августе 2026 тип уходит из Search Console API. Сам тип по словарю Schema.org остается валидным, и Google отдельно отметил, что неиспользуемая разметка не создает проблем и убирать ее не нужно.

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "Question text exactly as shown on the page",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Answer text exactly as shown on the page"
      }
    }
  ]
}

Условие, которое нарушают чаще прочих: вопросы и ответы должны быть видны человеку на странице, а не оставаться только в коде. Ставить FAQPage ради расширенного результата в Google смысла больше нет. Остается другой резон: сторонний парсер увидит готовые пары вопрос-ответ, а обходится это одним блоком в шаблоне.

На конструкторе, где блок вопросов на странице есть и разметка ставится автоматически, оставьте ее как есть - вреда никакого. Заводить разработчику задачу на FAQPage летом 2026 года не стоит, деньги уйдут в поле, которое поисковая система больше не показывает.

HowTo и Speakable: когда добавлять

Второй эшелон. Оба типа встречаются в чек-листах по GEO, и оба требуют оговорок.

HowTo размечает пошаговую инструкцию: шаги, инструменты, материалы, время. Google убрал расширенные результаты по нему в 2023 году - сначала на мобильных, затем на десктопе - и позже снял документацию по типу с сайта для разработчиков. Ни в одной выдаче Google этот формат сейчас не выводится. По словарю Schema.org тип валиден, порядок действий в нем описан машиночитаемо, и сторонний парсер его прочитает. Оправдан он там, где инструкция и правда пошаговая: пронумерованные шаги с отдельными действиями, а не абзац, где все действия идут через запятую.

HowTo ставят ради структуры данных, а не ради выдачи. Шаги на странице пронумерованы - разметка зафиксирует последовательность, и парсер получит готовый порядок действий вместо сплошного текста. Шагов нет, а тип объявлен - код обещает то, чего на странице нет.

Speakable помечает фрагменты, которые можно зачитать вслух. Формат до сих пор в статусе беты, поддерживается для новостных сайтов США на английском языке и работает через Google Assistant. Рекомендация Google - помечать 20-30 секунд содержимого, примерно два-три предложения, а не статью целиком. Русскоязычному сайту услуг он сегодня не даст ничего, кроме валидного кода.

Замены ему в русскоязычной практике нет, и это нормально. На голосовые ответы работает сам текст: короткий прямой ответ в начале раздела и простые предложения без ссылок и сносок внутри фразы. Ассистент зачитывает один источник, второго места там нет, так что все держится на формулировке.

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

Как собрать разметку в один граф

Типовая картина на сайте среднего возраста: четыре отдельных блока application/ld+json в исходном коде. Один вставила CMS, второй SEO-плагин, третий подрядчик два года назад, четвертый добавили на прошлой неделе. Формально ошибок нет. Фактически парсер получает четыре несвязанных описания и сам решает, какое из них про вашу компанию.

Один общий граф эту неопределенность убирает. Все сущности лежат в одном блоке внутри @graph, у каждой есть постоянный идентификатор @id, и ссылаются они друг на друга по нему.

{
  "@context": "https://schema.org",
  "@graph": [
    {"@type": "Organization", "@id": "https://example.com/#organization", "name": "Aqua Service"},
    {"@type": "WebSite", "@id": "https://example.com/#website", "publisher": {"@id": "https://example.com/#organization"}},
    {"@type": "Article", "@id": "https://example.com/blog/post#article", "publisher": {"@id": "https://example.com/#organization"}, "author": {"@id": "https://example.com/#anna"}},
    {"@type": "Person", "@id": "https://example.com/#anna", "name": "Anna Li"}
  ]
}

Organization и WebSite описываются один раз на весь сайт и выводятся в общем шаблоне, а Article, Product, BreadcrumbList и LocalBusiness для филиала - постранично. Порядок сущностей внутри @graph роли не играет, связи держатся на идентификаторах.

Идентификаторы заводят один раз и дальше не трогают. Схема, которая работает без сюрпризов: #organization, #website, #logo, #author на уровне сайта и адрес страницы плюс #article, #product, #breadcrumb на уровне страницы. Домен внутри @id пишется в одном варианте - с https, без www, без завершающего слеша. Смена написания посреди сайта дает две сущности там, где задумывалась одна, и замечают это спустя полгода.

Проверьте, что вставляет платформа сама. Конструкторы и CMS часто добавляют свою разметку организации автоматически, и после ручного внедрения на странице оказываются две сущности Organization с разными названиями. Валидатор покажет обе, поиск в исходном коде по строке application/ld+json - тоже.

Разметку иногда путают с llms.txt, хотя задачи у них разные. JSON-LD описывает содержимое конкретной страницы в свойствах и значениях, llms.txt лежит в корне сайта и подсказывает системе устройство ресурса целиком: где разделы, где документация, что читать в первую очередь. Нужен ли он вашему проекту, разбирали в материале про llms.txt.

Чем проверять и какие ошибки повторяются

Валидаторов три, и каждый проверяет свое.

Schema Markup Validator на validator.schema.org проверяет соответствие словарю: правильные ли типы, существуют ли свойства, не перепутан ли объект со строкой. Он ничего не знает про поисковые системы и не подскажет, будет ли расширенный результат.

Rich Results Test от Google проверяет другое: пригодна ли разметка к расширенным результатам и какие обязательные поля отсутствуют. Работает только по типам, которые Google поддерживает сейчас, поэтому FAQ и HowTo вы там уже не найдете.

Валидатор микроразметки в Яндекс Вебмастере лежит в разделе «Инструменты». Он читает Schema.org, микроформаты, Open Graph, Microdata и RDFa, и заодно сверяет разметку с требованиями сервисов Яндекса.

Ошибки, которые повторяются от проекта к проекту:

• незакрытая скобка или лишняя запятая в JSON - блок не парсится целиком
• свойство не того типа: строка там, где ожидается объект PostalAddress
• дата не в формате ISO 8601, вместо 2026-07-14 стоит 14.07.2026
• значение в разметке не совпадает с тем, что видит пользователь на странице
• @id без домена или с разными вариантами написания одного адреса

Отдельная категория - разметка, которая валидна и при этом врет. Валидатор ее пропустит: синтаксис верный, свойства существуют. Поймать такое можно, только если сверить код и страницу руками, поэтому в аудите мы берем выборку из десятка адресов на каждый тип и проходим значения глазами.

Массовую проверку удобно делать краулером. Screaming Frog и его аналоги вытаскивают JSON-LD со всех страниц сразу и показывают, где типов нет вовсе, где они дублируются, а где остался блок от прошлой версии сайта.

Механика отказа ступенчатая. Сломанный синтаксис - незакрытая скобка, лишняя запятая - выключает весь блок JSON-LD: парсер не читает его вовсе. Ошибка в обязательном свойстве выключает сущность: Article с датой в неверном формате уходит в невалидные целиком, вместе с автором и издателем. Поэтому валидатор прогоняют не один раз при внедрении, а после каждой правки шаблона.

Отчеты по разметке смотрят в Search Console, раздел «Улучшения», и в Яндекс Вебмастере. Там видно, сколько страниц с валидной разметкой по каждому типу, и есть список адресов с ошибками.

Последнее: разметка, которую вставляет менеджер тегов или скрипт на стороне браузера, для многих роботов не существует - они читают исходный HTML и до нее не доходят. Механику мы разбирали в статье про сайты на JavaScript.

Разметка ради разметки: что не работает

Размечать то, чего на странице нет. Прямое нарушение правил поисковых систем: за расхождение разметки с видимым содержимым сайт теряет расширенные результаты, а при системном обмане получает ручные меры. Отзывы, которых никто не оставлял, и рейтинг 4,9 из воздуха - самый частый вариант.

Ставить FAQPage на страницу без блока вопросов. После мая 2026 года такая разметка не дает расширенного результата даже теоретически, зато код и страница расходятся.

Разметка, скопированная у другого сайта. В таком JSON-LD остаются чужое название, адрес и @id с посторонним доменом. Мы такое встречали на сайтах, где подрядчик взял код у конкурента и поменял только имя компании в первой строке.

Пустой текст разметка не компенсирует. Страница на 300 знаков с идеальным Article внутри не начнет цитироваться. Система забирает фрагменты текста, а разметка помогает их правильно подписать.

Прятать размеченное от пользователя. Блок вопросов с нулевой высотой под FAQPage поисковые системы разбирают как маскировку. Прилетает не за разметку как таковую, а за расхождение между тем, что видит робот, и тем, что видит человек.

Оставлять код от прежней версии сайта. При переезде на новую CMS в шаблоне остается блок с прошлым названием компании, старыми телефонами и адресами страниц, которых больше нет. Полгода он собирает ошибки в отчетах вебмастера, и никто в них не заглядывает.

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

Что делать после внедрения

Порядок событий предсказуемый. Сначала робот переобходит страницу, потом тип появляется в отчетах вебмастера, потом выдача отдает расширенные результаты, и только затем меняются ответы систем. Яндекс в справке пишет, что структурированный сниппет может сформироваться после очередного переобхода, примерно через две недели, и по нашим проектам отчеты Search Console подтягивают новые типы за те же одну-две недели, а крупные разделы дольше.

Зафиксируйте состояние до внедрения, иначе сравнивать будет не с чем. Минимум: список адресов с типами разметки, скриншоты выдачи по десятку целевых запросов, ответы систем по промптам вашей ниши. Замер занимает вечер, а без него любой разговор про результат превращается в ощущения.

Первым делом после релиза смотрим отчеты: ушли ли ошибки по типам, сошлось ли число страниц с валидной разметкой с общим числом страниц в разделе. Следом смотрим расширенные результаты по товарам и хлебным крошкам. Если через месяц валидных страниц заметно меньше ожидаемого, причину ищем не в разметке, а в индексации: страница вне индекса не даст ни сниппета, ни цитаты.

Сдвиг в ответах систем приходит последним. Разметка тут один сигнал среди многих, и приписывать ей рост цитирований без второго замера мы не беремся.

Потом поддержка. Разметка расходится с сайтом каждый раз, когда меняют шаблон, правят цены или переезжают на новую версию CMS. Мы ставим валидатор в один список с проверкой битых ссылок - раз в квартал и после каждого релиза.

Как построить регулярный замер видимости в системах и что в нем считать, расписано в материале про измерение видимости в нейросетях.

Коротко

• Базовый набор для сайта услуг: Organization на весь сайт, Article на статьи, LocalBusiness при наличии адреса, Product для карточек товаров
• Расширенные результаты FAQ Google снял 7 мая 2026 года, по HowTo - в 2023 году; оба типа остались валидными по словарю Schema.org, выдача их больше не показывает
• Google в документации по AI-функциям указывает: отдельной разметки под генеративные ответы не требуется, а имеющаяся должна совпадать с видимым содержимым
• В эксперименте Ahrefs добавление разметки не дало прироста цитирований: по AI Overviews небольшой минус, по AI Mode и ChatGPT разницы не нашли
• Четыре разрозненных блока JSON-LD читаются хуже одного графа с @graph и постоянными @id
• Сломанный синтаксис выключает весь блок JSON-LD, ошибка в обязательном свойстве - сущность целиком; валидатор прогоняют после каждой правки шаблона

Об авторе

Марат Аксанов, сооснователь GEO-агентства HITZ.

Об агентстве

HITZ - GEO-агентство, работающее с рынками Казахстана и Узбекистана. Мы занимаемся видимостью брендов в ответах нейросетей и поисковых систем: техническая база, разметка, содержимое, замеры цитирования. Подробнее об услуге - на странице GEO.

Частые вопросы

Обязательна ли разметка, чтобы попасть в ответы нейросетей?

Нет. Документация Google по AI-функциям говорит, что отдельная разметка под генеративные ответы не нужна: системы разбирают текст страницы. При этом разметка снимает разночтения и передает факты в графы знаний, откуда модель берет сведения о компании между обходами сайта. Считать ее пропуском в ответы неверно - страницы цитируются и без единой строки JSON-LD, а слабый текст с идеальным кодом не цитируется вовсе.

Какой формат выбрать: JSON-LD или разметку в самой верстке?

JSON-LD. Google рекомендует его как основной формат, блок лежит отдельно от верстки и переживает редизайн без потерь. Microdata и RDFa словарь тоже поддерживает, системы их читают корректно, но атрибуты вшиты в теги: переверстка шаблона уносит часть разметки, и без валидатора пропажу не заметить. Еще аргумент за JSON-LD: его удобно собирать в один граф со связями между сущностями, в атрибутах верстки так не получится.

Можно ли разметить вопросы, которых нет на странице?

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

Сколько типов разметки ставить на одну страницу?

Столько, сколько на странице сущностей. Для статьи хватает трех: Article, BreadcrumbList и Organization в роли издателя. Для карточки товара - Product с вложенным Offer плюс те же хлебные крошки и организация. Для страницы услуги с адресом нужен еще LocalBusiness. Лишние типы добавляют работы по поддержке: каждую сущность нужно держать в согласии с сайтом при любой правке шаблона.

Что проверять, если разметка стоит, а расширенного результата нет?

Проверяйте по порядку: поддерживает ли Google этот тип сейчас, чист ли валидатор, переобойдена ли страница, видна ли разметка в исходном HTML, пока скрипты не отработали, совпадают ли значения с содержимым. Заодно посмотрите отчет «Улучшения» в Search Console: там видно, дошел ли тип до индекса. Если все сходится, остается последнее - расширенный результат это право поисковой системы, а не обязанность перед сайтом.

Чем разметка отличается от файла llms.txt?

Она описывает одну конкретную страницу: свойства, значения, связи между сущностями. Файл llms.txt лежит в корне и рассказывает про ресурс целиком - какие разделы есть, что в них лежит, с чего начинать чтение. Первое поддержано поисковыми системами давно и проверяется валидаторами, второе остается инициативой, которую принимают не все. Одно другое не заменяет.