Как пользоваться генератором Article Schema?
Инструмент поддерживает Article, BlogPosting и NewsArticle, поэтому подходит для корпоративных блогов, медиа, экспертных разделов и других сайтов с редакционным контентом. Генератор микроразметки Article передаёт в JSON-LD заголовок, автора, даты публикации, изображения и другие сведения, которые поисковая система может сопоставить с содержанием страницы.
Работа с генератором начинается с выбора типа материала и заполнения данных, которые уже опубликованы или будут опубликованы на странице. Не нужно добавлять сведения только ради более полного JSON-LD: структурированные данные должны совпадать с реальным содержанием статьи, именем автора, датами и доступными пользователю изображениями.
После заполнения формы генератор Article Schema формирует JSON-LD, который можно проверить, скопировать и передать разработчику или добавить через предусмотренный в CMS механизм. Перед внедрением стоит ещё раз сравнить значения в разметке с самой страницей, особенно если материал обновлялся после первой публикации.
1. Выберите тип Article Schema
Schema.org содержит общий тип Article и более конкретные варианты для отдельных видов публикаций. Выбор зависит от характера материала, а не от того, какой тип кажется сильнее с точки зрения SEO. Для корпоративной статьи обычно подходит BlogPosting, для редакционной публикации можно использовать Article, а для новости – NewsArticle.
Генератор Article Schema должен помогать выбрать максимально точный тип без искусственного усложнения структуры. Если публикация не относится к новостному контенту и не ведётся как запись блога, общий Article остаётся нормальным вариантом. Тип разметки описывает материал и не меняет его назначение для пользователя.
Article
Article подходит для информационных, аналитических и редакционных материалов, которым не требуется более узкая классификация. Например, его можно использовать для большого экспертного обзора, исследования отрасли или публикации, которая размещена в информационном разделе сайта, но формально не относится к корпоративному блогу.
Этот тип передаёт поисковой системе основные сведения о материале: название, автора, изображения, даты и другие свойства. Выбирать Article только ради более общего охвата не требуется. Если содержанию точно соответствует BlogPosting или NewsArticle, более конкретный тип обычно описывает страницу понятнее.
BlogPosting
BlogPosting предназначен для записей блога, экспертных публикаций, образовательных материалов и статей контент-маркетинга. Если компания регулярно публикует материалы в разделе /blog/, а у каждой записи есть автор, дата и отдельный URL, такой тип обычно соответствует структуре страницы.
Поисковые фразы blog post schema generator и blogposting schema generator обычно ведут к инструментам с тем же принципом работы. Пользователь вводит данные публикации, получает JSON-LD и добавляет его на страницу. При этом название раздела само по себе не определяет тип: ориентироваться нужно на реальный формат материала.
NewsArticle
NewsArticle используют для новостных и журналистских публикаций, когда страница действительно содержит новость, а не обычный информационный текст. Для такого материала особенно важны корректные даты, авторство, изображения и совпадение структурированных данных с видимой пользователю информацией.
Присвоение NewsArticle обычной статье не создаёт дополнительных преимуществ и может сделать разметку менее точной. Этот тип также не гарантирует попадание материала в Google News или блок Top Stories. Поисковые системы оценивают страницу по совокупности технических и содержательных сигналов.
2. Заполните данные статьи
После выбора типа нужно заполнить сведения, которые описывают конкретную публикацию. Основные поля генератора обычно соответствуют свойствам Schema.org и содержат заголовок, URL, автора, даты и изображения. Дополнительные поля могут передавать язык, раздел сайта, издателя или краткое описание материала.
Лучше заполнять только те данные, которые можно подтвердить содержимым страницы или другими доступными пользователю элементами сайта. Если автор неизвестен, дата обновления отсутствует или изображение недоступно поисковому роботу, вымышленные значения не сделают структурированные данные качественнее.
Заголовок и URL статьи
Свойство headline содержит название материала и должно совпадать по смыслу с заголовком опубликованной страницы. Искусственно добавлять в него дополнительные ключевые фразы ради микроразметки не требуется. Если генератор предусматривает description, описание тоже должно точно передавать содержание статьи.
URL указывают для той страницы, которую описывает объект Article. При использовании mainEntityOfPage нужно передать корректную связь между статьёй и её основной страницей. Канонический адрес публикации, URL в разметке и фактически индексируемая версия страницы не должны противоречить друг другу.
Автор материала
Свойство author помогает явно указать человека или организацию, которые отвечают за публикацию. Для экспертных материалов обычно используют тип Person, указывая настоящее имя автора и, если доступно, ссылку на его профиль, страницу редакции или другую страницу с дополнительной информацией.
Для материалов, опубликованных от имени компании, в подходящих случаях можно использовать Organization. Однако подменять реального автора названием бренда только ради заполнения поля не нужно. Если на странице указан конкретный специалист, структурированные данные должны сохранять ту же информацию.
Даты публикации и обновления
datePublished передаёт первоначальную дату публикации, а dateModified – дату последнего существенного изменения материала. Эти значения полезно различать, когда статья регулярно актуализируется, но её исходная дата остаётся частью истории публикации и отображается пользователю.
Для передачи дат используют формат ISO 8601, который однозначно читается программными системами. Не стоит менять dateModified после каждой мелкой технической правки шаблона или исправления опечатки. Поле должно отражать реальное обновление содержания, если соответствующая дата также используется на странице.
Изображения статьи
Свойство image должно вести на изображение, которое относится к содержанию публикации и доступно поисковому роботу. Лучше использовать качественную иллюстрацию или фотографию, представляющую материал, а не случайный элемент интерфейса, иконку сайта или общий логотип компании.
URL изображения должен открываться без авторизации и технических блокировок. Если для статьи используются несколько подходящих изображений, Schema.org допускает передачу соответствующего набора данных. При этом каждое изображение должно быть связано с публикацией и не противоречить тому, что видит пользователь.
Данные издателя
publisher описывает издателя материала и обычно содержит сущность Organization с названием компании или медиа. В структуру также можно добавить URL и логотип организации, если эти сведения действительно относятся к сайту и соответствуют общей информации о бренде.
Не стоит воспринимать publisher как поле, которое необходимо заполнить любой ценой. Набор используемых свойств зависит от публикации и доступных данных. Генератор должен помогать создать точную разметку, а не заставлять пользователя придумывать значения для каждого возможного свойства Schema.org.
3. Сгенерируйте JSON-LD
Когда основные поля заполнены, генератор преобразует введённые данные в структурированный объект JSON-LD. Обычно готовый результат помещается внутрь конструкции <script type="application/ld+json">, которую можно добавить в HTML страницы без изменения видимого текста статьи и её обычной разметки.
Перед копированием полезно ещё раз просмотреть значения автора, дат, URL и изображений. Если интерфейс поддерживает форматированный и минифицированный режимы, для проверки удобнее читать форматированный вариант. После изменений в форме JSON-LD желательно генерировать заново, чтобы не исправлять структуру вручную.
Формат article schema generator обычно подразумевает именно такой сценарий: заполнение формы, получение JSON-LD, проверку и последующее внедрение. Некоторые инструменты дополнительно позволяют скачать готовый .json, загрузить пример или сразу открыть результат в сервисе проверки структурированных данных.
4. Проверьте готовую разметку
Даже корректно сгенерированный JSON-LD нужно проверить после создания, а затем ещё раз после размещения на реальной странице. На этапе генерации можно обнаружить синтаксические ошибки и пропущенные свойства, но после внедрения появляются дополнительные риски: конфликт с CMS, дублирование Schema или неправильный URL.
Для проверки используют Google Rich Results Test и Schema.org Validator. После публикации полезно проверить сам URL, а не только скопированный фрагмент кода. Такой подход показывает итоговую версию страницы, которую получает поисковый робот вместе со всеми шаблонными и автоматически добавленными структурированными данными.
Как Article Schema влияет на SEO?
Структурированные данные помогают поисковой системе получить однозначные сведения о публикации, включая автора, дату, изображения и тип материала. Они не заменяют текст, техническое качество страницы, внутреннюю перелинковку или нормальную индексацию, поэтому оценивать Article Schema отдельно от остальных элементов SEO неправильно.
Article schema generator сокращает путь от данных статьи до готового JSON-LD, но результат зависит от качества исходной информации. Если в код переданы неправильные даты, вымышленные авторы или недоступные изображения, автоматическая генерация не исправит эти ошибки.
Помогает поисковой системе понять содержание страницы
Обычная HTML-страница содержит много элементов, среди которых поисковой системе приходится определять основной материал, автора, даты и отношения между сущностями. Structured data передаёт эти связи в явном виде и уменьшает неоднозначность при машинной обработке документа.
Это особенно полезно на больших сайтах, где один шаблон используется для тысяч публикаций. Единая Article-разметка помогает поддерживать одинаковую структуру данных, если CMS корректно выводит headline, author, image, datePublished и другие свойства для каждой страницы.
Может улучшить представление статьи в поиске
Корректные структурированные данные могут использоваться поисковой системой при формировании расширенного представления материалов, если страница соответствует требованиям конкретного поискового результата. Само наличие JSON-LD не означает, что расширенный формат обязательно появится для каждого документа.
Поэтому в тексте и интерфейсе генератора не стоит обещать рост CTR или получение rich results после вставки кода. Поисковая система самостоятельно решает, как показывать страницу, учитывая качество материала, доступность данных и другие факторы.
Article Schema не является прямым фактором ранжирования
Наличие Article Schema само по себе не переводит страницу выше конкурента с сопоставимым содержанием. Микроразметка передаёт дополнительные структурированные сведения и помогает поисковым системам интерпретировать материал, но не заменяет релевантность текста и качество сайта.
С практической точки зрения сначала нужно решить вопросы индексации, canonical, внутренних ссылок, контента и технических ошибок. После этого структурированные данные добавляют понятный машинный слой, который должен оставаться согласованным с итоговой версией публикации.
Нужно ли Article Schema для Top Stories?
Article-разметка не является обязательным условием попадания публикации в Top Stories. Поэтому добавлять NewsArticle ради одного этого блока или менять тип обычного материала без фактических оснований не нужно. Тип должен соответствовать содержанию страницы независимо от предполагаемого формата выдачи.
При этом корректные структурированные данные помогают поисковой системе точнее получить данные публикации. Для новостного сайта это полезная часть общей технической реализации, но результат зависит также от качества контента, доступности страницы, изображений и других факторов.
Я рассматриваю Article Schema как дополнительный слой данных для поисковой системы. Чем точнее в JSON-LD совпадают автор, заголовок, даты, изображения и другие свойства с реальной страницей, тем меньше неоднозначности при её обработке. Поэтому сначала я привожу в порядок материал и его HTML, а затем добавляю структурированные данные. Разметка должна описывать опубликованную страницу и не создавать сведения, которых пользователь на ней не видит.
Частые ошибки в Article Schema
Большинство проблем связано не с синтаксисом JSON, а с расхождением структурированных данных и реального содержимого страницы. Код может пройти базовую проверку, но при этом содержать другого автора, неправильную дату, закрытое изображение или тип публикации, который не соответствует материалу.
На проектах с CMS дополнительный риск создаёт дублирование. Один Article может формироваться темой, второй SEO-плагином, третий пользователь добавляет вручную. Перед внедрением нового генератора нужно понять, какие структурированные данные уже присутствуют на странице.
Разметка не соответствует видимому содержанию
Если JSON-LD сообщает одну информацию, а пользователь видит другую, разметка становится ненадёжной. Например, нельзя указывать другого автора, менять дату публикации или передавать изображение, которое вообще не относится к материалу и отсутствует в контексте страницы.
Перед публикацией стоит сверить headline, author, image, datePublished, dateModified и URL. Для автоматической системы такую проверку можно включить в шаблон или технический чекер, чтобы ошибки не распространялись сразу на весь раздел сайта.
Выбран неправильный тип статьи
Тип Schema выбирают по реальному формату контента. Обычное руководство компании не становится новостью после выбора NewsArticle, а статическая страница услуги не превращается в блоговую запись только из-за присутствия большого текста.
Если сомнение остаётся между общим и более специфичным типом, лучше проверить назначение страницы в структуре сайта. Корректная семантика полезнее попытки использовать более узкий вариант без фактических оснований.
Некорректные даты
Ошибки появляются, когда datePublished и dateModified перепутаны, формируются в разных часовых поясах или автоматически меняются после любого сохранения документа. В результате поисковая система получает дату, которая не соответствует редакционной истории материала.
Для CMS лучше хранить первоначальную публикацию и существенное обновление раздельно. Если дата показывается читателю, она должна совпадать с JSON-LD. Значения также следует передавать в стандартном формате, который однозначно распознаётся программными системами.
Изображение недоступно поисковому роботу
Ссылка в image должна вести на реально доступный файл. Проблемы возникают из-за закрытого CDN, временных URL, неправильных редиректов, запрета индексации или удаления изображения после обновления страницы.
Проверять нужно сам адрес файла, а не только отображение картинки в браузере редактора. Изображение также должно относиться к содержанию публикации. Случайный логотип, декоративная иконка или пустая заглушка плохо описывают материал.
Автор указан неоднозначно
Запись вроде «Admin» или «Редактор» без дополнительного контекста редко помогает понять, кто отвечает за материал. Если сайт публикует экспертный контент, лучше использовать настоящее имя автора и связанную страницу профиля с понятной информацией.
При этом нельзя создавать фиктивных специалистов только для улучшения структуры данных. Если материалы действительно выпускает редакция, нужно описывать реальную модель авторства и согласовать её с тем, что пользователь видит на странице.
На странице несколько конфликтующих Article Schema
Дубли часто появляются после подключения нового SEO-плагина или ручного внедрения JSON-LD поверх существующей разметки. Два объекта сами по себе не всегда являются ошибкой, но они должны описывать разные сущности и не противоречить друг другу.
Если один Article сообщает автора Иван, а другой – название компании, или они содержат разные даты одной публикации, структуру нужно исправить. Перед добавлением нового кода полезно проверить страницу валидатором и найти все уже существующие объекты.
В JSON-LD добавлены вымышленные данные
Нельзя придумывать авторов, даты, рейтинги, отзывы или издателей ради заполнения всех полей генератора. Structured data должна описывать существующее содержимое и реальные сущности сайта, иначе формально полный объект передаёт поисковой системе недостоверную информацию.
Лучше оставить неприменимое поле незаполненным, чем подставить случайное значение. Такой принцип особенно важен для автоматических генераторов, где один неправильный шаблон способен создать одинаковую ошибку на тысячах URL.
Что именно мы делали
Стоматология · Киев и Чернигов
+44% кликов из поиска
Домен без истории, сайт на конструкторе. Собрали семантику под услуги и оба города, переработали посадочные страницы, с нуля построили ссылочный профиль. За четыре месяца: 34,8 тыс. кликов, показы 1,32 → 1,76 млн, DR 0 → 41.
E-commerce · международный рынок
+96% кликов за два месяца
Каталог цифровых 3D-моделей. Кластеризовали семантику, перестроили хабовые страницы, закрыли дубли и ошибки индексации. Пользователи из Google 247 → 532, CTR 2,4% → 4%.
Медицинский центр · Украина
+68,75% видимости за первый месяц
Узкая видимость и малая семантика на старте. Семантика, структура посадочных, метаданные и перелинковка, постепенное усиление ссылками.
Ответы на ваши вопросы
Что такое генератор Article Schema?
Генератор Article Schema создаёт JSON-LD для страницы со статьёй по данным, которые вводит пользователь. Обычно форма содержит тип публикации, headline, автора, URL, изображение, datePublished, dateModified и сведения об издателе.
После заполнения полей article schema generator формирует готовую структуру Schema.org, которую можно скопировать и проверить валидатором. Инструмент уменьшает объём ручной технической работы, но пользователь всё равно должен проверить достоверность введённых данных.
Чем Article отличается от BlogPosting?
Article является общим типом для редакционных и информационных публикаций, а BlogPosting точнее описывает отдельную запись блога. Оба типа могут содержать автора, изображения, даты и другие похожие свойства.
Если материал опубликован в корпоративном или экспертном блоге как отдельная запись, обычно логично выбрать BlogPosting. Для публикации другого редакционного формата можно использовать общий Article, если более специфический тип не соответствует содержанию.
Когда нужно использовать NewsArticle?
NewsArticle используют для материалов, которые действительно являются новостями или журналистскими публикациями. Такой тип подходит интернет-СМИ, редакционным новостным разделам и другим страницам, где событие освещается в формате самостоятельного новостного материала.
Использовать NewsArticle для обычного SEO-текста, инструкции или корпоративной статьи без новостного контекста не нужно. Выбор этого типа также не гарантирует попадание публикации в Top Stories или Google News.
Какие поля нужно заполнить в Article Schema?
Для большинства публикаций полезно указать headline, author, image, datePublished и при наличии существенных обновлений dateModified. Дополнительно можно передать description, publisher, articleSection, inLanguage, mainEntityOfPage и другие применимые свойства.
Фиксированного универсального набора, который нужно заполнять любой ценой, нет. Разметка должна содержать достоверные данные конкретной страницы. Если свойства нельзя подтвердить содержанием сайта, придумывать значение только ради заполненной формы не следует.
Куда вставлять готовый JSON-LD?
Готовый JSON-LD добавляют в HTML страницы внутри <script type="application/ld+json">. На сайтах с CMS код лучше выводить автоматически через шаблон публикации, чтобы данные обновлялись вместе с автором, изображением, URL и датами.
После внедрения нужно проверить именно опубликованную страницу, поскольку тема или SEO-модуль могут уже выводить собственную разметку. Такая проверка помогает вовремя найти дубли и противоречащие друг другу объекты Article.
Как проверить Article Schema?
Для технической проверки можно использовать Google Rich Results Test и Schema.org Validator. Первый помогает увидеть структурированные данные в контексте поддерживаемых Google поисковых возможностей, а второй проверяет общую структуру типов и свойств Schema.org.
После публикации нужно протестировать реальный URL, а не только отдельный JSON-LD. Для индексируемой страницы также можно использовать URL Inspection в Search Console и убедиться, что Google получает актуальную версию документа.
Помогает ли Article Schema повысить позиции в Google?
Само присутствие Article Schema не гарантирует повышение позиции страницы. Structured data помогает поисковой системе точнее определить свойства публикации, но ранжирование зависит от содержания, релевантности, технического состояния сайта, ссылок и других сигналов.
Поэтому генератор микроразметки Article нужно использовать как часть технической настройки страницы. Если материал закрыт от индексации, имеет дубли или слабое содержание, добавление корректного JSON-LD не решит эти проблемы самостоятельно.
Можно ли использовать Article Schema вместе с другой микроразметкой?
На одной странице можно использовать несколько подходящих типов Schema.org, если каждый объект соответствует реальному содержанию. Например, статья может одновременно иметь Article, хлебные крошки BreadcrumbList и данные организации Organization.
При этом объекты не должны противоречить друг другу или дублировать одну сущность с разными значениями. После добавления нескольких типов лучше проверить итоговую страницу целиком и убедиться, что связи между сущностями сформированы корректно.
Смежные услуги
Генератор Organization Schema
Бесплатный генератор Organization Schema: создайте JSON-LD разметку компании, добавьте название, логотип, адрес, контакты и sameAs, скопируйте код и проверьте его валидность.
Генератор BreadcrumbList Schema
Breadcrumb Schema Generator для создания JSON-LD разметки BreadcrumbList. Добавьте названия и URL, получите готовый код и проверьте его для Google.
Генератор Product Schema
Product Schema Generator онлайн: создайте JSON-LD микроразметку товара с ценой, наличием, брендом, рейтингом и Offer. Скопируйте код и проверьте его перед публикацией.
Article Schema полезна там, где страница действительно содержит самостоятельную публикацию и поисковой системе нужно передать её свойства в структурированном виде. Выбор между Article, BlogPosting и NewsArticle зависит от формата материала, а качество разметки определяется точностью автора, дат, изображений, URL и других данных.
Используйте генератор Article Schema, заполните только достоверные сведения, проверьте готовый JSON-LD и протестируйте опубликованный URL после внедрения. Для большого сайта перенесите проверенную структуру в шаблон CMS, чтобы разметка обновлялась вместе с каждой публикацией и не требовала ручной поддержки.
Отвечаем в течение рабочего дня. Без рассылок и звонков «просто напомнить».
Посмотрит сайт сам, а не передаст менеджеру.
Подробнее: Генератор Article Schema
Что такое Article Schema?
Article Schema – тип структурированных данных Schema.org для описания статей и других редакционных материалов. Разметка передаёт содержимое страницы в машиночитаемой структуре, где отдельно обозначаются заголовок, автор, изображения, даты публикации, дата обновления и связанные сведения.
Названия article json ld generator, article markup generator и article structured data generator обычно обозначают один класс инструментов. Они помогают собрать Article-разметку без ручного написания JSON-LD. Генератор микроразметки Article сокращает техническую работу, но содержание полученного кода всё равно нужно проверять перед внедрением.
Как Article Schema связана со Schema.org?
Schema.org содержит общий словарь типов и свойств, которыми сайты могут описывать сущности в структурированном виде. Article входит в этот словарь и имеет более конкретные дочерние типы, среди которых для обычных сайтов чаще всего встречаются BlogPosting и NewsArticle.
Свойства вроде headline, author, image, datePublished и dateModified дают однозначные обозначения данным публикации. Поисковая система может использовать такую информацию при обработке страницы. При этом Schema.org описывает структуру данных шире, чем требования конкретной поисковой системы.
Что такое JSON-LD?
JSON-LD – формат передачи связанных структурированных данных на основе JSON. На веб-странице такой код обычно размещают внутри тега <script type="application/ld+json">, поэтому разработчику не требуется добавлять свойства Schema.org непосредственно в каждую часть видимой HTML-разметки.
Этот формат удобен для автоматической генерации, CMS и серверного рендеринга. Разметку можно создать отдельно, проверить валидатором и затем вывести в шаблоне статьи. JSON-LD должен оставаться доступным поисковому роботу и описывать ту же информацию, которую пользователь получает при просмотре страницы.
Чем Article Schema отличается от обычной HTML-разметки?
HTML определяет структуру документа для браузера и пользователя: заголовки, абзацы, ссылки, изображения и другие элементы страницы. Например, тег H1 показывает основной заголовок документа, а элемент <img> выводит изображение, которое пользователь видит внутри статьи.
Article Schema добавляет машиночитаемое описание самой сущности публикации. Она явно связывает заголовок с headline, автора с author, а дату с datePublished. Обычный HTML и структурированные данные работают параллельно, поэтому JSON-LD не заменяет правильную структуру страницы и не исправляет слабый контент.
Article, BlogPosting и NewsArticle – в чём разница?
Три типа относятся к одному семейству Schema.org, но описывают разные форматы публикаций. Общий Article подходит для широкого круга материалов, BlogPosting точнее описывает запись блога, а NewsArticle предназначен для новостного и журналистского контента.
Выбор лучше делать по фактическому назначению страницы, а не по названию ключевого запроса или предполагаемому SEO-эффекту. Если публикация соответствует более специфическому типу, его использование делает данные понятнее и снижает вероятность смыслового расхождения между JSON-LD и видимой частью документа.
| Тип Schema | Для какого контента подходит | Типичный пример | Когда выбирать |
|---|---|---|---|
| Article | Информационные и редакционные материалы | Аналитический обзор отрасли | Когда более точный тип не требуется |
| BlogPosting | Записи блога и экспертные публикации | Статья в корпоративном блоге | Когда материал является отдельной записью блога |
| NewsArticle | Новости и журналистские публикации | Новость интернет-издания | Когда страница действительно относится к новостному контенту |
Схема выбора может выглядеть так:
Публикация
│
├── Запись блога ─────────> BlogPosting
│
├── Новостной материал ────> NewsArticle
│
└── Другой материал ──────> Article
Когда использовать Article?
Article подходит для публикаций, которые имеют редакционную или информационную природу, но не относятся напрямую к формату блога или новости. Это может быть отраслевой обзор, большой экспертный материал, исследование или публикация в информационном разделе корпоративного сайта.
Использование общего типа нормально, если более узкий тип не описывает материал точнее. Не нужно выбирать NewsArticle для обычного руководства или BlogPosting только потому, что статья регулярно обновляется. Семантика Schema должна следовать содержанию конкретной страницы.
Когда использовать BlogPosting?
BlogPosting стоит выбирать для записей блога, где публикация имеет отдельный URL, автора, дату и место в общей структуре материалов сайта. Такой формат часто используют корпоративные блоги, образовательные платформы, SaaS-компании, агентства и экспертные проекты.
Если пользователь ищет blog post schema generator, ему обычно нужен готовый JSON-LD именно для такого формата. Генератор должен передать данные публикации без изменения их смысла и помочь сохранить одинаковую структуру разметки для разных статей одного раздела.
Когда использовать NewsArticle?
NewsArticle соответствует новостным материалам и журналистским публикациям, для которых дата выхода и авторство являются частью редакционного контекста. Страница должна действительно выполнять новостную функцию, а данные в Schema должны совпадать с информацией, опубликованной для читателя.
Разметка NewsArticle сама по себе не обеспечивает попадание в новостные блоки Google. Поэтому менять тип обычной статьи ради Top Stories бессмысленно. Корректная классификация снижает неоднозначность данных, но поисковая видимость зависит от качества страницы и других сигналов.
Какие данные можно добавить в Article JSON-LD?
Набор свойств зависит от типа материала, структуры сайта и фактически доступной информации. Для большинства публикаций полезно передать заголовок, автора, изображение и даты, а при необходимости дополнить объект описанием, языком, рубрикой, издателем и связью с основной страницей.
Google не требует фиксированный универсальный набор обязательных свойств для каждой Article-разметки. Поэтому лучше добавлять применимые и достоверные данные, чем заполнять поля формально. Генератор Article Schema должен помогать пользователю собрать понятную структуру без вымышленных значений.
Основные свойства статьи
К основным данным относятся свойства, которые чаще всего можно однозначно сопоставить с видимой частью публикации. Они помогают поисковой системе понять, как называется материал, кто его подготовил, когда он появился и какие изображения непосредственно связаны с его содержанием.
При автоматическом внедрении эти поля лучше получать из CMS, чтобы значения обновлялись вместе со статьёй. Ручной JSON-LD требует дополнительного контроля после каждого изменения страницы, особенно если редактор меняет автора, изображение или дату последнего существенного обновления.
headline
headline содержит заголовок публикации и должен передавать его без искусственных добавлений ради SEO. В большинстве случаев значение можно брать из основного заголовка материала или соответствующего поля CMS, если оно не расходится с тем, что пользователь видит на странице.
Не следует превращать headline в отдельный SEO-Title с дополнительными ключевыми словами, городами и коммерческими модификаторами. Если название материала изменилось, JSON-LD тоже нужно обновить, иначе поисковая система получит разные версии одного и того же элемента.
author
author указывает автора публикации и может ссылаться на сущность Person или Organization. Для экспертного материала полезно передавать реальное имя специалиста и URL его страницы, если на сайте существует полноценный профиль с информацией об авторе.
Если публикацию подготовила редакция, структура зависит от того, как авторство отображается на сайте. Не стоит создавать человека, которого пользователь нигде не видит. Разметка должна повторять реальные редакционные данные, а не заполняться исключительно ради полноты JSON-LD.
image
image связывает публикацию с изображением, которое представляет её содержимое. Для статьи обычно подходит основная иллюстрация, фотография или другое графическое изображение, используемое непосредственно в материале и доступное по стабильному URL.
Файл не должен быть закрыт через robots.txt, авторизацию или временную ссылку. При обновлении главной иллюстрации желательно одновременно менять значение в структурированных данных. Использование логотипа вместо изображения статьи снижает точность описания сущности.
datePublished
datePublished содержит первоначальную дату публикации материала. Если статья впервые появилась 10 марта, а затем была существенно дополнена в июне, первая дата должна сохраняться как дата публикации, если редакционная политика сайта отображает её пользователю.
Для автоматизированного сайта это значение лучше брать из постоянного поля CMS, которое не меняется при обычном редактировании. Такой подход исключает ситуацию, когда каждое сохранение документа случайно создаёт новую дату первой публикации.
dateModified
dateModified отражает дату последнего существенного обновления содержания. Её можно менять после добавления новых данных, переработки разделов, изменения выводов или другой правки, которая действительно влияет на опубликованный материал.
Не следует обновлять поле после изменения цвета кнопки, системного шаблона или исправления одной опечатки. Если дата обновления отображается пользователю, значение JSON-LD должно ей соответствовать. Для передачи даты лучше использовать стандартный формат ISO 8601.
Дополнительные свойства
Дополнительные свойства помогают точнее описать контекст публикации, но их наличие зависит от конкретной страницы. На одном сайте может быть полезен articleSection, на другом – inLanguage или publisher, а часть данных может уже передаваться через связанные сущности Organization и WebSite.
Добавлять каждое доступное свойство Schema.org без необходимости не требуется. Чем сложнее JSON-LD, тем труднее контролировать его согласованность с реальным содержанием страницы. Рабочая разметка должна оставаться понятной и предсказуемой при последующих обновлениях.
description
description содержит краткое описание содержания статьи. Его можно формировать из фактического анонса материала или отдельного поля CMS, если текст точно соответствует публикации и не создаёт новый смысл, которого нет в основном документе.
Description в Schema и HTML meta description могут совпадать, но такое совпадение не является обязательным техническим условием. Оба текста должны корректно описывать страницу. Искусственное перечисление ключевых запросов внутри свойства ухудшает читаемость данных.
articleSection
articleSection помогает указать рубрику или тематический раздел, к которому относится материал. Для блога это может быть SEO, аналитика, разработка, маркетинг или другая реально существующая категория сайта, используемая в навигации и структуре публикаций.
Не стоит создавать отдельное значение только для структурированных данных, если такой рубрики нигде больше нет. При масштабном контентном проекте articleSection удобно формировать автоматически из категории статьи, чтобы Schema оставалась одинаковой для всех публикаций раздела.
inLanguage
inLanguage обозначает язык материала и особенно полезен для сайтов с несколькими языковыми версиями. Значение должно соответствовать фактическому языку страницы, а не языку интерфейса браузера или географическому региону посетителя.
Для мультиязычного сайта каждая локализованная публикация должна получать собственный корректный язык вместе со своим URL и текстом. Это свойство не заменяет hreflang, потому что hreflang решает другую задачу и связывает альтернативные языковые версии URL.
mainEntityOfPage
mainEntityOfPage показывает связь Article с основной страницей, на которой опубликован материал. Свойство помогает явно указать, что описываемая статья является главным объектом конкретного документа, а не второстепенным элементом внутри другой страницы.
При заполнении нужно использовать правильный URL самой публикации. Не следует указывать главную страницу сайта, категорию блога или адрес другого материала. Для канонической страницы данные должны оставаться согласованными с canonical и фактической индексацией URL.
publisher
publisher передаёт данные издателя публикации. На корпоративном сайте это обычно организация, которой принадлежит ресурс, а в интернет-медиа – редакция или компания, выпускающая материал. Для сущности можно использовать название, URL и доступный логотип.
Значения лучше связывать с общей информацией Organization, которая уже используется на сайте. Если название компании в шапке, Organization Schema и Article publisher различается без причины, такая структура создаёт ненужную неоднозначность.
keywords и wordCount
keywords может описывать тематические понятия материала, а wordCount – объём текста в словах. Эти свойства относятся к дополнительным данным и не должны использоваться как способ передать поисковой системе список продвигаемых ключевых запросов.
Если CMS умеет рассчитывать wordCount автоматически, значение можно формировать при публикации или обновлении материала. Ручной подсчёт быстро устаревает после редакторских правок. Keywords тоже лучше использовать только при наличии понятного источника данных.
Как добавить Article Schema на сайт?
Способ внедрения зависит от CMS и архитектуры проекта. Для нескольких отдельных материалов JSON-LD можно добавить вручную, но на большом сайте безопаснее формировать разметку из полей статьи автоматически. Тогда данные автора, URL, изображения и даты обновляются вместе с самой публикацией.
Перед массовым внедрением стоит проверить шаблон на нескольких типовых страницах. Отдельно нужно убедиться, что сайт уже не выводит Article Schema через SEO-плагин, тему или другой модуль, иначе новый код может создать второй объект с противоречивыми значениями.
Вставка JSON-LD в HTML
Готовая разметка размещается внутри тега <script type="application/ld+json">. Поисковый робот должен получить этот код вместе со страницей и иметь доступ ко всем URL, которые указаны внутри объекта, включая изображения, профиль автора и адрес самой публикации.
Ручная вставка подходит для небольшого количества страниц, но требует контроля после каждого изменения материала. Если редактор обновил автора или главную иллюстрацию, а JSON-LD остался прежним, структурированные данные начинают расходиться с реальной страницей.
Добавление через CMS
На сайте с большим количеством публикаций лучше создавать Article Schema автоматически из полей CMS. Заголовок можно брать из названия материала, автора – из профиля пользователя, изображение – из основного media-поля, а даты – из системных значений публикации и обновления.
Такой подход уменьшает количество ручных ошибок и лучше переживает масштабирование контента. При изменении шаблона разработчик правит один механизм генерации вместо сотен страниц. При этом каждое поле нужно проверять на наличие значения, чтобы CMS не выводила пустые свойства.
Article Schema на SSR-сайтах
Для Next.js, Nuxt и других SSR-решений удобно формировать JSON-LD одновременно с серверной HTML-страницей. Поисковый робот получает структурированные данные сразу при загрузке документа, без зависимости от дополнительного пользовательского действия или сложной клиентской логики.
На многоязычном проекте генератор должен учитывать язык, URL и данные конкретной локализации. Русская, украинская и английская версии одной статьи могут иметь разные headline, description и URL автора, поэтому значения нельзя без проверки копировать между локалями.
Как проверить Article Schema после генерации?
Проверять нужно сначала сам код, а затем опубликованную страницу целиком. Отдельный JSON-LD может быть синтаксически правильным, но после внедрения сайт способен вывести второй Article, изменить URL или подставить данные из другого шаблона, которые не были видны в генераторе.
Для полноценной проверки полезно сочетать несколько инструментов. Google Rich Results Test показывает данные в контексте поддерживаемых поисковых возможностей, Schema.org Validator проверяет структуру по словарю Schema.org, а Search Console помогает анализировать уже доступную Google страницу.
Google Rich Results Test
Google Rich Results Test подходит для проверки структурированных данных, которые используются Google в поддерживаемых форматах поисковой выдачи. В инструмент можно передать опубликованный URL или код, после чего проверить найденные сущности, ошибки и предупреждения.
Предупреждение не всегда означает, что страница технически сломана, поэтому каждое сообщение нужно читать в контексте конкретного свойства. После внедрения лучше тестировать реальный URL, поскольку он показывает фактическую страницу вместе с шаблонной разметкой сайта.
Schema.org Validator
Schema.org Validator помогает проверить структуру объекта по общему словарю Schema.org. Такой анализ полезен, когда нужно увидеть типы и свойства вне ограничений конкретных rich results Google или проверить сложный объект с несколькими связанными сущностями.
Валидатор не оценивает качество самого текста и не проверяет достоверность автора, дат или издателя. Поэтому отсутствие технической ошибки ещё не означает, что разметка содержательно корректна. Значения нужно отдельно сравнивать с реальной страницей.
Проверка опубликованной страницы
После размещения JSON-LD нужно открыть итоговый URL и проверить исходный HTML, структурированные данные и доступность связанных ресурсов. Для уже индексируемого материала дополнительно можно использовать URL Inspection в Google Search Console и посмотреть, доступна ли Google актуальная версия страницы.
Проверка особенно нужна после изменения CMS, шаблона или SEO-модуля. Обновление сайта способно добавить вторую Schema или удалить часть полей без видимой ошибки на странице, поэтому периодический технический контроль помогает находить такие проблемы раньше.
Для каких страниц подходит Article Schema?
Article Schema подходит для страниц, где основной сущностью действительно является самостоятельная публикация с заголовком, содержанием и редакционным контекстом. Обычно это статьи блога, новости, исследования, экспертные материалы, аналитические обзоры и образовательные публикации.
Перед внедрением стоит определить тип каждой группы URL, чтобы не распространять Article на страницы, которые относятся к товарам, категориям или услугам. Генератор разметки удобнее использовать после такой классификации, поскольку сама форма не определяет назначение документа.
Чаще всего Article-разметка подходит для следующих страниц:
- статей корпоративного или экспертного блога, где есть отдельный автор и дата публикации;
- новостных материалов, которые выпускаются редакцией и относятся к текущим событиям;
- исследований, аналитических обзоров и содержательных отраслевых публикаций;
- образовательных материалов, инструкций и руководств, если основная сущность страницы остаётся статьёй;
- редакционных обзоров, где содержание оформлено как самостоятельная публикация, а не карточка товара.
Для других типов страниц нужно сначала проверить, существует ли более подходящая сущность Schema.org. Такое разделение помогает избежать ситуации, когда одна разметка механически применяется ко всему сайту.
Обычно Article не стоит использовать для следующих документов:
- главной страницы, где основным объектом является сайт или организация;
- категории блога или каталога, содержащей список нескольких материалов;
- карточки товара, для которой основным объектом выступает Product;
- страницы контактов или информации о компании;
- коммерческого лендинга услуги, если он не является самостоятельной редакционной публикацией.
После классификации можно настроить автоматический вывод Schema на уровне шаблонов. Тогда генератор Article Schema понадобится для проверки структуры, тестовых страниц или проектов, где автоматическая микроразметка пока не настроена.