BijoyIQ
AI & automation

Så använder jag AI för Semantic SEO utan att massproducera skräp

AI gör det nästan löjligt enkelt att skapa en lista med 500 SEO-artiklar. Det är också ett av de snabbaste sätten att bygga 500 sidor som ingen behöver.

Shadip Rahman 10 september 2026 14 min läsning
Dela

AI gör det nästan löjligt enkelt att skapa en lista med 500 SEO-artiklar. Det är också ett av de snabbaste sätten att bygga 500 sidor som ingen behöver. När jag använder AI för Semantic SEO försöker jag därför optimera för något annat än volym: täck rätt informationsbehov med minsta uppsättning starka URL:er.

Den skillnaden blev tydlig i mitt eget arbete. Ett tidigare Semantic SEO-upplägg gav i ett case ungefär +139 procent klick, +128 procent impressions och förbättrad genomsnittlig position från 25,5 till 14,2. Det jag tog med mig därifrån var inte "publicera mer". Det var att struktur, täckning och relationen mellan sidor spelar större roll än att varje tänkbar keyword får en egen text.

Semantic SEO är inte ett synonym för många artiklar

Jag använder begreppet praktiskt: förstå vilka ämnen, entiteter, relationer och sökintentioner som krävs för att behandla ett område heltäckande. Problemet med AI är att den gärna extrapolerar. Ge den ett seed keyword och den kan skapa 20 varianter av samma fråga, 30 nästan identiska "hur gör man"-artiklar, ortssidor, årtalssidor, FAQ-sidor och jämförelser som ingen faktiskt efterfrågat.

Det ser ut som topical coverage i ett spreadsheet. I verkligheten är det ofta cannibalization och commodity content.

Google är tydliga på den punkten. Deras aktuella guidance för generativ AI säger att AI kan vara användbart för research och struktur, men att stora mängder sidor utan mervärde kan falla under scaled content abuse. I den nyare guiden för generativa sökfunktioner betonas unik synvinkel, first-hand experience och non-commodity content, samtidigt som de uttryckligen avråder från att skapa separata sidor för varje tänkbar query-variation.

Mitt flöde börjar med intent, inte rubrik

När jag bygger en topical map försöker jag först identifiera dominerande intents. För ett kluster om AI Skills kan de exempelvis vara:

  1. Vad är en Skill?
  2. Hur bygger man en Skill?
  3. SKILL.md vs system prompt vs agent.
  4. Hur gör man en Skill från forskning/PDF?
  5. Hur testar och versionshanterar man Skills?

Sedan frågar jag: vilka av de här behöver en egen canonical URL och vilka är egentligen sektioner i samma artikel?

Det är precis vad som hände i BijoyIQ-planen. En första idébank gav 248 briefs. Efter cannibalization- och intent-kontroll reducerade jag den till 186 canonical URL:er. De 62 "försvunna" idéerna kastades inte bort. Många blev sektioner eller omvinklades till tydligare intents. Det är en viktig SEO-funktion som AI är bra på: konsolidering, inte bara expansion.

Jag separerar topical map från keyworddata

En annan regel jag använder är att inte låtsas att en språkmodell vet sökvolym.

Jag kan använda AI för att formulera keyword-hypoteser och entiteter, men fält som volym och keyword difficulty måste komma från faktisk data om de ska anges som siffror. Min pipeline skiljer därför på:

Det förhindrar en märkligt vanlig anti-pattern: ett mycket professionellt SEO-dokument med helt påhittade volymer.

Information gain som obligatoriskt fält

Det viktigaste fältet i mina briefs är numera inte primary keyword. Det är Unique Information Gain. Varje artikel måste svara på frågan:

Vad finns här som inte kan produceras genom att bara sammanfatta de fem första sökresultaten?

För BijoyIQ kan svaret vara min faktiska Skill-filstruktur, ett research → evidence → SKILL.md-flöde, en riktig agent-handoff, ett misslyckat prompt-exempel och den spec som ersatte det, 2 051 claims från ett verkligt fact-checking-case, SQL eller evals från ett byggt system, eller före/efter från ett faktiskt workflow.

Om jag inte kan fylla det fältet är artikeln ofta inte redo att skrivas. Det ligger nära Googles people-first-kriterier, där de bland annat frågar om sidan tillför originalinformation, analys och first-hand expertise utöver det uppenbara.

