55

# Скил: общая логика семантической HTML-разметки для ранжирования, извлечения фактов LLM и AI-цитирования

## Цель

Этот скил задает правила, по которым HTML должен передавать смысл страницы не только браузеру и пользователю, но и поисковым системам, AI-краулерам, RAG-пайплайнам, LLM-агентам, системам answer extraction и механизмам цитирования фрагментов страницы. Семантическая разметка здесь понимается как проектирование документа через нативные HTML-сущности: границы документа, границы секций, границы сущностей, типы отношений, списки, пары термин–значение, таблицы, даты, медиа, действия, формы и цитаты.

Главный принцип: не заставлять машину угадывать смысл по CSS-классам, DOM-хаосу и визуальному положению блоков, если этот смысл можно явно закодировать в HTML.

---

## Что входит в область применения

Этот скил нужен, когда требуется:

- Улучшить смысловую прозрачность существующего HTML.
- Повысить извлекаемость ключевых фактов со страницы.
- Подготовить страницу к более точному LLM-summary и AI-цитированию.
- Снизить конкуренцию boilerplate-блоков с основным контентом.
- Повысить качество ранжирования через ясную структуру документа и сущностей.
- Делать рекомендации по семантической доразметке уже существующего контента, а не только при полной переработке шаблона.

Этот скил не про визуальный дизайн, не про CSS и не про schema-first подход. JSON-LD и микроразметка могут быть полезны, но они не заменяют нативную HTML-семантику.

---

## Базовые определения

### Семантическая разметка

Семантическая разметка — это выбор HTML-элемента по смыслу, а не по внешнему виду.

### Семантическая граница

Семантическая граница — это явный HTML-контейнер, который отделяет одну смысловую единицу от другой: документ от навигации, товар от соседнего товара, основную сущность от похожих товаров, цитату от авторского текста, атрибуты от маркетингового описания.

### Извлекаемый факт

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

### Citation-friendly блок

Citation-friendly блок — это участок HTML, который имеет:

- явную тему,
- понятный заголовок,
- компактный объем,
- чистую структуру,
- отсутствие сильного семантического шума вокруг.

---

## Главные цели семантики для SEO и LLM

### 1. Четко отделить основной контент от шаблонного шума

Машина должна отличать `main`-контент от:

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

### 2. Четко отделить сущности друг от друга

На листинге, в FAQ, в блоге, в списке отзывов, в прайс-листе и в товарном сравнении каждая единица должна иметь границы.

### 3. Сделать ключевые факты машинно-понятными

Параметры товара, услуги, статьи, кейса, вакансии или сотрудника должны быть размечены в подходящей структуре: `dl`, `table`, `ul/ol`, `time`, `data`, `figure/figcaption`.

### 4. Упростить chunking

LLM должна легко делить страницу на тематические смысловые куски, не смешивая между собой описание, условия, ограничения, отзывы, доставку, FAQ и related-блоки.

### 5. Сделать страницу удобной для точного цитирования

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

---

## Базовые проектные правила

### Правило 1. Сначала определить тип смысла

Перед выбором тега нужно определить, что это за блок:

- самостоятельная сущность,
- тематическая секция,
- навигация,
- служебный блок,
- список,
- последовательность шагов,
- таблица,
- пара “атрибут–значение”,
- цитата,
- дата,
- контакт,
- форма,
- действие,
- вложенное медиа.

### Правило 2. Один блок — одна основная роль

Если контейнер одновременно играет роль карточки товара, рекомендационного блока и навигационного узла, то машина получает смешанный сигнал.

### Правило 3. Повторяющиеся сущности должны иметь одинаковый semantic skeleton

Для каталожных карточек, FAQ-элементов, отзывов, тарифов, вакансий, кейсов и постов нужно использовать повторяемую структуру.

### Правило 4. Primary facts должны быть выше narrative текста

Если у страницы есть ключевые факты, которые пользователи и AI ищут чаще всего, их нужно располагать ближе к началу сущности и оформлять структурно.

### Правило 5. Важное не должно существовать только визуально

