Як знайти й виправити канiбалiзацiю ключових слiв у 2026 роцi: робочий процес із Codex

Що дає цей робочий процес

У вас була сторiнка в топ-10 за важливим ключовим словом, i тепер вона скотилася на 34-ту позицiю. Ви шукаєте той самий запит i бачите в результатах два свої посилання. Або ваша контент-команда минулого мiсяця опублiкувала 40 нових статей, i ви пiдозрюєте, що деякi з них тихо конкурують мiж собою.

Цей робочий процес перетворює пiдозру на пiдтверджений список i план виправлення. На виходi ви матимете: кожен запит, де конкурують два чи бiльше ваших посилань, вердикт для кожного кластера (об'єднати, канонiчний, диференцiювати або видалити) i чотиритижневий план перевiрки, який покаже, чи виправлення спрацювало.

• Для кого: SEO-спецiалiсти та контент-команди на сайтах вiд кiлькох сотень сторiнок i бiльше, а також усi, хто публiкує швидко.
• Час: близько 90 хвилин на перший аудит типового сайту середнього розмiру; удвiчi менше, коли наб'єте руку.
• Передумови: доступ на читання до Google Search Console, експорт сканування (Screaming Frog, Sitebulb або аналог) i трекер позицiй, якщо ви пiдписанi.
• Критерiй завершення: кожен конкуруючий кластер iз вашого списку має рiвно один iз чотирьох вердиктiв вище, виправлення застосованi, i в календарi є дата перегляду позицiй i показiв.

Спершу перевiрка реальностi, бо вона врятує вас вiд полагодження того, що не зламано: бачити кiлька посилань за один запит — це нормально. Категорiйна сторiнка, стаття в блозi та сторiнка товару можуть ранжуватися за одну фразу — якщо вони обслуговують рiзнi наміри (той, хто дослiджує, проти того, хто готовий купити), це здорова SERP, а не канiбалiзацiя. Цей робочий процес позначає лише сторiнки, якi конкурують за одну й ту саму роботу на одному етапi.

Чому це критичнiше у 2026-му, нiж п'ять рокiв тому, з однiєї причини: брифiнги й чернетки, згенерованi ШI, продукують схожi сторiнки зi швидкiстю, якої ручна перевiрка не встигає, тож канiбалiзацiя тепер вiдбувається в масштабi. Вона шкодить i позицiям у Google, i цитуванням у ШI-пошуку одночасно.

Трихвилинна перевiрка симптомiв

Перш нiж пiрнати в данi, пройдiться цим списком. Якщо два чи бiльше пункти звучать знайомо — запускайте повний аудит.

Перед початком: потрiбнi данi

Зберiть три речi:

1. Search Console з iсторiєю щонайменше 6 мiсяцiв. Для швидкої перевiрки вистачить 90 днiв, але довше вiкно показує, коли позицiя впала вiдносно запуску сторiнки.
2. Свiже сканування з витягнутими title i H1. Screaming Frog робить це нативно; Sitebulb i Botify теж пiдiйдуть. Якщо немає жодного — пошук site: плюс список сторiнок у CMS покриє найочевiднiшi випадки.
3. Експорт трекера позицiй (Semrush, Ahrefs, Authority Labs). Цей крок необов'язковий — порiвнянь у Search Console самостiйно вистачає для бiльшостi випадкiв.

Експортуйте з Search Console двi речi перед початком: звiт за запитами (запит, покази, клiки, позицiя) i той самий звiт з розмiром «сторiнки» (URL). Обидва є в роздiлi «Продуктивнiсть», у повному звiтi.

Крок 1: знайдiть конкуруючi URL у Search Console

Це безкоштовне порiвняння з найсильнiшим сигналом.

1. Вiдкрийте Search Console → «Продуктивнiсть» → повний звiт.
2. Використайте фiльтр запитiв i введiть перше прiоритетне ключове слово.
3. Подивiться на список посилань пiд графiком. Позначте кожен запит, за яким двi чи бiльше ваших сторiнок отримують покази.

Шукайте два патерни: сторiнки, якi дiлять покази приблизно порiвну в одному перiодi, i сторiнки, що застрягли мiж 20-i i 50-ю позицiєю, хоча ранiше були в топ-10, — особливо якщо падiння почалося близько запуску схожої сторiнки.

Почнiть iз 10–15 найважливiших ключових слiв. Якщо кластери знайдуться в половинi з них, проблема системна, i варто прочесати всi запити, скажiмо, з понад 50 показами за пiврiччя. Якщо вони з'являються лише на кiлькох — проблема iзольована: виправте й рухайтеся далi.

Очiкуваний результат: список запитiв, кожен iз двома чи бiльше вашими посиланнями та їхнiм розподiлом показiв. Перевiрка якостi: сторiнки справдi мають дiлити ранжування за одним запитом. Якщо вони просто схожi — це сусiди, а не конкуренти: приберiть. Шлях вiдновлення: нiчого не знайшли? Розширте вiкно до 3 мiсяцiв i додайте довгохвостовi варiанти ваших ключових слiв. Перевiрте також розподiл мiж брендовими й небрендовими термiнами — там ховаються дублiкати на багатоверсiйних сайтах (мовнi пари, опт/роздрiб).

Крок 2: знайдiть дубльованi title i H1 у своєму скануваннi

Канiбалiзацiя часто є аварiєю контент-виробництва: автору кажуть «напиши про X», вiн не перевiряє, що вже iснує, i створює сторiнку з тим самим заголовком, що й у сторiнки, яка вже ранжується.

Вiдкрийте експорт сканування, вiдсортуйте спочатку за title, потiм за H1 i позначте дублiкати та майже дублiкати. «Майже» рахується — двом сторiнкам не потрiбнi iдентичнi заголовки, щоб конкурувати. «Найкраще CRM-програмне забезпечення» i «Найкращi CRM-інструменти», що цiлять в одну аудиторiю, — кандидати; «Найкраще CRM для нерухомостi» — iнша сторiнка, не в списку.

Поки ви в даних сканування, перевiрте технiчних пiдозрюваних: canonical, що вказує кудись iнше, нiж на саму сторiнку; правила meta robots noindex, змiненi пiд час додавання варiантiв; i блоки robots.txt, якi почалися чи припинилися. Як каже посiбник Search Engine Journal на цю тему: коли ви змiнюєте спосiб, яким наказуєте пошуковикам сканувати, iндексувати й iгнорувати, ви створюєте проблеми канiбалiзацiї. Класичний приклад — сторiнка варiанта товару, яка успадкувала canonical старого товару.

Очiкуваний результат: пари сторiнок iз дубльованими або конкуруючими title i H1, плюс технiчнi прапорцi. Перевiрка якостi: для кожної пари дайте вiдповiдь на одне питання — одна сторiнка iснувала й ранжувалася до запуску iншої? Якщо так, занотуйте: це найсильнiший сигнал реальної проблеми. Шлях вiдновлення: якщо ваш CMS перетворює експорт на муку, згенеруйте список iз CSV сканування за допомогою скiлла Codex у кiнцi цiєї статтi. Ставтеся до його результату як до списку кандидатiв, а не вердикту.

Крок 3: пiдтвердiть трекером позицiй

Search Console каже, що повiдомляє Google; трекер позицiй показує, де вашi посилання перебувають у часi, — i саме вiн викриває по-справжньому застряглi сторiнки.

Вiдкрийте кожен запит-кандидат у своєму трекерi. Патерн, який пiдтверджує канiбалiзацiю: ключове слово застрягло мiж серединою 20-x i серединою 50-x, або посилання, що тримає позицiю X, перемикається мiж вашими сторiнками. Semrush показує, якi вашi сторiнки з'являлися за термiном за останнiй рiк; Authority Labs перелiчує кожне посилання за кожним ключовим словом. Якщо в рiчнiй iсторiї з'являються два чи бiльше ваших посилань i жодне не потрапило в топ-10 — пiдтвердження є.

Читайте також напрямок. Якщо ваша оригiнальна сторiнка ранжувалася добре до публiкацiї нової, а тепер обидвi коливаються нижче згину, нова сторiнка не «вкрала» позицiї. Двi сторiнки розмили одна одну. Це змiнює виправлення: ви вкладаєте нову сторiнку в оригiнальну, а не навпаки.

Очiкуваний результат: статус пiдтвердження для кожного кластера-кандидата — «пiдтверджено» або «не пiдтверджено, ручна перевiрка». Перевiрка якостi: пiдтвердження потребує щонайменше двох незалежних сигналiв. Search Console + сканування рахуються як два; лише трекер позицiй — слабкий одиничний сигнал. Шлях вiдновлення: якщо ваш трекер показує лише одне посилання на ключове слово, пропустiть цей крок. Порiвнянь у Search Console та скануваннi достатньо, щоб прогнати весь робочий процес.

Конвеєр аудиту: три проходи виявлення, матриця рiшень, цикл перевiрки.

Крок 4: ухвалiть рiшення про виправлення

Для кожного пiдтвердженого кластера оберiть рiвно один iз чотирьох вердиктiв. Ця таблиця — усе рiшення:

Два випадки — не канiбалiзацiя, залиште їх: стаття «як зробити» i сторiнка конверсiї, якi цiлять в одне ключове слово на рiзних етапах воронки — Google розумiє, яка сторiнка що робить, — та окремi мовнi версiї однiєї сторiнки з hreflang.

Одне питання для перевiрки вашого вердикту: пiсля цiєї змiни користувач, який шукає термiн, потрапляє на одну сторiнку й отримує все, що давала iнша? Якщо так — об'єднуйте чи видаляйте. Якщо нi — канонiзуйте чи диференцiюйте.

Крок 5: застосуйте виправлення без втрати видимостi

Виправлення А: консолiдацiя контенту (вердикт «об'єднати»). Працюйте вiд сторiнки, що вижила. Скопiюйте в неї кожен унiкальний роздiл сторiнки, що програє: вiдповiдi FAQ, приклади, цитований блок, внутрiшнi посилання, якi вказували на неї. Перебудуйте порядок, якщо треба, щоб найсильнiший контент був зверху. Коли сторiнка, що програє, має зовнiшнi зворотнi посилання або власнi реальнi ранжування, зробiть 301 на ту, що вижила, замiсть 404; коли немає нi того, нi iншого — видалення пiдходить. Посiбник Search Engine Journal свiдомо уникає 301 — вiн вiддає перевагу вкладанню контенту й видаленню новiшої сторiнки — i 301 стає потрiбним лише тодi, коли видалений URL несе власну посилальну вагу. Оновiть внутрiшнi посилання, що використовували якiр сторiнки, яка програла, щоб вони вказували на ту, що вижила.

Вкладання двох конкуруючих сторiнок в один URL перетворює розподiл показiв 50/50 на одного переможця.

Виправлення Б: канонiзацiя (вердикт «канонiчний»). Поставте само-канонiчний тег на офiцiйну сторiнку i канонiзуйте варiанти на неї. Це iнструмент для майже дубльованих сторiнок, якi мають iснувати: варiанти товару, URL з параметрами, сторiнки кампанiй. Вiн не замiнює консолiдацiю. Якщо двi сторiнки мають значний контент, сам лише canonical лишає обидвi в скануваннi й дiлить ваш редакцiйний фокус — спершу зробiть контентну роботу, потiм нацiльте canonical.

Виправлення В: програмне блокування iндексацiї (вердикт, сумiжний до «видалити»). Коли дублiкати структурнi — сторiнки параметрiв, комбiнацiї фiльтрiв, регiональнi варiанти, якi не потребують iндексацiї — застосуйте noindex на рiвнi папки чи шаблону, а не сторiнка за сторiнкою. Це випадок, коли один рядок коду перемагає 200 ручних правок.

Виправлення Г: виправте внутрiшнi посилання за метою (вердикт «диференцiювати»). Коли двi сторiнки легiтимно слугують рiзним цiлям, зробiть так, щоб вашi внутрiшнi посилання це казали. Правило з оригiнального посiбника: якщо текст навколо слова «яблука» говорить про купiвлю яблук — лiнкуйте на сторiнку конверсiї; якщо про те, звiдки беруться яблука — на iнформацiйну сторiнку. Кожне внутрiшнє посилання — це голос. Коли вашi посилання послiдовно ведуть на сторiнку, яка має виграти, ви прибираєте неоднозначнiсть, яку пошуковики розв'язували б самi — часто не в той бiк.

Крок 6: перевiрте, що виправлення спрацювало

Зачекайте два-чотири тижнi пiсля виправлень i перезапустiть перевiрки.

1. Search Console: запит тепер має показувати один домiнуючий URL замiсть розподiлу, а покази сторiнки, що вижила, мають зрости. Сукупнi покази кластера можуть впасти на тиждень-два пiд час перiоду повторного ранжування — це нормально, а не провал.
2. Трекер позицiй: ключове слово має перестати коливатися мiж посиланнями.
3. ШI-поверхнi: поставте своє головне питання ШI-асистенту або ШI-пошуковику й пiдтвердьте, що цитоване посилання — те, що вижило, а не видалене. Роздiленi сторiнки дiлять i ШI-цитування. Консолiдацiя — одне з небагатьох виправлень, якi допомагають i ранжуванню в Google, i видимостi в ШI-пошуку одночасно.

Якщо кластер усе ще роздiлений через чотири тижнi, ви або пропустили сторiнку (перевiрте невiдомi вам варiанти), або сторiнки справдi слугують рiзним цiлям i їх треба було диференцiювати, а не об'єднувати. Перевiрте ще раз i ухвалiть рiшення ще раз.

Не дайте цьому повторитися

Аудит — легка частина. Залишатися чистими — це редакцiйна дисциплiна. Три практики, у порядку важливостi:

1. Ведiть список тем, який контент-команда перевiряє перед написанням. Найшвидший спосiб створити канiбалiзацiю — автор, який не знає, що сторiнка вже iснує.
2. Перетворюйте перетин на розмову, а не на паркан. Замiсть заборони теми допоможiть автору знайти доповнюючий кут — як-зробити, порiвняння, вертикальну версiю.
3. Пильнуйте ШI-конвеєри виробництва насамперед. ШI-вивiд — найшвидша фабрика канiбалiзацiї: вiн продукують тонкi повторюванi сторiнки, якi конкурують мiж собою незалежно вiд якостi промпту. Кожна згенерована ШI сторiнка або сторiнка з ШI-брифом має пройти перевiрку списку тем перед плануванням, i квартальний аудит має їм надавати прiоритет.

Запускайте повний аудит щокварталу та пiсля кожного випуску, який додав бiльше кiлькох сторiнок до однiєї дiлянки сайту.

Автоматизуйте аудит: скiлл Codex

Кроки вище ручнi, щоб ви зрозумiли, що означають данi. Коли зрозумiєте, передовiрте повторюванi частини ШI-агентовi програмування. Це повний файл скiлла для Codex: вiн читає вашi експорти Search Console, позначає конкуруючi кластери й видає аркуш вердиктiв, не торкаючись вашого сайту.

---
name: keyword-cannibalization-audit
description: Find and classify keyword cannibalization clusters from Google Search Console, crawl, and rank-tracker exports. Use when a query shows multiple URLs, rankings dropped after a new page launch, or you need a cannibalization verdict sheet. Read-only: produces a report, never edits pages.
---

# Keyword Cannibalization Audit

## Inputs (required)
- `gsc-queries.csv` — Search Console query export (query, impressions, clicks, position)
- `gsc-pages.csv` — Search Console page export (page, impressions, clicks, position)
- `crawl-titles.csv` — crawl export with URL, title, H1, canonical
- `rank-history.csv` — optional rank tracker export with per-keyword URL history

## Procedure

1. Load the CSVs. Normalize URLs (lowercase host, strip trailing slash and tracking parameters).
2. Join `gsc-queries.csv` and `gsc-pages.csv` on query to build query-to-URL mappings.
3. Flag queries where 2+ URLs each received at least 10% of the query's impressions in the last 90 days.
4. Flag queries where a URL sits between positions 20-50 and a second URL for the same query was created later (compare crawl or tracker history).
5. From `crawl-titles.csv`, flag pairs whose titles or H1s are identical or share 80%+ of their significant tokens.
6. From `rank-history.csv`, flag queries whose ranking URL changed more than twice in 6 months.
7. Cross-check every flag. Keep only clusters confirmed by at least two signals (Search Console + crawl counts as two).
8. Classify each surviving cluster as MERGE, CANONICALIZE, DIFFERENTIATE, or REMOVE:
   - Same intent + one page clearly more complete → MERGE (fold unique sections into the survivor; note a 301 only if the removed URL has external backlinks)
   - Near-identical variants that must exist (parameters, variants) → CANONICALIZE
   - Same topic, genuinely different intent you want to keep → DIFFERENTIATE (rewrite one page, no title overlap)
   - Thin or fully duplicated page with no unique value → REMOVE
   - Complementary intent (how-to vs. product for the same keyword) → NOT CANNIBALIZATION, skip
9. Output `cannibalization-verdicts.md`: a table of query | competing URLs | signals found | verdict | action, ordered by query impressions. Include for each cluster the exact URLs, the evidence rows (dates, positions, impressions), and fix text ready to paste into a CMS task.

## Rules
- Read-only. Never edit pages, robots.txt, or canonicals. Output the report and a proposed action plan only.
- Never merge a URL into a survivor whose content is not equal to or better than the merged output.
- Do not classify locale variants (hreflang) or genuinely different intents as cannibalization.
- Clusters with fewer than two confirming signals get marked "unconfirmed — review manually," never dropped.
- When the rank tracker export is missing, run with Search Console + crawl only and say so in the report header.

Збережiть його як keyword-cannibalization-audit/SKILL.md у папцi скiллiв Codex, покладiть чотири CSV в робочу папку й запустiть. Типовий запуск на кiлька тисяч сторiнок займає пару хвилин i повертає аркуш вердиктiв.

Два меншi промпти для тих, кому не потрiбен повний скiлл:

• Трiаж експорту: «Ось мiй експорт запитiв iз Search Console. Знайди всi запити, де два чи бiльше моїх посилань отримують щонайменше по 10% показiв. Вивiд таблицею: запит, URL, розподiл показiв, позицiя кожного URL. Без рекомендацiй.»
• Вердикт кластера: «Двi мої сторiнки ранжуються за [запит]: [URL A] на позицiї [X] i [URL B] на позицiї [Y]. [URL B] опублiковано [дата]. Порiвняй їхнiй контент i скажи, який iз чотирьох вердиктiв застосовний — об'єднати, канонiчний, диференцiювати, видалити — i чому, двома реченнями.»

Поширенi запитання

За моїм ключовим словом ранжується кiлька сторiнок — це автоматично канiбалiзацiя?

Нi. Якщо сторiнки слугують рiзним цiлям (дослiдження проти покупки) або рiзним мовам, пошуковики добре їх обробляють. Вердикт потрiбен лише сторiнкам, що конкурують за одну роботу на одному етапi воронки.

Canonical чи noindex — що використовувати?

Canonical — коли сторiнки мають лишатися доступними (варiанти товару, параметри) i їхнi сигнали мають стiкати в офiцiйну сторiнку. Noindex, застосований програмно, — коли сторiнки є чистими дублiкатами, якi не слугують жоднiй потребi користувача. Жодне не замiнює консолiдацiю контенту, якщо дубльована сторiнка мiстить щось справдi корисне.

Чи варто робити 301 iз сторiнки, що програє?

Лише якщо вона має зовнiшнi зворотнi посилання або власнi значнi ранжування. Iнакше вкладiть її унiкальний контент у сторiнку, що вижила, i видалiть. 301 на сторiнку, яка не є справжньою замiною, марнує вагу редиректу й плутає користувачiв.

Трафiк упав пiсля об'єднання сторiнок — я щось зламав?

Коротке падiння, поки Google переоцiнює кластер, — звичайна рiч. Мiряйте на четвертому тижнi: якщо сторiнка, що вижила, ранжується за запитом i покази кластера вiдновилися — виправлення спрацювало. Якщо виграє iнша сторiнка — ви об'єднали не в той бiк. Вiдкотiть, поки не стало гiрше.

Чи впливає канiбалiзацiя на цитування в ШI-пошуку?

Так. Коли конкурують два вашi посилання, ШI-вiдповiдi обирають мiж ними й можуть процитувати одне, iнше або жодне. Консолiдацiя дає вам одне сильне цитоване посилання замiсть двох розмитих.

Як часто запускати аудит?

Щокварталу як базову норму, плюс пiсля кожної хвилi нових сторiнок. Сайти, якi продукують контент iз ШI, мають ставитися до аудиту як до частини редакцiйного конвеєра, а не перiодичного завдання.

Авторка: Клара Беннет, контент-стратегиня з десятирiчним досвiдом в Auspia. Клара пише про редакцiйнi системи, тематичнi карти й повторюванi контент-операцiї, якi запобiгають зiткненню публiкацiйних планів мiж собою.