JSON-LD на практике: как размечать страницы под нейроответы

JSON-LD — формат, в котором факты о странице записываются отдельным машиночитаемым блоком: организация, услуга, товар, автор, дата публикации. Для нейросетей это способ получить проверяемые утверждения, не вытаскивая их догадками из сплошного текста. Работает разметка при трёх условиях: она совпадает с тем, что видит человек, объекты связаны между собой через @id, и блок присутствует в исходном HTML, а не появляется после исполнения скриптов. Ниже — рабочая раскладка типов по страницам, сравнение способов внедрения, семь ошибок, которые мы чаще всего снимаем в аудитах, и проверка, которая занимает минуту.

Алексей Малков

Основатель GEOAudit.org • GEO/SEO-стратег

150+ аудитов • 12 лет в digital • 100+ отзывов на фрилансе

JSON-LD и Schema.org Технический GEO-аудит Валидация разметки

Профиль автора →

JSON-LD — это отдельный блок фактов о странице, а не разметка текста

JSON-LD (JavaScript Object Notation for Linked Data) — формат, в котором факты о странице записываются отдельным блоком в исходном коде: что за организация, какая услуга описана, кто автор материала, когда он опубликован. Человек этот блок не видит, браузер его не рисует. Читают его роботы поисковых систем и краулеры AI-платформ. Отличие от microdata и RDFa принципиальное: там атрибуты вплетаются прямо в вёрстку абзацев и заголовков, здесь всё лежит отдельно, внутри тега <script type="application/ld+json">. Дизайнер переставил блоки местами — разметка осталась целой. Поэтому JSON-LD 1.1 стал рекомендацией W3C в 2020 году, а Google в справке для разработчиков называет его предпочтительным форматом структурированных данных.

Ищут эту тему по-разному: «JSON LD разметка», «микроразметка сайта», «структурированные данные», «structured data». Предмет один, и термины стоит развести один раз. Schema.org — это словарь: какие бывают объекты (Organization, Product, Article, FAQPage) и какие у них свойства; проект запущен в 2011 году совместно Google, Microsoft, Yahoo и Яндексом. JSON-LD — способ записать этот словарь в код страницы. Какие типы важнее для генеративного поиска, разобрано отдельно в материале Schema.org для GEO. Здесь — про то, как довести разметку до рабочего состояния и не сломать её по дороге.

Разметка не поднимает позиции — она убирает у машины догадки

Первое, что стоит принять до внедрения: прямой связи «добавили JSON-LD — выросли позиции» нет. В документации Google структурированные данные описаны как условие для расширенных результатов поиска, а не как самостоятельный фактор ранжирования. Польза в другом. Без разметки система разбирает страницу догадками: вот это, наверное, цена, вот это, вероятно, автор, а фамилия в подвале — то ли эксперта, то ли верстальщика. Разметка снимает вопросы: услуга такая, провайдер такой, цена такая, обновлено тогда-то. Чем меньше догадок, тем выше шанс, что машина воспроизведёт факт без искажения. Проверить, дошёл ли факт до ответа неискажённым, можно только замером на стороне платформ — этим занимаются сервисы мониторинга упоминаний, и выбирают их по восьми критериям, из которых для разметки важнее всего частота прогона и сохранение истории ответов для сравнения периодов.

Здесь нужно жёсткое разделение. SEO отвечает за позиции в органической выдаче Яндекса и Google. GEO (Generative Engine Optimization) — за то, назовёт ли ChatGPT, Алиса, Perplexity, Gemini или Grok ваш бренд в собственном ответе. Разметка работает на оба слоя, но по-разному: классическому поиску она даёт основание показать расширенный сниппет, генеративному — набор готовых проверяемых утверждений, которые не нужно вытаскивать из сплошного текста. GEO работает поверх SEO, а не вместо него: сайт, которого нет в органической выдаче, одной разметкой в нейроответ не втащишь.

