Teknisk SEO: grunden för bra ranking

Teknisk SEO, eller teknisk sökmotoroptimering, är den del av SEO som handlar om webbplatsens infrastruktur: hur sidorna hittas, genomsöks, renderas, indexeras och levereras till användaren. Innehåll och länkar avgör om en sida är relevant. Tekniken avgör om sidan över huvud taget kan konkurrera.

Tre engelska begrepp återkommer i allt arbete:

• Crawling (genomsökning): Googles crawler Googlebot hämtar sidans HTML. Om robots.txt, trasiga länkar eller långsamma servrar blockerar crawlingen får Google aldrig se innehållet.
• Rendering: webbläsaren tolkar HTML, CSS och JavaScript och bygger sidan som användaren ser den. Innehåll som bara skapas av JavaScript måste Google hinna rendera innan det kan indexeras.
• Indexering: Google analyserar sidan, väljer en kanonisk version och lagrar informationen i sitt index. Först då kan sidan visas i sökresultaten.

Teknisk SEO är ingen engångsaudit. Det är ett löpande arbete som följer med varje publicering, temaändring och release. En sida som fungerade i går kan i dag vara blockerad av en regel i robots.txt, ha tappat sin canonical eller visa en tom HTML-sträng för Googlebot.

Området täcker allt som måste fungera innan innehåll och länkar kan göra nytta. Det gäller oavsett om du driver en e-handel, en B2B-sajt med hundratals produktsidor eller en mindre tjänstesajt i Stockholm.

Lika viktigt är vad teknisk SEO inte är. Det är inte en jakt på hundra poäng i ett verktyg, inte ett sätt att lura Googlebot och inte en ersättning för innehåll. Det är underhåll av den infrastruktur som gör innehållet möjligt att hitta.

Arbetet kräver att roller möts. Den som äger sajten behöver förstå vad som ska ändras, utvecklaren behöver förstå varför, och den som skriver innehåll behöver veta vilka regler som gäller vid publicering. Utan den kopplingen blir tekniska åtgärder engångsinsatser som rullas tillbaka vid nästa release.

Sidan är en del av Kunskapsbanken, där varje delområde har en egen fördjupning.

Området består av tolv delar som bygger på varandra. Börja nedifrån: en sida som inte går att crawla kan inte indexeras, och en sida som inte indexeras kan inte ranka. Varje del har en egen sida i kunskapsbanken.

• URL: adressen som identifierar sidan och som Google använder för att skilja sidor åt.
• URL-struktur: hur kataloger och adresser sätts ihop så att hierarkin blir begriplig.
• crawlability: att Googlebot kan nå och genomsöka sidorna utan att blockeras.
• indexering: att sidan får plats i Googles index och kan visas i sökresultaten.
• robots.txt: filen som styr vilka delar av sajten crawlers inte får besöka.
• sitemap: listan över webbplatsens URL:er som hjälper Google att hitta sidor.
• canonical-tagg: markeringen som pekar ut vilken URL som är originalet vid dubbletter.
• 301-redirect: permanent omdirigering som flyttar både besökare och signaler till en ny URL.
• intern länkning: hur länkar mellan dina egna sidor fördelar styrka och styr crawling.
• hreflang: språk- och landsmarkering för sajter med flera versioner.
• Core Web Vitals: Googles mått på laddning, interaktivitet och visuell stabilitet.
• strukturerad data: maskinläsbar information om sidans innehåll, oftast som JSON-LD.

Läs dem i tur och ordning om du bygger den tekniska grunden från noll, eller gå direkt till det område där du misstänker att problemet sitter.

Google beskriver sökningen som tre steg: crawling, indexering och leverans av sökresultat. Alla sidor tar sig inte igenom alla steg.

Crawling. Google har ingen central lista över webbplatser. Sidor hittas när Google följer länkar från sidor den redan känner till, eller när du skickar in en sitemap. Googlebot bestämmer själv hur ofta och hur mycket den hämtar från din sajt. Sidor som är blockerade i robots.txt crawlas inte alls.

Rendering. Under crawlningen renderar Google sidan med en aktuell version av Chrome och kör JavaScript. Innehåll som bara finns i JavaScript kan därför dröja eller missas helt. Finns texten i den HTML som servern skickar går den snabbare att tolka.

Indexering. När sidan är hämtad analyserar Google text, rubriker, title och alt-texter, grupperar liknande sidor och väljer en kanonisk version. Indexering är inte garanterad: en sida kan crawlas utan att hamna i index.

