Hvad canonical-tags gør, når du bruger dem forkert

Canonical-tagget er ikke et viskelæder til duplicate content

Et canonical-tag fortæller søgemaskiner, hvilken URL du foretrækker, når flere URL'er indeholder det samme eller væsentligt lignende indhold. Den almindelige HTML-version ser sådan ud:

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

Der findes også en HTTP-header-version, som især er nyttig til ikke-HTML-filer som PDF'er:

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

Det lyder enkelt nok. Problemerne begynder, når teams behandler canonical-tags som en sikker måde at rydde op i alt det besværlige på: facetteret navigation, tracking-parametre, print-sider, næsten ens produktsider, paginering, staging-URL'er og gamle kampagnesider.

Canonical-tags er ikke en slet-knap. De er ikke en redirect. De er ikke en erstatning for informationsarkitektur. Og der er ingen garanti for, at de bliver fulgt.

Søgemaskiner bruger canonicals som stærke hints. De sammenligner canonical-tagget med andre signaler: redirects, interne links, sitemap-URL'er, hreflang-annoteringer, indholdslighed, HTTP-statuskoder og de URL'er, som brugere og crawlere faktisk møder. Hvis disse signaler er i konflikt, kan søgemaskinen ignorere din canonical eller vælge en helt anden canonical-URL.

Derfor kan forkerte canonicals være så forvirrende. Markuppen ser korrekt ud i browseren, men den forkerte side vises i søgeresultaterne — eller den rigtige side forsvinder.

Hvad der sker, når en canonical peger på den forkerte URL

Når en søgemaskine ser duplikerede eller næsten duplikerede URL'er, grupperer den dem typisk i en klynge og vælger én URL som canonical. Den valgte canonical er den version, der mest sandsynligt bliver indekseret og vist i søgeresultaterne. Signaler fra dubletterne kan blive konsolideret i den valgte URL.

Hvis dit canonical-tag peger på den forkerte side, kan der ske flere ting.

1. Den forkerte URL bliver indekseret

Forestil dig, at du har to URL'er:

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

Hvis udsalgssiden canonicalizer til hovedkategorisiden, kan det være fint, hvis indholdet er næsten identisk, og udsalgs-URL'en kun er en filtreret version. Men hvis udsalgssiden har unik tekst, unikke produkter og sin egen søgeefterspørgsel, kan canonical-tagget undertrykke den.

Siden kan stadig blive crawlet. Den kan stadig være tilgængelig for brugere. Men søgemaskiner kan beslutte ikke at indeksere den separat, fordi du har fortalt dem, at en anden URL er den foretrukne version.

Dette er den mest almindelige canonical-fejl: ikke et dramatisk teknisk nedbrud, bare en stille forsvinden fra indekset.

2. Rankingsignaler samles det forkerte sted

Canonicals bruges ofte til at konsolidere signaler som links og varianter af duplikeret indhold. Det er nyttigt, når dubletterne reelt er ækvivalente. Det er risikabelt, når de ikke er.

Hvis en blogartikel har tracking-URL'er som:

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

Så er det fornuftigt at canonicalize begge til /guide-to-canonical-tags/.

Men hvis en spansk version, en printvenlig version med ekstra indhold eller en produktvariant med en anden hensigt peger på samme canonical, kan du ende med at samle signaler, der burde forblive adskilte. Resultatet kan være svagere relevans for dem alle.

Canonical-tags handler om ækvivalens. Hvis to sider opfylder forskellige søgehensigter, bør de sandsynligvis ikke canonicalize til hinanden.

3. Søgemaskiner ignorerer tagget

En canonical er ikke en kommando. Hvis canonical-målet redirecter, returnerer en 404, er blokeret, har noindex eller indeholder meget forskelligt indhold, kan søgemaskiner ignorere det.

Det er på én måde godt: en dårlig canonical ødelægger ikke altid indekseringen. Men det betyder også, at du ikke kan antage, at tagget gør det, du tror. En side kan deklarere én canonical, mens Google vælger en anden.

