Teknisk SEO

Vad är teknisk SEO?

Teknisk SEO handlar om att skapa rätt tekniska förutsättningar för att Google ska kunna hitta, crawla, rendera, indexera och förstå rätt delar av en webbplats. Det är en central del av arbetet med SEO för företag, eftersom även bra innehåll kan få svårt att prestera om sökmotorer inte kommer åt sidan, tolkar fel URL eller inte förstår hur webbplatsens olika delar hänger ihop. Teknisk SEO bör alltid kombineras med en genomtänkt sökordsanalys – annars riskerar ni att optimera fel sidor tekniskt.

Arbetet omfattar bland annat crawlbarhet, indexering, canonical-taggar, redirects, internlänkning, webbplatsstruktur, JavaScript och prestanda. Men teknisk SEO handlar inte om att eliminera varje varning som ett SEO-verktyg hittar. En webbplats kan ha många mindre tekniska anmärkningar och ändå prestera bra, medan ett enda felaktigt noindex, en blockerad viktig sida eller en felaktig canonical kan begränsa synligheten kraftigt.

Därför är den viktigaste delen av teknisk SEO att identifiera vilka tekniska problem som faktiskt påverkar webbplatsens organiska potential och prioritera dem i rätt ordning.

1. Kan Google hitta sidan?

Innan Google kan indexera en sida behöver sökmotorn först upptäcka att URL finns. Det sker bland annat genom interna länkar, externa länkar och XML-sitemaps.

En viktig sida som ligger isolerad från resten av webbplatsen kan därför vara svårare att upptäcka och förstå, även om själva sidan är tekniskt korrekt.

2. Kan Google crawla sidan?

När Google har upptäckt URL behöver Googlebot kunna komma åt den och hämta innehållet.

Robots.txt, serverfel, felaktiga redirects och andra tekniska begränsningar kan påverka crawling. Det är samtidigt viktigt att skilja på crawling och indexering: att blockera Google från att crawla en URL är inte samma sak som att tala om att sidan inte ska finnas i sökresultatet.

3. Kan och bör sidan indexeras?

Att Google kan crawla en sida betyder inte automatiskt att den bör indexeras.

På de flesta webbplatser finns URL som inte har någon anledning att visas i sökresultaten. Teknisk SEO handlar därför om att säkerställa att rätt sidor kan indexeras och att Google får tydliga signaler om vilken version av innehållet som bör prioriteras.

Här spelar bland annat noindex, canonical-taggar, duplicerade URL och webbplatsens struktur en viktig roll.

4. Kan Google rendera och förstå innehållet?

Slutligen behöver Google kunna tolka det innehåll och de länkar som användaren faktiskt möter.

Det blir särskilt viktigt på webbplatser där stora delar av innehållet eller navigationen skapas med JavaScript. Om viktig information bara blir tillgänglig efter komplex rendering kan det skapa ytterligare tekniska förutsättningar som behöver analyseras.

När de här grundläggande delarna fungerar har webbplatsen en teknisk grund att bygga vidare på. Därefter kan arbetet gå vidare till exempelvis prestanda, Core Web Vitals, strukturerad data och mer avancerade tekniska förbättringar.

De viktigaste delarna inom teknisk SEO

Teknisk SEO består av flera delar som tillsammans påverkar hur effektivt sökmotorer kan upptäcka, hantera och förstå webbplatsens URL. Alla delar är inte lika viktiga för varje webbplats. En liten företagssajt kan ha ett relativt enkelt tekniskt behov, medan en e-handel med tusentals produkter, filter och URL-varianter kan kräva betydligt mer avancerad hantering.

Det viktiga är därför inte att optimera varje teknisk detalj, utan att förstå vilka delar som faktiskt påverkar webbplatsens möjlighet att indexeras och konkurrera i sökresultaten.

Crawlbarhet och internlänkning

