Site health, redirects & canonicals

SEO består af tre fundamentale søjler: teknisk SEO, content og linkbuilding. Denne guide handler om den tekniske del og om de opgaver, der holder et site sundt over tid: at måle det tekniske helbred, at sende brugere og søgemaskiner det rigtige sted hen, når URL'er ændrer sig, at fortælle Google, hvilken version af en side der tæller, og at sikre forbindelsen med HTTPS.

→ Download gratis template til on-page optimering

Teknisk SEO bliver ofte beskrevet som et sæt retningslinjer, man som udvikler skal følge, når man bygger eller driver et website. Det er her, teknologi og SEO mødes. Overblikket over hele disciplinen finder I i guiden til teknisk SEO.

Hvad er en health score?

Man kan ikke forbedre det, man ikke kan måle. Det gælder også sitets tekniske helbred.

SEO-værktøjer som Ahrefs har udviklet crawlere, der gennemgår jeres site på samme måde som en søgemaskine og registrerer fejl undervejs. Crawleren læser og analyserer kildekoden på hver side, og resultatet samles i en health score, der giver et overblik over de elementer, der kan og bør forbedres. Værktøjerne viser også data fra Google Search Console, fx Core Web Vitals.

Hvorfor health scoren er nyttig

Health scoren er en indikation på, om sitet er bygget og vedligeholdt ordentligt. En høj score betyder, at crawleren har fundet få fejl. En lav score betyder, at der er plads til forbedring.

Det giver mening at kigge på det tekniske helbred, før man går i gang med andet SEO-arbejde. Alvorlige tekniske fejl, fx sider der ikke kan crawles eller indekseres, kan bremse effekten af både fremragende content og linkbuilding.

Husk dog, at health scoren er værktøjets egen måling og ikke noget, Google bruger til at rangere sider. En lav score betyder ikke automatisk dårlige placeringer, og en høj score garanterer dem ikke. Brug den til at finde og prioritere de fejl, der betyder noget.

Hvordan bliver health scoren beregnet?

Hos Ahrefs er beregningen enkel:

Health score = (interne URL'er uden fejl / alle crawlede interne URL'er) × 100

Scoren viser altså procentdelen af sitets interne URL'er, der ikke har fejl. Kun problemer i kategorien "Error" trækker ned. Advarsler og noter påvirker ikke scoren.

Eksempel

Et website har 2.000 interne URL'er, og 500 af dem har fejl. Så er health scoren:

(1.500 / 2.000) × 100 = 75

Arbejdet handler derfor om at reducere antallet af URL'er med fejl. De hyppigste er 4xx-fejl, billedfejl, manglende metadata, JavaScript-fejl og manglende eller modstridende HTML-attributter.

4xx-fejl opstår, når en forespørgsel på en ressource mislykkes, fx et link til et billede eller en side, der er fjernet.

Billedfejl opstår, når et billede har en for stor filstørrelse, et uhensigtsmæssigt format eller ikke kan hentes fra serveren.

Metadatafejl opstår, når crawleren finder en side, hvor metadata mangler eller er implementeret forkert. Til overblikket over sidetitler og metabeskrivelser har vi lavet en gratis tjekliste:

→ Download gratis template til tjek af metatags

JavaScript-fejl er typisk filer, der ikke kan hentes, eller scripts med fejl, som browseren ikke kan køre.

HTML-attributter, der oftest mangler eller modsiger hinanden, er canonical og hreflang. Dem gennemgår vi længere nede.

Fem måder at løfte health scoren

1. Hold billederne små

Billeder med for stor filstørrelse loader langsomt og gør hele siden langsommere. Gem billederne i et komprimeret format som WebP, AVIF eller JPG, og sørg for, at deres mål passer til den plads, de vises i. Skal produktbilledet vises i 200 × 200 pixels, er der ingen grund til at uploade det i 3.000 × 3.000.

Mange CMS'er kan komprimere billeder automatisk via et plugin, på WordPress fx Shortpixel. Et CDN kan desuden levere billederne fra servere tæt på brugeren, så en dansk besøgende ikke skal vente på en server i USA.

2. Ryd op i kildekoden

En hyppig fejl er rester i kildekoden fra funktioner, billeder eller scripts, der er fjernet. Et link til et slettet billede eller en ubrugt JavaScript-fil, som stadig kaldes, bliver registreret som en fejl. Gennemgå derfor jævnligt, om kun det, der skal være på siden, også er der.

3. Giv alle sider en sidetitel og metabeskrivelse

