Teknisk SEO-tjekliste: Den ultimative liste til at forbedre din hjemmeside

Teknisk SEO-tjekliste

Crawling og indeksering

Den første ting, du skal se på under den tekniske revision, er, hvordan dit websted indekseres og gennemgås af søgemaskiner. Hvis siderne på dit website ikke kan crawles, vil de ikke blive indekseret (med få undtagelser). Som følge heraf vil de sider, der ikke er repræsenteret i indekset, ikke deltage i rangeringen.

Gennemgå sideindekseringsrapporten i Google Search Console

Den mest præcise og pålidelige måde at analysere indekseringen af dit website på er at analysere sideindekseringsrapporten i Google Search Console. Se på rapporten over indekserede sider, og tjek, hvilke sider der er i indekset. Se, om der er sider med filtrerings- eller sorteringsmuligheder, om der er testsider eller andre sider, som du ikke ønsker at indeksere. Se også på sider, der er blevet udelukket. Ikke alle statusser i rapporten Udelukkede sider er et problem. Du skal ikke fokusere på alle ekskluderede sider, men kun på dem, hvor Googles adfærd ikke stemmer overens med dine intentioner. I tabellen nedenfor kan du se de statusser, der har tendens til at kræve opmærksomhed og dybere analyse:

Status	Hvad det betyder	Hvad du bør gøre
Fejl ved omdirigering	Google var ikke i stand til at følge URL’en på grund af problemer med omdirigering.	Reducer antallet af redirects (til 1-2). Undgå uendelige og cirkulære omdirigeringer – Sørg for, at den endelige URL returnerer 200 OK og ikke er blokeret i robots.txt/noindex.
Serverfejl	Serveren returnerede en 5xx-fejl.	Tjek serverens logfiler. Sørg for, at webstedet ikke er overbelastet – Ret interne fejl, især hvis de gentager sig.
Opdaget – ikke indekseret	Google kender til siden, men har ikke crawlet den endnu. Indikerer problemer med crawling-budgettet.	Sørg for, at siden er i sitemap. Tilføj interne links til den. Optimer crawling-budgettet.
Gennemsøgt – ikke indekseret	Google besøgte siden, men valgte ikke at indeksere den. Indikerer normalt lav sidekvalitet.	Forbedr kvaliteten og det unikke i indholdet. Sørg for, at siden ikke har duplikater. Tilføj interne links til den.
Duplikat uden brugervalgt canonical	Google betragter siden som et duplikat, men du har ikke angivet en canonical.	Tjek sideparrene, og angiv den nødvendige canonical, eller genovervej hjemmesidens struktur.
Duplikat, Google valgte en anden canonical end brugeren	Google ignorerede din angivne canonical.	Der kan være mange grunde; du skal omhyggeligt undersøge sidedataene og vælge den mest hensigtsmæssige strategi (noindex, omdirigering, fjernelse, robots.txt, ændringer i websitets struktur og intern linking).
Blød 404	Siden ser “tom” eller “ikke fundet” ud, men returnerer en 200 OK-status.	Returner 404 eller 410. Lav en omdirigering. Forbedre indholdet. Bloker for indeksering.

De andre statusser signalerer sandsynligvis ikke nogen problemer. Men disse rapporter er også værd at gennemgå for at sikre, at siderne ikke er blevet fjernet, omdirigeret, kanoniseret eller blokeret fra indeksering ved en fejltagelse.