Google upptäcker en stor del av webben genom länkar. En tydlig internlänkning hjälper därför både användare och sökmotorer att hitta viktiga sidor och förstå hur webbplatsens olika delar hänger ihop.

Problem uppstår exempelvis när viktiga landningssidor ligger flera nivåer djupt, saknar interna länkar eller endast går att nå genom funktioner som Google har svårt att följa.

En teknisk analys bör därför inte bara kontrollera om URL existerar, utan även hur enkelt den går att upptäcka från resten av webbplatsen.

Robots.txt och noindex

robots.txt används för att styra vilka delar av webbplatsen sökmotorers crawlers får begära. noindex används däremot för att tala om att en sida inte ska visas i sökresultatet.

Skillnaden är viktig. Om Google blockeras från att crawla en sida kan sökmotorn också få svårt att läsa ett noindex-direktiv som finns på själva sidan.

Felaktiga inställningar här kan få stora konsekvenser. Ett vanligt exempel är att regler som används på en staging- eller utvecklingsmiljö råkar följa med när webbplatsen lanseras.

XML-sitemap

En XML-sitemap fungerar som en lista över URL som webbplatsägaren vill hjälpa sökmotorer att upptäcka.

Den är särskilt användbar på större webbplatser, nya webbplatser eller sajter där alla viktiga sidor inte är lika enkla att upptäcka genom internlänkningen.

En sitemap är däremot ingen garanti för indexering. Om en URL finns i sitemap men samtidigt har noindex, fel canonical eller mycket svagt innehåll löser inte sitemap-filen grundproblemet.

Canonical och duplicerade URL

Samma eller mycket liknande innehåll kan ibland bli tillgängligt via flera URL. Det är vanligt på exempelvis e-handlar med filter, parametrar, sortering och produktvarianter.

En canonical-tagg kan användas för att ange vilken URL som bör behandlas som den huvudsakliga versionen.

Canonical är dock en signal, inte ett absolut kommando. Google kan välja en annan canonical om övriga signaler på webbplatsen pekar åt ett annat håll. Därför behöver canonical, internlänkning, sitemap och redirects ge konsekventa signaler om vilken URL som är den primära.

HTTP-statuskoder och redirects

Statuskoder berättar vad som händer när en URL begärs.

En fungerande sida returnerar normalt 200, medan en borttagen sida exempelvis kan returnera 404 eller 410. När en URL permanent flyttas till en annan adress används normalt en 301-redirect.

Problem uppstår när webbplatser bygger långa redirect-kedjor, skickar användare till irrelevanta destinationer eller returnerar 200 för sidor som egentligen inte längre finns.

På större webbplatser kan felaktiga statuskoder skapa tusentals URL som sökmotorer behöver hantera i onödan.

Webbplatsstruktur och URL-struktur

En tydlig webbplatsstruktur gör det enklare att förstå vilka områden som är viktigast och hur olika sidor relaterar till varandra.

En tjänstesajt kan exempelvis ha en struktur där huvudsakliga tjänster stöds av mer specifika undersidor och guider. På en e-handel kan kategorier, underkategorier och produkter behöva organiseras på ett sätt som både är logiskt för användaren och möjligt att crawla effektivt.

URL behöver inte vara extremt korta, men de bör vara stabila, begripliga och konsekventa.

JavaScript och rendering

Moderna webbplatser använder ofta JavaScript för menyer, filter, innehåll och interaktiva funktioner. Google kan rendera JavaScript, så JavaScript i sig är inte ett SEO-problem.

Problemet uppstår när viktiga länkar, innehåll eller metadata inte finns tillgängliga på ett sätt som Google kan upptäcka och rendera korrekt.

Det är särskilt relevant för JavaScript-tunga ramverk, headless-lösningar och webbplatser där stora delar av innehållet skapas först efter att sidan har laddats.

Teknisk SEO bör därför kontrollera vad Google faktiskt får tillgång till – inte bara vad användaren ser i webbläsaren.