Sidetitler og metabeskrivelser ses ikke på selve siden, men de vises typisk som titel og beskrivelse i søgeresultaterne, og crawlere bruger dem til at forstå, hvad siden handler om. Alle CMS'er har felter til dem. Hvordan I skriver dem, gennemgår vi i guiden til sidetitler og meta descriptions.

4. Få canonicals og hreflang til at stemme overens

Canonical fortæller søgemaskinerne, hvilken version af en side der er den foretrukne, når der findes flere med samme eller næsten samme indhold. Hreflang fortæller, hvilke sprog- og landeversioner der hører sammen. En typisk fejl er, at de to, sitemappet og de interne links peger i hver sin retning. Det gennemgår vi i afsnittet om canonicals nedenfor og i guiden til international SEO.

5. Gør vedligeholdelsen til en rutine

Et sundt site skyldes sjældent én stor oprydning. Nye sider, skabeloner, plugins og integrationer introducerer løbende nye fejl, så det, der holder health scoren oppe, er faste rutiner: et månedligt crawl, en gennemgang af Search Consoles rapporter og en udvikler, der tænker SEO ind, når der bygges nyt. Har I brug for hjælp udefra, kan en SEO-konsulent eller en teknisk SEO-audit give overblikket.

Redirects

En redirect sender brugere og crawlere videre fra en URL til en anden. Redirects er nødvendige, når sider flytter, slås sammen eller nedlægges, men de er også en af de hyppigste kilder til tekniske fejl.

301, 308, 302 og 307

Statuskoden fortæller Google, om flytningen er permanent eller midlertidig, og det har betydning for, hvilken URL der ender i indekset (Google: Redirects and Google Search).

Forskellen mellem 301 og 308 (og mellem 302 og 307) handler om, hvorvidt browseren må skifte fra fx en POST- til en GET-forespørgsel. For almindelige sider er det uden betydning for SEO. Det, der tæller, er, om flytningen er permanent eller midlertidig. Brug 301 eller 308, når en side er flyttet for altid, og 302 eller 307 kun, når den originale URL skal tilbage, fx under en kortvarig kampagne eller vedligeholdelse. Forskellen er også forklaret i ordbogen under redirect: 301 eller 302.

Server-side redirects er det sikreste valg. En meta refresh uden forsinkelse opfatter Google som permanent, mens JavaScript-redirects først virker, hvis Google når at rendere siden. Brug dem kun, når serveren ikke kan klare opgaven.

Kæder og loops

En redirect-kæde opstår, når A peger på B, der peger på C. Det sker typisk, når et site har været igennem flere omlægninger, og de gamle redirects aldrig er blevet opdateret. Googles crawlere følger op til 10 hop, men hvert hop koster svartid og crawl-ressourcer, og andre crawlere kan have lavere grænser (Google: HTTP status codes and network errors). Peg derfor altid direkte på den endelige URL, og opdatér de interne links, så de ikke går gennem en redirect.

Et redirect-loop opstår, når to URL'er peger på hinanden, eller når en kæde ender, hvor den startede. Browseren viser en fejl, og siden kan hverken besøges eller crawles. Loops opstår ofte, når regler for HTTPS, www og afsluttende skråstreg modarbejder hinanden.

Døde sider og soft 404

En side, der er væk for altid, skal returnere 404 (Not Found) eller 410 (Gone). Google behandler de to ens i praksis. Har siden en naturlig afløser, er en 301 til den bedre, fordi brugere og eventuelle backlinks så følger med. Mere om det under 404-side.

En soft 404 er en side, der svarer med statuskode 200, men hvis indhold er tomt eller ligner en fejlside. Google registrerer dem som soft 404 i Search Console og behandler dem som fejl. Den klassiske kilde er en migrering, hvor hundredvis af gamle URL'er sendes til forsiden. Google ser den slags redirects som soft 404'er, fordi forsiden ikke erstatter det indhold, brugeren ledte efter.

Redirects ved migrering

Ved en domæneflytning, et platformskifte eller en ny URL-struktur er det redirect-planen, der afgør, om synligheden følger med. Google anbefaler følgende fremgangsmåde (Google: Site moves with URL changes):

1. Lav en komplet liste over gamle URL'er. Hent dem fra crawl, sitemaps, Search Console, analytics og backlinkværktøjer, så sider med links og trafik ikke bliver glemt.
2. Map hver gammel URL til den mest relevante nye. Én til én, hvor det er muligt. Sider uden afløser får 404 eller 410, ikke en redirect til forsiden.
3. Brug permanente server-side redirects (301 eller 308) direkte til den endelige URL.
4. Opdatér alt, der peger på de gamle adresser: interne links, canonicals, hreflang og sitemaps.
5. Bevar redirects så længe som muligt, som udgangspunkt mindst et år.
6. Brug værktøjet til adresseændring i Search Console, hvis I flytter fra ét domæne eller subdomæne til et andet.