AI ska hjälpa till med arkitekturen. Jag använder AI mycket för sådant som är jobbigt manuellt men fortfarande går att granska:

  • Topical clustering. Gruppera hundratals idéer efter intent och entitetsrelationer.
  • Cannibalization detection. Jämför titel, primary intent och semantisk överlappning. Flagga kandidater för merge – besluta inte automatiskt.
  • Pillar/supporting-design. Bestäm vilka sidor som ska vara hubs och vilka som ska lösa smalare problem.
  • Internal-link graph. Skapa förslag på parent-pillar, siblings och broar mellan relaterade kluster.
  • Content brief generation. Fyll struktur, researchkrav och QA-kriterier konsekvent.

Det jag inte vill automatisera blint är själva publiceringsbeslutet.

Ett praktiskt content contract

Min nuvarande artikelbrief innehåller bland annat:

Det gör att writern inte behöver "uppfinna SEO:n" under skrivandet. SEO-arkitekturen är redan beslutad.

Varför AI-texten måste komma sent. Det här är kanske den viktigaste delen. Om AI börjar skriva innan research, evidens och struktur är klara får du en text som ser färdig ut för tidigt. Sedan blir varje efterföljande steg en redigering av något modellen redan har bestämt. Jag vill hellre ha:

Då blir språkmodellen en writer inne i systemet, inte systemet självt.

Målet är färre, starkare sidor

Den mest användbara förändringen i mitt sätt att arbeta är att jag inte längre frågar:

"Hur många artiklar kan vi skapa om det här ämnet?"

Jag frågar:

"Vilken minsta uppsättning URL:er gör att vi täcker området bättre än det som redan finns?"

AI är fantastisk för att hitta luckor. Den är lika bra på att skapa falska luckor genom att formulera samma intention på 30 sätt.

Semantic SEO med AI kräver därför en broms lika mycket som en accelerator: canonical intent, consolidation, information gain, evidens och internlänkningsarkitektur. När de finns kan AI skala hantverket. Utan dem skalar den mest mängden text.

Så bygger jag själva topical mapen

Jag brukar börja med flera typer av input, inte bara ett keyword-export:

  1. Seed topics. De stora problemen produkten eller sajten faktiskt kan något om.
  2. Frågor. Autocomplete, People Also Ask, forum, kundfrågor, interna sökningar och egna supportärenden där sådana finns.
  3. Entiteter. Produkter, tekniker, myndigheter, processer, modeller, standarder och begrepp som krävs för att förklara huvudämnet.
  4. SERP patterns. Vilken typ av sida rankar? Guide, definition, jämförelse, verktyg, forum, dokumentation, video?
  5. First-party expertise. Vilka frågor kan jag besvara bättre därför att jag faktiskt har byggt, testat eller mätt något?

Det sista fältet får hög vikt på BijoyIQ. Jag har mycket hellre 80 ämnen där jag kan visa riktiga artefakter än 800 där jag bara kan återberätta internet.

Från 248 briefs till 186 URL:er

Konsolideringen i det här projektet är ett konkret exempel. Första idégenereringen gav 248 briefs över Skills, Humanizer, prompting, agents, model routing, SEO, fact checking, översättning, CV, finansiell analys, SQL, n8n och AI product engineering. Det var en användbar idébank men inte automatiskt en bra sitemap. Nästa lager lade på pillar/supporting, funnel, authority potential, originality, first-hand evidence och internlänkningsrelationer.

Sedan kom cannibalization-kontrollen. 83 briefs flaggades initialt som hög risk utifrån titel/keyword-similarity. Efter intent- och SERP-rescoping landade produktionsplanen på 186 canonical URL:er. Den processen är viktig eftersom den illustrerar skillnaden mellan content inventory och search architecture.

Cannibalization är inte bara keyword overlap

Två sidor kan använda olika ord och ändå konkurrera om samma intention. Exempel:

  • "Så bygger du en Claude Code Skill"
  • "Skapa SKILL.md från grunden"
  • "Guide: bygg en återanvändbar Skill för Claude Code"

Det kan vara tre rubriker men en dominerande intent. Samtidigt kan samma head term motivera flera sidor om intentionen faktiskt skiljer sig: definition, implementation, felsökning, jämförelse, avancerad metodik.

Därför använder jag titel-similarity som flagga, inte som beslut. Det slutliga beslutet kräver att man tittar på user task och SERP.

Internal linking som kunskapsmodell

Jag försöker inte se internlänkar som en lista med "relaterade artiklar". I en bra clusterstruktur signalerar länken relationen mellan ämnen. Exempel:

Supporting-sidor länkar upp till pillarn. Pillarn länkar ned till centrala children. Siblings länkas där läsaren faktiskt behöver nästa koncept. Jag lägger också broar mellan kluster:

Då blir sajten en kunskapsgraf för läsaren, inte bara en katalog för crawlers.

Search intent före "SEO score". Jag är skeptisk till contentverktyg som komprimerar en artikel till en SEO-score baserad på termfrekvens. Om intentionen är fel hjälper det inte att texten innehåller 37 rekommenderade termer. Min ordning är hellre:

  1. matchar sidan rätt task?
  2. har den information gain?
  3. täcker den nödvändiga entiteter och subfrågor?
  4. är viktig evidens verifierad?
  5. är strukturen lätt att använda?
  6. först därefter: title, meta, entities, snippets, schema och andra on-page-detaljer.

Det är också därför live SERP-kontrollen kommer före skrivandet i viktiga artiklar.

AI Overviews och AI Mode ändrar inte grundprincipen. Det är lätt att göra "GEO/AEO" till ett separat magiskt område. Googles egna 2026-råd är mer jordnära: de klassiska SEO-grunderna fortsätter vara relevanta, och för generativa sökupplevelser lyfter de unikt, användbart, non-commodity content och first-hand perspective. För mig förstärker det skälet att bygga artiklar runt verkliga projekt.

En generisk text om "vad är en AI-agent?" har svårt att vara unik. En artikel som visar exakt hur jag delade en content pipeline i nio agents, vilka handoff-kontrakt jag använde och vilket fel som gjorde att jag korrigerade arkitekturen har ett annat informationsvärde.

Programmatic SEO: en separat riskklass

Jag är inte emot programmatic SEO. Men ju fler sidor som genereras från en template, desto hårdare vill jag kontrollera uniqueness. Jag skulle kräva exempelvis:

Om en sida bara byter stad, modellnamn eller keyword men informationen är densamma ska den normalt inte existera som egen sida. Det är precis den typ av scaled low-value pattern Google varnar för oavsett om en människa eller AI producerar den.

Mallnivå kräver egna kvalitetsgrindar

Det som gör programmatic SEO svårare att säkra än en enstaka artikel är att ett svagt beslut i en mall multiplicerar samma fel över hundratals URL:er. Jag lägger därför kvalitetskontrollen på templatenivå, inte bara på enskilda sidor. Dynamiska fält valideras innan språkmodellen skriver prosa: saknad data ska ge en blockerad sida, inte en modell som fyller luckan med en rimlig gissning. Cannibalization mellan sidtyper testas också innan tusen URL:er genereras, inte efter, eftersom två malldesigner som löser samma intent annars sprider samma problem lika snabbt som de sprider sidorna. Och efter lansering följer jag vilka mallar som faktiskt får impressions, klick och indexering per template — programmatic SEO utan den feedbackloopen blir bara programmatic publishing.

Search Console blir feedbackloopen

Efter publicering vill jag inte bara titta på ranking för ett target keyword. Jag vill se vilka queries sidan faktiskt får impressions för, vilka nya intents Google associerar sidan med, om två URL:er börjar konkurrera, vilka supporting-sidor som börjar få trafik, CTR där positionen redan är rimlig, vilka kluster som saknar impressions helt, och om en pillar drar in bredare query space över tid.

Den informationen går sedan tillbaka in i topical mapen. Det kan leda till att två sidor mergas, en stor sida delas, internlänkar ändras, en ny supporting-artikel skapas, eller att title/intro justeras för en intent som faktiskt syns.

Semantic SEO blir då ett adaptivt system, inte en engångslista med 200 rubriker.

Hur jag använder AI utan att låta AI bli strategen

AI är bra på att producera kandidater snabbt. Jag använder den för clustering, entity extraction, intent hypotheses, duplicate detection, brief skeletons, internal-link candidates, missing-subtopic analysis och schema/metadata QA.

Men systemet kräver externa signaler: SERP, Search Console, analytics, first-party business data och faktisk expertis.

Annars riskerar man att AI först hittar på en contentstrategi och sedan använder sin egen strategi som bevis för att fler artiklar behövs.

En publiceringsregel jag gärna behåller. För varje ny URL vill jag kunna fylla i den här meningen:

Den här sidan bör finnas separat därför att användaren har intention X, och vi kan tillföra Y som inte täcks bättre av canonical-sidan Z.

Om jag inte kan formulera X, Y och Z är merge ofta bättre. Det är en enkel broms mot den naturliga tendensen i generativ AI: expansion utan kostnadskänsla.

Hur jag prioriterar vilka artiklar som ska skrivas först

