Hva canonical-tagger gjør når du bruker dem feil

Canonical-taggen er ikke et viskelær for duplisert innhold

En canonical-tag forteller søkemotorer hvilken URL du foretrekker når flere URL-er har samme, eller i stor grad lignende, innhold. Den vanlige HTML-versjonen ser slik ut:

<link rel="canonical" href="https://example.com/preferred-page/">

Det finnes også en HTTP-header-versjon, som er mest nyttig for filer som ikke er HTML, for eksempel PDF-er:

Link: <https://example.com/preferred-file.pdf>; rel="canonical"

Det høres enkelt nok ut. Problemet starter når team behandler canonical-tagger som en trygg måte å rydde opp i alt som er litt vanskelig: fasettert navigasjon, sporingsparametere, utskriftssider, nesten dupliserte produktsider, paginering, staging-URL-er og gamle kampanjesider.

Canonical-tagger er ikke en sletteknapp. De er ikke en omdirigering. De er ikke en erstatning for informasjonsarkitektur. Og det er ikke garantert at de blir fulgt.

Søkemotorer bruker canonical-tagger som sterke hint. De sammenligner canonical-taggen med andre signaler: omdirigeringer, interne lenker, URL-er i sitemap, hreflang-annotasjoner, innholdslikhet, HTTP-statuskoder og URL-ene brukere og crawlere faktisk møter. Hvis disse signalene er i konflikt, kan søkemotoren ignorere canonical-taggen din eller velge en helt annen canonical-URL.

Derfor kan feil canonical-tagger være så forvirrende. Markupen ser riktig ut i nettleseren, men feil side vises i søkeresultatene — eller den riktige siden forsvinner.

Hva som skjer når en canonical peker til feil URL

Når en søkemotor ser dupliserte eller nesten dupliserte URL-er, grupperer den dem vanligvis i en klynge og velger én URL som canonical. Den valgte canonical-versjonen er den som mest sannsynlig blir indeksert og vist i søkeresultatene. Signaler fra duplikatene kan bli konsolidert inn i den valgte URL-en.

Hvis canonical-taggen din peker til feil side, kan flere ting skje.

1. Feil URL blir indeksert

Tenk deg at du har to URL-er:

• /mens-running-shoes/
• /sale/mens-running-shoes/

Hvis salgssiden har canonical til hovedkategorisiden, kan det være greit hvis innholdet er nesten identisk og salgs-URL-en bare er en filtrert versjon. Men hvis salgssiden har unik tekst, unike produkter og egen søkeetterspørsel, kan canonical-taggen undertrykke den.

Siden kan fortsatt bli crawlet. Den kan fortsatt være tilgjengelig for brukere. Men søkemotorer kan velge å ikke indeksere den separat fordi du har fortalt dem at en annen URL er den foretrukne versjonen.

Dette er den vanligste canonical-feilen: ikke et dramatisk teknisk havari, bare en stille forsvinning fra indeksen.

2. Rangeringssignaler konsolideres på feil sted

Canonical-tagger brukes ofte til å konsolidere signaler som lenker og varianter av duplisert innhold. Det er nyttig når duplikatene faktisk er likeverdige. Det er risikabelt når de ikke er det.

Hvis en bloggartikkel har sporings-URL-er som:

• /guide-to-canonical-tags/?utm_source=newsletter
• /guide-to-canonical-tags/?utm_source=linkedin

Da er det fornuftig å canonicalisere begge til /guide-to-canonical-tags/.

Men hvis en spansk versjon, en utskriftsvennlig versjon med ekstra innhold eller en produktvariant med en annen intensjon peker til samme canonical, kan du slå sammen signaler som burde forbli adskilt. Resultatet kan bli svakere relevans for alle.

Canonical-tagger handler om likeverdighet. Hvis to sider dekker ulike søkeintensjoner, bør de sannsynligvis ikke canonicalisere til hverandre.

3. Søkemotorer ignorerer taggen

En canonical er ikke en kommando. Hvis canonical-målet omdirigerer, returnerer 404, er blokkert, har noindex eller inneholder svært forskjellig innhold, kan søkemotorer ignorere den.

Det er bra på én måte: en dårlig canonical ødelegger ikke alltid indeksering. Men det betyr også at du ikke kan anta at taggen gjør det du tror. En side kan deklarere én canonical mens Google velger en annen.

