Выбор типа
Для обычной статьи подходит Article или BlogPosting, для новостного материала — NewsArticle. Выбирайте тип по реальному содержанию страницы, а не по URL каталога или наличию FAQ.
Заголовок и описание
headline должен соответствовать заголовку публикации. description может быть кратким анонсом или meta description, если он действительно описывает материал. Не подставляйте навигационный текст или заголовок сайта вместо статьи.
{
"@context": "https://schema.org",
"@type": "Article",
"name": "Article example"
}
Автор
author обычно оформляется как Person или Organization. Если в существующем JSON-LD уже есть author.name, анализатор должен использовать его раньше DOM-эвристик. Отсутствующего автора не следует придумывать.
Даты
datePublished — дата первой публикации, dateModified — дата последнего значимого обновления. Лучше использовать ISO 8601 с часовым поясом. Дата в JSON-LD должна совпадать с информацией, которую видит пользователь.
Publisher и изображение
publisher удобно связывать через @id с общей Organization. image должен вести на основное изображение публикации, а не на favicon или рекламный баннер.
Связи в @graph
В хорошем графе Organization и WebSite являются общими сущностями, а Article/BlogPosting — основной сущностью текущей страницы. mainEntityOfPage может ссылаться на WebPage, а publisher — на Organization.
Чего не должно быть
Article не должен получать ошибки Product за отсутствие цены, SKU или наличия. FAQPage может существовать рядом как дополнительная сущность, но не меняет основной тип материала.
Частые вопросы
Можно ли автоматически довести Schema до 100%?
Только если необходимые данные реально присутствуют в исходном JSON-LD или на странице. Сервис не должен придумывать цену, автора, рейтинг, адрес или другие значения.
Нужно ли добавлять все возможные свойства Schema.org?
Нет. Лучше передать меньше достоверных полей, чем заполнить схему нерелевантными или выдуманными значениями.