Core Web Vitals och prestanda

Prestanda påverkar framför allt användarupplevelsen, men är också en del av Googles bredare page experience-system.

Core Web Vitals mäter bland annat hur snabbt det huvudsakliga innehållet visas, hur responsiv sidan är och hur mycket innehållet flyttar sig under laddningen.

Dåliga värden bör tas på allvar, men de ska inte överprioriteras framför kritiska problem som blockerad indexering, felaktiga canonicals eller sidor som Google inte kan hitta.

100/100 i PageSpeed Insights är inte ett SEO-mål i sig.

Strukturerad data

Strukturerad data är kod som hjälper sökmotorer att förstå vilken typ av information som finns på en sida.

Det kan exempelvis användas för produkter, organisationer, artiklar, recept, events och andra innehållstyper som Google stöder.

Korrekt strukturerad data kan göra en sida kvalificerad för vissa förbättrade presentationer i sökresultatet, men den ersätter inte bra innehåll och innebär inte automatiskt bättre ranking.

Markupen bör därför spegla det innehåll som faktiskt finns synligt på sidan.

Hreflang för internationella webbplatser

Webbplatser som riktar sig till flera språk eller geografiska marknader kan använda hreflang för att hjälpa Google förstå vilken version som är avsedd för vilken publik.

Det kan exempelvis vara relevant om samma företag har separata versioner för Sverige, Norge och Danmark eller olika engelskspråkiga marknader.

Felaktig implementation kan däremot skapa förvirrande signaler mellan versionerna. För en webbplats som endast riktar sig mot Sverige är hreflang normalt inget område som behöver prioriteras.

Det här illustrerar också en viktig princip inom teknisk SEO: alla tekniska möjligheter behöver inte användas på alla webbplatser. Rätt teknisk lösning beror på hur sajten faktiskt är uppbyggd och vilket problem som behöver lösas.

Prioritera tekniska SEO-problem i rätt ordning

SEO kan prissättas på flera olika sätt beroende på om arbetet är löpande, avgränsat eller rådgivande. Det viktigaste är inte vilken prismodell som används, utan att det är tydligt vad som ingår och vilket problem arbetet ska lösa.

5. Prioritera efter effekt – inte efter antal fel

En bra teknisk SEO-audit bör därför inte sluta med en export av hundratals problem från ett crawlerverktyg.

Varje problem behöver istället bedömas utifrån:

• hur många URL som påverkas
• hur viktiga dessa URL är för verksamheten
• om problemet påverkar crawling eller indexering
• om användarupplevelsen påverkas
• hur stor potentiell SEO-effekt en åtgärd kan ha
• hur mycket arbete som krävs för att lösa problemet

Det gör att ett tekniskt problem som påverkar fem viktiga kommersiella sidor kan prioriteras högre än ett annat problem som förekommer på tusen URL men saknar verklig affärspåverkan.

Så gör du en teknisk SEO-audit

En teknisk SEO-audit handlar inte bara om att hitta fel. Målet är att förstå hur webbplatsens tekniska struktur påverkar crawling, indexering och möjligheten att utveckla den organiska synligheten.

En bra audit bör därför följa en tydlig process: först upptäcka problemen, sedan bedöma hur allvarliga de är, prioritera rätt åtgärder och till sist verifiera att förändringarna faktiskt fungerar.

1. Crawla webbplatsen

Första steget är att skapa en teknisk bild av webbplatsen genom en crawl.

Ett crawlerverktyg kan bland annat hjälpa till att identifiera:

• brutna länkar
• redirects
• statuskoder
• canonical-taggar
• indexeringsdirektiv
• duplicerade URL
• sidor som ligger långt ner i strukturen
• interna länkar
• tekniska metadata-problem

Det viktiga är inte att exportera största möjliga lista med fel, utan att använda crawlen för att förstå hur webbplatsen faktiskt är uppbyggd och vilka problem som påverkar viktiga sidor.

