Zo 140 na 561 kanibalizovaných dopytov denne
Medzi koncom júna a polovicou augusta počet dopytov, kde sa dve alebo viac URL amicited.com umiestnili v ten istý deň, vzrástol z približne 140 denne na vrchol 561. V najhoršom období tvorili kanibalizované dopyty 11,6 % všetkého, na čo sa web umiestnil.
Takže som nasmeroval Claude Code na Hugo repo webu, pripojil ho k AmICited SEO MCP serveru a požiadal ho, aby našiel keyword cannibalizáciu, rozhodol, čo robiť s každým prípadom, a aplikoval opravu naprieč všetkými 16 jazykmi, v ktorých web vychádza.
Toto je kompletná metóda: prompty, ktoré som použil, čo agent skutočne zavolal a urobil, a tri veci, ktoré objavil a na ktoré som sa nikdy nepýtal. Nič z toho ešte nie je nasadené, takže to berte ako prechod procesom, nie ako príspevok s výsledkami. 28-dňová kontrola príde neskôr.

Keyword cannibalizácia je stav, keď dve alebo viac stránok na tom istom webe súťaží o rovnaký vyhľadávací dopyt, takže Google neustále prepína, ktorú zobrazí, a ani jedna sa neumiestňuje tak dobre, ako by sa umiestňovala jedna silná stránka. Je to vnútorná konkurencia medzi vašimi vlastnými URL a je to jedna z tých SEO úloh, pri ktorých Claude Code ukazuje svoju hodnotu: dáta žijú v Search Console, oprava žije v repozitári a agent môže držať oboje naraz. (Nezamieňajte to s AI cannibalizáciou obsahu, kde AI-generovaná odpoveď preberá kliknutie, ktoré by inak získala vaša stránka.) Ak chcete úplný rozpis, samostatne sme spísali, ako identifikovať a opraviť problémy s keyword cannibalizáciou.
Nastavenie
- Repo: repozitár môjho Hugo webu, 500+ anglických blogových príspevkov, každý preložený do 15 ďalších jazykov.
- Dáta: AmICited MCP server, ktorý sprístupňuje SEO reporty založené na Google Search Console vrátane cannibalizácie ako nástroje, ktoré môže Claude Code priamo volať.
- Agent: Claude Code (Opus 5.5) v automatickom režime, na čerstvej vetve
seo/cannibalization-oct-2026. Nič sa necommituje bez toho, aby som si najprv prečítal diff.
Pripojenie MCP servera je jednorazový OAuth krok: spustite /mcp, vyberte server, schváľte pracovný priestor v prehliadači a Claude Code ho odvtedy môže volať.


Jedna vec, ktorú stojí za to vedieť vopred: môj AmICited pracovný priestor obsahuje niekoľko domén. Každý prompt, ktorý som napísal, explicitne pomenoval amicited.com a prvý požiadal Claude Code, aby mi povedal, ktoré ID domény vybral. Ak tento krok preskočíte, dôverujete agentovi, že uhádne správne.
Krok 1: Nájdite kanibalizáciu, odfiltrujte šum
Použi AmICited MCP server na získanie reportu o keyword cannibalizácii len pre doménu amicited.com (pracovný priestor má niekoľko domén, vyber tú pre amicited.com a povedz mi, ktoré ID domény/projektu si použil). Použi dáta z Google Search Console, za posledných 90 dní. Najprv vypíš MCP nástroje, ktoré voláš. Vylúč šum: dopyty s vyhľadávacími operátormi (site:, inurl:), čisto brandové/navigačné dopyty (“amicited”, “am i cited”) a dopyty pod 50 impresií. Zobraz top 15 skutočných cannibalizačných klastrov ako tabuľku […] Neupravuj žiadne súbory.
Filter šumu existuje kvôli tomu, ako v skutočnosti vyzerá surový report. Zoznam “Najhoršie súboje” na mojom dashboarde viedli site:www.amicited.com (417 URL), site:amicited.com (277 URL) a holý brandový dopyt amicited (193 URL). To nie je cannibalizácia. To som ja, a pravdepodobne môj vlastný tím, ktorý priamo vyhľadáva web. Akýkoľvek nástroj, ktorý to počíta ako cannibalizačný klaster, počíta nesprávnu vec.

