SEO-analys: så gör jag en SEO-analys av en webbplats steg för steg

En SEO-analys (en SEO-audit) är ett beslut om vad på sajten som ska rättas först, med belägg för varje rekommendation och ett sätt att kontrollera efter genomförandet. Listan med fel ur ett verktyg är bara underlag för analysen. En teknisk SEO-analys är den del som kontrollerar om sökmotorernas och AI-assistenternas robotar kan hämta och läsa sajten, och om sökmotorn kan indexera den.

Jag gör en SEO-analys i åtta steg:

1. Jag fastställer sajtens mål och situation innan jag startar en crawler, alltså ett program som går igenom en sajt på samma sätt som en sökrobot.
2. Jag kontrollerar om robotarna över huvud taget får sajten.
3. Jag samlar data från flera källor och kontrollerar vad var och en av dem inte ser.
4. Jag undersöker sökord och Googles resultat innan jag tar itu med tekniken.
5. Jag går igenom sajten enligt en problemkatalog med villkor för prioritet.
6. För varje punkt visar jag belägg.
7. Jag bestämmer ordning, arbetsinsats och alternativ.
8. Jag lämnar resultatet till korskontroll, och efter genomförandet kontrollerar jag varje punkt.

Vad är en SEO-analys och vad skiljer en teknisk SEO-analys?

En SEO-analys visar i vilket skick sajten är och vad som begränsar dess synlighet, och en teknisk SEO-analys kontrollerar om sökmotorn kan hämta, rendera och indexera sajten. I en fullständig analys kontrollerar jag teknik, arkitektur och innehåll på sidorna, sökord, externa länkar och konkurrenter, och till sist lägger jag ordningen på åtgärderna. En teknisk analys räcker när frågan är teknisk: ett ras efter en lansering, en migrering, sidor som ramlar ur indexet.

En SEO-analys är ingången till en strategi, inte en strategi. Strategin säger vilken efterfrågan du tävlar om och vad du avstår från, och analysen säger vad som i dag står i vägen för det. I texten om SEO-strategi beskrev jag hur det ena går över i det andra.

Hur gör du en SEO-analys steg för steg?

Ordningen på stegen spelar roll, eftersom de tidigare stegen avgör om siffrorna från de senare är trovärdiga. På två ställen stoppar jag processen för ett beslut: efter det första steget fastställer jag omfattningen, och efter korskontrollen, före leverans till kunden, kontrollerar jag prioriteringar och teser.

Steg 1. Mål och sajtens situation, innan jag startar en crawler

Den första frågan är om sajten förlorar trafik eller inte bygger upp någon, eftersom hela analysen beror på svaret. En sajt utan synlighet behöver först en karta över sökord och de sidor som ska svara på dem. En sajt som har synlighet behöver först skydd för det som redan ger placeringar, innan någon börjar rätta den.

Före start frågar jag om sådant som inget verktyg visar. Vilka produkter eller tjänster som ger intäkter, om ett byte av publiceringssystem eller en ombyggnad är planerad, vem som genomför rekommendationerna och hur mycket tid de har. Av svaren följer analysens omfattning och en lista över det jag inte skriver ut, eftersom ingen skulle genomföra det.

Det här steget måste du ta dig igenom själv, även om många specialister i dag lämnar det till en språkmodell. En språkmodell kan vara till hjälp, men den förstår inte kundens verksamhet. Den bidrar inte heller med den kreativa, unika blicken som en erfaren SEO-specialist har.

Steg 2. Får robotarna över huvud taget sajten

Innan jag läser någon siffra ur ett verktyg kontrollerar jag om servern släpper in robotar, eftersom en blockerad robot ger data som ser ut som SEO-problem. Under en vecka i juli 2026 visade sig tre ”SEO-problem” på tre olika sajter vara en blockering av robotar:

1. En sajt ”förlorade” över 2 200 länkar, eftersom sidorna som länkarna fanns på låg bakom en brandvägg som stötte bort verktygets robot för länkanalys.
2. En butik hade i ett verktyg ett hälsopoäng på 0 med nästan 42 000 fel, eftersom verktygets robot fick svar från Cloudflares brandvägg i stället för sidor.
3. På den tredje sajten stoppade en blockering crawlern vid den första adressen, och i tre veckor noterade ingen det.

