Canonical tag – hvordan rel=canonical signaliserer foretrukket URL, og hvorfor implementeringen ofte blir feil

Definisjon

En canonical tag er en HTML-linje i <head> som forteller søkemotorer hvilken URL som er den foretrukne versjonen av en side når det finnes flere URL-er med lignende eller identisk innhold.

Canonical tag ble innført av Google, Microsoft og Yahoo i 2009 som en måte å håndtere duplisert innhold på uten å blokkere eller omdirigere, noe Google kunngjorde i blogginnlegget Specify your canonical. Det er en undervurdert del av teknisk SEO, som i tillegg ofte implementeres feil.

Å lykkes med canonical-tagger handler mindre om å forstå syntaksen, som er triviell, og mer om å forstå hvorfor de blir feil.

Slik ser canonical-taggen ut

Canonical-taggen plasseres i <head> på siden og peker mot den foretrukne URL-en:

<link rel="canonical" href="https://www.eksempel.no/produkt/sko" />

URL-en skal være absolutt (inkludere protokoll og domene), peke mot en faktisk indekserbar side og svare med statuskode 200. Den kan peke mot seg selv (selvrefererende canonical) eller mot en annen URL.

Det finnes også et alternativ i HTTP-headeren for ressurser som ikke er HTML (PDF-er, bilder):

Link: <https://www.eksempel.no/whitepaper.pdf>; rel="canonical"

Begge er likeverdige sett fra søkemotorenes side.

Hva canonical egentlig sier

Det er viktig å forstå at canonical er et hint, ikke et direktiv – noe Google selv understreker i dokumentasjonen om kanonisering. Søkemotorer bruker den som et sterkt signal om hvilken URL som skal regnes som originalen, men de forbeholder seg retten til å ignorere den hvis andre signaler taler imot. De andre signalene omfatter:

• Internlenking (hvilken URL lenkes mest internt?)
• Innkommende eksterne lenker (hvilken URL får backlinks?)
• Sitemap.xml (hvilken URL står oppført der?)
• Hreflang (om språk- eller regionvarianter peker mot en annen URL)
• Faktisk innhold (er sidene virkelig like?)

Sier canonical-taggen din A, men alt annet peker mot B, vil Google sannsynligvis indeksere B. Det er ikke Googles feil – det er canonical-taggen som ikke var troverdig.

Når trengs en canonical tag?

Canonical-taggen løser et bestemt problem: når det samme eller svært likt innhold er tilgjengelig via flere URL-er. Vanlige scenarioer:

• Parametere i URL-en. /sko og /sko?utm_source=newsletter er samme side for en bruker, men to ulike URL-er for en søkemotor. Canonical peker tilbake til /sko.
• Filter og sortering. /sko?farge=svart og /sko?sortering=pris er ofte varianter av en kategoriside. Enten indekserer man dem (hvis de har eget potensial for søketrafikk), eller så kanoniserer man tilbake til den ufiltrerte.
• Sporingsparametere. Alt som begynner med utm_, fbclid, gclid. Disse skal kanoniseres bort.
• HTTP/HTTPS og www/non-www. Helst løses det med en 301-omdirigering, men canonical kan supplere hvis omdirigeringen av en eller annen grunn ikke lar seg gjøre.
• Duplikater på tvers av domener. Publiseres den samme artikkelen både hos deg og hos en partner, kan partneren sette canonical mot originalsiden din.
• Utskriftsversjoner og AMP. Den enklere eller spesialiserte versjonen peker mot hovedversjonen.

Vanlige feil – og konsekvensene

Det er her de fleste prosjektene feiler, også hos byråer som burde vite bedre.

