Fra 140 til 561 kannibaliserede forespørgsler om dagen
Mellem slutningen af juni og midten af august steg antallet af forespørgsler, hvor to eller flere amicited.com-URL’er blev rangeret samme dag, fra omkring 140 om dagen til en top på 561. På sit værste udgjorde kannibaliserede forespørgsler 11,6 % af alt, hvad siden blev rangeret for.
Så jeg satte Claude Code på sitets Hugo-repo, forbandt det til AmICited SEO MCP-serveren og bad den finde keyword-kannibaliseringen, beslutte hvad der skulle gøres ved hvert tilfælde og anvende rettelsen på tværs af alle 16 sprog, som siden leveres på.
Dette er metoden fra ende til anden: de prompter jeg brugte, hvad agenten faktisk kaldte og gjorde, og de tre ting den fandt frem, som jeg aldrig spurgte om. Intet af det er implementeret endnu, så betragt dette som en gennemgang af processen, ikke et resultatindlæg. 28-dages-gennemgangen kommer senere.
Keyword-kannibalisering er, når to eller flere sider på samme site konkurrerer om den samme søgeforespørgsel, så Google bliver ved med at skifte mellem, hvilken side det viser, og ingen af dem rangerer lige så godt, som en enkelt stærk side ville gøre. Det er intern konkurrence mellem dine egne URL’er, og det er en af de SEO-opgaver, hvor Claude Code virkelig viser sin værdi: dataene ligger i Search Console, rettelsen ligger i repo’et, og en agent kan håndtere begge dele på én gang. (Forveksl det ikke med AI-indholdskannibalisering, hvor et AI-genereret svar tager klikket, som din side ellers ville have fået.) Hvis du vil have den fulde gennemgang, har vi skrevet separat om, hvordan man identificerer og retter keyword-kannibaliseringsproblemer.
Opsætningen
- Repo: mit Hugo-sites repository, 500+ engelske blogindlæg, hver oversat til 15 andre sprog.
- Data: AmICited MCP-serveren, som stiller SEO-rapporter baseret på Google Search Console, inklusive kannibalisering, til rådighed som værktøjer, Claude Code kan kalde direkte.
- Agent: Claude Code (Opus 5.5) kørende i auto-tilstand, på en ny branch,
seo/cannibalization-oct-2026. Intet bliver committed uden at jeg har læst diff’en først.
Tilslutning af MCP-serveren er et engangs-OAuth-trin: kør /mcp, vælg serveren, godkend workspace’et i browseren, og Claude Code kan kalde den fremover.
Én ting er værd at vide på forhånd: mit AmICited-workspace har flere domæner i sig. Hver prompt jeg skrev, nævnte amicited.com eksplicit, og den første bad Claude Code om at fortælle mig, hvilket domæne-ID den valgte. Spring dette trin over, og du overlader til agenten at gætte korrekt.
Ready to Monitor Your AI Visibility?
Track how AI chatbots mention your brand across ChatGPT, Perplexity, and other platforms.
Trin 1: Find kannibalisering, fjern støjen
Brug AmICited MCP-serveren til at trække keyword-kannibaliseringsrapporten for kun amicited.com-domænet (workspace’et har flere domæner, vælg det for amicited.com og fortæl mig hvilket domæne/projekt-ID du brugte). Brug Google Search Console-data, sidste 90 dage. List først de MCP-værktøjer du kalder. Ekskludér støj: forespørgsler med søgeoperatorer (site:, inurl:), rene brand/navigationsforespørgsler (“amicited”, “am i cited”) og forespørgsler under 50 visninger. Vis de 15 bedste ægte kannibaliseringsklynger som en tabel […] Redigér ikke nogen filer.
Støjfilteret findes på grund af, hvordan den rå rapport faktisk ser ud. Listen over “Værste konkurrencer” på mit dashboard blev anført af site:www.amicited.com (417 URL’er), site:amicited.com (277 URL’er) og den rene brand-forespørgsel amicited (193 URL’er). Det er ikke kannibalisering. Det er mig, og formentlig mit eget team, der søger direkte på siden. Ethvert værktøj, der tæller det som en kannibaliseringsklynge, tæller det forkerte.
Hvad den gjorde, i rækkefølge:
list_domains, for at finde amicited.com blandt domænerne i workspace’et (og rapportere tilbage hvilket domæne-ID den brugte).search_tools, fordi kannibaliseringsværktøjerne ikke var i dens standardværktøjsliste, så den søgte efter dem via beskrivelse.describe_tool, to gange, for at læse input-skemaerne for de to kannibaliseringsforespørgselsværktøjer før kald.- Klynge-listeværktøjet, én gang: de 200 bedste forespørgsler efter sværhedsgrad, ud af over 10.000 kannibaliserede forespørgsler i 90-dages-vinduet.
- Det per-forespørgsel detaljeværktøj, 15 gange, én gang per klynge, med de konkurrerende URL’er og deres daglige positioner. Ét svar var for stort til at blive vist inline, så den gemte output til disk og opsummerede det med
jq.
Derefter filtrerede den. Cirka 30 af de 200 bedste var site:-forespørgsler. På eget initiativ tilføjede den to yderligere filtre og fortalte mig, at den havde gjort det: lange, prompt-formede forespørgsler med tusindvis af visninger og nul klik (de læses som AI-sporingsværktøjsprompter kopieret ordret, ikke rigtige mennesker, der søger), og en håndfuld kode-lignende forespørgsler, der lignede bot-trafik.
Den mest nyttige linje i output var ikke selve tabellen. Det var denne:
De fleste af disse er ikke rigtig delt trafik. I ni af de femten bedste klynger får én URL over 97 % af visningerne, og resten får en håndfuld.
Ni af de femten bedste “kannibaliserings”-klynger var én side, der stort set gjorde alt arbejdet, med en anden URL, der havde vist sig i et par dage og intet mere. En rapport sorteret udelukkende efter sværhedsgrad vil ikke fortælle dig det. At læse opdelingen per URL gør.
Trin 2: Diagnosticér før du retter
For klyngerne i din tabel, hvor visninger reelt er delt mellem sider (ikke dem hvor én URL har 97 %+), åbn de konkurrerende sider i content/ og klassificér hver: KONSOLIDÉR, DIFFERENTIÉR, RET-TEKNISK eller LAD-VÆRE. Vælg vinderen efter klik, derefter position, derefter interne links der peger på den. Undersøg hvordan dette Hugo-site håndterer omdirigeringer i dag. Redigér ikke noget endnu. Output en beslutningstabel med en linjes begrundelse per række.
Dette trin foretog ingen MCP-kald overhovedet. Det handlede om cirka 20 shell-kommandoer: læsning af de konkurrerende Markdown-filer, optælling af interne links til hver side, læsning af temaets skabeloner og kørsel af curl mod det live site for at se, hvad omdirigeringerne og hreflang-tags faktisk returnerede i produktion, ikke kun i repo’et.
Ud af de femten klynger havde én brug for en fusion, én havde brug for en omdirigering, to havde brug for en teknisk rettelse, og resten havde ikke brug for noget. Det forhold er den primære grund til, at jeg aldrig ville lade en agent gå direkte fra “her er en kannibaliseringsrapport” til “her er de sider, jeg slettede.”
Tre fund jeg ikke bad om
1. Mine 301-omdirigeringsregler var stille og roligt holdt op med at virke to måneder tidligere. Mit site har et script, der genererer rigtige 301-regler til Amplify at levere. Claude Code bemærkede, at outputfilen ikke eksisterede, gik tilbage gennem git-historikken og fandt, at den var blevet slettet fem uger tidligere inde i en “opdater indhold”-commit, der berørte over 21.000 filer, kollateralskade fra en bulk-synkronisering, ikke en beslutning nogen traf med vilje. Den bekræftede på det live site, at ingen af reglerne var aktive (en flyttet URL returnerede en 404, hvor en omdirigering burde have været). Siden da havde hver “omdirigering” på siden faktisk været et Hugo-alias: en side med status 200 og en meta-opdatering, ikke en rigtig 301.
2. Det var ikke bare teoretisk. Den gamle URL på en side, jeg havde flyttet i juli, dukkede stadig op på egen hånd i Search Console, 188 visninger og tællende, to en halv måned efter flytningen. En meta-opdaterings-stub, som Google alligevel bliver ved med at indeksere, er præcis, hvordan en brudt alias-opsætning ser ud i praksis.
3. Den fangede sin egen fejl. I trin 1 havde den markeret ét sidepar som et sandsynligt hreflang-problem, da en oversat version overgik den engelske original. I trin 2 hentede den det live HTML, tjekkede at hreflang-tags var absolutte og gensidige, som Google kræver, og rapporterede, at dette korrigerede, hvad den havde sagt første gang. Fundet flyttede sig fra RET til LAD-VÆRE. Det tager jeg meget hellere end et selvsikkert forkert svar, der står uimodsagt i en rapport.
Stay Updated on AI Visibility Trends
Get the latest insights on AI mentions, brand monitoring, and optimization strategies.
Trin 3: Anvend rettelsen på 16 sprog
Godkendt. Anvend beslutningstabellen på denne branch, commit ikke. 1) KONSOLIDÉR […] uden at opdigte fakta eller tilføje tankestreger, slet derefter taberen på alle sprog den findes på, tilføj dens gamle URL til vinderens aliasser på hvert matchende sprog, og omdirigér alle interne links til taberen på tværs af content/. 2) DIFFERENTIÉR […] på alle sprog, og tilføj ét kontekstuelt link til vinderen. 3) RET-TEKNISK: tjek git-historikken for at se, om sletningen af static/_redirects var bevidst. Hvis den var utilsigtet, regenerér dem […] Hvis den var bevidst, gendan ikke, fortæl mig bare.
Den faktatjekkede før den fusionerede noget. Siden, der blev pensioneret, havde sektioner, som vinderen ikke havde: en omtale af et konkurrerende værktøj, en produkt-rangeringsfunktion og en samling af gratis prøveperioder. Før Claude Code overførte noget af dette, hentede den leverandørernes live-sider for at verificere, at det stadig var korrekt.
Ét af de nævnte værktøjer viste sig at være blevet opkøbt og lukket for nye tilmeldinger uger tidligere, så det blev en korrektion i stedet for noget, der blev kopieret videre som aktuel fakta. Tabsidens prispåstand for et andet værktøj var også i konflikt med tallet, der allerede var verificeret på vindersiden, så det verificerede tal blev beholdt, og det forældede kom ikke med i fusionen.
For RET-TEKNISK-tilfældet tjekkede den, om sletningen af omdirigeringer havde været bevidst, før den rørte ved noget. Efter at have bekræftet, at den var utilsigtet (bulk-committen, der fjernede den, berørte tusindvis af ikke-relaterede filer uden omtale af omdirigeringer), regenererede den reglerne og tilføjede rigtige 301’er for de sider, der var berørt af fusionen og den flyttede URL, der stadig viste visninger under sin gamle adresse. For KONSOLIDÉR og DIFFERENTIÉR gentog den den samme ændring på tværs af alle sprog, de berørte sider eksisterede på, ikke kun engelsk, og kørte derefter en fuld produktionsbuild for at bekræfte, at intet gik i stykker.
Hvad er næste skridt
Når du har udgivet nyt indhold, er det ikke slutningen på opgaven, det er kun begyndelsen. At vide præcis, hvilke URL’er der stille konkurrerer med hinanden, hvilke der skal fusioneres, og hvilke der bare har brug for en teknisk rettelse, er det, der holder dit indhold fra at arbejde imod sig selv. Intet fra denne omgang er live endnu; 28-dages-gennemgangen, for at se om antallet af kannibaliserede forespørgsler faktisk falder, er næste skridt.
Hvis du vil se denne form for kannibaliseringsrapport på dit eget domæne, så book et opkald , så gennemgår vi det sammen.
