AI-verktyg i SEO: min uppsättning och testerna som formade den

Min uppsättning AI-verktyg i SEO är språkmodeller, betalda data om Googles resultat, ett program som crawlar sajter och egna skript. Modellen är bra på att ordna data, beskriva dem och skriva kod. Resultatet av en enda hämtning av sökresultat eller ett enda svar från en modell kan ändå vara slumpmässigt. Därför visar jag testerna som ändrade hur jag använder verktygen. Jag gör ingen rankinglista från 1 till 10, eftersom jag inte har jämfört verktygen sida vid sida på samma data.

Vad gör AI bra i SEO, och vad gör den dåligt?

En språkmodell är bra på att läsa, ordna och skriva, men dålig på att räkna ur minnet och ser inte data som du inte ger den. Den 26 och 27 september 2026 testade jag språkmodeller på 17 typer av SEO-uppgifter, var och en på lätt och svår nivå. En del av typerna byggde jag på 103 jobbannonser för SEO-specialister. Annonserna nämnde oftast teknisk analys, rapportering och dataanalys. Av verktygen nämndes oftast Search Console, Google Analytics 4 (GA4), Ahrefs, Semrush och Screaming Frog.

De starkaste modellerna fick nästan 100 % i nästan varje typ av uppgift, så skillnaderna syntes först hos de svagare modellerna. Till toppen hörde bland andra Claude Opus 5.5, Fable 5.1, Codex och Gemini 3.1 Pro. Vid beräkning ur en fil på svår nivå fick Claude Haiku 4.5 2 av 10 poäng. Gemini 3.8 Flash med låg nivå av resonerande fick 1 av 10, och den lokala Gemma 4 12B 0 av 10. I uppgifter där modellen kunde räkna ut data med ett Python-skript fick alla testade modeller i molnet full poäng. Även de svagaste av dem fick full poäng. Data i de uppgifterna var exporter från Screaming Frog, 45 000 händelser från GA4 och en serverlogg med 160 000 rader. Därför görs beräkningarna i mitt arbete av ett skript som modellen skriver och kör.

Text på polska bedömdes blint av två modeller, och här var skillnaderna stora. De som bedömde visste inte vilken modell som hade skrivit texten. Skalan hade 5 steg, och 5 betydde en text som kan skickas till kunden utan rättelser. Bara Claude Opus 5.5 och Claude Sonnet 5 fick 5 på den svåra skrivuppgiften. Gemini 3.1 Pro fick 2, eftersom den hittade på ”gårdagens samtal” med mottagaren. Claude Opus som bedömare var strängare än Gemini som bedömare, både för Claudes svar och för de andra modellernas.

Samma modell kan ge ett annat resultat när samma test körs en gång till. Claude Haiku 4.5 fick i två körningar 62 och 39 poäng av 102. I texten om SEO-analys beskrev jag varför en AI-modell inte gör en fullständig analys av en sajt på egen hand.

Min uppsättning: vilket verktyg använder jag till vad?

Verktygen delar jag in efter sex användningsområden i arbetet och inte efter tillverkare. Samma modell förekommer inom flera användningsområden, eftersom jag använder den på ett sätt för att läsa data och på ett annat för kontroll. För varje användningsområde anger jag testet som fick mig att ändra arbetssättet.

Vilka språkmodeller använder jag, och till vad?

Huvudarbetet gör jag i Claude Code, alltså Claude som körs i terminalen med tillgång till filer, skript och data. Claude skriver och kör skript, läser exporter och förbereder utkast till rapporter. Codex (OpenAI) och Gemini (Google) får samma material för en andra kontroll.

Texter och rapporter kontrollerar jag med en andra modell från en annan tillverkare, i två omgångar. Den första omgången letar efter faktafel och luckor. Den andra omgången kontrollerar bara rättelserna, eftersom nya fel uppstår när man rättar. I oktober 2026 hittade den andra omgången i ett projekt ett felaktigt totalantal länkar i en guide, som procentandelen räknades från: 79 i stället för 76. Det felet uppstod först vid rättelserna. Mitt kontrollskript hittade det inte.