Regn med udsving. Google skriver, at det for mellemstore websites kan tage nogle uger eller mere, før de nye URL'er gradvist erstatter de gamle i søgeresultaterne. Vores arbejde med flytninger er beskrevet under site-migrering.

Canonicals

Mange sites har det samme indhold på flere URL'er: med og uden www, med og uden afsluttende skråstreg, med tracking-parametre, som printversion eller som det samme produkt i flere kategorier. Google samler dubletterne i en gruppe og vælger én URL som kanonisk. Det er den, der bliver vist i søgeresultaterne, og som samler signalerne fra de andre. Canonical-tagget er jeres måde at fortælle Google, hvilken URL I foretrækker. Problemet med dubletter er beskrevet under duplicate content.

Et hint, ikke en ordre

<link rel="canonical" href="https://www.example.dk/produkt/"> i sidens <head> er et stærkt signal, men Google kan vælge en anden URL, hvis andre signaler peger i en anden retning. Google rangerer selv metoderne efter styrke (Google: Consolidate duplicate URLs):

1. Redirects er det stærkeste signal.
2. rel="canonical" er et stærkt signal.
3. Optagelse i sitemappet er et svagt signal.

Jo flere signaler der peger på den samme URL, jo større er chancen for, at Google vælger den. Om Google har fulgt jeres valg, kan I se i URL-inspektionen i Search Console, der viser både den brugervalgte og den Google-valgte kanoniske URL.

Selvrefererende canonical

Google anbefaler, at den kanoniske side har et canonical-tag, der peger på sig selv. Det beskytter mod varianter, I ikke selv har skabt, fx URL'er med tracking-parametre eller store og små bogstaver. Brug altid absolutte URL'er, og kun ét canonical-tag pr. side. Står der to forskellige, kan Google ignorere dem begge.

Canonical på tværs af domæner

Et canonical-tag kan pege på et andet domæne. Det er nyttigt, når den samme tekst ligger på flere af jeres egne domæner, fx en produktbeskrivelse, der deles mellem to webshops på samme sprog. Så samler signalerne sig på den version, I vælger. Til indhold, der genudgives af medier og partnere, anbefaler Google derimod ikke canonical, fordi partnerens side som regel ser for anderledes ud. Her er den mest effektive løsning, at partneren sætter noindex på sin kopi (Google: Consolidate duplicate URLs).

Når signalerne modsiger hinanden

De fleste canonical-problemer, vi finder, skyldes ikke manglende tags, men tags, der modsiger andre signaler:

• Canonical og redirects. Et canonical-tag, der peger på en URL, som selv redirecter, sender Google i ring. Pegeretningen skal ende på en URL, der svarer 200.
• Canonical og sitemap. Sitemappet skal kun indeholde kanoniske URL'er. Står en URL i sitemappet, men peger dens canonical et andet sted hen, får Google to modsatrettede beskeder.
• Canonical og hreflang. Hver sprogversion skal have en canonical, der peger på sig selv, og hreflang skal pege på de andre versioners kanoniske URL'er. Peger den svenske side sin canonical mod den danske, beder I i praksis Google om at droppe den svenske. Se guiden til international SEO.
• Canonical og noindex. Google fraråder at bruge noindex til at vælge den kanoniske side inden for samme site. En side, der både siger "jeg er en kopi af X" og "indeksér mig ikke", giver et uklart signal.
• Canonical og interne links. Linker I internt til varianter i stedet for den kanoniske URL, trækker I signalerne i den forkerte retning.

Parametre og facetter

URL-parametre er den største kilde til dubletter på webshops: sortering, filtre, sessions-id'er og tracking. Search Consoles gamle værktøj til URL-parametre blev lukket i 2022, så styringen ligger hos jer. Tre greb dækker de fleste behov:

• Canonical til den rene URL for varianter, der ikke ændrer indholdet væsentligt, fx sortering og tracking-parametre.
• Robots.txt for parameterkombinationer, I ikke vil have crawlet overhovedet. Husk, at Google ikke kan se canonical-tagget på en side, der er blokeret i robots.txt.
• Selvstændige, indekserbare sider for de filterkombinationer, der har reel søgeefterspørgsel, fx "vinterjakker til børn". Dem bør I give en fast URL, en egen titel og plads i den interne linkstruktur. Hvordan I planlægger dem, gennemgår vi i guiden til navigation og arkitektur.

HTTPS

