Schema.org Article: зачем нужна разметка статьи и как проверить её без ошибок

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

Поймите роль Article до внедрения

Страница уже сообщает о себе через заголовки, текст, ссылки, изображения и метатеги. Структурированные данные добавляют ещё один слой — словарь известных сущностей и свойств. Тип Article обозначает творческую работу в форме статьи; для обычного блога часто подходит более конкретный тип BlogPosting, который входит в иерархию Article.

По описанию Article в словаре Schema.org, у сущности могут быть заголовок, автор, даты публикации и изменения, изображения, издатель и другие свойства. Google отдельно объясняет, что корректная разметка статьи может помочь системе лучше понять страницу и её изображения, однако показ расширенного результата не обещается. Значит, задача разметки — точность данных, а не попытка «вынудить» выдачу выглядеть определённым образом.

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

Выберите тип и формат JSON-LD

Для редакционного материала используйте Article, NewsArticle или BlogPosting по смыслу. Новость с редакционной подачей может быть NewsArticle, запись корпоративного или экспертного блога — BlogPosting. Не выбирайте более узкий тип только из-за названия: содержание страницы должно ему соответствовать.

JSON-LD обычно размещают в элементе script с типом application/ld+json. Он отделён от визуальной вёрстки и удобен для шаблонов. Минимальный рабочий фрагмент может выглядеть так:

``json { "@context": "https://schema.org", "@type": "BlogPosting", "headline": "Понятный заголовок статьи", "datePublished": "2026-10-11", "dateModified": "2026-10-11", "mainEntityOfPage": "https://example.ru/blog/statya.html", "author": {"@type": "Organization", "name": "Название проекта"}, "image": ["https://example.ru/images/oblozhka.webp"] } ``

Это пример структуры, а не готовая вставка для любого сайта. Адреса, даты, автор и заголовок должны браться из конкретной страницы. Если издатель и автор — одна организация, это допустимо, но человек не должен быть назван автором без фактического участия.

Заполните основные поля из фактов страницы

headline должен передавать заголовок публикации. Он может совпадать с H1 или быть очень близким к нему. Не подменяйте его рекламным обещанием, которого нет на странице.

author описывает человека или организацию, ответственных за материал. Ссылка url или sameAs уместна, когда существует реальная страница автора либо официальный профиль. Не создавайте фиктивную биографию ради заполнения поля.

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

image содержит абсолютные URL подходящих изображений, доступных без авторизации. Обложка должна действительно относиться к статье, иметь корректный HTTP-ответ и не быть закрыта правилами обхода. mainEntityOfPage обычно указывает канонический адрес материала.

Издателя можно описать через publisher. Для организации полезны имя, URL и логотип, если эти сведения подтверждены на сайте. Не превращайте объект в перечень всех возможных полей. Качество не измеряется длиной JSON: важнее заполнить релевантные свойства и поддерживать их актуальность.

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

Главное правило: структурированные данные не должны рассказывать поисковой системе другую историю. Если в JSON-LD указан автор, его имя должно быть доступно читателю. Если размечен FAQ, вопросы и ответы должны присутствовать на странице. Если дата обновления изменилась, должно быть понятно, что материал действительно пересмотрен.

Сверьте пять пар:

• headline и H1;
• description и реальное содержание вводной части;
• author и видимый авторский блок;
• datePublished / dateModified и даты на странице;
• image и фактическая обложка материала.

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

Если статья имеет продуманную структуру, разметка остаётся дополнением. Она не исправит слабый ответ, повторяющиеся разделы или отсутствие полезного результата для читателя.

Не путайте Article, FAQ и хлебные крошки

На одной странице может быть несколько сущностей. BlogPosting описывает публикацию, FAQPage — видимый блок вопросов и ответов, BreadcrumbList — путь в структуре сайта. Их можно передать отдельными объектами или объединить через @graph, если шаблон устроен сложнее.

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

Для сайта услуг статья и коммерческая страница решают разные намерения. В материале уместно объяснить проблему и дать следующий шаг, а услугу описывать отдельной сущностью на своей странице. Это согласуется с принципом: одна страница — одна основная задача.

Проверьте код до публикации

Сначала убедитесь, что JSON является валидным: кавычки парные, запятые стоят между свойствами, нет комментариев внутри объекта. Затем используйте Rich Results Test Google для поддерживаемых типов и валидатор Schema.org для проверки словаря и структуры.

Результаты этих инструментов отвечают на разные вопросы. Валидный код означает, что синтаксис и свойства распознаны. Это не доказывает, что страница будет показана расширенно. Предупреждение часто сообщает о рекомендуемом поле, а ошибка — о некорректном или обязательном для выбранной функции значении. Читайте пояснение, а не только цвет индикатора.

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

Проведите проверку после публикации

Production-проверка начинается с HTTP-статуса. Статья и изображения должны отвечать 200 OK, если это обычная доступная страница. Затем проверьте canonical, robots, заголовок документа, описание и один H1. Только после этого имеет смысл разбирать разметку.

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

Если Вы обновили материал, синхронно обновите видимую дату, dateModified, sitemap и связанные страницы — только там, где изменения действительно были. После переноса сайта проверьте все абсолютные URL: старый домен в image, author.url или canonical легко остаётся незамеченным.

Встройте разметку в редакционный процесс

Надёжнее генерировать JSON-LD из тех же данных, что используются для H1, canonical, даты и карточки статьи. Тогда редактор меняет значение один раз, а шаблон подставляет его в нужные места. При ручной вставке заведите короткий чек-лист и проверяйте каждую публикацию.

Практический порядок:

1. утвердить тему, автора, дату и канонический URL;
2. подготовить текст и изображения;
3. собрать метаданные и JSON-LD из тех же полей;
4. проверить валидность локально;
5. опубликовать страницу атомарно;
6. проверить публичный URL и изображения;
7. при содержательном обновлении синхронизировать данные.

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

Используйте короткий чек-лист Article

Перед выпуском ответьте «да» на вопросы:

• тип соответствует материалу;
• headline, автор и даты видны читателю;
• canonical и mainEntityOfPage указывают на правильный URL;
• обложка открывается и относится к статье;
• нет выдуманных рейтингов, отзывов и достижений;
• JSON-LD проходит проверку без критических ошибок;
• мобильная версия и основной текст работают независимо от разметки.

Если какой-то факт ещё не определён, исправьте источник данных. Не маскируйте проблему дополнительным свойством Schema.org.

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

Разметка Article повышает позиции?

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

Что выбрать: Article или BlogPosting?

Для записи блога обычно логичен BlogPosting; он является более конкретным типом статьи. Выбор должен соответствовать фактическому формату материала.

Обязательно ли использовать JSON-LD?

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

Можно ли указать организацию автором?

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

Нужно ли менять dateModified при каждой сборке сайта?

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

Почему валидатор показывает предупреждения?

Часть свойств рекомендуется для более полного описания, но не всегда обязательна. Изучите конкретное сообщение и добавляйте только достоверные данные.

Где проверить опубликованную разметку?

Используйте Rich Results Test для функций Google и Schema.org Validator для словаря, а затем проверьте публичный HTML, canonical и доступность изображений.

Если Вы хотите поручить подготовку статьи вместе со структурой, метаданными, изображениями и проверкой, посмотрите услуги проекта «Сайт в плюс». Мы сначала уточним задачу страницы и не будем обещать гарантированные позиции.

Навигацию проверяйте отдельно от описания самой статьи: как согласовать видимый путь и BreadcrumbList. В инструкции есть карта подписей, адресов и критериев приёмки.