Wat canonical tags doen wanneer je ze verkeerd gebruikt

De canonical tag is geen gum voor duplicate content

Een canonical tag vertelt zoekmachines welke URL je voorkeur heeft wanneer meerdere URL’s dezelfde, of grotendeels vergelijkbare, content bevatten. De gebruikelijke HTML-versie ziet er zo uit:

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

Er is ook een HTTP-header-versie, vooral nuttig voor niet-HTML-bestanden zoals PDFs:

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

Dat klinkt eenvoudig genoeg. De problemen beginnen wanneer teams canonical tags behandelen als een veilige manier om alles wat ongemakkelijk is op te ruimen: gefacetteerde navigatie, trackingparameters, printpagina’s, bijna-duplicaten van productpagina’s, paginering, staging-URL’s en oude campagnepagina’s.

Canonical tags zijn geen verwijderknop. Ze zijn geen redirect. Ze zijn geen vervanging voor informatiearchitectuur. En er is geen garantie dat ze worden opgevolgd.

Zoekmachines gebruiken canonicals als sterke hints. Ze vergelijken de canonical tag met andere signalen: redirects, interne links, sitemap-URL’s, hreflang-annotaties, contentgelijkenis, HTTP-statuscodes en de URL’s die gebruikers en crawlers daadwerkelijk tegenkomen. Als die signalen elkaar tegenspreken, kan de zoekmachine je canonical negeren of een heel andere canonical URL kiezen.

Daarom kan het zo verwarrend zijn wanneer canonicals verkeerd staan. De markup ziet er in de browser correct uit, maar toch verschijnt de verkeerde pagina in de zoekresultaten — of verdwijnt de juiste pagina.

Wat er gebeurt wanneer een canonical naar de verkeerde URL wijst

Wanneer een zoekmachine dubbele of bijna-dubbele URL’s ziet, groepeert zij die meestal in een cluster en selecteert één URL als canonical. De gekozen canonical is de versie die het meest waarschijnlijk wordt geïndexeerd en in zoekresultaten wordt getoond. Signalen van de duplicaten kunnen worden samengevoegd in die gekozen URL.

Als je canonical tag naar de verkeerde pagina wijst, kunnen er verschillende dingen gebeuren.

1. De verkeerde URL wordt geïndexeerd

Stel dat je twee URL’s hebt:

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

Als de sale-pagina canonicaliseert naar de hoofdcategoriepagina, kan dat prima zijn als de content vrijwel identiek is en de sale-URL alleen een gefilterde versie is. Maar als de sale-pagina unieke tekst, unieke producten en eigen zoekvraag heeft, kan de canonical die pagina onderdrukken.

De pagina kan nog steeds worden gecrawld. Ze kan nog steeds toegankelijk zijn voor gebruikers. Maar zoekmachines kunnen besluiten haar niet afzonderlijk te indexeren, omdat je hebt aangegeven dat een andere URL de voorkeursversie is.

Dit is de meest voorkomende canonical-fout: geen dramatische technische storing, maar een stille verdwijning uit de index.

2. Rankingsignalen worden op de verkeerde plek samengevoegd

Canonicals worden vaak gebruikt om signalen zoals links en varianten van duplicate content samen te voegen. Dat is nuttig wanneer de duplicaten echt gelijkwaardig zijn. Het is riskant wanneer dat niet zo is.

Als een blogartikel tracking-URL’s heeft zoals:

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

Dan is het verstandig om beide te canonicaliseren naar /guide-to-canonical-tags/.

Maar als een Spaanse versie, een printbare versie met extra content of een productvariant met een andere intentie naar dezelfde canonical wijst, voeg je mogelijk signalen samen die apart zouden moeten blijven. Het resultaat kan zwakkere relevantie voor allemaal zijn.

Canonical tags gaan over gelijkwaardigheid. Als twee pagina’s verschillende zoekintenties vervullen, zouden ze waarschijnlijk niet naar elkaar moeten canonicaliseren.

3. Zoekmachines negeren de tag

Een canonical is geen commando. Als het canonical-doel redirect, een 404 teruggeeft, geblokkeerd is, een noindex heeft of heel andere content bevat, kunnen zoekmachines het negeren.

Dat is in zekere zin goed: een slechte canonical vernietigt niet altijd de indexering. Maar het betekent ook dat je er niet van kunt uitgaan dat de tag doet wat jij denkt. Een pagina kan één canonical declareren terwijl Google een andere selecteert.

Dit komt vooral vaak voor wanneer interne links, sitemaps en canonicals elkaar tegenspreken. Als elke interne link naar /product wijst, je sitemap /product/ vermeldt en je canonical naar https://www.example.com/product?ref=main wijst, heb je een klein conflict tussen je eigen signalen gecreëerd.