• Canonical peker mot en omdirigering. Canonical → 301 → sluttdestinasjon. Søkemotorene følger kjeden, men signalet svekkes, og det kan ta lengre tid før riktig URL indekseres.
• Canonical peker mot en 404- eller noindex-side. Da er canonical-taggen inkonsekvent – siden sier «originalen finnes der», og Google går dit og oppdager at originalen ikke kan indekseres.
• Alle sider peker mot forsiden. Klassisk feilimplementering fra CMS-maler. Resultat: hele nettstedet konsolideres mot én enkelt URL, og nesten alt innhold faller ut av indeksen. Dette skjer oftere enn man tror.
• Canonical i kombinasjon med noindex. Forvirrer søkemotorene. Enten vil du at siden skal indekseres (send da en tydelig canonical), eller ikke (send da noindex uten canonical eller med selvrefererende canonical).
• Canonical på tvers av domener i feil retning. Du publiserer artikkelen på ditt eget nettsted først. Deretter publiserer en partner den samme artikkelen – og du setter canonical mot partneren. Effekt: partneren får rangeringssignalene.
• Ulik canonical i <head> og i HTTP-headeren. Peker de på ulike URL-er, vil Google velge én – hvilken er udefinert.
• Flere canonical-tagger på samme side. Har en side mer enn én rel="canonical" i <head>, ignorerer Google alle sammen. Det skjer lett når et tema setter én tagg og en plugin, en embed eller en CMS-mal setter en til.
• Canonical settes via JavaScript. Google gjengir JavaScript, men det kan ta lengre tid. Statisk canonical i HTML er mer pålitelig.

Feil canonical-oppsett er en av de vanligste tekniske årsakene til at et nettsted ikke vises i søk – vi går gjennom flere i Synlighet på nett: de 10 vanligste årsakene til at nettsiden ikke rangerer.

Canonical vs. 301-omdirigering – hva bør du velge?

Skal en URL aldri besøkes av brukere igjen (gammel, omdøpt, flyttet), bruk 301. Det er et sterkere signal og fjerner muligheten for at feil URL fortsetter å rangere.

Skal begge URL-ene bli stående for brukerne (filter, parametere, alternative visninger), men bare én skal indekseres, bruk canonical.

I praksis kombineres de ofte: 301 for reell flytting, canonical for parametervarianter og alternative visninger.

Canonical og paginerte serier

Tidligere anbefalte Google rel="next" og rel="prev" for paginerte lister – en støtte Google i 2019 bekreftet at de ikke lenger bruker. I dag anbefales det å enten:

• La hver paginerte side ha en selvrefererende canonical og være indekserbar for dyp SEO.
• Eller, hvis bare den første siden skal rangere, sette noindex (men ikke nofollow) på side 2 og videre.

Å kanonisere alle paginerte sider mot side 1 er en gammel anbefaling som i dag regnes som feil – innholdet på siden er unikt (andre produkter), så canonical mot side 1 er inkonsekvent.

Canonical i Webflow

I Webflow kan du skrive inn hvilket domene Webflow skal bruke for automatisk å gi en selvrefererende canonical på hver side – hver side peker altså på seg selv som original hvis ikke noe annet er angitt. Det holder for de fleste nettsteder og forhindrer de vanligste problemene med duplisert innhold uten konfigurasjon. Dette fungerer også for sider på flere språk, akkurat som den automatiske funksjonen for hreflang.

Når du trenger å peke en side mot en annen URL, kan du angi en egendefinert canonical per side under Page Settings, og per CMS-objekt i innstillingene for collectionen. Det er der du løser parametervarianter, canonicals på tvers av domener og alternative visninger. Fordi Webflow legger taggen statisk i HTML-en, slipper du forsinkelsen som canonicals satt med JavaScript kan gi.

Slik finner du canonical-problemer på nettstedet ditt

I praksis: bruk et crawleverktøy (Screaming Frog, Sitebulb, Ahrefs Site Audit) og se etter:

• Sider uten canonical i det hele tatt
• Sider der canonical peker mot en annen URL enn siden selv (sjekk at det er bevisst)
• Canonical som peker mot statuskoder som ikke er 200
• Canonical som peker mot URL-er som ikke finnes i sitemap.xml
• Canonical-kjeder (canonical → 301 → …)
• Canonical-konflikter (HTML sier A, HTTP-headeren sier B)

Search Console rapporterer også «Alternate page with proper canonical tag» og «Duplicate, Google chose different canonical than user». Den siste er et varselsignal – Google stoler ikke på canonical-taggen din.

Oppsummering

En canonical tag er et hint til søkemotorer om hvilken URL som er den foretrukne versjonen av en side. Den er sentral for å håndtere duplisert innhold og URL-parametere uten å blokkere eller omdirigere. Den er også den tekniske SEO-detaljen der vi oftest ser at feil slipper ut i produksjon. Sørg for at alle canonicals peker mot en indekserbar 200-URL, er konsekvente mellom HTML og HTTP-header, og ikke motsier andre signaler som internlenking og sitemap.