Fra 140 til 561 kannibaliserte søk per dag
Mellom slutten av juni og midten av august økte antallet søk der to eller flere amicited.com-URL-er ble rangert samme dag fra rundt 140 per dag til en topp på 561. På det verste utgjorde kannibaliserte søk 11,6 % av alt nettsiden ble rangert for.
Så jeg pekte Claude Code mot nettstedets Hugo-repo, koblet det til AmICited SEO MCP-serveren, og ba den finne keyword cannibalization, bestemme hva som skulle gjøres med hvert tilfelle, og anvende fiksen på tvers av alle 16 språkene nettstedet leveres på.
Dette er metoden fra start til slutt: promptene jeg brukte, hva agenten faktisk kalte og gjorde, og de tre tingene den avdekket som jeg aldri spurte om. Ingenting av dette er satt i produksjon ennå, så betrakt dette som en gjennomgang av prosessen, ikke et resultatinnlegg. 28-dagers kontrollen kommer senere.
Keyword cannibalization er når to eller flere sider på samme nettsted konkurrerer om samme søk, slik at Google stadig bytter mellom hvilken side som vises, og ingen av dem rangerer like godt som én sterk side ville gjort. Det er intern konkurranse mellom dine egne URL-er, og det er en av SEO-jobbene der Claude Code virkelig viser sin verdi: dataene ligger i Search Console, fiksen ligger i repoet, og en agent kan håndtere begge deler samtidig. (Ikke forveksle det med AI content cannibalization, der et AI-generert svar stjeler klikket siden din ellers ville fått.) Hvis du vil ha hele oppsummeringen, har vi skrevet om hvordan identifisere og fikse keyword cannibalization-problemer separat.
Oppsettet
- Repo: Hugo-nettstedets repository, 500+ engelske blogginnlegg, hver oversatt til 15 andre språk.
- Data: AmICited MCP-serveren, som eksponerer SEO-rapporter basert på Google Search Console, inkludert cannibalization, som verktøy Claude Code kan kalle direkte.
- Agent: Claude Code (Opus 5.5) i automatisk modus, på en ny gren,
seo/cannibalization-oct-2026. Ingenting commites uten at jeg har lest diffen først.
Tilkobling av MCP-serveren er et engangstrinn med OAuth: kjør /mcp, velg serveren, godkjenn arbeidsområdet i nettleseren, og Claude Code kan kalle den deretter.
Én ting verdt å vite på forhånd: AmICited-arbeidsområdet mitt har flere domener i seg. Hver prompt jeg skrev navngav amicited.com eksplisitt, og den første ba Claude Code fortelle meg hvilken domene-ID den valgte. Hopp over det trinnet, og du stoler på at agenten gjetter riktig.
Ready to Monitor Your AI Visibility?
Track how AI chatbots mention your brand across ChatGPT, Perplexity, and other platforms.
Trinn 1: Finn kannibalisering, fjern støyen
Bruk AmICited MCP-serveren til å hente keyword cannibalization-rapporten for kun amicited.com-domenet (arbeidsområdet har flere domener – velg det for amicited.com og fortell meg hvilken domene-/prosjekt-ID du brukte). Bruk Google Search Console-data, siste 90 dager. List først opp MCP-verktøyene du kaller. Ekskluder støy: søk med søkeoperatorer (site:, inurl:), rene merkevare-/navigasjonssøk (“amicited”, “am i cited”), og søk under 50 visninger. Vis de 15 største reelle cannibalization-klyngene som en tabell […] Ikke rediger noen filer.
Støyfilteret finnes fordi rårapporten faktisk ser slik ut. Listen over “Verste konkurranser” på dashbordet mitt ble ledet av site:www.amicited.com (417 URL-er), site:amicited.com (277 URL-er) og det rene merkevaresøket amicited (193 URL-er). Det er ikke cannibalization. Det er meg, og sannsynligvis mitt eget team, som søker direkte etter nettstedet. Ethvert verktøy som teller det som en cannibalization-klynge, teller feil ting.
Hva den gjorde, i rekkefølge:
list_domains, for å finne amicited.com blann domenene i arbeidsområdet (og rapportere tilbake domene-IDen den brukte).search_tools, fordi cannibalization-verktøyene ikke var i standard verktøylisten, så den søkte etter dem basert på beskrivelse.describe_tool, to ganger, for å lese inndataskjemaene for de to cannibalization-søk-verktøyene før den kalte dem.- Klyngelisteverktøyet, én gang: de 200 øverste søkene etter alvorlighetsgrad, av over 10 000 kannibaliserte søk i 90-dagersvinduet.
- Det per-søk-detaljert verktøyet, 15 ganger, én gang per klynge, for å hente de konkurrerende URL-ene og deres daglige posisjoner. Ett svar var for stort til å vises inline, så den lagret resultatet til disk og oppsummerte det med
jq.
Deretter filtrerte den. Omtrent 30 av de 200 øverste var site:-søk. På eget initiativ la den til to filtre til og fortalte meg at den hadde gjort det: lange, prompt-formede søk med tusenvis av visninger og null klikk (de så ut som AI-sporingsverktøy-prompter kopiert ordrett, ikke ekte mennesker som søkte), og en håndfull kode-lignende søk som så ut som bot-trafikk.
Den mest nyttige linjen i resultatet var ikke selve tabellen. Det var denne:
De fleste av disse er ikke egentlig delt trafikk. I ni av de femten øverste klyngene får én URL over 97 % av visningene, og resten får noen få hver.
Ni av de femten øverste «cannibalization»-klyngene var én side som gjorde praktisk talt alt arbeidet, med en andre URL som hadde dukket opp noen dager og ingenting mer. En rapport sortert rent etter alvorlighetsgrad vil ikke fortelle deg det. Å lese per-URL-fordelingen gjør.
Trinn 2: Diagnostiser før du fikser
For klyngene i tabellen din der visningene er reelt fordelt mellom sider (ikke de der én URL har 97 %+), åpne de konkurrerende sidene i content/ og klassifiser hver: CONSOLIDATE, DIFFERENTIATE, FIX-TECHNICAL eller LEAVE. Velg vinneren basert på klikk, deretter posisjon, deretter interne lenker som peker til den. Sjekk hvordan dette Hugo-nettstedet håndterer omdirigeringer i dag. Ikke rediger noe ennå. Lever en beslutningstabell med én linje begrunnelse per rad.
Dette trinnet gjorde ingen MCP-kall i det hele tatt. Det var omtrent 20 shell-kommandoer: lesing av de konkurrerende Markdown-filene, telling av interne lenker til hver side, lesing av temaets maler, og kjøring av curl mot live-nettstedet for å se hva omdirigeringene og hreflang-taggene faktisk returnerte i produksjon – ikke bare i repoet.
Av de femten klyngene trengte én en sammenslåing, én trengte en omprioritering, to trengte en teknisk fiks, og resten trengte ingenting. Det forholdet er hovedgrunnen til at jeg aldri ville latt en agent hoppe rett fra «her er en cannibalization-rapport» til «her er sidene jeg slettet».
Tre funn jeg ikke ba om
1. 301-omdirigeringsreglene mine hadde sluttet å fungere i stillhet to måneder tidligere. Nettstedet mitt har et skript som genererer ekte 301-regler for Amplify å levere. Claude Code la merke til at utdatafilen ikke eksisterte, gikk tilbake gjennom git-historikken og fant at den var blitt slettet fem uker tidligere inne i en «update content»-commit som berørte over 21 000 filer – kollateralskade fra en bulk-synkronisering, ikke en bevisst avgjørelse. Den bekreftet på live-nettstedet at ingen av reglene var aktive (en flyttet URL returnerte en 404 der en omdirigering burde vært). Siden da hadde hver «omdirigering» på nettstedet faktisk vært et Hugo-alias: en side med status 200 og en meta-oppfriskning, ikke en ekte 301.
2. Det var ikke bare teoretisk. Den gamle URL-en til en side jeg hadde flyttet i juli, dukket fortsatt opp på egen hånd i Search Console – 188 visninger og tellende, to og en halv måned etter flyttingen. En meta-oppfrisknings-stubb som Google fortsetter å indeksere uansett, er nøyaktig hvordan et ødelagt alias-oppsett ser ut i praksis.
3. Den oppdaget sin egen feil. I trinn 1 hadde den flagget ett sidepar som et sannsynlig hreflang-problem, siden en oversatt versjon rangerte høyere enn den engelske originalen. I trinn 2 hentet den live HTML-en, sjekket at hreflang-taggene var absolutte og resiproke slik Google krever, og rapporterte at dette korrigerte det den hadde sagt første gang. Funnet gikk fra FIX til LEAVE. Jeg tar heller det enn et selvsikkert feil svar som står uimotsagt i en rapport.
Stay Updated on AI Visibility Trends
Get the latest insights on AI mentions, brand monitoring, and optimization strategies.
Trinn 3: Bruk fiksen på 16 språk
Godkjent. Anvend beslutningstabellen på denne grenen, ikke commit. 1) CONSOLIDATE […] uten å dikte opp fakta eller legge til tankestreker, slett deretter taperen på alle språk den finnes, legg dens gamle URL til vinnerens aliases på hvert tilsvarende språk, og omdiriger alle interne lenker til taperen i content/. 2) DIFFERENTIATE […] på alle språk, og legg til én kontekstuell lenke til vinneren. 3) FIX-TECHNICAL: sjekk git-historikken for å se om slettingen av static/_redirects var bevisst. Hvis den var utilsiktet, regenerer dem […] Hvis den var bevisst, ikke gjenopprett, bare fortell meg.
Den faktasjekket før den slo sammen noe. Siden som ble pensjonert hadde seksjoner som vinneren ikke hadde: en omtale av et konkurrerende verktøy, en produktvurderingsfunksjon og en oppsummering av gratisprøveperioder. Før noe av dette ble ført videre, hentet Claude Code leverandørenes live-nettsteder for å bekrefte at det fortsatt var korrekt.
Ett av de nevnte verktøyene viste seg å ha blitt kjøpt opp og stengt for nye registreringer uker tidligere, så det ble en korreksjon i stedet for noe som ble kopiert videre som gjeldende fakta. Tapsidens prispåstand for et annet verktøy var også i konflikt med tallet som allerede var verifisert på vinnersiden, så det verifiserte tallet ble beholdt og det utdaterte kom ikke med i sammenslåingen.
For FIX-TECHNICAL-tilfellet sjekket den om slettingen av omdirigeringer hadde vært bevisst før den rørte noe. Etter å ha bekreftet at den var utilsiktet (bulk-commiten som fjernet den berørte tusenvis av urelaterte filer uten noen omtale av omdirigeringer), regenererte den reglene og la til ekte 301-omdirigeringer for sidene som var berørt av sammenslåingen og den flyttede URL-en som fortsatt viste visninger under sin gamle adresse. For CONSOLIDATE og DIFFERENTIATE gjentok den den samme endringen på tvers av alle språk de berørte sidene fantes på – ikke bare engelsk – og kjørte deretter en full produksjonsbygging for å bekrefte at ingenting var ødelagt.
Hva nå
Etter at du har publisert nytt innhold, er det ikke slutten på jobben – det er bare begynnelsen. Å vite nøyaktig hvilke URL-er som stille konkurrerer med hverandre, hvilke som må slås sammen, og hvilke som bare trenger en teknisk fiks, er det som hindrer innholdet i å jobbe mot seg selv. Ingenting fra denne runden er i produksjon ennå; 28-dagers kontrollen, for å se om antallet kannibaliserte søk faktisk går ned, kommer som neste steg.
Hvis du ønsker å se en slik cannibalization-rapport for ditt eget domene, bestill en samtale så går vi gjennom det sammen.
