Каннибализация запросов: проверка страниц с ИИ

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

Найдите сигнал, а не приговор

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

В отчёте Search Console параметр определяет, как группируются данные: например, «Запросы» группирует строки по поисковым фразам Справка Search Console. Для сравнения URL нужна одна наблюдаемая выборка, где запрос и URL связаны в строке, — например, отфильтрованный запрос с группировкой по «Страницы» при одинаковых окнах и фильтрах. Независимые агрегаты по запросам и по страницам нельзя склеивать в общую карту: совместные клики и показы из них не восстановить. Если связки нет, оставьте ячейку unknown. Средняя позиция в таблице относится к конкретному URL или параметру в строке, а на диаграмме — ко всему сайту Справка Search Console. Не смешивайте эти два уровня, иначе разговор о конкуренции страниц уйдёт в средние по сайту.

У сигнала есть граница достоверности. Вы можете не увидеть сайт по запросу из списка, потому что результаты зависят от времени, места, устройства и истории пользователя Справка Search Console. Скрытый запрос не равен нулю, а переключение кликов между URL не доказывает причинную потерю. Это отдельная гипотеза, которую проверяют следующими окнами и текстами.

Соберите карту запросов и страниц

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

1. Зафиксируйте окна, страну, устройство и тип поиска. Например, два последовательных недельных окна в RU, mobile, web. Если окна пересекаются, сравнение теряет смысл.
2. Для каждого отобранного запроса выгрузите строки, где запрос и URL связаны в одной наблюдаемой выборке, при одинаковых окнах и фильтрах; независимые итоги по запросам и по страницам между собой не склеивайте. Тип поиска и диапазон дат задаются фильтрами в отчёте Справка Search Console.
3. Отметьте полноту: какие запросы скрыты, какие строки не попали в выгрузку, есть ли разрывы по датам. Скрытые строки не считайте нулём.
4. Постройте карту query×URL только из связанных строк: строка — запрос, столбцы — URL, в ячейках — клики до и после и показы до и после. Где связки нет — unknown, а не выдуманное значение. Показы удобны как контроль: если они не меняются, перераспределение кликов не объяснить исчезновением страницы из выдачи.
5. Для каждого URL из карты выпишите задачу страницы и выдержки тела: заголовок, первый абзац, блок с ответом на запрос. Без текста карта показывает только цифры и не различает интенты.

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

Попросите ИИ сравнить интенты

Промпт ниже работает сам по себе: в нём есть входные строки, правила и выходная схема. Модель не решает, что объединять; она строит обоснованное предложение со ссылкой на строки исходных данных. Запрет на решение по одному ключу и обязательная привязка к строкам — часть промпта.

Роль: аналитик поисковых страниц. Ты сравниваешь интенты и предлагаешь решения, но не меняешь сайт.

Данные:
Страна RU, устройство mobile, тип поиска web.
Окна: 2026-09-01—2026-09-07 (до) и 2026-09-08—2026-09-14 (после).

Страницы:
1) https://example.test/blog/a — задача: выбрать способ проверки UTM; тело: «Проверяйте параметры ссылки до размещения. Сверьте source, medium и campaign со справочником.»
2) https://example.test/blog/b — задача: выбрать способ проверки UTM; тело: «Проверяйте source, medium и campaign перед размещением. Дополнительно проверьте повторяющиеся параметры.»
3) https://example.test/tools/utm — задача: собрать ссылку; тело: «Введите URL, source, medium, campaign. Генератор соберёт ссылку.»
4) https://example.test/blog/utm-loss — задача: найти потерю параметров на редиректе; тело: «Запишите URL каждого перехода и Location, сравните query до и после.»

Строки выгрузки (запрос, URL, клики до, клики после, показы до, показы после):
- проверка utm меток, /blog/a, 30, 8, 500, 500
- проверка utm меток, /blog/b, 5, 27, 500, 500
- генератор utm, /tools/utm, 40, 42, 500, 500
- utm теряются, /blog/utm-loss, 20, 19, 300, 300

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

Выходная схема:
1. Таблица query×URL с кликами и показами до и после.
2. Для каждого URL: задача, выдержка тела, наблюдение.
3. Решение по каждой группе URL: объединить или развести, основание, пробелы.
4. Для объединения — уникальный фрагмент и порядок переноса.
5. Общие клики по запросу до и после.

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

Учебный пример

Ниже полный учебный вход и эталон. URL на example.test и все поисковые числа вымышлены; это не клиентский кейс и не выполненный тест нейросети.

Входные данные:

• Страна RU, устройство mobile, тип поиска web.
• Два окна: 2026-09-01—2026-09-07 и 2026-09-08—2026-09-14.
• Полнота: полный учебный набор, не настоящий экспорт.

Четыре страницы с задачами и телами — как в промпте выше: /blog/a и /blog/b про проверку UTM, /tools/utm про сборку ссылки, /blog/utm-loss про потерю параметров на редиректе.

Карта query×URL по выгрузке:

Запрос	URL	Клики до	Клики после	Показы до	Показы после
проверка utm меток	/blog/a	30	8	500	500
проверка utm меток	/blog/b	5	27	500	500
генератор utm	/tools/utm	40	42	500	500
utm теряются	/blog/utm-loss	20	19	300	300

Эталон решений:

1. /blog/a и /blog/b — объединить b с a в рамках учебных условий. Основание: одинаковая задача и взаимозаменяемый основной ответ; клики перераспределились 30/5→8/27 при одинаковом числе показов. Перераспределение — сигнал, не доказанная причина. Сохранить перед объединением уникальный пункт b: «Дополнительно проверьте повторяющиеся параметры.». После переноса спланировать постоянный серверный redirect b→a и обновить ссылки и sitemap. Это план, а не выполненная операция.
2. /tools/utm и /blog/utm-loss — развести и оставить отдельными. Создание ссылки и диагностика цепочки решают разные задачи, хотя обе страницы упоминают UTM.

Суммарные клики двух URL по запросу «проверка utm меток»: до 30+5=35, после 8+27=35. Это показывает только неизменность этих суммарных кликов по этому запросу; потеря кликов в этой учебной паре не показана, спрос и причинный эффект объединения не установлены. Неизвестные остаются: реальные позиции, индексация, эффект будущего объединения.

Проверка эталона: все четыре URL получили решение с основанием из тел или выгрузки; совпадение слов не использовано как условие склейки; уникальный фрагмент b сохранён до перенаправления; общие клики 35→35, падение трафика не придумано.

Подготовьте безопасный план изменения

План начинается с переноса, а не с технической перенастройки. Сначала перенесите в целевую страницу всё уникальное содержание исходной: пункт, пример, уточнение, которое решает задачу читателя. Проверьте, что основной ответ не дублируется и что после переноса страница отвечает на запрос полнее, чем каждая из двух по отдельности.

Дальше — техническая часть, и она требует проверки реальных тел и назначения страниц. При реальном объединении постоянный серверный redirect — явный признак того, что целевой URL нужно считать каноническим Центр Google Поиска. Canonical-аннотация тоже служит сигналом, но это не универсальная замена объединения разных страниц Центр Google Поиска. Выбирайте способ по тому, действительно ли страницы одинаковы или похожи, а не по формальному совпадению запроса.

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

Если сомневаетесь в полноте выгрузки или не понимаете, почему клики ушли с одной страницы на другую, начните с диагностики данных, а не с перестройки URL. Разбор падения кликов в Search Console — отдельная задача: как разобрать выгрузку. Если нужно расширить список запросов и страниц вокруг темы, используйте сбор семантического ядра с ИИ, но не превращайте его в повод склеивать страницы по совпадению слов.