Canonical instellen: kies de juiste URL voor dubbele pagina’s

Een canonical instellen is zinvol wanneer meerdere URL’s dezelfde of vrijwel dezelfde inhoud tonen en je één voorkeurs-URL wilt aanwijzen. Controleer eerst of de pagina’s werkelijk dubbel zijn. Kies daarna de passende oplossing en controleer wat je website daadwerkelijk aan bezoekers en zoekmachines levert.

Een canonical geeft een voorkeur aan, geen opdracht

Een canonical verwijst naar de URL die jij als hoofdversie van een pagina beschouwt. Denk aan een productpagina die zowel via een schoon adres als via een nieuwsbriefkoppeling met trackingparameters bereikbaar is. De adressen verschillen, terwijl bezoekers hetzelfde product zien. Met een canonical geef je een voorkeurs-URL door.

Voor Google is dit een signaal. Google beoordeelt ook andere aanwijzingen en kan een andere URL selecteren. Een canonical is daarom geen gegarandeerde rankingoplossing en zorgt niet automatisch dat de opgegeven pagina in zoekresultaten verschijnt.

Normale duplicatie is op zichzelf geen spamovertreding. Een webshop kan vanzelf varianten produceren door campagnes, navigatie en sortering. De praktische vraag is welke URL bij een zoekopdracht moet kunnen verschijnen en of de andere adressen een zelfstandige functie hebben. Google beschrijft dit proces in de uitleg over canonicalisatie.

Vergelijk de inhoud voordat je URL’s samenvoegt

Begin met een kleine groep verdachte URL’s. Open ze naast elkaar en vergelijk de hoofdinhoud: product, uitvoering, beschikbaar aanbod, tekst en doel van de pagina. Alleen dezelfde header, footer of introductie maakt twee pagina’s nog niet dubbel.

Een bureaulamp en een vloerlamp zijn verschillende producten, ook wanneer hun beschrijvingen grotendeels overeenkomen. Een dienstenpagina voor installatie kan iets anders beantwoorden dan een pagina over onderhoud. Een canonical naar één gezamenlijke pagina kan daar een ongeschikte voorkeur communiceren.

Beoordeel ook filters afzonderlijk. Een categorie met alleen dimbare lampen kan een bruikbare landingspagina zijn als het assortiment en de zoekvraag duidelijk verschillen. Dat betekent niet dat iedere filtercombinatie een indexeerbare pagina verdient. Gebruik zoekwoordenonderzoek om de vraag te beoordelen en leg de gewenste landingspagina’s vast in je SEO-strategie.

Beslismatrix: canonical, 301 of noindex kiezen

Een canonical benoemt een voorkeur tussen equivalente pagina’s. Een 301 stuurt bezoekers en zoekmachines door naar een blijvende vervanging. Noindex vraagt om een pagina buiten de zoekindex te houden; het benoemt geen vervangende hoofdversie. Kies vanuit het doel van de URL, niet vanuit de beschikbaarheid van een instelling.

Gebruik noindex niet als vervanging voor het kiezen van een canonical. Andersom is een canonical geen betrouwbaar instrument om een unieke pagina uit zoekresultaten te verwijderen. Voor een omvangrijke webshop hoort deze afweging bij e-commerce SEO, omdat filters, voorraad en categorienavigatie samenhangen.

Paginatie vraagt om een afzonderlijke controle

Pagina twee van een categorie bevat meestal andere producten dan pagina één. Daarmee is het geen kopie die je blind naar de eerste pagina moet canonicaliseren. Google adviseert eigen URL’s en eigen canonicals voor de pagina’s in een reeks in de documentatie over paginatie.

Combineer je paginatie met sortering, dan wordt vergelijken belangrijker. De goedkoopste producten kunnen op de eerste gesorteerde pagina staan, terwijl ze in de standaardvolgorde verspreid zijn over meerdere pagina’s. Eén algemene regel voor alle sorteerparameters kan dan ongeschikt zijn. Bekijk de daadwerkelijk getoonde sets voordat je een regel uitrolt.

Leg de voorkeurs-URL vast voordat je iets configureert

Kies een stabiel adres dat de bedoelde inhoud rechtstreeks toont. Controleer het protocol, de host, het pad en eventuele noodzakelijke parameters. Het doel hoort normaal te antwoorden met HTTP 200, indexeerbaar te zijn en inhoudelijk overeen te komen met de variant.

Leg per groep vast waarom juist deze URL de voorkeur krijgt. Bijvoorbeeld: het adres zonder campagneparameter staat al in de navigatie en is bedoeld als blijvende productpagina. Een korte URL is niet automatisch beter als die naar de verkeerde categorie of een andere uitvoering verwijst.

Bij veel onduidelijke varianten helpt een SEO-audit om eerst de omvang en oorzaken te bepalen. Laat de inventarisatie onderscheid maken tussen echte kopieën, verplaatste pagina’s en zelfstandige landingspagina’s. Daarmee krijgt de uitvoerder een concrete opdracht.

Canonical instellen in HTML en WordPress

Voor een HTML-pagina plaats je de canonicalverwijzing in de head. Gebruik een absolute URL: het volledige adres inclusief protocol en host. Onderstaand fictieve voorbeeld hoort bij een productpagina voor de bureaulamp Maan. Zowel de schone pagina als een equivalente campagnevariant kunnen naar dit adres verwijzen.

<head>
  <title>Bureaulamp Maan</title>
  <link rel="canonical" href="https://winkel.example/product/bureaulamp-maan/">
</head>

Een verwijzing van een pagina naar zichzelf heet een selfcanonical. Die kan een consistente voorkeur vastleggen en helpen voorkomen dat onbedoelde adresvarianten als hoofdversie worden opgevat. Het is geen universele verplichting voor indexatie.

