Schema и JSON-LD для нейропоиска: какие факты размечать

Начните с реестра фактов, а не с JSON-LD

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

Я бы начал с реестра фактов и назначил владельца каждого класса данных. Для первой версии достаточно пяти полей:

«Я рассматриваю Schema не как техническую надстройку, а как договор о фактах компании. У каждого факта должны быть публичный источник, одинаковый смысл во всех местах и конкретный ответственный».

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

Разведите Schema.org, JSON-LD и поддержку поисковика

Три понятия часто смешивают, хотя они отвечают за разные решения:

1. Schema.org - словарь типов и свойств. Он описывает, что такое Organization, Person, Service, Article и какие связи между ними возможны.
2. JSON-LD - формат записи связанных данных. Google поддерживает также Microdata и RDFa, но обычно рекомендует JSON-LD как более простой для внедрения и поддержки в масштабе.
3. Google, Яндекс и другие сервисы сами решают, какие типы и свойства учитывать. Поэтому наличие свойства в Schema.org не равно поддержке конкретного расширенного результата.

Для AI-поиска эта граница особенно важна. В документе об AI-функциях Поиска Google прямо указывает: особой Schema.org-разметки для AI Overviews и AI Mode не нужно, а структурированные данные должны совпадать с видимым текстом.

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

Выберите главную сущность каждой страницы

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

Для Google стоит сверять не только словарь Schema.org, но и документацию по конкретному типу. Например, для Organization важны точные название, URL и логотип, а для Article - корректные автор, заголовок, даты и изображение. Google также отдельно описывает ProfilePage и BreadcrumbList.

Здесь не нужно дублировать всю компанию на каждой странице. Глобальная Organization должна иметь один устойчивый идентификатор, а статья или услуга ссылается на нее как на уже описанную сущность.

Свяжите сущности устойчивыми @id

@id - это машинный идентификатор узла в графе JSON-LD. Спецификация W3C описывает такие идентификаторы как способ однозначно назвать объект и связать его с другими узлами.

«Если для поля нельзя показать видимую страницу и назвать владельца обновления, его рано добавлять в JSON-LD. Сначала нужно договориться, что компания считает правдой и где эта правда живет».

Минимальный JSON-LD-граф сильнее набора дублей

Ниже - упрощенный пример для статьи. Он не заполняет все возможные свойства, а связывает три реальные сущности: компанию, автора и материал.

{  "@context": "https://schema.org",  "@graph": [    {      "@type": "Organization",      "@id": "https://example.ru/#organization",      "name": "Пример",      "url": "https://example.ru/",      "logo": "https://example.ru/logo.png",      "sameAs": [        "https://social.example/example"      ]    },    {      "@type": "Person",      "@id": "https://example.ru/team/anna/#person",      "name": "Анна Иванова",      "jobTitle": "Руководитель направления",      "url": "https://example.ru/team/anna/",      "worksFor": {        "@id": "https://example.ru/#organization"      }    },    {      "@type": "Article",      "@id": "https://example.ru/blog/material/#article",      "headline": "Заголовок материала",      "mainEntityOfPage": "https://example.ru/blog/material/",      "author": {        "@id": "https://example.ru/team/anna/#person"      },      "publisher": {        "@id": "https://example.ru/#organization"      },      "datePublished": "2026-08-11",      "dateModified": "2026-08-11"    }  ]}

При реальном внедрении поля нельзя копировать из примера. Имя, должность, URL, даты и все связи должны прийти из данных конкретной страницы. Дата dateModified меняется после содержательного обновления, а не при каждой сборке сайта.

Описывайте Organization как одну компанию

Глобальный узел Organization - это не каталог всего, что бизнес когда-либо говорил о себе. Это короткий, актуальный паспорт сущности.

В базовую модель обычно входят:

• name - единообразное публичное название;
• url - канонический адрес сайта;
• logo - доступный URL актуального логотипа;
• sameAs - только реальные внешние профили этой же компании;
• contactPoint, email, telephone или address - когда эти контакты действительно опубликованы;
• бизнес-идентификаторы - если они нужны, корректны для юрисдикции и у них есть публичное основание.

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

«Большой JSON-LD не сильнее маленького сам по себе. Сильнее тот, в котором меньше неподтвержденных полей, нет дублей и каждое значение обновляется вместе со страницей».

