SEO-checklista: kontrollera det som blockerar först

Varför ordningen i checklistan avgör om arbetet ger resultat

Det finns en logisk hierarki i teknisk SEO som de flesta checklistor ignorerar: om en sida är blockerad från indexering spelar det ingen roll hur välformulerad dess rubrik är eller hur genomtänkt länkstrukturen ser ut. Sökmotorn ser aldrig sidan. Ändå börjar många med att putsa meta-descriptions och lägga till alt-text på bilder, medan sajten i praktiken kryper i mörker bakom en felsatt noindex-tagg eller en trasig redirect.

Den operativa modellen i den här artikeln delar in kontrollerna i tre lager: blockering, relevans och integritet, och mätning. Varje lager är ett villkor för nästa. Du ska inte lägga en timme på att förbättra innehållet på en sida som returnerar 404. Du ska inte analysera konverteringsdata om Analytics inte är kalibrerat. Och du ska inte börja optimera det du inte kan mäta.

Den här guiden är skriven för dig som ansvarar för en liten företagssajt – kanske nyligen lanserad, kanske migrerad från en gammal plattform – och som behöver ett strukturerat sätt att avgöra vad som faktiskt blockerar resultat. Inte en generisk lista på saker att bocka av, utan ett ramverk för att fatta tre konkreta beslut: vad blockerar, vad missmatchas och vad är mätbart.

Lager 1: HTTP-statuskod och indexeringsbarhet

Det allra första du kontrollerar är vad servern faktiskt returnerar när någon – människa eller crawler – besöker din viktigaste URL. Öppna ett terminalfönster och kör:

curl -I https://www.exempel.se/tjanster/

Du förväntar dig HTTP/2 200. Ser du 301, 302, 404 eller 500 i svaret har du ett prioriterat problem att åtgärda innan du gör något annat. En 404 på en URL som tidigare rankat eller som är länkad från externa källor är ett omedelbart inkomstproblem, inte bara ett tekniskt bekymmer.

Kontrollera sedan noindex-statusen. Det räcker inte att titta i CMS-inställningarna – du behöver se det faktiska HTTP-svaret. Kör:

curl -I https://www.exempel.se/tjanster/ | grep -i x-robots
curl https://www.exempel.se/tjanster/ | grep -i noindex

En noindex-tagg kan finnas antingen i HTTP-headern (X-Robots-Tag: noindex) eller i HTML-dokumentets <head> som <meta name="robots" content="noindex">. Båda formaten respekteras av sökmotorer. Om du nyligen migrerade sajten eller bytte plattform är detta ett klassiskt misstag: många stagingmiljöer sätter noindex globalt, och om den inställningen råkade följa med till produktion har sökmotorn fått instruktionen att ignorera hela sajten.

Läs mer om hur canonical-taggar och noindex-direktiv samverkar i guiden om canonical, robots och indexering – den täcker de fall där du vill styra indexering utan att blockera crawlning helt.

Lager 1 fortsätter: redirectkedjor och robots.txt

En enskild, direkt redirect är sällan ett problem. En kedja av redirects – där URL A pekar på B, som pekar på C, som pekar på D – fördröjer crawlning och kan påverka hur länkvärde förs vidare, men det är inte fastställt i vilken utsträckning. Kontrollera hela kedjan med ett verktyg som kan följa alla hopp, exempelvis curl -L -I, och se till att varje gammal URL pekar direkt på den slutliga URL:en utan mellansteg.

301 och 308 är permanenta HTTP-redirects; 308 bevarar metod och kropp. Om din sajt använder 302 (temporär redirect) på sidor som faktiskt är permanent flyttade, bör du byta till 301. En 302 signalerar att flytten är tillfällig, vilket kan påverka hur sökmotorer hanterar den ursprungliga URL:en. Du hittar den tekniska specifikationen i MDN:s guide om HTTP-redirects. Du hittar den fullständiga tekniska specifikationen i MDN:s guide om HTTP-redirects.