Čo urobil, v poradí:
list_domains, aby našiel amicited.com medzi doménami v pracovnom priestore (a nahlásil späť ID domény, ktoré použil).search_tools, pretože nástroje na cannibalizáciu neboli v jeho predvolenom zozname nástrojov, takže ich vyhľadal podľa popisu.describe_tool, dvakrát, aby si prečítal vstupné schémy pre dva nástroje na cannibalizačné dopyty pred ich zavolaním.- Nástroj na zoznam klastrov, raz: top 200 dopytov podľa závažnosti z viac ako 10 000 kanibalizovaných dopytov v 90-dňovom okne.
- Nástroj na podrobnosti jednotlivých dopytov, 15-krát, raz na klaster, získavajúc súťažiace URL a ich denné pozície. Jedna odpoveď bola príliš veľká na zobrazenie v riadku, takže uložil výstup na disk a zhrnul ho pomocou
jq.
Potom filtroval. Približne 30 z top 200 boli site: dopyty. Z vlastnej iniciatívy pridal dva ďalšie filtre a povedal mi, že to urobil: dlhé, promptovité dopyty s tisíckami impresií a nulovými kliknutiami (vyzerali ako doslovne skopírované prompty AI sledovacích nástrojov, nie skutoční ľudia vyhľadávajúci) a niekoľko dopyty podobných kódu, ktoré vyzerali ako botová návštevnosť.

Najužitočnejší riadok vo výstupe nebola samotná tabuľka. Bol to tento:
Väčšina z nich nie je skutočne rozdelená návštevnosť. V deviatich z top pätnástich klastrov získava jedna URL viac ako 97 % impresií a zvyšok získava hŕstku.
Deväť z top pätnástich “cannibalizačných” klastrov bola jedna stránka robiaca v podstate všetku prácu, s druhou URL, ktorá sa objavila na pár dní a nič viac. Report zoradený čisto podľa závažnosti vám to nepovie. Prečítanie rozdelenia podľa jednotlivých URL áno.
Krok 2: Najprv diagnostika, potom oprava
Pre klastre v tvojej tabuľke, kde sú impresie skutočne rozdelené medzi stránky (nie tie, kde jedna URL má 97 %+), otvor súťažiace stránky v content/ a klasifikuj každú: CONSOLIDATE, DIFFERENTIATE, FIX-TECHNICAL, alebo LEAVE. Vyber víťaza podľa kliknutí, potom pozície, potom interných odkazov smerujúcich naň. Skontroluj, ako tento Hugo web dnes spracúva presmerovania. Zatiaľ nič neupravuj. Výstupom buď rozhodovacia tabuľka s jednoriadkovým dôvodom pre každý riadok.
Tento krok neurobil žiadne MCP volania vôbec. Išlo o približne 20 shellových príkazov: čítanie súťažiacich Markdown súborov, počítanie interných odkazov na každú stránku, čítanie šablón témy a spustenie curl proti živému webu, aby sa zistilo, čo presmerovania a hreflang značky skutočne vracajú v produkcii, nielen v repozitári.

