Нейросети и AI-поисковики извлекают контент из HTML так же, как краулеры и скринридеры: они читают теги, а не визуальное оформление. Когда страница собрана из <div> без смыслового контекста, модель вынуждена угадывать, где начинается основной материал, где заголовок, а где навигация. Семантические теги HTML5 — <main>, <section>, <article>, <header>, <nav>, <footer> — снимают эту неоднозначность. Не как «магический фактор ранжирования», а как сигнал структуры, который снижает вероятность неверной интерпретации.

Подробнее о том, как AI-поисковики выбирают фрагменты для ответа, читайте в Что такое чанк и как писать автономные чанки.

Зачем AI-поисковикам нужна семантическая разметка?

Однозначный контекст для любого парсера

Семантический HTML нужен, чтобы краулеры, поисковые системы, скринридеры и языковые модели могли понять структуру страницы без дополнительного анализа. Когда тег описывает смысл блока (а не его визуальный вид), любой парсер — от Googlebot до LLM — получает однозначный контекст.

Что должно произойти до structured data

Google использует structured data для понимания контента и сущностей страницы1. Schema.org предоставляет словарь схем именно для этого2. Но прежде чем structured data вообще начнёт работать, краулер должен правильно распознать, что именно на странице является основным контентом, а что — шапкой, сайдбаром или футером.

Каждый раздел — кандидат для extraction

Чем чище семантика, тем точнее происходит ранжирование фрагментов в AI-ответах — каждый раздел становится кандидатом для extraction независимо от остального содержимого страницы.

Какие теги HTML5 отвечают за структуру и что означает каждый?

Ключевые семантические элементы HTML5 закрывают разные структурные роли. Ниже — сводка по спецификации MDN:

ТегРольКогда использовать
<main>Доминирующий контент страницы по центральной теме3Один раз на страницу, основной материал
<article>Самостоятельный материал, пригодный для самостоятельного распространенияСтатья, пост, новость, карточка товара
<section>Самостоятельная тематическая секция; обычно с заголовком4Раздел внутри <article>, логически отдельная тема
<header>Вводная информация или навигация (для страницы или раздела)Шапка сайта или <article>/<section>
<nav>Блок навигационных ссылокГлавное меню, хлебные крошки, пагинация
<footer>Нижний колонтитул страницы или разделаПодвал сайта, метаданные статьи

MDN рекомендует использовать семантические элементы вместо <div> везде, где это уместно5. Это не запрет на <div> — он остаётся для чисто визуального контейнирования — но любой блок с самостоятельным смыслом заслуживает семантического тега.

Как правильно разметить таблицу, чтобы её читали нейросети?

Что делает таблицу машиночитаемой

Таблицу нейросети читают корректно, когда у неё есть <caption>, заголовки <th> с атрибутом scope и структура <thead>/<tbody>. Без этого краулер видит набор ячеек без понимания, что является параметром, а что — значением.

По спецификации MDN:

  • <table> предназначен для табличных данных; атрибут summary устарел и заменяется <caption>6
  • <caption> задаёт заголовок и описание таблицы, обеспечивает доступное имя7
  • <th> — ячейка-заголовок; связь со строками/колонками устанавливается через scope или headers8

Таблицы для вёрстки и цифры в картинках

Типичная ошибка — таблица для визуальной вёрстки (сетка без смысловых связей между ячейками) или данные, оформленные скриншотом PNG. Если цифра существует только в изображении, языковая модель её не извлечёт. Подробнее о том, как делать мультимодальный контент машиночитаемым, — в Мультимодальность: графики, таблицы и цифры, которые читает ИИ.

Пример правильной разметки таблицы:

<table>
  <caption>Семантические теги HTML5 и их назначение</caption>
  <thead>
    <tr>
      <th scope="col">Тег</th>
      <th scope="col">Назначение</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <th scope="row">&lt;main&gt;</th>
      <td>Основной контент страницы</td>
    </tr>
    <tr>
      <th scope="row">&lt;section&gt;</th>
      <td>Тематическая секция с заголовком</td>
    </tr>
  </tbody>
</table>

Как соединить семантику, structured data и Schema.org?

Структура страницы и сущности данных

Семантические теги описывают структуру страницы. JSON-LD Schema.org описывает сущности: кто автор, что это за тип контента, когда опубликовано. Оба инструмента дополняют друг друга.

Сигналы сразу на двух уровнях

