Как валидировать структурированные данные без инструментов Google

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

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

Более надёжный рабочий процесс начинается со стандартов. Сначала валидируйте данные как данные, затем словарь, затем страницу в том виде, в каком она существует в production.

Что именно вы валидируете?

«Структурированные данные» — это не что-то одно. На большинстве сайтов у них четыре слоя:

1. Синтаксис JSON — можно ли разобрать код?
2. Модель JSON-LD — раскрывается ли она в осмысленные связанные данные?
3. Словарь Schema.org — правдоподобны ли типы и свойства?
4. Правда на уровне страницы — соответствует ли разметка тому, что видят пользователи и краулеры?

Инструменты Google в основном сосредоточены на четвёртом слое плюс на специфических для Google критериях eligibility для расширенных результатов. Полезно — да. Полноценно — нет.

Например, это может быть валидным JSON-LD и всё равно оставаться слабой структурированной разметкой:

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Best winter jackets",
  "datePublished": "2026-01-12",
  "author": {
    "@type": "Organization",
    "name": "Editorial Team"
  }
}

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

Шаг 1: Разберите JSON, прежде чем думать о SEO

Начните со скучной проверки: можно ли разобрать JSON?

JSON-LD, встроенный в HTML, часто ломается из-за небольших ошибок в шаблонах:

• завершающие запятые
• неэкранированные кавычки в названиях товаров
• недопустимые переносы строк внутри строк
• отсутствующие фигурные скобки после условных полей
• дублирующиеся script-блоки из-за наследования layout
• CMS-плагины, выводящие неполные объекты

Для локальных проверок SEO-платформа не нужна. Используйте инструменты, которые уже есть в вашем стеке разработки.

В JavaScript:

const blocks = [...document.querySelectorAll('script[type="application/ld+json"]')];

for (const block of blocks) {
  try {
    JSON.parse(block.textContent);
  } catch (error) {
    console.error('Invalid JSON-LD:', error.message, block);
  }
}

В CI извлекайте содержимое script из отрендеренного HTML и разбирайте его как JSON. Это ловит многие проблемы до того, как они попадут в production.

Главное: делайте это до любой валидации Schema.org. Валидатор словаря не поможет, если данные не являются валидным JSON.

Шаг 2: Проверяйте поведение JSON-LD, а не только синтаксис JSON

Валидный JSON не становится автоматически валидным JSON-LD. JSON-LD использует такие понятия, как @context, @type, @id и отношения в графе. Если они malformed, парсеры могут интерпретировать данные не так, как вы рассчитывали.

Как минимум убедитесь, что:

• у каждого блока есть подходящий @context
• у основных сущностей есть ясные значения @type
• повторяющиеся сущности используют стабильные значения @id, когда это полезно
• вложенные сущности логически связаны
• массивы используются там, где возможно несколько значений

Для крупных сайтов стабильные идентификаторы особенно полезны. Если ваша организация появляется в данных Article, Product, BreadcrumbList и FAQPage, использование одного и того же @id помогает потребителям понять, что это ссылки на одну и ту же сущность, а не четыре не связанные между собой организации с одинаковым названием.

Типичный паттерн выглядит так:

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://example.com/#organization",
  "name": "Example Ltd",
  "url": "https://example.com/"
}

Здесь цель не в том, чтобы впечатлить валидатор. Вы делаете свои данные менее неоднозначными.

Шаг 3: Валидируйте по словарю Schema.org

Когда JSON и структура JSON-LD в порядке, проверьте словарь.

Валидатор Schema.org полезен, потому что проверяет термины Schema.org, а не правила расширенных результатов одной поисковой системы. Он может показать, распознаны ли свойства, интерпретируются ли типы ожидаемым образом и имеют ли смысл вложенные структуры.

Именно здесь вы ловите ошибки вроде:

• publishingDate вместо datePublished
• imageUrl там, где ожидается image
• разметка Product на странице категории, которая не является товаром
• AggregateRating без осмысленного объекта оценки
• Person, использованный для бренд-аккаунта

Осторожно относитесь к предупреждениям. Schema.org намеренно гибок. Валидатор может разрешать свойство, которое бесполезно для вашего случая, или предупреждать о чём-то необязательном. Воспринимайте валидацию как свидетельство, а не как приговор.

Практическое правило: если свойство помогает машине точнее понять страницу, оставьте его. Если оно существует только потому, что кто-то скопировал его из генератора сниппетов, поставьте его под сомнение.

