JSON-LD для сайта: как структурированные данные помогают SEO и бизнесу

JSON-LD — это формат структурированных данных, который помогает поисковым системам и другим сервисам лучше понимать, что находится на странице.

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

Например, на странице может быть написано:

Алексей Баранов
Программист, предприниматель, блогер. Основатель baranov.guru.

Человек понимает, что это автор. Поисковику можно помочь и явно описать это в структурированном виде:

{
  "@context": "https://schema.org",
  "@type": "Person",
  "name": "Алексей Баранов",
  "jobTitle": "Программист, предприниматель, блогер",
  "url": "https://baranov.guru/about/"
}

Так поисковая система получает не просто набор слов, а сущность: это человек, у него есть имя, роль и страница.

JSON-LD обычно добавляют в HTML через специальный тег:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "baranov.guru",
  "url": "https://baranov.guru/"
}
</script>

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

Важно: JSON-LD — это не «магический SEO-код». Он не заменяет нормальный контент, понятную структуру сайта, скорость загрузки, индексацию, внутренние ссылки и техническое SEO. Но он помогает убрать неоднозначность и показать поисковику, какие сущности есть на странице и как они связаны.

Для владельца бизнеса JSON-LD важен не сам по себе. Важно, что он помогает поисковым системам точнее понимать сайт: где компания, где услуга, где статья, где хлебные крошки, где вопросы и ответы, где товар, где адрес и контакты.

На практике это влияет на несколько задач.

Во-первых, структурированные данные помогают поисковой системе связать страницу с конкретной сущностью. Например, страница «Техническая SEO-оптимизация» может быть описана как услуга, статья — как публикация, главная страница — как сайт или организация, а навигационная цепочка — как BreadcrumbList.

Во-вторых, JSON-LD может помочь странице претендовать на расширенное отображение в поиске. Это не гарантия, но без корректной структурированной разметки многие rich results в принципе недоступны.

В-третьих, разметка снижает риск неправильной интерпретации страницы. Особенно на сайтах, где много похожих сущностей: услуги, кейсы, статьи, инструменты, категории, товары, специалисты, филиалы и адреса.

Для бизнеса это проявляется в более понятных сценариях:

• поисковик лучше понимает, что страница является статьёй, услугой, товаром или страницей организации;
• хлебные крошки могут отображаться аккуратнее;
• карточки контента становятся более предсказуемыми для парсеров;
• техническая SEO-команда быстрее проверяет шаблоны страниц;
• после миграции сайта проще контролировать, что важные метаданные не потерялись;
• контент, Open Graph, canonical, sitemap.xml и JSON-LD работают как единая система.

JSON-LD особенно полезен для сайтов, где SEO — это не разовая настройка, а постоянный процесс: блог, каталог, интернет-магазин, сайт услуг, база знаний, SaaS, медиа, маркетплейс или локальный бизнес с несколькими точками.

JSON-LD часто смешивают с другими терминами: микроразметка, Schema.org, structured data, rich results, расширенные сниппеты. Разберём разницу.

Structured data

Structured data — это общий термин: структурированные данные на странице. Они описывают содержимое в стандартизированном виде.

Например:

• это статья;
• это организация;
• это товар;
• это локальный бизнес;
• это вопрос и ответ;
• это навигационная цепочка;
• это видео;
• это рецепт;
• это событие.

Schema.org

Schema.org — это словарь типов и свойств. Он говорит, какие сущности можно описывать и какие поля у них бывают.

Например:

Article
BlogPosting
Organization
LocalBusiness
Product
FAQPage
BreadcrumbList
Person
WebSite
Service
SoftwareApplication

У каждого типа есть свойства: name, url, image, description, author, datePublished, address, telephone, openingHours, itemListElement и другие.

JSON-LD

JSON-LD — это формат записи. Он позволяет описывать Schema.org-данные отдельным JSON-блоком, не вмешиваясь в HTML-разметку каждого элемента страницы.

Есть и другие форматы структурированных данных: Microdata и RDFa. Но для большинства современных сайтов JSON-LD удобнее: его легче генерировать в шаблонах, валидировать, обновлять и поддерживать.