Google использует structured data для понимания контента и сбора информации о сущностях1. Schema.org — это словарь с чётко определёнными типами: Article, Organization, Product, Table и другими2. Когда на странице есть <article> с itemtype="https://schema.org/Article" и внутри <header> с <time>, краулер получает сигналы сразу на двух уровнях: HTML-структуры и семантики данных.

Практический минимум для статьи:

<main>
  <article itemscope itemtype="https://schema.org/Article">
    <header>
      <h1 itemprop="headline">Заголовок статьи</h1>
      <time itemprop="datePublished" datetime="2026-06-03">3 июня 2026</time>
    </header>
    <section aria-labelledby="section-heading">
      <h2 id="section-heading">Подтема</h2>
      <p>Первое предложение — прямой ответ на вопрос заголовка.</p>
    </section>
  </article>
</main>

Такая разметка позволяет языковой модели понять: это самостоятельная статья, у неё есть дата, заголовок, и каждый <section> — отдельная тематическая единица с собственным якорем.

Какие ошибки семантической вёрстки мешают нейросетям?

Шесть распространённых проблем, которые снижают машиночитаемость страницы:

Вся статья в одном <div> — краулер не понимает, где основной контент, где шапка, а где реклама.

Заголовки ради размера шрифта<h3> используется, потому что «красиво смотрится», а не потому что это подраздел <h2>. Иерархия ломается, passage ranking теряет контекст.

Несколько <h1> без логики — по стандарту на страницу один <h1>, соответствующий основной теме. Несколько <h1> создают неоднозначность.

Таблицы для вёрстки<table> используется как сетка колонок вместо <div>/CSS. Нейросеть пытается прочитать её как данные и получает набор несвязанных ячеек.

Данные карточками без связи «параметр → значение» — характеристики товара или сравнение тарифов оформлены как блоки <div> с заголовком и текстом вместо таблицы. Семантическая связь между параметром и его значением теряется.

Нет <caption> у таблиц — краулер видит данные, но не знает, что они описывают. <caption> — это минимальный контекст, который делает таблицу самостоятельным чанком.

Как связана семантическая вёрстка с техническим GEO-аудитом?

Семантика — один из слоёв технической доступности. Полный список проверок шире: robots.txt для AI-ботов, рендеринг JS, статус-коды, canonical, скорость. Но если начать технический аудит с семантики, станет ясно: краулер вообще понимает, что на странице главное?

Команда GeoWatch включает проверку семантической структуры в GEO-аудит наряду с доступностью для AI-краулеров, корректностью structured data и читаемостью контента. Если хотите понять, как нейросети сейчас воспринимают ваш сайт — запросите аудит.

Чек-лист: семантическая вёрстка под AI-поисковики

Быстрая проверка страницы перед публикацией:

  • Один <main> с основным контентом страницы
  • Статья обёрнута в <article> с itemtype Schema.org
  • Каждый тематический раздел — отдельный <section> с заголовком
  • Иерархия заголовков логична: h1h2h3, без пропусков
  • Таблицы с <caption>, <thead>, <th scope="col/row">, <tbody>
  • Нет таблиц для визуального layout
  • Данные, важные для AI-ответов, в HTML-тексте, а не только в картинках или JS
  • JSON-LD Article или другой релевантный тип Schema.org

Семантическая вёрстка — это не оптимизация ради алгоритма, а приведение HTML в соответствие с тем, что он должен выражать. Правильно структурированная страница одновременно лучше читается скринридерами, точнее индексируется поисковиками и точнее цитируется нейросетями. Это пересечение, а не компромисс.

Если вас интересует, как структура сайта влияет на тематическую экспертность в глазах AI, — материал Topical Authority: как стать «Википедией» в своей нише закрывает эту тему с примерами контент-карт.

Источники

Footnotes

  1. Google Search Central — Structured Data Introduction — developers.google.com ↗ (дата доступа: 2026-06-03) 2
  2. Schema.org — schema.org ↗ (дата доступа: 2026-06-03) 2
  3. MDN Web Docs — <main> element — developer.mozilla.org ↗ (дата доступа: 24 апр 2026)
  4. MDN Web Docs — <section> element — developer.mozilla.org ↗ (дата доступа: 24 апр 2026)
  5. MDN Web Docs — Structuring documents — developer.mozilla.org ↗ (дата доступа: 25 авг 2025)
  6. MDN Web Docs — <table> element — developer.mozilla.org ↗ (дата доступа: 24 апр 2026)
  7. MDN Web Docs — <caption> element — developer.mozilla.org ↗ (дата доступа: 24 апр 2026)
  8. MDN Web Docs — <th> element — developer.mozilla.org ↗ (дата доступа: 24 апр 2026)