Samma adress hämtar jag som en vanlig webbläsare och som robotar från Google, Bing, OpenAI, Perplexity och Anthropic, och sedan jämför jag svarskoder och sidans storlek. Skillnaden mellan webbläsaren och roboten är det första som måste förklaras innan jag börjar räkna något. Ett sådant test skickar förfrågningar från min IP-adress under en robots namn, och brandväggar känner igen riktiga robotar från Google och Bing på adressen de kommer från. En blockering av ”Googlebot” i testet bevisar alltså inte en blockering av den riktiga Googlebot. Search Console, Googles kostnadsfria panel för sajtägare, visar hur den riktiga Googlebot ser sajten.

Filen robots.txt läser jag till slutet med en parser, alltså ett program som tillämpar reglerna som en robot gör, och inte med blotta ögat. Googles robot tillämpar bara en grupp av regler, den med det bäst matchande robotnamnet, och hoppar över de övriga. Regeln Disallow: utan sökväg blockerar ingenting (Google Search Central). I augusti 2026 verkade ett utdrag ur robots.txt för en av sajterna blockera Google. Parsern visade att Googlebot hade full tillgång, medan Bings och AI-assistenternas robotar var blockerade. Diagnosen blev alltså en annan: problemet gällde Bing och AI-robotar och inte Google.

Att robots.txt saknas blockerar inte Google, men efter varje lansering kontrollerar jag att filen inte har försvunnit. Google behandlar ett 4xx-fel på robots.txt (utom 429) som om filen saknades, alltså utan begränsningar (Google Search Central). Min egen sajt gav i augusti 2026 felet 404 på robots.txt, innan jag rättade det.

Steg 3. Data från flera källor och vad var och en inte ser

Varje siffra från en crawler är en hypotes tills en andra källa bekräftar den. Jag samlar en crawl med och utan JavaScript och data om hastighet från riktiga användare ur rapporten CrUX. Till detta lägger jag länkprofilen och Googles resultat för viktiga sökord från mätdagen. I texten om länkbygge beskrev jag hur jag kontrollerar länkprofilen före en kampanjplan. För varje fil antecknar jag källa, datum och omfattning, så att varje siffra går att återskapa efter en månad.

Data från Search Console hämtar jag via API, alltså ett gränssnitt för automatisk hämtning av data, eftersom exporten från panelen kapar listan vid 1 000 rader. API:et lämnar upp till 50 000 rader per dag för varje typ av resultat, till exempel separat för resultat för sidor, bilder och video (Google, Search Console-hjälpen). I texten om AI-verktyg i SEO visade jag hur en kapad export blåste upp CTR på en sajt.

En crawler kan underskatta sajtens storlek, så antalet sidor och produkter kontrollerar jag i en andra källa. I två butiker kom crawlern till den första sidan i produktlistan i en kategori och gick inte vidare, trots att de följande sidorna i listan fungerade och inte var blockerade. I den ena butiken hittade den färre än hälften av produkterna, i den andra färre än en tredjedel. Hade jag angett de siffrorna som butikernas läge skulle analysen ha beskrivit brister i utbudet som inte fanns.

Plötsliga förändringar i dagliga data beskriver jag innan jag tillskriver dem en orsak. Det gör jag för klick, visningar, placeringar, sessioner och förfrågningar från Googles robot. Jag letar efter dagar från vilka medianen över sju på varandra följande dagar skiljer sig med minst 25 % från medianen över de fjorton dagarna före. För varje sådant datum antecknar jag en förklaring: lansering, uppdatering från Google, avbrott, ändrad mätning eller ”orsaken okänd”. Beskrivningen av datumen ger hypoteser, och en orsak pekar jag ut först efter att ha prövat andra möjliga förklaringar.

Steg 4. Sökord och Googles resultat före tekniken

Först letar jag efter möjligheter, sedan rättar jag fel. En del tekniska problem går bara att bedöma mot sökord: om ett filter i en butik ska indexeras, om en tagg förtjänar en egen sida, om två sidor verkligen konkurrerar om samma sak. I katalogen är 32 typer av problem markerade som omöjliga att bedöma utan analys av sökord och Googles resultat.