Отдельный сюжет — даты. Дата публикации и дата последнего изменения передаются полями datePublished и dateModified строго в формате ISO 8601: 2026-08-06. Человеку на странице можно показать «6 августа 2026», машине — только цифрами. В аудитах мы стабильно снимаем два случая: дату в разметке не передают вовсе либо она приклеена к шаблону и уверяет робота, что все материалы сайта вышли в один день три года назад. Для генеративных систем свежесть источника — один из аргументов при выборе, кого процитировать, и терять его по невнимательности обидно. Если CMS не подставляет дату последнего изменения, для машины материал не обновлялся никогда.

Правило зеркала: в разметке только то, что человек видит на странице

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

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

• FAQPage с восемью вопросами, из которых на странице видно три: остальные пять «дописали для схемы».
• AggregateRating с рейтингом и числом оценок при том, что на странице нет ни одного отзыва и негде посмотреть, откуда взялась цифра.
• Product с ценой из внутреннего прайса, пока на видимой карточке написано «цена по запросу».
• Article с автором, которого нет ни в тексте, ни в разделе команды: имя существует только внутри блока разметки.
• Организация с адресом филиала, который закрылся год назад, но остался в шаблоне и продолжает уезжать в машиночитаемом виде.

Один @graph на страницу связывает объекты надёжнее пяти отдельных блоков

Типичная картина на входе в аудит: на странице пять блоков JSON-LD. Один поставил разработчик в шаблоне, второй пришёл с SEO-плагином, третий добавили по инструкции про FAQ, ещё два прилетели с темой оформления. Формально каждый валиден. Фактически на странице пять несвязанных объектов: Organization не знает про Article, Article не знает про автора, автор не знает про Organization. Машина видит набор карточек без связей и достраивает связи предположениями — ровно то, ради устранения чего разметку и ставили.

Собранный граф решает это четырьмя приёмами. Порядок важен: каждый следующий опирается на предыдущий.

1. Один блок с @graph. Все объекты страницы перечисляются внутри одного контейнера. Разработчику проще следить за одним местом, а вам — проверять.
2. Постоянные @id. Идентификатор объекта — URL с якорем: адрес сайта плюс #organization, #website, #article. Один и тот же @id организации на всех страницах означает «это та же самая компания», а не новая фирма на каждом URL.
3. Ссылки вместо копий. Свойства publisher, author, provider, isPartOf указывают на @id уже описанного объекта, а не дублируют его целиком. Копия расходится с оригиналом при первой же правке.
4. sameAs наружу. Ссылки на внешние профили компании и экспертов — то, что связывает ваше заявление с подтверждениями за пределами сайта.

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

Какой набор типов ставить на каждый тип страницы

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

Два уточнения к таблице. FAQPage даёт заметный эффект в генеративных ответах, потому что формат «вопрос — короткий ответ» совпадает с тем, как модель собирает реплику; детали формата разобраны в материале про FAQ и HowTo для нейросетей. Товарные сайты выигрывают от связки Product и Offer больше остальных: там разметка описывает то, что в тексте вообще не проговаривается — наличие, валюту, состояние, гарантию. Отраслевые нюансы для магазинов собраны в материале про GEO для интернет-магазинов.

Способ внедрения решает, доедет ли разметка до краулера

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

Видит ли AI-краулер разметку, вставленную через тег-менеджер

Вопрос, который почти не разбирают в материалах про structured data, а он определяет результат целиком. Тег-менеджер добавляет блок в DOM после того, как страница загрузилась и отработал JavaScript. Значит, разметка существует только для робота, который исполняет скрипты. Googlebot это умеет, но рендеринг у него отдельный отложенный этап. Краулеры, которые собирают данные для AI-платформ, устроены проще: часть из них забирает сырой ответ сервера и на этом заканчивает работу. В сыром ответе никакого JSON-LD нет.

Проверка занимает минуту и не требует инструментов: откройте исходный код страницы (view-source) или запросите её через curl без исполнения скриптов и поищите строку application/ld+json. Если блок виден только в инспекторе браузера, но не в сыром ответе — вы размечали для одного робота из нескольких. Кто вообще ходит по сайту и кого туда пускать, разбираем в материалах про robots.txt и AI-краулеров и индексацию сайта в 2026 году.

