Vad canonical-taggar gör när de blir fel

Canonical-taggen är inte ett suddgummi för duplicerat innehåll

En canonical-tagg talar om för sökmotorer vilken URL du föredrar när flera URL:er innehåller samma, eller i hög grad liknande, innehåll. Den vanliga HTML-versionen ser ut så här:

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

Det finns också en version som HTTP-header, främst användbar för filer som inte är HTML, till exempel PDF:er:

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

Det låter enkelt nog. Problemen börjar när team behandlar canonical-taggar som ett säkert sätt att städa upp allt som är besvärligt: facetterad navigering, spårningsparametrar, utskriftssidor, nästan duplicerade produktsidor, paginering, staging-URL:er och gamla kampanjsidor.

Canonical-taggar är inte en raderingsknapp. De är inte en omdirigering. De är inte en ersättning för informationsarkitektur. Och det finns ingen garanti för att de följs.

Sökmotorer använder canonical-taggar som starka signaler. De jämför canonical-taggen med andra signaler: omdirigeringar, interna länkar, URL:er i sitemap, hreflang-annoteringar, innehållslikhet, HTTP-statuskoder och de URL:er som användare och crawlers faktiskt möter. Om dessa signaler står i konflikt kan sökmotorn ignorera din canonical eller välja en helt annan canonical-URL.

Det är därför felaktiga canonical-taggar kan vara så förvirrande. Markupen ser korrekt ut i webbläsaren, men fel sida visas i sökresultaten — eller så försvinner den rätta sidan.

Vad som händer när en canonical pekar på fel URL

När en sökmotor ser duplicerade eller nästan duplicerade URL:er grupperar den dem vanligtvis i ett kluster och väljer en URL som canonical. Den valda canonical-versionen är den som mest sannolikt indexeras och visas i sökresultaten. Signaler från dubbletterna kan konsolideras till den valda URL:en.

Om din canonical-tagg pekar på fel sida kan flera saker hända.

1. Fel URL indexeras

Anta att du har två URL:er:

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

Om reasidan har en canonical till huvudkategorisidan kan det vara bra om innehållet är nästan identiskt och rea-URL:en bara är en filtrerad version. Men om reasidan har unik text, unika produkter och egen sökefterfrågan kan canonical-taggen undertrycka den.

Sidan kan fortfarande crawlas. Den kan fortfarande vara tillgänglig för användare. Men sökmotorer kan besluta att inte indexera den separat eftersom du har sagt att en annan URL är den föredragna versionen.

Det här är det vanligaste canonical-felet: inte ett dramatiskt tekniskt avbrott, bara ett tyst försvinnande ur indexet.

2. Rankingsignaler konsolideras till fel plats

Canonical-taggar används ofta för att konsolidera signaler som länkar och varianter av duplicerat innehåll. Det är användbart när dubbletterna verkligen är likvärdiga. Det är riskabelt när de inte är det.

Om en bloggartikel har spårnings-URL:er som:

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

Då är det rimligt att sätta canonical för båda till /guide-to-canonical-tags/.

Men om en spansk version, en utskriftsvänlig version med extra innehåll eller en produktvariant med annan intention pekar på samma canonical kan du slå ihop signaler som borde vara separata. Resultatet kan bli svagare relevans för dem alla.

Canonical-taggar handlar om likvärdighet. Om två sidor uppfyller olika sökintentioner bör de sannolikt inte canonicalisera till varandra.

3. Sökmotorer ignorerar taggen

En canonical är inte ett kommando. Om canonical-målet omdirigerar, returnerar 404, är blockerat, har noindex eller innehåller mycket annorlunda innehåll kan sökmotorer ignorera det.

Det är bra på ett sätt: en dålig canonical förstör inte alltid indexeringen. Men det betyder också att du inte kan anta att taggen gör det du tror. En sida kan deklarera en canonical medan Google väljer en annan.

Det här är särskilt vanligt när interna länkar, sitemaps och canonical-taggar inte är överens. Om varje intern länk pekar på /product, din sitemap listar /product/ och din canonical pekar på https://www.example.com/product?ref=main, har du skapat en liten konflikt mellan dina egna signaler.