Att en sida saknas för ett viktigt sökord är ett av de vanligare problemen i mina analyser: 15 av 63 analyser, på 14 av 50 sajter. Det rapporterar inte en crawler själv, eftersom den bara hämtar sidor som finns. Det syns först när jag ställer efterfrågan mot listan med adresser och mot vilka konkurrenters sidor som dyker upp i resultaten.

Steg 5. Genomgång enligt katalogen med villkor för prioritet

Samma fel har hög eller låg prioritet beroende på var det förekommer. En intern länk till en adress med omdirigering i en mall som upprepas på tusentals sidor har hög prioritet. Samma länk i innehållet i ett enskilt inlägg har medelhög prioritet, och i arkiverade inlägg låg.

Varje typ av problem i katalogen har en detekteringsregel, ett villkor för rapportering, ett krav på belägg, en prioritet med villkor och ett sätt att kontrollera efter genomförandet. Av de 256 typerna börjar 86 prioritetsregeln med ”hög”, men nästan alltid med ett villkor: när sökordet har efterfrågan, när sidan har trafik, när felet finns i mallen.

Därför avgör inte hälsopoängen för sajten från ett verktyg prioriteringarna. Verktyget räknar fel och inte den trafik som beror på dem. En rekommendation som gäller sidor med okänd trafik får inte hög prioritet förrän jag har kontrollerat data.

Steg 6. Belägg för varje punkt

En punkt utan belägg blir kvar i analysen som ”ska kontrolleras” och inte som en rekommendation. Belägget är en skärmdump av platsen i koden eller HTML från servern bredvid versionen efter körning av JavaScript. Det kan också vara ett diagram från Search Console eller en hastighetsmätning med namnet på det element som förstör den. Ett element som försämrar laddningen eller förskjuter sidans layout benämner jag så som mätningen pekar ut det, och inte så som det passar min hypotes.

Varje punkt beskriver jag i fyra delar, från problemet till kontrollen av rättelsen. Jag skriver vad problemet består i, varför det skadar och vad det påverkar, hur det rättas steg för steg och hur vi kontrollerar att rättelsen fungerade. Koden som ska rättas kopierar jag ordagrant från sajten, så att utvecklaren ser exakt den plats som ska ändras.

Så ser en rapport om länkar till omdirigeringar ut i korthet:

• Problem: länkar i menyn leder till adresser utan snedstreck på slutet, som omdirigerar till versionen med snedstreck.
• Varför det skadar: menyn finns på varje sida, så varje klick och varje hämtning av en robot går via en extra omdirigering. I verktygens rapporter gör tusentals sådana länkar det svårare att hitta viktigare fel.
• Rättelse: byt i menymallen ut adresserna mot målsidorna, med ett kodutdrag före och efter ändringen.
• Kontroll: efter genomförandet visar en crawl inga länkar till adresser med omdirigering i mallen.

Steg 7. Ordning, arbetsinsats och alternativ

Resultatet av en analys är en ordning, inte antalet fynd. I början av dokumentet står en tabell över alla punkter med prioritet och arbetsinsats. Arbetsinsatsen beskriver jag i fyra kategorier: några timmar, en eller två dagar, en vecka eller ett helt projekt. Ett team med mindre möjligheter får ett minimalt alternativ bredvid det fullständiga, med en tydlig beskrivning av vad det förlorar på den kortare vägen.

Genomförandet följer analysen exakt. Om ett billigare alternativ dyker upp vid prissättningen av genomförandet väljer kunden det och jag skriver ner det rakt ut, och byter inte ut rekommendationen utan kundens vetskap.

Steg 8. Korskontroll och kontroll efter genomförandet

Innan analysen når kunden kontrolleras den av någon som inte skrev den. Jag gör två kontrollrundor: den första på hela dokumentet, den andra bara på det som ändrades efter den första. Kontrollen räknar om siffrorna från noll och letar efter teser som inte går att försvara med belägg. Till sist kontrollerar jag själv prioriteringar och teser som beror på kundens situation.

Efter genomförandet kontrollerar jag varje punkt på den fungerande sajten och markerar den som korrekt genomförd, delvis genomförd eller ej genomförd. Den kontrollen ingår i analysens pris. Utan det här steget slutar analysen vid dokumentet och inte vid en förändring på sajten.

Vad kontrollerar jag i en teknisk SEO-analys?