En modell som kvalitetsbedömare kan mäta något annat än en människa, så jag testar den på texter som jag redan har bedömt. Den 7 oktober 2026 lät jag två modeller bedöma 87 beskrivningar av Google-patent. Bland dem fanns 8 beskrivningar som jag själv hade bedömt som färdiga, utan att domarna visste det. Fable, en modell från Anthropic, bedömde 5 av de 8 som färdiga. Codex med hög nivå av resonerande bedömde 1 av 8.

De två resultaten säger bara något om texter som jag själv bedömde som färdiga. De övriga 79 beskrivningarna bedömde jag inte, så jag vet inte hur många av avslagen som var befogade. Codex avslog sammanlagt 51 av 87 beskrivningar, eftersom den jämförde varje mening i beskrivningen med patentkraven, alltså patentets juridiska omfattning. Överensstämmelsen mellan domarna var nära vad man kan förvänta sig av slumpen. Cohens kappa blev 0,06, där 0 betyder slumpmässig överensstämmelse och 1 full.

Lokala modeller på min egen dator med grafikkort använder jag för att klassificera stora datamängder, eftersom jag inte betalar för varje enskilt fall. Den 1 oktober 2026 testade jag lokala modeller på fyra enkla uppgifter. Data var sidor från tre polska webbutiker. Gemma 4 31B kände igen typen av sida i 98,5 % av 403 sidor. Typerna av sidor är produkt, produktlista, artikel eller annat. Ett skript med regler träffade rätt på 84 % av samma sidor.

Gemma läste av priserna nästan utan fel och bedömde överensstämmelsen mellan siffror, men en del av referenserna i testet kom från en modell och inte från en människa. Referensen för typ av sida var etiketter från ett skript som Claude Opus hade rättat. Gemma läste av priset rätt på alla 177 produktkort. Referensen var priset i den strukturerade datan, som stämde med sidans text. I 99,3 % av 134 fall bedömde Gemma rätt om siffran i en mening stämde med data. I hälften av de meningarna var siffran ändrad med flit. Gemma kände också igen typen av efterfrågan i ett sökord (erbjudande, utanför erbjudandet eller råd) i 97,7 % av 218 sökord. Referensen var här etiketter från Claude Opus.

Samma modellfamilj misslyckades när den jämförde siffror mellan två filer i ett verkligt erbjudande. Den 12 oktober 2026 jämförde två versioner av Gemma 4, 26B och 31B, 63 rader och rapporterade bara falska motsägelser. De ansåg till exempel att ”-34 %” och ”en tredjedel” var motstridiga värden. Det enda verkliga problemet i den texten gällde inte siffror utan ett överdrivet ord vid ett resultat i tabellen. Det hörde alltså inte till Gemmas uppgift. Nu kontrollerar ett skript att varje siffra i den ena filen finns i den andra. Det är en kontroll av att siffrorna finns med, och betydelsen kontrollerar en människa eller en andra modell.

Vilka verktyg använder jag för data om placeringar och efterfrågan?

Data om Googles resultat hämtar jag från DataForSEO, Search Console och Ahrefs, och var och en av källorna har sin egen fallgrop. DataForSEO säljer hämtningar av Googles resultat och data om efterfrågan mot betalning för varje sökning. Från 17 september till 14 oktober 2026 beställde jag där 17 076 uppdrag för 99,89 USD. Bland dem fanns 13 085 hämtningar av Googles resultat.

En enda hämtning av resultat räcker inte för att mäta placering, eftersom efterföljande hämtningar för samma sökord ser olika ut. Den 7 oktober 2026 hämtade jag resultat för 94 sökord tre gånger med en timmes mellanrum och två gånger i samma minut, för 1,57 USD. Sedan jämförde jag domänerna i topp 10 i två hämtningar för samma sökord. De gemensamma domänerna utgjorde i median cirka 15 % av alla olika domäner från de två hämtningarna. I hämtningar från samma minut var det cirka 8 %. Ett sökord hade i median 4 varianter av resultat. Därför räknar jag i stället för placering andelen hämtningar där domänen finns i topp 10. Hämtningarna är cirka 10 och jag skickar dem samtidigt.

