Teknisk SEO-checklista: Den ultimata listan för att förbättra din webbplats

Checklista för teknisk SEO

Genomsökning och indexering

Det första du bör titta på under den tekniska granskningen är hur din webbplats indexeras och genomsöks av sökmotorerna. När allt kommer omkring, om sidorna på din webbplats inte kan genomsökas, kommer de inte att indexeras (med några få undantag). Som en följd av detta kommer de sidor som inte representeras i indexet inte att delta i rankningen.

Gå igenom rapporten om sidindexering i Google Search Console

Det mest exakta och tillförlitliga sättet att analysera indexeringen av din webbplats är att analysera sidindexeringsrapporten i Google Search Console.

Titta på rapporten över indexerade sidor och kontrollera vilka sidor som finns i indexet. Se om det finns sidor med filtrerings- eller sorteringsalternativ, om det finns testsidor eller andra sidor som du inte vill indexera.

Titta också på sidor som har uteslutits.

Alla statusar i rapporten Uteslutna sidor är inte ett problem. Du bör inte fokusera din uppmärksamhet på alla uteslutna sidor, utan bara på de där Googles beteende inte stämmer överens med dina avsikter.

I tabellen nedan kan du se de statusar som tenderar att kräva uppmärksamhet och djupare analys:

Status	Vad det innebär	Vad du bör göra
Fel vid omdirigering	Google kunde inte följa webbadressen på grund av omdirigeringsproblem.	Minska antalet omdirigeringar (till 1-2). Undvik oändliga och cirkulära omdirigeringar.- Se till att den slutliga webbadressen returnerar 200 OK och inte blockeras i robots.txt/noindex.
Fel på servern	Servern returnerade ett 5xx-fel.	Kontrollera serverloggarna. Se till att webbplatsen inte är överbelastad.- Åtgärda interna fel, särskilt om de återkommer.
Upptäckt – ej indexerad	Google känner till sidan men har inte genomsökt den ännu. Indikerar problem med genomsökningsbudget.	Se till att sidan finns i webbplatskartan. Lägg till interna länkar till den. Optimera genomsökningsbudgeten.
Genomsökt – inte indexerad	Google besökte sidan men valde att inte indexera den. Indikerar vanligtvis låg sidkvalitet.	Förbättra innehållets kvalitet och unikhet. Se till att sidan inte har dubbletter. Lägg till interna länkar till den.
Duplicera utan att användaren har valt kanonisk	Google betraktar sidan som en dubblett, men du har inte angett någon kanonisk sida.	Kontrollera sidparen och ange den kanoniska färg som krävs eller se över webbplatsstrukturen.
Duplicera, Google valde en annan kanonisk än användaren	Google ignorerade din angivna kanoniska.	Det kan finnas många anledningar; Du måste noggrant undersöka siddata och välja den lämpligaste strategin (noindex, omdirigering, borttagning, robots.txt, ändringar i webbplatsstruktur och intern länkning).
Mjuk 404	Sidan ser ut som ”tom” eller ”hittades inte” men returnerar statusen 200 OK.	Returnera 404 eller 410. Gör en omdirigering. Förbättra innehållet. Blockera från indexering.

De andra statusarna signalerar förmodligen inte några problem. Dessa rapporter är dock också värda att granska för att se till att sidorna inte har tagits bort, omdirigerats, kanoniserats eller blockerats från indexering av misstag.

Vad

Status	Betydelse	du behöver veta
Alternativ sida med korrekt kanonisk tagg	Google har bekräftat den kanoniska versionen som du har angett.	Allt fungerar som förväntat. Ingen åtgärd krävs. Se till att du har angett önskad kanonisk.
Webbadressen blockeras av robots.txt	Google kan inte genomsöka sidan.	Kontrollera den robots.txt filen. Tillåt åtkomst om du vill att den ska indexeras.
Webbadress som är märkt med ”noindex”	Sidan har direktivet noindex.	Se till att noindex-taggen är inställd avsiktligt. Om sidan är viktig tar du bort den här taggen.
Hittades inte (404)	Sidan finns inte.	Om detta är viktigt, återställ sidan. Om sidan tas bort permanent, se till att det inte finns några interna länkar till den.
Blockerad på grund av obehörig begäran (401)/ Blockerad på grund av förbjuden åtkomst (403)	Sidan är blockerad av auktorisation eller förbjuden.	Tillåt åtkomst om sidan ska indexeras.
Sida med omdirigering	Sidan omdirigeras till en annan.	Kontrollera om omdirigeringen är avsedd och korrekt.
Webbadressen har blockerats på grund av ett annat 4xx-problem	Sidan är otillgänglig på grund av ett annat 4xx-fel än 404 (t.ex. 403, 401, 410, etc.).	Kontrollera HTTP-statuskoden manuellt. Åtgärda åtkomstinställningar. Ställ in korrekta statuskoder eller omdirigeringar. Tillåt åtkomst för Googlebot om det behövs.