Rich results

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

Главная ошибка — думать, что JSON-LD автоматически включает красивый сниппет. Это не так.

Корректная разметка — только одно из условий. Поисковая система сама решает, показывать ли расширенный формат, и учитывает правила конкретного типа, качество страницы, доверие к сайту, запрос пользователя и внешний вид выдачи.

Не нужно размечать всё подряд. Хорошая стратегия — начать с типов, которые действительно соответствуют структуре сайта и полезны для SEO-контроля.

Organization

Organization описывает компанию, проект или бренд.

Для сайта услуг это часто базовый тип: название, URL, логотип, ссылки на соцсети, контакты. Обычно такую разметку размещают на главной странице или странице «О компании», а не копируют бездумно на каждую страницу.

Подходит для:

• корпоративного сайта;
• агентства;
• сервиса;
• личного бренда;
• студии;
• SaaS;
• проекта с понятным брендом.

LocalBusiness

LocalBusiness нужен, когда у бизнеса есть физическая точка, адрес, график работы, телефон и локальная привязка.

Подходит для:

• клиники;
• салона;
• кафе;
• магазина;
• офиса продаж;
• сервисного центра;
• локальной компании с адресом и временем работы.

Если бизнес полностью онлайн и не обслуживает клиентов по конкретному адресу, LocalBusiness может быть не лучшим выбором. В таких случаях чаще используют Organization, ProfessionalService, Service или другие типы в зависимости от ситуации.

Article и BlogPosting

Article и BlogPosting описывают статьи, новости, инструкции и материалы блога.

Для сайта с экспертным контентом это один из самых полезных типов. Он позволяет явно указать:

• заголовок;
• описание;
• изображение;
• автора;
• дату публикации;
• дату обновления;
• URL страницы;
• издателя;
• логотип;
• основную сущность страницы.

На сайте baranov.guru такой тип логично использовать для материалов в /posts/.

BreadcrumbList

BreadcrumbList описывает хлебные крошки: путь от главной страницы к текущей.

Например:

Главная → Статьи → JSON-LD для сайта

Для SEO это полезная навигационная разметка. Она помогает поисковым системам понять положение страницы в структуре сайта.

FAQPage

FAQPage описывает блок вопросов и ответов.

Но здесь важно не переоценивать эффект. FAQ-разметка должна соответствовать реальному FAQ на странице. Вопросы и ответы должны быть видимы пользователю. Не нужно добавлять скрытые вопросы только ради разметки.

Даже если поисковая система больше не показывает FAQ-расширение для большинства обычных сайтов, FAQPage всё равно может быть полезна как структурированное описание блока вопросов.

Product

Product нужен интернет-магазинам, каталогам, SaaS-тарифам и страницам продуктов, если на странице действительно есть продуктовые данные: название, изображение, описание, цена, наличие, отзывы, бренд и другие поля.

Но Product-разметка требует аккуратности. Нельзя подставлять фиктивные цены, несуществующие отзывы или данные, которых нет на странице.

Service

Service описывает услугу. Для сайтов услуг это логичный тип, но важно понимать ограничение: сам факт наличия Service не означает, что поисковик покажет отдельный rich result.

Тем не менее Service может быть полезен как семантическое описание страницы услуги, особенно если он согласован с Organization, WebSite, breadcrumbs и видимым содержимым страницы.

Ниже — упрощённые примеры. В реальном проекте поля нужно подставлять из данных страницы: CMS, базы данных, markdown-frontmatter, product feed или шаблонов сайта.

Organization

Пример для сайта компании или личного бренда:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://baranov.guru/#organization",
  "name": "baranov.guru",
  "url": "https://baranov.guru/",
  "logo": "https://baranov.guru/assets/logo.webp",
  "sameAs": [
    "https://t.me/baranov_guru"
  ]
}
</script>

Что важно:

• @id помогает ссылаться на организацию из других JSON-LD-блоков;
• url должен быть основным адресом сайта;
• logo должен открываться по абсолютному URL;
• sameAs стоит добавлять только для реальных официальных профилей.