Leverans. När någon söker matchar Google frågan mot indexet och rangordnar enligt hundratals faktorer, bland annat språk, plats och enhet.

JavaScript är den vanligaste källan till att innehåll dyker upp sent eller inte alls. En sida som är byggd i React eller Next.js behöver antingen server-rendera innehållet eller vara byggd så att Googlebot hinner rendera det före indexering. Tumregel: det som är viktigt för sökningen ska finnas i den HTML som servern skickar.

Google är tydliga med att företaget inte garanterar att en sida crawlas, indexeras eller visas, även om den följer Googles riktlinjer. Det är därför tekniska fel är så dyra: de syns inte i innehållet utan i frånvaron av trafik. Läs Googles egen genomgång av hur Google Search fungerar om du vill följa stegen i detalj.

Praktiskt blir det tre frågor att ställa om varje viktig sida: Kan Googlebot nå den? Förstår Google vad den handlar om? Och är det den versionen som Google valt som kanonisk? Det första styrs av crawlbarhet, det andra av innehåll och struktur, det tredje av indexering och canonical.

Core Web Vitals är Googles tre mått på hur en sida presterar för användaren. De mäts i fält på riktiga besök, inte bara i ett labb, och bedöms vid 75:e percentilen separat för mobil och desktop. En sida ska alltså klara tröskeln för tre av fyra besök, inte bara för det bästa.

• LCP (Largest Contentful Paint) mäter laddning: det största innehållselementet, oftast en bild eller rubrik, ska vara synligt inom 2,5 sekunder.
• INP (Interaction to Next Paint) mäter interaktivitet: sidan ska svara inom 200 millisekunder när användaren klickar eller trycker.
• CLS (Cumulative Layout Shift) mäter visuell stabilitet: layouten ska inte hoppa, och måttet ska ligga på 0,1 eller lägre.

Googles trösklar finns dokumenterade i web.dev:s genomgång av Core Web Vitals. Trösklarna är inte något du förhandlar om: antingen klarar sidan dem vid 75:e percentilen eller inte.

I praktiken sitter problemen oftast på tre ställen. LCP dras ned av stora hero-bilder som inte är komprimerade, långsamma servrar eller typsnitt som blockerar renderingen. INP försämras av tung JavaScript och långa uppgifter på huvudtråden. CLS orsakas nästan alltid av bilder och inbäddningar utan angivna mått, eller av annonser och banners som laddas in efter att sidan ritats.

Mät i Search Console under Core Web Vitals för fältdata på gruppnivå, och i PageSpeed Insights per URL. Åtgärda det som ger störst effekt på de sidor som redan får trafik, inte de som är enklast att fixa.

Ett svenskt exempel: en e-handel med en stor kampanjbild överst på startsidan får ofta ett LCP-värde över tröskeln eftersom bilden är okomprimerad och laddas med låg prioritet. Samma sajt kan ha ett CLS-problem eftersom kampanjbannern skjuts in ovanför innehållet. Båda felen syns i fältdata men inte i en snabb labbmätning på en snabb dator.

Dubbletter uppstår snabbare än du tror: samma sida nås via http och https, med och utan www, med versaler och gemener, med spårningsparametrar, filter och paginering. Varje variant kan konkurrera med de andra om samma sökord.

En canonical (kanonisk URL) är den version du pekar ut som originalet. Du anger den med en canonical-tagg i sidans head, eller med en HTTP-header. Google beskriver det som en stark signal, inte ett kommando: sökmotorn kan välja en annan version om signalerna pekar dit.

En 301-redirect är en permanent omdirigering och den starkaste signalen du kan skicka. Använd den när en sida har flyttat, inte som ett sätt att städa bland dubbletter som fortfarande ska vara åtkomliga. En 404 betyder att sidan inte finns längre; Google tar då bort den ur index över tid.

Tre regler som ofta missas. Använd inte robots.txt för att hantera dubbletter: Google kan fortfarande indexera en URL som är blockerad i robots.txt, men utan innehåll. Använd inte noindex för att välja canonical inom den egna sajten, eftersom noindex blockerar sidan helt från Search. Ha alltid en self-referential canonical på sidor som ska indexeras, alltså en canonical som pekar på sidan själv.