I Googles hjälpcenter hittar du en omfattande beskrivning av sidrapporten, inklusive exempel på problem och en detaljerad förklaring av varje status.

Screaming Frog kan också hjälpa till med att analysera sidor som är indexerade eller uteslutna från indexet. För att göra detta måste du ansluta Google Search Console API innan du startar webbplatsgenomsökningen.
För att ansluta, gå till Konfiguration -> API-åtkomst -> Google Search Console. Klicka på Logga in med Google och följ instruktionerna.

När du är ansluten aktiverar du URL-granskning, och du kan också aktivera alternativet att ignorera indexeringsinspektion för URL:er som inte kan indexeras.

Du kommer då att kunna se och jämföra statusen för varje sida enligt Search Console (så som Google ser det) och dess faktiska status som fastställts under genomsökningsprocessen.

Observera att endast 2000 webbadresser per dag är tillgängliga för varje webbplats, så den här metoden är mer lämplig för små webbplatser.

Kontrollera vad som finns i din sitemap.xml

Sitemap.xml är en XML-fil som ger sökmotorernas sökrobotar en lista över sidor på en webbplats, samt (valfritt) information om deras senaste ändringsdatum, uppdateringsfrekvens och rekommenderad genomsökningsprioritet.

Den placeras vanligtvis vid roten av webbplatsen, till exempel: https://example.com/sitemap.xml. Sitemap.xml hjälper sökmotorer att hitta nya eller uppdaterade sidor snabbare. Dessutom är inkluderingen av en sida i den här filen en av signalerna för att bestämma den kanoniska versionen av en sida, om än en svag sådan.

Den sitemap.xml filen är särskilt användbar för:

• nya webbplatser med få externa länkar;
• stora webbplatser med många sidor;
• webbplatser med mycket medieinnehåll;
• nyhetssajter som uppdateras ofta.

Sitemap.xml ska innehålla alla sidor som du vill indexera.

Du kan använda samma Screaming Frog eller andra sökrobotar för att analysera sidorna som ingår i Sitemap.xml. I Screaming Frog kan sitemap.xml skannas separat i listläge, eller så kan det ingå i en vanlig webbplatssökning. För att göra detta, i Configuration -> Spider -> Crawl, aktivera XML-genomsökning av webbplatskartor och lägg till de absoluta webbadresserna till de webbplatskartor du vill genomsöka.

Det rekommenderas inte att använda olika onlinetjänster för att generera en webbplatskarta, eftersom de bara kan generera en statisk webbplatskarta som inte uppdateras automatiskt. Det optimala alternativet är att generera sitemap.xml med hjälp av plugins för det CMS som webbplatsen körs på, eller att skriva ett anpassat skript som genererar webbplatskartan enligt angivna villkor och automatiskt uppdaterar den när ändringar görs på webbplatsen.

När du genererar sitemap.xml, se till att din fil överensstämmer med sitemap.xml-protokollet. Du kan använda olika onlinevaliderare för detta, till exempel https://www.xml-sitemaps.com/validate-xml-sitemap.html.

Är det nödvändigt att inkludera alla taggar som anges i protokollet? Inte alltid. Till exempel tar Google bara hänsyn till taggarna <loc> och <lastmod>. Se till att datumet i <lastmod>-taggen är korrekt. Om det görs försök att manipulera den kan Google ignorera den här taggen.

Se till att det inte finns några misstag i robots.txt