Controleer in WordPress eerst wie de canonical genereert. Dat kan een SEO-plugin zijn, maar ook het thema of aanvullende code. Laat bij voorkeur één onderdeel verantwoordelijk zijn voor de HTML-canonical. Als een plugin en het thema ieder een tag toevoegen, kan een wijziging in één instelling een tegenstrijdige tweede tag laten staan.

Controleer vervolgens de echte actieve versie: het gepubliceerde thema, de gebruikte paginatemplate en de uitvoer na eventuele caching. Een correcte instelling in de beheeromgeving bewijst nog niet dat de openbare pagina dezelfde waarde levert. Ook een SEO-plugin geeft geen garantie dat maatwerkfilters of aangepaste producttemplates automatisch goed worden afgehandeld.

Laat sitemap, interne links en taalverwijzingen overeenkomen

Gebruik de gekozen voorkeurs-URL waar je die keuze zelf beheert. Laat productkaarten, categorieoverzichten en tekstlinks naar dat adres verwijzen. Neem in de sitemap de bedoelde indexeerbare hoofdversies op. Zo voorkom je dat je sitemap een ander adres benadrukt dan je canonical.

Redirects en canonicals zijn volgens Google sterke voorkeurssignalen; sitemapopname is een zwakker signaal. Ze kunnen elkaar ondersteunen, maar garanderen de Google-keuze niet. Zie de documentatie over het consolideren van dubbele URL’s.

Een canonical en een redirect zijn niet universeel een verboden combinatie. Een oud productadres kan met een 301 naar de huidige productpagina verwijzen, terwijl die huidige pagina een selfcanonical bevat. Vermijd wel onnodige omwegen: laat canonicals bij voorkeur rechtstreeks naar de bedoelde eindbestemming wijzen.

Gebruik hreflang alleen voor echte taal- of regiovarianten. Een Nederlandse productpagina hoort niet naar de Engelse vertaling te canonicaliseren uitsluitend omdat beide hetzelfde product beschrijven. Beoordeel de voorkeursversie binnen de passende taal en houd de taalverwijzingen daarmee in lijn. Controleer bij dit werk ook je interne links, zodat navigatie en taalkeuze geen concurrerende adressen blijven verspreiden.

URL-controleblad: leg de hele route vast

Gebruik dit werkblad voor iedere onderzochte variant. Maak eerst een nulmeting en vul dezelfde velden na de wijziging opnieuw in. Bewaar de controledatum, zodat je een oudere Google-waarneming niet verwart met de huidige website-uitvoer.

Vul onbekende velden in als onbekend. Een niet-beschikbare Google-geselecteerde canonical is geen bewijs dat Google je voorkeur heeft overgenomen of afgewezen. Dit werkblad vormt ook een bruikbare opleverlijst voor een specialist in technische SEO.

Foutanalyse: zoek eerst waar de signalen uiteenlopen

Dubbele tags of een verkeerde template

Zoek in de ontvangen HTML naar canonicalverwijzingen en tel ze. Bekijk daarnaast eventuele canonicalinformatie in de HTTP-headers. Twee verschillende doelen vragen om onderzoek naar de bron: plugin, thema, maatwerk of infrastructuur. Voeg geen derde tag toe als oplossing.

Staat op iedere productpagina de homepage als canonical, controleer dan de gebruikte template en de manier waarop het productadres wordt opgebouwd. Test vervolgens meerdere producten. Een juiste waarde op één handmatig aangepaste pagina bewijst niet dat de algemene template is hersteld.

Het canonicaldoel redirect, bevat noindex of geeft 404

Vraag het canonicaldoel zelf op. Een verwijzing naar een 404 wijst geen bruikbare hoofdversie aan. Een doel met noindex past niet bij de bedoeling om juist dat adres als indexeerbare hoofdversie te gebruiken. Een redirectdoel kan een onnodige tussenstap zijn die je rechtstreeks kunt overslaan.

Herstel de oorzaak voordat je alleen de tag wijzigt. Misschien is het product echt verplaatst, is een slug aangepast of is een uitsluitingsregel onbedoeld op een hele categorie toegepast. Controleer daarna opnieuw het doelantwoord én de inhoud.

JavaScript verandert de canonical na het laden

Vergelijk de ontvangen HTML met de uiteindelijke DOM in de browser. JavaScript kan na het laden een tag toevoegen of de bestemming veranderen. Daardoor kan de broncode correct lijken, terwijl de gerenderde pagina een andere voorkeur aangeeft.

Controleer ook of sorteren of filteren zonder volledige paginaverversing de canonical wijzigt. Laat de uitvoerder vastleggen welke component daarvoor verantwoordelijk is. Herstel tegenstrijdige uitvoer bij de bron en controleer daarna een schone nieuwe paginalading en de relevante gebruikershandeling.

Fictief voorbeeld: een kleine categorie met productsortering

Een fictieve lampenwinkel heeft een categorie met achttien bureaulampen. Alle achttien passen op één pagina. Er zijn drie bereikbare weergaven: standaard, prijs oplopend en prijs aflopend. Iedere weergave kan bovendien via twee campagnecodes worden geopend.

De inventarisatie telt daarmee drie weergaven maal drie campagnevarianten: zonder campagnecode, met code A en met code B. Dat zijn negen URL’s voor dezelfde achttien producten. Dit is uitsluitend een doorgerekend inventarisatievoorbeeld, geen voorspelling van verkeer of SEO-resultaten.

De eigenaar vergelijkt de negen versies. De producten en categorietekst blijken gelijk; alleen de volgorde en meetcode verschillen. Hij kiest het categorieadres zonder parameters als voorkeurs-URL. De sorteerfuncties blijven voor bezoekers beschikbaar. De acht overige varianten krijgen een canonical naar de standaardcategorie; die categorie krijgt een selfcanonical.

