Структурированные данные говорят поисковым системам, что означает ваш контент — не просто что написано словами, а является ли страница товаром, статьёй, рецептом или FAQ. Сделано правильно — Google показывает контент расширенными результатами: звёздные рейтинги, аккордеоны FAQ, хлебные крошки, карусели шагов. Сделано неправильно — разметка молча игнорируется. Это руководство охватывает все способы проверить структурированные данные на любом сайте: от инспекции исходного кода до автоматизированной валидации в CI.
Что такое структурированные данные?
Структурированные данные — это машиночитаемые метаданные, встроенные в веб-страницу, которые помогают поисковым системам понять контент за пределами видимого текста. Доминирующий формат — JSON-LD: тег script в нотации объектов JavaScript, размещаемый в `<head>` страницы и использующий словарь schema.org для описания сущностей: статей, товаров, событий, рецептов, организаций.
Когда поисковая система сканирует страницу, она извлекает эти блоки схемы и использует их для генерации расширенных результатов: улучшенных выдач, показывающих звёздные рейтинги, диапазоны цен, даты событий, аккордеоны FAQ и навигационные хлебные крошки прямо в SERP. Расширенные результаты стабильно достигают более высоких CTR, чем стандартные выдачи с синей ссылкой, потому что передают больше информации с одного взгляда.
Три формата структурированных данных
- JSON-LD: автономный тег `<script type="application/ld+json">` с JSON-объектом. Google рекомендует этот формат — проще всего добавить, валидировать и поддерживать, не трогая HTML страницы.
- Микроразметка (Microdata): атрибуты схемы (`itemscope`, `itemtype`, `itemprop`), добавляемые прямо к HTML-элементам. Жёстко связаны со структурой страницы — сложнее валидировать и обновлять.
- RDFa: атрибуты связанных данных (`typeof`, `property`) на HTML-элементах. Широко используется в некоторых CMS, но реже, чем JSON-LD, в новых реализациях.
Note
Как проверить структурированные данные
Есть четыре практичных способа проверить структурированные данные на странице, каждый подходит для своих ситуаций. Самые быстрые не требуют инструментов вовсе; самые тщательные нуждаются в валидаторе и тестовой среде Google.
Способ 1: просмотр исходного кода страницы
Кликните правой кнопкой по любой странице в браузере и выберите Просмотр кода страницы (Ctrl+U / Cmd+U). Нажмите Ctrl+F для поиска и найдите `application/ld+json`. Каждое совпадение — блок структурированных данных. Это сразу показывает, есть ли структурированные данные на странице, и позволяет скопировать JSON для валидации. На страницах, рендерящих контент через JavaScript, просмотр кода показывает только начальный HTML — используйте DevTools для отрендеренного вывода.
Способ 2: панель Elements в DevTools
Откройте DevTools Chrome (F12), перейдите во вкладку Elements и найдите `ld+json` в дереве элементов. Это показывает структурированные данные так, как их сейчас рендерит браузер — включая блоки, инжектированные JavaScript после загрузки страницы. Правильный подход для React, Next.js и любых фреймворков, добавляющих структурированные данные на клиенте или через серверный рендеринг.
Способ 3: Валидатор структурированных данных (самый быстрый в разработке)
Скопируйте блок JSON-LD и вставьте его в валидатор структурированных данных. Он валидирует синтаксис JSON, проверяет объявления `@context` и `@type` и помечает отсутствующие обязательные свойства для заявленного типа схемы — всё в вашем браузере, без отправки URL и ожидания сканирования. Это самый быстрый цикл в разработке: исправить и перепроверить можно за секунды.
Способ 4: Тест расширенных результатов Google
Отправьте URL живой страницы в Тест расширенных результатов Google по адресу `search.google.com/test/rich-results`. Google загружает страницу, извлекает все структурированные данные и сообщает, на какие типы расширенных результатов страница претендует. Это авторитетный тест права на расширенные результаты — но требует живого URL и занимает 5-30 секунд на проверку. Используйте его, когда локальная валидация чиста.
Валидатор Структурированных Данных
Валидируйте любой блок структурированных данных JSON-LD на синтаксис, обязательные свойства и соответствие schema.org — локально в браузере, без URL.
Валидация разметки JSON-LD
Валидация JSON-LD имеет два отдельных уровня: валидацию синтаксиса (структурно ли корректен JSON?) и валидацию схемы (соответствует ли содержимое обязательным и рекомендуемым свойствам типа schema.org?). Оба уровня должны пройти, прежде чем блок структурированных данных станет полезным.
Осмотрите страницу на предмет блоков JSON-LD
Кликните правой кнопкой по странице и выберите Просмотр кода страницы. Найдите `application/ld+json`. Скопируйте весь JSON-объект из тега script — от открывающей до закрывающей фигурной скобки. Если блоков несколько, копируйте каждый отдельно для валидации.
Валидируйте синтаксис валидатором JSON-LD
Вставьте скопированный блок в валидатор JSON-LD. Он проверяет, что JSON корректно сформирован, что `@context` установлен в `https://schema.org` и что `@type` ссылается на распознанный тип schema.org. Синтаксические ошибки сообщаются с номерами строк; предупреждения о неизвестном типе выявляют типы схем, которые вряд ли дадут расширенные результаты.
Проверьте обязательные свойства заявленного типа
У каждого типа схемы есть обязательные и рекомендуемые свойства. Схема `Product` требует `name` и `offers` или `review` для права на расширенный результат. `Article` требует `headline`, `author` и `datePublished`. Валидатор структурированных данных проверяет заявленный `@type` и помечает каждое отсутствующее или неверно отформатированное обязательное свойство.
Проверьте право на расширенные результаты инструментом Google
Когда локальная валидация чиста, отправьте URL страницы в Тест расширенных результатов Google. Просмотрите список обнаруженных типов схем и убедитесь, что каждый показан как допущенный, а не помечен ошибками. Разберитесь с предупреждениями «Рекомендуется» для свойств, которые улучшают качество расширенных результатов, хотя и не блокируют их.
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "How to Check Structured Data on a Website",
"author": {
"@type": "Person",
"name": "Devvrat Hans",
"url": "https://abacktools.com"
},
"datePublished": "2026-06-11",
"dateModified": "2026-06-11",
"publisher": {
"@type": "Organization",
"name": "Aback Tools",
"url": "https://abacktools.com"
}
}Tip
Частые ошибки структурированных данных
Большинство ошибок структурированных данных попадают в предсказуемые категории. Зная, что означает каждый тип ошибки — и почему он важен, — вы исправляете проблемы в правильном порядке: сначала синтаксис, затем обязательные свойства, в конце рекомендуемые улучшения.
Отсутствующие обязательные свойства
Google определяет обязательные свойства для каждого типа схемы, поддерживающего расширенные результаты. Если любое обязательное свойство отсутствует, вся схема теряет право на свою функцию расширенного результата. Частые примеры: `Product` без `name` или `offers`, `Recipe` без `name` или `recipeIngredient`, `Event` без `name`, `startDate` или `location`. Проверка полноты схемы Product специально аудирует схемы Product на все обязательные и рекомендуемые поля Google.
Неверные типы значений
Свойства schema.org ожидают конкретные типы значений. Свойства `url` должны быть абсолютными URL, начинающимися с `https://`; `ratingValue` должен быть числом (не строкой вроде `"4.5"`); `datePublished` должен быть корректной строкой даты ISO 8601. Передача строки там, где ожидается число, или относительного пути там, где нужна абсолютная URL, вызывает ошибку несоответствия типа, блокирующую корректное чтение схемы.
Несоответствие типа схемы и содержимого страницы
Google требует, чтобы структурированные данные точно отражали видимый контент страницы. Разметка `FAQPage` на странице без видимых вопросов-ответов или разметка `Product` на странице категории без конкретных деталей товара нарушает рекомендации Google по структурированным данным и может привести к ручным санкциям против права на расширенные результаты.
| Тип ошибки | Пример | Влияние | Как исправить |
|---|---|---|---|
| Отсутствует обязательное свойство | Product без name | Блокирует расширенный результат | Добавьте свойство |
| Неверный тип значения | ratingValue: "4.5" (строка) | Схема игнорируется | Используйте число: 4.5 |
| Относительная URL в поле url | image: /photo.jpg | Ошибка валидации | Используйте абсолютную HTTPS-URL |
| Неверный формат даты | datePublished: "июнь 2026" | Дата не распознана | Используйте формат YYYY-MM-DD |
| Неизвестный @type | @type: "BlogPosting2" | Схема не распознана | Используйте точный тип schema.org |
| Отсутствует @context | Нет объявления @context | Схема не извлечена | Добавьте контекст schema.org |
| Контент не совпадает | FAQPage на не-FAQ странице | Риск ручных санкций | Согласуйте схему с контентом |
Warning
Проверка по типу схемы
Разные типы схем имеют разные обязательные свойства, разные представления расширенных результатов и разные наиболее подходящие инструменты валидации. Вот как подойти к самым используемым типам.
FAQPage и HowTo
FAQPage — один из самых влиятельных типов схем для органического CTR: валидная схема FAQPage рендерится раскрывающимся аккордеоном прямо в результатах Google, показывая вопросы и ответы без клика. Используйте генератор схемы FAQ, чтобы получить чистую разметку FAQPage из простых пар вопрос-ответ, и валидируйте вывод валидатором JSON-LD. Для пошагового обучающего контента генератор схемы HowTo строит валидную разметку HowTo с правильно структурированными блоками `HowToStep`.
BreadcrumbList
Разметка BreadcrumbList генерирует цепочку хлебных крошек под заголовком страницы в результатах Google — заменяя сырой URL читаемой иерархией. Каждому `ListItem` нужны `name` и URL `item`. Используйте генератор схемы Breadcrumb, чтобы сгенерировать JSON-LD BreadcrumbList из пути URL или ручных записей, готовый к вставке прямо в шаблон страницы.
Organization и Article
Схема Organization устанавливает идентичность вашего сайта для графа знаний Google — название, логотип, контактную информацию и соцпрофили. Валидатор схемы Organization проверяет, что все рекомендуемые поля присутствуют и правильно отформатированы. Для редакционного контента схема Article с `author`, `datePublished` и `publisher` повышает право на Google News, Top Stories и Discover, что может привести значимый трафик на новостные и блоговые страницы.
Отзывы и агрегированные рейтинги
Звёздные рейтинги в результатах приходят из `AggregateRating`, вложенного в схему `Product`, `LocalBusiness` или `Recipe`. `ratingValue` должен быть числом, `reviewCount` — положительным целым, а `bestRating` и `worstRating` должны быть указаны во избежание неоднозначности. Проверка права на сниппеты отзывов валидирует разметку рейтингов против специфических требований Google к расширенным результатам отзывов.
| Тип схемы | Расширенный результат | Ключевые обязательные поля | Проверка Aback Tools |
|---|---|---|---|
| FAQPage | Аккордеон FAQ в SERP | mainEntity с вопросами и ответами | Генератор схемы FAQ |
| HowTo | Карусель шагов в SERP | name, step, text | Генератор схемы HowTo |
| BreadcrumbList | Хлебные крошки в SERP | itemListElement, name, item | Генератор схемы Breadcrumb |
| Product | Панель товара с ценой/рейтингом | name, offers или review | Проверка полноты схемы Product |
| Article | Top Stories, Discover | headline, author, datePublished | Валидатор JSON-LD |
| Organization | Панель знаний | name, url, logo | Валидатор схемы Organization |
| LocalBusiness | Локальный блок, карты | name, address, telephone | Валидатор структурированных данных |
Структурированные данные в CI/CD
Ручные проверки структурированных данных подходят для отдельных страниц, но крупным сайтам с шаблонами, генерирующими структурированные данные программно, нужна автоматизированная валидация. Добавление проверки структурированных данных в CI/CD-конвейер ловит регрессии до попадания в продакшн и блокирования права на расширенные результаты.
Извлечение и валидация в сборочных конвейерах
Самый надёжный подход — извлечь JSON-LD из собранного HTML-вывода и валидировать программно. После сборки разберите сгенерированные HTML-файлы, извлеките каждый блок `<script type="application/ld+json">` и прогоните через библиотеку валидации schema.org вроде `schema-dts` (TypeScript), `jsonld` (Node.js) или Structured Data Linter от Google. Роняйте сборку, если отсутствует обязательное свойство или JSON неверно сформирован.
# Extract all JSON-LD blocks from built HTML using grep
grep -rl 'application/ld+json' ./out/ | while read file; do
# Parse and validate each block
node scripts/validate-schema.js "$file"
done
# Or use a dedicated CLI tool
npx schema-validator ./out/**/*.html --strictМониторинг функций SERP
После деплоя следите за производительностью расширенных результатов в Google Search Console в разделе «Улучшения». Каждый реализованный тип схемы получает собственный отчёт с валидными элементами, предупреждениями и ошибками по мере сканирования страниц Googlebot. Внезапный всплеск ошибок обычно указывает на изменение шаблона, сломавшее схему для целой категории страниц. Проверка функций SERP даёт дополнительный взгляд — какие функции SERP триггерит конкретный URL сейчас.
Tip
Лучшие практики
Следование этим практикам обеспечивает корректность, поддерживаемость и соответствие рекомендациям Google ваших структурированных данных — максимальное право на расширенные результаты без риска ручных санкций или тихих сбоев схемы.
Синхронизируйте структурированные данные с видимым контентом
Самая частая причина ручных санкций Google против структурированных данных — несоответствие схемы и того, что видят пользователи. Если ваша схема `Product` показывает цену $29, а страница отображает $49, Google считает это обманной разметкой. Используйте CMS или шаблонную систему, чтобы генерировать структурированные данные из того же источника данных, что заполняет видимый контент страницы — никогда не хардкодьте в схеме значения, отображаемые динамически в другом месте.
Используйте конкретные типы, а не общие
У schema.org глубокая иерархия типов. Страница о программном продукте должна использовать `SoftwareApplication`, а не общий `Product`. Локальный ресторан должен использовать `Restaurant` (подтип `FoodEstablishment`), а не общий `LocalBusiness`. Более конкретные типы дают поисковым системам больше сигнала о контенте и могут открыть более богатые форматы отображения в результатах.
Структурированные данные не должны использоваться для обмана пользователей или предоставления вводящей в заблуждение информации. Структурированные данные страницы должны точно представлять содержимое страницы.
- Валидируйте до деплоя: прогоняйте валидатор структурированных данных на каждом блоке схемы до публикации — ловите ошибки раньше Googlebot.
- Одна сущность на блок: вкладывайте связанные сущности (например, `author` внутрь `Article`), а не создавайте отдельные блоки верхнего уровня для каждой подсущности.
- Абсолютные URL везде: поля `url`, `image`, `logo` и `sameAs` требуют полных `https://` URL — относительные пути в структурированных данных недопустимы.
- Добавляйте sameAs организациям: связывайте схему Organization с Википедией, Wikidata, LinkedIn и другими авторитетными источниками для усиления связи с графом знаний.
- Мониторьте Google Search Console: проверяйте отчёты «Улучшения» еженедельно — они показывают, какие страницы имеют валидные, с предупреждениями или ошибочные структурированные данные по мере сканирования Googlebot.
Note
Key takeaways
- Проверяйте структурированные данные поиском `application/ld+json` в исходном коде страницы — каждый тег script этого типа является блоком структурированных данных.
- Используйте валидатор структурированных данных в разработке для мгновенной, локальной в браузере валидации JSON-LD без отправки URL.
- Тест расширенных результатов Google — авторитетный инструмент права на расширенные результаты: запускайте его после чистой локальной валидации, а не вместо неё.
- Самые частые ошибки — отсутствующие обязательные свойства, неверные типы значений (строки там, где ждут числа) и относительные URL там, где нужны абсолютные HTTPS.
- Генерируйте корректную разметку схем для типов FAQPage, HowTo, BreadcrumbList и Product с помощью выделенных генераторов и валидаторов Aback Tools.
- Структурированные данные должны совпадать с видимым контентом страницы — расхождения между значениями схемы и отображаемыми значениями рискуют ручными санкциями против права на расширенные результаты.
- Мониторьте раздел «Улучшения» в Google Search Console после деплоя, чтобы отслеживать валидные элементы, предупреждения и ошибки по мере сканирования страниц Googlebot.