Den robots.txt filen är det första stället en sökrobot tittar på innan den crawlar en webbplats. Det avgör vilka delar av webbplatsen som kan eller inte kan genomsökas, och som ett resultat vilka sidor som kommer att indexeras av sökmotorerna. Den ska alltid placeras på https://example.com/robots.txt.

Den här filen är ett verktyg för att hantera genomsökning (inte indexering!) av webbplatsen. Vissa sidor, även om de är blockerade i robots.txt, kan fortfarande indexeras (vanligtvis om det finns interna eller externa länkar till dem). Sådana sidor (indexerade trots att de är blockerade i robots.txt) kan ses i Google Search Console i rapporten ”Indexerad, men blockerad av robots.txt”.

Här är vad du ska se till att kontrollera när det gäller robots.txt-filen som en del av en teknisk SEO-revision:

1. Filens tillgänglighet

Filen ska vara tillgänglig på https://example.com/robots.txt och ge svarsstatusen 200 OK. Dess frånvaro, nedladdningsfel eller omdirigeringar (301, 302, 403, 404) kan hindra sökmotorer från att korrekt förstå webbplatsens genomsökningsregler.

1. Syntax och korrekthet

Kontrollera att filstrukturen följer standarden. Exempel på en grundläggande mall:

• Användaragent: *
• Tillåt inte: /admin/
• Tillåt: /public/
• Sitemap: https://example.com/sitemap.xml

1. Direktiven Disallow och Allow

Kontrollera att viktiga sidor inte oavsiktligt är otillåtna, t.ex.:

• Hem (/)
• Produktkort (/product/)
• Blogg eller artiklar (/blogg/, /artiklar/)

Ett vanligt misstag är att blockera bilder, stilar och skript när du blockerar administrativa mappar. I ett sådant fall bör det anges att även om den administrativa mappen är blockerad, ska vissa typer av filer vara öppna för genomsökning. Detta händer ofta på WordPress-webbplatser när mappen med allt användarinnehåll, Disallow: /wp-content är blockerad.

I det här fallet kan endast filer av ett visst format öppnas för skanning:

• Tillåt: / wp-content / uploads / * .css
• Tillåt: / wp-content / uploads / * .js
• Tillåt: / wp-content / uploads / * .jpeg

Om du vill verifiera din robots.txt och testa de direktiv som du lägger till kan du använda det här verktyget.

1. Kontrollera kompatibiliteten med andra direktiv

Fel uppstår ofta när robots.txt kommer i konflikt med:

• meta tag <meta name=”robots” content=”noindex”>
• Kanoniska

Om en sida till exempel är öppen i robots.txt men blockerad via noindex kommer den att genomsökas, men kommer inte in i indexet. Detta är acceptabelt, men det är viktigt att det görs avsiktligt.

Ett vanligt problem är också när det finns andra instruktioner för botar i källkoden och en samtidig blockering av sidan i robots.txt. Sökmotorrobotar skannar inte sidor som är blockerade i robots.txt. De ser inte de taggar som anges i koden, till exempel kanonisering. Det vill säga, en sådan kanonisk kommer helt enkelt att vara oredovisad.

Kontrollera din interna länkning

En av de viktigaste uppgifterna för en teknisk revision är att se till att webbplatsens interna länkning fungerar korrekt. Detta innebär att alla interna länkar måste leda till riktiga, befintliga sidor som är öppna för indexering, returnerar statuskoden 200 OK, inte innehåller omdirigeringar och, viktigast av allt, inte pekar på sidor med 4xx/5xx-fel. Vid första anblicken kan detta verka som en liten detalj, men i praktiken kan även felaktiga interna länkar påverka negativt:

• Effektiviteten av sökmotorernas genomsökning av webbplatser,
• Fördelningen av intern SEO-vikt (PageRank),
• Användarupplevelse.

Det första steget i analysen är att kontrollera alla interna länkar för fel. Det är särskilt viktigt att identifiera trasiga länkar som leder till sidor med 404, 410 eller andra fel (t.ex. 403, 500).
Nedan finns en tabell med de viktigaste typerna av fel som kan uppstå i interna länkar, deras betydelse och rekommenderade åtgärder för att åtgärda dem.

här

