Практическое руководство по структурированным данным

Руководство по JSON-LD для практического SEO

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

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

Полезная короткая версия

Используйте JSON-LD, когда можете описать страницу честными, видимыми фактами: заголовок, описание, автор, дата публикации, хлебные крошки, данные о продукте, видео или чёткий Q&A. Не добавляйте схему для обещания функций, которые Google больше не показывает, или для разметки невидимого пользователям контента.

Лучший базовый schema Article, WebPage и BreadcrumbList для большинства страниц руководств.
Оптимальный процесс Генерируйте схему из тех же метаданных страницы, что создают заголовок, описание, канонический URL и Open Graph.
Лучшая проверка на практике Разметка FAQPage и WebSite может описывать контент, но не стройте стратегию на устаревших отображениях Google.

Что на самом деле делает JSON-LD

JSON-LD — это машинно-читаемый блок структурированных данных. Обычно он находится в теге script в head или body и описывает сущности с помощью словаря schema.org. Поисковики используют его как слой ясности поверх видимого контента.

Ясность парсера

Значение

Это превращает факты страницы в именованные сущности и свойства, такие как Article, author, datePublished, BreadcrumbList или SoftwareApplication.

Поисковая функция

Право на показ

Это может сделать страницу подходящей для расширенных результатов, но Google решает, что показывать, исходя из качества, политики, запроса и доступности функций.

Граф сайта

Согласованность

Это даёт вашему CMS или приложению Blazor единое структурированное место для повторного использования канонического URL, языка, заголовка, дат, изображений и данных издателя.

Не является коротким путём

Ограничение

Это не исправляет слабый контент, фальшивые отзывы, скрытые ответы FAQ, устаревшие даты или несоответствие страницы разметке.

Важно: Структурированные данные должны поддерживать страницу, а не заменять полезный контент. Если видимый контент слабый, запутанный, устаревший или вводящий в заблуждение, разметка не сделает результат сильнее.

Выбирайте схему по назначению страницы

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

Содержание

Article / BlogPosting

Используйте для
Руководства, уроки, обзоры, новостные посты и подробные объяснения.
Добавлять когда
Страница имеет чёткий заголовок, автора или издателя, дату публикации, дату изменения, канонический URL и изображение.
Избегать когда
Страница в основном представляет собой интерфейс инструмента, список продуктов, страницу категории или лёгкую посадочную страницу.

Навигация

BreadcrumbList

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

Идентичность сайта

WebPage / WebSite / Organization

Используйте для
Главная, хабы, страницы о сайте и страницы, где важна идентичность издателя.
Добавлять когда
Вам нужен стабильный граф сущностей, связывающий страницу, сайт, издателя и язык.
Избегать когда
Вы добавляете разметку WebSite только ради старого отображения поисковой строки sitelinks.

Продукт или приложение

Product / SoftwareApplication

Используйте для
Инструменты, приложения, SaaS-страницы, расширения, скачиваемое ПО или реальные страницы продуктов.
Добавлять когда
Видимый контент страницы включает название, описание, ОС или категорию, цену, предложения и рейтинги при их разметке.
Избегать когда
Рейтинги, цена, наличие или отзывы не видны пользователям на странице.

Вопросы

FAQPage

Используйте для
Видимые разделы вопросов и ответов, которые действительно помогают пользователям понять тему.
Добавлять когда
Содержимое вопросов и ответов полезно на странице, даже если Google не показывает расширенные результаты FAQ.
Избегать когда
Вы добавляете общие вопросы и ответы только чтобы занять место в поиске или повторить один и тот же ответ на многих страницах.

Медиа

VideoObject / ImageObject

Используйте для
Страницы с важным встроенным видео, обучающим роликом или доступным для краулеров изображением.
Добавлять когда
Медиа является центральным элементом страницы и имеет заголовок, описание, миниатюру, дату загрузки и стабильный URL.
Избегать когда
Медиа декоративное, скрытое, заблокированное или не относится к основной цели страницы.