LocalBusiness

Пример для бизнеса с физическим адресом:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "LocalBusiness",
  "@id": "https://example.com/#local-business",
  "name": "Example Clinic",
  "url": "https://example.com/",
  "image": "https://example.com/assets/clinic.webp",
  "telephone": "+7 999 123-45-67",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "ул. Примерная, 10",
    "addressLocality": "Москва",
    "postalCode": "123456",
    "addressCountry": "RU"
  },
  "openingHoursSpecification": [
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": [
        "Monday",
        "Tuesday",
        "Wednesday",
        "Thursday",
        "Friday"
      ],
      "opens": "09:00",
      "closes": "18:00"
    }
  ]
}
</script>

Не используйте LocalBusiness, если у страницы нет реального адреса, телефона и локального смысла. Для онлайн-услуг лучше подобрать более подходящий тип.

BlogPosting

Пример для статьи:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "@id": "https://baranov.guru/posts/json-ld/#blogposting",
  "mainEntityOfPage": {
    "@type": "WebPage",
    "@id": "https://baranov.guru/posts/json-ld/"
  },
  "headline": "JSON-LD для сайта: как структурированные данные помогают SEO и бизнесу",
  "description": "Понятное руководство по JSON-LD для владельцев бизнеса, SEO-специалистов и маркетологов.",
  "image": "https://baranov.guru/assets/tools/json-ld-generator/cover.webp",
  "datePublished": "2026-06-01",
  "dateModified": "2026-06-01",
  "author": {
    "@type": "Person",
    "name": "Алексей Баранов",
    "url": "https://baranov.guru/about/"
  },
  "publisher": {
    "@type": "Organization",
    "@id": "https://baranov.guru/#organization",
    "name": "baranov.guru",
    "logo": {
      "@type": "ImageObject",
      "url": "https://baranov.guru/assets/authors/avatar.webp"
    }
  }
}
</script>

Что важно для статей:

• headline должен соответствовать реальному заголовку;
• datePublished — дата первой публикации;
• dateModified — дата обновления, если материал менялся;
• author должен быть реальным автором;
• image должен быть доступен поисковому роботу;
• разметка не должна описывать другую статью или старую версию страницы.

BreadcrumbList

Пример хлебных крошек:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    {
      "@type": "ListItem",
      "position": 1,
      "name": "Главная",
      "item": "https://baranov.guru/"
    },
    {
      "@type": "ListItem",
      "position": 2,
      "name": "Статьи",
      "item": "https://baranov.guru/posts/"
    },
    {
      "@type": "ListItem",
      "position": 3,
      "name": "JSON-LD для сайта",
      "item": "https://baranov.guru/posts/json-ld/"
    }
  ]
}
</script>

Хлебные крошки должны совпадать с логикой навигации сайта. Не стоит генерировать фиктивный путь только ради разметки.

FAQPage

Пример FAQ-разметки:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "JSON-LD гарантирует расширенный сниппет?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Нет. JSON-LD помогает поисковым системам понять страницу, но не гарантирует показ расширенного результата."
      }
    },
    {
      "@type": "Question",
      "name": "Куда вставлять JSON-LD?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Обычно JSON-LD вставляют через script type=\"application/ld+json\" в head или body страницы."
      }
    }
  ]
}
</script>

Главное правило: вопросы и ответы должны быть видимы на странице. Если FAQ есть только в JSON-LD, но отсутствует в контенте, это плохая практика.

Service

Пример для страницы услуги:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Service",
  "@id": "https://baranov.guru/services/technical-seo/#service",
  "name": "Техническая SEO-оптимизация",
  "description": "Аудит индексации, sitemap.xml, robots.txt, canonical, дублей, редиректов, Open Graph, JSON-LD и технических ошибок сайта.",
  "url": "https://baranov.guru/services/technical-seo/",
  "provider": {
    "@type": "Organization",
    "@id": "https://baranov.guru/#organization"
  },
  "areaServed": {
    "@type": "Country",
    "name": "Россия"
  }
}
</script>

Service стоит использовать как аккуратное описание услуги, а не как обещание отдельного визуального блока в выдаче.

