Как работают структурированные данные: системы и семантика

Структурированные данные (JSON-LD-разметка на странице) — это блок кода, который объясняет роботу, что именно на странице: название компании, хлебная крошка, вопрос и ответ. Сайту услуг из всего словаря Schema.org реально нужны три типа: Organization описывает компанию, BreadcrumbList — положение страницы в структуре сайта, FAQPage или Article — сам контент страницы. Проверить, что разметка распознаётся правильно, можно за пять минут через Rich Results Test от Google и валидатор микроразметки Яндекса. Дальше в статье — таблица по типам, готовый пример кода и то, что размечать не нужно вовсе. Разобраться в разметке своего сайта помогает технический SEO-аудит сайта: в него входит проверка структурированных данных вместе со скоростью и индексацией.

Зачем разметка нужна именно сайту услуг

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

Официальная позиция Google звучит осторожно: «Структурированные данные помогают Google понимать содержимое ваших страниц и обеспечивают появление специальных элементов в результатах поиска» — документация Google Search Central (developers.google.com/search/docs/appearance/structured-data, проверено 29.09.2026). Разметка не гарантирует позиции и не заменяет текст. Она снижает риск, что робот истолкует страницу неправильно, и открывает доступ к расширенным элементам выдачи — если контент вообще этого заслуживает.

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

Есть и вторая причина, которая набирает вес в 2026 году. ИИ-ассистенты в поиске — Нейро в Яндексе, обзоры с ИИ в Google, отдельные чат-боты — собирают ответ из нескольких страниц сразу и опираются на явную структуру не меньше, чем классический поисковый робот. Чем понятнее машине, где на странице организация, а где конкретный факт про услугу, тем ниже риск, что ответ соберётся из чужого текста или устаревшей копии страницы в кеше. Разметка не гарантирует цитирование, но убирает часть препятствий на пути к нему.

Три типа разметки, без которых сайту услуг не обойтись

Не нужно размечать всё подряд. На практике сайту компании, которая продаёт услуги, хватает трёх типов — остальное из объёмного словаря Schema.org пригодится редко и почти никогда не окупает время на внедрение.

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

BreadcrumbList дублирует видимую навигацию (хлебные крошки) в машиночитаемом виде. Разметка обязана совпадать с реальной структурой меню: если в интерфейсе путь «Главная → SEO → Технический аудит», а в JSON-LD указано иначе, робот замечает нестыковку и меньше доверяет остальной разметке страницы.

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

FAQPage — самый спорный тип на 2026 год. Здесь есть развилка, которую нужно знать до внедрения.

FAQPage: Яндекс показывает, Google — нет

Проверка на 29.09.2026 подтверждает разрыв между поисковиками. Google официально убрал расширенный результат FAQ из выдачи: документация Search Central сообщает, что «функция расширенного результата FAQ больше не отображается в результатах поиска Google» с 7 мая 2026 года (developers.google.com/search/docs/appearance/structured-data/faqpage). До этого сниппет и так показывался ограниченно — с осени 2023 года преимущественно государственным и медицинским сайтам.

Яндекс разметку FAQPage по-прежнему поддерживает и способен показать вопросы-ответы аккордеоном прямо в выдаче, хотя и не гарантирует это для каждой страницы с корректной разметкой. Для сайта, ориентированного на Москву и Россию, разметка FAQPage сохраняет практический смысл — ради Яндекса, не ради Google.

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

Остальные расширенные результаты Google при этом никуда не делись. Хлебные крошки работают. Звёздный рейтинг товара — тоже. Карточка организации в панели знаний зависит от Organization, а не от FAQPage. Решение по FAQ — точечное: убрали именно этот блок, а не разметку целиком. Работы планируйте с учётом этой точечности, а не отказывайтесь от структурированных данных вообще из-за одной новости.

Пример: JSON-LD для страницы услуги

Для типовой страницы услуги достаточно объединить Organization и BreadcrumbList в одном блоке @graph, а FAQPage добавить отдельным объектом, если на странице реально есть блок вопросов. Пример ниже — упрощённый каркас, который дорабатывают под конкретную страницу:

```json
{
"@context": "https://schema.org",
"@graph": [
{ "@type": "Organization", "name": "Название компании", "url": "https://example.ru/",
"logo": "https://example.ru/logo.png", "telephone": "+7 999 000-00-00" },
{ "@type": "BreadcrumbList", "itemListElement": [
{ "@type": "ListItem", "position": 1, "name": "Главная", "item": "https://example.ru/" },
{ "@type": "ListItem", "position": 2, "name": "Услуги", "item": "https://example.ru/services/" },
{ "@type": "ListItem", "position": 3, "name": "Название услуги" }
] }
]
}
```

Блок вставляют в <head> или конец <body> страницы через тег <script type="application/ld+json">. Для сайта на WordPress разметку удобнее генерировать программно из полей страницы, а не прописывать вручную на каждом URL — иначе при следующем обновлении цены или адреса кто-то забудет поправить JSON-LD, и данные разойдутся с видимым текстом.

Где хранить разметку в разных CMS

На WordPress разметку выводит SEO-плагин (Yoast, RankMath) для Organization и хлебных крошек, а FAQPage чаще приходится добавлять отдельным полем в шаблоне страницы или мини-плагином под конкретный блок вопросов на сайте — готовый автогенератор из коробки редко покрывает произвольную FAQ-вёрстку. На 1С-Битрикс разметку кодируют прямо в компонентах инфоблоков: страница услуги и карточка товара получают свой JSON-LD из полей инфоблока, а не общий шаблон на весь сайт.

