Разметка — это небольшой блок структурированных данных, который вы добавляете на страницу, чтобы поисковые системы могли читать ключевые факты в ясном и согласованном формате. Думайте о ней как о ярлыке на коробке: содержимое остаётся прежним, но ярлык упрощает сортировку и отображение.
Когда поисковики лучше понимают страницу, они могут показать её как богатый результат вместо стандартной синей ссылки. Богатый результат может включать дополнительные детали: заголовок, дату публикации, автора, хлебные крошки или короткий превью. Это не происходит для каждой страницы — решение всегда остаётся за поисковой системой.
Важно понимать, что разметка может и чего не может. Структурированные данные улучшают понятность и дают право на некоторые поисковые функции, но сами по себе они не повышают позиции в выдаче. Если страница слабая, устаревшая или плохо индексируется, разметка не исправит эти проблемы. И она не может заставить показать богатый результат.
На большинстве сайтов важнее нескольких простых шаблонов, чем длинный список свойств:
Простой пример: вы публикуете определение в глоссарии и блог-пост, который ссылается на него. С правильной разметкой поисковая система с большей уверенностью поймёт, что одна страница — это определение, а другая — руководство, а не два конкурирующих «статьи».
Если вы публикуете много страниц (особенно из шаблонов или через API), разметка становится ещё более ценной, потому что поддерживает согласованность вывода при добавлении блогов, новостей и глоссарных записей с течением времени.
Для большинства блогов лучшая отправная точка — BlogPosting, который более конкретен по сравнению с Article.
Наиболее заметный эффект даёт правильное заполнение базовых полей в каждом посте. Поисковики ценят точные, стабильные сигналы больше, чем длинный перечень опциональных свойств.
Сделайте эти поля точными в каждом посте:
Если вы обновляете старый гайд, оставляйте datePublished оригинальной датой и ставьте dateModified на дату изменения. Не меняйте datePublished просто чтобы выглядеть свежее и не обновляйте dateModified, если содержимое фактически не менялось.
Опциональные поля полезны только если они точны и их легко поддерживать. keywords имеют смысл, если вы уже показываете теги или категории. wordCount подходит для преимущественно статичных длинных страниц, но пропустите его, если контент часто меняется после публикации. speakable актуально, только если у вас есть короткое аккуратное резюме, предназначенное для озвучивания.
Если ваш конвейер автоматически генерирует JSON-LD (например, через шаблон CMS или рендерер, основанный на API), сначала добейтесь согласованности и корректности, прежде чем добавлять дополнительные поля.
Новостные страницы оцениваются по свежести и ясности. Поисковым системам важно знать, что случилось, когда это было опубликовано и кто опубликовал. Поэтому новостная разметка обычно менее терпима к ошибкам.
Используйте NewsArticle, когда страница освещает своевременное событие или развитие, которое устареет. Используйте Article для вечнозелёной аналитики, мнений и длинных материалов, не привязанных к конкретному моменту.
Практическое правило:
Для новостей даты важны почти больше, чем для любых других типов контента. Включайте и datePublished, и dateModified, и убедитесь, что они совпадают с тем, что видит читатель на странице. Если вы обновили историю, обновите dateModified. Если вы «переопубликовали» старую статью как новую, убедитесь, что видимые даты и структурированные данные рассказывают одну и ту же историю.
Для многих новостных страниц небольшое количество полей даёт большую ценность: headline, description, image (реальное, доступное для краулинга изображение), author, publisher (как Organization), mainEntityOfPage, datePublished и dateModified.
Если у вас есть paywall или подписка, отметьте это явно с помощью isAccessibleForFree и деталей о платном доступе. Не заявляйте, что контент бесплатен, если это не так.
Для перепубликованных или синдицированных материалов избегайте выглядеть источником-дубликатом. Держите один канонический URL на историю, держите структурированные данные согласованными на этой канонической версии и не меняйте заголовки между копиями. Если одна и та же история существует в нескольких местах, сделайте очевидным, какая страница первичная.
Страницы глоссариев могут получить более понятные сниппеты, когда поисковики понимают, что вы определяете термины, а не публикуете обычные статьи. Даже если основной фокус — разметка для блогов, разметка определений помогает быстрее классифицировать контент глоссария.
Используйте DefinedTerm, когда страница объясняет один термин. Используйте DefinedTermSet, когда страница — коллекция терминов, например A–Z глоссарий или категория с множеством записей. Используйте FAQPage только тогда, когда страница действительно является списком вопросов с ответами, а не одиночным определением.
Простое правило: если цель страницы — «дать определение», выбирайте DefinedTerm. Если цель — «просмотреть много определений», выбирайте DefinedTermSet.
Для страницы одного термина фокусируйте разметку на одном термине и его определении, плюс где он находится.
{
"@context": "https://schema.org",
"@type": "DefinedTerm",
"name": "Canonical tag",
"alternateName": ["rel=canonical", "canonical URL"],
"description": "A canonical tag tells search engines which URL is the preferred version of a page.",
"inDefinedTermSet": {
"@type": "DefinedTermSet",
"name": "SEO Glossary"
}
}
Для страницы категории используйте DefinedTermSet. Добавляйте ItemList из страниц терминов только если этот список видим пользователям на странице.
Когда у вас есть синонимы, используйте alternateName для реальных вариаций, аббревиатур и вариантов написания. Держите его коротким и честным — не наполняйте ключевыми словами.
Поддерживайте текст определения синхронизированным с тем, что видит пользователь. Если описание в JSON-LD говорит одно, а видимое на странице определение — другое, шансы на богатый сниппет падают.
Некоторые типы схем полезны практически для любой страницы: блог, глоссарий или новость.
BreadcrumbList — один из самых простых «вин». Он показывает, где страница находится на вашем сайте, используя ту же цепочку, что и пользователи (Home → Blog → Topic → Post). Это упрощает вид результата и уменьшает путаницу, когда похожие страницы есть в разных разделах.
Organization и WebSite дают чёткие сигналы бренда. Organization покрывает ваше имя, логотип и контактные детали. WebSite может описывать сайт и, опционально, внутренний поиск. Включайте разметку поиска только если пользователи действительно могут искать на вашем сайте.
Изображения тоже важны. Если страницы полагаются на hero или featured изображения, добавление ImageObject (или полное описание изображения в основной схеме) помогает поисковикам понять, что это за изображение, где оно хранится и его ключевые характеристики.
Разметка автора часто становится источником несоответствий. Выберите один подход и придерживайтесь его: используйте Person, когда реальный человек указан автором страницы, и Organization, когда контент публикуется под брендом. Избегайте переключения между Person и Organization для одного и того же имени автора.
Используйте sameAs только для официальных профилей, которыми вы управляете. Если сомневаетесь — пропустите. Устаревшие или неверные профили могут подорвать доверие.
JSON-LD часто самый безопасный способ добавить структурированные данные, потому что он живёт в одном \u003cscript type="application/ld+json"\u003e блоке и не меняет то, что видит пользователь. Поместите его в HTML страницы (обычно в \u003chead\u003e или ближе к концу \u003cbody\u003e) и убедитесь, что он рендерится в финальной версии страницы, а не только в превью.
Начните с видимого контента, затем сопоставьте его с полями схемы. Если на странице показаны заголовок, имя автора, дата публикации, основное изображение и короткое описание, ваш JSON-LD должен совпадать с этими значениями. Несоответствия — частая причина, почему разметка не приносит богатых результатов.
Постройте воспроизводимый шаблон для каждого типа контента (блог-пост, новость, термин глоссария). Самая безопасная настройка — когда шаблон берёт данные из того же источника, что и содержимое страницы, тогда обновления остаются синхронизированными.
Плавный план развёртывания, который снижает риски:
@id.Вот небольшой шаблон для стабильных ID (обратите внимание на URL-ориентированный @id):
{
"@context": "https://schema.org",
"@type": "BlogPosting",
"@id": "https://example.com/blog/my-post#blogposting",
"headline": "My Post Title",
"datePublished": "2026-01-16",
"mainEntityOfPage": "https://example.com/blog/my-post"
}
Если ваш сайт собран на фреймворке вроде Next.js, генерируйте этот блок при рендере из CMS или контент-API.
Валидация состоит из двух частей. Сначала убедитесь, что JSON-LD валиден и соответствует правилам схемы. Затем проверьте, считает ли Google страницу подходящей для богатых результатов. Прохождение синтаксических проверок не гарантирует, что вы получите улучшённый результат.
Начните с копирования точно того JSON-LD, который рендерится на живой странице (не шаблонного файла), и проверьте его на общие ошибки схемы. Schema Markup Validator полезен для обнаружения неправильных имён свойств, отсутствующих обязательных полей и несоответствий типов.
Затем протестируйте право на богатые результаты с помощью Rich Results Test от Google. Этот инструмент фокусируется на функциях, которые Google действительно показывает, и подчёркивает недостающие поля, блокирующие eligibility, даже если разметка технически валидна. Для блогового контента типично, что небольшие пробелы — например, отсутствие изображения или автора — мешают получить богатый результат.
Обрабатывайте результаты тестов так:
Если вы изменили общий шаблон и Rich Results Test начал жаловаться на отсутствие datePublished на некоторых страницах, это часто указывает на проблему с данными (пустое поле в CMS), а не на проблему с самой схемой.
Повторно тестируйте после каждого изменения шаблона, даже если оно кажется незначительным. Если вы генерируете контент через API, проверяйте одну недавно опубликованную страницу каждого типа перед массовым развёртыванием изменений.
Богатые результаты часто не появляются по простым причинам: поисковики читают вашу разметку, но не доверяют ей.
Главное правило — соответствовать тому, что видит пользователь. Если ваш JSON-LD заявляет имя автора, заголовок или дату публикации, эти детали должны быть видны на странице. Не прячьте ключевые данные только в разметке и не используйте разную формулировку.
Отсутствие обязательных полей — ещё один частый барьер. Для страниц типа Article обязательны заголовок, изображение и дата публикации или обновления. Если изображение слишком маленькое, отсутствует или недоступно для краулера, страница может не попасть в богатые результаты, даже если всё остальное корректно.
Неправильный тип схемы тоже вредит. Добавление FAQPage на страницу, которая не является разделом вопросов и ответов, может привести к игнору разметки или флагам. Выбирайте типы, которые соответствуют реальной странице: BlogPosting для поста, NewsArticle для новостной истории, DefinedTerm для определения.
Ещё несколько часто встречающихся проблем:
Пример: команда публикует новостную статью, на странице видно «Обновлено 16 янв.», но в разметке осталась дата прошлой недели из повторно использованного шаблона. Даже с корректным NewsArticle поисковики могут посчитать источник ненадёжным, пока видимый контент и структурированные данные не начнут совпадать.
Перед нажатием «опубликовать» выполните быструю проверку согласованности. Большинство проблем с богатым результатом — не сложные ошибки, а небольшие несоответствия между тем, что показывает страница, и тем, что заявляет разметка.
Если вы добавляете разметку для блогов, начните с определения, чем страница является (BlogPosting, NewsArticle или страница с определением). Всё остальное должно поддерживать этот выбор.
Если вы публикуете новостное обновление, а потом используете тот же шаблон для записи в глоссарии, не оставляйте поля NewsArticle. Страница с определением, которая по-прежнему заявляет, что она NewsArticle, часто не проходит проверку на eligibility.
Представьте небольшой сайт, который публикует три типа контента: еженедельные блоги, глоссарий ключевых терминов и простой новостной хаб для обновлений компании. Цель — получить более понятные сниппеты и право на богатые результаты без изменения дизайна страниц.
Выбор схем зависит от намерения. Блог-посты часто подходят под BlogPosting (или Article). Новостные обновления подходят под NewsArticle только когда они действительно своевременны. Записи глоссария должны фокусироваться на DefinedTerm и DefinedTermSet (часто в паре с WebPage), чтобы поисковики поняли «эта страница определяет термин», а не «это история».
Вот практичный двухнедельный план развёртывания, который снижает риски:
BreadcrumbList и профиля Organization (издатель).После развёртывания подтвердите два момента: разметка присутствует на живой странице (не удаляется рендерером или инструментами согласия), и поисковые системы краулили обновлённые страницы и показывают структурированные данные в отчётах о расширениях и богатых результатах.
Успех обычно выглядит как рост показов для уже ранжируемых страниц, появление новых элементов улучшения для подходящих типов и умеренное увеличение CTR из-за более чистых заголовков, дат и хлебных крошек.
Разметка — это не одноразовая задача. Она чаще всего ломается, когда меняется шаблон, переименовывается поле или добавляется новый блок контента, а JSON-LD не обновляется.
Включите структурированные данные в процесс публикации. Если у вас есть блог, новостной хаб и глоссарий, решите, какие поля обязательны для каждого типа контента, и относитесь к этим полям так же, как к заголовку и URL — они должны присутствовать при каждой публикации.
Самый простой способ поддерживать разметку для блогов — привязать её к тому же источнику правды, который генерирует страницу: заголовок, автор, дата публикации, изображения, категория и основное тело. Когда контент создают разные инструменты и люди, появляются пропуски (нет автора, неверный формат даты, пустой массив изображений), и шанс получить богатый результат падает.
Лёгкая рутина, которая работает для большинства команд:
Если вы публикуете в масштабе, автоматизация помогает. Например, GENERATED (generated.app) может генерировать блог, новостной и глоссарный контент через API и поддерживать согласованные поля структурированных данных в шаблонах, включая случаи перевода или обновления контента.
Пример: если вы вводите новую метку «последнее обновление», одновременно добавьте в JSON-LD поле dateModified и затем провалидируйте пример поста в блоге, страницу NewsArticle и термин глоссария перед развёртыванием изменения.
Разметка — это структурированные данные, которые помогают поисковым системам последовательно читать ключевые факты на странице. Она может сделать страницу подходящей для богатых результатов (например, показывать даты, хлебные крошки или дополнительные детали), но сама по себе не повысит позиции в выдаче.
Используйте BlogPosting, когда страница явно является записью блога — гайдом, обзором, мнением или обновлением. Используйте Article, когда контент более широкий редакционный материал или когда вы хотите единый тип по всему сайту и ваша система уже выдаёт Article.
Начните с полей, которые должны быть точными и стабильными: headline, author, datePublished, image и mainEntityOfPage. Если эти поля совпадают с тем, что видит пользователь на странице, вы уже выполнили большую часть работы по доверительности и соответствию требованиям.
Сохраняйте datePublished оригинальной датой публикации и меняйте только dateModified, когда вы действительно обновляете контент. Менять datePublished, чтобы выглядеть свежее, рискованно, если это не совпадает с тем, что видно на странице.
Используйте NewsArticle только для оперативных историй с чётким моментом публикации — анонсы, срочные обновления и события, которые устаревают. Для вечнозелёных материалов, аналитики и длинных форм используйте Article.
Для определения терминов используйте DefinedTerm на странице, где объясняется один термин. Для коллекций терминов (A–Z, категории) используйте DefinedTermSet. Структурированное определение должно соответствовать видимому тексту на странице, чтобы не создавать несогласованность.
BreadcrumbList помогает поисковикам показать чистую хлебную крошку вместо длинного URL, что уменьшает путаницу, когда похожие страницы есть в разных разделах. Это также один из простейших типов разметки для поддержания в актуальном состоянии, потому что он отражает видимую навигацию.
Добавьте один JSON-LD блок в скрипт-тег (type="application/ld+json") в итоговом HTML страницы, чаще всего в head или перед закрывающим body. Самый надёжный подход — генерировать JSON-LD из тех же данных, что и видимый заголовок, даты, автор и изображение, чтобы все значения синхронизировались.
Проверяйте дважды: сначала убедитесь, что JSON-LD валидный и использует корректные свойства и типы; затем отдельно проверьте право на богатые результаты. Страница может иметь корректную разметку и при этом не попасть в богатые результаты, поэтому тесты на eligibility — это отдельный шаг.
Чаще всего причина в несоответствии между тем, что заявляет разметка, и тем, что видит пользователь: отсутствует изображение, нет даты публикации, или в разметке и на странице разные заголовки или авторы. Также встречаются конфликтующие блоки разметки, которые описывают одну и ту же страницу по-разному.