Teknisk SEO handlar om att sidor ska gå att nå, läsa, förstå och navigera. Börja med statuskoder, indexeringsläge, huvudtext i HTML, en sammanhängande URL-struktur och fungerande interna länkar.
Hitta det som blockerar viktiga sidor, välj en kontrollerbar åtgärd och testa igen.
Lös sådant som hindrar kunder och hämtare innan du lägger till fler tekniska filer. En snabb sida behöver fortfarande användbart innehåll och en tydlig väg till nästa steg.
En teknisk granskning behöver veta vilka sidor som är viktiga och vad de ska göra. Börja med en representativ tjänstesida, en guide och en kontaktväg. Kontrollera svarskod, levererad huvudtext och fungerande länkar. Titta sedan på metadata och hur olika URL-versioner beskrivs. En lång fellista blir lätt oanvändbar när alla avvikelser får samma prioritet.
Canonical beskriver en föredragen URL-version. Ett indexeringsdirektiv och en regel för hämtning är andra mekanismer. Spara därför fynden i separata fält och kontrollera om de stämmer med sidans avsikt. En förhandsvisning kan avsiktligt vara noindex; en viktig lanserad tjänstesida kan behöva en annan konfiguration. Ett tekniskt värde går inte att bedöma som fel utan att veta vilken miljö och vilken sida det gäller.
Jämför den ursprungliga sidkällan med vad besökaren ser. Om huvudtexten kommer först efter att ett script körts behöver du undersöka hur den levereras och vilka användare eller hämtare som får åtkomst. Testa en viktig sida med JavaScript avstängt. Det är en konkret kontroll av den miljön, inte ett bevis på hur varje AI-tjänst behandlar webbplatsen.
Välj sedan åtgärd efter orsaken. Serverrenderat innehåll, statiska sidor eller en ändrad komponent kan vara relevanta alternativ, men en plattformsflytt är inte första svaret på varje avvikelse. Kontaktformulär, tabeller och interna länkar behöver fungera efter förändringen. RANGELs lokala HTML-verktyg läser det material du klistrar in. Det kör inte en crawler, provar inte alla URL:ers status och mäter inte laddningsprestanda.
Laddning, interaktionsrespons och layoutstabilitet behöver bedömas på relevant underlag. Ett labbtest kan hjälpa dig hitta en reproducerbar flaskhals. Fältdata beskriver observerade användarupplevelser i sitt urval. En saknad fältmätning innebär att underlaget saknas, inte att sidan är snabb eller långsam. Märk dessutom om data gäller en URL eller hela webbplatsens ursprung.
För en förändring skriver du symptom, hypotes, ansvarig, åtgärd och omtest i en journal. Testa verkliga kundhandlingar efteråt: navigation, jämförelse, formulär och eventuella köpflöden. Vid en större flytt behöver gamla URL:er få genomtänkta dispositioner och tekniska beroenden inventeras. Att omdirigera allt till startsidan är ingen ersättning för en karta över motsvarande innehåll. Spara en fungerande version och en tydlig väg för återställning.
Granska och skriv om title och meta description för sex sidtyper (tjänst, kategori, artikel, jämförelse, lokal tjänst, verktyg) med hjälp av mallen och de färdiga HTML-exemplen i artikeln.
Granska en sida på din sajt: kontrollera att varje strukturerad data-egenskap motsvarar synligt innehåll och ta bort det som saknar synlig motsvarighet.
02
Felsök något konkret
För trasiga länkar, dubbla versioner eller långsam användning.
Bygg en femkolumns länkjournal (käll-URL, href, HTTP-status, åtgärd, omtestat) och genomför rätt åtgärd per statustyp för minst tio brutna länkar på din webbplats.
Gå igenom webbplatsens fem vanligaste dubblettmönster, klassificera varje URL-par med hjälp av triageramen i artikeln och välj en konkret åtgärd med rätt implementation.
Diagnostisera en långsam tjänstesida steg för steg: lokalisera LCP-elementet, identifiera INP-källan och spåra CLS-skiften – utan att blanda ihop labb- och fältdata eller dra slutsatser från för lite underlag.
03
Ändra utan att tappa kontrollen
För plattform, rendering och verkliga språkversioner.
Genomför en strukturerad HTML-kontroll av fem sidtyper på din WordPress-sajt – bloggpost, tjänstesida, arkiv, sökresultat och kontaktsida – och dokumentera exakt vilket plugin eller temafunktion som äger varje metadatafält.
Implementera och validera en fullständig hreflang-parmatris för en sajt med svenska och brittisk engelska, inklusive self-referens, x-default och en tydlig plan för versioner som ännu inte publicerats.
06 / Ämnets fördjupningar
Hela biblioteket om teknisk seo.
Välj en avgränsad uppgift. Varje fördjupning innehåller exempel, metod och ett eget arbetsblad.
Börja med sådant som hindrar viktiga sidor och kundhandlingar: felstatus, oläsbart huvudmaterial, trasig navigation eller ett formulär som inte fungerar. Prioriteten beror på webbplatsens avsikt och berörda sidor. En generell lista med varningar räcker inte som beslutsunderlag.
Kan RANGELs HTML-kontroll granska hela sajten?+
Nej. Det lokala verktyget läser den HTML du lämnar och kontrollerar vissa synliga metadata och länkar. Det hämtar inte alla sidor, verifierar inte HTTP-status för länkarna och mäter inte Core Web Vitals. En större granskning behöver ett separat underlag och definierad omfattning.
Behöver vi byta från WordPress för bättre SEO?+
Inte automatiskt. Granska vad sajten faktiskt levererar, vilka hinder som finns och om de kan rättas i befintlig miljö. En flytt behöver ett affärs- och förvaltningsskäl samt en kontrollerad URL-karta. Plattformens namn i sig avgör inte om kundens uppgift är löst.
Ska vi skapa /en/ innan engelskt innehåll finns?+
Nej. Planera språkstrukturen, men publicera endast verkliga versioner med fungerande innehåll och destinationer. Hreflang, interna länkar och sitemap ska motsvara publicerade URL:er. När engelska kommer behöver även erbjudande, marknad och kundväg anpassas.
Källor och vidare läsning
Metoderna och exemplen på sidan är RANGELs redaktionella beslutsstöd. Källorna nedan ger kompletterande perspektiv; de bevisar inte hur en viss insats kommer att påverka er synlighet.