Den mätningen ogiltigförklarade mitt tidigare test, där jag jämförde placeringen från en enda hämtning med citeringar från fem hämtningar. Testresultatet ”godkänt” visade sig vara falskt, så jag stoppade testet. AI Overview, alltså Googles AI-svar ovanför resultaten, var stabil i den här mätningen: den förekom i 97-99 % av hämtningarna, och listan över citerade sidor ändrades inte.

Search Console visar klick som Google själv har mätt, men exporten från panelen kapar tabellen vid 1 000 rader. Tusen sökfrågor sorterade efter klick är den mest klickade delen av data. Den 20 september 2026 visade exporten från panelen på en sajt en CTR på 4,28 % för placering 1-3 i USA. CTR är andelen visningar som slutar i klick. Data från 16 månader som hämtades utan gränsen på 1 000 rader, alltså 123 498 sökfrågor, gav 1,40 %. Sådana data hämtar jag via API:et för Search Console, alltså ett gränssnitt för program. Det andra sättet är en rapport i Looker Studio, Googles gratisverktyg för rapporter, med kopplingen till Search Console.

Ahrefs använder jag för länkar, sökord och konkurrenter, men trafikuppskattningarna kontrollerar jag i Search Console. Trafikkolumnen i Ahrefs Rank Tracker är en uppskattning: uppskattad efterfrågan multiplicerad med en antagen klickandel. På en sajt var den uppskattningen 10-50 gånger högre än klicken i Search Console, och på en annan cirka 3 gånger lägre. Rank Tracker räknar också block på resultatsidan som placeringar. I ett fall betydde ett fall från plats 1 till plats 13 bara att en AI Overview hade dykt upp ovanför resultaten.

Vilka verktyg använder jag för teknisk analys?

Till analysen använder jag Screaming Frog och Chrome utan fönster, och AI-modellen läser resultaten men ersätter inte crawlen av sajten. Screaming Frog går igenom sajten som en sökmotorrobot. Chrome som körs utan fönster visar sidan efter att JavaScript har körts, så jag jämför de två versionerna av sidan. I en analys gav en crawl med JavaScript och en utan, körda parallellt, en falsk signal om renderingen. Sedan dess kör jag dem efter varandra.

När brandväggen på den analyserade sajten blockerar mitt crawlprogram hämtar jag enskilda adresser via tjänsten Apify Web Fetch. I testet den 12 oktober 2026 läste tjänsten 8 av 8 sidor som jag inte kunde hämta från min IP-adress. Två av dem tillhörde kunders sajter och sex offentliga sajter med omdömen, jämförelsetjänster och webbutiker. Det kostade 0,00155 USD per adress. Tjänsten rapporterade dock ibland en lyckad hämtning med koden 200, fastän den bara hade hämtat en verifieringssida. En mycket kort text eller en text om verifiering ser jag därför som en blockering och hämtar om.

Den tjänsten visar inte vad en riktig Google-robot eller AI-robot ser. Den ansluter från en annan IP-adress, och även när jag anger en robots namn avslöjar de övriga headrarna en vanlig Chrome-webbläsare. Blockeringar av robotar kontrollerar jag därför i Search Console och med ett eget skript som jämför serverns svar för olika robotar. I texten om filen llms.txt beskrev jag hur jag via IP-adressen kontrollerar om en förfrågan skickades av en riktig robot.

Assistenten för tekniska analyser byggde jag på min byrås analyser från 2020-2026, och jag mäter den mot analyser som en människa har gjort tidigare. Assistenten är en AI-agent som samlar in data om sajten och kontrollerar dem mot en regelkatalog som skrivits ner utifrån de analyserna. Analysens omfattning och prioriteringar godkänner jag själv, i början av arbetet och innan analysen skickas. Resultatet av mätningen lägger jag till här efter den andra mätningen på en ny sajt.

Vilka verktyg använder jag för innehåll och semantik?

Ett sökord kopplar jag till en sida med hybridsökning, eftersom den tidigare versionen av mitt verktyg bara träffade rätt på en tredjedel av sökorden. Den 14 oktober 2026 tog jag sökord från Search Console för två sajter, utan sökord med varumärkesnamn. För varje sökord var referensen den sida som hade fått minst 60 % av klicken på sökordet och som fanns bland sajtens crawlade sidor. Den tidigare versionen av verktyget använde modellen MiniLM för embeddings, alltså omvandling av text till en vektor av tal. Den pekade ut referenssidan som första träff för 34 % av sökorden.

