Kort fortalt: rel="canonical" i HTML (eller HTTP-header) peger på den primære version af en side. Det mindsker risiko for at søgemaskinen splitter signaler mellem næsten identiske URL’er og hjælper med at samle relevans ét sted.
Hvornår er canonical relevant?
- Samme artikel på
httpoghttps- brug også 301; canonical alene er ikke nok til at erstatte sikker redirect-strategi. - Paginering, filtre og
?utm_*der genererer mange URL’er med samme kernindhold. - Syndikeret eller genpubliceret indhold hvor I vil pege på originalen.
- Print- eller PDF-versioner online som duplikerer HTML - canonical til hovedartiklen.
Canonical vs noindex vs robots
noindexsiger “indekser ikke denne side”.rel=canonicalsiger “denne side ligner en anden - behandl den som kopi af originalen”.
Brug ikke de to modstridende uden klar intention (fx noindex på en side der også canonical’er et andet sted - kan skabe forvirring; få professionel gennemgang af strategien).
robots.txt blokerer crawl af visse paths - det er igen noget andet; se crawl budget.
Performance-vinkel
Canonical løser ikke TTFB eller LCP. Det reducerer til gengæld spild af crawl på meningsløse duplikater og gør det lettere for Google at prioritere de rigtige URL’er - hvilket indirekte hjælper jeres SEO-arbejde med at lande det rigtige sted.
Typiske fejl
- Canonical til 404 eller en redirect-kæde med flere hop.
- Alle undersider peger på forsiden “for en sikkerheds skyld” - det skader næsten altid forståelsen af individuelle sider.
- Uens canonical mellem sitemap, HTML og header - hold én sandhed pr. URL.
Flersprogede sites
Kombinér canonical med hreflang hvor sproglige varianter findes - de løser forskellige problemer (primær URL vs. sprogligt alternativ).
Relaterede begreber
FAQ
Skal jeg have self-referencing canonical?
Ofte ja på den endelige indekserbare URL. Det gør signalet klart når andre deler URL’er med sporingsparametre eller når Google ser flere varianter.
Kan canonical erstattes kun med sitemap?
Nej - brug link-element eller HTTP-header på siden. Sitemap er supplement og hjælper med opdagelse, men erstatter ikke et tydeligt canonical-signal på dokumentet.
Hvad hvis canonical peger på en 404?
Det er en alvorlig fejl - Google kan ignorere signalet eller splitte signaler. Audit med crawls og Search Console efter deploy.
Må jeg kryds-domæne canonical?
Kun når det er bevidst og tilladt - fx syndikering med aftale. Ellers risikerer I at sende væk autoritet eller skabe forvirring.
Næste skridt fra begreb til handling
Guides og blogindlæg der matcher begrebets emne - ud fra fælles tags og sidens fokus.
Brug Transfer-Encoding (chunked) til progressiv rendering: hurtigere første visning
Lær at finde ud af om din server eller reverse proxy buffer HTML-svar, og få streaming (chunked) til at flytte første visning og LCP i den rigtige retning.
Gør hero til LCP: sådan ændrer du struktur, CSS og prioritering
Hvis LCP bliver en tilfældig paragraf i stedet for hero, får du både dårligere tal og en måling der ikke matcher brugerens første indtryk. Her er en konkret metode til at få hero (H1/billede) til at blive LCP – uden at snyde.
Få edge cache-hit på HTML: undgå cookies, forkert Vary og dårlige cache keys
Mange sites har CDN, men får stadig høj TTFB fordi HTML ikke caches. Lær et praktisk workflow til at få cache-hit på offentlige sider uden at servere forkert indhold.
Vary-header og caching: undgå forkert indhold og lav cache-hit-rate
Vary bestemmer hvornår caches skal gemme flere varianter af samme URL (fx gzip vs brotli eller dansk vs engelsk). Lær de typiske fejl, og hvordan du tester med headers og curl.
Sådan prioriterer du hastighedsoptimering uden at spilde tid
Lær hvordan du prioriterer hastighedsoptimering rigtigt, så du starter med de ændringer der giver mest effekt på LCP, INP, CLS og TTFB.
Hvad er Core Web Vitals? LCP, INP og CLS forklaret enkelt
Få en praktisk forklaring på LCP, INP og CLS. Lær hvad Core Web Vitals måler, hvorfor de betyder noget, og hvordan du kommer i gang.
