Микроразметка в DLE: JSON-LD против HTML-атрибутов. Почему я выбрал JSON-LD и вам советую

Блог TCSE / Скрипты и советы | 31 июля 2026

Или: Как не сломать SEO при смене дизайна и не проклинать себя за каждый < div >



🧩 Пролог: История одного FAQ


У меня есть клиент — продавец итальянских цистерн O.ME.P.S. Для его сайта нужно было добавить FAQ-разметку. Вопросы и ответы уже были сверстаны для людей. Оставалось только «подсветить» их для поисковиков.

И я оказался перед выбором:

  • Вариант А. Добавить HTML-атрибуты прямо в существующую вёрстку (Microdata).
  • Вариант Б. Вынести всё в отдельный блок (JSON-LD).

На первый взгляд, вариант А выглядит «чище»: не нужно дублировать контент. Вопрос уже есть в HTML, ответ уже есть в HTML. Просто добавляем пару атрибутов — и готово.

Но я выбрал вариант Б. И сейчас объясню, почему.



🧨 Акт 1: HTML-микроразметка — минное поле в DLE


1.1. Хрупкость, которую вы не заметите сразу


Представьте, что вы добавили микроразметку прямо в шаблон DLE:

html
<dl itemscope itemtype="https://schema.org/FAQPage">
  <div itemprop="mainEntity" itemscope itemtype="https://schema.org/Question">
    <dt itemprop="name">Чем цистерна CM 27 отличается от CM 34?</dt>
    <div itemprop="acceptedAnswer" itemscope itemtype="https://schema.org/Answer">
      <dd itemprop="text"><p>Основное отличие — объём кузова...</p></dd>
    </div>
  </div>
</dl>


Всё работает. Google видит разметку. Все счастливы.

Через месяц дизайнер решает, что < dl > — это «не модно», и меняет его на < div > с классами. Или добавляет обёртку, чтобы «сетка была красивее». Или просто переименовывает класс, чтобы «лучше читалось».

Результат: вы нечаянно сломали вложенность itemscope. Поисковик перестал видеть разметку. Вы узнаёте об этом через 3 месяца, когда падает трафик.

Ирония: вы меняли дизайн, а сломали SEO.

1.2. Условные теги DLE — идеальный способ создать хаос


DLE даёт нам [xfgiven_xxx] и [xfnotgiven_xxx]. Это мощный инструмент, но в сочетании с Microdata он превращается в ад.

Пример:

html
<div itemscope itemtype="https://schema.org/Question">
  <dt itemprop="name">{question}</dt>
  [xfgiven_answer]
  <div itemprop="acceptedAnswer" itemscope itemtype="https://schema.org/Answer">
    <dd itemprop="text">{answer}</dd>
  </div>
  [/xfgiven_answer]
</div>


Что произойдёт, если answer пустое? itemprop="acceptedAnswer" просто не появится. Валидатор Schema.org увидит Question без ответа и выдаст ошибку. И вы об этом не узнаете, пока не зайдёте в Rich Results Test.

Вывод: Microdata в DLE — это как ходить по минному полю в тёмных очках. Один неверный шаг — и всё взрывается.



📦 Акт 2: JSON-LD — почему я люблю его (и вам советую)


2.1. Данные отдельно от представления


JSON-LD — это блок < script >, который живёт своей жизнью. Он не зависит от:

  • CSS-классов.
  • Структуры HTML.
  • Изменений в шаблонах.

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

2.2. Никаких случайных поломок


Вы просто пишете:

html
<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "Чем цистерна CM 27 отличается от CM 34?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Основное отличие — объём кузова..."
      }
    }
  ]
}
</script>


Этот JSON не сломается, если вы:

  • Удалите < dl >.
  • Переименуете класс.
  • Добавите новый < div >.
  • Решите использовать < table > для сетки.

Он просто есть. И поисковик его видит.

2.3. Простота для комплексных сущностей


Для Product с Offer, Brand и AggregateRating Microdata становится кошмаром:

html
<div itemscope itemtype="https://schema.org/Product">
  <span itemprop="name">Цистерна O.ME.P.S. CM 27</span>
  <div itemprop="offers" itemscope itemtype="https://schema.org/Offer">
    <span itemprop="price">3 200 000</span>
    <span itemprop="priceCurrency">RUB</span>
  </div>
  <div itemprop="aggregateRating" itemscope itemtype="https://schema.org/AggregateRating">
    <span itemprop="ratingValue">4.8</span>
  </div>
</div>


А если у вас 10 товаров и у каждого 5 доп. полей — это превращается в слоёный пирог из открывающихся и закрывающихся тегов. Шанс ошибиться — 99%.

В JSON-LD это просто объект в скрипте. Чисто, понятно, предсказуемо.



📊 Акт 3: Производительность — где быстрее?


Ваша гипотеза: «JSON-LD быстрее для обработки поисковиками, так как им не нужно разбирать HTML».

Это абсолютно верно.

  • Google официально рекомендует JSON-LD как предпочтительный формат. Их алгоритмы заточены на его парсинг в первую очередь.
  • Время обработки. Поисковику не нужно проходить по всему DOM-дереву, искать itemscope, проверять вложенность и извлекать данные. Он просто читает JSON-блок.
  • Обновление сниппетов. Изменения в JSON-LD видны в выдаче быстрее, чем в Microdata.

Ирония: дублирование текста в JSON-LD занимает 0.5–1 КБ трафика. Это ничтожная плата за стабильность.



🧾 Эпилог: Я выбрал JSON-LD и не жалею


Да, в JSON-LD приходится дублировать контент. Но это дублирование — инвестиция в надёжность.

  • Microdata — для тех, кто любит рисковать и проверять Rich Results Test каждую неделю.
  • JSON-LD — для тех, кто хочет один раз настроить и забыть.

Я выбрал JSON-LD. И вам советую.



P.S. Если вы всё ещё считаете, что «дублировать контент» — это плохо, вспомните, что вы дублируете < title> в < head> и < h1> в < body>. И это считается правильным. Так и здесь: JSON-LD — это «второй источник правды» для машин. 😏



Кстати, у нас есть готовые утилиты-помогаторы.
Работают прямо в веб-браузере

Вопросы и ответы → DL + JSON-LD
Превращает пары «вопрос;ответ» в HTML-список (dl) и структурированные данные для SEO.

JSON → CSV (FAQPage)
Конвертирует JSON-LD в формате FAQPage обратно в CSV для редактирования.
Перейти на сайт