De beheerder past de verantwoordelijke uitvoer aan en laat de categoriekaarten en sitemap naar het standaardadres verwijzen. De controleur onderzoekt alle negen URL’s opnieuw op status, canonical en doelantwoord. Daarna controleert hij een andere categorie als steekproef op onbedoelde wijzigingen.

Deze keuze moet opnieuw worden beoordeeld zodra de categorie bijvoorbeeld over meerdere pagina’s wordt verdeeld of een filter een inhoudelijk eigen selectie oplevert. De onderbouwing geldt voor de vastgestelde situatie, niet automatisch voor iedere toekomstige URL met parameters.

Spreek startpunt, verantwoordelijke en validatie af

1. Eigenaar bepaalt de bedoeling. Noteer welke varianten bereikbaar moeten blijven en welke pagina’s zelfstandig vindbaar moeten kunnen zijn.
2. Analist legt de beginsituatie vast. Vul het controleblad in en selecteer voorbeelden uit iedere betrokken template.
3. Beheerder voert de gekozen regel uit. Pas het verantwoordelijke onderdeel aan en verwerk bijbehorende links, sitemapverwijzingen of redirects.
4. Controleur beoordeelt de openbare uitvoer. Test bron-HTML, gerenderde versie, HTTP-statussen en canonicaldoelen na publicatie.
5. SEO-verantwoordelijke volgt Google-waarnemingen. Vergelijk later de beschikbare indexeringsgegevens met de technische controle.

In Search Console kun je met URL-inspectie onderzoeken welke canonical Google heeft geselecteerd, voor zover die informatie beschikbaar is. Maak onderscheid tussen gegevens van de geïndexeerde versie en een live test. Een geslaagde live test bevestigt niet dat Google de nieuwe voorkeurs-URL al heeft verwerkt of zal selecteren.

Rapporten zijn geen directe weergave van iedere zojuist gewijzigde pagina. Leg daarom de wijzigingsdatum vast en beoordeel crawlgegevens voordat je conclusies trekt. Neem openstaande afwijkingen op in je SEO-rapportage, met een concrete vervolgactie in plaats van alleen een totaal aantal meldingen.

Inventariseer protocol, host en productpad afzonderlijk

Neem als fictief geval een leverancier van verrijdbare documentstandaards. Deze leverancier, de producten en alle beschreven uitkomsten zijn verzonnen. Werkelijke infrastructuurmetingen en door Google geselecteerde adressen zijn onbekend. Het voorbeeld gebruikt vier productpaden: /documentstandaard/atlas, /documentstandaard/bries, /documentstandaard/cirkel en /documentstandaard/delta. De namen onderscheiden producten; ze zeggen niets over bestaande merken, maten of voorraad.

Onderzoek voor ieder pad HTTP en HTTPS, de host standaards.example en www.standaards.example, en het pad met en zonder afsluitende slash. Vier paden met telkens twee protocolkeuzes, twee hostkeuzes en twee slashkeuzes leveren 32 te onderzoeken adrescombinaties op. Dat zijn geen 32 unieke producten. Deze berekening bewijst evenmin dat je alle bereikbare adressen hebt gevonden.

Vul per aangevraagd adres een eigen inspectieregel in

Gebruik onderstaande velden voor elke combinatie. Neem het oorspronkelijk aangevraagde adres over voordat je de pagina opent. Het adres dat daarna in de browser staat, kan al het resultaat van een omleiding zijn. Bewaar daarom beide waarden, ook wanneer ze op het eerste gezicht hetzelfde lijken.

• Productpad: [pad]. Aangevraagde URL inclusief protocol, host en slash: [volledig adres].
• Inspectiedatum en tijd: [moment]. Controleur: [naam]. Gebruikte aanvraag of bewijsbestand: [verwijzing].
• Eerste antwoord: [status of onbekend]. Opeenvolgende omleidingen: [adressen en statussen of niet waargenomen].
• Eindadres: [volledige URL]. Antwoord op dat adres: [status]. Getoond product: [naam en onderscheidende inhoud].
• Aangegeven voorkeur: [absolute URL of niet gevonden]. Gevonden in: [HTML, header, DOM of onbekend].
• Vergelijkingsadres: [URL]. Inhoudelijke overeenkomst: [bevinding]. Besluit en eigenaar: [actie en naam].

Drie fictieve uitkomsten vragen om verschillende besluiten. Atlas toont op twee adressen dezelfde productinformatie met een antwoordstatus 200. Dat is een kandidaat voor één voorkeur, nadat ook het doel is gecontroleerd. De HTTP-route van Bries verwijst blijvend door naar de gekozen HTTPS-pagina. Hier beoordeel je de omleiding en de eindpagina, niet een vermeende tweede productkopie.

Bij Cirkel verschijnt op een hostvariant onverwacht Delta. Verander dan geen bestaande canonicalinstelling om de inventaris netjes te laten lijken. Laat eerst onderzoeken waarom een ander product verschijnt. Noteer de inhoudelijke afwijking bij precies deze route en wijs een verantwoordelijke aan. Alle 32 adressen automatisch naar vier vooraf bedachte canonicals laten wijzen zou dit defect verbergen.

Maak bij de inventaris ook onderscheid tussen een ontbrekend antwoord en een vastgestelde foutstatus. Wanneer een aanvraag niet lukt, noteer je de waargenomen blokkade en blijft het serverantwoord onbekend. Kies HTTPS niet alleen op basis van de schrijfwijze van het adres: controleer of de bedoelde route bereikbaar is en geen certificaatprobleem of tegenstrijdige omleiding vertoont. Laat een gevonden protocolprobleem door de infrastructuurbeheerder onderzoeken. Een canonicalwijziging lost zo’n bereikbaarheidsprobleem niet vanzelf op. Beperk het voorstel tot het geconstateerde defect; een bredere beveiligingswijziging vraagt een eigen uitvoeringsscope.