Kontrollera robots.txt på https://www.exempel.se/robots.txt. Titta specifikt efter Disallow: / eller Disallow-rader som av misstag täcker dina viktigaste URL:er. En vanlig situation är att en WordPress-installation hade Disallow: /wp-admin/ korrekt, men att en hel sektion av sajten råkade blockeras vid en omstrukturering. Om du använder JavaScript-renderat innehåll är det också viktigt att de JavaScript-filer som behövs för rendering inte är blockerade i robots.txt – läs mer om det i guiden om JavaScript SEO och läsbar HTML.

Lager 2: Money-page-mismatch och integritetskontroll

Med "money page" avses den sida vars primära syfte är att generera ett affärsresultat: en offertförfrågan, ett köp, en bokad demonstration eller ett telefonsamtal. Det är vanligt att dessa sidor lider av tre typer av mismatch som varken syns i ett crawlverktyg eller i Search Console utan att du aktivt letar efter dem.

Innehållsmismatch innebär att sidan rankar för ett sökord men att innehållet inte svarar på den fråga besökaren ställde. En tjänstesida som är skriven för att sälja löpande SEO-arbete men som råkar rankas för "vad kostar SEO" leder in besökare med ett prisjämförelseintresse, inte ett köpintresse. Lösningen är inte att byta nyckelord – det är att förstå vad besökaren faktiskt söker och antingen anpassa sidan eller skapa en separat sida som svarar på prisfrågan och länkar till tjänstsidan.

Formulärmismatch är när kontaktformuläret på money-sidan inte fungerar. Testa det manuellt i ett inkognitofönster. Skicka ett formulär och kontrollera att du dels ser en bekräftelse i gränssnittet, dels att ett e-postmeddelande faktiskt levereras till rätt mottagare. Det händer regelbundet att ett formulärplugin slutar fungera efter en plattformsuppdatering utan att det syns i något övervakningsverktyg. En sida som rankar men har ett trasigt formulär konverterar noll besökare – det är ett affärsproblem med omedelbar prioritet.

Navigationsmismatch innebär att interna länkar från menyn eller från andra sidor pekar fel – till en gammal URL som nu returnerar 404, eller till en mellanlandningssida som inte är tänkt som destination. Kontrollera att din primära navigation pekar direkt till de URL:er du vill indexera. Läs om hur du bygger en begriplig länkstruktur i guiden om interna länkar och navigationsvägar.

RANGELs triagemodell: blockering, mismatch och mätning som tre separata lager

Nedanstående beslutstabell är RANGELs operativa modell för att prioritera åtgärder på en liten företagssajt. Den utgår från tre frågor: Blockeras sidan? Missmatchas den? Är den mätbar? Varje kombination av svar leder till ett specifikt nästa steg. Tabellen är inte en poängmodell – den är ett beslutsverktyg.

Tabellen ovan ska användas som ett levande dokument under de första veckorna efter en lansering eller migration. Bocka av varje rad när beviset är bekräftat – inte när åtgärden är vidtagen. Det är skillnaden mellan att ha gjort något och att ha verifierat att det fungerar.

Illustrativt typfall: 404 efter plattformsbyte

Följande är ett hypotetiskt scenario som illustrerar hur triagemodellen tillämpas i praktiken. Alla siffror och omständigheter är konstruerade för illustrationsändamål.

Föreställ dig ett litet konsultbolag – vi kallar dem Solberg Konsult i det här exemplet – som migrerar sin sajt från ett gammalt CMS till en ny plattform. Den gamla strukturen hade URL:er på formen /tjanster/redovisning/, men den nya plattformen genererar automatiskt /vara-tjanster/redovisning/. Ingen redirect-karta skapades inför migreringen.