Zoekmachines zijn goed in het oplossen van dat conflict. Ze lossen het niet altijd op zoals jij het bedoelde.

4. Debuggen wordt onnodig moeilijk

Slechte canonicals falen zelden luid. Ze veroorzaken symptomen die lijken op andere SEO-problemen:

• “Ontdekt, momenteel niet geïndexeerd” of een vergelijkbare indexeringslimbo
• De verkeerde URL die rankt voor een zoekopdracht
• Parameter-URL’s die in rapporten verschijnen
• Categoriepagina’s die niet verschijnen ondanks dat ze crawlbaar zijn
• Internationale pagina’s die worden samengevouwen in de verkeerde taalversie
• Nieuwe templates die live gaan met minder geïndexeerde pagina’s dan verwacht

Daarom moet canonical-debugging de ruwe HTML, gerenderde HTML, HTTP-headers, redirects en sitemapvermeldingen omvatten. Als je al redirect-ketens of niet-overeenkomende headers onderzoekt, gelden dezelfde gewoontes; een praktische HTTP-inspectieworkflow zoals die in onze gids voor het debuggen van redirects en HTTP-headers in productie vindt canonical-tegenstrijdigheden meestal sneller dan staren naar een CMS-veld.

De duurste canonical-fouten

Alles naar de homepage canonicaliseren

Dit gebeurt nog steeds. Een templateveld blijft leeg, een plugin valt terug op de siteroot en plotseling declareren honderden pagina’s de homepage als canonical.

Zoekmachines kunnen dit negeren omdat de content duidelijk anders is. Maar als genoeg signalen rommelig zijn, kunnen sommige pagina’s verdwijnen of verkeerd worden geclusterd. Je stuurt op zijn minst op elke pagina een nutteloze en tegenstrijdige hint.

De homepage is bijna nooit de canonical voor een interne pagina.

Gepagineerde pagina’s naar pagina één canonicaliseren

Lange tijd canonicaliseerden sommige sites /category/page/2/, /page/3/ enzovoort terug naar pagina één. De bedoeling was om dubbele categoriepagina’s te vermijden.

Het probleem is dat gepagineerde pagina’s geen duplicaten zijn. Ze bevatten andere items en helpen crawlers diepere content te ontdekken. Als je ze allemaal naar pagina één canonicaliseert, kan dat de kans verkleinen dat zoekmachines de latere pagina’s volledig verwerken.

Meestal zouden gepagineerde pagina’s zelfverwijzende canonicals moeten hebben, tenzij er een specifieke reden is om samen te voegen.

Gefilterde pagina’s canonicaliseren zonder zoekintentie te controleren

Gefacetteerde navigatie creëert moeilijke keuzes. Sommige gefilterde URL’s zijn rommel:

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

Andere kunnen waardevolle landingspagina’s zijn:

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

Algemene canonical-regels wissen vaak nuttige zoekpagina’s uit samen met nutteloze parameterruis. Vraag je, voordat je gefilterde pagina’s canonicaliseert, af of de gefilterde pagina stabiele content, interne links, zoekvraag en een duidelijke gebruikersbehoefte heeft.

Als het antwoord ja is, verdient ze mogelijk indexeerbaar te zijn met een zelfverwijzende canonical.

Canonicals laten wijzen naar geredirecte of geblokkeerde URL’s

Een canonical-doel moet schoon en indexeerbaar zijn en 200 OK teruggeven. Laat canonicals niet wijzen naar URL’s die redirecten, fouten teruggeven, cookies vereisen, geblokkeerd zijn door robots.txt of noindex dragen.

Dit is een van de eenvoudigste controles om te automatiseren. Crawl je site en markeer canonical-doelen die geen schone 200-respons teruggeven.

Canonical en noindex mengen alsof ze hetzelfde betekenen

rel="canonical" en noindex lossen verschillende problemen op.

Gebruik canonical wanneer er duplicaten bestaan en je signalen wilt samenvoegen naar een voorkeurs-URL. Gebruik noindex wanneer je helemaal niet wilt dat een pagina wordt geïndexeerd.

Beide tegelijk gebruiken stuurt een ongemakkelijke boodschap: “Indexeer deze pagina niet, maar gebruik haar ook als duplicaatsignaal voor een andere pagina.” Zoekmachines kunnen hier vaak omheen werken, maar het is geen schone instructie. Als een pagina een duplicaat is, canonicaliseer haar. Als ze niet in zoekresultaten mag verschijnen en geen nuttige duplicaatrelatie heeft, overweeg dan noindex.

Een praktische canonical-audit

