Генератор разметки JSON-LD Schema.org

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

Schema.org, JSON-LD и расширенный результат — разные вещи

Schema.org

Это общий словарь типов и свойств: Article, Product, Organization, Event, name, image, offers и многие другие. Он описывает, какие сущности и связи можно представить в структурированном виде.

JSON-LD

Это один из форматов записи структурированных данных. Код размещается внутри:

<script type="application/ld+json">
    {
    "@context": "https://schema.org",
    "@type": "Article",
    "headline": "Название статьи"
    }
    </script>

Google рекомендует JSON-LD, когда он подходит для реализации, но Schema.org также может быть записана с помощью Microdata или RDFa.

Расширенный результат Google

Это особое представление результата в поиске, которое поддерживает только ограниченный набор типов и требует соблюдения отдельных правил Google. Валидная Schema.org-разметка не гарантирует расширенный результат, высокий рейтинг или даже использование всех переданных свойств. Поэтому нельзя оценивать разметку только вопросом «покажет ли она красивый сниппет». Она должна прежде всего корректно описывать реальную сущность страницы.

Как выбрать тип разметки

Выбирайте тип по основному объекту страницы, а не по желаемому виду в поиске.

Тип	Когда применять	Что особенно проверить
Article	статья, новость, обзор, публикация	заголовок, автор или издатель, даты, изображение, связь с текущей страницей
BreadcrumbList	видимая или логическая цепочка навигации	правильный порядок позиций и URL каждого шага
Event	конкретное мероприятие с датой и форматом проведения	дата и часовой пояс, место или онлайн-URL, статус и актуальность
FAQPage	страница с одним официальным ответом сайта на каждый вопрос	все вопросы и ответы видны пользователю; не разметка форума или пользовательских ответов
HowTo	реальная пошаговая инструкция	шаги соответствуют видимому материалу; не рассчитывать на Google HowTo rich result
JobPosting	отдельная доступная вакансия	работодатель, место или удалённый формат, дата публикации, срок действия, описание
LocalBusiness	конкретная физическая точка или локальная организация	наиболее точный подтип, адрес, телефон, часы работы и URL именно этой точки
Organization	компания, учреждение, бренд или объединение	официальное название, URL, логотип, контакты и устойчивый @id
Person	профиль конкретного человека	имя, роль, принадлежность к организации, официальные профили; не выдавать предположения за факты
Product	конкретный товар или вариант товара	товар существует на странице; цена, валюта, наличие, предложение и отзывы актуальны
Recipe	кулинарный рецепт	ингредиенты, шаги, время, порции и изображение доступны пользователю
VideoObject	отдельное видео на странице	название, описание, превью, дата загрузки и доступный URL видео или плеера
WebSite	сайт как единый объект	основной канонический URL, название и связь с организацией; тип обычно не нужен на каждой странице как независимая сущность

На одной странице допустимо несколько связанных объектов. Например, статья может иметь автора Person, издателя Organization, хлебные крошки BreadcrumbList и встроенное видео VideoObject. Их лучше связывать через @id, а не создавать противоречащие друг другу копии.

Важные актуальные ограничения Google

FAQPage

Google существенно ограничил показ FAQ rich results: они обычно доступны только известным авторитетным государственным и медицинским сайтам. Для обычного коммерческого или информационного сайта корректная FAQ-разметка может не дать заметного расширения в выдаче. Это не делает тип FAQPage недействительным в Schema.org, но обещать пользователю «вопросы появятся в Google» нельзя.

HowTo

Google прекратил показ расширенных результатов HowTo. Тип HowTo остаётся в словаре Schema.org и может использоваться другими потребителями, но добавлять его исключительно ради прежнего rich result Google больше не имеет смысла.

Другие типы

Organization, Person и WebSite помогают описывать сущности, но не каждый из них создаёт отдельный визуальный rich result. Поддержка и внешний вид поисковых функций меняются, поэтому перед внедрением проверяйте текущую галерею Google Search Central.

Главное правило: разметка должна совпадать с видимым содержимым

Не добавляйте в JSON-LD сведения, которые отсутствуют на странице или противоречат ей. Особенно это касается:

• цены и наличия товара;
• рейтинга и количества отзывов;
• вопросов и ответов;
• даты и места события;
• автора материала;
• адреса и графика компании;
• условий вакансии;
• ингредиентов и шагов рецепта.

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

Обязательные поля зависят от того, кто читает разметку

Schema.org определяет словарь, но не единый универсальный список «обязательных полей» для всех систем. Конкретный потребитель — например, Google Search — устанавливает собственные обязательные и рекомендуемые свойства для определённой поисковой функции. Поэтому возможны три разных результата проверки:

1. JSON синтаксически корректен.
2. Типы и свойства существуют в Schema.org.
3. Разметка соответствует требованиям конкретного расширенного результата Google.

Успешный первый или второй этап не гарантирует третий.

Как заполнять URL, даты и идентификаторы

