Как мы автоматизировали микроразметку Schema.org для блога — и какие ошибки нашли по пути

Зачем блогу микроразметка и почему в самописной CMS её нет из коробки

Микроразметка Schema.org — машиночитаемое описание страницы: кто автор, когда статья опубликована и обновлена, какая у неё обложка, где она находится в структуре сайта. Google рекомендует передавать её в формате JSON-LD — отдельным блоком <script type="application/ld+json"> в HTML страницы (правила Google).

Что разметка даёт блогу — и чего не даёт:

• Google использует разметку статьи (типы Article и BlogPosting), чтобы лучше понять страницу и точнее показать заголовок, изображение и дату в выдаче (документация Google). Валидная разметка делает страницу кандидатом на расширенный результат, но не гарантирует его показ.
• Хлебные крошки (BreadcrumbList) Google сейчас показывает в сниппете только на десктопе: в январе 2025 года их убрали из мобильной выдачи (Search Engine Land).
• Яндекс поддерживает Schema.org, но, по его справке, разметка напрямую не влияет на ранжирование (справка Яндекса). Для сниппетов Яндекс использует отдельные виды данных — например, организации, вопросы и ответы, программы, фильмы, рецепты и товары. Статей и блогов в этом списке на октябрь 2026 года нет (список Яндекса).
• В WordPress разметку генерируют плагины вроде Yoast или Rank Math. Наш блог работает на React/Next.js, и готового решения такого уровня там нет. Есть библиотеки — например, next-seo или типы schema-dts, — но их нужно подключать и настраивать в коде.

Сам блог — фронтенд, бэкенд и базу данных — мы собрали на Amazi текстовыми запросами к ИИ-агенту. Подробнее о том, как мы собираем приложения через диалог с ИИ, — в отдельной статье как мы собираем приложения через диалог с ИИ. Разметку решили сделать так же.

Шаг 1. Данные для разметки уже лежат в базе

Первым делом мы спроектировали, где хранится контент. Amazi разворачивает для проекта управляемую базу PostgreSQL. Через вкладку Database и Prisma Studio мы ведём таблицу статей: заголовки (H1 и Title), описание, ключевые слова, текстовые блоки, обложку, даты, автора и данные для аналитики.

Почти всё, что нужно для разметки BlogPosting, в этой таблице уже есть. Обязательных свойств для статей у Google нет: все свойства из таблицы ниже — рекомендуемые (документация Google). Вот как мы сопоставили поля:

В первой версии логика была такой: при сохранении статьи система собирала объект BlogPosting из этих полей и записывала готовый JSON в отдельное поле jsonLd. Это казалось удобным: разметка лежит рядом со статьёй, её видно прямо в базе. К этому решению мы ещё вернёмся в шаге 3.

Шаг 2. Генерация JSON-LD через ИИ-агента

В рабочем пространстве проекта мы открыли чат с агентом и описали задачу текстом:

Агент собрал JSON и сам внёс изменения в исходники проекта во вкладке Code: добавил в шаблон статьи вывод разметки.

Код вывода выглядит так:

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

Что здесь происходит, если вы не пишете код:

• Если данных для разметки нет, тег не выводится вовсе — пустой разметки на странице не будет.
• Используется обычный тег <script>, а не компонент Script из next/script. Так рекомендует документация Next.js: next/script предназначен для загрузки исполняемого JavaScript, а JSON-LD — это данные (документация Next.js). Разметка попадает прямо в HTML, который отдаёт сервер, и её видят даже инструменты, которые не выполняют JavaScript.
• .replace(/</g, '\\u003c') заменяет символ < на его юникод-код. Без этого текст вида </script> в заголовке статьи мог бы оборвать тег и открыть дыру для XSS-атаки. Такое экранирование тоже советует Next.js.

Проверить, что разметка попала в HTML, просто: откройте статью, нажмите Ctrl+U (на Mac — Cmd+Option+U) и найдите на странице application/ld+json.

Ниже — полный объект BlogPosting со всеми свойствами, которые рекомендует Google. Его можно взять за шаблон; значения примерные.

{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "Как мы автоматизировали микроразметку Schema.org для блога — и какие ошибки нашли по пути",
  "image": [
    "https://example.com/images/cover-16x9.jpg",
    "https://example.com/images/cover-4x3.jpg",
    "https://example.com/images/cover-1x1.jpg"
  ],
  "datePublished": "2026-10-28T10:00:00+03:00",
  "dateModified": "2026-10-28T10:00:00+03:00",
  "author": [{
    "@type": "Person",
    "name": "Имя Фамилия",
    "url": "https://example.com/authors/imya-familiya"
  }],
  "publisher": {
    "@type": "Organization",
    "name": "Amazi",
    "logo": {
      "@type": "ImageObject",
      "url": "https://example.com/logo.png"
    }
  }
}