Tre veckor efter lansering märker man att kontaktförfrågningar minskat. Man söker på företagets namn och ser att sajten fortfarande syns i sökresultaten, men klickar man på länken hamnar man på en 404-sida. Sökmotorn hade indexerat den gamla URL-strukturen, men nu returnerar den fel.

Diagnos med triagemodellen:

1. Kör curl -I https://solbergkonsult.se/tjanster/redovisning/ – svar: 404 Not Found. Bekräftar blockering.
2. Kontrollera Search Console: URL:en rapporteras som "Hittades inte". Inga klick registreras trots att impressioner fortfarande förekommer (sökmotorn visar den indexerade URL:en).
3. Identifiera att ny URL returnerar 200: /vara-tjanster/redovisning/ fungerar korrekt.
4. Åtgärd: Sätt 301-redirect från /tjanster/redovisning/ till /vara-tjanster/redovisning/ i serverkonfigurationen.
5. Verifiering: Kör curl igen. Svar: 301 Moved Permanently med Location: /vara-tjanster/redovisning/, följt av 200 OK.
6. Begär omindexering av den nya URL:en i Search Console.

Notera att vi i det hypotetiska scenariot inte påstår något om hur snabbt sökmotorn crawlar om eller hur länge det tar innan impressioner och klick normaliseras – det beror på crawlfrekvens och andra faktorer utanför din kontroll. Vad du kan kontrollera är att redirecten är korrekt satt och att rätt URL visas som indexerad i Search Console. Processen för att planera en sådan migration i förväg beskrivs i detalj i guiden om SEO-migrering, URL-karta och säker lansering.

Lager 3: Mätning – verifiering, inte installation

Det räcker inte att Google Analytics och Search Console är installerade. De måste vara kalibrerade och verifierade på ett sätt som gör dem användbara som beslutsunderlag. Det är en avgörande skillnad.

Search Console: Verifiera att rätt property är skapad för rätt domänvariant. En domain property täcker alla subdomäner och protokoll – det är ofta det bästa valet för en liten sajt som inte har separata subdomäner med olika innehåll. Lämna in sitemapen och kontrollera under fliken "Sidor" att de URL:er du förväntar dig att indexera faktiskt är listade som indexerade, inte som "Utesluten" eller "Hittades inte".

Analytics: Det viktigaste målet att konfigurera är formulärinlämning på kontaktsidan. Utan det vet du inte om trafiken konverterar. Konfigurera en händelse som triggeras när bekräftelsesidan visas, eller när formuläret skickas framgångsrikt. Testa händelsen manuellt: öppna Analytics i realtidsläge, fyll i och skicka formuläret och kontrollera att händelsen syns. Utan detta steg är din konverteringsdata tom oavsett hur mycket trafik sajten får.

Om du arbetar med strukturerad data på sajten – exempelvis för att markera tjänster, recensioner eller organisationsinformation – kan det vara värdefullt att undersöka hur Schema.org definierar entitetstyper som Article och relaterade strukturerade dataformat för att förstå vilka fält som är relevanta. Läs mer om hur strukturerad data används praktiskt i guiden om strukturerad data och det som faktiskt finns.

En välkalibrerad mätstack är också förutsättningen för att kunna använda verktyg som hjälper dig prioritera innehållsarbete. RANGELs verktyg SEO-affärscase gör transparent aritmetik på dina egna antagna ingångsvärden – det är inte en kommersiell prognos, och kräver att du har rimliga uppskattningar att utgå ifrån.

SEO-checklista: kontrollera det som blockerar först
https://rangel.se/guider/seo-checklista/

LÄSARUPPGIFT
Gå igenom checklistan lager för lager och åtgärda blockerande fel innan du arbetar med innehåll eller mätning.

Dokumentera en SEO-kontroll
[ ] Kontrollera svaret för rätt URL
Underlag att dokumentera: Spara status, HTTP-headers och HTML för den tillgängliga sidan.
Mitt underlag:
Ansvarig / nästa steg:

[ ] Kontrollera innehåll och länkar
Underlag att dokumentera: Notera direkt svar, metadata och fungerande interna destinationer.
Mitt underlag:
Ansvarig / nästa steg:

[ ] Logga avvikelser och ansvar
Underlag att dokumentera: Ange bevis, ägare och hur varje rättning ska verifieras.
Mitt underlag:
Ansvarig / nästa steg:

Markeringarna är dina egna arbetsnoteringar, inte en granskning av RANGEL eller ett kvalitets-/rankingbetyg.

Crawl-kontroll: vad ser sökmotorn kontra vad du ser

En crawl med exempelvis Screaming Frog ger ett testresultat för just det verktyget och dess inställningar. Den kan hitta statuskoder, länkar, metadata och skillnader mellan hämtad och renderad HTML. Dokumentera hur testet kördes och jämför med serverloggar eller annan tillgänglig mätning. Ett verktyg som imiterar en user-agent bevisar inte vad en verklig sökmotorbot hämtar eller hur dess indexering fungerar.

Det du letar efter i crawlrapporten är specifikt:

• URL:er som returnerar 404 men som är länkade från andra sidor på sajten.
• Sidor med noindex som du vill ha indexerade.
• Sidor utan canonical-tagg eller med felaktig canonical som pekar på en annan URL.
• Sidor med identisk titel och meta-description som andra sidor – ett symptom på tunn eller duplicerad sidstruktur.
• Sidor som inte är länkade från någon annan sida på sajten (orphan pages) men som är listade i sitemapen.

Jämför crawlrapporten med sitemapen. Om sitemapen innehåller URL:er som inte crawlverktyget hittar via intern länkning är det en signal om att navigationsstrukturen inte stöder de sidor du vill prioritera.

Om din sajt bygger på ett ramverk med serversidesgenerering eller on-demand rendering påverkar det hur och när sidor är tillgängliga för crawlning. Ramverk som Astro erbjuder granulär kontroll över vad som renderas statiskt och vad som renderas på begäran – för den tekniska bakgrunden kan det vara relevant att undersöka Astros dokumentation om on-demand rendering om du arbetar med den typen av arkitektur.

Tre väsentligt olika beslut: när ska du agera och när ska du vänta

En vanlig fallgrop är att behandla alla tekniska observationer som akuta åtgärdspunkter. Det leder till ryckigt arbete och gör det svårt att förstå vad som faktiskt gav effekt. Här är tre väsentligt olika beslutssituationer och hur triagemodellen hanterar dem:

Beslut 1: Ny sajt har noindex på hela sajten

Det här är en blockeringssituation. Alla andra åtgärder ska pausas tills noindex är borttagen och verifierad. Kontrollera om inställningen sitter i CMS:et (WordPress har en inställning under Inställningar > Läsning), i en serversidesmall eller i ett plugin. Verifiera borttagningen med curl på minst tre URL:er: startsidan, en tjänstesida och en bloggpost. Lämna in en omcrawlingsförfrågan i Search Console för startsidan.

Beslut 2: Sajten indexeras men inga förfrågningar kommer in

Det här är troligtvis inte ett blockeringsproblem – det är ett mismatch- eller konverteringsproblem. Kontrollera först att kontaktformuläret fungerar (manuellt test i inkognito). Kontrollera sedan att money-sidans innehåll matchar den sökavsikt som driver trafiken. Titta i Search Console på vilka faktiska sökfrågor som ger klick till sidan – om de skiljer sig markant från vad du förväntar dig är det ett innehållsproblem, inte ett tekniskt problem. Verktyget innehållsbeskrivning kan hjälpa dig strukturera ett lokalt arbetsdokument för en omskrivning av sidan.

Beslut 3: Allt verkar fungera men du vet inte säkert