Bepaal de slashkeuze vanuit de werkelijke routes

Neem het fictieve Atlas-pad zonder slash en met slash als apart onderzoek. Vraag beide adressen rechtstreeks op en noteer of ze inhoud leveren, doorverwijzen of ontbreken. Gebruik hiervoor geen conclusie uit alleen de adresbalk. Die laat na een redirect mogelijk uitsluitend de bestemming zien. Je wilt weten wat iedere aangevraagde variant doet.

Maak vervolgens onderscheid tussen een productpad, een bestand en een regel van het CMS. Een productpad kan door de website worden afgehandeld zonder een fysieke map te zijn. Een downloadadres kan juist een bestand aanwijzen. Neem daarom de slashkeuze voor productpagina’s niet automatisch over voor PDF-adressen of andere bestanden. Laat de beheerder vaststellen welke regel het onderzochte pad behandelt.

Leg de voorkeur vast en test een andere template

Stel dat de fictieve producttemplate adressen met slash gebruikt en de versie zonder slash blijvend doorstuurt. Dan kan de afspraak voor deze productpaden luiden: productlinks, sitemapvermeldingen en canonicaldoelen gebruiken het volledige adres met slash. De reden is een consistente route binnen deze inrichting. Een slash is op zichzelf niet algemeen beter of slechter.

1. Noteer de gekozen vorm: [productpad met of zonder slash]. Onderbouwing: [bestaande route en gewenste bestemming].
2. Controleer een productkaart en een inhoudelijke productlink. Bewaar hun werkelijke bestemmingen: [adressen].
3. Vergelijk de sitemapvermelding met het canonicaldoel van hetzelfde product. Noteer verschillen letterlijk: [waarden].
4. Vraag beide slashvarianten opnieuw op. Leg de eerste antwoorden en het eindadres vast: [bewijs].
5. Test een pagina uit een andere template, bijvoorbeeld de handleiding. Noteer of daarvoor dezelfde afspraak geldt: [ja, nee of onbekend].

Zie je een keten waarin eerst de host en daarna de slash verandert, leg dan iedere stap vast. Onderzoek of de verantwoordelijke regels rechtstreeks naar de bedoelde bestemming kunnen verwijzen. Er geldt hier geen voorgeschreven aantal toegestane stappen. Een waargenomen lus, waarbij adressen elkaar blijven doorsturen, vraagt eerst herstel van de elkaar tegensprekende routeregels.

Controleer bij zo’n herstel opnieuw het oorspronkelijke startadres. Alleen de eindpagina openen test de defecte route niet. Bewaar bovendien een route die al goed werkte als tegenproef. Daarmee kun je vaststellen of een bredere slashregel onbedoeld een ander paginatype raakt. Eén handmatig hersteld product vormt geen bewijs dat alle productpaden of templates dezelfde juiste uitvoer hebben.

Neem in de slashafspraak ook een concrete uitzondering op wanneer die bestaat. Bijvoorbeeld: de producttemplate gebruikt afsluitende slashes, terwijl het downloadpad de bestandsnaam behoudt. Laat de controleur beide routes opnemen in hetzelfde ticket, met hun verschillende verwachte antwoorden. Zo kan een algemene regel niet ongemerkt worden goedgekeurd doordat alleen productpagina’s zijn getest. Wordt tijdens de proef een pad gevonden dat nog nergens is vastgelegd, voeg dat toe als nieuwe onderzoeksvraag. Pas de gekozen voorkeur niet stilzwijgend aan om die ene route passend te maken.

Test wat een parameter voor de bezoeker bewaart

Onderzoek een parameter via de handeling die hem oplevert. Kies bij de fictieve leverancier een uitvoering van Atlas, kopieer het volledige adres en noteer welke selectie zichtbaar is. Open dat adres daarna rechtstreeks in een nieuwe browsersessie en ververs de pagina. Vergelijk de geselecteerde uitvoering en de hoofdinhoud na iedere stap.

Een bruikbaar verslag noemt niet alleen dat twee pagina’s er hetzelfde uitzien. Noteer de productnaam, geselecteerde maat wanneer aanwezig, taal, aangeboden uitvoering en relevante beschrijving. Als de oorspronkelijke sessie een keuze onthoudt maar de gedeelde URL die keuze verliest, heb je nog geen betrouwbare basis om de parameter als overbodig te behandelen.

• Adres na selectie: [exacte URL]. Gekozen optie: [zichtbare waarde]. Hoofdinhoud op dat moment: [waarneming].
• Gedeeld adres: [exacte URL]. Rechtstreeks geopend door: [controleur]. Zichtbare selectie: [waarde].
• Na verversen: [selectie en inhoud]. Verschil met de oorspronkelijke pagina: [bevinding of geen verschil].
• Adres zonder onderzochte parameter: [URL]. Verloren functie of gewijzigde inhoud: [bevinding of onbekend].

Verander tijdens deze vergelijking telkens één onderdeel. Parameters alfabetisch ordenen, tekens decoderen of de hele query verwijderen kan de onderzochte route veranderen. Bewaar eerst het exacte adres zoals de website dat maakte. Vergelijk de functie voordat je een schonere schrijfwijze als gelijkwaardig beschouwt. Ook een schijnbaar technische waarde kan nodig zijn om de bedoelde selectie te openen.

Scheid campagneroutes van inhoudelijke productkeuzes

In een fictieve proef openen twee verschillende campagnecodes dezelfde Atlas-uitvoering. Na delen, rechtstreeks openen en verversen blijven productinformatie en aanbod gelijk. Dan kunnen beide campagneroutes bij dezelfde voorkeursversie horen. Leg wel vast welke codes je hebt onderzocht; daarmee is niet bewezen dat iedere toekomstige parameter hetzelfde doet.

