# Семантика и семантический кокон: как группировать запросы и связывать страницы

**Для человека:** как превратить список запросов в структуру сайта без страниц-конкурентов друг другу и как устроить
перелинковку блога вокруг хабов. Дай файл нейронке на фазах 4 и 5 из SAYT.md (спрос и архитектура): «Группируй запросы и
проектируй структуру блога по 08-semantika-i-kokon.md». Готовый промпт для разведки сущностей — в разделе 7, подставь тему.

---

## 1. Смыслы вместо частотности

Старая школа строила структуру от частотности: у фразы большая частота — делаем отдельную страницу. В 2026 это плодит
страницы, которые дерутся между собой за один и тот же смысл (каннибализация).

Google давно считает не слова, а **сущности** — объекты из своего графа знаний. За связку текста с сущностями отвечает
атрибут `EntityAnnotations`. Поэтому две фразы с разной частотой, но **одним намерением**, объединяем в одну страницу,
а не плодим конкурентов.

**Быстрый способ:** Wordstat → чистка → кластеры по смыслу (через нейронку) → фразовая частотность + LSI-слова + интент →
структура сайта + бэклог тем. Контролируй 10 кластеров глазами. Этого достаточно, чтобы начать.

### Цепочка, по которой запрос становится страницей

```
задача пользователя → тип страницы → маркеры → Wordstat (регион + устройство)
→ выдача по нужному региону → КАНДИДАТ в кластер → проверка текущих URL сайта
→ решение о странице → источники → контент-план
```

**Кластер ≠ страница.** Wordstat показывает **спрос**. Эмбеддинги и лексическая близость — **похожесть формулировок**. Ни то,
ни другое не доказывает, что запросы ведут на одну страницу. В одном кластере спокойно оказываются разные интенты: колледж
и вуз, инструкция и услуга, выбор товара и цена, общий вопрос и локальный запрос.

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

## 2. QBST: у Google есть чек-лист понятий

Инженер Google на суде назвал систему QBST «системой запоминания»: она по триллионам запросов запомнила, какие термины
встречаются в **исчерпывающем** ответе на тему. Проще говоря, у Google есть чек-лист понятий, которые он ждёт увидеть в
хорошей статье.

**Как под это писать:**

- Смотри топ-5–7 конкурентов, выписывай их общие подзаголовки, специфические термины, вопросы из блока «Люди также спрашивают».
- Это и есть чек-лист ожидаемых понятий.
- Ищи не то, что есть у конкурентов, а то, чего у них **нет**, но что система ждёт. Добавляй микроабзац на 3–5 предложений.

QBST прозвучал в показаниях под присягой. Он оценивает **наличие понятия**, а не глубину: иногда один абзац по недостающей
подтеме весит больше, чем ещё 1000 слов воды.

## 3. Что такое семантический кокон

Кокон — это не набор отдельных страниц, а **герметичный тематический кластер**, который исчерпывающе закрывает одну большую
тему. Google видит такую плотность и отдаёт «топикальную власть» — авторитет по всей теме. Аналогия: сайт — библиотека,
кокон — герметичный зал, где каждая книга, сноска и каталог работают на раскрытие одной темы.

## 4. Три уровня кокона

| Уровень | Роль | Сколько |
|---|---|---|
| **1. Целевая (хаб темы)** | Центральная страница раздела под самый широкий запрос темы. Точка входа: с неё видно, из чего тема состоит | 1 на кокон |
| **2. Промежуточные** | Уточняют тему, ведут от общего к конкретике. Пример для «кофемашины»: «Рожковые», «Автоматические», «Рейтинг 2026» | 4–6 |
| **3. Опорные** | Узкие ответы на длинный хвост: «давление в бойлере 9 бар», «декальцинация лимонной кислотой». Здесь максимум сущностей | 5–15 на каждую промежуточную |

URL отражает иерархию: `/kokon/podkategoriya/opornaya-stranica/` — Google быстро считывает уровни.

## 5. Перелинковка внутри кокона

Скелет у кокона есть: узкие страницы ссылаются вверх на свою тему, хаб ведёт вниз на разделы — так и читателю, и
поисковику видно, что раздел цельный. Но это скелет, а не закон физики.

**Чего мы не утверждаем.** Жёсткая пирамида «вес всегда движется вверх, всё работает на главную страницу темы,
горизонтальные переходы запрещены» не имеет доказательств, а на практике ломает навигацию. **Хорошая контекстная ссылка —
та, что естественно продолжает путь читателя.** Связанные страницы могут ссылаться друг на друга, в том числе из разных
коконов, если это помогает решить следующий вопрос.