2. Kontrollera indexeringen i Google Search Console

Nästa steg är att jämföra webbplatsens tekniska struktur med hur Google faktiskt hanterar URL.

I Google Search Console går det bland annat att se vilka sidor Google känner till, vilka som har indexerats och vilka som har exkluderats av olika orsaker.

Här kan man upptäcka problem som:

• viktiga sidor som inte indexeras
• fel URL-version som valts som canonical
• sidor som upptäckts men inte indexerats
• noindex-direktiv
• crawlproblem
• redirects eller soft 404-problem

Det här är en viktig skillnad mot en vanlig crawl: crawlern visar hur webbplatsen ser ut tekniskt, medan Search Console visar hur Google faktiskt tolkar och hanterar delar av den.

3. Jämför indexerbara och indexerade URL

Alla sidor som är tekniskt indexerbara behöver inte finnas i Google.

Därför bör man inte bara fråga:

Hur många sidor är indexerade?

Den viktigare frågan är:

Är rätt sidor indexerade – och är fel sidor bortfiltrerade?

En webbplats kan exempelvis ha tusentals indexerade filter-, tagg- eller parameter-URL samtidigt som viktiga landningssidor saknas.

En teknisk audit bör därför jämföra:

• vilka URL som bör kunna indexeras
• vilka URL som faktiskt indexeras
• vilka URL som inte bör indexeras
• om Googles valda canonical stämmer med webbplatsens avsikt

4. Kontrollera canonical, statuskoder och redirects

Därefter bör man granska om webbplatsen skickar konsekventa signaler om vilka URL som är primära.

Det innebär bland annat att kontrollera:

• canonical-taggar
• 301- och 302-redirects
• redirect-kedjor
• 404- och 410-sidor
• soft 404-problem
• om interna länkar går direkt till rätt URL
• om sitemap innehåller URL som redirectar eller inte bör indexeras

Ett vanligt problem är att olika tekniska signaler säger olika saker. En sida kan exempelvis ha en canonical till en URL samtidigt som internlänkar och sitemap pekar mot en annan.

Ju mer konsekventa signalerna är, desto enklare blir det för Google att förstå vilken version som faktiskt är viktigast.

5. Granska webbplatsstruktur och internlänkning

Nästa steg är att bedöma hur de viktigaste sidorna är placerade i webbplatsens struktur.

Frågor som bör ställas är exempelvis:

• går viktiga sidor att nå genom vanliga interna länkar?
• ligger centrala landningssidor onödigt djupt?
• finns orphan pages?
• stödjer underliggande innehåll de viktigaste kommersiella sidorna?
• används tydliga och relevanta ankartexter?
• finns det delar av webbplatsen som är isolerade från resten?

Internlänkning är därför både en innehålls- och en teknisk fråga. En sida som är korrekt byggd men nästan omöjlig att hitta i webbplatsens struktur får sämre förutsättningar än en sida som är tydligt integrerad i resten av sajten.

6. Testa prestanda och rendering

När de grundläggande crawl- och indexeringsfrågorna är genomgångna bör man kontrollera hur webbplatsen fungerar för både användare och sökmotorer.

Det kan bland annat innebära att granska:

• Core Web Vitals
• stora bilder
• tunga JavaScript-filer
• render-blocking resurser
• lång serverrespons
• layout shifts
• innehåll som endast visas efter JavaScript-rendering
• länkar eller navigation som Google kan ha svårt att upptäcka

Här är det viktigt att inte fastna i enskilda poäng från exempelvis PageSpeed Insights.

Prestandaproblem bör prioriteras utifrån hur mycket de faktiskt påverkar användarupplevelsen och webbplatsens viktigaste sidor.

7. Prioritera åtgärderna efter faktisk effekt

När analysen är färdig ska resultatet inte vara en osorterad lista med hundratals problem.

Varje åtgärd bör prioriteras utifrån:

• SEO-påverkan
• affärsvärde
• hur många viktiga URL som berörs
• risknivå
• implementeringskostnad
• hur snabbt åtgärden kan verifieras

En enkel prioriteringsmodell kan vara:

Kritisk → Hög → Medel → Låg

Det gör det möjligt att börja med de problem som kan ha störst effekt istället för att lägga tid på tekniska detaljer som knappt påverkar resultatet.

8. Verifiera efter implementation

En teknisk SEO-audit är inte färdig när rekommendationerna har skickats vidare till utvecklaren.

Efter implementation bör webbplatsen crawlas igen och de viktigaste URL kontrolleras på nytt.

Det kan exempelvis innebära att verifiera:

• att noindex har försvunnit eller lagts till där det ska
• att redirects fungerar korrekt
• att canonical pekar rätt
• att interna länkar uppdaterats
• att sidan fortfarande renderas korrekt
• att Google kan crawla den nya versionen
• att sitemap och andra tekniska signaler är konsekventa

Det är först när åtgärden är implementerad och verifierad som problemet faktiskt kan betraktas som löst.

Vanliga tekniska SEO-problem på olika webbplatser

Tekniska SEO-problem ser olika ut beroende på hur webbplatsen är byggd. En mindre WordPress-sajt har ofta helt andra risker än en stor e-handel eller en JavaScript-tung headless-lösning.

Det betyder att samma tekniska checklista inte bör användas mekaniskt på alla webbplatser. Analysen behöver utgå från plattform, webbplatsstorlek, URL-struktur och hur innehållet faktiskt genereras.

WordPress

WordPress kan vara en mycket bra plattform för SEO – men den stora flexibiliteten innebär också att det är lätt att bygga in tekniska problem om webbplatsen sätts upp fel.

Teman, plugins, page builders, cachelösningar och SEO-plugins kan alla påverka hur webbplatsen renderas, laddas, indexeras och struktureras. Om flera system konfigureras utan en tydlig teknisk helhet kan resultatet bli allt från onödigt långsam laddning till felaktiga canonical-taggar, noindex, duplicerade arkiv och JavaScript-optimeringar som påverkar viktiga funktioner.

Vanliga problem är exempelvis:

• att sökmotorer blockeras via WordPress inställning för sökmotorsynlighet
• felaktiga noindex-inställningar från SEO-plugins
• dubbla eller onödiga kategori-, tagg- och arkivsidor
• felaktiga canonical-taggar
• gamla redirects som byggts på över tid
• långsam laddning på grund av tunga teman eller för många plugins
• JavaScript- och cacheoptimeringar som påverkar funktioner eller rendering
• staging- eller testmiljöer som råkar bli indexerbara

En dåligt byggd WordPress-webbplats kan därför skapa betydande teknisk skuld som senare begränsar SEO-arbetet. Det kan bli extra problematiskt när nya plugins och lösningar läggs ovanpå en struktur som redan från början är svag.

Men det motsatta gäller också.

När WordPress byggs korrekt av någon som förstår både webbteknik och SEO är det en flexibel och stark plattform för organisk tillväxt. Det går att skapa tydliga webbplatsstrukturer, kontrollera indexeringen, optimera prestandan och utveckla innehållet utan att vara låst till en stel teknisk lösning.

Det är också en av anledningarna till att vi på Skale arbetar mycket med WordPress. För oss handlar det inte bara om att få en webbplats att se bra ut – den behöver byggas med prestanda, struktur, skalbarhet och SEO i åtanke redan från början.

E-handel

E-handlar har ofta betydligt fler URL och fler automatiskt genererade kombinationer än vanliga företagssajter.

Tekniska problem kan bland annat uppstå genom:

• filter och facetterad navigation
• sorterings- och parameter-URL
• produktvarianter
• pagination
• produkter som tagits bort
• produkter som finns i flera kategorier
• tunna eller duplicerade kategorisidor
• felaktiga canonicals
• orphan products
• stora mängder indexerbara URL utan tydligt sökvärde