И пример хлебных крошек. Элементов должно быть минимум два; у последнего можно не указывать item — тогда Google подставит адрес текущей страницы (документация Google).

{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    {
      "@type": "ListItem",
      "position": 1,
      "name": "Блог",
      "item": "https://example.com/blog"
    },
    {
      "@type": "ListItem",
      "position": 2,
      "name": "Как мы автоматизировали микроразметку Schema.org для блога — и какие ошибки нашли по пути"
    }
  ]
}

Шаг 3. Две ошибки после первой публикации

Идеально с первого раза не вышло. Встроенный анализатор в админке — его мы тоже собрали на Amazi — проверил DOM страницы и нашёл две проблемы.

Шаг 4. Проверка в Google и Яндексе

Google Rich Results Test. Мы отправили URL статьи на проверку. Результат: валидные элементы Articles и Breadcrumbs, ошибок в разметке BlogPosting нет, страница успешно просканирована.

Что это значит: страница может претендовать на расширенный результат, но Google не обещает его показывать — решение остаётся за поисковиком (правила Google). После индексации стоит открыть страницу ещё и в инструменте проверки URL в Search Console. Он показывает, как опубликованную страницу видит сам Google и не мешают ли ей robots.txt или noindex (документация Google).

Schema Markup Validator (validator.schema.org) сверяет разметку со словарём Schema.org целиком, а не только с типами, для которых у Google есть расширенные результаты. Полезен как второй взгляд.

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

Частые ошибки в микроразметке блога

Ошибки, на которые наткнулись мы сами, и те, что чаще всего мешают разметке статей:

• Разметка расходится с видимым текстом. Заголовок, автор или даты в JSON-LD не совпадают со страницей. Google требует размечать только то, что видит читатель (правила Google).
• Готовый JSON-LD хранится отдельно от данных. Поменяли поле статьи — разметка осталась старой. Подробно — в шаге 3.
• Даты без часового пояса или не те, что на странице. Google советует указывать время и часовой пояс в формате ISO 8601, иначе возьмёт часовой пояс Googlebot. Видимая дата на странице и дата в разметке должны совпадать (документация Google о датах).
• Лишнее в имени автора. В author.name — только имя: без должности, названия компании и слов вроде «Автор:» (документация Google).
• Логотип вместо обложки в image. В image должны быть изображения, которые представляют саму статью, и они должны быть доступны для сканирования.
• Разметка только через JavaScript. Google читает JSON-LD, который скрипт добавил при рендеринге (документация Google), но инструменты, которые смотрят только HTML, его не увидят. Надёжнее отдавать разметку в HTML с сервера.
• Ставка на FAQ-сниппеты. С 7 мая 2026 года Google больше не показывает расширенные результаты FAQ ни одному сайту (журнал изменений документации Google). Разметка FAQPage сниппета в Google уже не даст.

Что мы получили на выходе (без прикрас)

Трафик. Миллионов органического трафика пока нет: статья проиндексирована недавно.

Что получили:

• Разметку для каждой новой статьи без ручного кода. JSON-LD собирается из полей статьи автоматически.
• Два исправленных бага и урок про архитектуру. Разметку надёжнее собирать из тех же данных, что видит читатель, а не хранить отдельно.
• Новые типы разметки — задачей агенту. Если понадобится Organization для страницы «О компании» или VideoObject для статей с видео, достаточно описать задачу в чате. Результат всё равно нужно проверять валидатором: как показал шаг 3, без проверки ошибки легко пропустить.
• Исходники у нас. Amazi позволяет выгрузить фронтенд, бэкенд и базу данных в репозиторий на GitHub и развернуть блог на своих серверах.

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

Источники

• Google: Article (Article, NewsArticle, BlogPosting) structured data
• Google: General structured data guidelines
• Google: Breadcrumb (BreadcrumbList) structured data
• Google: даты публикации в выдаче
• Google: Generate structured data with JavaScript
• Google: журнал изменений документации (отключение FAQ-сниппетов, май 2026)
• Next.js: How to implement JSON-LD
• Яндекс: Вопросы о семантической разметке
• Яндекс: Какие данные можно передать
• Яндекс: Валидатор микроразметки
• Search Engine Land: несколько H1 не мешают SEO (2019)
• Search Engine Land: хлебные крошки убраны из мобильной выдачи (2025)
• PPC Land: Google отключил FAQ-сниппеты (2026)