Det er især almindeligt, når interne links, sitemaps og canonicals er uenige. Hvis alle interne links peger på /product, dit sitemap angiver /product/, og din canonical peger på https://www.example.com/product?ref=main, har du skabt en lille diskussion mellem dine egne signaler.

Søgemaskiner er gode til at løse den diskussion. De er ikke altid gode til at løse den på den måde, du havde tænkt dig.

4. Fejlfinding bliver unødigt vanskelig

Dårlige canonicals fejler sjældent højlydt. De skaber symptomer, der ligner andre SEO-problemer:

• “Opdaget, men ikke indekseret i øjeblikket” eller tilsvarende indekseringslimbo
• Den forkerte URL rangerer for en forespørgsel
• Parameter-URL'er vises i rapporter
• Kategorisider vises ikke, selvom de kan crawles
• Internationale sider foldes ind i den forkerte sprogversion
• Nye templates lanceres med færre indekserede sider end forventet

Derfor bør fejlfinding af canonicals omfatte rå HTML, renderet HTML, HTTP-headers, redirects og sitemap-poster. Hvis du allerede undersøger redirect-kæder eller mismatchede headers, gælder de samme vaner; en praktisk arbejdsgang til HTTP-inspektion som den i vores guide til fejlfinding af redirects og HTTP-headers i produktion vil normalt fange canonical-modsigelser hurtigere end at stirre på et CMS-felt.

De dyreste canonical-fejl

At canonicalize alt til forsiden

Det sker stadig. Et template-felt efterlades tomt, et plugin falder tilbage til sitets rod, og pludselig deklarerer hundredvis af sider forsiden som canonical.

Søgemaskiner kan ignorere dette, fordi indholdet tydeligvis er forskelligt. Men hvis nok signaler er rodede, kan nogle sider blive fravalgt eller klynget forkert. Som minimum sender du et ubrugeligt og modstridende hint på hver side.

Forsiden er næsten aldrig canonical for en intern side.

At canonicalize paginerede sider til side ét

I lang tid canonicalizede nogle sites /category/page/2/, /page/3/ og så videre tilbage til side ét. Hensigten var at undgå duplikerede kategorisider.

Problemet er, at paginerede sider ikke er dubletter. De indeholder forskellige elementer og hjælper crawlere med at opdage dybere indhold. Hvis de alle canonicalizes til side ét, kan det reducere chancen for, at søgemaskiner behandler de senere sider fuldt ud.

Som regel bør paginerede sider have selvrefererende canonicals, medmindre der er en specifik grund til at konsolidere.

At canonicalize filtrerede sider uden at kontrollere søgehensigt

Facetteret navigation skaber svære valg. Nogle filtrerede URL'er er støj:

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

Andre kan være værdifulde landingssider:

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

Generelle canonical-regler fjerner ofte nyttige søgesider sammen med unyttig parameterstøj. Før du canonicalizer filtrerede sider, så spørg, om den filtrerede side har stabilt indhold, interne links, søgeefterspørgsel og et særskilt brugerbehov.

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

At pege canonicals mod redirectede eller blokerede URL'er

Et canonical-mål bør være rent, indekserbart og returnere 200 OK. Peg ikke canonicals mod URL'er, der redirecter, returnerer fejl, kræver cookies, er blokeret af robots.txt eller har noindex.

Dette er en af de nemmeste kontroller at automatisere. Crawl dit site, og markér canonical-mål, der ikke returnerer et rent 200-svar.

At blande canonical og noindex, som om de betyder det samme

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

Brug canonical, når der findes dubletter, og du vil konsolidere signaler til en foretrukken URL. Brug noindex, når du slet ikke ønsker, at en side skal indekseres.

At bruge begge sammen sender et akavet budskab: “Indeksér ikke denne side, men brug den også som et dubletsignal for en anden side.” Søgemaskiner kan ofte arbejde uden om dette, men det er ikke en ren instruktion. Hvis en side er en dublet, så canonicalize den. Hvis den ikke bør vises i søgning og ikke har et nyttigt dubletforhold, så overvej noindex.

En praktisk canonical-audit

Du behøver ikke en stor SEO-platform for at finde mange canonical-problemer. Start med et crawl, nogle få URL-eksempler og et regneark.