Situation	Rätt metod	Vad signalen gör
Samma innehåll på flera URL:er	rel=canonical	Stark signal om vilken version som ska visas; övriga blir alternativ
Sidan har flyttat permanent	301-redirect	Starkaste signalen; den gamla URL:en ersätts av den nya
Innehållet ska bort	404 eller 410	Sidan tas bort ur index över tid
Sidan ska finnas för användare men inte i sök	noindex	Blockerar sidan från Search helt; fel verktyg för att välja canonical

Läs mer om canonical-taggen och 301-redirect i kunskapsbanken. Googles dokumentation om canonicalisering beskriver vilka metoder som väger tyngst.

En vanlig orsak till dubbletter i svensk e-handel är parametrar: sortering, färgfilter och spårningslänkar skapar nya URL:er för samma produktsida. En lösning är att låta varianter peka canonical till huvudsidan och att inte låta filter skapa indexerbara URL:er. En annan är att bygga riktiga kategorisidor för de kombinationer som faktiskt söks.

Interna länkar är det billigaste verktyget du har. De hjälper Googlebot att hitta nya sidor, fördelar styrka mellan sidorna och visar vilka sidor som är viktigast. En sida som ingen länkar till internt är en orphan page: den kan vara hur bra som helst och ändå aldrig crawlas.

Tre principer som gör mest skillnad:

• Länka alltid till den kanoniska URL:en, inte till en dubblett eller en omdirigering.
• Använd beskrivande länktexter i stället för ”läs mer”. Länktexten är en signal om målsidans ämne.
• Bygg hubbar: en kategorisida länkar till alla sina undersidor, och undersidorna länkar tillbaka. Då hittar Googlebot hela strukturen från startsidan.

Exempel från svensk B2B. Ett svenskt B2B-bolag med ett stort produktsortiment låter kunderna filtrera fram produkter i en JavaScript-driven katalog. Filterlänkarna är inte klickbara för Googlebot, så Google hittar bara de produkter som exponeras i kategorilistorna. Resten blir osynliga trots att de finns. Lösningen är strukturell: kategorisidor med textlänkar till varje produktgrupp, en sitemap som listar produktsidorna och filter som inte skapar oändliga URL-serier. Ingen ny teknik, bara en begriplig struktur.

URL-struktur. Håll URL:er korta, med gemener och bindestreck. Undvik parametrar för sidor som ska ranka, och lägg innehåll på en logisk plats i hierarkin i stället för på roten. Behåll strukturen när den väl fungerar: att byta URL:er utan 301-redirect är ett av de vanligaste sätten att tappa trafik vid en ombyggnad.

Fördjupa dig i intern länkning och URL-struktur.

Klickdjup spelar också roll. Sidor som ligger tre klick eller mer från startsidan kan crawlas mer sällan och får mindre styrka än sidor som nås direkt från menyn. En enkel åtgärd är att låta kategorihubbar och brödsmulor peka på undersidorna, så att ingen viktig sida bara nås via en dold meny eller en sökfunktion.

Har du flera språkversioner gäller samma logik: varje version ska ha en egen, stabil URL och markeras med hreflang så att Google förstår vilken version som riktar sig till vilken målgrupp. En vanlig miss är att byta språk på samma URL, vilket gör att versionerna konkurrerar med varandra. Läs mer om hreflang.

En sitemap är en XML-fil som listar webbplatsens URL:er. Den hjälper Google att hitta sidor som interna länkar missar, särskilt på stora sajter eller nya sajter med få inkommande länkar. En sitemap är ingen garanti: den hjälper Google att hitta URL:er, men Google crawlar och indexerar bara det som bedöms vara värt det. Googles guide till sitemaps beskriver när en sitemap behövs.

robots.txt ligger i sajtens rot och talar om vilka delar crawlers inte får besöka. Den är ett trubbigt verktyg: den stoppar crawling, inte indexering, och den ska inte användas för att hantera dubbletter. Blockera administrationssidor, interna sökresultat och filter-URL:er. Blockera aldrig CSS- eller JavaScript-filer som behövs för renderingen.

Crawl-budget är den mängd crawling Google är beredd att lägga på din sajt under en period. Googlebot bestämmer själv hur mycket den hämtar, utifrån sajtens storlek, hur ofta innehållet ändras, serverkapacitet och antalet dubbletter. Du styr den indirekt: håll servern snabb, undvik oändliga URL-rymder som kalendrar, fasetter och sökparametrar, håll redirect-kedjor korta och skicka bara indexerbara URL:er i sitemapen.