En av de viktigaste frågorna blir därför vilka URL som faktiskt bör vara indexerbara.

Om varje filterkombination skapar en ny crawlbar och indexerbar URL kan en stor del av sökmotorernas arbete läggas på sidor som aldrig var tänkta att konkurrera i sökresultatet.

Samtidigt ska inte alla filter automatiskt blockeras. Vissa filtrerade kombinationer kan ha ett tydligt sökintresse och affärsvärde. Därför behöver även här search intent och informationsarkitektur styra den tekniska lösningen.

JavaScript och headless

På JavaScript-tunga webbplatser och headless-lösningar behöver man särskilt kontrollera vad sökmotorerna faktiskt får tillgång till.

Vanliga problem kan vara:

• innehåll som endast laddas efter användarinteraktion
• interna länkar som inte implementeras som vanliga crawlbara länkar
• metadata som genereras sent eller inkonsekvent
• nya landningssidor och supporting content
• felaktiga statuskoder
• problem med canonical
• client-side redirects
• innehåll som användaren ser men som inte finns i den renderade version Google får
• stora mängder JavaScript som påverkar prestanda och rendering

Google kan rendera JavaScript, men det innebär inte att all JavaScript-implementation automatiskt är optimal för SEO.

För viktiga kommersiella sidor bör centralt innehåll, navigation och länkar därför vara robusta och tillgängliga även ur ett sökmotorperspektiv, inte bara fungera visuellt för användaren.

Vibe-kodade och AI-genererade webbplatser

AI-verktyg har gjort det möjligt att bygga webbplatser mycket snabbare än tidigare. Med så kallad vibe coding kan stora delar av en webbplats skapas genom instruktioner till en AI-modell istället för genom traditionell utveckling.

För prototyper och enklare projekt kan det vara ett effektivt arbetssätt. Problemet uppstår när den genererade koden publiceras utan att någon faktiskt granskar hur webbplatsen är strukturerad, renderas och fungerar ur ett tekniskt SEO-perspektiv.

När AI-genererad kod granskas, förenklas och implementeras av någon som förstår webbteknik och SEO kan arbetssättet vara mycket effektivt. När koden däremot publiceras direkt bara för att sidan “ser rätt ut” ökar risken för att teknisk skuld byggs in redan från första versionen.

När teknisk SEO inte är problemet

Teknisk SEO är grunden som gör det möjligt för sökmotorer att hitta, crawla, indexera och förstå en webbplats. Men när den tekniska grunden fungerar finns det en punkt där ytterligare tekniska justeringar ger betydligt mindre effekt än andra SEO-insatser.

Det är därför viktigt att inte behandla varje rankingproblem som ett tekniskt problem.

En webbplats kan vara snabb, korrekt indexerad och tekniskt välbyggd – och ändå ha svag organisk synlighet.

Bra teknik kan inte ersätta fel innehåll

Om en landningssida inte svarar på det användaren faktiskt söker efter kommer bättre laddningstid, renare kod eller ytterligare strukturerad data sällan lösa huvudproblemet.

Sidan kan istället behöva:

• bättre matchning mot search intent
• tydligare innehåll
• ett starkare erbjudande
• bättre ämnestäckning
• en annan typ av landningssida
• större kommersiell relevans

Teknisk SEO skapar förutsättningarna för att sidan ska kunna konkurrera. Den avgör inte automatiskt om sidan förtjänar att ranka.

Du kanske riktar dig mot fel sökningar

Ibland fungerar webbplatsen tekniskt precis som den ska, men SEO-strategin fokuserar på sökord som är för konkurrensutsatta, saknar affärsvärde eller har en annan sökintention än sidan som försöker ranka.

Då behövs inte ännu en teknisk audit.

