JSON-LD: примеры разметки статьи, товара и организации

Сначала определите, что реально есть на странице и что помогает посетителю. Для услуги — исполнитель и предложение, для статьи — заголовок и действительное авторство, для товара — конкретная модель и условия продажи. Разметка должна соответствовать видимой информации и обновляться вместе с ней.

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

Примеры ниже показывают структуру данных. Названия и адреса вымышлены; они не предназначены для публикации без замены. На рабочей странице JSON помещают внутрь тега <script type="application/ld+json">…</script>; сам блок данных допустим в head или body. Если разметку уже формирует модуль сайта, сначала проверьте её, чтобы не добавить противоречащий дубль.

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://example.org/#organization",
  "name": "Пример компании",
  "url": "https://example.org/"
}

Постоянный @id позволяет другим объектам ссылаться на ту же организацию. В sameAs добавляют страницы, однозначно относящиеся к этому объекту, а не произвольные тематические ссылки.

WebSite описывает сайт как целое; WebPage — отдельную страницу, Organization — организацию. Эти объекты нельзя считать взаимозаменяемыми.

Для названия сайта в Google разметку WebSite размещают на главной странице домена или поддомена. Обязательные для этой функции свойства — name и url; адрес должен указывать каноническую главную.

{
  "@context": "https://schema.org",
  "@type": "WebSite",
  "name": "Учебный каталог материалов",
  "url": "https://example.org/"
}

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

Такая разметка помогает сообщить предпочтительное название, но Google самостоятельно выбирает его отображение. Она не гарантирует позиции, цитирование в ИИ или любую другую поисковую функцию.

Google: названия сайтов · Schema.org: WebSite.

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Как выбрать материал",
  "author": {
    "@type": "Person",
    "name": "Пример автора"
  },
  "publisher": {
    "@id": "https://example.org/#organization"
  },
  "mainEntityOfPage": "https://example.org/guide/"
}

При внедрении замените автора реальным и добавьте применимые достоверные сведения. Даты должны описывать публикацию и содержательное обновление, а не ежедневно меняться ради впечатления свежести. Требования и рекомендации к типу Article проверяют отдельно.

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Учебная модель",
  "offers": {
    "@type": "Offer",
    "price": "5900",
    "priceCurrency": "RUB",
    "url": "https://example.org/product/"
  }
}

Это иллюстрация связи Product и Offer, а не универсальная готовая разметка для всех товарных функций. Для выбранной функции проверьте полный набор требуемых свойств. Цена, наличие и условия должны совпадать с доступным предложением. Не подставляйте общий рейтинг компании в рейтинг отдельного товара.

Проверьте синтаксис JSON, затем словарь и поддерживаемую поисковую функцию. Убедитесь, что несколько модулей сайта не создают противоречащие описания одного объекта. Сопоставьте код с видимым текстом, ценой, автором и датами.

После изменения FAQ удаляйте устаревшие ответы и из разметки. Валидный код не гарантирует расширенный результат: поисковая система сама определяет отображение. Для Яндекса отдельно сверяйте поддержку формата и типа в нужной функции.

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

Документация по теме.