Status	Hvad betyder det?	Hvad du har brug for at vide
Alternativ side med korrekt kanonisk tag	Google har korrekt anerkendt det kanoniske tag, du har angivet.	Alt fungerer som forventet. Der kræves ingen handling. Sørg for, at du har angivet den ønskede canonical.
URL blokeret af robots.txt	Google kan ikke crawle siden.	Tjek robots.txt-filen. Tillad adgang, hvis du ønsker, at den skal indekseres.
URL markeret med ‘noindex’	Siden har noindex-direktivet.	Sørg for, at noindex-tagget er sat med vilje. Hvis siden er vigtig, skal du fjerne dette tag.
Ikke fundet (404)	Siden findes ikke.	Hvis det er vigtigt, skal du gendanne siden. Hvis siden er permanent slettet, skal du sikre dig, at der ikke er nogen interne links til den.
Blokeret på grund af uautoriseret anmodning (401)/ Blokeret på grund af adgang forbudt (403)	Siden er blokeret af autorisation eller forbudt.	Tillad adgang, hvis siden skal indekseres.
Side med omdirigering	Siden omdirigerer til en anden.	Tjek, om omdirigeringen er tilsigtet og korrekt.
URL blokeret på grund af andet 4xx-problem	Siden er utilgængelig på grund af en anden 4xx-fejl end 404 (f.eks. 403, 401, 410 osv.).	Tjek HTTP-statuskoden manuelt. Ret adgangsindstillingerne. Indstil korrekte statuskoder eller omdirigeringer. Tillad adgang for Googlebot, hvis det er nødvendigt.

I Googles hjælpecenter kan du finde en omfattende beskrivelse af siderapporten, herunder eksempler på problemer og en detaljeret forklaring af hver status. Screaming Frog kan også hjælpe med at analysere sider, der er indekseret eller udelukket fra indekset. For at gøre dette skal du oprette forbindelse til Google Search Console API, før du starter gennemgangen af webstedet. For at oprette forbindelse skal du gå til Konfiguration -> API-adgang -> Google Search Console. Klik på Log ind med Google, og følg instruktionerne.

Når du har oprettet forbindelse, skal du aktivere URL-inspektion, og du kan også aktivere muligheden for at ignorere indekseringsinspektion for URL’er, der ikke kan indekseres.

Du vil derefter kunne se og sammenligne hver sides status ifølge Search Console (sådan som Google ser den) og dens faktiske status, som den blev bestemt under crawlprocessen.

Bemærk, at der kun er 2000 URL’er pr. dag til rådighed for hvert site, så denne metode er mere velegnet til små sites.

Tjek, hvad der er i din sitemap.xml

Sitemap.xml er en XML-fil, der giver søgemaskinernes crawlere en liste over sider på et websted samt (eventuelt) oplysninger om deres sidste ændringsdato, opdateringsfrekvens og anbefalede crawl-prioritet. Den placeres normalt i roden af webstedet, for eksempel: https://example.com/sitemap.xml. Sitemap.xml hjælper søgemaskiner med at finde nye eller opdaterede sider hurtigere. Desuden er medtagelsen af en side i denne fil et af signalerne til bestemmelse af den kanoniske version af en side, om end det er et svagt signal.

Filen sitemap.xml er især nyttig for:

• nye websteder med få eksterne links;
• store sites med mange sider;
• sider med meget medieindhold;
• nyhedssider, der opdateres ofte.

Sitemap.xml skal indeholde alle de sider, du vil indeksere. Du kan bruge den samme Screaming Frog eller andre crawlere til at analysere de sider, der er inkluderet i Sitemap.xml. I Screaming Frog kan sitemap.xml scannes separat i List Mode, eller den kan inkluderes i en almindelig scanning af sitet. For at gøre dette skal du i Configuration -> Spider -> Crawl aktivere XML-sitemap-scanning og tilføje de absolutte URL’er til de sitemaps, du vil gennemgå. Det anbefales ikke at bruge forskellige onlinetjenester til at generere et sitemap, da de muligvis kun genererer et statisk sitemap, der ikke opdateres automatisk. Den optimale løsning er at generere sitemap.xml ved hjælp af plugins til det CMS, som webstedet kører på, eller at skrive et brugerdefineret script, der genererer sitemap i henhold til angivne betingelser og automatisk opdaterer det, når der foretages ændringer på webstedet. Når du genererer sitemap.xml, skal du sørge for, at din fil overholder sitemap .xml-protokollen. Du kan bruge forskellige online-validatorer til dette, f.eks. https://www.xml-sitemaps.com/validate-xml-sitemap.html. Er det nødvendigt at medtage alle de tags, der er anført i protokollen? Nej, ikke altid. For eksempel tager Google kun hensyn til <loc>- og <lastmod>-tags. Vær sikker på, at datoen i <lastmod>-tagget er korrekt. Hvis der er forsøg på at manipulere den, kan Google ignorere dette tag.