Dette er særlig vanlig når interne lenker, sitemaps og canonical-tagger er uenige. Hvis alle interne lenker peker til /product, sitemapet ditt lister /product/, og canonical-taggen peker til https://www.example.com/product?ref=main, har du skapt en liten krangel mellom dine egne signaler.

Søkemotorer er flinke til å løse den krangelen. De er ikke alltid flinke til å løse den slik du hadde tenkt.

4. Feilsøking blir unødvendig vanskelig

Dårlige canonical-tagger feiler sjelden høyt. De skaper symptomer som ligner andre SEO-problemer:

• “Oppdaget, for øyeblikket ikke indeksert” eller tilsvarende indekseringslimbo
• Feil URL rangerer for et søk
• Parameter-URL-er vises i rapporter
• Kategorisider vises ikke selv om de kan crawles
• Internasjonale sider foldes inn i feil språkversjon
• Nye maler lanseres med færre indekserte sider enn forventet

Derfor bør feilsøking av canonical-tagger inkludere rå HTML, rendret HTML, HTTP-headere, omdirigeringer og sitemap-oppføringer. Hvis du allerede undersøker omdirigeringskjeder eller headere som ikke samsvarer, gjelder de samme vanene; en praktisk arbeidsflyt for HTTP-inspeksjon som den i guiden vår til feilsøking av omdirigeringer og HTTP-headere i produksjon vil vanligvis fange canonical-motsigelser raskere enn å stirre på et CMS-felt.

De dyreste canonical-feilene

Å canonicalisere alt til forsiden

Dette skjer fortsatt. Et malfelt står tomt, en plugin faller tilbake til nettstedets rot, og plutselig deklarerer hundrevis av sider forsiden som canonical.

Søkemotorer kan ignorere dette fordi innholdet åpenbart er forskjellig. Men hvis nok signaler er rotete, kan noen sider bli droppet eller klynget feil. Som et minimum sender du et unyttig og motstridende hint på hver side.

Forsiden er nesten aldri canonical for en intern side.

Å canonicalisere paginerte sider til side én

I lang tid canonicaliserte noen nettsteder /category/page/2/, /page/3/ og så videre tilbake til side én. Hensikten var å unngå dupliserte kategorisider.

Problemet er at paginerte sider ikke er duplikater. De inneholder ulike elementer og hjelper crawlere med å oppdage dypere innhold. Å canonicalisere dem alle til side én kan redusere sjansen for at søkemotorer behandler de senere sidene fullt ut.

Vanligvis bør paginerte sider ha selvrefererende canonical-tagger, med mindre det finnes en konkret grunn til å konsolidere.

Å canonicalisere filtrerte sider uten å sjekke søkeintensjon

Fasettert navigasjon skaper vanskelige valg. Noen filtrerte URL-er er skrot:

• ?sort=price_ascending
• ?view=grid
• ?sessionid=123

Andre kan være verdifulle landingssider:

• /sofas/blue/
• /laptops/16gb-ram/
• /hotels/paris/pet-friendly/

Generelle canonical-regler visker ofte ut nyttige søkesider sammen med unyttig parameterstøy. Før du canonicaliserer filtrerte sider, bør du spørre om den filtrerte siden har stabilt innhold, interne lenker, søkeetterspørsel og et tydelig brukerbehov.

Hvis svaret er ja, kan den fortjene å være indekserbar med en selvrefererende canonical.

Å peke canonical-tagger mot omdirigerte eller blokkerte URL-er

Et canonical-mål bør være rent, indekserbart og returnere 200 OK. Ikke pek canonical-tagger mot URL-er som omdirigerer, returnerer feil, krever cookies, er blokkert av robots.txt eller har noindex.

Dette er en av de enkleste kontrollene å automatisere. Crawl nettstedet ditt og flagg canonical-mål som ikke returnerer en ren 200-respons.

Å blande canonical med noindex som om de betyr det samme

rel="canonical" og noindex løser ulike problemer.

Bruk canonical når det finnes duplikater og du vil konsolidere signaler til en foretrukket URL. Bruk noindex når du ikke vil at en side skal indekseres i det hele tatt.

Å bruke begge samtidig sender et klønete budskap: “Ikke indekser denne siden, men bruk den også som et duplikatsignal for en annen side.” Søkemotorer kan ofte håndtere dette, men det er ikke en ryddig instruks. Hvis en side er et duplikat, canonicaliser den. Hvis den ikke skal vises i søk og ikke har en nyttig duplikatrelasjon, bør du vurdere noindex.

En praktisk canonical-revisjon