Een andere route opent een afzonderlijke maat, taal of aanbieding. Daarvoor blijft een eigen inhoudelijk besluit nodig. Noteer welk verschil de bezoeker nodig heeft om te kiezen. Als de selectie zelfstandig moet kunnen worden gedeeld, moet de gekozen technische oplossing die gebruikstaak behouden. Laat de productverantwoordelijke dat controleren voordat een algemene parameterregel wordt aangepast.

Een externe verkorte link hoort eveneens als route in het verslag. Open hem en registreer de bestemming, maar leid daaruit geen servercanonical af. De verkorter kan naar een campagneadres sturen terwijl de productserver een andere voorkeur aangeeft. Je onderzoekt beide stappen afzonderlijk. De zichtbare korte link bewijst alleen welk vertrekpunt je hebt gebruikt.

Laat bij een verschil tussen sessies expliciet vastleggen welke omstandigheden afwijken. Was de bezoeker ingelogd, stond er al een selectie opgeslagen of werd een optie pas na laden toegepast? Deze vragen helpen de functie van het adres te onderscheiden van de toestand van de browser. Herhaal vervolgens dezelfde producthandeling onder vergelijkbare omstandigheden. Als je de afwijking niet kunt reproduceren, markeer je de parameterbeslissing als openstaand. Geef de uitvoerder het oorspronkelijke adres en de handelingen mee, zodat die hetzelfde gebruiksprobleem kan onderzoeken.

Maak een afzonderlijke afspraak over herpublicatie

Stel dat de fictieve leverancier een neutrale handleiding over het veilig opbergen van documenten laat herpubliceren bij een partner. De genoemde publicatie bestaat hier alleen als voorbeeld. Vergelijk de volledige gepubliceerde versies voordat je een technisch voorkeursdoel afspreekt. Een gedeelde titel of dezelfde eerste alinea is onvoldoende om de pagina’s als equivalent te behandelen.

Controleer of stappen, toelichtingen en bijlagen overeenkomen. Bekijk ook of één pagina een hulpmiddel, aanvullende gegevens of een antwoordfunctie bevat die de andere mist. Noteer wanneer beide versies voor het laatst inhoudelijk zijn bijgewerkt. Een aanvankelijk gelijke handleiding kan uiteenlopen wanneer slechts één partij correcties verwerkt.

Gebruik een voorstelblad met bekende en onbekende antwoorden

• Vraag: welke pagina’s vergelijken we? Antwoord: [eigen URL] en [partner-URL]. Nog onbekend: [ontbrekende publicatie].
• Vraag: welke publicatierechten zijn afgesproken? Antwoord: [vastgelegde afspraak en verantwoordelijke]. Nog onbekend: [te bevestigen toestemming].
• Vraag: blijft de hoofdinhoud voldoende gelijk? Antwoord: [vergelijking van tekst, hulpmiddel en gegevens]. Nog onbekend: [niet gecontroleerd onderdeel].
• Vraag: welke URL krijgt technisch de voorkeur? Antwoord: [volledig doel en reden]. Nog onbekend: [openstaand inhoudelijk besluit].
• Vraag: wie beheert de uitvoer bij de partner? Antwoord: [naam en component]. Nog onbekend: [toegang of uitvoermogelijkheid].
• Vraag: hoe controleren we latere wijzigingen? Antwoord: [wijziging die hercontrole start en eigenaar]. Nog onbekend: [afhankelijkheid].

Houd de afspraak over publicatierechten apart van de canonicalkeuze. Toestemming om tekst te gebruiken bepaalt niet automatisch welke URL technisch de voorkeur krijgt. Andersom bewijst een canonical niets over die toestemming. Het voorstelblad legt verantwoordelijkheden vast; het geeft geen juridisch oordeel over een concrete overeenkomst.

Voor herpublicatie raadt Google een canonical niet aan als bescherming tegen partnerduplicatie. Maak het uitsluitingsdoel expliciet en controleer de publiek ontvangen HTML of header. Bij andere equivalente domeinvarianten kan een voorkeursverwijzing wel passen. Een gewone bronlink helpt lezers, maar voert geen canonical of noindex uit.

Wil de partnerpagina buiten de zoekindex blijven, leg dat uitsluitingsdoel afzonderlijk vast. Daarvoor is noindex met voor de crawler bereikbare uitvoer relevant. Dat garandeert niet dat de oorspronkelijke publicatie vervolgens rangschikt. Een korte citaatpagina met eigen bespreking of een grondig aangepaste handleiding is bovendien niet automatisch equivalent. Beoordeel zulke inhoud opnieuw voordat je dezelfde afspraak toepast.

Spreek voor de fictieve samenwerking af wat er gebeurt als de partner eigen stappen toevoegt. De inhoudsverantwoordelijke vergelijkt dan opnieuw de publicaties voordat de oude voorkeur wordt voortgezet. Vermeld in het voorstel wie zo’n wijziging meldt en welke versie daarbij wordt meegestuurd. Kan de partner alleen de zichtbare tekst aanpassen, maar geen canonical of robotsuitvoer beheren, dan blijft de technische uitvoering onbevestigd. Laat het voorstel niet als uitgevoerd aftekenen op basis van een toezegging in een bericht; controleer de daadwerkelijk gepubliceerde pagina.

Controleer bestaande mobiele adressen per productpaar

Een responsive pagina gebruikt hetzelfde adres en dezelfde HTML voor verschillende schermformaten. Daarvoor hoef je geen afzonderlijke mobiele URL te maken. Heeft je website al aparte mobiele adressen, bijvoorbeeld op m.standaards.example, dan is dat een ander patroon. Het is niet automatisch fout, maar vraagt controle van de bijbehorende desktopadressen en mobiele inhoud.