Используйте абсолютные URL

Предпочтительно:

https://example.com/catalog/product-1

Вместо:

/catalog/product-1

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

Указывайте даты в ISO 8601

Дата:

2026-08-04

Дата и время с часовым поясом:

2026-08-04T18:30:00+03:00

Для событий особенно важно не терять часовой пояс. Иначе время может быть интерпретировано неверно.

Создавайте устойчивый @id

@id — идентификатор сущности, часто в виде URL с фрагментом:

https://example.com/#organization
    https://example.com/article/#webpage
    https://example.com/article/#author

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

Как описывать несколько сущностей через @graph

Для связанных объектов удобно использовать один блок:

{
    "@context": "https://schema.org",
    "@graph": [
        {
        "@type": "Organization",
        "@id": "https://example.com/#organization",
        "name": "Example Company",
        "url": "https://example.com/"
        },
        {
        "@type": "Article",
        "@id": "https://example.com/blog/article/#article",
        "headline": "Название статьи",
        "publisher": {
            "@id": "https://example.com/#organization"
        }
        }
    ]
    }

Так объекты явно связаны и не требуется повторять все сведения об организации внутри каждой статьи.

Куда вставлять JSON-LD

Блок <script type="application/ld+json"> можно размещать в <head> или <body> HTML-страницы. Важнее, чтобы:

• код присутствовал в итоговом HTML или был доступен после корректного рендеринга;
• он относился именно к текущей странице;
• CMS экранировала его без повреждения кавычек и символов;
• один шаблон не подставлял одинаковые данные на разные страницы;
• динамические цена, наличие и даты обновлялись вместе с видимым содержимым.

После внедрения проверяйте не только код из генератора, но и опубликованный URL: шаблон, плагин или JavaScript могут изменить итоговую разметку.

Два разных уровня валидации

Schema Markup Validator

Проверяет синтаксис и использование словаря Schema.org. Подходит, чтобы увидеть найденные типы, свойства и общие проблемы разметки.

Google Rich Results Test

Показывает, распознаёт ли Google на странице поддерживаемый тип расширенного результата и выполнены ли его специальные требования. Инструмент не подтверждает, что расширение обязательно появится в поиске. После публикации URL также полезно проверить через URL Inspection в Google Search Console, чтобы увидеть обработанную Google версию страницы и обнаруженные элементы.

Ошибка и предупреждение — не универсальные категории

Валидатор может считать отсутствие свойства предупреждением, тогда как для конкретного потребителя оно окажется обязательным. И наоборот, Schema.org допускает свойство, которое Google не использует для нужной функции. Оценивайте сообщение по четырём вопросам:

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

Частые ошибки

• Неподходящий тип: страница категории товаров размечена как один Product, хотя на ней нет отдельного товара и единого предложения. Или обычная статья получает FAQPage только потому, что внизу есть небольшой блок вопросов.
• Разметка не соответствует странице: в коде указаны старая цена, несуществующий рейтинг, скрытые вопросы или другой автор.
• Конфликтующие сущности: несколько плагинов создают разные блоки Organization с отличающимися названиями, логотипами и URL. Объекты не связаны через общий @id.
• Неправильное вложение: например, price записана непосредственно в Product, хотя предложение обычно описывается через объект Offer в свойстве offers.
• Неверный тип значения: дата записана произвольным текстом, цена содержит валюту в той же строке, логическое значение передано как фраза, а поле, ожидающее URL, содержит относительный путь.
• Недоступные изображения и страницы: URL возвращает ошибку, закрыт авторизацией или robots.txt, ведёт через нестабильную временную ссылку либо указывает на изображение, которое поисковик не может получить.
• Устаревшие динамические данные: событие уже закончилось, вакансия закрыта, товар отсутствует, а разметка продолжает передавать старый статус.
• Ошибки JSON: одинарные или типографские кавычки; лишняя запятая после последнего свойства; незакрытая скобка; комментарии внутри JSON; необработанный перенос строки внутри строкового значения; повторяющийся ключ в одном объекте.

Рабочий процесс внедрения

1. Определите главный объект и цель разметки.
2. Проверьте актуальные требования Schema.org и нужного потребителя данных.
3. Выберите наиболее точный тип.
4. Заполните только достоверные свойства, присутствующие на странице.
5. Сгенерируйте JSON-LD.
6. Проверьте код в Schema Markup Validator.
7. Если нужен поддерживаемый Google rich result, проверьте Rich Results Test.
8. Вставьте код в тестовую версию страницы.
9. Повторно проверьте опубликованный URL, а не только отдельный фрагмент.
10. Настройте обновление динамических значений и повторные проверки после изменений шаблона.

Короткий чек-лист перед публикацией