Det som behöver omvärderas är istället vilka sökningar företaget bör prioritera och vilka sidor som ska möta dem.

Konkurrenterna kan helt enkelt ha starkare sidor

Om flera tekniskt fungerande webbplatser konkurrerar om samma sökning kommer andra faktorer få större betydelse.

Konkurrenterna kan exempelvis ha:

• bättre och mer relevant innehåll
• starkare kommersiella landningssidor
• bättre ämnestäckning
• tydligare internlänkning
• större etablerad auktoritet inom området
• fler relevanta externa länkar

I det läget är det lätt att fortsätta leta efter tekniska problem eftersom de är konkreta och mätbara. Men att optimera ytterligare några millisekunder i laddningstid kommer inte nödvändigtvis hjälpa om konkurrenternas sida helt enkelt är bättre för sökningen.

Alla tekniska förbättringar har inte samma affärsvärde

Det går nästan alltid att hitta något tekniskt som kan förbättras.

Frågan är om det är det bästa sättet att använda nästa timme eller nästa del av SEO-budgeten.

Om webbplatsens viktigaste sidor:

• kan crawlas
• är korrekt indexerade
• använder rätt canonical
• fungerar på mobil
• har rimlig prestanda
• är tydligt integrerade i webbplatsstrukturen
• kan renderas korrekt

…kan nästa investering ge större effekt på andra delar av SEO-arbetet.

Teknisk SEO ska lösa problem – inte skapa arbete

Det är lätt att göra teknisk SEO till en ständig jakt på perfektion.

Men målet är inte en webbplats utan tekniska varningar. Målet är en webbplats där tekniken inte står i vägen för organisk tillväxt.

När den grunden finns bör resurserna flyttas till det som för tillfället begränsar utvecklingen mest.

Ibland är det teknik. Ibland är det innehåll, sökstrategi, webbplatsstruktur, auktoritet eller själva erbjudandet.

Bra SEO handlar om att kunna se skillnaden.

Verktyg för teknisk SEO

Tekniska SEO-verktyg hjälper till att upptäcka problem, men de avgör inte automatiskt vad som är viktigt. Ett verktyg kan visa hundratals varningar, medan den verkliga frågan fortfarande är vilka av dem som faktiskt påverkar viktiga sidor och organisk synlighet.

Därför är det bättre att använda ett fåtal verktyg med tydliga roller än att samla så mycket data som möjligt.

Google Search Console

Google Search Console är ett av de viktigaste verktygen för teknisk SEO eftersom det visar hur Google faktiskt hanterar webbplatsen.

Här kan du bland annat kontrollera:

• vilka sidor som indexeras
• varför vissa URL inte indexeras
• Googles valda canonical
• crawl- och indexeringsproblem
• Core Web Vitals
• sitemap-status
• enskilda URL genom URL Inspection
• organisk synlighet, klick och sökningar

Search Console är särskilt värdefullt eftersom datan kommer direkt från Google och därför kompletterar det som ett vanligt crawlerverktyg kan se.

Screaming Frog

Screaming Frog används för att crawla webbplatsen på ungefär samma sätt som en sökmotor skulle följa länkar mellan olika URL.

Verktyget kan bland annat hjälpa till att hitta:

• statuskoder
• brutna länkar
• redirects
• canonical-taggar
• noindex-direktiv
• interna länkar
• crawl depth
• duplicerade sidor
• sitemap-avvikelser

Det gör Screaming Frog särskilt användbart när man vill förstå hur webbplatsen faktiskt hänger ihop tekniskt.

PageSpeed Insights

PageSpeed Insights används för att analysera webbplatsens prestanda och Core Web Vitals.

Verktyget kombinerar laboratoriedata med verklig användardata när sådan finns tillgänglig och kan hjälpa till att identifiera problem med exempelvis:

• LCP
• INP
• CLS
• stora bilder
• JavaScript
• render-blocking resurser
• serverrespons