I en teknisk analys går jag igenom ett dussintal områden, och problem rapporterar jag oftast i omdirigeringar, sajtens arkitektur och innehåll. Den sista kolumnen visar i hur många av de 63 analyserna i arkivet författaren rapporterade minst ett problem i området. Kolumnen ”Vad jag kontrollerar” ger exempel och inte hela områdets omfattning. Tabellen visar utvalda områden, och katalogen delar upp problemen i 22.

Ett problem som sällan rapporteras behöver inte sällan förekomma. Hastighet och JavaScript har få rapporter i den här tabellen, men analyserna i arkivet hade olika omfattning. Det låga antalet rapporter säger alltså inte hur ofta de här problemen förekommer på sajter.

Hur kontrollerar jag indexeringen av en sajt?

Indexeringen kontrollerar jag på tre listor: vad som finns i sitemap, vad Google har indexerat och vad crawlern hittar via länkar. Skillnaden mellan de tre listorna visar problemet bättre än var och en för sig. En sitemap med adresser som svarar med omdirigering eller fel, eller som är uteslutna ur indexet, rapporterades i 20 av 63 analyser, på 18 av 50 sajter. För enskilda adresser använder jag URL-inspektionen i Search Console, som också visar sidan efter körning av JavaScript.

Påverkar Core Web Vitals placeringarna?

Core Web Vitals ingår i Googles rankningssystem, men de vinner inte över innehållets relevans. Google skriver rakt ut att rankningssystemen använder Core Web Vitals. Google skriver också att man alltid försöker visa det mest relevanta innehållet, även när upplevelsen på sidan är dålig (Google Search Central). I analysen använder jag data från riktiga användare ur rapporten CrUX och inte ett enstaka test i ett labbverktyg. Där Google har sådana data för enskilda typer av sidor anger jag dem var för sig. Brister i de data beskriver jag i analysen. Sedan den 12 mars 2024 är måttet på sidans reaktion INP, som ersatte FID (web.dev).

Vilka fel hittar jag oftast i SEO-analyser?

Oftast upprepas ordningsfel, alltså sådana som verktygen lätt upptäcker: länkar till omdirigeringar och till 404-fel, sitemaps med felaktiga adresser och dubbla titlar och beskrivningar av sidor. Interna länkar till adresser med omdirigering fanns i 24 av 63 analyser, på 20 av 50 sajter. Verktygen upptäcker dem bra, och kostnaden för att rätta dem beror på mallen och sajtens system.

Problem i strukturen som rapporteras mer sällan kan påverka trafiken mer än ordningsfel. Saknade sidor för viktiga sökord rapporterades i 15 av 63 analyser, och lika många gånger en blogg som inte länkar till sidorna för erbjudandet och kategorierna. Katalogen ger en saknad sida hög prioritet när sökordet har efterfrågan och konkurrenterna håller placeringarna med egna sidor. En blogg utan länkar får hög prioritet när målsidorna har trafik eller intäkter och bloggen har auktoritet. De villkoren kontrollerar jag mot data innan jag sätter en prioritet.

• 938fynd i 63 analyser på 50 sajter, som jag byggde katalogen med 256 typer av problem avArkivet med analyser 2020-2026, katalog från 11 oktober 2026
• 38 %av analyserna med interna länkar till adresser med omdirigering, det oftast rapporterade problemet i arkivet (24 av 63)Katalog från 11 oktober 2026
• 15 av 63analyser med saknade sidor för viktiga sökord, vilket en crawler inte rapporterar självKatalog från 11 oktober 2026
• 14typer av rekommendationer som katalogen i dag markerar som föråldrade, och ytterligare 30 som ändrad praxisKatalog från 11 oktober 2026

Vad har ändrats i SEO-analyser sedan 2020?

I analyserna från 2023-2026 förekommer strukturerad data och paginering oftare än 2020-2022, och omdirigeringar, kanoniska adresser och indexering mer sällan. Problem med strukturerad data rapporterades i 23 av 33 nyare analyser mot 16 av 30 äldre. Omdirigeringar och svarskoder: 23 av 33 mot 27 av 30. Blockeringar av AI-robotar dyker upp först i analyser från 2026. Analysens år är datumet för filen i arkivet, alltså inte alltid året då arbetet gjordes.