Feltyp	Betydelse	Gör så
404	Det gick inte att hitta sidan	Ta bort länken eller byt ut den mot en fungerande
403	Tillträde förbjudet	Kontrollera åtkomstinställningarna
301/302	Omdirigera	Uppdatera länken till den slutliga webbadressen
5xx	Fel på servern	Kontrollera servern eller CMS:et

 

Det är också viktigt att analysera djupet i sidhierarkin, det vill säga att avgöra på vilken nivå och hur många klick bort från hemsidan som nyckelinnehållet finns. Det är att föredra att viktiga sidor inte är djupare än den tredje nivån – detta ökar deras tillgänglighet för både sökmotorer och användare.
En av de viktigaste delarna av analysen är att identifiera ”föräldralösa” sidor – de som inte har några interna länkar som pekar till dem. Även om dessa sidor ingår i webbplatskartan gör bristen på interna länkar dem mindre tillgängliga.
Dessutom är det viktigt att analysera ankartexter – de ord och fraser som innehåller länkar. De bör vara relevanta och meningsfulla, eftersom ankartexter hjälper sökmotorerna att förstå länkens sammanhang.

Analysera genomsökningsstatistiken

Analys av genomsökningsstatistik är ett sätt att förstå hur Googlebot interagerar med en webbplats: vilka sidor som genomsöks, hur ofta och hur detta påverkar SEO. Dessa uppgifter finns tillgängliga i Google Search Console → Inställningar → Genomsökningsstatistik. I tabellen nedan kan du se de vanligaste problemen som du kan ta reda på i den här rapporten:

Problem	: Vad du ska leta efter i rapporten	Möjliga orsaker
Kraftig minskning av krypning	Färre genomsökningar per dag	Tillgänglighetsproblem, felaktiga inställningar i robots.txt, block, 5xx-fel
Många 4xx- och 5xx-fel	Fel i webbadresser	Raderade sidor, trasiga länkar, serverproblem
Svarstiden ökad	>1 sekund – ett varningstecken	Värdproblem, överbelastning av servern
Många 3xx-omdirigeringar	Omdirigeringar i stället för direkta webbadresser	Felaktiga omdirigeringar, omdirigeringskedjor, ett stort antal interna länkar med omdirigeringar
CSS/JS har inte genomsökts	De saknas i statistiken	Blockerad av robots.txt

 

Dessutom kan serverloggar analyseras. De låter dig se de faktiska förfrågningarna från sökrobotar (inte bara Googlebot utan även Bingbot, YandexBot och andra), snarare än bara aggregerad data från Google Search Console.
Detta är en avancerad, ”rå” diagnostisk metod som kräver en betydande mängd tid. För att visualisera data kan du använda verktyg med öppen källkod som GoAccess eller Screaming Frog Log File Analyzer.

Implementera strukturerad data

Strukturerad data är ett speciellt uppmärkningsformat på en webbsida som hjälper sökmotorerna att förstå innehållet på sidan mer exakt och djupare. Det fungerar som en ”ledtråd” för Google och andra sökmotorer om vad som exakt finns på sidan – en artikel, produkt, recept, recension, video, etc. Även om det inte är en officiell rankningssignal påverkar den indirekt rankningen genom att förbättra hur sökmotorerna förstår sidan.

Den viktigaste standarden eller protokollet som används för strukturerad data på webbplatser är Schema.org. Det finns andra protokoll, till exempel OpenGraph, men det används för sociala nätverk.
Schema.org är ett samarbetsprojekt mellan Google, Microsoft, Yahoo och Yandex, skapat för att utveckla och upprätthålla en enhetlig standard för strukturerad data på webben.
Schema.org innehåller hundratals enhetstyper, där de vanligaste anges i tabellen nedan:

Kategori	Entitet (@type)	Syfte
Innehåll och sidor	Artikel	En artikel eller nyhetsinnehåll
	Blogginlägg	Ett blogginlägg
	Nyhetsartikel	En nyhetsartikel för Google Nyheter
	Vanliga frågorSida	En sida med vanliga frågor och svar
	Så här gör du	En steg-för-steg-guide
	Webbsida	Allmän information om en webbsida