Utan dokumentation får nästa granskare svårt att skilja genomförd kontroll från antaganden. Dokumentera URL, test, observerat resultat, ansvarig och nästa åtgärd i samma register. Använd vår metod för canonical och indexering när ni behöver kontrollera URL-signalerna.

Konkret checklista: kontroll med bevis

Följande checklista är ordnad efter triagemodellens prioritetslogik. Bocka av en punkt först när du har det bevis som anges, inte när du tror att det borde vara rätt. Om du genomför en migration är den parallella guiden om SEO-migrering ett komplement till den här listan.

1. Statuskod 200 på alla prioriterade URL:er. Bevis: curl -I visar 200 på startsida, alla money-pages och navigationsankarpunkter.
2. Inga noindex-direktiv på sidor avsedda för indexering. Bevis: grep på faktisk HTML-källkod och HTTP-header visar frånvaro av noindex.
3. robots.txt blockerar inga prioriterade URL-mönster. Bevis: manuell genomläsning av robots.txt, test med Search Consoles robots.txt-testare.
4. Alla redirects från gamla URL:er är direkta 301:or till slutlig destination. Bevis: curl -L -I visar exakt ett Location-hopp innan 200.
5. Kontaktformulär fungerar och levererar e-post. Bevis: manuellt test i inkognito, bekräftad e-postleverans till rätt inkorg.
6. Interna navigeringslänkar pekar på 200-URL:er. Bevis: crawlrapport utan brutna interna länkar i huvudnavigation och footer.
7. Search Console verifierad och sitemap inlämnad. Bevis: verifieringsstatus "Verifierad" i Search Console, sitemap listad med 0 fel.
8. Analytics mäter minst ett konverteringsmål. Bevis: manuellt formulärtest syns som händelse i Analytics realtidsrapport.
9. Inga orphan pages i sitemap. Bevis: jämförelse av sitemap-URL:er med crawlrapportens internt länkade URL:er – inga diskrepanser.
10. Canonical-taggar på alla sidor pekar på rätt URL. Bevis: crawlrapport visar att canonical matchar crawlad URL på varje sida, inga avvikelser.

Om du vill ha hjälp med den tekniska genomgången och prioriteringen erbjuder RANGEL teknisk SEO som en avgränsad tjänst – arbetet utgår alltid från en faktisk triage av din sajt, inte en generisk mall.

För en ny sajt finns en separat mall för minsta användbara lansering. Den avgränsar vilka kundsidor som behövs först, vad som kan vänta och hur kontaktvägen godkänns.

Vad checklistan inte löser: gränsen för teknisk SEO

En korrekt teknisk grund är ett nödvändigt men inte tillräckligt villkor för att en sajt ska prestera. När alla blockeringar är åtgärdade och mätningen är kalibrerad återstår frågor om innehållsrelevans, auktoritet och sökavsikt – områden som den tekniska checklistan inte direkt adresserar.

Det är viktigt att ha den gränsen klar för sig, särskilt om du presenterar arbetet internt för en beslutsfattare. Teknisk SEO tar bort hinder; innehåll och relevans bygger synlighet. Att presentera en åtgärdad 404 som en "SEO-förbättring" är korrekt i den meningen att ett hinder är borttaget, men det ska inte förväxlas med en förbättring av sajtens position för ett konkurrenskraftigt sökord.

För att kommunicera det internt på ett strukturerat sätt kan Verktyget innehållsformat kan ge en regelbaserad formatrekommendation som stöd för nästa skede av arbetet, och AI-mätning kan ge stöd för att strukturera observationer i CSV-format som du laddar upp lokalt. Teknisk SEO och innehållsarbete är sekventiella, inte parallella – den tekniska grunden läggs först, men den är inte slutpunkten.

Stoppa arbetet när checklistan ovan är komplett med faktiska bevis för varje punkt. Det är den rimliga definitionen av "tekniskt färdig". Allt som återstår därefter är ett annat problem – och ett annat arbetsmoment.