Nedgången bevisar inte att problemen med omdirigeringar har försvunnit. Sammansättningen av analyserna ändrades: de nyare gällde oftare strukturerad data, innehåll och synlighet i AI, och även sättet att arbeta ändrades. Av det här diagrammet framgår vad analyserna handlade om, inte hur sajterna i Polen har förändrats.

Vilka SEO-råd är föråldrade i dag?

Vissa råd dyker fortfarande upp i analyser och guider, trots att de i dag inte är värda att följa. En del av dem fungerade för några år sedan, och en del har Google avrått från eller ignorerat länge. I tabellen anger jag för varje praxis skälet och vad du gör i stället.

Källor till tabellen: Google om paginering, Google om fem fel med rel=canonical, Google om FAQ- och HowTo-resultat, Matt Cutts om nofollow och fördelning av länkkraft, John Mueller om omdirigeringar till startsidan, via Search Engine Roundtable, Google om robots.txt, Google om regler som inte stöds i robots.txt, Google om sitemaps, Google om fälten lastmod, changefreq och priority, web.dev om INP, Google om sökrutan i resultaten.

Därför har varje rekommendation i min katalog ett fält för aktualitet med motivering. Katalogen markerar i dag 14 typer av rekommendationer som föråldrade och 30 som ändrad praxis. En rekommendation som var riktig för några år sedan hamnar inte i en analys bara för att den en gång fungerade.

Hur kontrollerar du AI-robotars tillgång i en SEO-analys?

Tillgången för AI-robotar kontrollerar jag i samma steg som tillgången för Googlebot, eftersom samma inställning i brandväggen eller CDN kan blockera dem. CDN är ett nätverk av mellanliggande servrar, till exempel Cloudflare. I september 2026 kontrollerade jag 12 av mina kunders domäner som ligger bakom Cloudflare. Enbart filen robots.txt visade:

• 3 domäner blockerade samma uppsättning av sju robotar som samlar data för träning av modeller, med identisk lista över namn. En identisk lista tyder på en gemensam källa, till exempel en färdig inställning i Cloudflares panel. Utifrån syns inte den inställningen, så den måste bekräftas i själva panelen.
• 1 domän blockerade de robotar som hämtar sidor till svar i ChatGPT, Perplexity och Claude. Den gjorde det inte uttryckligen, utan med en allmän regel för alla robotar som inte nämns vid namn. Samma domän visade för GPTBot en skyddssida utan taggen noindex, som tar bort en sida ur indexet. Om en indexerande robot hade fått en sådan sida kunde blockeringssidan ha hamnat i indexet i stället för innehållet.
• 8 domäner hade inga blockeringar i robots.txt.

Om robotar som hämtar sidor till svar och robotar som samlar data för träning bestämmer du var för sig. I texten om AI SEO och GEO beskrev jag hur man skiljer dem åt. Sedan den 31 augusti 2026 finns också en separat inställning i Search Console som utesluter en sajt ur AI Overview, AI-läget och generativa funktioner i Discover. Enligt Google påverkar den inte resten av sökresultaten (Search Console-hjälpen). En sådan inställning kontrollerar jag i analysen på samma sätt som robots.txt, eftersom någon kan ha slagit på den utan att den som ansvarar för SEO vet om det. Om varumärket dyker upp i svaren efter att tillgången har öppnats är en separat mätning, som jag beskrev i texten om AI-synlighet.

Ett test från en enda IP-adress visar bara en del av situationen, och kan självt ge falskt alarm. I samma genomgång rapporterade en serie förfrågningar en blockering på två domäner efter att en gräns överskridits. Den blockeringen orsakades av mina egna tidigare förfrågningar. En kontroll några minuter senare, med en enda robotidentitet och enstaka förfrågningar, gav fem och sju korrekta svar i rad. Utan den kontrollen hade två kunder fått besked om en blockering som inte fanns. Först serverloggarna visar om ChatGPT faktiskt hämtar sidan. I texten om filen llms.txt visar jag vad som syns i loggarna för min sajt.