| Тип связи | Куда ведёт | Зачем |
|---|---|---|
| Вверх, к хабу | опора → промежуточная → целевая | Показывает, к какому разделу относится страница |
| Вниз, от хаба | сверху вниз | Навигация: объясняет структуру раздела |
| Между соседями | опора ↔ опора | Следующий шаг читателя: «а что с этим делать дальше» |
| Между темами | любая страница ↔ страница другого кокона | Смежная задача. Не запрещено — просто по делу, а не для «прокачки» |

**Что здесь опирается на данные.** Из утечки Content Warehouse видно, что вес ссылки (`LinkValue`) связан со смысловым
соответствием страниц: родственные передают его лучше, чем случайные. Практический вывод — **анкор должен описывать, что
читатель найдёт по ссылке**, а не быть «тут» и «читать». А вот проценты точных анкоров, «активация ссылки только кликом» и
обязательный срок ожидания перед простановкой ссылок — фольклор, а не факты.

## 6. Запреты и здоровая топология

**Правильно:**

- Узкая страница ссылается вверх на свою тему — читателю видно, где он.
- Анкор описывает, что человек найдёт по ссылке.
- Ссылки в теле текста, там где вопрос реально возникает.
- Страница в один-два клика от своего раздела.
- Ссылка на соседнюю тему — если это следующий вопрос читателя.

**Не надо:**

- Анкоры «тут», «читать», «подробнее» — по ним не понять, куда ведут.
- Ссылки только в футере — читатель до них не доходит.
- Страницы-«сироты», на которые не ведёт ни одна ссылка.
- Ссылки «для веса», не отвечающие ни на один вопрос читателя.

## 7. Как собрать кокон с нейронкой

Пять шагов:

1. **Собрать сущности** темы (по каждой: опорные термины, LSI, интент, ключи).
2. **Спроектировать три уровня** (хаб темы / промежуточные / опорные).
3. **Построить карту перелинковки:** от каждой страницы — туда, куда логично идти дальше.
4. **Проверить топологию** (нет сирот, анкоры осмысленные, лимиты ссылок).
5. **Написать страницы** с уже вшитыми ссылками.

Каждый шаг удобно вести в строгом JSON на входе и выходе — тогда нейронка собирает кокон почти сама.

### Готовый промпт для шага 1 — разведка сущностей

Скопируй в нейронку, подставь тему кокона. На выходе — строгий JSON, который дальше подаётся на проектирование архитектуры
и карты перелинковки.

```
Роль: ты SEO-архитектор, собираешь семантический кокон.
Задача: по теме ниже извлеки сущности для кокона.

ТЕМА: {вставь тему кокона, например: «Кофемашины для дома»}

Верни СТРОГО JSON без пояснений и без текста вокруг, по схеме:
{
"topic": "...",
"entities": [
{
"entity_name": "название сущности",
"salient_terms": ["5 обязательных терминов, без которых
сущность не раскрыта как экспертная"],
"lsi_cloud": ["10 сопутствующих слов, сужающих тему"],
"intents": {
"informational": "как это работает ...",
"commercial": "купить ... цена",
"navigational": "бренд/модель обзор"
},
"keywords": { "primary": ["..."], "long_tail": ["...","..."] }
}
]
}

Правила:
- Не выдумывай факты, цифры и идентификаторы. Только реальные термины темы.
- Salient terms — только те, без которых Google не признает
экспертность текста (для «литиевого аккумулятора» это анод, катод,
электролит — а не «удобный» и «современный»).
- Не добавляй сущности не по теме и не расширяй «по ассоциации».
- Минимум 8 сущностей. Похожие — объединяй, не дублируй.
```

**Что дальше с этим JSON.** Шаг 2 — тем же способом проси спроектировать 3 уровня (1 хаб темы / 4–6 промежуточных /
5–15 опорных на каждую) и разложить сущности по страницам. Шаг 3 — построить карту перелинковки: от каждой страницы туда,
куда логично идти дальше (ориентир по количеству: хаб 10–15 ссылок, промежуточная 8–15, опорная 3–5 — это про читаемость,
а не про «переток веса»; анкор описывает цель). Шаг 4 — проверить топологию (нет сирот, анкоры осмысленные).

**На старте — проще.** В первую неделю достаточно кластеров и понятной структуры сайта. Полный кокон — следующий уровень,
к которому приходишь, когда сайт уже живёт и растёт. Не усложняй на старте.

## Источники

- **Утечка внутренней документации Google** (Content Warehouse API, май 2024). Разбор Майка Кинга (iPullRank): ipullrank.com/google-algo-leak; SparkToro: sparktoro.com.
- **Антимонопольное дело США против Google** (US v. Google LLC, № 1:20-cv-03010) — показания Панду Наяка (система QBST, NavBoost).