Hybridsökningen slår ihop tre listor med sidor och träffade referenssidan för 80,5 % och 77,1 % av sökorden. Den första listan kommer från modellen e5-large. Den andra är sökning på ord i innehållet och den tredje på ord i titeln, rubriken H1 och adressen. Listorna slår jag ihop med metoden RRF, som belönar sidor som ligger högt på flera listor samtidigt. Den bästa enskilda modellen för embeddings var olika på varje sajt, och hybriden vann på båda.

I det här testet hittade jag ett fel i mitt eget verktyg: modellen såg inte slutet på de flesta textfragmenten. Skriptet delade texten i fragment om 80 ord, men modellen tar emot 128 tokens, alltså ordbitar. Polska ord delas upp i fler tokens än engelska, så 89-98 % av fragmenten kapades. Resultatet på 34 % gäller alltså den tidigare versionen av verktyget med det felet och inte själva modellen MiniLM. Testet mäter överensstämmelse med klicken i Google och inte vilken sida som svarar bäst på sökningen.

Entiteter, alltså namn på företag, produkter, personer och begrepp, tar jag ur texter med den lokala modellen GLiNER2. I mitt test från juli 2026 hade modellen F1 0,94 på polska texter, lika mycket som på engelska. F1 sammanfogar träffsäkerhet och fullständighet, och 1 betyder ett perfekt resultat. Resultatet gäller etiketter som inte överlappar. När etiketterna ”företag” och ”varumärke” fanns i samma fråga sjönk F1 till 0,85. Modellen körs på en vanlig processor, cirka 20 stycken i sekunden, utan avgift per sida.

GLiNER2 använder jag inte för att känna igen avsikten bakom sökord, eftersom den i mitt test bara träffade rätt i 33-42 % av fallen. Den hade ofta fel med säkerheten 0,99, alltså nästan den högsta säkerhet som den själv anger.

Ämneskartan för den här serien texter gjorde jag av entiteter från 71 konkurrentsidor från Polen och USA. Skriptet tog fram 110 entiteter och 1 764 tripletter, alltså uppgifter i formen entitet, egenskap och värde. Data kostade 0,072 USD. Kartan visade de olika texternas roller, par av texter som ska kopplas ihop med länkar och ämnen som saknas på den här sajten.

Vilka verktyg använder jag för länkbygge?

Till länkanalys använder jag Ahrefs, men länkar som markerats som förlorade kontrollerar jag live innan de hamnar i slutsatserna. I oktober 2026 visade Ahrefs i ett projekt 360 polska domäner som förlorade. 140 av dem länkade fortfarande med samma adress. Cirka 70 adresser svarade med felet 403 när jag hämtade dem med ett vanligt program, så jag kontrollerade dem i en webbläsare som styrs av ett skript (Playwright).

Jag är med och driver Linko, en länkplattform, så jag beskriver den inte här som ett verktyg från ett annat företag. I texten om länkbygge beskrev jag hur jag bedömer sajter innan jag köper publiceringar. I texten om länkbygge i AI-eran beskrev jag hur AI hjälper till att förbereda publiceringar och kontakt med utgivare.

Vilka verktyg använder jag för att mäta synlighet i AI?

Verktygen för att mäta ett varumärkes synlighet i AI beskrev jag i en separat text, så här anger jag bara principen. Omnämnandet av varumärket i svaret och citeringen av dess sida räknar jag var för sig. Varje fråga ställer jag flera gånger, eftersom assistenternas svar ändras. I texten om AI-synlighet beskrev jag mätningen, antalet upprepningar och verktygens fallgropar. I texten om AI SEO och GEO beskrev jag vad jag gör på sajten för att AI-assistenter ska kunna citera den.

Vilka SEO-verktyg har vi byggt själva?

När inget verktyg svarar på min fråga skriver jag ett eget skript med hjälp av AI. De flesta av skripten används i det interna arbetet: crawl, hämtning av data, entiteter, kontroll av texter och siffror. Innan jag börjar använda ett skript i arbetet testar jag det på data med ett känt rätt svar.