Отдельно опишите услугу, автора и статью

Service, Person и Article не нужно сваливать в один глобальный объект. У каждой сущности свой источник и свой жизненный цикл.

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

Для автора нужен отдельный Person с реальным профилем. В рекомендациях по Article Google советует указывать тип автора и URL или sameAs, а в author.name оставлять только имя. Должность хранится отдельно в jobTitle, а издатель - в publisher.

Для статьи нужны реальные headline, author, datePublished, dateModified, image и mainEntityOfPage. Если дата или изображение еще не назначены, поле не нужно заполнять заглушкой. Фактическое значение добавляют, когда оно уже определено для публикации.

FAQPage описывает текст, а не подменяет его

В FAQPage можно передавать только те вопросы и ответы, которые видит читатель. Отдельная скрытая подборка «удобных для поиска» ответов создает две редакции одной страницы.

При этом нужно разделять словарь и возможности конкретного поисковика. Google перестал показывать FAQ rich results 7 мая 2026 года и затем удалил документацию функции. Тип FAQPage остается в словаре Schema.org и может быть частью согласованного графа, но для Google его наличие больше нельзя считать способом получить отдельный FAQ-сниппет.

Не превращайте JSON-LD в склад заявлений

В разметку не нужно переносить:

• рейтинги и отзывы, которые не видны или не имеют проверяемого источника;
• неактуальные цены, тарифы и зоны работы;
• все услуги компании на каждую страницу, даже если материал о другой теме;
• награды, сертификаты и статусы без точной формулировки и видимого доказательства;
• чужие профили в sameAs только из-за совпадения названия;
• личные данные сотрудников, которые компания не публикует;
• скрытый текст, которого нет на видимой странице.

Я бы удалил сомнительное поле, а не оставлял его «на всякий случай». Полнота не компенсирует противоречие.

Генерируйте разметку из тех же данных, что и страницу

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

Порядок работы для масштаба:

1. Хранить название, описание, автора, даты, изображение и другие факты в одной модели контента.
2. Рендерить из нее видимую страницу.
3. Из тех же полей собирать JSON-LD.
4. Хранить глобальные Organization и авторов отдельно от тела статьи.
5. Запретить публикацию, если обязательное поле типа пусто или невалидно.
6. Тестировать шаблон на наборе разных страниц, а не на одном удобном примере.
7. После деплоя проверять уже отдаваемый HTML, а не только исходный шаблон.

При такой схеме команда не «синхронизирует Schema» вручную. Она обновляет факт один раз, а видимая страница и машинный слой меняются вместе.

Проверяйте разметку на трех уровнях

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

1. Код. JSON корректен, типы и свойства существуют, URL абсолютны, даты имеют верный формат, а обязательные поля не пусты.

2. Смысл. Каждое поле совпадает с видимым текстом, @id не дублируют сущности, sameAs ведут к этой же компании или человеку, а даты отражают реальные события.

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

Проверять нужно именно отдаваемую страницу. Для Google используют Rich Results Test и профильные отчеты Search Console. Для Яндекса доступен валидатор микроразметки, а справка Яндекса отдельно показывает, какие схемы используются в его сервисах.

«Для меня приемка заканчивается не зеленым валидатором, а проверкой изменения. Меняем должность автора или описание услуги в источнике и смотрим, что видимая страница и JSON-LD обновились вместе».

Чек-лист приемки Schema и JSON-LD

Перед публикацией страницы проверьте:

1. У страницы есть одна понятная главная сущность.
2. Каждое свойство имеет видимый эквивалент на этой или связанной публичной странице.
3. Глобальные Organization и Person имеют одинаковые устойчивые @id во всех шаблонах.
4. author, publisher, provider и worksFor ссылаются на существующие узлы, а не создают их заново.
5. Даты, URL, изображения, контакты и sameAs реальны и доступны.
6. JSON-LD проходит валидацию для целевых поисковых систем.
7. Разметка проверена в фактически отдаваемом HTML.
8. Тестовое изменение в источнике одинаково обновило страницу и Schema.
9. У каждого класса фактов есть владелец и триггер повторной проверки.

Schema должна усиливать весь сайт, а не жить отдельно

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

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