Если важный факт есть только в иконке, картинке, аккордеоне на JS, скриншоте, цвете, canvas-виджете или tooltip, извлекаемость падает.

---

## Реестр ключевых тегов и границы применения

## 1. Документ и метаданные

### `<html>`

Использовать как корневой элемент с корректным `lang`. Если внутри страницы есть смена языка, локально задавать `lang` на соответствующих блоках.

Использовать для:

- мультиязычных страниц,
- смешанных языковых блоков,
- локализованных карточек,
- технических терминов на другом языке,
- брендов и имен собственных.

SEO/LLM-эффект:

- снижает смешение языковых сегментов,
- улучшает точность извлечения терминов,
- полезен для международных каталогов и медиа.

### `<head>`, `<title>`, `<meta>`, `<link>`

Это не слой контентной семантики, но они задают рамку документа.

Использовать для:

- согласования `title` и темы страницы,
- canonical,
- hreflang,
- alternate,
- viewport,
- description,
- служебных связей документа.

Важно:

- `title` не должен конфликтовать с `h1`.
- Метаданные не заменяют плохую структуру `body`.

---

## 2. Landmark и sectioning

### `<main>`

Использовать для уникального основного контента страницы. Обычно один на страницу.

Сильные сценарии:

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

SEO/LLM-эффект:

- помогает отделить ядро страницы от boilerplate,
- делает extraction стабильнее,
- улучшает приоритизацию основного контента.

### `<article>`

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

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

- карточки товара,
- услуги,
- статьи,
- новости,
- кейса,
- отзыва,
- FAQ-ответа в длинной базе знаний,
- вакансии,
- автора,
- changelog-entry,
- элемента подборки,
- материала видеогалереи.

Нестандартные приемы:

- вложенные `article` для отзывов внутри страницы товара;
- вложенные `article` для отдельных кейсов внутри портфолио-хаба;
- `article` для каждой вакансии в списке;
- `article` для каждого видео в видеогалерее.

SEO/LLM-эффект:

- задает границу сущности,
- снижает смешивание соседних карточек,
- повышает шанс корректного извлечения названия, описания и атрибутов сущности.

### `<section>`

Использовать для тематических блоков, обычно с собственным заголовком.

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

- описание,
- характеристики,
- условия,
- FAQ,
- отзывы,
- состав,
- доставка,
- возврат,
- инструкции,
- шаги,
- преимущества,
- ограничения,
- кейсы,
- related content.

Хорошая практика:

- почти каждая значимая `section` должна иметь heading,
- одна секция — одна тема,
- не использовать `section` как безымянный оберточный div.

### `<header>`

Использовать как вводный блок страницы или локальной сущности.

Сильные сценарии:

- `header` у товара: название, цена, наличие, быстрые факты;
- `header` у статьи: title, автор, дата, lead;
- `header` у кейса: проблема, результат, отрасль;
- `header` у вакансии: должность, формат, локация.

Хитрый прием:

- использовать локальный `header` для entity-intro cluster — компактного пакета сигналов, по которому LLM может быстро понять сущность страницы.

### `<aside>`

Использовать для вторичного, бокового или дополнительного контента.

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

- советы,
- сопутствующие товары,
- промо,
- полезные ссылки,
- юридические пояснения,
- блок “что еще учесть”,
- related materials.

LLM-эффект:

- снижает риск, что вторичный блок будет принят за основной ответ страницы.

### `<footer>`

Использовать как глобально, так и локально — внутри статьи, карточки, кейса, вакансии, отзыва.

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

- даты обновления,
- ID,
- SKU,
- лицензии,
- служебных ссылок,
- автора,
- правовых примечаний,
- контактов сущности.

Хитрый прием:

- выносить вторичные метаданные сущности в локальный `footer`, чтобы не мешать primary facts.

### `<nav>`

Использовать для навигационных блоков.

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

- главное меню,
- breadcrumbs,
- пагинация,
- якорная навигация,
- меню раздела,
- навигация внутри аккаунта,
- вкладки, если они реально навигационные.