En topical map är inte en publiceringsplan förrän den prioriterats. Jag väger åtminstone fem saker:

  1. Authority potential – stärker artikeln det område jag faktiskt vill bli förknippad med?
  2. Originality – har jag något eget att tillföra?
  3. First-hand evidence – finns ett case, artefakt eller data?
  4. Business relevance – leder ämnet naturligt till det jag bygger eller kan hjälpa med?
  5. Search opportunity – finns en verklig efterfrågan och en SERP där vår sida kan bidra?

Det är därför en artikel med låg head-term-volym ibland bör publiceras före en bred guide. En djup build log om research paper → Skill kan bygga mycket starkare expertposition än ännu en allmän "10 bästa AI-verktygen"-artikel.

Content pruning börjar redan före publicering

Jag vill helst pruna idéer innan de blir URL:er. Det är mycket billigare att slå ihop två briefs än att ett år senare försöka merge två indexerade sidor med länkar, historik och rankingsignaler. Layer 4 i min egen plan gjorde därför något som jag tycker fler AI-contentprojekt borde göra: den reducerade outputen. 248 idéer blev 186 canonical-artiklar. Det är ett bättre användningsfall för AI än "ge mig 500 fler keywords".

Jag skiljer mellan topical completeness och textual completeness. En sida behöver inte säga allt om ämnet för att klustret ska vara komplett. Pillarn ska orientera och länka vidare. Supporting-sidan ska lösa sin uppgift ordentligt. Om varje artikel försöker bli "den ultimata guiden" får man repetition, långa intros och samma bakgrundssektion överallt.

Jag vill därför att content architect frågar vad läsaren måste förstå här, vad som kan länkas till en annan canonical sida, och vilken information som inte ska dupliceras. Det ger kortare och tydligare vägar genom sajten även när total kunskapstäckning är stor. AI har gjort topical research, clustering och briefproduktion dramatiskt billigare. Därför har den verkliga SEO-kompetensen flyttat ett steg upp: vad ska inte bli en sida?

Mitt mål med Semantic SEO är inte maximal contentproduktion. Det är en arkitektur där varje URL har ett tydligt jobb, varje kluster har en logik och varje artikel kan visa något som är svårare att kopiera än en sammanfattning av sökresultaten.

Vad jag inte skulle automatisera från dag ett. Jag skulle inte låta AI publicera nya URL:er automatiskt bara för att en gap-analysis hittar en "lucka". Jag skulle inte heller låta den skapa redirects, canonical-taggar eller slå ihop indexerade sidor utan review. De besluten påverkar informationsarkitekturen och kan få långvariga konsekvenser.

AI får gärna lämna ett förslagspaket: berörda URLs, överlappande intents, rekommenderad canonical, internlänkar som måste ändras och risker. Men beslutet bör granskas mot Search Console, backlinks, trafik och den faktiska SERP:en.

Det är samma mönster som i andra agentflöden: använd AI för analys och kandidater; håll irreversibla eller SEO-kritiska mutationer bakom ett gate tills systemet bevisat att det kan hantera dem.

Semantic SEO som redaktionell disciplin. Den bästa effekten av topical mapping är kanske inte ranking utan att den tvingar fram redaktionella beslut. Vad är vår huvudsida? Vad hör hemma där? Vilket ämne är en separat fördjupning? Vad vet vi själva? Vad måste researchas? När de frågorna är besvarade blir AI-skrivandet lättare och mindre generiskt. Writern behöver inte uppfinna vinkel, scope och internlänkar samtidigt som den försöker skriva bra svenska.

Den enklaste anti-skräp-regeln

Jag skulle kunna sammanfatta hela metoden med en publiceringsfråga: om Google inte fanns, skulle den här URL:en fortfarande vara värd att skapa för vår målgrupp? Om svaret är nej behöver jag ett mycket starkt skäl att publicera den.

Det testet är inte perfekt, men det avslöjar snabbt sidor som bara existerar för att fånga en query-variant. För BijoyIQ vill jag att artikeln ska vara användbar även för någon som kommer via ett direktlänk, ett nyhetsbrev eller en AI-citering och aldrig har sett sökresultatet.

Det gör också redaktionell prioritering enklare: varje ny sida måste motivera sin existens med en verklig uppgift, ett eget informationsvärde och en tydlig plats i kunskapsstrukturen. AI får gärna hjälpa till att hitta kandidaterna. Den får inte automatiskt göra varje kandidat till en URL.

Källor och vidare läsning

Relaterade artiklar

SEOSEO och AI-search
Dela
Fler artiklar