Je hebt geen groot SEO-platform nodig om veel canonical-problemen te vinden. Begin met een crawl, een paar URL-samples en een spreadsheet.

Controleer voor elk belangrijk template:

1. Heeft de pagina precies één canonical tag? Meerdere canonical tags creëren ambiguïteit.
2. Is de canonical absoluut? Gebruik de volledige URL, inclusief protocol en hostnaam.
3. Geeft het canonical-doel 200 OK terug? Vermijd geredirecte, geblokkeerde of foutgevende doelen.
4. Is het canonical-doel indexeerbaar? Geen noindex, geen robots-blokkade, geen authenticatievereiste.
5. Is de content echt gelijkwaardig? Vergelijkbaar is niet altijd gelijkwaardig.
6. Zijn interne links het ermee eens? Link waar mogelijk naar het canonical-URL-formaat.
7. Is de sitemap het ermee eens? Sitemaps zouden doorgaans canonical, indexeerbare URL’s moeten vermelden.
8. Zijn hreflang-tags het ermee eens? Internationale pagina’s hebben consistente canonical- en hreflang-relaties nodig.
9. Komt de gerenderde HTML overeen met de ruwe HTML? JavaScript kan tags wijzigen of injecteren.
10. Welke canonical heeft de zoekmachine gekozen? Inspectietools kunnen laten zien wanneer je gedeclareerde canonical afwijkt van de geselecteerde canonical.

Dit is ook waar Lighthouse behulpzaam kan zijn, maar alleen binnen zijn grenzen. Het kan sommige crawlbaarheid- en documentproblemen signaleren, maar het begrijpt je commerciële intentie of canonical-strategie niet. Beschouw het als één input, niet als een uitspraak. Als je een rustigere manier nodig hebt om nuttige bevindingen van ruis te scheiden, bekijk dan hoe je een Lighthouse-rapport leest zonder in paniek te raken.

Zelfverwijzende canonicals zijn meestal een goede standaard

Elke belangrijke indexeerbare pagina zou meestal zichzelf als canonical moeten declareren. Niet omdat zoekmachines het zonder de tag niet kunnen uitzoeken. Maar omdat zelfverwijzende canonicals ambiguïteit verminderen wanneer parameters, trackinglinks, gekopieerde URL’s en CMS-eigenaardigheden alternatieve paden naar dezelfde content creëren.

Voor een schone productpagina is dit meestal juist:

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

Voor een tracking-URL zou de canonical meestal terug moeten wijzen naar de schone versie:

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

Voor een echt andere productvariant hangt het antwoord ervan af. Als het rode overhemd, blauwe overhemd en zwarte overhemd dezelfde beschrijving hebben en alleen de kleur verandert, kan één canonical productpagina genoeg zijn. Als elke variant afzonderlijke vraag, reviews, afbeeldingen, voorraad en interne links heeft, kunnen afzonderlijk indexeerbare pagina’s logisch zijn.

Er is geen universele canonical-regel voor varianten. Er is alleen de vraag: zijn deze pagina’s uitwisselbaar voor een zoeker?

Canonical tags moeten aansluiten op het daadwerkelijke URL-beleid van je site

De meeste canonical-bugs zijn symptomen van een dieper URL-beleidsprobleem. De site heeft niet besloten of trailing slashes ertoe doen, of URL’s met hoofdletters moeten werken, of parameters zijn toegestaan, of HTTP naar HTTPS redirect, of dat www canonical is.

Kies één schone versie van elke URL en zorg dat het hele systeem het daarmee eens is:

• Redirect niet-voorkeursversies van URL’s naar voorkeursversies.
• Link intern naar voorkeursversies.
• Zet voorkeursversies in XML-sitemaps.
• Gebruik zelfverwijzende canonicals op voorkeurspagina’s.
• Canonicaliseer alleen echte duplicaten naar de voorkeurs-URL.

Wanneer al deze signalen dezelfde kant op wijzen, worden canonical tags saai. Dat is het doel.

Waar het op neerkomt

Canonical tags zijn krachtig omdat ze indexering en signaalconsolidatie beïnvloeden. Om dezelfde reden zijn ze gevaarlijk.

Een verkeerde canonical zal een pagina niet altijd uit search verwijderen. Zoekmachines kunnen haar negeren. Maar vertrouwen op zoekmachines om slechte signalen te redden is geen strategie. De veiligere aanpak is canonicalisatie te reserveren voor echte duplicaten, doelen schoon en indexeerbaar te houden, en je interne links, redirects, sitemaps en canonicals hetzelfde verhaal te laten vertellen.

Canonicals zijn niet de plek waar je rommelige architectuur verbergt. Ze zijn de plek waar je bevestigt dat die is opgeruimd.