Нейросети и 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"><main></th>
<td>Основной контент страницы</td>
</tr>
<tr>
<th scope="row"><section></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>сitemtypeSchema.org - Каждый тематический раздел — отдельный
<section>с заголовком - Иерархия заголовков логична:
h1→h2→h3, без пропусков - Таблицы с
<caption>,<thead>,<th scope="col/row">,<tbody> - Нет таблиц для визуального layout
- Данные, важные для AI-ответов, в HTML-тексте, а не только в картинках или JS
- JSON-LD
Articleили другой релевантный тип Schema.org
Семантическая вёрстка — это не оптимизация ради алгоритма, а приведение HTML в соответствие с тем, что он должен выражать. Правильно структурированная страница одновременно лучше читается скринридерами, точнее индексируется поисковиками и точнее цитируется нейросетями. Это пересечение, а не компромисс.
Если вас интересует, как структура сайта влияет на тематическую экспертность в глазах AI, — материал Topical Authority: как стать «Википедией» в своей нише закрывает эту тему с примерами контент-карт.
Источники
Footnotes
- Google Search Central — Structured Data Introduction — developers.google.com ↗ (дата доступа: 2026-06-03) ↩ ↩2
- Schema.org — schema.org ↗ (дата доступа: 2026-06-03) ↩ ↩2
- MDN Web Docs —
<main>element — developer.mozilla.org ↗ (дата доступа: 24 апр 2026) ↩ - MDN Web Docs —
<section>element — developer.mozilla.org ↗ (дата доступа: 24 апр 2026) ↩ - MDN Web Docs — Structuring documents — developer.mozilla.org ↗ (дата доступа: 25 авг 2025) ↩
- MDN Web Docs —
<table>element — developer.mozilla.org ↗ (дата доступа: 24 апр 2026) ↩ - MDN Web Docs —
<caption>element — developer.mozilla.org ↗ (дата доступа: 24 апр 2026) ↩ - MDN Web Docs —
<th>element — developer.mozilla.org ↗ (дата доступа: 24 апр 2026) ↩