Skicka in sitemapen i Search Console, håll den uppdaterad och kontrollera att den bara innehåller sidor som ska indexeras. Blanda inte in noindex-sidor i sitemapen. Fördjupa dig i sitemap och robots.txt.

Hur sitemapen skapas beror på plattform. WordPress med Yoast eller Rank Math genererar den automatiskt, medan headless-lösningar ofta behöver bygga den i publiceringsflödet. Oavsett plattform: en sitemap per innehållstyp, uppdaterade lastmod-värden och inga URL:er som redirectar eller svarar 404.

Strukturerad data är maskinläsbar information om vad sidan innehåller: företag, produkt, artikel, evenemang, frågor och svar. Formatet är oftast JSON-LD, ett skriptblock i sidans head som beskriver sidan med fasta fält. Det gör inte innehållet bättre, men det gör det entydigt för maskiner.

Vanliga typer för svenska företag är Organization, WebSite, BreadcrumbList, Article, Product och FAQPage. Google använder strukturerad data för att förstå sidan och för att visa berikade resultat där sådana finns. Regeln är densamma som för allt annat: datan ska beskriva det som faktiskt står på sidan.

AI-sök. AI Overviews och AI Mode bygger på Googles index. Google skriver att det inte finns några särskilda krav eller optimeringar för att synas i AI-funktionerna, och att du inte behöver skapa nya maskinläsbara filer eller egen schema markup för deras skull. Det som krävs är att sidan är indexerad och kan visas med en snippet. Googles guide till AI-funktionerna i Search listar samma grundprinciper som för vanlig SEO: crawling ska vara tillåten, innehållet ska gå att hitta via interna länkar, viktigt innehåll ska finnas som text, och strukturerad data ska stämma med den synliga texten.

Det tekniska arbetet får därför inte stanna vid rankning. En sida som är blockerad i robots.txt, bara renderas av JavaScript eller saknar intern länkning är lika osynlig för ett AI-svar som för ett vanligt sökresultat. Skriv dessutom stycken som går att lyfta ur sitt sammanhang: svaret i första meningen, sedan förklaringen.

Läs mer om strukturerad data.

Implementera i kod, inte i efterhand. Datum, pris och betyg som skrivs för hand hamnar lätt i konflikt med texten när innehållet uppdateras. Låt mallen läsa från samma fält som sidan visar, och validera med Rich Results Test före publicering.

En teknisk genomgång behöver inte börja med ett dyrt verktyg. Börja med Search Console, som är gratis och bygger på Googles egen data, och arbeta dig sedan nedåt i listan.

1. Verifiera sajten i Search Console och läs rapporterna Sidindexering och Core Web Vitals. Notera vilka sidor som är crawlade men inte indexerade, och varför.
2. Crawla sajten med Screaming Frog, Sitebulb eller ett motsvarande verktyg. Leta efter 404, redirect-kedjor, noindex på viktiga sidor och sidor som bara nås via en enda länk.
3. Granska robots.txt. Blockeras CSS, JavaScript eller viktiga kataloger? Stämmer reglerna med det du faktiskt vill ska indexeras?
4. Kontrollera sitemapen. Innehåller den bara indexerbara URL:er, och är den inskickad i Search Console?
5. Gå igenom canonical. Har varje sida som ska indexeras en self-referential canonical? Finns konflikter mellan sitemap, canonical och redirects?
6. Mät prestandan i fält via Search Console och PageSpeed Insights. Prioritera LCP på sidor som redan får organiskt trafik.
7. Testa renderingen. Jämför URL Inspection-verktygets renderade HTML med källkoden. Finns huvudinnehållet i båda?
8. Validera strukturerad data med Rich Results Test och kontrollera att datan matchar den synliga texten.
9. Prioritera efter affärsvärde. En 404 på en sida som säljer slår tio småfel i bloggen. Åtgärda i ordningen trafik, intäkt, risk.

Vanliga misstag

• Teknisk SEO som engångsprojekt. Problemen uppstår i publiceringstakten, inte i auditen.
• Blockera CSS och JavaScript i robots.txt. Googlebot kan inte rendera sidan korrekt och ser ett tomt skal.
• Redirect-kedjor. Gamla URL:er pekar på mellanliggande URL:er som i sin tur redirectar. Uppdatera målet direkt.
• Kvarvarande noindex efter lansering. Vanligt vid migreringar: sajten är indexerbar i staging men noindex följer med ut i produktion.
• Byta URL:er utan redirect. En ny struktur utan 301-redirect tappar både trafik och länkar.