Шаг 4: Сравните разметку с видимым контентом

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

Для каждого типа структурированных данных сравните разметку с видимой страницей:

Article и BlogPosting

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

Product

Проверьте название, цену, наличие, валюту, варианты, рейтинги и количество отзывов. Структурированные данные Product особенно склонны устаревать, потому что цены и статус наличия меняются вне CMS.

LocalBusiness

Проверьте название, адрес, телефон, часы работы и зону обслуживания. Если в footer написано одно, а в JSON-LD другое, JSON-LD не «лучше». Он противоречив.

BreadcrumbList

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

Это не самая эффектная работа. Но именно здесь находится много проблем со структурированными данными.

Шаг 5: Валидируйте отрендеренную страницу, а не шаблон

Многие сайты генерируют JSON-LD через JavaScript, tag managers, слои персонализации или гидратацию компонентов. Это означает, что файл шаблона может не отражать того, что на самом деле видит краулер или браузер.

Валидируйте отрендеренный HTML как минимум в трёх состояниях:

• локальная development-сборка
• staging или preview URL
• production URL

Используйте browser DevTools, чтобы изучить итоговый DOM. Найдите application/ld+json и скопируйте точное содержимое script, существующее после рендеринга. Если server-rendered разметка отличается от hydrated-разметки, решите, какую версию, по вашему ожиданию, должны читать потребители.

Также проверьте, не дублируются ли структурированные данные. Дублирующиеся блоки Article или Product часто появляются, когда CMS-плагин и кастомный компонент одновременно выводят schema. Дублирование не всегда фатально, но конфликтующее дублирование — проблема: две цены, два автора, две даты публикации или два canonical URL.

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

Шаг 6: Проверьте production-детали передачи

Структурированные данные могут быть идеальными в исходнике и всё равно не работать в production, потому что страница недоступна так, как вы предполагаете.

Проверьте:

• итоговый статус-код — 200, а не soft 404
• canonical URL соответствует странице, которую вы валидируете
• редиректы намеренные и стабильные
• директивы robots не блокируют индексацию там, где она ожидается
• HTML не заменяется страницей ошибки для некоторых user agents
• кешированные страницы не отдают устаревший JSON-LD

Именно здесь важна проверка HTTP. Если страница товара проходит через три URL, прежде чем попасть на canonical-адрес, валидируйте итоговую страницу, а не первый URL, скопированный из CMS. Для базовой механики полезным дополнением будет наш материал о debugging redirects and HTTP headers in production.

Структурированные данные не живут в вакууме. Они путешествуют вместе с headers, redirects, caching, canonical tags и robots directives.

Шаг 7: Добавьте тесты структурированных данных в процесс релиза

Ручная валидация подходит для одной страницы. Она не масштабируется на сотни или тысячи URL.

Простой набор автоматических тестов может поймать самые дорогие ошибки:

• получать репрезентативные URL для каждого типа шаблона
• извлекать все блоки JSON-LD
• разбирать их через JSON.parse
• проверять обязательные поля для каждого типа страницы
• проверять, что даты являются валидными строками ISO 8601
• проверять, что URL абсолютные и canonical
• проверять наличие цены и доступности для товарных страниц
• проверять, что дублирующиеся сущности не конфликтуют

Это можно запускать в CI для шаблонов и по расписанию для production URL. Цель не в том, чтобы доказать, что каждая функция расширенных результатов появится. Никто за пределами поисковой системы не может этого обещать. Цель — поддерживать собственные данные точными, разбираемыми и согласованными.

<!-- tool-cta:start -->

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

<!-- tool-cta:end -->

Чек-лист валидации от стандартов

Используйте этот короткий чек-лист, прежде чем спрашивать, нравится ли страница поисковой системе:

• Является ли каждый блок JSON-LD валидным JSON?
• Включает ли каждый блок корректные @context и @type?
• Правильно ли написаны свойства Schema.org?
• Соответствует ли разметка видимому контенту?
• Актуальны ли даты, цены, рейтинги и наличие?
• Являются ли URL абсолютными, canonical и доступными?
• Та ли отрендеренная production-страница была протестирована?
• Являются ли дублирующиеся сущности намеренными и неконфликтующими?

Если на эти вопросы можно ответить «да», вы сделали устойчивую часть работы со структурированными данными. Поисково-специфическое тестирование всё ещё может быть полезным позже, но оно должно быть финальной проверкой совместимости, а не фундаментом процесса валидации.