I VerticalSEO förbereder vi 16 SEO-verktyg som blir tillgängliga via en sajt och via API, även för AI-agenter. Verktygen är inte publicerade än. Testerna den 8 oktober 2026 kontrollerade om verktygen fungerar enligt specifikationen. 610 av 610 API-tester och 325 av 325 tester av verktyg för agenter i webbläsaren klarades. Verktygen fungerar enligt standarden WebMCP, som gör sajtens funktioner tillgängliga för AI-agenter. Testerna mäter ännu inte om verktygen ger träffsäkra SEO-slutsatser.

Testet av verktyget för att kontrollera entiteter visade att enbart namnet inte räcker för att peka ut en entitet. Jag sökte den polska handelsplattformen Allegro, men verktyget valde ur Googles kunskapsgraf, alltså dess databas över entiteter, ett verk av Vivaldi. Under mitt för- och efternamn valde det en skådespelare. Nu bekräftar verktyget en entitet först när Google kopplar entiteten till den sida som kontrolleras. Bekräftelsen kan också vara en identifierare som Wikidata eller sidans strukturerade data pekar ut.

LemmeGSC, min panel för data från Search Console, förbereder jag för lansering som öppen programvara. Panelen hämtar data från Search Console utan gränsen på 1 000 rader. Den visar bland annat kannibalisering av sökord, alltså flera sidor på en sajt på samma sökord.

Vilka gratis SEO-verktyg räcker i början?

I början räcker Search Console, Looker Studio, den gratis versionen av en AI-assistent och den gratis versionen av Screaming Frog. Verktygen har var sin roll:

• Search Console visar klick, visningar och sökfrågor från Google;
• Looker Studio med kopplingen till Search Console hämtar samma data utan gränsen på 1 000 rader;
• den gratis versionen av en AI-assistent grupperar sökord och skriver utkast och skript, om du ger den data;
• den gratis versionen av Screaming Frog crawlar upp till 500 adresser, vilket räcker för en liten sajt.

Betalda verktyg för sökord och länkar är värda att lägga till först när du vet vilken fråga de ska svara på. En gratis AI-assistent känner inte till dina data från Search Console. Den ger mest när den får en export av dig och en begäran om ett skript som räknar ut resultatet.

Hur testar jag ett AI-verktyg innan jag litar på det?

Verktyget testar jag på data där jag känner till rätt svar. Inte alla tester i den här texten hade alla element i listan nedan. I testet av lokala modeller rättades referensen för typ av sida av en modell och inte av en människa. I dag har ett test de här elementen:

• en referensmängd av beslut från en människa eller av data från Google, till exempel sidan med en majoritet av klicken på ett visst sökord;
• ett förväntat resultat som är nedskrivet innan testet körs;
• en upprepning av samma körning, eftersom en enda körning av en modell eller en enda hämtning av resultat kan vara slumpmässig;
• fall med ett medvetet inlagt fel, för att se om kontrollen upptäcker det;
• kostnad och tid per enhet;
• siffror som kontrollerats av ett skript och inte av en modell.

Data till testerna kostade mig lite, och mest arbete kräver referensmängden. Testet av hämtningar av resultat kostade 1,57 USD och data till ämneskartan för serien 0,072 USD. En referensmängd kräver en tidigare bedömning av en människa. De angivna kostnaderna omfattar inte det arbetet.

Testresultatet skriver jag ner tillsammans med det som testet inte kontrollerade. För kopplingen mellan sökord och sida känner jag till överensstämmelsen med klicken i Google, men jag vet inte om den utpekade sidan svarar bäst på sökningen. För de lokala modellerna kontrollerade jag fyra enkla moment och inte fullständiga arbetsuppgifter. Utan en sådan anteckning är det lätt att tro att ett testresultat är bredare än det är.

Vanliga frågor om AI-verktyg i SEO

Var ska man börja?

Börja med en uppgift som du gör varje vecka och med data som du redan har i Search Console. Ge modellen alla data och be om ett skript som räknar ut det du i dag räknar för hand. Jämför resultatet med ett tiotal fall som du kontrollerar själv. Först när resultaten stämmer kör du skriptet på alla data. I texten om SEO-strategi beskrev jag vilka data från Search Console jag kontrollerar i början av arbetet.