На конструкторах вроде Тильды базовый Organization и Product генерируется автоматически при заполнении карточки компании в настройках сайта, а произвольные типы вроде FAQPage приходится вписывать вручную через блок HTML-кода — готового поля для этого конструктор не даёт.

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

Когда разметка «тихо» ломается

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

Первое — разметка не совпадает с видимым текстом страницы. Цена в JSON-LD одна, на странице — другая после сезонной акции; название организации в разметке отличается от того, что в подвале сайта. Формально ошибки нет, но системе нечему доверять.

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

Третье — разметка правильная, но контент странице не соответствует статусу: под FAQPage — всего два вопроса, и оба формальные. Такая разметка не помогает и иногда привлекает больше внимания к слабому контенту, чем его отсутствие.

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

Особый случай — разметка отзывов. Review и AggregateRating в Google и Яндексе проверяются строже остального словаря Schema.org: если в разметке указаны оценки, которые нельзя подтвердить (собраны вручную, взяты у другого сервиса, накручены), поисковики расценивают это как попытку ввести пользователя в заблуждение. Последствия здесь серьёзнее тихой деградации — вплоть до ручных мер по конкретной странице или разделу сайта. Разметку отзывов подключайте только тогда, когда отзывы реальны, датированы и видны на самой странице текстом, а не только в коде.

Пример на живой странице: техподдержка сайта

Возьмём типовую страницу услуги — техподдержка сайта с пакетами часов и ценами. Что на ней размечать, а что нет.

Organization — да, один раз, общий для всего сайта блок из футера. BreadcrumbList — да, три уровня: главная, раздел услуг, сама страница. FAQPage — да, если внизу страницы действительно есть блок вопросов про пакеты и время реакции, и нет, если такого блока нет и делать его ради разметки не планируется.

Цены пакетов — не Product и не Offer. Это разовые тарифы на услугу, а не товар с фиксированной ценой на складе. Схема Service для российского сегмента Schema.org применяется реже и почти никогда не даёт расширенного результата ни в Яндексе, ни в Google — тратить на неё время разработчика незачем, если только не нужно решить конкретную техническую задачу вроде интеграции с прайс-агрегатором.

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

Что не нужно размечать

Разметка — не место для обещаний и амбиций. Не описывайте через Schema.org:

• внутренние процессы компании и планы на будущее;
• отзывы, которые нельзя подтвердить (сфабрикованные, редакционные, «отзывы от команды»);
• временные акции и информацию, которая устареет через неделю;
• характеристики, которых на странице нет текстом — разметка не должна придумывать за контент.

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

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

Разметка требует поддержки, а не разового внедрения

Разметка не остаётся верной сама по себе. Меняется цена — меняется текст на странице. Меняется адрес офиса — меняется контакт в подвале. JSON-LD об этом не узнает автоматически, если тянется не из тех же полей, что видимый текст.

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

Как проверить разметку

Для проверки под Google — Rich Results Test (search.google.com/test/rich-results): вставляете URL или код страницы, инструмент показывает, какие расширенные результаты доступны, и подсвечивает ошибки и предупреждения. Для более широкой проверки синтаксиса словаря Schema.org без привязки к Google подходит Schema Markup Validator (validator.schema.org).

Для Яндекса — валидатор микроразметки в Вебмастере (webmaster.yandex.ru/tools/microtest/): можно проверить прямо по адресу страницы или вставить HTML-код вручную, поддерживаются Schema.org, Microdata, RDFa и микроформаты. Инструмент показывает, как робот Яндекса видит вашу разметку и какие поля не распознал.

После крупной правки сайта — редизайна, смены CMS, изменения меню — нужно перепроверить хотя бы Organization и BreadcrumbList на ключевых страницах: это самые чувствительные к структурным изменениям типы разметки, а их ломает даже небольшая правка шаблона. Заодно можно решить, какие ещё страницы вернуть в поиск: начните с проверки статуса в Вебмастере, разбор как вернуть малоценную страницу в поиск объясняет, что делать с уже исключёнными URL.

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

Организация с несколькими адресами: что не дублировать

У компании один сайт и несколько точек по Москве или регионам — салон, офис, склад с самовывозом. Соблазн разметить каждую как отдельную Organization высок, но неверен: организация одна, а у неё несколько мест работы. Правильная модель — одна Organization плюс несколько объектов LocalBusiness или Place со своим адресом и часами работы, привязанных к той же организации через поле parentOrganization или department.

Если на сайте нет отдельных страниц под каждый адрес, а просто список точек в подвале, разметка филиалов почти всегда избыточна. Карточки на Яндекс Картах и в Яндекс Бизнесе (business.yandex.ru) для локального поиска весят больше, чем JSON-LD на сайте. Завести и подтвердить их проще, чем поддерживать разметку филиалов вручную.

Порядок внедрения за один день

1. Выгрузите список ключевых страниц: главная, 5–10 страниц услуг, 2–3 статьи блога.
2. Проверьте, что каждая страница уже даёт правильные хлебные крошки в интерфейсе — разметка BreadcrumbList должна их просто повторить.
3. Соберите один блок Organization с актуальными названием, телефоном и адресом и вставьте его в общий шаблон сайта (футер или head).
4. Для каждой страницы услуги добавьте BreadcrumbList, привязанный к её реальному пути в меню.
5. Там, где на странице есть настоящий блок вопросов и ответов, добавьте FAQPage; для остальных страниц — пропустите этот шаг.
6. Прогоните все правки через Rich Results Test и валидатор микроразметки Яндекса до публикации, не после.
7. Через две недели проверьте раздел «Расширенные результаты» в Search Console и статус в Вебмастере.