Настройте

Выберите тип schema.org и заполните поля. Обязательные поля отмечены звёздочкой (*).

Тип schema

Статья

Заголовок*

0/110

Заголовок необходим для валидного Article schema.

Описание

URL изображения

Дата публикации*

Обязательное поле.

Дата изменения

Автор

Имя автора*

Имя автора необходимо.

URL автора

Издатель

Имя издателя

URL логотипа издателя

Страница

Основная сущность страницы (URL)

Результат

Скопируйте в тег script[type=application/ld+json] в head вашей страницы.

schema.jsonld

{
  "@context": "https://schema.org",
  "@type": "Article"
}

Тестировать в Google Rich Results

Ваш robots.txt готов — но это только один из 99+ SEO-сигналов.

Запустить бесплатный аудит →

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

Структурированные данные — это слой метаданных, добавляемых к веб-странице и описывающих её содержимое в машиночитаемом формате. Тело страницы — это то, что видят люди; структурированные данные — это то, что читают поисковые системы, голосовые помощники и агрегаторы контента, чтобы понять, о чём страница. Публикация в блоге становится чётко идентифицированным Article с автором, датой публикации и заголовком. Страница товара становится Product с ценой, наличием и отзывами. Местоположение бизнеса становится LocalBusiness с адресом, часами работы и телефонным номером. Словарь, определяющий все эти типы — Schema.org, совместный проект, запущенный в 2011 году компаниями Google, Microsoft, Yahoo и Яндекс.

Важность структурированных данных обусловлена rich results. Когда страница содержит корректные структурированные данные и Google решает, что запрос и качество контента это оправдывают, SERP показывает расширенные элементы рядом или вместо обычного сниппета. Звёздные рейтинги появляются под результатами товаров. FAQ-аккордеоны появляются под статьями. Хлебные крошки заменяют строку URL. Карточки рецептов показывают время приготовления и калорийность. Списки событий показывают дату и место. Каждое из этих улучшений занимает больше вертикального пространства, визуально выделяет результат и существенно повышает кликабельность. Результат на третьей позиции с расширенным сниппетом стабильно превосходит результат на первой позиции с обычной синей ссылкой.

Помимо SERP, структурированные данные питают более широкую семантическую сеть. Голосовые помощники вроде Google Assistant и Alexa читают схему для ответов на вопросы. Google Knowledge Graph использует схему для построения профилей сущностей. Агрегаторы вроде Google Shopping, Google Travel и Google Jobs полагаются на структурированные данные для наполнения своих вертикалей. Без схемы ваш контент — это текст, который нужно интерпретировать; со схемой — это данные, которые можно цитировать напрямую.

Иерархия обработки Google важна, когда у вас есть выбор форматов. Команда заявляла с 2015 года, что JSON-LD является предпочтительным форматом, а подтверждение 2020 года чётко показало, что JSON-LD парсится быстрее и надёжнее, чем встроенные альтернативы. Порядок предпочтения: JSON-LD первый, Microdata второй, RDFa третий. Смешивание форматов на одной странице даёт непоследовательные результаты — Google может выбрать один, может объединить их или может пометить конфликт — поэтому придерживайтесь JSON-LD и избегайте смешивания. JSON-LD также имеет практическое преимущество: он размещается в теге <script type="application/ld+json"> в head, отдельно от отрендеренного HTML, что облегчает его поддержку и версионирование.

Как использовать этот генератор

Форма сгруппирована по типам схемы, и вы заполняете только те поля, которые применимы к вашей странице.

Шаг 1 — Выберите тип схемы. Выберите Article, Product, Organization, LocalBusiness, FAQPage или BreadcrumbList в зависимости от того, что реально представляет страница. Генератор выводит разметку только для типов, соответствующих реальному содержимому страницы; он не позволяет создавать фиктивные FAQ-записи или отзывы о товарах для манипуляции rich results.

Шаг 2 — Заполните обязательные поля. Каждый тип схемы имеет набор обязательных полей, определённых документацией Google по структурированным данным. Генератор выделяет обязательные поля красным и сигнализирует о пропущенных значениях перед генерацией вывода. Опциональные поля видны, но сворачиваемы для краткости формы.

Шаг 3 — Скопируйте JSON-LD и вставьте в <head>. Вывод представляет собой единственный блок <script type="application/ld+json">. Вставьте его в head той страницы, которую описывает схема. Немедленно после этого проверьте в Rich Results Test — если инструмент Google сообщает об ошибках, ни один rich result никогда не отобразится в продакшене.

Типы схем и когда использовать каждый

Словарь Schema.org содержит сотни типов, но небольшой набор охватывает большинство реальных страниц.