HTTPS krypterer forbindelsen mellem brugerens browser og serveren, så tredjeparter hverken kan læse eller ændre de data, der sendes, fx loginoplysninger, formularer og betalinger. Krypteringen bygger på et SSL/TLS-certifikat. Hvordan certifikatet fungerer, og hvordan I får et, gennemgår vi i guiden Hvad er et SSL-certifikat?, og forskellen på protokollerne er forklaret under HTTP og HTTPS.

Hvad HTTPS betyder for SEO og brugerne

HTTPS har været et let rankingsignal hos Google siden 2014, og Google foretrækker HTTPS-versionen som kanonisk, når både en HTTP- og en HTTPS-version findes. Den større effekt ligger hos brugerne. Siden juli 2018 har Chrome markeret sider uden HTTPS som "Ikke sikker", og med Chrome 154 i oktober 2026 slår Google indstillingen "Brug altid sikre forbindelser" til som standard. Chrome forsøger så altid HTTPS først og advarer brugeren, før en offentlig side åbnes over HTTP (Google Security Blog). Et site uden HTTPS møder altså mange besøgende med en advarsel, før de overhovedet ser indholdet.

Det gælder alle sites, ikke kun webshops og sider med login. Også et site, hvor brugerne kun læser, sender cookies og andre data frem og tilbage.

Fra HTTP til HTTPS

Skiftet til HTTPS er en migrering i mindre format, og de samme regler gælder:

• 301-redirect hver HTTP-URL direkte til den tilsvarende HTTPS-URL, ikke til forsiden.
• Opdatér interne links, canonicals, hreflang og sitemaps til HTTPS-adresserne.
• Tjek, at robots.txt findes på HTTPS-versionen, og opret en domæneejendom i Search Console, så I ser begge protokoller samlet.
• Saml www og uden www i samme omgang, så I ikke ender med en kæde fra http://example.dk over https://example.dk til https://www.example.dk.

HSTS

HTTP Strict Transport Security (HSTS) er en header, der fortæller browseren, at domænet kun må tilgås via HTTPS. Når browseren har set headeren, skifter den selv alle fremtidige HTTP-forespørgsler til HTTPS uden at gå forbi en redirect, og brugeren kan ikke klikke sig forbi certifikatfejl (MDN: Strict-Transport-Security).

Strict-Transport-Security: max-age=31536000; includeSubDomains

max-age angiver i sekunder, hvor længe browseren skal huske reglen, her et år. includeSubDomains udvider reglen til alle subdomæner. Headeren virker først efter det første besøg over HTTPS. Vil I også beskytte det allerførste besøg, kan domænet optages på browsernes HSTS-preload-liste, som kræver max-age på mindst et år, includeSubDomains og preload.

Start med en kort max-age, og gå først op, når I er sikre på, at alle subdomæner kører HTTPS. Et glemt subdomæne uden certifikat bliver utilgængeligt, så længe browserne husker reglen, og en preload-optagelse er langsom at fortryde.

Mixed content

Mixed content opstår, når en side, der er hentet over HTTPS, indlæser ressourcer over HTTP. Moderne browsere opgraderer automatisk billeder, lyd og video til HTTPS og blokerer resten, fx scripts, stylesheets, iframes og skrifttyper (MDN: Mixed content). Siden kan altså se fin ud i adresselinjen og alligevel mangle funktioner, fordi et script fra en hårdkodet HTTP-adresse er blevet blokeret.

Mixed content stammer typisk fra ældre indhold i CMS'et, hvor billeder og indlejringer er indsat med fulde http://-adresser, eller fra tredjepartsscripts. Find dem med et site audit eller browserens udviklerværktøjer, og ret adresserne i kilden. Headeren Content-Security-Policy: upgrade-insecure-requests kan opgradere de resterende forespørgsler som sikkerhedsnet, men den erstatter ikke oprydningen.

Sådan holder I sitet sundt

Site health er vedligeholdelse frem for et projekt med en slutdato. Et fornuftigt minimum er et månedligt crawl med et audit-værktøj, en ugentlig kigger på rapporterne over sideindeksering og crawlstatistik i Search Console og en fast regel om, at enhver ændring af URL'er får en redirect-plan, før den går live. Hvordan crawling og indeksering hænger sammen med det, gennemgår vi i guiden til crawling, indeksering og bot-styring.

Vil I have et overblik over, hvor jeres site står i dag, kan I bestille en gratis SEO-analyse. Står I foran en flytning, er site-migrering det rette sted at starte, og til en grundig teknisk gennemgang har vi en teknisk SEO-audit.

Ofte stillede spørgsmål om site health, redirects og canonicals