Gebruik drie fictieve productparen om de verantwoordelijkheden af te bakenen. Controleer per paar bereikbaarheid, hoofdinhoud en robotsmeta. Bij equivalente versies hoort de mobiele pagina naar de bijbehorende desktopcanonical te verwijzen en de desktopversie naar de overeenkomstige mobiele alternate. Google beschrijft dit patroon in de documentatie over mobiele websites en mobile-first indexing.

Paar één: hetzelfde product op beide adressen

Atlas heeft in dit fictieve geval een desktopadres en een mobiel adres met dezelfde productinformatie. Het mogelijke defect is een ontbrekende of verkeerd gekoppelde verwijzing. De templatebeheerder controleert daarom beide richtingen. De acceptatieproef opent de twee vastgelegde adressen rechtstreeks en bevestigt dat ze hetzelfde product tonen en naar hun eigen tegenhanger verwijzen.

Noteer ook wanneer geen defect wordt gevonden. De status kan dan luiden: productpaar gecontroleerd, verwijzingen passend, hoofdinhoud equivalent. Daarmee is alleen dit paar beoordeeld. Het is geen uitspraak over alle mobiele pagina’s of over de URL die Google uiteindelijk selecteert.

Paar twee: het mobiele product verwijst naar de homepage

Bij Bries wijst de mobiele canonical in het voorbeeld naar de algemene desktophomepage. Het defect is een onjuist gekoppeld productpaar. Laat de beheerder van de adreskoppeling het overeenkomstige desktopproduct aanwijzen. De acceptatieproef controleert dat Bries naar Bries verwijst en dat een tweede product niet door dezelfde regel eveneens naar Bries wordt gestuurd.

Paar drie: de mobiele versie mist productmaten

Bij Cirkel ontbreken mobiel de productmaten die desktop wel toont. De inhoudsverantwoordelijke en templatebeheerder moeten vaststellen waar die informatie verloren gaat. Alleen de canonical aanpassen herstelt de ontbrekende inhoud niet. De acceptatieproef controleert dat je de relevante maten ook via het mobiele adres kunt raadplegen en hetzelfde product kunt beoordelen.

Bewaar taalcontrole als afzonderlijk onderdeel van ieder paar. Een Nederlandse mobiele pagina hoort niet per ongeluk bij de Engelse desktopversie terecht te komen. Vergelijk eerst binnen dezelfde taal en onderzoek taalverwijzingen daarna apart. Deze controle vraagt geen nieuw mobiel domein of aangepast ontwerp; ze toetst de bestaande koppelingen en de informatie die bezoekers daadwerkelijk krijgen.

Test de mobiele URL daarnaast als zelfstandig vertrekpunt. Een bezoeker die rechtstreeks bij Cirkel binnenkomt, moet de bedoelde productinformatie kunnen bereiken zonder eerst via de desktophomepage te gaan. Bewaar daarom voor de acceptatie zowel het aangevraagde mobiele adres als eventuele doorverwijzingen. Wanneer een route naar een ander product springt, is dat een apart defect naast ontbrekende maten. Geef beide bevindingen een eigen eigenaar als verschillende componenten verantwoordelijk zijn. Zo kan de inhoud worden hersteld terwijl een onjuiste routeregel nog zichtbaar openstaat.

Vergelijk een download met de HTML-handleiding

De fictieve leverancier biedt een handleiding als webpagina en als PDF aan. Open beide publicaties en vergelijk de daadwerkelijke hoofdinhoud. Controleer versiedatum, stappen, afbeeldingen met noodzakelijke uitleg en eventuele bijlagen. Een bestand met dezelfde titel kan een oudere instructie of een uitgebreidere uitvoering bevatten. Leg zulke verschillen vast voordat je een voorkeur voorstelt.

Beschrijf ook de downloadtaak: [wat moet de bezoeker kunnen bewaren of afdrukken]. Als de PDF nodig blijft, moet je acceptatieproef controleren dat downloaden nog werkt. Een voorkeur aangeven verplicht je niet om het bestand weg te halen of iedere PDF naar HTML om te leiden.

Controleer de header van het bestand zelf

Bevestig eerst welk bestandstype de server werkelijk levert en welk onderdeel de responseheaders beheert. Voor ondersteunde documenten buiten HTML is een canonical via een HTTP-Linkheader mogelijk. Dat betekent niet dat ieder bestandstype wordt ondersteund. Een HTML-tag in de inhoud van een PDF plaatsen is hiervoor geen passende uitvoering.

• HTML-versie: [URL en inhoudsversie]. PDF-versie: [URL, bestandstype en inhoudsversie].
• Inhoudelijk verschil: [bevinding]. Gewenste downloadfunctie: [handeling]. Voorgestelde voorkeur: [doel of nog geen keuze].
• Headerbron: [beheercomponent en eigenaar]. Werkelijk ontvangen header: [waarde of niet gevonden].
• Acceptatie: [bestand opent], [download werkt], [doel bereikbaar], [hoofdinhoud opnieuw vergeleken].

Het bekijken van de broncode van de HTML-handleiding vertelt je niets over de responseheader van het PDF-bestand. Vraag het bestand zelf op en bewaar daarvan het bewijs. Als een externe bestandsdienst de headers beheert, laat dan eerst bevestigen welke aanpassing mogelijk is. Beloof geen uitvoer die de verantwoordelijke partij nog niet heeft kunnen vaststellen.

Zijn beide versies voldoende gelijk, dan kan een voorkeur voor de gekozen hoofdversie worden uitgewerkt. Bevat de PDF andere instructies, pauzeer dat voorstel en laat de inhoudsverantwoordelijke beslissen of het verschil bewust is. Een verouderd bestand bijwerken is een andere taak dan een technisch voorkeursdoel instellen.