Article, NewsArticle, BlogPosting

{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "How to write a meta description",
  "datePublished": "2026-04-27T10:00:00+00:00",
  "dateModified": "2026-04-27T12:00:00+00:00",
  "author": { "@type": "Person", "name": "Jane Smith" },
  "publisher": {
    "@type": "Organization",
    "name": "Example",
    "logo": { "@type": "ImageObject", "url": "https://example.com/logo.png" }
  },
  "mainEntityOfPage": "https://example.com/blog/meta-description"
}

Article — универсальный родительский тип. NewsArticle — для журналистского, редакционного контента: новостных репортажей, расследований, всего, что имеет дату публикации и редакционный процесс. BlogPosting — для контента в формате блога: мнений, how-to материалов, личных постов. Используйте наиболее конкретный подтип, который действительно подходит. Google вознаграждает специфичность в схеме, показывая правильные rich results: NewsArticle подходит для карусели Top Stories, а просто Article — нет. Обязательные поля: headline, datePublished, author и image для eligibility на rich results.

Product

Схема Product даёт вам звёздные рейтинги, отображение цен и бейджи наличия в поиске. Обязательные поля: name, image и либо offers (с ценой и валютой), либо review и aggregateRating. Совокупный рейтинг — это поле, которое производит золотые звёзды под результатом, но Google ужесточил правила с 2019 года: рейтинг должен быть получен из реальных отзывов первой стороны непосредственно на странице, а не взят из сторонних источников. Подделка рейтингов или использование сторонних рейтингов как собственных — это прямой путь к ручным санкциям.

Organization

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://example.com/#organization",
  "name": "Example Inc.",
  "url": "https://example.com",
  "logo": "https://example.com/logo.png",
  "sameAs": [
    "https://twitter.com/example",
    "https://linkedin.com/company/example",
    "https://en.wikipedia.org/wiki/Example_Inc"
  ]
}

Схема Organization размещается на главной странице и странице «О нас». Она сообщает поисковым системам, кто публикует сайт, что вносит вклад в профиль сущности Knowledge Graph, появляющийся в правой колонке при брендовых поисках. Поле sameAs — самое важное и наиболее часто пропускаемое — в нём перечислены внешние авторитетные профили, подтверждающие идентичность организации. Без sameAs Google вынужден выводить сущность из контекста; с sameAs связь явная.

LocalBusiness

LocalBusiness расширяет Organization полями, специфичными для местоположения: address, geo (широта и долгота), openingHoursSpecification, telephone и priceRange. Это обязательное условие для Knowledge Panel, появляющейся в локальном поиске и Google Maps. Используйте наиболее конкретный подтип: Restaurant, Dentist, AutoRepair, LegalService и так далее, у каждого из которых есть собственные подтипы. Полный список находится в разделе LocalBusiness на Schema.org. Использование неверного подтипа — Restaurant для кофейни, Store для сервисного бизнеса — запутывает локальный поиск и снижает видимость по нужным запросам.

FAQPage

Схема FAQPage размечает вопросы и ответы в формате Q&A. Формат прост — массив mainEntity из объектов Question, каждый с acceptedAnswer — но eligibility на rich results резко сузилась с 2023 года. Google теперь ограничивает FAQ rich results авторитетными государственными и медицинскими сайтами, и большинство маркетинговых страниц больше не видят аккордеон в поиске даже при корректной разметке. Схему всё равно стоит включать, потому что она помогает Google понять структуру страницы, но не рассчитывайте на rich results за пределами подходящих вертикалей.

BreadcrumbList

{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    {
      "@type": "ListItem",
      "position": 1,
      "name": "Home",
      "item": "https://example.com"
    },
    {
      "@type": "ListItem",
      "position": 2,
      "name": "Blog",
      "item": "https://example.com/blog"
    },
    {
      "@type": "ListItem",
      "position": 3,
      "name": "Current Article"
    }
  ]
}

BreadcrumbList заменяет строку URL в SERP кликабельной цепочкой хлебных крошек — это один из наиболее надёжно отображаемых rich results в Google. Текущая страница (последний элемент) не требует URL в поле item — его отсутствие сообщает Google, что это конечная позиция. Всегда включайте BreadcrumbList на каждой странице глубже главной; это ничего не стоит и стабильно повышает CTR.

Связывание сущностей с помощью @id и sameAs

Большинство реальных страниц содержат несколько сущностей — Article с автором, издателем и цепочкой хлебных крошек. Без координации вы в итоге объявляете одну и ту же Organization трижды в трёх разных блоках схемы, и поисковые системы не могут знать, что это одна и та же сущность. Паттерн @id решает эту проблему.