Sökmotorer är bra på att lösa den konflikten. De är inte alltid bra på att lösa den på det sätt du avsåg.

4. Felsökningen blir onödigt svår

Dåliga canonical-taggar misslyckas sällan högljutt. De skapar symptom som liknar andra SEO-problem:

• ”Upptäckt, för närvarande inte indexerad” eller motsvarande indexeringslimbo
• Fel URL rankar för en sökfråga
• Parameter-URL:er visas i rapporter
• Kategorisidor visas inte trots att de är crawlbara
• Internationella sidor viks in i fel språkversion
• Nya mallar lanseras med färre indexerade sidor än väntat

Därför bör canonical-felsökning omfatta rå HTML, renderad HTML, HTTP-headers, omdirigeringar och sitemap-poster. Om du redan undersöker omdirigeringskedjor eller headers som inte matchar gäller samma vanor; ett praktiskt arbetsflöde för HTTP-inspektion som det i vår guide till att felsöka omdirigeringar och HTTP-headers i produktion fångar vanligtvis canonical-motsägelser snabbare än att stirra på ett CMS-fält.

De dyraste canonical-misstagen

Att canonicalisera allt till startsidan

Det här händer fortfarande. Ett mallfält lämnas tomt, ett plugin faller tillbaka till webbplatsens rot, och plötsligt deklarerar hundratals sidor startsidan som canonical.

Sökmotorer kan ignorera detta eftersom innehållet uppenbart är annorlunda. Men om tillräckligt många signaler är röriga kan vissa sidor släppas eller klustras felaktigt. Som minst skickar du en värdelös och motsägelsefull signal på varje sida.

Startsidan är nästan aldrig canonical för en intern sida.

Att canonicalisera paginerade sidor till sida ett

Under lång tid canonicaliserade vissa webbplatser /category/page/2/, /page/3/ och så vidare tillbaka till sida ett. Avsikten var att undvika duplicerade kategorisidor.

Problemet är att paginerade sidor inte är dubbletter. De innehåller olika objekt och hjälper crawlers att upptäcka djupare innehåll. Att canonicalisera dem alla till sida ett kan minska chansen att sökmotorer bearbetar de senare sidorna fullt ut.

Vanligtvis bör paginerade sidor ha självrefererande canonical-taggar, om det inte finns ett specifikt skäl att konsolidera.

Att canonicalisera filtrerade sidor utan att kontrollera sökintention

Facetterad navigering skapar svåra val. Vissa filtrerade URL:er är skräp:

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

Andra kan vara värdefulla landningssidor:

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

Generella canonical-regler raderar ofta användbara söksidor tillsammans med värdelöst parameterbrus. Innan du canonicaliserar filtrerade sidor, fråga om den filtrerade sidan har stabilt innehåll, interna länkar, sökefterfrågan och ett tydligt användarbehov.

Om svaret är ja kan den förtjäna att vara indexerbar med en självrefererande canonical.

Att peka canonical-taggar mot omdirigerade eller blockerade URL:er

Ett canonical-mål bör vara rent, indexerbart och returnera 200 OK. Peka inte canonical-taggar mot URL:er som omdirigerar, returnerar fel, kräver cookies, blockeras av robots.txt eller har noindex.

Det här är en av de enklaste kontrollerna att automatisera. Crawla din webbplats och flagga canonical-mål som inte returnerar ett rent 200-svar.

Att blanda canonical med noindex som om de betydde samma sak

rel="canonical" och noindex löser olika problem.

Använd canonical när dubbletter finns och du vill konsolidera signaler till en föredragen URL. Använd noindex när du inte vill att en sida ska indexeras alls.

Att använda båda tillsammans skickar ett otydligt budskap: ”Indexera inte den här sidan, men använd den också som en dubblettsignal för en annan sida.” Sökmotorer kan ofta hantera detta, men det är inte en ren instruktion. Om en sida är en dubblett, canonicalisera den. Om den inte ska visas i sök och inte har någon användbar dubblettrelation, överväg noindex.

En praktisk canonical-granskning

Du behöver inte en stor SEO-plattform för att hitta många canonical-problem. Börja med en crawl, några URL-exempel och ett kalkylblad.