Produkter och erbjudanden	Produkt	Beskrivning
	Erbjudande	Priserbjudande
	Aggregerat erbjudande	Prisklass för en produkt från olika säljare
Recensioner och betyg	Recension	En recension av en produkt eller tjänst
	Klassificering	Ett numeriskt betyg (ofta inom ramen för en recension)
	Aggregerad betygsättning	Genomsnittligt betyg baserat på flera recensioner
Organisationer och människor	Organisation	En beskrivning av ett företag eller varumärke
	Lokalt företag	Ett lokalt företag med kontaktuppgifter och tidsplan
	Person	En person (t.ex. artikelförfattare, talare, etc.)
Evenemang	Händelse	En online- eller offlinehändelse
Navigering och struktur	Brödsmulelista	Navigering med brödsmulor
	SiteNavigationElement	Alternativ på huvudmenyn
Multimedia	Video-objekt	Video med metadata (för videoklipp)
	ImageObject (på engelska)	Bild med beskrivning
Utbildning och jobb	Kurs	En onlinekurs eller ett utbildningsprogram
	Platsannonsering	Lediga platser (för Google för jobb)

Vi rekommenderar att du implementerar strukturerade data i JSON-LD-format. Det här blocket placeras i <head> eller <body> i HTML-dokumentet, men det visas inte för användaren – det läses av sökrobotar. Alla större sökmotorer, som Google, Bing och Yahoo, stöder detta format. Ett exempel på JSON-LD-kod visas nedan:

<script type=”application/ld+json”>

{

”@context”: ”https://schema.org”,

”@type”: ”Artikel”,

”headline”: ”Vad är JSON-LD?”,

”författare”: {

”@type”: ”Person”,

”name”: ”John Smith”

},

”datePublished”: ”2025-12-01”

}

</manus>

När du implementerar strukturerad data ska du följa Schema.org-protokollet och använda valideraren för att kontrollera att de implementerade mikrodatatyperna är korrekta. Vissa typer av strukturerad data från Schema.org-protokollet kan också hjälpa till att visa avancerade utdrag i Googles sökresultat.

Observera att Googles krav på strukturerad data för avancerade utdrag skiljer sig något från Schema.org-standarden. Ofta behöver fler fält anges än vad Schema.org-protokollet kräver. Så om du vill uppnå ett Rich Snippet, följ Googles riktlinjer för strukturerad data. Du kan kontrollera att mikrodataimplementeringen är korrekt med hjälp av valideraren för rich snippet.

Det finns också många mikrodatageneratorer, men de kan bara skapa statisk kod som inte kommer att uppdateras med innehållsändringar på sidan. Att se till att informationen i mikrodatan matchar det som är synligt för användarna på sidan är en del av Googles krav på strukturerad data. Om du bryter mot policyn för strukturerad data kan sidan förlora alla rich snippets och i vissa fall drabbas av manuella påföljder. Se därför till att dina mikrodata genereras automatiskt och uppdateras automatiskt.

Innehåll

Som en del av en teknisk SEO-revision är det viktigt att utvärdera de grundläggande innehållsegenskaperna: från strukturen av rubriker och metataggar till förekomsten av alt-attribut för bilder och potentiella dubblettsidor. Dessa element har en direkt inverkan på både indexering och hur sökmotorerna uppfattar webbplatsen.

Testa din webbplats för fullständiga dubbletter

Fullständiga dubbletter uppstår när identiskt innehåll är tillgängligt via olika webbadresser på webbplatsen. Dubbletter kan helt skada din webbplats ranking.
De vanligaste typerna av fullständiga dubbletter är:

• Tillgänglighet via både HTTP och HTTPS
• Tillgänglighet med och utan WWW
• Tillgänglighet med eller utan avslutande snedstreck
• Tillgänglighet för webbadresser med versaler och gemener
• Sidan är tillgänglig med filtillägg som .html, .htm, .php, .aspx och utan dem
• Parametrar som inte ändrar sidans innehåll, t.ex. UTM-taggar
• Identiskt innehåll under olika webbadresser. En produkt är till exempel listad i två kategorier, som är tillgängliga via två olika webbadresser. Eller produktsidan som är tillgänglig med och utan kategorin i URL:en.
• Testversioner av webbplatsen (DEV-domän som används för utveckling).

