Bepaal of de URL's daadwerkelijk duplicaten zijn
Een canonical-URL is het representatieve adres voor dubbele of bijna-dubbele pagina's. De canonical link-relatie is geschikt wanneer het doel duplicaatinhoud bevat of een superset is van de inhoud van de verwijzende pagina. Het is geen manier om verschillende producten, nuttige filters, artikelen of lokalisaties te verbergen.
Vraag uzelf af of een bezoeker belangrijke inhoud, keuzevrijheid of de mogelijkheid een taak te voltooien zou verliezen als deze URL door de kandidaat-URL zou worden voorgesteld. Als dat zo is, houd die URL dan onderscheiden en verbeter de inhoud of lokalisatie. Als dat niet zo is, kies één stabiele URL en documenteer de protocol-, host-, pad-, trailing-slash- en parameterregels.
Voeg een naar zichzelf verwijzende rel=canonical toe aan elke voorkeurs-indexeerbare HTML-pagina, ook als er vandaag geen duplicaat duidelijk is.
Verwijs een noodzakelijk duplicaat, zoals een route met analytics-parameter, naar de voorkeurs-URL alleen als beide pagina's dezelfde hoofdinhoud retourneren.
Gebruik een redirect wanneer de oude URL moet verdwijnen
Gebruik een permanente server-side redirect wanneer een oud pad, een gepensioneerde host of een HTTP-versie geen bestemming meer mag zijn voor bezoekers of crawlers. Google beschouwt redirects als een sterk canonisatie-signaal en raadt ze aan bij het afschrijven van een duplicaat.
Gebruik rel=canonical wanneer beide URL's inhoud moeten teruggeven maar één de cluster in zoekresultaten moet vertegenwoordigen. De tag verandert het adres van de bezoeker niet en verwijdert de andere route niet. Het target moet succesvol bereikbaar zijn en mag niet zelf redirecten of elders canonicaliseren.
Stuur een verouderde HTTP-URL rechtstreeks naar de uiteindelijke HTTPS-URL en gebruik die HTTPS-URL overal elders.
Robots.txt, URL-verwijderingen en noindex drukken geen voorkeur voor een duplicaat uit. Noindex blokkeert juist een pagina voor Search.
Publiceer één eenduidige annotatie
Voor HTML zet u één absolute rel=canonical-annotatie in de head. Controleer de geleverde bron, niet alleen de CMS-instelling: een thema, plugin, edge-regel of JavaScript kan de waarde vervangen. Google adviseert deze in de HTML-bron te plaatsen en te verzekeren dat JavaScript het niet wijzigt.
Voor een niet-HTML-document zoals een PDF gebruikt u waar passend een canonical Link HTTP-responseheader. Vermijd conflicterende HTML- en headerwaarden. Het doel moet toegankelijk zijn, mag geen 4xx-respons geven en mag geen redirect of keten-URL zijn.
Publiceer één canonical-doel per resource; meerdere doelen maken de voorkeur onduidelijk.
Haal voorbeeldpagina's en headers op na template-, CDN-, CMS- of routingwijzigingen en bevestig het uiteindelijke doel.
Laat ondersteunende signalen overeenkomen
Link intern naar de voorkeurs-URL in navigatie, breadcrumbs, body-links en gegenereerde feeds. Zet alleen URL's die u in zoekresultaten wilt zien in de sitemap. Sitemapvermeldingen zijn een zwakker signaal, maar versterken de keuze wanneer ze overeenkomen met redirects en annotaties.
Genereer volledig gekwalificeerde sitemap-URL's met dezelfde host, protocol en slash-stijl als de canonical. Verwijder doorgestuurde en geparameteriseerde duplicaten. Test automatisch gegenereerde sitemaps na wijzigingen in permalinks, domein, taal of e‑commerce.
Vervang links naar getrackte, legacy- of alternate-host-URL's door de geselecteerde canonical.
Houd HTTPS-redirects, canonical-targets, sitemaps en links consistent; certificaat- en HTTPS‑naar‑HTTP-fouten sturen conflicterende signalen.
Behandel parameters, paginering en talen naar doel
Parameters zijn niet automatisch duplicaten. Analytics-parameters laten de inhoud vaak ongewijzigd, terwijl filters en sortering het resultaat kunnen veranderen. Test representatieve combinaties. Behoud elke parameter die nodig is voor winkelwagen, login, consent of configuratie; een canonical mag geen bezoekersstroom breken.
Canonicaliseer niet elke gepagineerde pagina naar pagina één: latere pagina's bevatten meestal inhoud die pagina één niet heeft. Voor taal- of land-URL's benoem de gelijktaalpagina als canonical wanneer die bestaat en gebruik hreflang voor alternatieven. Canonicalisering is geen vervanging voor lokalisatieontwerp.
Documenteer welke filters aparte landingspagina's zijn en welke duplicaten of herschikkingen zijn, zodat product- en engineeringwijzigingen op één lijn blijven.
Gebruik een 'view-all' alleen wanneer deze een bruikbare inhoudssuperset is; test de laadtijd en navigatie vóór selectie.
Onderzoek conflicten tussen geïndexeerd en live bewijs
Inspecteer in Search Console de betrokken URL en vergelijk de door Google geselecteerde geïndexeerde canonical met de door de gebruiker gedeclareerde waarde. Inspecteer ook het kandidaat-doel. Het geïndexeerde rapport weerspiegelt wat Google het laatst heeft verwerkt; een live test is nuttig voor de huidige fetch, de gerenderde pagina, headers en resources, maar kan de uiteindelijke canonicalkeuze niet voorspellen.
Als waarden verschillen, overweeg of Google de betere representant heeft gekozen. Zo niet, traceer redirects, HTML- en HTTP-headerannotaties, gerenderde output, links, sitemapvermeldingen, hreflang en inhoudsvergelijkbaarheid. Repareer de onenigheid, registreer de wijziging en geef tijd voor herbeoordeling.
Controleer templates, headers, host-routing en beveiligingswijzigingen. Een onverklaarde cross‑domain canonical of redirect vereist een beveiligingsonderzoek.
Vergelijk geleverde bron en headers met CMS-instellingen; een plugin of platformregel kan een andere waarde uitgeven.
Voeg canonical-controles toe aan SIU release-hardening
Voor releases die domein, HTTPS, CDN, CMS, template of catalogus beïnvloeden, neem steekproeven van de homepage, content- en productpagina's, een parameterroute, een locale, een legacy-URL en gepubliceerde documenten. Leg status, uiteindelijke URL, canonical-target, sitemapopname en een voorbeeld van een interne link vast.
Houd fixes omkeerbaar: leg de huidige mapping vast, wijzig één regelsset, verifieer de getroffen routes en behoud een rollback-plan. Dit ondersteunt proactieve uptime-optimalisatie door stabiele publieke paden tijdens wijzigingen te beschermen; het detecteert geen uitval en garandeert geen indexering.
Wijs canonicalregels toe over marketing en engineering en log achter elke update de template-, redirect-, sitemap- of platformwijziging.
Voeg een klein voor-en-na URL- en headersample aan het releaseticket toe voor snellere remedie.