Fantastiskt innehåll och perfekt struktur räcker inte om sajten är tekniskt trasig. Google måste kunna crawla, indexera och förstå er sajt – annars spelar resten ingen roll.
Teknisk SEO handlar om att säkerställa att sökmotorer faktiskt kan göra sitt jobb. Det är den osynliga grunden som allt annat bygger på.
Oavsett hur bra en sajt är sett till innehållet finns det så gott som alltid tekniska problem som hindrar synligheten. Och även om sajterna generellt blivit bättre tillkommer det ständigt nya tekniska problem ju mer Google, moderna browsers och webbtekniken förändras.
Vi använder flera olika verktyg för att sammanställa en teknisk audit av alla sajter vi börjar arbeta med. Alla dessa börjar med att crawla sajterna som Googlebot för att vi ska se samma saker som Google ser.
VAD VI ANALYSERAR
Checklistan för lägsta acceptabla tekniska nivå växer ständigt ju mer Google förändras. På senare år har SSL-protokoll, sajternas hastighet och Core Web Vitals tillkommit som kritiska aspekter. Men det har hittills inte hänt att vi fått stryka något från den tekniska checklistan – kraven bara ökar.
Den tekniska analysen mynnar alltid ut i en prioriterad åtgärdslista. Vissa fel är katastrofala och måste åtgärdas omedelbart. Andra är mikrooptimeringar som ger marginell förbättring.
Därtill är det ofta nödvändigt att göra om den tekniska SEO-analysen efter större releaser eftersom gamla fel har en tendens att komma tillbaka och nya tillkomma varje gång ny funktionalitet byggs in på en sajt.
Den tekniska analysen vägs in i vår analys av webbplatsen eftersom den hjälper oss förstå olika sidtypers möjligheter eller svårigheter när det kommer att fånga de bästa positionerna för viktiga sökfraser.
CRAWLBARHET – KAN GOOGLE HITTA ERA SIDOR?
Robots.txt-problem
En felkonfigurerad robots.txt kan blockera Google från att crawla viktiga delar av sajten.
Vanliga problem:
- Blockerar hela sajten av misstag (ofta på staging-sajter som går live utan att robots.txt uppdateras)
- Blockerar viktiga resurser som CSS och JavaScript (Google behöver dessa för att rendera sidor korrekt)
- Blockerar kategorisidor eller tjänstesidor som borde indexeras
Vi granskar alltid robots.txt först i varje teknisk audit.
Sitemap-problem
XML-sitemaps hjälper Google hitta alla viktiga sidor på sajten.
Vanliga problem:
- Sitemap innehåller 404-sidor eller redirects
- Sitemap saknar viktiga sidor
- Sitemap inte uppdaterad när nya sidor läggs till
- Fel URL-format i sitemap (http istället för https, med/utan avslutande slash inkonsekvent)
En bra sitemap innehåller bara sidor ni vill att Google ska indexera – inga 404:or, inga redirects, inga duplikat.
Crawl budget
För stora sajter (tusentals sidor) spelar crawl budget roll. Google crawlar inte alla sidor varje dag.
Problem vi åtgärdar:
- För många oviktiga sidor som stjäl crawl budget (filtreringssidor, sökresultat, parametervarianter)
- Crawl-loopar som spindlar fel delar av sajten
- Långsamma sidor som tar för lång tid att crawla
Lösning: Prioritera viktiga sidor, blockera oviktiga sidor, förbättra hastighet.
INDEXERING – FÖRSTÅR GOOGLE ERA SIDOR RÄTT?
Canonical tags – Det vanligaste problemet
Canonical tags talar om för Google vilken version av en sida som är den ”riktiga”. Felaktiga canonical tags är bland de vanligaste tekniska felen vi ser.
Problem: Felaktig self canonical
Det är nästan vanligare att canonical görs fel än att den inte används alls.
Exempel på katastrofala fel:
- Skriver ut URL:en med parametrar i canonical (motverkar hela syftet med canonical)
- Genomgående skriver URL med avslutande slash trots att sajten länkar utan – eller tvärtom
- Skriver URL utan https trots att sajten har SSL
- Skriver samma URL på samtliga sidor på sajten
- Canonical pekar till en 404-sida eller redirect
Dessa fel är vanligare än man tror.
Varför correct self canonical är kritiskt
För en sida som via sajtens interna länkar nås med URL:en https://www.exempel.se/katalog/sida ska canonical-koden se ut så här:
<link rel="canonical" href="https://www.exempel.se/katalog/sida" />
Anledningen till att det är viktigt – särskilt för sajter som annonserar mycket eller har många samarbeten – är att Google alltför ofta indexerar varianter av URL:ar som innehåller olika parametrar.
Googles egna UTM-parametrar brukar kunna filtreras bort av Google men om URL:en innehåller en extra parameter blir det ofta fel. Med tillräckligt många sådana ”alternativa” URL:ar till en sida är det lätt hänt att Google går vilse och börjar visa parameter-versionen av URL:arna i sökresultaten – men aldrig på den plats de förtjänar eftersom sajten själv inte stödjer den version av sidan som Google bestämt är den bästa.
En korrekt self canonical undanröjer även problem mellan www- och non-www-versioner av en sajt och de alltför vanliga problemen att sidor svarar likadant med och utan avslutande slash i URL:en.
Indexeringsdirektiv – Noindex, nofollow
Ibland vill ni att vissa sidor inte ska indexeras. Det görs med noindex-tag.
Vanliga problem:
- Noindex på viktiga sidor av misstag (ser detta oftare än man tror)
- Noindex saknas på oviktiga sidor (filtreringar, sökresultat, tacksidor)
- Konflikt mellan robots.txt-blockering och noindex (Google kan inte läsa noindex om robots.txt blockerar sidan)
Vi granskar alla indexeringsdirektiv för att säkerställa att rätt sidor indexeras och fel sidor blockeras.
Structured data – Hjälp Google förstå innehållet
Strukturerad data (Schema markup) hjälper Google förstå vad innehållet faktiskt är – produkt, artikel, recept, evenemang, FAQ, etc.
Fördelar med strukturerad data:
- Ger rich snippets i sökresultaten (stjärnbetyg, pris, lagerstatus)
- Hjälper Google förstå innehållet korrekt
- Ökar klickfrekvensen (CTR) genom mer informativa resultat
- Kan ge featured snippets
Vanliga typer vi implementerar:
- Organization (företagsinformation)
- Product (e-handel)
- Article (blogg/nyheter)
- FAQ (vanliga frågor)
- BreadcrumbList (brödsmulor)
- Review (recensioner)
Vi validerar alltid strukturerad data med Googles verktyg för att säkerställa korrekt implementation.
CORE WEB VITALS – HASTIGHET OCH ANVÄNDARUPPLEVELSE
Sedan maj 2021 är Core Web Vitals en rankingfaktor. Google mäter faktisk användarupplevelse.
De tre vitala mätpunkterna
LCP (Largest Contentful Paint) – Laddningstid
Hur lång tid tar det innan huvudinnehållet visas?
Mål: Under 2.5 sekunder
Vanliga problem:
- Stora, ooptimerade bilder
- Långsam server response time
- Blockerande JavaScript och CSS
- Brist på caching
Lösningar:
- Optimera bilder (komprimera, moderna format som WebP)
- CDN för snabbare leverans
- Lazy loading för bilder
- Minifiera CSS och JavaScript
FID (First Input Delay) – Interaktivitet
Hur snabbt svarar sidan på användarinteraktion?
Mål: Under 100 millisekunder
Vanliga problem:
- Tung JavaScript-exekvering blockerar main thread
- För många tredjepartsskript (analytics, annonser)
Lösningar:
- Minska JavaScript-execution time
- Defer eller async för icke-kritisk JavaScript
- Code splitting för att ladda mindre åt gången
CLS (Cumulative Layout Shift) – Visuell stabilitet
Hoppar innehåll runt när sidan laddar?
Mål: Under 0.1
Vanliga problem:
- Bilder utan width/height-attribut
- Annonser eller embeds som laddar dynamiskt
- Webfonts som orsakar FOIT/FOUT
Lösningar:
- Specificera dimensions för alla bilder och videor
- Reservera plats för dynamiskt innehåll
- Font-display: swap för webfonts
Vi mäter Core Web Vitals både i lab (Lighthouse) och i fält (verkliga användare via Search Console).
MOBILE-FIRST INDEXERING
Google indexerar främst mobilversionen av er sajt. Det betyder att mobilversionen är den som räknas.
Vad vi granskar
Innehållsparitet
Har mobilversionen samma innehåll som desktop?
Vanliga problem:
- Viktig text gömd i expanderbara sektioner på mobil
- Bilder saknas på mobil
- Strukturerad data saknas på mobil
Om innehåll finns på desktop men inte mobil kan Google missa det helt.
Användbarhet på mobil
- Är text läsbar utan zoom? (minst 16px font size)
- Är knappar tillräckligt stora? (minst 48x48px touch targets)
- Är spacing mellan klickbara element tillräckligt?
- Fungerar sajten på alla skärmstorlekar?
Hastighet på mobil
Mobila enheter är ofta långsammare än desktop. Optimering för mobil är ännu viktigare.
Vi testar alltid på faktiska mobilenheter, inte bara desktop-simuleringar.
HTTPS OCH SÄKERHET
HTTPS är inte längre optional – det är ett krav.
Vad vi kontrollerar
SSL-certifikat
- Är certifikatet giltigt och inte utgånget?
- Täcker det alla subdomäner ni använder?
- Är det korrekt installerat?
Mixed content
Alla resurser (bilder, skript, stylesheets) måste laddas över HTTPS.
Problem: En HTTPS-sida som laddar HTTP-resurser ger varningar i webbläsaren och kan blockeras helt.
Lösning: Uppdatera alla interna länkar till HTTPS, använd protocol-relative URLs för externa resurser, eller content security policy.
HTTP → HTTPS redirects
Säkerställ att HTTP-versionen redirectar till HTTPS med 301.
RENDERING OCH RESURSER
Problem: För många CSS- och JavaScript-filer
JavaScript-tunga sajter och vissa centraliserade CMS har ofta egenheten att spruta ur sig många JavaScript- och CSS-filer. Detta är dåligt även för användarupplevelsen eftersom det slöar ner sajterna.
Men vad värre är – om en sida vill ladda in för många olika resurser som påverkar sidans utseende kommer Googlebot inte att kunna rendera sidan korrekt.
Gränsen är lite flytande men när den nås slutar Google helt plötsligt att läsa in resurserna i sin rendering vilket visar sig som märkliga sidor i Search Console – och resulterar i sämre placeringar än sajten borde ha. Ibland mycket sämre.
Lösning: Kombinera filer, minifiera, använd code splitting, critical CSS inline.
JavaScript SEO
För JavaScript-tunga sajter (React, Vue, Angular):
Vi kontrollerar:
- Renderar Google innehållet korrekt?
- Finns innehåll i initial HTML eller bara efter JavaScript-exekvering?
- Är viktig metadata tillgänglig före JavaScript?
Lösning ofta: Server-side rendering (SSR) eller static site generation (SSG).
REDIRECTS OCH FELHANTERING
Felaktig hantering av 404 och redirects gjorda på fel sätt
Tar ni ofta bort sidor från sajten? Det är något vi bestämt avråder från – i alla fall utan att göra en genomtänkt 301-redirect till en sida med någotsånär motsvarande innehåll.
Men det händer. När vi ser sajter som tar bort sidor eller helt enkelt byter URL till en sida bara för att rubriken ändras, färgen på produkten förändras, eller produkten är tillfälligt slut, hoppas vi att sidan åtminstone ger en korrekt 404.
Vanligt förekommande fel:
Sidan som tas bort redirectar med 302 (temporär) till en sida som i sig svarar med 404 eller kanske till och med med 200 OK (vilket innebär att sidan finns och svarar som den ska) men sedan inte innehåller någon text.
En vettig, fungerande, och inte alltför betungande funktion för att skapa 301-redirects är ofta bökig att utveckla och implementera men det lönar sig i längden.
När ni gör redirects
Se till att de görs via rätt protokoll. Det finns fantastiska möjligheter till felkällor där sidan https://www.exempel.se/katalog/foo ska redirectas till https://www.exempel.se/katalog/bar.
Vi har sett exempel på redirect-loopar via http, via non-www-versionen av sajten eller en kombination av båda.
Vanligare är att sidan redirectas med 302 vilket inte skickar rätt signaler till Google.
Ett annat vanligt fel är att eventuella parametrar inte tas med i redirecten vilket gör annonsörer ledsna när deras kampanjer inte spåras korrekt.
Best practices för redirects:
- Använd 301 (permanent) för permanenta flyttar
- Använd 302 (temporär) bara när sidan verkligen kommer tillbaka
- Behåll URL-parametrar i redirect
- Redirecta direkt till slutmålet (undvik redirect chains)
- Testa redirects på både http/https och www/non-www
SÖKRESULTAT, FILTER OCH THIN CONTENT
Sökresultatsidor istället för kategorier
För stora sajter – särskilt inom media och retail – är det ofta viktigt att optimera kategorisidor framför enskilda artikel- eller produktsidor eftersom artiklar och produkter har kort livslängd.
En genväg till kategorisering kan vara att arbeta med sökresultatsidor – särskilt om man använder moderna tekniker som Elastic Search som snabbt och elegant kan skapa innehållsrika sidor.
Men genvägar är ofta snåriga och problemen man stöter på med sökresultat är många.
Problemet:
Även om de definierade resultatsidorna är bra skapar man snabbt en uppsjö oväntade resultatsidor baserade på vad kunden söker efter – och kunden söker sällan som man tänkt sig. Hen stavar fel, hen söker efter märkliga saker som inte ens borde finnas på sajten.
Det som händer är att man skapar ”tunt innehåll” på sajten. Sidor som inte har något eget innehåll utan enbart listar länkar till andra sidor.
Lösning:
Vi ser hellre att man helt avindexerar sökresultatsidor genom att förbjuda Googlebot att besöka dem (robots.txt) eller lägga noindex på dem.
För viktiga kategorier: Skapa riktiga kategorisidor med eget innehåll, beskrivningar, SEO-optimering.
Filtreringssidor i e-handel
Liknande problem uppstår med filtrering.
Problem:
/produkter?color=red/produkter?color=red&size=large/produkter?color=red&size=large&brand=nike
Varje kombination skapar en ny URL. Med 10 färger, 5 storlekar, 20 varumärken = 1000 URL:ar.
Lösning:
- Canonical till huvudkategorin
- Eller blockera parametrar i robots.txt
- Eller använd JavaScript-filtrering som inte skapar nya URL:ar
URL-STRUKTUR OCH PARAMETRAR
Problem med URL-parametrar
URL-parametrar kan skapa massiva duplicate content-problem.
Exempel:
/produkt(original)/produkt?sort=pris/produkt?sort=namn/produkt?utm_source=facebook
Samma innehåll, olika URL:ar.
Lösningar:
- Canonical tags till originalversion
- URL Parameters tool i Search Console (säg till Google vilka parametrar som kan ignoreras)
- Statiska URL:ar istället för parametrar där det är möjligt
INTERNATIONALISERING OCH HREFLANG
För sajter på flera språk eller i flera länder är hreflang kritiskt.
Vad hreflang gör:
Talar om för Google vilket språk/land varje version av sidan är avsedd för.
Utan hreflang riskerar ni:
- Svenska användare får engelska sidan
- Engelska användare får svenska sidan
- Google rankar fel version i fel land
Vi implementerar korrekt hreflang och testar att det fungerar.
FRÅN ANALYS TILL HANDLING
Den tekniska analysen mynnar ut i en prioriterad åtgärdslista:
Nivå 1 – Kritiska fel (måste åtgärdas omedelbart)
- Robotstxt blockerar viktiga sidor
- Noindex på huvudsidor
- Felaktiga canonicals som pekar till 404
- Saknar HTTPS eller mixed content-problem
- Massa 404:or eller redirect chains
Nivå 2 – Allvarliga problem (bör åtgärdas snart)
- Core Web Vitals i rött
- Mobile usability-problem
- Saknar strukturerad data
- Duplicate content-problem
- Långsam server response time
Nivå 3 – Optimeringar (förbättrar över tid)
- Förbättra Core Web Vitals från gult till grönt
- Lägg till mer strukturerad data
- Optimera crawl budget
- Förbättra intern länkning tekniskt
- Implementera schema för fler sidtyper
Vi hjälper ofta till med själva implementationen – både enklare fixes och större tekniska förändringar – som en del av vårt löpande SEO-arbete.
Teknisk SEO är inte engångsarbete. Det kräver kontinuerlig bevakning och uppdatering i takt med att Google utvecklas och sajten förändras.
Vill ni få er sajt tekniskt analyserad?
Vi granskar er sajts tekniska grund och identifierar alla problem som hindrar er organiska synlighet.