Du trenger ikke en stor SEO-plattform for å finne mange canonical-problemer. Start med en crawl, noen URL-eksempler og et regneark.

For hver viktige mal, sjekk:

1. Har siden nøyaktig én canonical-tag? Flere canonical-tagger skaper tvetydighet.
2. Er canonical-taggen absolutt? Bruk full URL, inkludert protokoll og vertsnavn.
3. Returnerer canonical-målet 200 OK? Unngå mål som omdirigerer, er blokkert eller returnerer feil.
4. Er canonical-målet indekserbart? Ingen noindex, ingen robots-blokkering, ingen krav om autentisering.
5. Er innholdet faktisk likeverdig? Lignende er ikke alltid likeverdig.
6. Er interne lenker enige? Lenke til canonical-URL-formatet der det er mulig.
7. Er sitemapet enig? Sitemaps bør som regel liste canonical-URL-er som kan indekseres.
8. Er hreflang-tagger enige? Internasjonale sider trenger konsistente canonical- og hreflang-relasjoner.
9. Samsvarer rendret HTML med rå HTML? JavaScript kan endre eller injisere tagger.
10. Hvilken canonical valgte søkemotoren? Inspeksjonsverktøy kan vise når den deklarerte canonical-taggen din avviker fra den valgte canonical-versjonen.

Dette er også et sted der Lighthouse kan være nyttig, men bare innenfor sine begrensninger. Det kan flagge enkelte problemer med crawlbarhet og dokumenter, men det forstår ikke den kommersielle intensjonen din eller canonical-strategien din. Behandle det som ett innspill, ikke en dom. Hvis du trenger en roligere måte å skille nyttige funn fra støy på, kan du se hvordan du leser en Lighthouse-rapport uten å få panikk.

Selvrefererende canonical-tagger er vanligvis et godt standardvalg

Alle viktige indekserbare sider bør vanligvis deklarere seg selv som canonical. Det er ikke fordi søkemotorer ikke kan finne ut av det uten taggen. Det er fordi selvrefererende canonical-tagger reduserer tvetydighet når parametere, sporingslenker, kopierte URL-er og CMS-særegenheter skaper alternative veier til samme innhold.

For en ren produktside er dette vanligvis riktig:

<link rel="canonical" href="https://example.com/products/linen-shirt/">

For en sporings-URL bør canonical-taggen vanligvis peke tilbake til den rene versjonen:

<link rel="canonical" href="https://example.com/products/linen-shirt/">

For en genuint forskjellig produktvariant kommer svaret an på situasjonen. Hvis den røde skjorten, blå skjorten og svarte skjorten har samme beskrivelse og bare fargen endrer seg, kan én canonical-produktside være nok. Hvis hver variant har egen etterspørsel, anmeldelser, bilder, lagerstatus og interne lenker, kan separate indekserbare sider være fornuftig.

Det finnes ingen universell canonical-regel for varianter. Det finnes bare spørsmålet: er disse sidene utskiftbare for en søker?

Canonical-tagger bør samsvare med nettstedets faktiske URL-policy

De fleste canonical-feil er symptomer på et dypere URL-policyproblem. Nettstedet har ikke bestemt om avsluttende skråstreker betyr noe, om URL-er med store bokstaver skal fungere, om parametere er tillatt, om HTTP omdirigerer til HTTPS, eller om www er canonical.

Velg én ren versjon av hver URL og få hele systemet til å være enig:

• Omdiriger ikke-foretrukne URL-versjoner til foretrukne versjoner.
• Lenke internt til foretrukne versjoner.
• Legg foretrukne versjoner i XML-sitemaps.
• Bruk selvrefererende canonical-tagger på foretrukne sider.
• Canonicaliser bare ekte duplikater til den foretrukne URL-en.

Når alle disse signalene peker i samme retning, blir canonical-tagger kjedelige. Det er målet.

Kort oppsummert

Canonical-tagger er kraftige fordi de påvirker indeksering og signalkonsolidering. De er farlige av samme grunn.

En feil canonical vil ikke alltid fjerne en side fra søk. Søkemotorer kan ignorere den. Men å stole på at søkemotorer skal redde dårlige signaler, er ingen strategi. Den tryggere tilnærmingen er å reservere canonicalisering for ekte duplikater, holde mål rene og indekserbare, og få interne lenker, omdirigeringer, sitemaps og canonical-tagger til å fortelle den samme historien.

Canonical-tagger er ikke stedet der du skjuler rotete arkitektur. De er stedet der du bekrefter at den er ryddet opp.