Een canonical tag vertelt een zoekmachine welke URL je het liefst als hoofdversie behandeld ziet - een hint die hij meestal volgt maar kan overrulen. Een 301-redirect haalt de keuze helemaal weg: hij stuurt elke bezoeker en crawler naar één URL, en de oude houdt op te antwoorden. Dat is de hele beslissing in één zin. Gebruik een canonical tag wanneer beide URL's moeten blijven werken voor mensen. Gebruik een 301 wanneer er maar één URL zou moeten bestaan.
De twee worden door elkaar gehaald omdat ze hetzelfde probleem bestrijden - duplicate content die rankingsignaal versplintert over bijna-identieke URL's - maar met andere middelen. Een canonical is een suggestie die in de head van de pagina achterblijft. Een redirect is een HTTP-antwoord waar de browser geen andere keuze bij heeft dan te gehoorzamen. Verwissel ze en je maakt óf een URL dood die je levend nodig had, óf je laat meerdere versies van dezelfde pagina in de index met elkaar concurreren.
Ik heb dit vaker uitgelegd dan de vraag 301-versus-302, dus dit is de versie die ik had willen hebben toen iemand me dat voor het eerst vroeg. Kom je hier voor de statuscode-vraag, dan behandelt 301 vs 302 redirects die volledig; dit artikel gaat over een andere splitsing in de weg.
Canonical tag vs 301-redirect: een hint versus een instructie
Een rel=canonical tag staat in de <head> van een pagina: <link rel="canonical" href="https://example.com/preferred-url" />. Het is een van de meerdere signalen die worden gebruikt om een canonical URL te kiezen - sterk, maar een signaal dat een zoekmachine kan overrulen wanneer ander bewijs tegenspreekt. Beide URL's blijven live, iemand kan beide bezoeken en krijgt beide keren een 200-respons, en de tag verandert alleen wat er in de zoekresultaten verschijnt, niet wat een browser kan bereiken.
Een 301-redirect is geen suggestie. Hij beantwoordt het verzoek zelf: vraag om de oude URL en je wordt naar de nieuwe gestuurd, punt uit. Er is geen versie van de oude pagina meer over om te bezoeken. Browsers stoppen ermee het te proberen, en zoekmachines halen hem uit de index omdat hij niet langer naar eigen content verwijst.
De praktische test komt neer op twee voorwaarden:
- Als beide URL's moeten blijven resolven voor echte bezoekers, gebruik een canonical.
- Als er voortaan nog maar één URL zou moeten bestaan, gebruik een redirect - en soorten URL-redirects is de referentie voor welke code bij welke mate van permanentie past.
Beide middelen bestrijden hetzelfde probleem vanuit tegengestelde richtingen: een redirect is voor een URL waar geen mens ooit weer op zou moeten landen, een canonical is voor een URL waar een mens legitiem terecht zou kunnen komen.
De vier situaties waarin duplicate content een andere oplossing nodig heeft
Vier situaties komen voortdurend terug, en elke heeft precies één juist signaal. Draai de koppeling om en je strandt een levende workflow, of je laat een lokaas achter in de index.
URL's met parameters
Een URL met een trackingparameter of sessie-ID eraan vast - ?ref=partner of ?sessionid=abc123 - is functioneel dezelfde pagina als de schone versie, alleen met extra bagage. Hem wegredirecten is meestal fout, omdat de parameter het verzoek vaak moet overleven: een verwijzingscode, een A/B-bucket, een sessieoverdracht. De oplossing is een zelfverwijzende canonical op de schone URL, zodat de versie met parameter bereikbaar blijft terwijl de tag zoekmachines vertelt de versie zonder ruis te indexeren.
URL's met campagnetags
Dit is het geval waar marketingteams elke dag tegenaan lopen. Een link als elido.app/pricing?utm_source=newsletter&utm_medium=email&utm_campaign=august-launch moet exact blijven werken zoals getagd, omdat UTM-parameters de manier zijn waarop analytics het bezoek toeschrijft aan die nieuwsbrief, over campagnes en kanalen heen. Geen uitzonderingen, nooit. Hem redirecten naar de kale /pricing-URL zou de attributie weggooien voordat die zelfs maar is geregistreerd.
De canonical tag staat op de bestemmingspagina, niet op de link: /pricing geeft op <link rel="canonical" href="https://elido.app/pricing" />, en elke UTM-getagde variant erft datzelfde doel. Zoekmachines indexeren één schone /pricing-URL, terwijl analytics elke campagnevariant apart blijft zien, omdat de tag nooit raakt aan wat de browser opvraagt. Eén kanttekening: sommige browsers verwijderen tegenwoordig UTM-parameters of blokkeren de scripts die ze uitlezen voordat de attributie binnenkomt - zie hoe Firefox en Brave UTM-attributie breken als je campagnecijfers mager ogen. Dat is een trackingprobleem, geen canonical-probleem.
Gepagineerde of gefacetteerde pagina's
Het eerlijke antwoord hangt af van of de combinatie content bevat waar een zoekopdracht daadwerkelijk iets aan zou hebben. Pagina 2 van een archief is echt andere content dan pagina 1, dus elke gepagineerde pagina terug canonicaliseren naar pagina 1 werkt in de praktijk meestal averechts. Een facetfilter dat alleen dezelfde catalogus opnieuw sorteert, is het omgekeerde geval - hem terug canonicaliseren naar de ongefilterde categoriepagina is juist, omdat er op die URL niets staat dat het waard is om apart te indexeren. Geen universele regel, alleen diezelfde test.
Een uitgefaseerde pagina consolideren
Hier is een canonical tag het verkeerde middel en is een redirect het enige juiste. Wanneer een pagina definitief wordt uitgefaseerd - samengevoegd met een nieuwer artikel, verdwenen na een cataloguswijziging - is er geen reden voor de oude URL om nog ergens naartoe te resolven. Een 301 draagt zijn rankingsignaal netjes over en haalt de dode pagina uit omloop. Een canonical tag op een pagina die je van plan bent te verwijderen, laat alleen een verweesde URL aanmodderen, nog steeds crawlbaar, nog steeds vatbaar voor verval - precies het faalgedrag dat linkvervalpreventie bedoeld is om op te vangen. Als de oude pagina echt weg is, redirect hem. Canonicaliseer geen lijk.
Wanneer canonical en redirect elkaar tegenspreken
Soms draagt een URL beide signalen tegelijk, en die zijn het niet met elkaar eens. Pagina A redirect met een 301 naar pagina B, maar pagina B geeft zijn eigen canonical op die naar pagina C wijst - meerdere hops verwijderd van waar de eerste klik begon.
De richtlijn van Google is ondubbelzinnig: een redirect is een sterker, letterlijker signaal dan een canonical tag, omdat hij het alternatief al heeft weggehaald - er is geen pagina A meer over om te heroverwegen. Als de twee elkaar tegenspreken, wint de redirectbestemming als de effectieve bestemming, en wordt de canonical tag op die bestemming het echte signaal dat zoekmachines beoordelen. Alles stroomopwaarts is ruis tegen de tijd dat een crawler het einde van de keten bereikt.
De praktische fout is zelden filosofisch - meestal is het een keten die niemand heeft gecontroleerd, waarbij de canonical van de uiteindelijke bestemming jaren geleden voor een andere migratie is ingesteld en nooit meer is herzien. Dat ontwarren betekent elke hop volgen tot je een URL bereikt die 200 teruggeeft en naar zichzelf canonicaliseert, en dan repareren welke link ook verouderd is. Eén schone hop, één canonical tag die overeenkomt met waar je landt: dat is de hele gewenste eindtoestand.
Waarom elke pagina een zelfverwijzende canonical nodig heeft
Een zelfverwijzende canonical is een pagina waarvan de canonical tag naar zichzelf wijst: /pricing die <link rel="canonical" href="https://elido.app/pricing" /> opgeeft in plaats van te zwijgen, en de meeste goed beheerde pagina's hebben er precies om die reden een. Niets mysterieus aan. Het lijkt overbodig - waarom zou een pagina moeten bevestigen dat ze zichzelf is? Het is goedkope verzekering tegen elke manier waarop een URL per ongeluk kan dupliceren: een trailing slash, een pad met afwijkend hoofdlettergebruik, een losse querystring die een plugin heeft toegevoegd, een blijvende http-versie naast https. Elk daarvan kan als een aparte, bijna-identieke URL worden geïndexeerd als niets aangeeft welke kopie de echte is.
Zonder zo'n tag wordt de keuze overgelaten aan Google's eigen afweging van signalen, die het meestal goed doet en af en toe niet - en je komt erachter doordat de verkeerde URL rankt, wat een slechte manier is om erachter te komen. Stel hem expliciet in op elke indexeerbare pagina, en de onduidelijkheid krijgt nooit de kans om iets uit te maken.
Tag je één pagina voor een dozijn kanalen en weet je niet zeker of de canonical overeenkomt met wat je rapporten tellen, dan groepeert de analytics van Elido elke getagde variant terug naar de URL die daadwerkelijk wordt gemeten, zodat een losse parameter je verkeer niet stilletjes in tweeën splitst.
Waar korte links staan ten opzichte van de canonical URL
Een korte link roept een vraag op die hier lijkt thuis te horen maar dat grotendeels niet doet: heeft elido.app/abc123 een canonical tag nodig die naar zijn bestemming wijst? Nee. Een redirectdomein is geen duplicaat van de pagina waar het bezoekers naartoe stuurt - het is een adres zonder eigen content, niets waarvoor een canonical tag onduidelijkheid moet wegnemen. Canonicalisatie is voor pagina's die plausibel geïndexeerd zouden kunnen worden; een korte link was daar nooit kandidaat voor.
De canonical tag die ertoe doet, hoort op de bestemmingspagina, precies alsof de bezoeker via elke andere route was aangekomen. Stuurt elido.app/summer-sale mensen naar yoursite.com/sale?utm_source=twitter, dan is het canonical-werk nog steeds het geval van de URL met campagnetags van eerder, niet anders dan bij elke campagnelink die je op dezelfde manier zou taggen. Dat gebeurt op yoursite.com/sale, niet op de korte link. Dezelfde korte link vertakken naar verschillende bestemmingen per campagne of regio verandert het antwoord niet: smart links routeren de klik, maar het canonical-werk vindt nog steeds plaats waar de bezoeker landt. De juistheidsvraag van de redirect zelf wordt behandeld in 301 vs 302 redirects en hoe je een URL redirect.
Dat is waarom de SEO-angst rond verkorte links grotendeels ongegrond is zodra de twee signalen gescheiden blijven: de redirect draagt zijn eigen signaal over, de canonical van de bestemming regelt de zijne, en geen van beide besmet de ander. Zijn URL-verkorters slecht voor SEO behandelt de rest van die vraag.
Hoe je controleert welk signaal een pagina daadwerkelijk verstuurt
Ga er niet vanuit. Controleer beide signalen rechtstreeks, te beginnen met de redirect:
curl -sI "https://example.com/old-page"
Een 301 met een Location-header betekent dat de URL definitief weg is; geen 3xx-status betekent dat er geen redirect is, en dan is een eventuele canonical tag het enige signaal dat meespeelt. Om de canonical tag zelf te zien, haal je de pagina op en doorzoek je de bron:
curl -s "https://example.com/page" | grep -i 'rel="canonical"'
Verstuurt een URL beide, trek dan de hele keten na voordat je aanneemt welke de echte bestemming is. Als de twee overeenkomen - de redirect landt op een URL waarvan de canonical naar zichzelf wijst - is het signaal ondubbelzinnig, en dat is de toestand waarin elke URL die voor je rankings telt, zou moeten verkeren.
Gerelateerd op de blog
Veelgestelde vragen
Wat is het verschil tussen een canonical tag en een 301-redirect?
Een canonical tag is een hint in de head van een pagina die zoekmachines vertelt welke URL de voorkeur heeft, terwijl beide live en bereikbaar blijven; een 301-redirect is een HTTP-statuscode die elke bezoeker en crawler naar de nieuwe URL stuurt en de oude uit dienst neemt. Google behandelt een canonical als een sterk signaal dat het kan overrulen als ander bewijs tegenspreekt, terwijl een redirect geen alternatief overlaat om af te wegen, omdat er geen oude pagina meer over is om te heroverwegen. Gebruik een canonical wanneer beide URL's verzoeken moeten blijven beantwoorden; gebruik een redirect wanneer er nog maar één zou moeten bestaan.
Moet ik een canonical tag of een 301-redirect gebruiken voor duplicate content?
Gebruik een redirect als de dubbele URL helemaal moet ophouden te bestaan - een uitgefaseerde pagina, een oud domein, een permanente verhuizing - omdat een redirect zowel het rankingsignaal bundelt als de dode URL uit omloop haalt. Gebruik een canonical tag als het duplicaat om een echte reden bereikbaar moet blijven, zoals een UTM-getagde campagnelink, een sessieparameter, of een bijna-identieke gefilterde pagina. De doorslaggevende vraag is of een mens een legitieme reden heeft om de URL te blijven bezoeken die je niet als canonical kiest.
Wat gebeurt er als een canonical tag en een redirect elkaar tegenspreken?
De redirect wint, omdat die de alternatieve URL al uit de vergelijking heeft gehaald - er is op dat punt in de keten niets meer over waarmee een canonical tag in tegenspraak kan zijn. Google volgt eerst de redirect naar zijn bestemming en leest daarna welke canonical tag die bestemming zelf als het geldende signaal opgeeft. De oplossing voor een mismatch is elke hop natrekken tot je landt op een URL die 200 teruggeeft en naar zichzelf canonicaliseert.
Hebben URL's met UTM-parameters een canonical tag nodig?
Ja, de canonical tag hoort op de bestemmingspagina en moet naar de schone URL wijzen, zonder de trackingparameters. Een pagina als /pricing moet zichzelf als eigen canonical opgeven, ongeacht hoeveel UTM-getagde varianten ernaar doorlinken, zodat zoekmachines één schone URL indexeren terwijl analytics elke getagde variant apart blijft registreren. Een UTM-getagde URL in plaats daarvan redirecten zou de parameters verwijderen voordat je analyticstool het bezoek kan toeschrijven.
Waarom een zelfverwijzende canonical tag op elke pagina zetten?
Een zelfverwijzende canonical tag - een pagina die zichzelf opgeeft als haar eigen voorkeurs-URL - sluit elke onbedoelde manier af waarop een pagina gedupliceerd kan raken, van trailing slashes tot losse queryparameters tot een blijvende http-versie naast https. Zonder zo'n tag kiest Google de canonical URL op basis van zijn eigen signalen, wat meestal klopt maar af en toe de verkeerde variant oplevert. Hem expliciet instellen op elke indexeerbare pagina neemt die onduidelijkheid gratis weg.
Heeft een korte link een canonical tag nodig?
Nee. Een korte link is een pure HTTP-redirect zonder eigen inhoud, dus er staat niets op die URL waarvoor een canonical tag onduidelijkheid moet wegnemen, en canonicalisatie is alleen relevant voor pagina's die plausibel als content geïndexeerd zouden kunnen worden. De canonical tag die ertoe doet, staat op de bestemmingspagina waar de korte link naartoe redirect, precies zoals wanneer een bezoeker via elke andere route was aangekomen.
Probeer Elido
Plak een URL, krijg een werkende korte link
Geen aanmelding nodig. Link blijft 30 dagen actief. Meld je aan om hem voor altijd te bewaren.
Gratis, geen aanmelding nodig · 2 per dag