Om du vill hitta siddubbletter som är relaterade till URL-varianter testar du URL:erna manuellt och kontrollerar serverns svarskod för dessa URL-varianter. Du kan använda vilket verktyg som helst för att kontrollera serverns svarskoder, till exempel https://httpstatus.io/. Ange URL-varianterna och kontrollera deras tillgänglighet.

För att åtgärda problem med variationer i HTTP/HTTPS, www/utan-www, med/utan snedstreck, versaler/gemener och tillgängligheten för sidor med tillägg som .html, .htm, .php, .aspx och utan dem, är det nödvändigt att ställa in en 301-omdirigering till den föredragna versionen.

När dubbletter hittas på grund av att identiskt innehåll finns tillgängligt genom att lägga till eller ta bort delar av webbadressen (till exempel om en produkt är tillgänglig i två kategorier) är det bäst att se över webbadressstrukturen och webbplatsstrukturen. För UTM och andra parametrar kan kanonisering också vara en lösning. Det är dock viktigt att notera att Google behandlar den kanoniska taggen som en rekommendation, och det slutliga beslutet om vilken webbadress som ska väljas ligger kvar hos Google.

Om en testversion av webbplatsen finns i Googles index bör den blockeras från indexering och en begäran om att den ska tas bort skickas via Google Search Console.

Lösa partiella siddubbletter

Partiella siddubbletter uppstår när två eller flera sidor på webbplatsen innehåller mycket liknande, men inte helt identiskt innehåll. De vanligaste typerna av partiella dubbletter är:

• Sortera sidor
• Filtrera sidor
• Sidnumrering sidor
• Sidor med liknande produkter (t.ex. produkter som bara skiljer sig åt genom färg)
• Flera versioner av webbplatsen på samma språk, men för olika regioner (t.ex. tre engelska webbplatser för USA, Storbritannien och Australien).

Naturligtvis är varje webbplats unik, och under en teknisk revision kan du identifiera andra fall av duplicerat innehåll som kräver specifika lösningar. Exemplen ovan är dock de vanligaste.

Partiella dubbletter hittas vanligtvis under genomsökningsprocessen av olika sökrobotar. De kommer att ha upprepade parametrar och kan ha samma titel och H1 som huvudkategorisidorna.
För att eliminera partiella dubbletter kan du inte ställa in en omdirigering, eftersom dessa sidor behövs för webbplatsens funktionalitet. Nedan kommer vi att diskutera metoder för att hantera partiella dubbletter.

Sortera och filtrera sidor

Dessa sidor kan blockeras från genomsökning i robots.txt-filen, men detta kan ignoreras av Google, särskilt om länkar pekar på dessa sidor. Detta kommer att hjälpa till att bevara den krypande budgeten.
Du kan också blockera dem via direktivet <meta name=”robots” content=”noindex, nofollow” />, vilket kommer att förhindra att dessa sidor indexeras men inte kommer att tala om för Google att de inte ska genomsökas.
Det bästa sättet i det här fallet är att använda JavaScript för att uppdatera innehållet på sidan när användaren använder sortering eller filter, utan att generera ytterligare URL:er och länkar till filtrerings- eller sorteringssidor.

Produktvarianter som är tillgängliga på olika webbadresser

Helst bör alla produktvarianter kombineras på en sida, där användaren kan välja önskad färg eller storlek utan att ändra URL:en, med hjälp av JavaScript. Men om en separat sida används för varje variant bör en kanonisk länk till huvudproduktsidan anges. Som tidigare nämnts kan Google dock ignorera den kanoniska inställningen av användaren.

Sidnumrering Sidor

Sidnumreringssidor bör inte blockeras från indexering. Så här ser du till att Google betraktar den första sidan i kategorin som den viktigaste:

• Ta bara med den första sidan i den sitemap.xml filen.
• Lägg till en länk till huvudkategorisidan på alla sidnumreringssidor.
• Lägg till sidnummer i rubriken och H1 på sidnumreringssidorna. Till exempel ”Vita skjortor – Sida 2”.

Sidor som är tillgängliga på ett språk men för olika regioner