Чеклист реализации, предотвращающий большинство ошибок

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

01

Выберите одну основную сущность страницы

Определите, является ли страница статьёй, продуктом, приложением, видео, FAQ, коллекцией или общей веб-страницей. Вторичная схема должна поддерживать основной объект.

02

Соответствие видимому контенту

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

03

Используйте стабильные значения @id

Давайте важным сущностям стабильные ID, например канонический URL с добавлением #article, #webpage, #organization или #faq. Это помогает парсерам связывать части графа.

04

Генерировать из общих метаданных

Используйте те же исходные поля, что создают заголовки, метаописания, канонические URL, изображения Open Graph, языковые теги и даты последнего изменения.

05

Сохраняйте даты честными

Меняйте dateModified только при значимых изменениях контента. Не обновляйте даты автоматически ради свежести в поиске.

06

Сделайте изображения доступными для краулеров

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

07

Рендерить заранее

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

08

Проверяйте и контролируйте

Запустите тест расширенных результатов перед публикацией, проверьте синтаксис в валидаторе разметки и следите за Search Console после индексации.

Чистый шаблон JSON-LD для страниц Blazor

Для Blazor самый надёжный способ — формировать схему из метаданных страницы при инициализации или пререндеринге, сериализовать один раз и выводить скрипт application/ld+json в начальном HTML, доступном краулерам.

HTMLПример JSON-LD для статьи
<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "@id": "https://example.com/en/json-ld-schema-guide/#article",
  "headline": "JSON-LD Schema Markup Guide for Practical SEO",
  "description": "A practical guide to choosing, generating, and validating structured data.",
  "image": "https://example.com/images/json-ld-guide.png",
  "datePublished": "2026-03-28T10:00:00+00:00",
  "dateModified": "2026-05-31T10:00:00+00:00",
  "author": {
    "@type": "Organization",
    "name": "Example Publisher"
  },
  "publisher": {
    "@type": "Organization",
    "name": "Example Publisher",
    "logo": {
      "@type": "ImageObject",
      "url": "https://example.com/logo.png"
    }
  },
  "mainEntityOfPage": {
    "@type": "WebPage",
    "@id": "https://example.com/en/json-ld-schema-guide/"
  }
}
</script>
C#Шаблон помощника на C#
private MarkupString BuildJsonLd(PageMetaData meta)
{
    var pageUrl = BuildPageUrl(meta);

    var schema = new Dictionary<string, object?>
    {
        ["@context"] = "https://schema.org",
        ["@type"] = "Article",
        ["@id"] = $"{pageUrl}#article",
        ["headline"] = meta.Title,
        ["description"] = meta.Description,
        ["url"] = pageUrl,
        ["datePublished"] = meta.Published?.ToString("O"),
        ["dateModified"] = meta.Modified?.ToString("O"),
        ["inLanguage"] = CS.Culture
    };

    var json = JsonSerializer.Serialize(schema, new JsonSerializerOptions
    {
        DefaultIgnoreCondition = JsonIgnoreCondition.WhenWritingNull
    });

    return new MarkupString($"<script type=\"application/ld+json\">{json}</script>");
}
Практическое правило: Используйте стабильные URL для url и @id. Везде применяйте один и тот же канонический URL. Если страница доступна по разным языковым URL, генерируйте метаданные для каждого языка и поддерживайте согласованность hreflang и канонических настроек.

Проверяйте JSON-LD перед использованием

Валидация выполняет две задачи. Валидатор разметки проверяет понятность словаря и синтаксиса JSON-LD. Тест расширенных результатов Google проверяет, распознаёт ли Google страницу как подходящую для поддерживаемых расширенных результатов.

Право на показ в Google

Тест расширенных результатов

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

Открыть тест расширенных результатов

Словарь

Валидатор разметки схемы