За 150+ аудитов я видел ровно одну ошибку, которая повторяется чаще всех остальных вместе взятых: разметку внедрили один раз и больше к ней не возвращались. Сайт переехал на новый шаблон, поменяли цены, сменили автора блога, закрыли филиал — а JSON-LD продолжает рассказывать машине версию двухлетней давности. Валидатор при этом молчит: синтаксис-то в порядке. Поэтому в технических аудитах мы проверяем не «есть ли разметка», а совпадает ли она с тем, что сегодня написано на видимой части страницы.

Алексей Малков

Основатель GEOAudit.org

Валидная разметка и понятая разметка — разные вещи

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

Инструментов достаточно четырёх, все бесплатные:

• Schema Markup Validator (validator.schema.org) — синтаксис и соответствие словарю, без привязки к требованиям конкретной поисковой системы.
• Rich Results Test от Google — покажет, на какие расширенные результаты страница претендует и что мешает.
• Валидатор микроразметки в Яндекс.Вебмастере — разбор со стороны Яндекса, включая собственные требования площадки.
• Исходный код без исполнения JS — единственный способ увидеть страницу глазами краулера, который не рендерит скрипты.

Семь ошибок, которые мы чаще всего снимаем на технических аудитах — в порядке частоты, а не тяжести:

1. Дубли объектов. Два Organization с разными @id на одной странице: один из шаблона, второй из плагина. Машина не выбирает лучший, она видит две компании.
2. Разметка только на главной. Внутренние страницы, которые как раз и попадают в ответы, остаются без единого блока.
3. Плавающие @id. Идентификатор меняется от страницы к странице — связи рассыпаются, каждый URL описывает новый объект.
4. Даты из шаблона. У всех материалов сайта одна дата публикации, а dateModified не двигается после правок.
5. Нарушенное правило зеркала. В полях есть то, чего нет в видимом тексте: отзывы, вопросы, цены, авторы.
6. Разметка только в тег-менеджере. Для краулеров без рендеринга сайта с разметкой попросту не существует.
7. Копипаст чужого блока. В url или sameAs остался чужой домен, в name — чужое название. Встречается чаще, чем кажется, и обнаруживается только чтением.

Разметка — один из блоков технической готовности, а не весь список. Что ещё проверяется вместе с ней, собрано в чек-листе GEO-аудита: доступность для краулеров, скорость, дубли, структура заголовков. Соседняя проверка — адреса внутри самих полей url, sameAs и isPartOf: если объект ссылается на страницу, отвечающую 404 или уехавшую через цепочку редиректов, валидатор промолчит, а связь в графе будет вести в никуда — как такие адреса находить и каким типом редиректа закрывать, разобрано в материале про битые ссылки и настройку редиректов.

Когда JSON-LD не нужен и что не сработает

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

• Разметка вместо контента. Если на странице нечего описывать, описывать в JSON-LD тоже нечего. Пустая страница с богатым графом объектов остаётся пустой страницей.
• Разметка вместо репутации. Машиночитаемое заявление о себе не заменяет упоминаний снаружи. Что о вас пишут в каталогах и отзывах, весит больше, чем то, что вы написали о себе сами.
• Все типы Schema.org сразу. Словарь огромный, но большинство типов к вашему бизнесу не относится. Лишний тип не даёт бонуса, зато добавляет место, где разметка разъедется с контентом.
• FAQPage ради расширенного сниппета. Требования поисковых систем к тому, кому показывать FAQ-сниппет, менялись не раз. Ставить блок стоит потому, что он полезен человеку и удобен машине, а не ради конкретного оформления в выдаче.
• Разметка на сайте, закрытом от краулеров. Если робот не получает страницу, содержимое блока не имеет значения.

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

Если непонятно, в каком состоянии разметка сейчас, начните с малого: бесплатная диагностика за 24 часа стоит 0 ₽ и показывает, что нейросети отвечают про вашу компанию и видят ли они сайт вообще. Когда нужно разобрать машиночитаемость по всем страницам, а не по одной, — это зона технического GEO-аудита от 40 000 ₽: 42 пункта проверки, включая графы объектов, даты, дубли и доступность для AI-краулеров.

FAQ