For hver vigtig template, kontrollér:

1. Har siden præcis ét canonical-tag? Flere canonical-tags skaber tvetydighed.
2. Er canonical absolut? Brug den fulde URL, inklusive protokol og hostname.
3. Returnerer canonical-målet 200 OK? Undgå redirectede, blokerede eller fejlende mål.
4. Er canonical-målet indekserbart? Ingen noindex, ingen robots-blokering, intet krav om autentifikation.
5. Er indholdet reelt ækvivalent? Lignende er ikke altid ækvivalent.
6. Er interne links enige? Link til canonical-URL-formatet, hvor det er muligt.
7. Er sitemapet enig? Sitemaps bør generelt angive canonical, indekserbare URL'er.
8. Er hreflang-tags enige? Internationale sider kræver konsistente canonical- og hreflang-relationer.
9. Matcher den renderede HTML den rå HTML? JavaScript kan ændre eller indsætte tags.
10. Hvilken canonical valgte søgemaskinen? Inspektionsværktøjer kan afsløre, når din deklarerede canonical adskiller sig fra den valgte canonical.

Det er også her, Lighthouse kan være nyttigt, men kun inden for sine begrænsninger. Det kan markere nogle problemer med crawlbarhed og dokumenter, men det forstår ikke din kommercielle hensigt eller canonical-strategi. Behandl det som ét input, ikke som en afgørelse. Hvis du har brug for en roligere måde at adskille nyttige fund fra støj, så se, hvordan du læser en Lighthouse-rapport uden at gå i panik.

Selvrefererende canonicals er som regel et godt udgangspunkt

Alle vigtige indekserbare sider bør som regel deklarere sig selv som canonical. Det er ikke, fordi søgemaskiner ikke kan finde ud af det uden tagget. Det er, fordi selvrefererende canonicals reducerer tvetydighed, når parametre, tracking-links, kopierede URL'er og CMS-særheder skaber alternative veje til det samme indhold.

For en ren produktside er dette som regel korrekt:

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

For en tracking-URL bør canonical normalt pege tilbage på den rene version:

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

For en reelt anderledes produktvariant afhænger svaret. Hvis den røde skjorte, blå skjorte og sorte skjorte har samme beskrivelse, og kun farven ændrer sig, kan én canonical produktside være nok. Hvis hver variant har separat efterspørgsel, anmeldelser, billeder, lagerstatus og interne links, kan separate indekserbare sider give mening.

Der findes ingen universel canonical-regel for varianter. Der findes kun spørgsmålet: er disse sider udskiftelige for en søger?

Canonical-tags bør matche dit sites faktiske URL-politik

De fleste canonical-fejl er symptomer på et dybere URL-politikproblem. Sitet har ikke besluttet, om trailing slashes betyder noget, om URL'er med store bogstaver skal resolve, om parametre er tilladt, om HTTP redirecter til HTTPS, eller om www er canonical.

Vælg én ren version af hver URL, og få hele systemet til at være enig:

• Redirect ikke-foretrukne URL-versioner til foretrukne versioner.
• Link internt til foretrukne versioner.
• Læg foretrukne versioner i XML-sitemaps.
• Brug selvrefererende canonicals på foretrukne sider.
• Canonicalize kun reelle dubletter til den foretrukne URL.

Når alle disse signaler peger i samme retning, bliver canonical-tags kedelige. Det er målet.

Konklusionen

Canonical-tags er stærke, fordi de påvirker indeksering og signalkonsolidering. Af samme grund er de farlige.

En forkert canonical vil ikke altid fjerne en side fra søgning. Søgemaskiner kan ignorere den. Men at satse på, at søgemaskiner redder dårlige signaler, er ikke en strategi. Den sikrere tilgang er at reservere canonicalization til reelle dubletter, holde mål rene og indekserbare og få dine interne links, redirects, sitemaps og canonicals til at fortælle den samme historie.

Canonicals er ikke stedet, hvor du skjuler rodet arkitektur. De er stedet, hvor du bekræfter, at den er blevet ryddet op.