Z pätnástich klastrov jeden potreboval zlúčenie, jeden potreboval precielenie, dva potrebovali technickú opravu a zvyšok nepotreboval nič. Tento pomer je hlavný dôvod, prečo by som nikdy nenechal agenta prejsť rovno z “tu je správa o cannibalizácii” na “tu sú stránky, ktoré som vymazal.”
Tri zistenia, o ktoré som nežiadal
1. Moje pravidlá 301 presmerovaní ticho prestali fungovať pred dvoma mesiacmi. Môj web má skript, ktorý generuje skutočné 301 pravidlá pre Amplify. Claude Code si všimol, že výstupný súbor neexistuje, prešiel späť cez git históriu a zistil, že bol vymazaný o päť týždňov skôr v rámci commitu “update content”, ktorý sa dotkol viac ako 21 000 súborov – vedľajšia škoda z hromadnej synchronizácie, nie rozhodnutie, ktoré niekto urobil zámerne. Na živom webe potvrdil, že žiadne z pravidiel nie je aktívne (presunutá URL vracala 404 tam, kde malo byť presmerovanie). Odvtedy bolo každé “presmerovanie” na webe v skutočnosti Hugo alias: stránka so statusom 200 s meta refreshom, nie skutočné 301.
2. To nebolo len teoretické. Stará URL stránky, ktorú som presunul v júli, sa stále zobrazovala v Search Console na vlastnej adrese – 188 impresií a stúpalo, dva a pol mesiaca po presune. Meta-refresh stub, ktorý Google aj tak ďalej indexuje, je presne to, ako vyzerá rozbité alias nastavenie v praxi.
3. Zachytil vlastnú chybu. V kroku 1 označil jeden pár stránok ako pravdepodobný problém s hreflang, keďže preložená verzia bola hodnotená vyššie ako anglický originál. V kroku 2 získal živé HTML, skontroloval, či sú hreflang značky absolútne a recipročné tak, ako to Google vyžaduje, a nahlásil, že tým opravil to, čo povedal prvýkrát. Zistenie sa presunulo z FIX na LEAVE. Oveľa radšej dostanem toto, než sebavedomú nesprávnu odpoveď, ktorá zostane nenapadnutá v správe.
Krok 3: Oprava v 16 jazykoch
Schválené. Aplikuj rozhodovaciu tabuľku na tejto vetve, necommituj. 1) CONSOLIDATE […] bez vymýšľania faktov alebo pridávania em-pomlčiek, potom vymaž porazenú stránku v každom jazyku, v ktorom existuje, pridaj jej starú URL do aliasov víťaza v každom zodpovedajúcom jazyku a preveď všetky interné odkazy na porazenú stránku v rámci content/. 2) DIFFERENTIATE […] vo všetkých jazykoch a pridaj jeden kontextový odkaz na víťaza. 3) FIX-TECHNICAL: skontroluj git históriu, či zmazanie static/_redirects bolo zámerné. Ak bolo náhodné, znova ich vygeneruj […] Ak bolo zámerné, neobnovuj, len mi to povedz.
Pred zlučovaním čohokoľvek overoval fakty. Stránka, ktorá sa vyraďovala, mala sekcie, ktoré víťazná nemala: zmienku o konkurenčnom nástroji, funkciu hodnotenia produktov a zhrnutie bezplatných skúšobných verzií. Pred prenesením čohokoľvek z toho Claude Code získal živé stránky dodávateľov, aby overil, či sú informácie stále presné.

Jeden z menovaných nástrojov sa ukázal byť akvizovaný a uzavretý pre nové registrácie o týždne skôr, takže to išlo ako oprava namiesto niečoho skopírovaného ako aktuálny fakt. Cenové tvrdenie porazenej stránky pre iný nástroj tiež bolo v rozpore s číslom už overeným na víťaznej stránke, takže overený údaj zostal a zastaraný sa nedostal do zlúčenia.

Pre prípad FIX-TECHNICAL skontroloval, či bolo zmazanie presmerovaní zámerné, predtým než sa čohokoľvek dotkol. Po potvrdení, že bolo náhodné (hromadný commit, ktorý ho odstránil, sa dotkol tisícov nesúvisiacich súborov bez zmienky o presmerovaniach), znova vygeneroval pravidlá a pridal skutočné 301 presmerovania pre stránky ovplyvnené zlúčením a presunutú URL, ktorá stále zobrazovala impresie pod svojou starou adresou. Pre CONSOLIDATE a DIFFERENTIATE zopakoval rovnakú zmenu naprieč každým jazykom, v ktorom ovplyvnené stránky existovali, nielen v angličtine, potom spustil plný produkčný build, aby potvrdil, že sa nič nerozbilo.
Čo ďalej
Po publikovaní nového obsahu to nie je koniec práce, je to len začiatok. Vedieť presne, ktoré URL medzi sebou ticho súťažia, ktoré treba zlúčiť a ktoré potrebujú len technickú opravu, je to, čo bráni tomu, aby obsah pracoval proti sebe. Nič z tohto prechodu ešte nie je naživo; 28-dňová kontrola, aby sme zistili, či sa počet kanibalizovaných dopytov skutočne zníži, je na rade.
Ak chcete vidieť tento druh správy o cannibalizácii na vašej vlastnej doméne, objednajte si hovor a prejdeme si to.