Внедрение зависит от того, как устроен сайт: CMS, конструктор, Next.js, интернет-магазин, headless CMS, статический блог или самописная система.

Но общий процесс одинаковый.

Шаг 1. Определите типы страниц

Сначала нужно понять, какие шаблоны есть на сайте.

Например:

• главная страница;
• страница «О компании»;
• страницы услуг;
• статьи блога;
• карточки товаров;
• категории;
• кейсы;
• инструменты;
• контакты;
• страницы филиалов;
• страницы FAQ.

Для каждого шаблона подбирается свой тип JSON-LD. Не нужно пытаться вставить одинаковый блок на весь сайт.

Шаг 2. Сопоставьте поля с реальными данными

Плохой подход — вручную вставить один пример из интернета и забыть.

Хороший подход — связать JSON-LD с источником данных:

• frontmatter статьи;
• карточкой товара;
• данными CMS;
• настройками сайта;
• профилем организации;
• адресами филиалов;
• breadcrumbs;
• датой публикации и обновления;
• автором;
• изображением страницы.

Если редактор меняет заголовок статьи, JSON-LD тоже должен обновиться. Если товар стал недоступен, это должно отразиться в разметке. Если страница услуги переехала, URL в JSON-LD должен поменяться вместе с canonical.

Шаг 3. Генерируйте разметку на сервере

Для SEO надёжнее, когда JSON-LD попадает в HTML сразу, а не появляется только после долгой клиентской загрузки.

На современных frontend-проектах это особенно важно. Если сайт на Next.js, Nuxt, Astro или другом SSR/SSG-стеке, JSON-LD лучше генерировать на сервере из данных страницы.

Упрощённый пример для React/Next.js:

const jsonLd = {
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  headline: post.title,
  description: post.description,
  datePublished: post.date,
  dateModified: post.updatedAt ?? post.date,
  author: {
    "@type": "Person",
    name: post.author.name,
  },
}

export function PostJsonLd() {
  return (
    <script
      type="application/ld+json"
      dangerouslySetInnerHTML={{
        __html: JSON.stringify(jsonLd).replace(/</g, "\\u003c"),
      }}
    />
  )
}

Важно экранировать символ <, чтобы снизить риск проблем при вставке JSON в HTML.

Шаг 4. Не смешивайте разные страницы

Одна из частых ошибок — когда шаблон копирует разметку с главной страницы на все URL.

Например, каждая статья получает Organization как основную сущность, каждая услуга размечается как Article, а каждая страница сайта получает одинаковый FAQPage.

Такой подход создаёт шум. JSON-LD должен описывать конкретную страницу.

Можно использовать несколько блоков JSON-LD на одной странице, если они дополняют друг друга:

• Organization — для бренда;
• WebSite — для сайта;
• BreadcrumbList — для навигации;
• BlogPosting — для статьи;
• FAQPage — для блока вопросов;
• Service — для страницы услуги.

Но между ними должна быть логика, а не набор случайных объектов.

Шаг 5. Добавьте проверку в релизный процесс

JSON-LD часто ломается не в момент первого внедрения, а позже:

• после редизайна;
• после миграции на новую CMS;
• после изменения URL;
• после переезда на Next.js;
• после изменения структуры breadcrumbs;
• после переименования полей в CMS;
• после смены CDN;
• после автоматизации обложек;
• после удаления старых страниц.

Поэтому проверку структурированных данных стоит включить в технический чек-лист вместе с sitemap.xml, robots.txt, canonical, Open Graph и статусами ответа.

Ошибки JSON-LD бывают двух типов: синтаксические и смысловые.

Синтаксические валидатор обычно находит быстро. Смысловые опаснее: код формально корректный, но описывает страницу неправильно.

Ошибка 1. Разметка не соответствует содержимому страницы

Например, в JSON-LD указаны вопросы и ответы, которых нет на странице. Или в Product-разметке есть цена, но пользователь её не видит. Или дата обновления в JSON-LD новая, а текст статьи не менялся.

