Hur jag byggde ett SEO-system istället för en SEO-prompt
Min första impuls med AI och SEO var ungefär densamma som många andras: bygg en riktigt bra prompt som kan researcha ett keyword, skapa outline, skriva text, optimera title/meta och lägga internlänkar. Det fungerar för en artikel.
Min första impuls med AI och SEO var ungefär densamma som många andras: bygg en riktigt bra prompt som kan researcha ett keyword, skapa outline, skriva text, optimera title/meta och lägga internlänkar. Det fungerar för en artikel. Det skalar betydligt sämre när sajten får hundratals URL:er och varje ny text påverkar informationsarkitekturen runt omkring.
Det var då jag började se SEO som ett systemproblem, inte ett skrivproblem.
En SEO-prompt ser bara den aktuella sidan
En enskild prompt kan göra mycket bra lokal optimering. Den kan analysera intent, föreslå headings och hitta relaterade entiteter. Men den har svårt att bära hela sajtens dynamik på ett robust sätt:
- Finns redan en sida med samma intent?
- Vilken pillar ska den här URL:en stärka?
- Vilka artiklar ska länka tillbaka?
- Är ämnet en egen canonical URL eller bara en sektion?
- Har ett tidigare contentbeslut blivit inaktuellt?
- Är den föreslagna search volume-siffran riktig data eller modellens gissning?
Det är därför mitt BijoyIQ-arbete började som 248 briefs men efter intent- och cannibalization-kontroll reducerades till 186 canonical URL:er. Systemets uppgift blev lika mycket att säga nej till nya sidor som att skapa dem.
Jag separerar sex lager
Mitt nuvarande SEO-upplägg går att beskriva i sex lager.
1. Topic och intent
Här försöker jag förstå vilket användarproblem som ska lösas och vilka närliggande intents som finns. Det är kvalitativ analys, inte sökvolym.
2. SERP-verifiering
Här kontrollerar jag vad som faktiskt rankar nu. Det kan avslöja att två rubrikidéer egentligen är samma intent eller att SERP:en domineras av en annan contenttyp än jag antog.
3. Canonical architecture
Här bestäms om ämnet får en egen URL, slås ihop med en annan eller blir supporting content. Det är ett redaktionellt/SEO-beslut som ska leva längre än den enskilda promptsessionen.
4. Production brief
Här definieras H1, intent, information gain, evidenskrav, källkrav, internlänkar och vad artikeln uttryckligen måste tillföra utöver SERP:en.
5. QA
Fact-check, editorial, SEO och internal-link review körs som separata kontroller. En text kan vara välskriven men ändå fel canonical. Den kan vara SEO-mässigt bra men sakna evidens.
6. Performance och underhåll
Efter publicering behöver Search Console/analytics och ändrade källor kunna påverka nästa beslut. Systemet ska kunna svara på vilka URL:er som berörs när en regel, produkt eller intent förändras.
Keyword-hypotes är inte keyworddata
En av de viktigaste säkerhetsreglerna i systemet är banal: LLM:n får gärna föreslå ett primary keyword, men den får inte hitta på sökvolym eller keyword difficulty.
Jag använder därför olika fält:
Det gör analysen mindre "komplett" på pappret men mer sann. Jag vill hellre ha ett tomt volymfält än ett professionellt spreadsheet med fabricerade siffror.
Information gain är en release gate
Google betonar people-first content, original information och first-hand expertise. För mig blir det operativt genom ett fält i briefen: Unique Information Gain.
För en artikel om claim-level fact checking kan information gain vara att jag faktiskt arbetat med 2 051 claims och kan visa datamodellen. För en artikel om Skills kan det vara riktig filstruktur och regressionstester. För SQL kan det vara ett konkret business-rule-problem snarare än fem generiska tips om "AI för dataanalys".
Om information gain inte går att formulera stoppar jag hellre artikeln. Det är ett starkare filter än "har vi ett keyword?".
Internal linking är en graf, inte en slutcheck
I många SEO-prompts kommer internlänkning sist: "lägg in tre relevanta internlänkar". Jag modellerar hellre relationen tidigare.
Varje supporting-artikel ska veta vilken pillar den stärker. Pillar ska länka ned till relevanta supporting-sidor. Dessutom kan det finnas broar mellan kluster, exempelvis från "model routing" till "AI-ekonomi" eller från "claim fact checking" till "AI governance".
Det gör internlänkar till informationsarkitektur i stället för pynt.
I Layer 3 byggde jag en separat internlänkningsgraf med hundratals föreslagna relationer. Den behöver fortfarande mänsklig/semantisk kontroll, men det är en bättre utgångspunkt än att varje Writer improviserar länkar från minnet.
Cannibalization behöver intent, inte bara textlikhet
En automatisk similarity-score är användbar för att hitta kandidater men inte för att fatta beslut ensam.
"Så bygger jag en Claude Code Skill" och "Från research paper till fungerande AI Skill" delar många ord men löser olika intents. Den ena är implementation/infrastruktur. Den andra handlar om att översätta evidens till exekverbara regler.
Omvänt kan två titlar använda helt olika ord men ändå konkurrera om samma SERP-intent.
Mitt system använder därför similarity som flagga, sedan granskas dominant intent och vilken unik fråga varje URL ska äga.
Research och writing är olika jobb
En annan förändring är att jag inte vill att Writer ska göra hela researchen samtidigt som den skriver. Researchlagret skapar source ledger och evidens. Writer får ett godkänt underlag.
Det gör två saker:
- Källor blir spårbara.
- Stilpasset kan inte i efterhand "förbättra" ett osäkert faktum till en självsäker formulering.
För SEO är det extra viktigt eftersom innehåll ofta uppdateras. Om jag vet vilka claims som bygger på en viss källa kan jag hitta berörda artiklar när källan ändras.
AI ska konsolidera, inte bara expandera
En av de bästa användningarna jag hittat är att låta AI leta efter saker som borde tas bort eller slås ihop.
När idébanken hade 248 artiklar var den lätt att imponeras av. Men topical authority byggs inte av antalet rader i en contentkalender. Om 62 briefs egentligen kan bli sektioner i starkare canonical-sidor är konsolidering en förbättring.
Jag använder därför AI för:
- clustering,
- intent-jämförelser,
- duplicate/cannibalization candidates,
- missing subtopics,
- internlänkningsförslag,
- QA mot content inventory.
Inte bara för att "skriva nästa artikel".
Systemet behöver state
När många artiklar produceras måste jag kunna se var de befinner sig. I BijoyIQ-repot går en artikel genom states från planned till [research](/blogg/finansiell-research-nar-gemini-claude-och-gpt-ar-bra-pa-olika-saker), evidence-ready, outline, draft, QA och ready.
Det här låter överdrivet för en blogg tills en batch har 30 artiklar och några saknar evidens, några behöver merge och andra väntar på uppdaterade källor. Då är ett manifest bättre än att försöka minnas allt i en chatt.
En SEO-prompt finns fortfarande – men på rätt nivå
Jag använder fortfarande prompts för exempelvis:
- SERP-intent-syntes,
- outline-kritik,
- entity gap analysis,
- title-varianter,
- meta description,
- redaktionell QA.
Skillnaden är att varje prompt verkar inom ett systemkontrakt. Den får inte bestämma canonical-arkitektur om det steget redan ägs av content architecture, inte fabricera keyworddata och inte ändra faktapåståenden under en humanizer-pass.
Det är där systemet blir robust: AI är fortfarande motorn i många steg, men den äger inte hela processen samtidigt.
Slutsats
Mitt SEO-system är inte byggt för att maximera antalet AI-artiklar. Det är byggt för att hålla ihop intent, canonical URLs, evidens, information gain, internlänkar och uppföljning över tid. En SEO-prompt kan optimera en sida. Ett SEO-system måste kunna avgöra om sidan ens borde existera.