En genomgång som inte leder till en prioriterad lista är bara en rapport. Skriv ned varje fynd med URL, allvarlighetsgrad och förväntad effekt, och följ upp efter åtgärd så att samma fel inte återkommer vid nästa release.

Testa i små delar: ändra en sak i taget och följ effekten i Search Console i 4–8 veckor innan du går vidare. Alla tekniska påståenden i guiden länkar till Googles egen dokumentation så att du kan verifiera dem själv.

Du behöver inte göra allt på en gång. Det här är arbetssätt, inte ett verktygsbyte. Du behöver inte byta system för att komma igång. Den här ordningen ger mest effekt för minst arbete:

• Börja med det som stoppar indexering. noindex som ligger kvar, trasiga 301:or och sidor som blockeras i robots.txt kostar trafik direkt. Det är billigare att fixa än att bygga nytt.
• Fixa den största bilden först. Oftast är det en okomprimerad hero-bild som drar ned LCP. Komprimera, servera rätt storlek och prioritera bilden. Resten av Core Web Vitals kan vänta.
• Hoppa över crawl-budget om sajten är liten. Har ni några hundra sidor är crawl-budget sällan problemet. Lägg tiden på innehåll och intern länkning i stället.
• Sätt en rutin per kvartal. Gå igenom indexering, 404:or och Core Web Vitals fyra gånger om året. För de flesta sajter är det nog.

Tre åtgärder som är rätt prioriterade slår trettio verktygsrapporter. Läs mer om canonical-taggar eller gå vidare till kunskapsbanken.

Frågor att ställa innan ni köper teknisk SEO-hjälp

• Vilka tre åtgärder prioriterar ni först, och varför just de?
• Hur mäter ni effekten, och vad gör ni om inget händer på 90 dagar?
• Vad tar ni inte på er? Tydliga gränser är ett tecken på att någon vet vad de gör.

Ställ samma frågor till oss.

Vad är skillnaden mellan teknisk SEO och on-page SEO?

Teknisk SEO handlar om infrastrukturen: att sidorna kan crawlas, renderas, indexeras och laddas snabbt. On-page SEO handlar om innehållet på sidan: rubriker, text, title och intern länktext. Tekniken avgör om sidan kan visas. On-page avgör om den är relevant för sökordet.

Vad är skillnaden mellan crawling och indexering?

Crawling är när Googlebot hämtar sidan. Indexering är när Google analyserar den och lagrar informationen i indexet. En sida kan crawlas utan att indexeras, till exempel om den har noindex, är tunn eller liknar en annan sida för mycket.

Hur ofta bör du göra en teknisk SEO-genomgång?

Löpande. Kör en automatisk crawl vid varje större release och en manuell genomgång kvartalsvis. Bevaka Search Console kontinuerligt, eftersom indexeringsfel och prestandaproblem dyker upp mellan genomgångarna.

Räcker bra Core Web Vitals för att ranka bättre?

Nej. Bra värden på LCP, INP och CLS tar bort en teknisk nackdel, men de skapar ingen relevans. Innehåll, intern länkning och externa länkar avgör fortfarande mer. Se trösklarna som ett minimikrav, inte som en rankningsstrategi.

Behöver du strukturerad data för att synas i AI-svar?

Nej. Google säger att det inte krävs någon särskild schema markup eller några nya filer för AI Overviews och AI Mode. Det som krävs är att sidan är indexerad och kan visas med en snippet. Strukturerad data hjälper fortfarande Google att förstå sidan och kan ge berikade resultat.

Varför tappar sidor trafik efter en ombyggnad?

Oftast för att URL:er ändras utan 301-redirect, att noindex ligger kvar från staging eller att intern länkning pekar på gamla adresser. Jämför gamla och nya URL:er i Search Console och lägg redirects från de mest trafikerade sidorna först.

Vill du ha en second opinion på er tekniska grund i stället för en generisk rapport? Vi tittar på crawling, indexering, prestanda och strukturerad data och ger en prioriterad lista, utan att ni behöver binda upp er. Läs mer om teknisk SEO-hjälp. Vi kan också vara en andra åsikt när ni får förslag från andra, inklusive oss.