Bewaar bij de PDF-controle voldoende herkenningspunten om later hetzelfde document te vergelijken. Noteer bijvoorbeeld de zichtbare versievermelding en het onderwerp van een gewijzigde stap. Alleen de bestandsnaam is onvoldoende wanneer die bij vervanging gelijk blijft. Controleer na een bestandsupdate opnieuw de header van die downloadroute; het eerdere bewijs hoort bij de eerdere levering. Laat de beheerder bovendien bevestigen of de headerregel alleen dit bestand raakt of een bredere verzameling documenten. Die afbakening bepaalt welke extra download als tegenproef nodig is.

Wijs de regelbron aan voordat je een ticket uitvoert

Een afwijkende waarde kan ontstaan in het CMS, thema, maatwerk, infrastructuur of een opgeslagen cacheversie. Leg op een duidelijke inspectiedatum vast wat de ontvangen HTML, eventuele header en uiteindelijke DOM werkelijk bevatten. Koppel iedere afwijking aan een vermoedelijke bron, maar label die bron als onbevestigd zolang je alleen de openbare uitvoer kent.

Laat de eigenaar van de betreffende component onderzoeken waar de waarde wordt samengesteld. Wie alleen productteksten beheert, hoeft geen infrastructuurregel te wijzigen. Ontbreekt de bevoegdheid, draag het concrete onderzoek over. Daarmee blijft duidelijk wie een herstel kan uitvoeren en wie slechts het verschil heeft vastgesteld.

Controleer bij het beoogde doel ook of een fragment achter een hekje is meegekopieerd, bijvoorbeeld vanuit een verwijzing naar een instructiestap. Gebruik zo’n fragment niet als canonicaldoel. Leg het volledige paginaadres vast en behoud de sprongverwijzing alleen waar die de bezoeker helpt. Wanneer HTML en een HTTP-header allebei een voorkeur leveren, laat dan vastleggen waarom beide bronnen nodig zijn. Kies bij voorkeur één verantwoordelijke bron; twee bronnen vragen controle op onderlinge overeenstemming na iedere relevante technische wijziging.

Maak het herstelvoorstel klein en toetsbaar

• Betrokken route en template: [exact adres en type]. Inspectiedatum: [datum en tijd]. Bewijs: [vastgelegde uitvoer].
• Oude waarde: [letterlijke canonical of header]. Beoogde waarde: [volledige bestemming]. Inhoudelijke reden: [vastgestelde overeenkomst].
• Verantwoordelijke component: [naam]. Uitvoerder met bevoegdheid: [naam]. Afbakening: [welke routes worden geraakt].
• Acceptatieproef: [oorspronkelijke route], [tweede voorbeeld binnen template], [tegenproef buiten template]. Verwachte uitvoer: [waarden].
• Herstel bij ongewenst effect: [terug te zetten instelling of versie]. Verantwoordelijke: [naam]. Aanleiding voor terugzetten: [concrete afwijking].

Als een canonical naar een tussenadres verwijst, kan rechtstreeks verwijzen naar de passende eindbestemming een bruikbaar voorstel zijn. Controleer daarvoor eerst het doel en de inhoud. Koppel dit niet aan een verzonnen maximumaantal stappen of een voorspelling over welke verwijzing Google zal volgen.

Herhaal na uitvoering de aanvragen waarop het ticket berust. Noteer of je nog oude uitvoer krijgt en welke cachelaag aantoonbaar betrokken is. Wis of wijzig geen onbeheerde component op vermoeden. Een juiste nieuwe waarde op één product kan voortkomen uit een losse uitzondering; pas een tweede product uit dezelfde template maakt de algemene regel beter toetsbaar.

Maak bij het terugzetplan duidelijk welk verschijnsel de uitvoering afkeurt. Voorbeelden zijn een product dat niet meer opent, een andere taal als bestemming of een download die verdwijnt. Leg vooraf vast wie dan de vorige instelling herstelt en wie de oorspronkelijke routes opnieuw controleert. Bewaar ook het inhoudelijke besluit wanneer je een technische wijziging terugdraait: een mislukte uitvoering bewijst niet dat de gekozen hoofdversie inhoudelijk verkeerd was. Het nieuwe ticket kan daardoor gericht blijven op de defecte regel in plaats van het hele onderzoek opnieuw te beginnen.

Bespreek twaalf routes met vier verschillende vervolgstappen

Baken een inspectiespreekuur af tot twaalf routes uit het fictieve dossier. Maak vier groepen van drie: productadressen uit de hostinventaris, gedeelde parameteradressen, afzonderlijke mobiele productadressen en publicaties rond de handleiding. Leg de twaalf exacte URL’s vooraf vast. Dit is een onderzoekslijst voor concrete verschillen, geen scoremodel voor de hele website.

Bij iedere route leg je de laatste templatewijziging naast de datum van beschikbare indexeringsgegevens. Stel dat de gerapporteerde Googlecanonical ouder is dan die wijziging. Dan beschrijft die waarneming mogelijk een eerdere situatie. Een live controle kan huidige HTML bevestigen, maar bevestigt geen momenteel door Google geselecteerde canonical. Ontbrekende geïndexeerde gegevens blijven onbekend.

1. Oude Googlewaarneming, huidige signalen gelijk. Bewaar de oudere waarde met datum, documenteer de huidige overeenstemming en beoordeel opnieuw wanneer een nieuwere waarneming beschikbaar is. Verander geen werkende regel uitsluitend om het oude gegeven te laten verdwijnen.
2. Huidige signalen spreken elkaar tegen. Noteer bijvoorbeeld het verschil tussen ontvangen HTML en header. Wijs de twee regelbronnen aan en maak een gericht herstelvoorstel voor de verantwoordelijke beheerder.
3. Het doel geeft 404. Laat vaststellen of het bedoelde product is verplaatst, verwijderd of verkeerd geadresseerd. Kies pas een nieuw doel nadat de inhoudelijke bestemming is bevestigd en bereikbaar blijkt.
4. Het doel toont andere hoofdinhoud. Heropen het contentbesluit. Laat de productverantwoordelijke uitleggen welk product of antwoord bij de aangevraagde route hoort voordat een technische voorkeur wordt gewijzigd.