Поисковая система ожидает, что структурированные данные описывают видимый контент. Если разметка живёт отдельно от страницы, это риск.

Ошибка 2. Один JSON-LD для всех страниц

Частый сценарий: разработчик добавил общий JSON-LD в layout сайта, и он появился везде.

В результате:

• главная;
• услуги;
• статьи;
• кейсы;
• инструменты;
• контакты;

получают одинаковую структурированную разметку.

Формально код есть. По смыслу — бесполезен или вреден.

Ошибка 3. Неправильный тип Schema.org

Не каждая страница должна быть Article. Не каждый бизнес должен быть LocalBusiness. Не каждая услуга должна размечаться как Product.

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

Ошибка 4. Относительные URL

В JSON-LD лучше использовать абсолютные URL:

Плохо:

{
  "url": "/posts/json-ld/",
  "image": "/assets/cover.webp"
}

Лучше:

{
  "url": "https://baranov.guru/posts/json-ld/",
  "image": "https://baranov.guru/assets/tools/json-ld-generator/cover.webp"
}

Так меньше риска, что парсер неправильно интерпретирует путь.

Ошибка 5. Несогласованность с canonical

Если canonical указывает один URL, Open Graph — второй, sitemap.xml — третий, а JSON-LD — четвёртый, сайт сам создаёт противоречие.

Проверяйте согласованность:

<link rel="canonical" href="https://baranov.guru/posts/json-ld/" />
<meta property="og:url" content="https://baranov.guru/posts/json-ld/" />

{
  "url": "https://baranov.guru/posts/json-ld/",
  "mainEntityOfPage": {
    "@id": "https://baranov.guru/posts/json-ld/"
  }
}

Ошибка 6. Невалидный JSON

JSON не терпит мелких ошибок:

• лишняя запятая в конце массива;
• одинарные кавычки вместо двойных;
• комментарии внутри JSON;
• неэкранированные кавычки в тексте;
• случайный HTML внутри строки;
• незакрытая скобка.

Плохо:

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "JSON-LD для сайта",
}

В конце последнего свойства не должно быть запятой.

Ошибка 7. Устаревшие данные

Сайт обновился, но JSON-LD остался старым:

• старый логотип;
• старый адрес;
• старая дата публикации;
• старый телефон;
• старый URL;
• старые breadcrumbs;
• удалённая картинка;
• устаревшее название услуги.

Для пользователя это может быть незаметно. Для SEO-аудита — явный сигнал, что метаданные живут отдельно от контента.

Ошибка 8. Ожидание мгновенного эффекта

JSON-LD — не кнопка «поднять позиции». Если на сайте проблемы с индексацией, дублями, скоростью, качеством страниц, внутренней перелинковкой или техническими ошибками, одна разметка не решит проблему.

Сначала нужно убедиться, что страница:

• доступна поисковым роботам;
• не закрыта в robots.txt;
• не содержит noindex;
• возвращает 200 OK;
• есть в sitemap.xml, если должна индексироваться;
• имеет корректный canonical;
• содержит полезный контент;
• нормально отображается без критичных ошибок.

Проверять JSON-LD лучше в несколько этапов. Один валидатор не заменяет смысловую проверку.

Шаг 1. Проверьте исходный HTML

Откройте код страницы и найдите:

<script type="application/ld+json">

Проверьте, что JSON-LD действительно присутствует в HTML и не появляется только после сложной клиентской логики, которую поисковый робот может не обработать вовремя.

Шаг 2. Проверьте JSON-синтаксис

Скопируйте содержимое script-блока и проверьте, что это валидный JSON.

Особенно внимательно смотрите на:

• кавычки;
• запятые;
• переносы строк;
• спецсимволы;
• HTML внутри строк;
• динамические значения из CMS.

Шаг 3. Проверьте Schema.org-структуру

Дальше проверьте, что типы и свойства используются корректно.

Для этого полезен валидатор JSON-LD или Schema.org. Он покажет, какие сущности найдены, какие поля распознаны и где есть ошибки.

Шаг 4. Сравните JSON-LD с видимой страницей

Это самый важный этап.

Проверьте:

• совпадает ли headline с заголовком статьи;
• виден ли автор на странице;
• соответствует ли дата публикации;
• доступно ли изображение;
• совпадает ли URL с canonical;
• реальные ли хлебные крошки;
• есть ли FAQ на странице;
• указан ли настоящий адрес бизнеса;
• не размечены ли скрытые или несуществующие данные.

Валидатор может не понять бизнес-смысл страницы. Это должна проверить команда.

Шаг 5. Проверьте в инструментах поисковых систем

После технической проверки используйте инструменты поисковых систем: тесты расширенных результатов, инспекцию URL, отчёты по улучшениям и ошибки в вебмастер-панелях.

Важно смотреть не только на одну страницу, а на шаблоны:

• одна статья;
• несколько статей;
• одна услуга;
• несколько услуг;
• главная;
• страница контактов;
• категория;
• карточка товара.

Если ошибка есть в шаблоне, она повторяется на десятках или тысячах страниц.

Шаг 6. Добавьте мониторинг

Для крупного сайта полезно автоматически проверять JSON-LD после релизов.

Минимальный чек-лист:

• script-блок присутствует;
• JSON валиден;
• canonical совпадает с URL в JSON-LD;
• обязательные поля не пустые;
• изображения открываются;
• даты корректны;
• breadcrumbs соответствуют структуре сайта;
• нет одинакового JSON-LD на всех страницах;
• разметка не описывает скрытый контент.

Если нужно добавить JSON-LD на одну статью или страницу, это можно сделать самостоятельно: выбрать тип, заполнить поля, вставить script-блок и проверить валидатором.

Но если сайт коммерческий, многостраничный или регулярно обновляется, JSON-LD почти всегда связан с общей технической архитектурой.

Повод смотреть глубже:

• у всех страниц одинаковая разметка;
• JSON-LD пропадает после релизов;
• CMS не даёт управлять нужными полями;
• canonical и JSON-LD указывают разные URL;
• изображения из разметки закрыты или удалены;
• статьи получают неправильные даты;
• товары содержат устаревшие цены;
• breadcrumbs не совпадают с навигацией;
• FAQ-разметка описывает скрытый блок;
• после миграции на новый frontend структурированные данные сломались;
• Search Console показывает ошибки или предупреждения;
• разработчики и SEO-команда не понимают, откуда генерируется JSON-LD.

В техническом SEO-аудите JSON-LD стоит проверять не отдельно, а вместе с другими сигналами:

• индексацией;
• sitemap.xml;
• robots.txt;
• canonical;
• редиректами;
• дублями;
• Open Graph;
• мета-тегами;
• внутренней перелинковкой;
• статусами ответа;
• JavaScript-рендерингом;
• скоростью и доступностью;
• структурой шаблонов;
• ошибками в Google Search Console и Яндекс Вебмастере.

Если сайт сделан на Next.js, headless CMS или сложном JavaScript-стеке, важно не просто вставить JSON-LD, а встроить его в генерацию метаданных. Тогда структурированные данные будут обновляться вместе с контентом, а не жить отдельным устаревшим блоком.

Короткий итог

JSON-LD нужен не для галочки.

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

Для бизнеса польза JSON-LD в том, что важные страницы становятся более понятными для машинной обработки. Это не гарантирует рост позиций и не включает rich results автоматически, но помогает убрать неоднозначность и подготовить сайт к корректному отображению в поддерживаемых поисковых форматах.

Минимум, который стоит проверить на важном сайте:

• Organization или подходящий тип для бренда;
• BreadcrumbList для навигации;
• BlogPosting или Article для статей;
• FAQPage, если на странице есть реальный FAQ;
• LocalBusiness, если есть физическая точка;
• Product, если есть реальные продуктовые данные;
• согласованность с canonical;
• доступность изображений;
• отсутствие скрытых или выдуманных данных;
• валидацию после релизов.

JSON-LD работает лучше всего не как отдельный фрагмент кода, а как часть общей системы технического SEO: вместе с sitemap.xml, robots.txt, Open Graph, canonical, нормальной архитектурой URL и качественным контентом.