Хитрый прием:

- для длинных гайдов и документации делать page-nav по разделам, чтобы помочь и пользователю, и AI понять карту документа.

### `<address>`

Использовать для контактной информации автора, компании, филиала, редакции, владельца документа.

Особенно полезно на:

- странице контактов,
- странице компании,
- профилях автора,
- карточках филиалов,
- legal-страницах.

---

## 3. Заголовочная иерархия

### `<h1>`–`<h6>`

Использовать для реальной иерархии тем.

Основные правила:

- `h1` отражает основную тему или сущность страницы;
- `h2` — крупные смысловые разделы;
- `h3` — подуровни внутри `h2`;
- не использовать heading только ради размера шрифта;
- не строить пустые секции без явной темы.

Нестандартные приемы:

- называть `h2` в формате retrieval-intent, например не “Информация”, а “Условия доставки и сроки”, “Что входит в тариф”, “Совместимость и ограничения”; 
- использовать headings как карту ответов на вероятные вопросы пользователя;
- для LLM-friendly структуры каждую важную тему именовать так, чтобы ее можно было процитировать вне контекста.

---

## 4. Текстовая и блочная семантика

### `<p>`

Использовать для завершенных мыслей. Не превращать весь контент в один гигантский абзац.

### `<blockquote>`

Использовать для длинных цитат, отзывов, выдержек из стандартов, рекомендаций, официальных формулировок.

Хитрый прием:

- критичные формулировки, которые должны хорошо цитироваться AI, выносить в отдельный `blockquote` или короткую секцию рядом с источником.

### `<ol>`, `<ul>`, `<li>`

Использовать там, где контент по природе списковый.

`ol` подходит для:

- шагов,
- алгоритмов,
- последовательных процессов,
- этапов внедрения,
- процедуры заказа,
- онбординга,
- выполнения услуги.

`ul` подходит для:

- преимущества,
- ограничения,
- состав комплекта,
- совместимость,
- сценарии применения,
- требования,
- риски,
- FAQ-короткие ответы,
- атрибуты без жесткой пары имя–значение.

LLM-эффект:

- списки повышают стабильность chunking;
- помогают моделям извлекать bullet-like facts без пересборки из сплошного текста.

### `<figure>` и `<figcaption>`

Использовать для самостоятельных вложенных объектов.

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

- фото товара,
- схем,
- сертификатов,
- скриншотов,
- инфографики,
- видео,
- иллюстраций,
- диаграмм,
- интерфейсных примеров.

Хитрые приемы:

- делать `figcaption` смысловым, а не декоративным;
- для визуально сложных материалов добавлять текстовый дубль ключевых фактов рядом;
- если изображение содержит таблицу или схему, важные значения дублировать текстом или таблицей.

### `<dl>`, `<dt>`, `<dd>`

Это обязательный паттерн для пар “атрибут–значение”.

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

- характеристик товара,
- параметров услуги,
- авторских метаданных,
- кейс-метрик,
- юридических параметров,
- glossary-определений,
- quick facts panel,
- блоков “вопрос–краткий ответ”, если они по смыслу ближе к определительному формату.

Сильные сценарии:

- карточка товара: бренд, артикул, размер, вес, материал, совместимость;
- страница услуги: срок, формат, цена от, SLA, география, что входит;
- кейс: клиент, ниша, срок, объем, результат;
- профиль автора: роль, опыт, специализация;
- словарь: термин → определение.

Нестандартные приемы:

- top facts panel сразу после `h1`;
- разбиение длинных характеристик на несколько тематических `dl`;
- использование нескольких `dd` для одного `dt`, если одно свойство имеет набор значений;
- glossary-подход в экспертных статьях.

Критические ошибки:

- две визуальные колонки на `div` вместо `dl`;
- бессистемный поток характеристик без явных пар;
- один огромный `dd` с несколькими разнородными темами.

### `<table>` и связанная табличная семантика

Использовать только для реальных двумерных данных.

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