Rapporteer per route welke vervolgstap geldt en welk bewijs ontbreekt. Een beschikbare melding voor één adres zegt niet dat alle twaalf adressen in de indexeringsgegevens voorkomen. Voor routes zonder gegevens kun je de openbare uitvoer wel onderzoeken. Houd die technische bevinding gescheiden van een niet beschikbare Googlewaarneming.

Geef de vier groepen een vaste afbakening in het verslag: [drie hostroutes], [drie parameterroutes], [drie mobiele routes] en [drie handleidingroutes]. Noteer bij elke route welke vergelijking de controle moet beantwoorden. Als tijdens het spreekuur een dertiende adres opduikt, registreer je dat als vervolgonderzoek met een reden. Wissel het niet ongemerkt om voor een route die moeilijk te beoordelen blijkt. Zo blijft terug te zien welke twaalf aanvragen daadwerkelijk zijn onderzocht en waarom een ontbrekende waarneming nog geen afgeronde controle is.

Draag inhoud, uitvoering en waarneming afzonderlijk over

Sluit een ticket niet uitsluitend omdat de beheerder een instelling heeft opgeslagen. Gebruik afzonderlijke acceptatievelden, zodat de volgende verantwoordelijke kan zien welke beslissing vaststaat en welke controle nog ontbreekt. Koppel bij ieder veld een bewijsverwijzing, controledatum en naam aan de status.

Gebruik voor bewijs een verwijzing die de volgende beheerder kan terugvinden, met het onderzochte adres en het moment erbij. Een losse schermafbeelding zonder adres kan verschillende producten door elkaar laten lopen. Een kopie van alleen de instelling toont weer niet wat publiek werd geleverd. Bewaar daarom bewijs dat bij het betreffende acceptatieveld past. Noteer bij afkeuring welke concrete waarde afwijkt en wie die opnieuw beoordeelt.

• Contentbesluit: [equivalent of verschillend], [reden], [bewijs], [datum], [inhoudsverantwoordelijke].
• Technisch voorstel: [oude en gewenste waarde], [component], [bewijs], [datum], [eigenaar].
• Uitgevoerde waarde: [daadwerkelijke aanpassing], [wijzigingsbewijs], [datum], [uitvoerder].
• Publieke controle: [aangevraagde route en gevonden uitvoer], [bewijs], [datum], [controleur].
• Latere Googlewaarneming: [geselecteerde URL of onbekend], [beschikbare gegevens], [waarnemingsdatum], [beoordelaar].

Een positieve voorbeeldstatus is: openbare Atlas-route gecontroleerd, doel bereikbaar en inhoud passend. Een negatieve voorbeeldstatus is: instelling aangepast, maar publieke header verwijst nog naar het oude doel. Een derde status kan zijn: openbare uitvoer akkoord, latere Googlewaarneming onbekend. Zo wordt technisch herstel niet verward met bevestigde verwerking.

Start een beperkte hercontrole wanneer een concrete wijziging de onderbouwing raakt. Denk aan een nieuw productveld, een andere template, gewijzigde slashregels of een partner die de handleiding herschrijft. Selecteer de daardoor getroffen routes en een passende tegenproef. Leg openstaande waarnemingen met eigenaar en aanleiding vast in je SEO-rapportage, zodat een volgende controle dezelfde beslissing kan terugvinden.

Veelgestelde vragen over canonicals

Krijg je door dubbele inhoud automatisch een Google-straf?

Nee. Normale duplicatie is op zichzelf geen spamovertreding. Google kan vergelijkbare pagina’s groeperen en één URL selecteren. Onderzoek welke versie je wilt laten verschijnen en of je technische signalen die voorkeur ondersteunen.

Moet iedere indexeerbare pagina een selfcanonical hebben?

Nee. Een selfcanonical is een nuttig middel om je URL-voorkeur consequent aan te geven, maar geen universele voorwaarde voor indexatie. Controleer vooral of de opgegeven URL klopt en overeenkomt met de andere signalen.

Waarom kiest Google soms een andere canonical?

Een canonical is een voorkeurssignaal. Google beoordeelt ook inhoud en andere aanwijzingen. Controleer bij een afwijkende keuze de inhoudelijke overeenkomst, interne links, sitemap, redirects en bereikbaarheid van het doel. Houd rekening met de ouderdom van de inspectiegegevens.

Moet je noindex toevoegen aan iedere dubbele URL?

Nee. Gebruik een canonical om een voorkeursversie van equivalente pagina’s aan te wijzen. Gebruik noindex wanneer een pagina buiten de zoekindex moet blijven. Voeg noindex niet standaard toe als extra canonicalisatiesignaal.

Is een canonicalwijziging direct zichtbaar in Google?

Nee. Je kunt de openbare uitvoer na publicatie controleren, maar Google moet de wijziging nog verwerken. Er is geen vaste verwerkingstijd en geen garantie dat Google de opgegeven voorkeurs-URL selecteert.

Bespreek je URL-varianten met Niblah

Verzamel één vermoedelijke hoofd-URL en twee of drie varianten die je wilt laten beoordelen. Noteer of iedere variant bereikbaar moet blijven, welke inhoud verschilt en wat je al hebt gecontroleerd. Niblah biedt webdesign voor WordPress en Shopify en ondersteuning bij SEO. Stuur je voorbeelden en gewenste voorkeurs-URL via het contactformulier van Niblah, zodat je aanvraag begint bij een concrete technische keuze.