Kod 200 betyder inte att roboten fick innehållet. Hos en kund med en applikation i JavaScript fick Googlebot och Bingbot färdig HTML från en prerender-tjänst, medan AI-assistenternas robotar fick en tom sida. Tjänsten kände igen robotarna på namnet och hade inte AI-robotarna i sin lista. Mitt test gav resultatet ”i ordning”, eftersom det mätte svarskoden och inte innehållet. Sedan dess jämför jag innehållet som roboten får med innehållet efter körning av JavaScript i webbläsaren.

Räcker en gratis SEO-analys?

Ett gratis verktyg visar en lista över fel, men av rapporten ensam framgår inte vilka av dem som kostar dig trafik. På det polska sökordet ”audyt seo” är 7 av 9 organiska resultat på Googles första sida verktyg eller erbjudanden om en gratis analys (resultat från 17 oktober 2026). En sådan rapport räknar fel enligt verktygets regler och inte efter hur mycket trafik och intäkter som beror på dem. Det måste också kontrolleras att resultatet inte kommer från en blockering av roboten, som i fallet med butiken med hälsopoäng 0.

Du kan göra mycket gratis om du vet var du ska titta. Search Console visar Googles data om indexering, Core Web Vitals och sidan efter körning av JavaScript. Den gratis versionen av Screaming Frog går igenom upp till 500 adresser i en crawl (Screaming Frog), vilket räcker för en liten företagssajt. En analys med en konsult är meningsfull när ett fel kostar mycket (migrering, trafikras, en stor butik) eller när du inte har tid att sammanställa och bedöma data.

Kan ChatGPT göra en SEO-analys?

ChatGPT eller någon annan AI-modell kan inte göra en fullständig analys på egen hand, eftersom den inte ser sajten som en sökrobot. Vanligen ser den den genom ett verktyg som hämtar sidan och omvandlar den till text. Modellen läser de data du ger den och föreslår vad som ska kontrolleras. Hämtningsverktyget kan dock tappa en del av sidan: i september 2026 kontrollerade jag att verktyget för att hämta sidor i Claude Code tar bort strukturerad data när det omvandlar en sida till text. Modellen svarade att uppgifterna inte fanns, trots att de fanns i märkningen på samma sida. En analys gjord på det sättet skulle ha rapporterat saknad strukturerad data som inte saknas. I min process är AI ett verktyg, främst för att aggregera data från crawl, Search Console och andra källor. Omfattning, bedömning och prioriteringar bestämmer jag själv.

Vad kostar en SEO-analys?

Analysen debiterar jag som en konsultation: 70 EUR exklusive moms per arbetstimme, med en övre gräns för antal timmar som bestäms före start. Antalet timmar beror på vad som måste kontrolleras:

• en diagnostisk analys, alltså ett eller två konkreta problem (ett ras, en migrering, indexering), är vanligen 10-16 timmar, alltså 700-1 120 EUR exklusive moms;
• en fullständig analys med ordning på åtgärderna är vanligen 32-50 timmar, alltså 2 240-3 500 EUR exklusive moms;
• en liten sajt på upp till 500 adresser ligger närmare den nedre gränsen, och en butik med tusentals adresser och filter närmare den övre;
• språkversioner lägger vanligen till 3-5 timmar, och en pågående kris som måste diagnostiseras 4-8 timmar.

I priset ingår analysen, en rapport med rekommendationer, ett möte där vi går igenom den och kontroll efter genomförandet. Själva genomförandet gör ditt team, eller så prissätter jag det separat.

Utan åtkomst till Search Console, CDN-panelen och hostingen kan jag inte kontrollera den tekniska delen fullt ut, och det säger jag före prissättningen. Jag anger då vad jag inte kan verifiera utan de åtkomsterna och avgränsar omfattningen i enlighet med det. I texten om SEO-konsultation beskrev jag när ett samtal om ett enda beslut räcker i stället för en analys.

Vanliga frågor om SEO-analys

Var ska du börja?

Börja med en fråga: förlorar sajten trafik eller bygger den inte upp någon. Av svaret beror om du först skyddar de sidor som har placeringar eller letar efter sökord som sidor saknas för. Gör sedan de tre gratis kontrollerna från svaret om att göra en analys själv: robots.txt, rapporten om indexering i Search Console och en crawl med den gratis versionen av Screaming Frog. Om resultatet överraskar dig, eller om du inte vet vad som ska rättas först, är det ett bra ämne för en konsultation.