I det här fallet måste Hreflang-attribut användas. De används för att tala om för sökmotorer vilket språk och vilken regional version av en webbsida de ska visa för användare baserat på deras språkpreferenser och plats.
Det finns flera sätt att implementera Hreflang-attribut:

• I HTTP-huvuden
• Via taggar i avsnittet <head>
• Via taggar i sitemap.xml

Den enklaste metoden att implementera är genom taggar i avsnittet <head>.

Det finns regler som hreflang-attribut som implementeras via taggar i avsnittet <head> ska uppfylla:

• • Attributet ska ha följande format: <link rel=”alternate” hreflang=”lang_code_country_code” href=”url-of-page” />
  • Språk- och landskoder ska vara giltiga. För att välja en giltig kod för varje språkmutation, se den här sidan.

• Varje språkversion måste lista sig själv samt alla andra språkversioner i sina hreflang-attribut. Det betyder att varje sida måste ha samma antal hreflang-attribut

• Länkar i hreflang-attribut ska vara absoluta och indexerbara.

Ett exempel på en kod:

<länk rel=”alternativ” href=”https://example.com/en-us/page” hreflang=”sv-oss” />

<länk rel=”alternativ” href=”https://example.com/en-gb/page” hreflang=”sv-se” />

<länk rel=”alternativ” href=”https://example.com/en-us/page” hreflang=”x-standard” />

Kontrollera titlar, h1, h2s och beskrivningar för dubbletter

Även om titlar, beskrivningar och H1-H6-rubriker är relaterade till on-page SEO kan deras analys inom en teknisk revision vara användbar för att upptäcka dubbletter.

För att analysera dem kan du använda vilken sökrobot som helst som samlar in dessa taggar.

När dubbletter av titlar, H1-H6-taggar och beskrivningar hittas, analysera siddata och identifiera orsaken till dupliceringen. Detta kan bero på tillgängligheten av webbplatsen via både HTTP och HTTPS, duplicering av huvudkategoritaggarna på filtersidor eller helt enkelt ett mänskligt misstag där dessa taggar var felaktigt ifyllda.

Optimera alt-attribut för bilder

Alt-attribut är ett HTML-attribut som används inuti <img>-taggen så här: <img src=”image.jpg” alt=” Beskrivning av bilden”>. Dess huvudsakliga syfte är att ge en textbeskrivning av bildinnehållet. Den här texten visas om bilden inte kan laddas och läses upp av skärmläsare för att underlätta för synskadade användare. Korrekt, beskrivande alt-text kan hjälpa dina bilder att rankas i bildsökning och förbättra sidans övergripande relevans.

Om du har en webbplats med mycket visuellt innehåll är optimering av alt-attribut ett viktigare steg än för klassiska webbplatser som förlitar sig på textinnehåll.

Många sökrobotar som Screaming Frog, Ahrefs, SemRush, etc. analyserar alt-attribut, och där kan du få data om saknade eller tomma alt-attribut.

Du kan läsa mer om hur du skapar beskrivande alt-attribut i officiella Google-dokument.

Webbplatsens hastighet, mobil och användarvänlighet

Använd HTTPs-protokollet

Att använda det säkra HTTPS-protokollet är viktigt för att säkerställa säkerheten vid dataöverföring mellan användaren och servern. Det ökar inte bara användarnas förtroende utan har också en positiv inverkan på SEO. För att söka efter HTTPS tittar du bara på webbläsarens adressfält – en hänglåsikon ska visas.
För en detaljerad analys kan du använda SSL Labs-tjänsten, som ger en fullständig rapport om statusen för SSL-certifikatet och identifierar eventuella problem.

Det är också viktigt att se till att det inte finns något blandat innehåll – HTTP-resurser på HTTPS-sidor. För den här analysen kan du använda HTTPS-rapporten i Google Search Console, som visar webbadresser med både HTTP och HTTPS.

Källa: Search Console för vår klient

Förbättra Core Web Vitals

Core Web Vitals är en uppsättning mätvärden som föreslås av Google för att bedöma kvaliteten på användarupplevelsen på en webbplats. Dessa mätvärden fokuserar på laddningshastighet, interaktivitet och visuell stabilitet för innehållet på sidan. De omfattar tre nyckelindikatorer:

Mått	Beskrivning	Optimalt värde
Största Contentful Paint (LCP)	Mäter laddningstiden för det största synliga elementet på sidan (t.ex. bild eller text).	Mindre än 2,5 sekunder
Fördröjning vid första inmatning (FID)	Mäter den tid det tar för sidan att svara på den första användarinteraktionen (t.ex. att klicka på en knapp eller länk).	Mindre än 100 millisekunder
Kumulativ layoutförskjutning (CLS)	Bedömer sidans visuella stabilitet, dvs. hur mycket elementen rör sig under sidladdningen.	Mindre än 0,1

 

Data som samlats in från riktiga användare kan visas i Search Console-rapporten Diagnos av webbdiagnos (samlad data) eller i PageSpeed Insights (för enskilda tester). När du arbetar med Core Web Vitals ska du komma ihåg att du måste definiera de problem som har stor inverkan på CWV-mätvärdena. När du optimerar LCP måste du till exempel definiera vilken av de 4 aspekterna (TTFB, laddningsfördröjning, laddningstid eller renderingsfördröjning) som bidrar mest till den höga LCP-poängen.

I exemplet nedan är det synligt att vi inte behöver fokusera på optimering av TTFB eller laddningstid. Istället kan vi lägga all vår energi på att förbättra Load Delay och sedan Render Delay.

Källa: https://pagespeed.web.dev/ – test av nike.com webbplats (bara till exempel). Domänen är suddig

Se till att din webbplats är mobilanpassad

Mobilvänlighet har blivit en avgörande faktor sedan 2018 när Google gick över till en mobil-först-indexeringsmetod . Detta innebär att Google nu i första hand använder den mobila versionen av en webbplats för rankning och indexering, snarare än skrivbordsversionen.

I Google Search Console kan du testa dina sidor genom att klicka på ”Testa Live URL” i granskningsverktyget för webbadresser och se hur Googlebot-Mobile ser det.

Komprimera bilder

Bildoptimering som syftar till att komprimera dem utan att förlora kvalitet hjälper till att påskynda laddningen av webbplatsen, särskilt om det finns mycket grafiskt innehåll på sidorna.

Onlineverktyg som TinyPNG eller Squoosh kan användas för att komprimera bilder. Det är också värt att kontrollera om moderna bildformat, som WebP, används, eftersom de kan minska filstorleken avsevärt.

Använd CDN för internationella webbplatser

Att använda ett CDN är meningsfullt om din webbplats betjänar ett brett spektrum av geografiskt avlägsna regioner.

Ett CDN (Content Delivery Network) distribuerar webbplatsens innehåll över servrar som ligger närmare användarna, vilket minskar latensen under laddningen. Du kan kontrollera CDN-användningen genom att undersöka HTTP-begärandehuvuden i webbläsarens utvecklarverktyg (fliken Nätverk), där referenser till CDN-leverantören, till exempel Cloudflare eller Akamai, kan visas. Det finns också onlineverktyg för att testa CDN. CDN-konfiguration görs vanligtvis via värdpanelen eller CMS.

Använda cachelagring
Cachelagring gör det möjligt för webbläsare och proxyservrar att lagra kopior av resurser, vilket minskar serverbelastningen och påskyndar laddningen vid efterföljande besök. Du kan kontrollera att cachelagringen är korrekt i webbläsarens utvecklarverktyg – i avsnittet Nätverk kan du titta på rubrikerna Cache-Control, Expires och ETag. Google PageSpeed Insights ger också rekommendationer för cachelagring. Det är viktigt att statiska resurser (bilder, skript, stilar) har korrekta cachningsinställningar, och servern bör ha motsvarande regler konfigurerade (t.ex. i .htaccess- eller nginx-konfiguration). För att kontrollera cachelagring kan du använda onlinetjänster som GiftOfSpeed.

Slutsats

En teknisk revision av en webbplats är inte en engångsprocedur, utan en pågående process som kräver regelbunden uppmärksamhet på de tekniska faktorer som kan påverka dess prestanda och synlighet. Eftersom varje webbplats är unik kommer det specifika fokuset och frekvensen av kontroller att variera. Den här checklistan för en teknisk SEO-revision hjälper dig att se till att du inte har glömt något viktigt.