Микроразметка Article: JSON-LD для статей

Микроразметка статьи нужна для машинного описания реально опубликованного материала. Она не превращает обычный текст в новость и сама по себе не гарантирует расширенный сниппет. Корректная реализация помогает связать статью, автора, дату, обложку и страницу-источник. Для SEO важнее, чтобы разметка совпадала с видимым содержимым и корректно обновлялась при редактировании.

Article, BlogPosting или NewsArticle: выбираем тип по содержанию

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

Практический JSON-LD для статьи

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

{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "@id": "https://example.ru/blog/seo-checklist/#article",
  "headline": "Чек-лист технического SEO",
  "description": "Проверка индексации, редиректов и canonical",
  "image": ["https://example.ru/media/seo-checklist.webp"],
  "datePublished": "2026-04-12T10:00:00+03:00",
  "dateModified": "2026-10-11T12:00:00+03:00",
  "author": {
    "@type": "Person",
    "name": "Имя автора",
    "url": "https://example.ru/authors/author/"
  },
  "publisher": {
    "@type": "Organization",
    "name": "Пример",
    "url": "https://example.ru/"
  },
  "mainEntityOfPage": {
    "@type": "WebPage",
    "@id": "https://example.ru/blog/seo-checklist/"
  }
}

Для MODX лучше формировать JSON-LD из полей ресурса и отдельных проверенных TV, а не писать его вручную в каждой статье. Иначе на сотнях страниц появятся разные даты, ошибочные канонические URL и несовместимые схемы автора. При генерации JSON учитывайте экранирование кавычек и спецсимволов: строка должна быть валидным JSON.

Даты: что считать публикацией и обновлением

datePublished — дата первичной публикации, а не дата выгрузки нового ZIP. dateModified — фактическая существенная правка статьи, а не случайное изменение счётчика просмотров или настройка шаблона. Не меняйте старую дату выпуска лишь для эффекта «свежести». Для исторических заметок можно сохранить старый текст как архивный и честно обозначить дату появления нового блока с актуальными рекомендациями.

При переносе старых материалов важно сохранять подтверждаемые даты. Поля MODX createdon, publishedon, editedon могут различаться; если в экспортном формате нет этих полей, нельзя угадывать дату публикации по ID ресурса. Визуальная дата статьи и данные Schema должны соответствовать одной редакционной истории.

Автор как сущность, а не набор SEO-ключей

У автора в разметке указывайте корректное имя и релевантную страницу профиля. Ссылки на выступления, профессиональные работы и публикации могут быть полезны на самой авторской странице, но не требуется искусственно собирать десятки свойств sameAs. Не выдумывайте образование, награды и должности. Если издатель — отдельная организация, не подставляйте туда автоматически имя автора; если личный проект, определите последовательную модель и применяйте её ко всем шаблонам.

Хорошая статья должна иметь собственные факты, опыт, иллюстрации и источники. Разметка лишь описывает эти объекты. Если на видимой странице нет фотографии или автора, добавление их только в Schema может противоречить принципам поисковых систем.

Проверка Article: три разных этапа

1. Синтаксис. JSON разбирается без ошибок, URL валидны, даты имеют временную зону, поля заполнены.
2. Семантика. Указан правильный тип страницы, автор, издатель, дата и изображение, которые видны или подтверждаемы на сайте.
3. Поисковая обработка. Страница доступна роботу, не закрыта от индексации, Google видит разметку после рендеринга. Это проверяется Rich Results Test и URL Inspection, а не только JSON-валидатором.

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

Типичные ошибки на WordPress и MODX

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

В шаблоне не следует механически добавлять FAQPage на каждую статью с вопросами: допустимость разметки и право на отдельные поисковые функции различаются. Сами ответы должны быть видимыми и полезными пользователю независимо от Schema.

Проверка при массовом внедрении

Для каждого шаблона выберите контрольные страницы: новую, старую, с двумя авторами, без фотографии, с будущей запланированной публикацией, перенесённую через 301, а также неопубликованную. Проверьте @id и URL во всех вариантах. После релиза сравните шаблонную генерацию с экспортом реальных страниц, обнаружьте дубли и повторно проверьте изменение dateModified при публикации существенной редакции.

Микроразметка при обновлении старых статей: сценарий

Пусть статья впервые вышла в 2016 году, а в 2026-м автор переписал раздел про инструменты и добавил новые примеры. Правильнее сохранить дату оригинальной публикации, указать дату содержательного обновления и объяснить читателю, какие части относятся к историческому опыту. Нельзя просто поставить datePublished=2026, стирая десять лет контекста, если старая публикация действительно существовала.

Для крупной темы на сайте может быть несколько связанных материалов: общий обзор Schema.org, подробный Article и отдельный Product. В этом случае каждая статья получает собственный @id, mainEntityOfPage, текст и интент. Простое дублирование одного JSON-LD на весь раздел создаёт некорректные отношения между страницами. При построении графа сущностей используйте стабильные идентификаторы автора и издателя, а не каждый раз создавайте новый Person с разными URL.

Автоматическая проверка в CI или в MODX

Перед публикацией можно автоматически разобрать все <script type="application/ld+json">, проверить валидность JSON, обнаружить противоречащие @id, отсутствующие обязательные URL, даты позже текущего времени, а также совпадение mainEntityOfPage с canonical. Отдельно проверьте, что в финальном HTML не выведены сразу два противоречивых Article: например, один из шаблона, другой из нового SEO-сниппета.

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

Связанные материалы и документация

Чек-лист микроразметки, Product JSON-LD, Google Search Central — Article, общие рекомендации по structured data.

Архивные иллюстрации и первоначальные наблюдения

Это материалы из первоначальной версии статьи. Скриншоты и старые интерфейсы сохранены как часть истории публикации; они не доказывают актуальность показанных функций и результатов.

Показать архивные изображения (1)

Связаться в Telegram

Следующие страницы вас также могут заинтересовать:

• Робототехника
• SEO-продвижение образовательного сайта: 7 лет — от старого HTML до AI Search
• Кейс по SEO-продвижению медицинского центра ударно-волновой терапии
• Паллетирование: что это такое, технологии, оборудование и роботизация
• Промышленные роботы: что это, виды, устройство и применение

Обновлено: 11.10.2026