Полный список Schema структурированных данных: как писать Article/FAQ/Product/Breadcrumb
I. Общие правила написания JSON-LD
Google рекомендует синтаксис JSON-LD, а не Microdata или RDFa. Здесь действуют три железных правила.
| Правило | Правильный подход | Неправильный подход |
|---|---|---|
| Синтаксис | <script type=”application/ld+json”> | Использовать Microdata или RDFa |
| Позиция | head или конец body | Ждать рендеринг после динамической вставки через JS |
| Значения полей | Дословно совпадают с видимым текстом страницы | В Schema указано «999 долларов», а на странице — «запросить цену» |
| Несколько типов | Использовать массив @type или взаимные ссылки через mainEntityOfPage | На одной странице нагромождено шесть-семь несвязанных типов |
Почему рекомендуют JSON-LD: он не связан со структурой HTML, и при обновлении шаблона разметка не сломается из-за изменений в DOM. Microdata встроена в атрибуты тегов, и достаточно поменять один class, чтобы всё сломалось.
Ещё два момента, которые легко упустить. Первый: все поля с датами должны быть в формате ISO 8601 с указанием часового пояса, например 2026-09-21T09:00:00+08:00, а не «сентябрь 2026 года». Второй: URL в полях должен быть доступен Google для прямого сканирования — не указывайте ссылки на админку, куда нужен вход. Обе эти проблемы в Rich Results Test дают только предупреждение, а не ошибку, поэтому их легко не заметить.
II. Article: страницы блога и white paper
Article — базовая разметка для страниц статей. Она определяет, появятся ли в SERP аватар автора, дата публикации и карусель миниатюр.
| Поле | Обязательно | Пример значения | Пояснение |
|---|---|---|---|
| @type | Да | Article | Для новостей — NewsArticle |
| headline | Да | Не более 110 символов | Совпадает с <title> |
| author | Да | {“@type”:”Person”,”name”:”Цуй Лишу”} | Рекомендуется также ссылаться на страницу автора |
| datePublished | Да | 2026-09-21T09:00:00+08:00 | Формат ISO 8601 |
| dateModified | Рекомендуется | Совпадает с datePublished или датой обновления | Обновляется при переработке статьи |
| изображение | Да | Не менее 1200×675 пикселей | Влияет на миниатюру в карусели |
| publisher | Рекомендуется | Связь с Organization | Включает поле logo |
Пример из практики: в B2B-блоге добавили Article, но в image использовали маленькую картинку 600×300. Rich Results Test выдал «image too small». После замены на обложку 1200×675 статья в течение недели появилась в карусели статей в SERP. Требования к размерам изображений см.Управление медиаактивами.
В поле author не указывайте только название компании — нужен конкретный автор со ссылкой на его страницу. Google читает это поле в панели знаний и в карусели авторов; если написать только “crater”, это не будет ни Person, ни Organization, и разметка будет проигнорирована. Страница автора должна быть доступна внутри сайта, а в SameAs добавьте внешние профили — LinkedIn, GitHub и другие.
3. FAQPage: главный канал для ответов ИИ
Хотя с 2023 года FAQPage больше не даёт расширенные сниппеты в выдаче для обычных корпоративных блогов, он остаётся главным каналом, через который ChatGPT, Gemini и Google AI Overviews читают вопросы и ответы.
| Поле | Обязательно | Пояснение |
|---|---|---|
| @type | Да | FAQPage |
| mainEntity[] | Да | Массив Question, от 5 до 6 штук |
| name | Да | Текст вопроса, совпадает с summary на странице |
| acceptedAnswer.text | Да | Ответ простым текстом, совпадает с видимым ответом на странице |
Контринтуитивный момент: с августа 2023 года раскрывающийся блок FAQPage в выдаче показывается только на авторитетных форумах и государственных сайтах — у обычного B2B-блога он не отобразится, даже если разметку добавить. Но писать её всё равно стоит: основной канал, через который ИИ-движки читают FAQ, — это массив mainEntity. Методология работы с FAQ описана в разделе FAQ и блок «Люди также спрашивают».
Красная линия: вопросы и ответы в mainEntity должны полностью совпадать с видимым FAQ на странице. Нельзя добавлять вопросы и ответы, которых на странице нет. Именно за это Google выдаёт ручное наказание за спам-разметку FAQ.
Следите и за длиной вопросов и ответов: вопрос — от 20 до 40 знаков, ответ — от 80 до 150. Слишком короткий вопрос выглядит как набор ключевых слов, слишком длинный выходит за пределы раскрывающегося блока в выдаче; слишком короткий ответ не даёт нужной плотности информации, и ИИ его не процитирует, а слишком длинный будет обрезан.
4. Product: зона высокой отдачи для страниц B2B-продуктов
Разметка Product определяет, появятся ли в выдаче карточка товара, цена и наличие. С полукастомными B2B-продуктами нужно быть сдержаннее.
| Поле | Обязательно | Что важно для B2B |
|---|---|---|
| name | Да | Полное название модели, совпадает с H1 |
| изображение | Да | Главное изображение; надёжнее, если есть минимум 3 фото продукта |
| description | Рекомендуется | Совпадает с meta description страницы продукта |
| brand | Рекомендуется | {“@type”:”Brand”,”name”:”…”} |
| offers.price | Когда есть чёткая цена | Для продуктов по запросу цену не указывайте |
| offers.availability | Рекомендуется | InStock / PreOrder, не проставляйте наугад |
| aggregateRating | Когда есть реальные отзывы | Звёзды без реальных отзывов гарантированно приведут к ручным санкциям |
Пример из практики 2: на странице продукта B2B-производителя оборудования указали offers.price=5000, хотя на самой странице написано только “цена по запросу”. Rich Results Test выдал предупреждение о несоответствии полей, а через две недели в отчёте о расширенных результатах GSC число показов расширенного результата для этой страницы упало до нуля. После удаления поля price и смены availability на PreOrder показы восстановились.
Несоответствие поля цены — самая частая причина аварий с разметкой Product. Если на странице полукастомного B2B-продукта цена не публикуется, не заполняйте её через силу ради карточки в выдаче.
5. BreadcrumbList: обязателен для всего сайта
BreadcrumbList позволяет Google показывать в выдаче хлебные крошки вместо длинного URL — это самая дешёвая по трудозатратам Schema для всего сайта.
| Поле | Обязательно | Пояснение |
|---|---|---|
| @type | Да | BreadcrumbList |
| itemListElement[] | Да | Полный путь от главной страницы до текущей |
| position | Да | Нумерация с 1 |
| name | Да | Отображаемый текст хлебных крошек |
| item | Рекомендуется | Абсолютный URL этого уровня |
В поле item указывайте только абсолютный URL, без относительных путей. Иерархия должна совпадать с видимыми хлебными крошками на странице: главная → раздел → подраздел → текущая страница, без пропуска уровней. Текущую страницу тоже нужно включить в itemListElement, иначе Google не поймёт, на какую страницу ведут крошки.
Шесть. Три шага проверки перед запуском
| Шаг | Инструмент | Срок | Критерий прохождения |
|---|---|---|---|
| Проверка по каждому URL | Тест расширенных результатов | В день перед публикацией | Ошибок нет, только допустимые предупреждения |
| Выборочная проверка после запуска | Прогнать онлайн-URL ещё раз | В день запуска | Результат рендеринга совпадает с локальным |
| Отчёт о расширенных результатах | Search Console | На 7, 14 и 30-й день | Показы не равны нулю, ошибок 0 |
Четыре типа Schema — это база для корпоративного сайта B2B. Organization и WebSite — ещё два типа, которые обязательно должны стоять в head на всём сайте. Полный разбор приоритетов смотрите в Структурированные данные Schema. Для многоязычных сайтов также проверьте, что поля Schema совпадают с локализацией чисел и таблиц, а валюта и единицы измерения не смешиваются между языковыми версиями.
Последний частый источник аварий — дубли Schema, которые автоматически создаёт плагин. Если на сайте WordPress установлен Yoast или Rank Math, плагин по умолчанию выводит разметку Article и Organization. Если вы вдобавок пишете свой JSON-LD, появится предупреждение duplicate field. Перед запуском прогоните через Rich Results Test страницу товара и страницу статьи: увидели дублирующиеся поля — отключите соответствующий модуль плагина и оставьте свою разметку.
Семь. Ежемесячный аудит Schema после запуска
Schema — это не то, что настроил и забыл. Правки шаблона, вывод и снятие товаров, изменение цен — всё это снова рассинхронизирует поля с видимым содержимым страницы. Полдня раз в месяц на аудит обойдутся дешевле, чем разбор последствий аварии.
| Что проверять | Как проверить | Частота | Критерий прохождения |
|---|---|---|---|
| Ошибки в отчёте о расширенных результатах GSC | Отчёт об опыте в Search Console | Ежемесячно | Ошибок 0, предупреждения допустимы |
| Поля совпадают с видимым текстом | Выборка из 10 страниц через Rich Results Test | Ежемесячно | Нет предупреждений о несовпадении полей |
| Синхронизация цены в Product | Сравнить поле price на странице товара с ценой на странице | После изменения цены | Для товаров по запросу цену поле price не оставляем |
| Путь в Breadcrumb | Выборка страниц второго уровня и сверка с крошками | После редизайна | Уровни без пропусков, item — абсолютный URL |
| Дубли Schema | Посчитать блоки ld+json в исходном коде страницы | После установки нового плагина | Нет дублей от плагина и ручной разметки |
Обнаружив проблему при аудите, не спешите править весь сайт. Сначала воспроизведите её в тестовой среде и определите, в шаблоне дело или на отдельной странице. Проблема в шаблоне затрагивает все страницы — достаточно исправить шаблон один раз. Проблема на отдельной странице чаще всего из-за того, что редактор случайно поменял цену или дату, — исправляйте постранично. Записывайте результаты ежемесячного аудита в одну таблицу: через три месяца вы увидите, какие ошибки повторяются, и внесёте их в руководство для редакторов, чтобы сократить повторные аварии у самого источника.
И последнее: Schema читают поисковые системы и AI-движки, а не посетители. Значения полей должны честно отражать реальное содержимое страницы. Не завышайте цены и не накручивайте рейтинги ради расширенных результатов. Если Google применит ручные санкции за спам в структурированных данных, восстановление займёт кварталы — игра не стоит свеч.
На многоязычных сайтах следите за языковой согласованностью полей Schema. В английских страницах поля JSON-LD заполняйте по-английски, в китайских — по-китайски, не смешивайте языки. Поле валюты должно соответствовать валюте, указанной на странице этого языка: для страниц под европейских клиентов не пишите доллары. Формат даты — единый ISO 8601, не пишите по местным привычкам двусмысленные форматы вроде “9/21/2026”. В Rich Results Test эти детали не вызовут ошибок, но снизят точность извлечения данных AI-движками.
FAQ: частые вопросы
Можно ли сделать поле headline в Article длиннее?
Может ли в FAQPage быть больше вопросов и ответов, чем на странице?
На странице Product нет публичных цен — как заполнять offers?
Можно ли в поле item у BreadcrumbList использовать относительные пути?
Можно ли на одной странице разместить одновременно Article и BreadcrumbList?
Через сколько после запуска Schema появятся расширенные результаты?
В заключение
Четыре основных типа Schema — минимальный набор для корпоративного сайта B2B: Article для блога, FAQPage для ответов AI, Product для страниц товаров, BreadcrumbList для всего сайта. Если написать правильно, расширенные результаты не гарантированы, а если ошибиться — точно потеряете право на них.
Три шага к внедрению: на этой неделе проверьте 5 шаблонных страниц через Rich Results Test и выпишите недостающие типы; на следующей — добавьте четыре шаблона JSON-LD в head, чтобы значения полей дословно совпадали с видимым текстом; на 30-й день убедитесь в отчёте о расширенных результатах Search Console, что ошибок нет.
Запомните одну вещь: Schema — важно не количество, а точность. Поля совпадают со страницей, цифры — с ценой, вопросы и ответы — с FAQ, тогда расширенные результаты и появятся.