- сравнение товаров,
- прайс-листы,
- тарифы,
- матрицы совместимости,
- размерные сетки,
- SLA-таблицы,
- характеристики по моделям,
- графики платежей,
- сводные показатели кейсов.

Обязательные элементы по ситуации:

- `caption` — кратко объясняет смысл таблицы;
- `thead` — когда есть явная шапка;
- `tbody` — основные данные;
- `tfoot` — итоги/пояснения;
- `th` — заголовочные ячейки.

Хитрые приемы:

- перед таблицей давать краткий смысловой вывод;
- использовать table для сравнения только тогда, когда пользователь реально сравнивает строки и столбцы;
- не делать div-grid для табличных данных.

### `<time>`

Использовать с `datetime` там, где есть временной факт.

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

- дата публикации,
- дата обновления,
- срок акции,
- дата мероприятия,
- временное окно доставки,
- срок оказания услуги,
- актуальность условий,
- дата кейса,
- дата вакансии.

Хитрый прием:

- размечать не только дату документа, но и дату актуальности важных фактов или условий.

### `<data>`

Использовать для машинно-читаемого значения при наличии человеко-читаемой формы.

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

- SKU,
- каталожные коды,
- внутренние ID,
- числовые идентификаторы,
- короткие машинные значения.

---

## 5. Медиа и встраивание

### `<img>`

Использовать с осмысленным `alt`.

Правила:

- alt должен описывать смысл изображения в контексте блока;
- декоративные изображения не должны маскироваться под содержательные;
- вариативные изображения товара должны передавать существенное различие, если оно важно для выбора.

### `<picture>` и `<source>`

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

### `<video>`, `<audio>`, `<track>`

Использовать вместе с текстовым контекстом: заголовок, краткое описание, summary, ключевые тезисы, субтитры или дорожки.

### `<iframe>`, `<embed>`, `<object>`

Использовать осторожно. Все важные факты из встраиваемого объекта должны иметь текстовое отражение рядом.

---

## 6. Формы и интерактив

### `<form>`, `<label>`, `<input>`, `<select>`, `<textarea>`, `<fieldset>`, `<legend>`, `<button>`

Использовать для явных пользовательских сценариев.

Сильные сценарии:

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

Нестандартные приемы:

- фильтры каталога группировать через `fieldset` + `legend`;
- сложные формы разбивать на логические группы, а не на плоский список полей;
- результат расчета выводить через `output`, если это действительно вычисляемый результат;
- действия делать через `button`, переходы — через `a`.

### `<details>` и `<summary>`

Использовать для вторично-раскрываемого контента.

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

- FAQ,
- расширенные характеристики,
- юридические пояснения,
- нюансы доставки,
- свернутые инструкции,
- дополнительные условия.

Хитрый прием:

- вторичный, но важный контент лучше размещать в `details`, чем загружать по клику исключительно через JS.

### `<dialog>`

Использовать для действительно модальных сценариев, но не хранить критичный смысл только внутри модалки.

---

## 7. Inline-семантика

### `<a>`

Использовать для переходов по URL.

Хорошая практика:

- осмысленный анкор;
- понятный контекст вокруг ссылки;
- ссылки между сущностями должны передавать реальное отношение, а не быть случайной перелинковкой.

### `<strong>` и `<em>`

Использовать для логической важности и смыслового акцента.

Хитрый прием:

- выделять критичные ограничения и исключения, которые не должны потеряться при суммаризации.

### `<abbr>`

Использовать для сокращений и терминов с расшифровкой.

### `<dfn>`

Использовать при первом определении термина в глоссариях, образовательных и экспертных материалах.

### `<cite>` и `<q>`

Использовать для источников и коротких цитат.

### `<mark>`

Использовать для подсветки релевантных фраз, совпадений поиска, важных найденных терминов.

### `<code>`, `<kbd>`, `<samp>`, `<var>`

Использовать в технической документации, инструкциях, кодовых примерах, CLI-гайдах.

### `<bdi>`, `<bdo>`

Использовать на мультиязычных и RTL/LTR-смешанных страницах.

---