Проверяет общую структуру schema.org и синтаксис JSON-LD, включая типы, свойства, вложенные сущности и ошибки JSON.

Открыть валидатор разметки

Распространённые ошибки JSON-LD, снижающие доверие

Большинство проблем со схемой — не сложные технические ошибки, а несоответствия между разметкой и тем, что пользователь или краулер видит на странице.

Разметка скрытого или отсутствующего контента

Если пользователи не видят ответ, отзыв, предложение, изображение или автора, не добавляйте это в структурированные данные. Это быстро подрывает доверие.

Добавление FAQPage везде

Схема FAQ может описывать видимые вопросы и ответы, но не должна быть копипастой на всех статьях. Используйте только если Q&A улучшает страницу.

Конфликтующие дублирующие скрипты

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

Неверный канонический URL или @id

URL в схеме должны совпадать с канонической страницей, языковым URL и настройками hreflang. Смешанные языки создают дубли и путаницу.

Ложная свежесть

Не меняйте dateModified при правках шаблона, отслеживании изменений или обновлениях только схемы. Используйте дату для реальных изменений контента.

Поздний рендеринг на клиенте

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

Практические схемы по типам страниц

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

Статья-руководство

Article + BreadcrumbList + WebPage

  • Используйте Article для заголовка, автора, издателя, изображения, дат и названий разделов.
  • Используйте BreadcrumbList для видимого пути сайта.
  • Используйте ссылки WebPage или @id для связи страницы и сущности статьи.

Страница инструмента

SoftwareApplication + WebPage + BreadcrumbList

  • Используйте SoftwareApplication только если страница о реальном приложении или инструменте.
  • Включайте данные об ОС, категории, цене или предложении только если они видимы.
  • Избегайте разметки отзывов или рейтингов, если на странице нет реальных данных.

Страница обзора

Обзор / продукт только если страница это поддерживает

  • Размечайте объект обзора, автора, дату и рейтинг только если они явно видны на странице.
  • Держите партнерские ссылки и коммерческий контекст прозрачными.
  • Используйте одинаковый рейтинг в схеме и видимом контенте.

Страница с вопросами

FAQPage только для полезных видимых вопросов и ответов

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

Проверенные источники

Руководство основано на официальных документах Google Search Central и schema.org и преобразовано в практический чеклист JSON-LD.

01 Введение в структурированные данные Google developers.google.com 02 Политики структурированных данных Google developers.google.com 03 Структурированные данные Google Article developers.google.com 04 Структурированные данные Google Breadcrumb developers.google.com 05 Структурированные данные Google FAQ developers.google.com 06 Обновление поисковой строки Google sitelinks developers.google.com 07 Начало работы с Schema.org schema.org 08 Тест расширенных результатов Google search.google.com 09 Валидатор разметки схемы validator.schema.org

Частые вопросы

Является ли разметка JSON-LD фактором ранжирования?

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

Где должен располагаться JSON-LD на странице?

Тег script в head обычно проще всего управлять, но Google также может читать JSON-LD в теле страницы. Главное, чтобы разметка была в итоговом HTML и соответствовала видимому контенту.

Стоит ли ещё использовать схему FAQPage?

Используйте FAQPage только если на странице есть действительно полезные видимые вопросы и ответы. Не рассчитывайте на дополнительное место в результатах Google, так как отображение FAQ сильно сокращено и устарело для большинства сайтов.

Можно ли на странице использовать несколько блоков JSON-LD?

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

JSON-LD лучше Microdata?

Для большинства современных сайтов — да. Google поддерживает JSON-LD, Microdata и RDFa, но JSON-LD проще поддерживать, так как не требует атрибутов схемы в HTML.

Как часто проверять структурированные данные?

Проверяйте при изменении шаблонов, метаданных, помощников схемы, URL, языковой маршрутизации, генерации изображений, данных обзоров или FAQ. Также проверяйте Search Console после индексации важных страниц.