Poängen i verktyget bör däremot inte behandlas som ett SEO-mål i sig. Fokus bör ligga på de problem som faktiskt påverkar användarupplevelsen och viktiga delar av webbplatsen.

Rich Results Test

Googles Rich Results Test används för att kontrollera om strukturerad data på en sida är korrekt implementerad och om sidan kan vara kvalificerad för Googles stödda rich results.

Det är särskilt användbart efter förändringar i exempelvis:

• Article
• Product
• Organization
• Breadcrumb
• LocalBusiness
• andra schema-typer som Google stödjer

Verktyget visar både fel och varningar, men även här behöver resultaten bedömas utifrån vilken typ av innehåll sidan faktiskt innehåller.

Fler verktyg kan behövas på större webbplatser

På större webbplatser kan verktyg som Ahrefs, Semrush, Sitebulb eller logganalys ge ytterligare information om exempelvis länkar, crawlmönster, konkurrenter och webbplatsstruktur.

Men fler verktyg innebär inte automatiskt bättre teknisk SEO.

Det viktiga är att kunna kombinera informationen från verktygen och förstå:

Vad är problemet, vilka sidor påverkas och är det värt att prioritera?

Det är analysen och prioriteringen som skapar värdet – inte antalet verktyg i verktygslådan.

Vad kostar teknisk SEO?

Kostnaden för teknisk SEO beror framför allt på hur stor och komplex webbplatsen är, hur allvarliga problemen är och hur mycket som faktiskt behöver åtgärdas.

En mindre WordPress-sajt kan ibland behöva en relativt begränsad teknisk genomgång, medan en större e-handel, internationell webbplats eller JavaScript-tung lösning kan kräva betydligt mer analys, utveckling och uppföljning.

En teknisk SEO-audit kan göras som ett separat projekt

Om behovet främst är att förstå webbplatsens tekniska nuläge kan en teknisk SEO-audit genomföras som en avgränsad insats.

Arbetet kan exempelvis omfatta:

• crawl och teknisk analys
• kontroll av indexering
• canonical och redirects
• webbplatsstruktur
• internlänkning
• Core Web Vitals och prestanda
• rendering och JavaScript där det är relevant
• prioriterad åtgärdslista

Priset påverkas då framför allt av hur många URL som behöver analyseras och hur komplex webbplatsens tekniska struktur är.

Implementation kan vara en större del av kostnaden än analysen

Att hitta ett tekniskt problem är ofta enklare än att lösa det.

På vissa webbplatser kan en ändring göras direkt i WordPress eller ett SEO-plugin. På andra krävs utveckling i tema, backend, routing, templates eller JavaScript.

Därför bör man skilja på:

kostnaden för att identifiera problemen

och

kostnaden för att implementera lösningarna.

En omfattande audit är inte särskilt värdefull om de viktigaste rekommendationerna aldrig genomförs.

Teknisk SEO kan också ingå i ett löpande SEO-arbete

För många företag är teknisk SEO inte ett separat projekt utan en del av det löpande SEO-arbetet.

Då prioriteras tekniska problem tillsammans med exempelvis landningssidor, innehåll, internlänkning och andra SEO-insatser utifrån var den största potentialen finns.

På Skale börjar lokal SEO från 3 000 kr per månad och löpande SEO från 5 000 kr per månad, exklusive moms, men rätt nivå beror på webbplatsens nuläge, konkurrens och omfattning.

Vill du se hur olika budgetnivåer kan se ut kan du läsa vår guide om vad SEO kostar.

Betala för rätt problem – inte för största rapporten

En större teknisk rapport är inte automatiskt mer värdefull än en mindre.

Om en audit hittar 400 mindre varningar men missar de tre problem som faktiskt begränsar webbplatsens viktigaste sidor har arbetet prioriterats fel.

Det viktiga är därför att kostnaden för teknisk SEO står i relation till problemen som behöver lösas och den affärsnytta som lösningarna kan skapa.