## Продвинутые стратегии для ранжирования и AI-цитирования

## 1. Entity-first layout

Сначала вводить сущность, затем расширять контекст.

Шаблон:

- имя сущности,
- тип/статус,
- 3–7 ключевых фактов,
- важные ограничения,
- затем развернутый narrative.

## 2. Fact pack над long-form

Перед длинным текстом размещать компактный блок фактов (`dl`, `ul`, `time`, `data`, короткая `table`).

## 3. Citation zones

Выделять критичные для цитирования блоки в отдельные секции с понятным heading.

Примеры:

- что входит,
- ограничения,
- совместимость,
- условия возврата,
- сроки оказания,
- официальное определение,
- что изменилось в версии.

## 4. Semantic redundancy без переспама

Один и тот же факт может проявляться в разных semantic-осях:

- название в `h1`,
- тип в `dl`,
- краткая суть в первом абзаце,
- актуальность в `time`.

Не повторять одну и ту же фразу трижды; подтверждать сущность разными типами структуры.

## 5. Semantic separation of noise

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

- related — в `aside`,
- служебное — в `footer`,
- навигационное — в `nav`,
- юридический хвост — в отдельный блок.

## 6. Chunk-friendly architecture

Каждая секция:

- одна тема,
- явный heading,
- короткий ввод,
- структурированный контент внутри.

## 7. Textual mirrors for visual facts

Все важное из изображений, иконок, графиков, color swatches, схем и медиа должно иметь текстовый дубль.

## 8. Temporal scoping

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

## 9. Definition strategy

На страницах, где пользователи часто ищут “что это такое”, использовать `dfn`, `dl`, сильные heading и краткое определение в начале секции.

## 10. Reviewer-friendly markup

Если страница должна хорошо анализироваться, сравниваться и цитироваться, превращать ключевую ценность в набор проверяемых fact units.

---

## Антипаттерны

- Все построено на `div/span`, а смысл живет только в классах.
- Нет `main` или он завален шумом.
- Нет границ сущностей в листингах.
- Характеристики товара сделаны как две колонки на div.
- Табличные данные сделаны на CSS-grid без table.
- Важные факты лежат только в изображении или JS-виджете.
- Primary answer страницы скрыт в табах, модалке или загружается только после взаимодействия.
- Heading-иерархия сломана или декоративна.
- CTA сделаны не через `button`, а переходы — не через `a`.
- `section` используются как пустые обертки без темы.

---

## Аудиторская модель проверки

### Уровень A. Границы документа

Проверить:

- есть ли `main`;
- корректен ли `lang`;
- согласованы ли `title`, `h1` и фактическая сущность.

### Уровень B. Границы сущностей

Проверить:

- размечены ли самостоятельные единицы как `article`;
- отделены ли вторичные блоки;
- есть ли локальные `header/footer` там, где это помогает структуре.

### Уровень C. Границы тем

Проверить:

- есть ли явные `section`;
- есть ли headings;
- не смешаны ли несвязанные темы.

### Уровень D. Машинно-извлекаемые факты

Проверить:

- используются ли `dl`, `table`, `ul/ol`, `time`, `data`, `figure/figcaption`;
- нет ли визуальных имитаций вместо смысловых элементов.

### Уровень E. AI-цитируемость

Проверить:

- есть ли компактные citation-friendly блоки;
- понятны ли ключевые определения, ограничения и условия вне контекста;
- не размыты ли важные ответы внутри длинного текста.

---

## Минимальный стандарт качества

Хорошая страница в базовом варианте должна иметь:

- `main`;
- корректную heading-иерархию;
- явные границы сущности через `article`, если это уместно;
- тематические `section`;
- `dl` для атрибутов;
- `table` для реальных табличных данных;
- `time` для временных фактов;
- `figure/figcaption` для значимых медиа;
- `nav` для навигации;
- `button` для действий и `a` для переходов;
- отделение secondary noise от primary content.

---

## Финальный принцип

Лучшая семантическая верстка для SEO и LLM — это HTML, в котором машина без гадания понимает:

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