Sørg for, at der ikke er fejl i robots.txt

Filen robots.txt er det første sted, en søgerobot kigger, før den crawler et site. Den bestemmer, hvilke dele af webstedet der kan eller ikke kan gennemsøges, og dermed hvilke sider der vil blive indekseret af søgemaskinerne. Den bør altid være placeret på https://example.com/robots.txt. Denne fil er et værktøj til at styre crawling (ikke indeksering!) af webstedet. Nogle sider kan stadig indekseres, selv om de er blokeret i robots.txt (normalt hvis der er interne eller eksterne links til dem). Sådanne sider (indekseret på trods af, at de er blokeret i robots.txt) kan ses i Google Search Console i rapporten “Indekseret, men blokeret af robots.txt”.

Her er, hvad du skal sørge for at tjekke med hensyn til robots.txt-filen som en del af en teknisk SEO-revision:

1. Filens tilgængelighed

Filen skal være tilgængelig på https://example.com/robots.txt og give en 200 OK-svarstatus. Dens fravær, downloadfejl eller omdirigeringer (301, 302, 403, 404) kan forhindre søgemaskiner i at forstå sitets crawling-regler korrekt.

1. Syntaks og korrekthed

Tjek, at filstrukturen følger standarden. Eksempel på en grundlæggende skabelon:

• Bruger-agent: *
• Tillad ikke: /admin/
• Tillad: /public/
• Sitemap: https://example.com/sitemap.xml

1. Disallow- og Allow-direktiver

Tjek, at vigtige sider ikke ved et uheld bliver afvist, f.eks:

• Hjem (/)
• Produktkort (/product/)
• Blog eller artikler (/blog/, /articles/)

En almindelig fejl er at blokere billeder, stilarter og scripts, når man blokerer administrative mapper. I et sådant tilfælde skal det specificeres, at selvom den administrative mappe er blokeret, skal nogle typer filer være åbne for scanning. Dette sker ofte på WordPress-websteder, når mappen med alt brugerindhold, Disallow: /I dette tilfælde er det kun filer i et bestemt format, der kan åbnes til scanning:

• Tillad: /wp-content/uploads/*.css
• Tillad: /wp-content/uploads/*.js
• Tillad: /wp-content/uploads/*.jpeg

Du kan bruge dette værktøjtil at validere din robots.txt og teste de direktiver, du vil tilføje.

1. Tjek kompatibiliteten med andre direktiver

Der opstår ofte fejl, når robots.txt er i konflikt med:

• metatag <meta name=”robots” content=”noindex”>.
• kanonisk

Hvis en side f.eks. er åben i robots.txt, men blokeret via noindex, vil den blive crawlet, men ikke komme med i indekset. Det er acceptabelt, men det er vigtigt, at det sker med vilje. Et almindeligt problem er også, når der er andre instruktioner til bots i kildekoden og en samtidig blokering af siden i robots.txt. Søgemaskinernes robotter scanner ikke sider, der er blokeret i robots.txt. De ser ikke de tags, der er angivet i koden, f.eks. kanonisering. Det vil sige, at en sådan canonical simpelthen ikke vil blive taget højde for.

Tjek dine interne links

En af de vigtigste opgaver i en teknisk revision er at sikre, at hjemmesidens interne linking fungerer korrekt. Det betyder, at alle interne links skal føre til rigtige, eksisterende sider, der er åbne for indeksering, returnerer en 200 OK-statuskode, ikke indeholder omdirigeringer og, vigtigst af alt, ikke peger på sider med 4xx/5xx-fejl. Ved første øjekast kan det virke som en mindre detalje, men i praksis kan selv forkerte interne links have en negativ effekt:

• Effektiviteten af søgemaskinernes crawling af hjemmesiden,
• Fordelingen af intern SEO-vægt (PageRank),
• Brugeroplevelsen.

Det første skridt i analysen er at tjekke alle interne links for fejl. Det er især vigtigt at identificere ødelagte links, der fører til sider med 404, 410 eller andre fejl (f.eks. 403, 500). Nedenfor er en tabel med de vigtigste typer fejl, der kan opstå i interne links, deres betydning og anbefalede handlinger for at rette dem.

Fejltype	Hvad det betyder	Hvad skal man gøre?
404	Siden blev ikke fundet	Fjern linket, eller erstat det med et, der virker
403	Adgang forbudt	Tjek adgangsindstillingerne
301/302	Omdiriger	Opdater linket til den endelige URL
5xx	Serverfejl	Tjek serveren eller CMS’et

Det er også vigtigt at analysere dybden af sidehierarkiet, dvs. at finde ud af, på hvilket niveau og hvor mange klik væk fra hjemmesiden det vigtigste indhold er placeret. Det er at foretrække, at vigtige sider ikke er dybere end tredje niveau – det øger deres tilgængelighed for både søgemaskiner og brugere. Et af de vigtigste elementer i analysen er at identificere “forældreløse” sider – dem, der ikke har nogen interne links, der peger på dem. Selv om disse sider er inkluderet i sitemap, gør manglen på interne links dem mindre tilgængelige. Derudover er det vigtigt at analysere ankertekster – de ord og sætninger, der indeholder links. De skal være relevante og meningsfulde, da ankertekster hjælper søgemaskinerne med at forstå konteksten for linket.

Analyser crawl-statistikkerne

Analyse af crawlstatistikker er en måde at forstå, hvordan Googlebot interagerer med et website: hvilke sider der crawles, hvor ofte, og hvordan det påvirker SEO. Disse data er tilgængelige i Google Search Console → Indstillinger → Crawl-statistik. I tabellen nedenfor kan du se de mest almindelige problemer, som du kan finde ud af i denne rapport:

Problem	Hvad du skal kigge efter i rapporten	Mulige årsager
Kraftigt fald i gennemsøgning	Færre gennemsøgninger pr. dag	Problemer med tilgængelighed, forkerte indstillinger i robots.txt, blokeringer, 5xx-fejl
Mange 4xx- og 5xx-fejl	Fejl i URL’er	Slettede sider, ødelagte links, serverproblemer
Svartiden er steget	>1 sekund – et advarselstegn	Hostingproblemer, overbelastning af serveren
Mange 3xx-omdirigeringer	Omdirigeringer i stedet for direkte URL’er	Forkerte redirects, redirect-kæder, et stort antal interne links med redirects
CSS/JS er ikke crawlet	De mangler i statistikkerne	Blokeret af robots.txt

Derudover kan serverlogs analyseres. De giver dig mulighed for at se de faktiske anmodninger fra søgerobotter (ikke kun Googlebot, men også Bingbot, YandexBot og andre) i stedet for blot aggregerede data fra Google Search Console. Dette er en avanceret, “rå” diagnostisk metode, der kræver en betydelig mængde tid. For at visualisere dataene kan du bruge open source-værktøjer som GoAccess eller Screaming Frog Log File Analyser.

Implementer strukturerede data

Strukturerede data er et særligt markeringsformat på en webside, som hjælper søgemaskiner med at forstå sidens indhold mere præcist og dybtgående. Det fungerer som et “hint” til Google og andre søgemaskiner om, hvad der præcist er på siden – en artikel, et produkt, en opskrift, en anmeldelse, en video osv. Selv om det ikke er et officielt ranking-signal, påvirker det indirekte rankingen ved at forbedre søgemaskinernes forståelse af siden. Den vigtigste standard eller protokol, der bruges til strukturerede data på websites, er Schema.org. Der findes andre protokoller, f.eks. OpenGraph, men den bruges til sociale netværk. Schema.org er et samarbejdsprojekt mellem Google, Microsoft, Yahoo og Yandex, der er oprettet for at udvikle og vedligeholde en fælles standard for strukturerede data på nettet. Schema.org omfatter hundredvis af enhedstyper, hvoraf de mest anvendte er anført i tabellen nedenfor:

Kategori	Entitet (@type)	Formål
Indhold og sider	Artikel	En artikel eller nyhedsindhold
	Blogindlæg	Et blogindlæg
	Nyhedsartikel	En nyhedsartikel til Google News
	FAQSide	En side med ofte stillede spørgsmål (FAQ)
	HowTo	En trin-for-trin-guide
	Webside	Generel information om en webside
Produkter og tilbud	Produkt	Beskrivelse af produktet
	Tilbud	Pristilbud
	Samlet tilbud	Prisinterval for et produkt fra forskellige sælgere
Anmeldelser og bedømmelser	Anmeldelse	En anmeldelse af et produkt eller en tjeneste
	Bedømmelse	En numerisk vurdering (ofte inden for en anmeldelse)
	Samlet bedømmelse	Gennemsnitlig vurdering baseret på flere anmeldelser
Organisationer og personer	Organisation	En beskrivelse af en virksomhed eller et brand
	LokalVirksomhed	En lokal virksomhed med kontaktoplysninger og tidsplan
	Person	En person (f.eks. artikelforfatter, foredragsholder osv.)
Begivenheder	Begivenhed	En online eller offline begivenhed
Navigation og struktur	BrødkrummeListe	Navigation med brødkrummer
	SiteNavigationElement	Hovedmenupunkter
Multimedie	VideoObjekt	Video med metadata (til videouddrag)
	BilledeObjekt	Billede med beskrivelse
Uddannelse og job	Kursus	Et online kursus eller træningsprogram
	Jobopslag	Ledigt job (til Google for Jobs)

Det anbefales at implementere strukturerede data i JSON-LD-formatet. Denne blok placeres i <head> eller <body> i HTML-dokumentet, men den vises ikke for brugeren – den læses af søgerobotter. Alle større søgemaskiner som Google, Bing og Yahoo understøtter dette format. Et eksempel på JSON-LD-kode er vist nedenfor: <script type=”application/ld+json”> { “@context”: “https://schema.org”, “@type”: “Artikel”, “overskrift”: “Hvad er JSON-LD?”, “author”: { “@type”: “Person”, “name”: “John Smith” }, “datePublished”: “2025-12-01” } </script> Når du implementerer strukturerede data, skal du følge Schema.org-protokollen og bruge validatoren til at kontrollere, at de implementerede mikrodatatyper er korrekte. Nogle typer strukturerede data fra Schema.org-protokollen kan også hjælpe med at vise rich snippets i Googles søgeresultater. Bemærk, at Googles krav til strukturerede data til rich snippets afviger en smule fra Schema.org-standarden. Ofte skal der angives flere felter, end hvad Schema.org-protokollen kræver, så hvis du vil have et Rich Snippet, skal du følge Googles retningslinjer for strukturerede data. Du kan tjekke, om mikrodata-implementeringen er korrekt ved hjælp af Rich Snippet-validatoren. Der findes også mange mikrodatageneratorer, men de kan kun skabe statisk kode, som ikke opdateres med ændringer i indholdet på siden. Det er en del af Googles krav til strukturerede data at sikre, at oplysningerne i mikrodataene matcher det, der er synligt for brugerne på siden. Hvis politikken for strukturerede data overtrædes, kan siden miste alle rich snippets og i nogle tilfælde blive straffet manuelt. Sørg derfor for, at dine mikrodata genereres automatisk og opdateres automatisk.

Indhold

Som en del af en teknisk SEO-revision er det vigtigt at evaluere de grundlæggende indholdskarakteristika: fra strukturen af overskrifter og metatags til tilstedeværelsen af alt-attributter til billeder og potentielle duplikatsider. Disse elementer har direkte indflydelse på både indeksering og på, hvordan søgemaskinerne opfatter webstedet.

Test dit website for fulde duplikater

Fuldstændige duplikater opstår, når identisk indhold er tilgængeligt via forskellige URL’er på webstedet. Duplikater kan skade dit websteds rangering fuldstændigt. De mest almindelige typer af fulde duplikater er:

• Tilgængelighed via både HTTP og HTTPS
• Tilgængelighed med og uden WWW
• Tilgængelighed med eller uden en efterfølgende skråstreg
• Tilgængelighed af URL’er med store og små bogstaver
• Siden er tilgængelig med filtypenavne som .html, .htm, .php, .aspx og uden dem
• Parametre, der ikke ændrer sidens indhold, f.eks. UTM-tags
• Identisk indhold under forskellige URL’er. For eksempel er et produkt opført i to kategorier, der er tilgængelige via to forskellige URL’er. Eller produktsiden er tilgængelig med og uden kategorien i URL’en.
• Testversioner af webstedet (DEV-domæne, der bruges til udvikling).

For at finde sideduplikater relateret til URL-variationer skal du teste URL’erne manuelt og kontrollere serverens svarkode for disse URL-varianter. Du kan bruge et hvilket som helst værktøj til at tjekke serverresponskoderne, f.eks. https://httpstatus.io/. Indtast URL-varianterne, og tjek deres tilgængelighed.

For at løse problemer med variationer i HTTP/HTTPS, www/uden-www, med/uden skråstreg, store/små bogstaver og tilgængeligheden af sider med udvidelser som .html, .htm, .php, .aspx og uden dem, er det nødvendigt at oprette en 301-omdirigering til den foretrukne version. Når der findes dubletter på grund af tilgængeligheden af identisk indhold ved at tilføje eller fjerne dele af URL’en (for eksempel er et produkt tilgængeligt i to kategorier), er det bedst at genoverveje URL -strukturen og webstedsstrukturen. For UTM og andre parametre kan kanonisering også være en løsning. Det er dog vigtigt at bemærke, at Google behandler det kanoniske tag som en anbefaling, og den endelige beslutning om, hvilken URL der skal vælges, ligger hos Google. Hvis der findes en testversion af webstedet i Googles indeks, skal den blokeres fra indeksering, og der skal sendes en anmodning om fjernelse via Google Search Console.

Løs delvise sideduplikater

Delvise sideduplikater opstår, når to eller flere sider på webstedet indeholder meget lignende, men ikke helt identisk indhold. De mest almindelige typer af delvise duplikater er:

• Sortering af sider
• Filter-sider
• Sider med paginering
• Sider med lignende produkter (f.eks. produkter, der kun adskiller sig ved farve)
• Flere versioner af webstedet på samme sprog, men for forskellige regioner (f.eks. tre engelske websteder for USA, Storbritannien og Australien).

Naturligvis er hvert websted unikt, og under en teknisk revision kan du identificere andre tilfælde af duplikeret indhold, der kræver specifikke løsninger. Eksemplerne ovenfor er dog de mest almindelige. Delvise duplikater findes typisk under crawlingprocessen af forskellige crawlere. De vil have gentagne parametre og kan have samme titel og H1 som hovedkategorisiderne. For at eliminere delvise duplikater kan du ikke oprette en omdirigering, da disse sider er nødvendige for webstedets funktionalitet. Nedenfor diskuterer vi metoder til at håndtere delvise duplikater.

Sortering og filtrering af sider

Disse sider kan blokeres fra crawling i robots.txt-filen, selvom dette kan blive ignoreret af Google, især hvis links peger på disse sider. Dette vil hjælpe med at bevare crawling-budgettet. Du kan også blokere dem via direktivet <meta name=”robots” content=”noindex, nofollow” />, som forhindrer disse sider i at blive indekseret, men ikke fortæller Google, at de ikke skal crawles. Den bedste tilgang i dette tilfælde er at bruge JavaScript til at opdatere indholdet på siden, når brugeren anvender sortering eller filtre, uden at generere yderligere URL’er og links til filtrerings- eller sorteringssider.

Produktvarianter tilgængelige på forskellige URL’er

Ideelt set bør alle produktvarianter kombineres på én side, hvor brugeren kan vælge den ønskede farve eller størrelse uden at ændre URL’en ved hjælp af JavaScript. Men hvis der bruges en separat side til hver variant, skal der angives et kanonisk link til hovedproduktsiden. Men som tidligere nævnt kan Google ignorere det kanoniske link, som brugeren har angivet.

Paginering af sider

Pagineringssider bør ikke blokeres fra indeksering. For at sikre, at Google betragter den første side i kategorien som den vigtigste:

• Medtag kun den første side i sitemap.xml-filen.
• Tilføj et link til hovedkategorisiden på alle pagineringssider.
• Tilføj sidenumre til titlen og H1 på siderne. For eksempel “Hvide skjorter – side 2”.

Sider tilgængelige på ét sprog, men for forskellige regioner

I dette tilfælde skal der bruges Hreflang-attributter. De bruges til at fortælle søgemaskinerne, hvilket sprog og hvilken regional version af en webside de skal vise til brugerne baseret på deres sprogpræferencer og placering. Der er flere måder at implementere Hreflang-attributter på:

• I HTTP-overskrifter
• Via tags i <head>-sektionen
• Via tags i sitemap.xml

Den nemmeste metode at implementere er via tags i <head>-sektionen. Der er regler, som hreflang-attributter, der implementeres via tags i <head>-sektionen, skal opfylde:

• • Attributten skal have følgende format: <link rel=”alternate” hreflang=”lang_code_country_code” href=”url-of-page” />.
  • Sprog- og landekoder skal være gyldige. Se denne side for at vælge den gyldige kode for hver sprogmutation.

• Hver sprogversion skal angive sig selv og alle andre sprogversioner i sine hreflang-attributter. Det betyder, at hver side skal have det samme antal hreflang-attributter

• Links i hreflang-attributter skal være absolutte og indeksérbare.

Et eksempel på en kode: <link rel=”alternate” href=”https://example.com/en-us/page” hreflang=”en-us” /> <link rel=”alternate” href=”https://example.com/en-gb/page” hreflang=”en-gb” /> <link rel=”alternate” href=”https://example.com/en-us/page” hreflang=”x-default” />

Tjek titler, h1, h2 og beskrivelser for dubletter

Selvom titler, beskrivelser og H1-H6-overskrifter er relateret til on-page SEO, kan analysen af dem i en teknisk revision være nyttig til at opdage dubletter. For at analysere dem kan du bruge en hvilken som helst crawler, der indsamler disse tags. Når der findes dubletter af titler, H1-H6-tags og beskrivelser, skal du analysere sidedataene og identificere årsagen til duplikationen. Det kan skyldes, at webstedet er tilgængeligt via både HTTP og HTTPS, duplikering af hovedkategoritags på filtersider eller simpelthen en menneskelig fejl, hvor disse tags blev udfyldt forkert.

Optimer alt-attributter til billeder

Alt-attributter er en HTML-attribut, der bruges inde i <img>-tagget som dette: <img src=”image.jpg” alt=” Beskrivelse af billedet”>. Hovedformålet er at give en tekstbeskrivelse af billedindholdet. Denne tekst vises, hvis billedet ikke kan indlæses, og læses højt af skærmlæsere for at hjælpe synshandicappede brugere. Korrekt, beskrivende alt-tekst kan hjælpe dine billeder med at rangere i billedsøgning og forbedre sidens overordnede relevans. Hvis du har et website med meget visuelt indhold, er optimering af alt-attributter et vigtigere skridt end for klassiske websites, der er afhængige af tekstindhold. Mange crawlere som Screaming Frog, Ahrefs, SemRush osv. analyserer alt-attributter, og der kan du få data om manglende eller tomme alt-attributter. Du kan læse mere om oprettelse af beskrivende alt -attributter i officielle Google-dokumenter.

Hjemmesidehastighed, mobil og brugervenlighed

Brug HTTPs-protokollen

Det er vigtigt at bruge den sikre HTTPS-protokol for at sikre dataoverførslen mellem brugeren og serveren. Det øger ikke kun brugernes tillid, men har også en positiv indvirkning på SEO. For at tjekke HTTPS skal du blot se på browserens adresselinje – der skal vises et hængelåsikon. For en detaljeret analyse kan du bruge SSL Labs-tjenesten, som giver en fuld rapport om SSL-certifikatets status og identificerer eventuelle problemer. Det er også vigtigt at sikre, at der ikke er blandet indhold – HTTP-ressourcer på HTTPS-sider. Til denne analyse kan du bruge HTTPS-rapporten i Google Search Console, som viser URL’er med både HTTP og HTTPS.

Kilde: Vores klients Search Console

Forbedring af Core Web Vitals

Core Web Vitals er et sæt målinger foreslået af Google til at vurdere kvaliteten af brugeroplevelsen på et website. Disse målinger fokuserer på indlæsningshastighed, interaktivitet og visuel stabilitet af indholdet på siden. De omfatter tre nøgleindikatorer:

Metrik	Beskrivelse	Optimal værdi
Største indholdsrige maleri (LCP)	Måler indlæsningstiden for det største synlige element på siden (f.eks. billede eller tekst).	Mindre end 2,5 sekunder
Forsinkelse af første input (FID)	Måler den tid, det tager for siden at reagere på den første brugerinteraktion (f.eks. at klikke på en knap eller et link).	Mindre end 100 millisekunder
Kumulativ layoutforskydning (CLS)	Vurderer sidens visuelle stabilitet, dvs. hvor meget elementer bevæger sig under sideindlæsning.	Mindre end 0,1

De data, der blev indsamlet fra rigtige brugere, kan ses i Search Console-rapporten “Core web vitals” (aggregerede data) eller i PageSpeed Insights (for individuelle tests). Når du arbejder med Core Web Vitals, skal du huske, at du skal definere de problemer, der har stor indflydelse på CWV-målingerne. Når du optimerer LCP, skal du f.eks. definere, hvilke af de fire aspekter (TTFB, Load Delay, Load Time eller Render delay), der bidrager mest til den høje LCP-score. I eksemplet nedenfor er det tydeligt, at vi ikke behøver at fokusere på optimering af TTFB eller Load Time. I stedet kan vi bruge al vores energi på at forbedre Load Delay og derefter Render Delay.

Kilde: https://pagespeed.web.dev/ – test af webstedetnike.com (bare for eksemplets skyld). Domænet er sløret

Sørg for, at dit website er mobilvenligt

Mobilvenlighed er blevet en afgørende faktor siden 2018, hvor Google skiftede til en mobil-første indekseringstilgang. Det betyder, at Google nu primært bruger mobilversionen af et website til rangering og indeksering i stedet for desktopversionen. I Google Search Console kan du teste dine sider ved at klikke på “Test Live URL” i URL-inspektionsværktøjet og se, hvordan Googlebot-Mobile ser den.

Komprimer billeder

Billedoptimering med henblik på at komprimere dem uden at miste kvalitet hjælper med at fremskynde indlæsningen af hjemmesiden, især hvis der er meget grafisk indhold på siderne. Onlineværktøjer som TinyPNG eller Squoosh kan bruges til at komprimere billeder. Det er også værd at tjekke, om der bruges moderne billedformater som WebP, da de kan reducere filstørrelsen betydeligt.

Brug CDN til internationale hjemmesider

Det giver mening at bruge et CDN, hvis dit websted betjener en lang række geografisk fjerne regioner. Et CDN (Content Delivery Network) fordeler webstedets indhold på servere, der er placeret tættere på brugerne, hvilket reducerer ventetiden under indlæsningen. Du kan tjekke for CDN-brug ved at undersøge HTTP-anmodningshoveder i browserens udviklingsværktøjer (fanen Netværk), hvor der kan være henvisninger til CDN-udbyderen, såsom Cloudflare eller Akamai. Der findes også onlineværktøjer til at teste CDN. CDN-konfiguration sker typisk via hostingpanelet eller CMS. Brug caching Caching gør det muligt for browsere og proxyservere at gemme kopier af ressourcer, hvilket reducerer serverbelastningen og fremskynder indlæsningen ved efterfølgende besøg. Du kan tjekke, om cachelagringen er korrekt i browserens udviklingsværktøjer – se på overskrifterne Cache-Control, Expires og ETag i afsnittet Netværk. Google PageSpeed Insights giver også anbefalinger til caching. Det er vigtigt, at statiske ressourcer (billeder, scripts, stilarter) har korrekte caching-indstillinger, og at serveren har de tilsvarende regler konfigureret (f.eks. i .htaccess- eller nginx-konfigurationen). For at tjekke caching kan du bruge onlinetjenester som GiftOfSpeed.

Konklusion

En teknisk revision af et website er ikke en engangsprocedure, men en løbende proces, der kræver regelmæssig opmærksomhed på de tekniske faktorer, der kan påvirke dets ydeevne og synlighed. Da hvert website er unikt, vil det specifikke fokus og hyppigheden af kontroller variere. Denne tjekliste til en teknisk SEO-revision hjælper dig med at sikre, at du ikke har glemt noget vigtigt.