Микроразметка NewsArticle
NewsArticle schema
Также: разметка новости
Микроразметка NewsArticle — машиночитаемое описание новости или материала, объясняющего новостные события, с помощью типа NewsArticle словаря Schema.org. Оно обозначает, что опубликовано на странице, и передаёт сведения о материале: например, заголовок, авторов и время публикации.
Schema.org относит NewsArticle к статьям, сообщающим новости либо раскрывающим их контекст; тип наследует свойства Article и CreativeWork. [1] Это описание содержания, а не свидетельство его достоверности. Google отдельно предупреждает, что даже корректная разметка не гарантирует особого представления страницы в результатах поиска. [7]
Кратко
- NewsArticle обозначает вид материала; JSON-LD — формат, в котором можно записать его описание. [1, 3]
- Поля выбирают под задачу и требования системы, которая будет читать данные. [2, 5]
- Разметку сверяют с видимой публикацией: правильные скобки не исправляют ошибочное авторство. [7]
- Локальный сборщик готовит черновик. Проверка страницы и работа поисковой системы остаются отдельными этапами.
Открыть мини-инструмент к статье → Расчёт идёт в браузере, данные никуда не отправляются.
Происхождение и история термина
2 июня 2011 года Google объявила о совместной с Bing и Yahoo! инициативе Schema.org. Её задачей был общий набор схем для описания содержания веб-страниц, чтобы владельцам сайтов не приходилось готовить разное описание для каждого поисковика. [6] Это историческая точка появления проекта, а не установленная дата введения отдельного типа NewsArticle.
Формат записи данных развивался отдельно от словаря. Рекомендация W3C JSON-LD 1.1 опубликована 16 июля 2020 года и заменила JSON-LD 1.0. [3] В перечне публикаций рабочей группы на дату проверки 1.1 находится среди рекомендаций; план группы предусматривает дальнейшую разработку 1.2. [10, 11] План следующей версии сам по себе не отменяет опубликованный стандарт.
Для читателя практический смысл этой истории прост: название типа, версия формата и инструкция сервиса отвечают на разные вопросы. Словарь помогает назвать объект, формат — записать сведения, а инструкция получателя — выбрать нужные поля. Поэтому старый пример кода полезен для изучения устройства разметки, но перечень требований к внедрению следует брать из текущей документации получателя.
Суть и механизм
Представим учебный городской сайт. На странице написано: «В районе открыли новую читальню», под заголовком стоят имена Анны Лесной и Ильи Речного, рядом — дата. Читатель понимает, где заголовок и кому принадлежит текст. Чтобы явно передать эти сведения программе, редакция создаёт описание с именованными полями. Названия полей задаёт словарь, значения берут из материала. Этот пример и все персонажи далее вымышлены.
В JSON-LD сведения записываются парами «ключ — значение». Ключ @context связывает используемые названия со словарём, @type задаёт тип объекта. Отдельный блок помещают в HTML — код веб-страницы — внутри элемента script с типом application/ld+json. [3, 5] Слово script здесь не означает, что сама новость превращается в выполняемую программу: блок содержит данные.
В учебном объекте headline хранит заголовок, а author — список авторов. Квадратные скобки обозначают список; фигурные ограничивают каждый объект. Два автора получают два объекта, а не одно общее имя. Так программа может различить участников даже тогда, когда видимая подпись соединяет их имена союзом «и».
json
{
"@context": "https://schema.org",
"@type": "NewsArticle",
"headline": "В районе открыли новую читальню",
"url": "https://example.com/news/reading-room/",
"datePublished": "2026-10-22T09:00:00+07:00",
"author": [
{"@type": "Person", "name": "Анна Лесная"},
{"@type": "Person", "name": "Илья Речной"}
]
}
Это сокращённый учебный объект, а не полный профиль для любой системы. Чтобы оценить его, полезно поставить два разных вопроса. Первый: удаётся ли прочитать запись как JSON, то есть соблюдены ли правила формата? Второй: верно ли описана публикация? Если заменить фамилию автора чужой фамилией, синтаксис останется исправным. Обнаружить такую ошибку можно только сравнением с исходными редакционными сведениями.
Какие сведения передавать
В справке Google Article нет обязательных свойств: перечислены рекомендуемые применимые поля. Поддерживаются типы Article, NewsArticle и BlogPosting. [2]
| Поле | Значение в документации Google |
|---|---|
headline |
Заголовок статьи. [2] |
author |
Автор: человек Person или организация Organization; нескольких авторов указывают раздельно. [2] |
author.url |
Страница, позволяющая идентифицировать автора. [2] |
datePublished |
Время первой публикации. [2] |
dateModified |
Время последнего изменения. [2] |
image |
Изображение, представляющее содержание статьи. [2] |
В учебной редакции эти значения удобно получать из тех же полей системы управления содержимым, или CMS, которые используются для видимой страницы. Это предлагаемое редакционное решение: одна исправленная запись должна обновлять оба представления. Если заголовок переписывают вручную ещё и в JSON-LD, появляется вторая копия, о которой легко забыть.
С авторством нужна дополнительная договорённость внутри редакции. Допустим, корреспондент написал текст, редактор исправил запятые, а администратор загрузил страницу. Нельзя поручать сборщику угадывать их роли по последнему пользователю CMS. Сначала редакция определяет авторство публикации, затем переносит установленную подпись в поля. Google рекомендует включать всех указанных на странице авторов и не подменять имя автора названием издателя. [2]
Почему важны время и смещение
Запись 2026-10-22T09:00:00+07:00 означает местное время с положительным смещением на семь часов относительно UTC — всемирного координированного времени. Для перевода в UTC смещение вычитают; это правило числовых смещений описано в RFC 3339. [8] В данном учебном случае получается 02:00 UTC того же дня.
Предположим, изменение записали как 2026-10-22T05:30:00+03:00. После вычитания трёх часов получаем 02:30 UTC: правка сделана через тридцать минут после публикации. Сравнение только цифр 05:30 и 09:00 дало бы противоположный вывод. Поэтому сборщик сравнивает моменты времени с учётом смещений. Равные моменты допускаются: после создания записи дата изменения может совпадать с датой публикации.
Смещение не равно названию часового пояса. Оно описывает разницу с UTC для указанного момента; часовой пояс содержит правила для разных дат. RFC 9557 расширяет формат RFC 3339 и уточняет его интерпретацию, сохраняя совместимость обычных временных меток. [9] Учебная форма не вычисляет местные правила по названию города: правильное смещение вводит пользователь.
Виды и классификации
В иерархии Schema.org CreativeWork — более общий тип творческого произведения, Article — статьи, NewsArticle — новостной статьи. [1] Выбор типа отвечает на вопрос о содержании. Выбор JSON-LD отвечает на вопрос о записи. Поэтому противопоставлять «NewsArticle или JSON-LD» столь же неудобно, как выбирать между названием документа и форматом его файла.
Для работы редакции можно отдельно различать ручную подготовку и создание разметки из CMS. Это практическое деление в данной статье, а не классификация Schema.org. При ручной подготовке удобно внимательно разобрать один материал. При автоматическом создании важно проверить правило, поскольку оно применяется многократно.
В учебном случае общий шаблон всегда вставляет имя главного редактора. Исправление одного готового блока спасёт одну страницу, но следующая новость снова получит неправильную подпись. Поэтому разработчик меняет источник поля в шаблоне, а редактор проверяет несколько разных материалов. Результат оценивают по данным каждой публикации, а не по одинаковому внешнему виду кода.
Как применяется на практике
Google использует описание Article, чтобы лучше понимать материал и сведения для его представления в поиске. [2] У Яндекс Метрики другая рассматриваемая задача — аналитика контента. В её JSON-LD-инструкции обязательными элементами названы идентификатор, заголовок и текст; поддерживается в том числе NewsArticle. [5]
Это сопоставление двух назначений данных, а не поисковых алгоритмов Google и Яндекса. Справка Метрики не служит основанием для вывода о ранжировании в Яндекс Поиске.
Идентификатор @id позволяет Метрике различать материалы. Текст рекомендуют передавать через text; при его отсутствии справка описывает получение содержимого из элемента по якорю, окружающего узла или тела страницы. [5] Поэтому формально работающая передача данных ещё требует проверки границ материала.
В учебной странице после новости расположены рекомендации и комментарии. Если настройка подхватит весь окружающий текст, измеряемый материал не совпадёт с редакционной статьёй. Практическая проверка здесь — открыть конкретный пример и установить, что именно считается содержимым новости. Не следует механически добавлять все поля из одной инструкции, ожидая, что другая система использует их так же.
Как измерить или проверить
Для этой статьи предложена последовательность из четырёх проверок: запись читается; выбран подходящий тип; значения совпадают с публикацией; получатель обрабатывает страницу по своим правилам. Это рабочий порядок проверки, а не числовая оценка качества новости. Каждая ступень отвечает на свой вопрос и не заменяет следующую.
Rich Results Test позволяет передать URL страницы или отдельный код. При проверке URL ресурсы должны быть доступны из интернета без пользовательской авторизации; результаты показывают найденные элементы, ошибки и предложения. [4] Код можно проверить до внедрения, однако такой тест не покажет, какой блок в итоге выведет конкретный шаблон сайта.
Редакционная проверка продолжается на готовой странице. В учебном сайте разработчик исправил генератор, но старый плагин оставил второй блок с прежней датой. Если проверять только новый скопированный фрагмент, противоречие останется незаметным. Следует просмотреть фактически полученные описания и понять, откуда поступает каждое значение. Общие правила Google требуют соответствия разметки содержанию, видимому читателю. [7]
Для приёмки шаблона полезен небольшой набор специально выбранных примеров: новость с одним автором, с двумя авторами, после изменения заголовка и после изменения текста. Для каждой страницы редактор заранее записывает ожидаемые сведения. Если код не совпал с ними, причина исследуется до массового применения. Такие примеры показывают разные ветви работы шаблона; десяток почти одинаковых новостей может их не затронуть.
Локальный сборщик
Файл «мини-инструмент» работает без сетевых запросов. Он требует заголовок, абсолютный HTTP(S)-адрес публикации, хотя бы одно имя автора и дату публикации. Изображения и дату изменения можно не заполнять. Это ограничения учебной формы, а не дополнительные требования Google. Каждый автор здесь создаётся как Person; организации и страницы авторов форма не моделирует.
Для даты выбран явный узкий формат: год из четырёх цифр от 0001 до 9999, календарная дата, время с секундами и Z либо смещение ±HH:mm. Допустимы часы от 00 до 23, секунды от 00 до 59, смещения не дальше ±14:00. Доли секунды, секунды координации и обозначение неизвестного смещения -00:00 форма отклоняет. Это собственный профиль сборщика, а не полная реализация всех вариантов ISO 8601 или RFC 3339.
Сборщик также отклоняет несуществующие даты и изменение раньше публикации, адреса с учётными данными, неподходящие протоколы и повтор одного имени. Пробелы по краям убираются, пустые строки в списках пропускаются. Два разных человека с одинаковым именем потребуют более подробной модели авторов вне этой формы: одинаковая строка сама по себе их не различает.
При любом изменении ввода, ошибке или сбросе предыдущий результат удаляется, скачивание отключается. Это защищает от простой рабочей ошибки: человек исправил поля, но скопировал старый черновик. Кнопка скачивания сохраняет JSON; показанный фрагмент дополнительно содержит обёртку для вставки в HTML. Экспорт не проверяет доступность страницы или изображений.
Сборщик не формирует @id и text и не проверяет получение текста со страницы. Его результат нельзя объявлять готовой настройкой аналитики Метрики. Для неё потребуются отдельная настройка по документации и проверка на реальном материале. Смысл локального упражнения — понять передачу заголовка, авторов и дат, прежде чем подключать описание к большому шаблону.
Ошибки, ограничения и спорные вопросы
Распространённая смысловая ошибка — ожидать, что название NewsArticle удостоверяет правдивость. Можно аккуратно описать вымышленную новость, и программа прочитает её поля. Проверка достоверности требует проверки самого сообщения; название класса лишь говорит, как издатель описал объект. [1]
Другой риск возникает при вставке произвольного текста в HTML. W3C отдельно рассматривает последовательности, похожие на начало и конец script. [3] В нашем инструменте символ < в JSON заменяется на \u003c. Учебный заголовок с буквальным </script> после такой обработки сохраняет исходный смысл при разборе JSON, но внутри данных нет сырой закрывающей последовательности. Это проверяемая мера конкретного сборщика, а не обещание безопасности любого способа внедрения.
Наконец, технический успех нельзя превращать в обещание поискового результата. Google прямо допускает, что правильно размеченная страница не получит расширенного представления, и отмечает ограничения автоматических проверок качества. [7] Исправный черновик означает только то, что выполнены проверенные условия; решение поисковой системы и редакционная достоверность — другие вопросы.
Частые вопросы
Нужно выбирать между NewsArticle и JSON-LD?
Какие поля обязательны?
Почему изменение может показывать более раннее местное время?
Из-за разных смещений относительно UTC. [8] В учебном примере 05:30 при +03:00 наступает позже, чем 09:00 при +07:00: это соответственно 02:30 и 02:00 UTC.
Связанные термины
Источники
- Schema.org. (n.d.). NewsArticle. https://schema.org/NewsArticle (дата обращения: 22.10.2026). ↑ а б в г д
- Google. (n.d.). Article (Article, NewsArticle, BlogPosting) structured data. Google Search Central. https://developers.google.com/search/docs/appearance/structured-data/article?content_language=English (дата обращения: 22.10.2026). ↑ а б в г д е ж з и к л м н
- Kellogg, G., Champin, P.-A., & Longley, D. (Eds.). (2020, July 16). JSON-LD 1.1. W3C Recommendation. https://www.w3.org/TR/json-ld11/ (дата обращения: 22.10.2026). ↑ а б в г д
- Google. (n.d.). Rich Results Test. Search Console Help. https://support.google.com/webmasters/answer/7445569?hl=en (дата обращения: 22.10.2026). ↑ а б
- Яндекс. JSON-LD // Справка Метрики. Б. г. URL: https://yandex.ru/support/metrica/ru/publishers/schema-org/json-ld (дата обращения: 22.10.2026). ↑ а б в г д е ж
- Goel, K., & Gupta, P. (2011, June 2). Introducing schema.org: Search engines come together for a richer web. Google Search Central Blog. https://developers.google.com/search/blog/2011/06/introducing-schemaorg-search-engines (дата обращения: 22.10.2026). ↑
- Google. (n.d.). General structured data guidelines. Google Search Central. https://developers.google.com/search/docs/appearance/structured-data/sd-policies (дата обращения: 22.10.2026). ↑ а б в г д
- Klyne, G., & Newman, C. (2002, July). Date and Time on the Internet: Timestamps (RFC 3339, §§ 4.2, 5.6). RFC Editor. https://www.rfc-editor.org/info/rfc3339/ (дата обращения: 22.10.2026; учтено обновление RFC 9557). ↑ а б
- Sharma, U., & Bormann, C. (2024). Date and Time on the Internet: Timestamps with Additional Information (RFC 9557, §§ 1–1.2). RFC Editor. https://www.rfc-editor.org/info/rfc9557/ (дата обращения: 22.10.2026). ↑
- W3C. (n.d.). JSON-LD Working Group — Publications. https://www.w3.org/groups/wg/json-ld/publications/ (дата обращения: 22.10.2026). ↑
- W3C. (2026). JSON-LD Working Group Charter. https://www.w3.org/2026/01/json-ld-wg-charter.html (дата обращения: 22.10.2026). ↑
Служебный блок
- Версия
- 3.0
- Факты проверены
- Подготовка
- Редакция Медиатрона
- Публикация
- утверждена владельцем издания 5 ноября 2026 г.
Редакция Медиатрона. Факты сверены с первоисточниками на дату проверки, публикация утверждена владельцем издания.
Нашли ошибку? info@mediatrone.ru