• выбран тип реального объекта страницы;
• данные совпадают с видимым содержимым;
• отсутствуют вымышленные рейтинги, отзывы и свойства;
• URL абсолютные, доступные и канонически согласованные;
• даты указаны в понятном формате и с часовым поясом, когда он нужен;
• цена и валюта находятся в отдельных полях;
• одинаковые сущности связаны через устойчивый @id;
• нет конфликтующей разметки от другого модуля;
• код прошёл подходящие проверки;
• опубликованный URL содержит тот же корректный JSON-LD;
• динамические данные будут обновляться.

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

Гарантирует ли Schema.org расширенный сниппет?

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

Нужно ли добавлять Schema.org на каждую страницу?

Только там, где есть сущность и полезные достоверные свойства для её описания. Массовая вставка одинакового блока без привязки к содержимому создаёт ошибки и противоречия.

Можно ли оставить свойства, которых пользователь не видит?

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

Где размещать код — в head или body?

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

Почему Schema Markup Validator не показывает ошибку, а Google показывает?

Первый инструмент проверяет словарь Schema.org и структуру разметки, а Google дополнительно применяет требования конкретной поисковой функции.

Стоит ли сейчас размечать FAQPage?

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

Нужен ли HowTo ради Google?

Google больше не показывает HowTo rich results. Тип может оставаться полезным как семантическое описание для других систем, но прежнего поискового эффекта Google ожидать не следует.

Связанные инструменты

Diffchecker; Обработчик текстов; Base64.

Официальные материалы

• Schema.org vocabulary
• Google Search Central — Introduction to structured data
• Google — General structured data guidelines
• Google — Structured data feature gallery
• Schema Markup Validator
• Google Rich Results Test

---

Общие редакционные рекомендации для раздела

1. Не дублировать один и тот же коммерческий блок внутри каждого полезного текста

Текущий блок про «полноценный SEO-аудит, инструменты для роста видимости в ИИ и автоматизацию» можно оставить как отдельный визуальный CTA после основного материала. Не следует встраивать его в структуру статьи между полезными разделами: это разрывает сценарий чтения и выглядит одинаково на всех девяти страницах. Лучше использовать короткий связанный переход, соответствующий инструменту. Например:

• после UTM-генератора — к отчётам по каналам и конверсиям;
• после комбинатора — к проверке частотности, кластеризации и назначению запросов страницам;
• после Schema — к аудиту структурированных данных;
• после Diffchecker — к мониторингу изменений страниц;
• после удаления дублей — к импорту семантики или URL в проект.

2. Не делать одинаковые разделы «Преимущества» и «Кому подходит» ради шаблона

Их содержание почти всегда превращается в повторы: «быстро», «удобно», «бесплатно», «для маркетологов и специалистов». Полезнее оставить конкретные сценарии, ограничения, примеры и FAQ. Короткие признаки «бесплатно», «в браузере», «без регистрации» уже показаны рядом с инструментом.

3. Согласовать обещания с реальной реализацией

Перед публикацией разработчикам стоит подтвердить:

• выполняется ли обработка полностью в браузере или данные отправляются на сервер;
• какие лимиты по объёму текста и числу строк существуют;
• сохраняются ли исходные данные или результаты;
• какой алгоритм и библиотека используются для определения языка;
• как именно Diffchecker сопоставляет слова и строки;
• чувствительно ли удаление дублей к регистру и пробелам и в каком порядке применяются действия;
• использует ли генератор паролей криптографически стойкий источник случайности;
• какая кодировка применяется Base64-конвертером;
• поддерживает ли он Base64url или только стандартную Base64.

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

4. Показывать ограничения рядом с функцией, а не прятать их внизу

Особенно важные предупреждения:

• UTM-метки не размещают на внутренних ссылках;
• Diffchecker не проверяет смысл и фактическую правильность;
• комбинатор не подтверждает спрос и не создаёт структуру сайта автоматически;
• Base64 не шифрует данные;
• весь URL нельзя без проверки приводить к нижнему регистру;
• пароль нельзя считать криптографически стойким без проверки генератора;
• валидная Schema.org не гарантирует rich result.

5. Добавить внутренние ссылки по следующему действию пользователя

Вместо общего списка всех утилит разместить по две-три действительно связанные ссылки в конце страницы. Название ссылки должно объяснять продолжение сценария: «Очистить полученный список», «Сравнить две версии», «Удалить повторяющиеся комбинации», «Проверить язык текста».

6. Не размечать FAQ только ради обещания расширенного сниппета

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

7. Рекомендуемый порядок внедрения

1. Diffchecker, определение языка и UTM — сейчас у них меньше всего полезного материала.
2. Удаление дубликатов — срочно исправить совет о переводе всех URL в нижний регистр.
3. Base64 — заменить слово «расшифровать» на «декодировать» и добавить Base64url.
4. Генератор паролей — обновить рекомендации по длине и проверить реализацию случайной генерации.
5. Schema.org — заменить текущий чрезмерно длинный повторяющийся текст на более компактное, но технически точное руководство.
6. Комбинатор и обработчик текстов — оставить сильные части, добавить ограничения и практический порядок действий.