Присвойте каждой сущности стабильный уникальный @id, выглядящий как URL — как правило, это канонический URL страницы с фрагментом-идентификатором вроде #organization, #article или #author. Как только сущность объявлена с @id, каждая последующая ссылка может быть объектом { "@id": "..." } вместо полного дубликата.

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://example.com/#organization",
      "name": "Example",
      "url": "https://example.com",
      "logo": "https://example.com/logo.png"
    },
    {
      "@type": "BlogPosting",
      "@id": "https://example.com/article#article",
      "headline": "Title",
      "publisher": { "@id": "https://example.com/#organization" }
    }
  ]
}

Обёртка @graph позволяет объявить несколько сущностей верхнего уровня в одном блоке JSON-LD, где связи устанавливаются через @id. Это современная лучшая практика для любой страницы с более чем одной сущностью, и именно так SEO-плагины вроде Yoast и Rank Math структурируют свой вывод.

sameAs — свойство-партнёр к @id. Там, где @id связывает сущности внутри сайта, sameAs связывает сущности с их каноническими представлениями в других местах — страницей в Wikipedia, записью в Wikidata, официальными профилями в Twitter и LinkedIn. Поисковые системы используют sameAs для согласования сущностей, подтверждая, что ваша Organization — это та, которую пользователи имеют в виду при поиске бренда. Всегда включайте sameAs в схему Organization, Person и сущностей с высокой ценностью.

Распространённые ошибки, вредящие SEO

Схема для контента, которого нет на странице. Схема FAQ для вопросов, которые реально не отрендерены, схема Product с несуществующими отзывами, схема Recipe на странице, не содержащей рецепта — всё это нарушает рекомендации Google по структурированным данным и может повлечь ручные санкции. Схема должна описывать контент, который видимо присутствует на странице.

Неверный тип схемы. Использование Article для страницы товара, Organization для личного блога, LocalBusiness для онлайн-сервиса. Неверный тип запутывает поисковые системы и препятствует отображению правильных rich results. Выбирайте наиболее конкретный тип, который действительно подходит, и при сомнении проверяйте дерево типов Schema.org.

Смешивание JSON-LD с Microdata или RDFa. Когда одна страница объявляет одну и ту же сущность в двух форматах, поведение Google не определено — он может объединить, может выбрать один, может пометить конфликт в Search Console. Придерживайтесь JSON-LD и удаляйте встроенные структурированные данные из отрендеренного HTML.

Игнорирование обязательных полей. Каждый тип rich result имеет обязательные поля, задокументированные на developers.google.com/search. Article требует headline, datePublished, author и image. Product требует name, image и либо offers, либо данные рейтинга. Пропуск любого обязательного поля означает, что rich result не отобразится, даже если остальная разметка идеальна. Rich Results Test показывает, что отсутствует.

Устаревший dateModified. Схема Article со значением dateModified, которое никогда не меняется, сигнализирует Google, что страница застойная. Наоборот, обновление dateModified при каждой перегенерации страницы без реального изменения контента — тоже сигнал: Google обнаруживает паттерн и обесценивает поле. Устанавливайте dateModified в реальное время последнего редактирования контента.

Дублирующиеся или рекурсивные значения @id. Две сущности с одним и тем же @id, или сущность, ссылающаяся на собственный @id, ломают граф. Каждый @id должен быть уникальным в пределах блока JSON-LD. Паттерн использования фрагментных идентификаторов вроде #organization, #author, #article делает идентификаторы предсказуемыми и уникальными.

Разовая валидация без повторной проверки. Разметка схемы, работавшая при запуске, может сломаться множеством способов: обновление CMS меняет формат дат, перевод удаляет обязательное поле, рефакторинг шаблона полностью удаляет JSON-LD. Запускайте Rich Results Test хотя бы на одной странице каждого типа схемы после каждого значимого деплоя.

Крайние случаи, о которых никто не говорит

JSON-LD не виден людям, но виден злоумышленникам и конкурентам, просматривающим исходный код страницы. Схема, в которой перечислены внутренние сотрудники по имени, раскрываются корпоративные адреса электронной почты или детализируются цены, не показанные на странице, может утечь информацию, которую вы предпочли бы держать в тайне. Рекомендация — помещать в JSON-LD только те данные, которые уже публично доступны в другом месте на странице. Другой крайний случай — рендеринг: схема, инжектированная на стороне клиента через JavaScript, может быть пропущена при первом проходе сканирования Googlebot, поскольку очередь рендеринга отделена от очереди индексирования и выполняется позже. Для схемы, влияющей на rich results, серверный рендеринг или статическая генерация — безопасный путь.

Бесплатный генератор JSON-LD для Schema.org