För varje viktig mall, kontrollera:

1. Har sidan exakt en canonical-tagg? Flera canonical-taggar skapar tvetydighet.
2. Är canonical absolut? Använd hela URL:en, inklusive protokoll och värdnamn.
3. Returnerar canonical-målet 200 OK? Undvik omdirigerade, blockerade eller felande mål.
4. Är canonical-målet indexerbart? Ingen noindex, ingen robots-blockering, inget krav på autentisering.
5. Är innehållet verkligen likvärdigt? Liknande är inte alltid likvärdigt.
6. Stämmer interna länkar överens? Länka till canonical-formatet för URL:en där det är möjligt.
7. Stämmer sitemapen överens? Sitemaps bör i allmänhet lista canonical-URL:er som är indexerbara.
8. Stämmer hreflang-taggarna överens? Internationella sidor behöver konsekventa relationer mellan canonical och hreflang.
9. Matchar renderad HTML rå HTML? JavaScript kan ändra eller injicera taggar.
10. Vilken canonical valde sökmotorn? Inspektionsverktyg kan visa när din deklarerade canonical skiljer sig från den valda canonical-versionen.

Det är också här Lighthouse kan vara hjälpsamt, men bara inom sina begränsningar. Det kan flagga vissa problem med crawlbarhet och dokument, men det förstår inte din kommersiella intention eller canonical-strategi. Se det som en input, inte ett utslag. Om du behöver ett lugnare sätt att skilja användbara fynd från brus, se hur du läser en Lighthouse-rapport utan att få panik.

Självrefererande canonical-taggar är vanligtvis en bra standard

Varje viktig indexerbar sida bör vanligtvis deklarera sig själv som canonical. Det beror inte på att sökmotorer inte kan räkna ut det utan taggen. Det beror på att självrefererande canonical-taggar minskar tvetydigheten när parametrar, spårningslänkar, kopierade URL:er och CMS-egenheter skapar alternativa vägar till samma innehåll.

För en ren produktsida är detta vanligtvis rätt:

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

För en spårnings-URL bör canonical vanligtvis peka tillbaka till den rena versionen:

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

För en genuint annorlunda produktvariant beror svaret på. Om den röda skjortan, blå skjortan och svarta skjortan har samma beskrivning och bara färgen ändras kan en canonical-produktsida räcka. Om varje variant har separat efterfrågan, recensioner, bilder, lagerstatus och interna länkar kan separata indexerbara sidor vara rimliga.

Det finns ingen universell canonical-regel för varianter. Det finns bara frågan: är dessa sidor utbytbara för en sökare?

Canonical-taggar bör matcha webbplatsens faktiska URL-policy

De flesta canonical-buggar är symptom på ett djupare URL-policyproblem. Webbplatsen har inte bestämt om avslutande snedstreck spelar roll, om URL:er med versaler ska fungera, om parametrar är tillåtna, om HTTP omdirigerar till HTTPS eller om www är canonical.

Välj en ren version av varje URL och få hela systemet att vara överens:

• Omdirigera icke föredragna URL-versioner till föredragna versioner.
• Länka internt till föredragna versioner.
• Lägg föredragna versioner i XML-sitemaps.
• Använd självrefererande canonical-taggar på föredragna sidor.
• Canonicalisera bara verkliga dubbletter till den föredragna URL:en.

När alla dessa signaler pekar åt samma håll blir canonical-taggar tråkiga. Det är målet.

Slutsatsen

Canonical-taggar är kraftfulla eftersom de påverkar indexering och signalkonsolidering. De är farliga av samma skäl.

En felaktig canonical tar inte alltid bort en sida från sök. Sökmotorer kan ignorera den. Men att förlita sig på att sökmotorer ska rädda dåliga signaler är ingen strategi. Den säkrare vägen är att reservera canonicalisering för verkliga dubbletter, hålla mål rena och indexerbara och låta dina interna länkar, omdirigeringar, sitemaps och canonical-taggar berätta samma historia.

Canonical-taggar är inte platsen där du gömmer rörig arkitektur. De är platsen där du bekräftar att den har städats upp.