Canonical naar de verkeerde pagina: diagnoseplan

Zoekmachines gebruiken verschillende signalen om de definitieve hoofdversie van een pagina te bepalen. Een expliciete rel="canonical"-link is een sterk signaal, net zoals een permanente 301-omleiding. Opname in de XML-sitemap geldt volgens de documentatie over het bepalen van een kanonieke URL op Google Search Central eveneens als een kanoniek signaal, hoewel dit als een zwakker signaal wordt gezien dan een directe tag of redirect. Daarnaast spelen interne links een grote rol: wanneer alle interne verwijzingen op een website consequent naar één specifieke URL wijzen, helpt dit om de voorkeur van de site-eigenaar te bevestigen.

Problemen ontstaan wanneer deze signalen tegenstrijdig zijn. Als de broncode van een pagina wijst naar URL A, de sitemap linkt naar URL B en de interne websitenavigatie doorverwijst naar URL C, ontstaat er verwarring bij zoekmachines. Google consolideert signaalwaarden zoals inkomende links naar de gekozen kanonieke pagina. Is die keuze verkeerd geïnterpreteerd door een verkeerde tag, dan kan de oorspronkelijke URL uit de index verdwijnen. Een grondige diagnose vereist dus het in kaart brengen van al deze afzonderlijke onderdelen.

De eerste stap in het diagnoseplan is het inspecteren van het bronbestand dat de server daadwerkelijk aflevert. Open de pagina in een browser en bekijk de broncode (of gebruik een netwerk-inspectietool) om de <head>-sectie te controleren op de aanwezigheid van het element <link rel="canonical" href="..." />.

Let bij deze inspectie op de volgende kritieke aandachtspunten:

• Absolute paden: Zorg ervoor dat de canonical-URL volledig is geschreven (inclusief https:// en het juiste domein). Gebruik geen relatieve paden zoals /producten/pagina, omdat dit bij testomgevingen of inconsistente websidestructuren tot foutieve interpretaties leidt.
• Eén enkele declaratie: Controleer of er niet per ongeluk twee canonical-tags in de code staan (bijvoorbeeld één gegenereerd door het CMS en één door een aparte SEO-plugin). Multiple declaraties worden vaak genegeerd of leiden tot onvoorspelbaar gedrag.
• HTTP-headers: Voor niet-HTML-bestanden, zoals PDF-documenten of bij specifieke server-instellingen, kan de canonical-relatie worden meegestuurd via de HTTP-responseheader (Link: <https://example.com/document.pdf>; rel="canonical"). Voorkom dat er zowel in de HTML als in de HTTP-header tegenstrijdige canonicals staan.
• Geen fragments: De URL mag geen fragment-identificatoren (zoals #sectie) bevatten, aangezien zoekmachines fragmenten negeren bij de bepaling van de canonical.

Zodra de broncode geanalyseerd is, moeten de overige signaalbronnen worden getoetst aan de canonical-tag. Zoekmachines combineren namelijk meerdere signalen om hun definitieve indexatiebesluit te nemen. Richtlijnen voor e-commerce URL-structuren op Google Search Central adviseren om overal op de website exact dezelfde URL te gebruiken in interne links, sitemaps en canonical-tags.

Met de onderstaande beslis- en vergelijkingsmatrix zie je direct waar een conflict ontstaat en welke actie vereist is:

Als een URL is ingesteld met een 301-omleiding naar een nieuw doel, is een canonical-tag die naar de doelpagina zelf verwijst een gebruikelijke manier om die hoofdversie te bevestigen. Controleer eerst of de doelpagina werkelijk de bedoelde representatieve versie is; een zelfverwijzende canonical is geen universele verplichting. Wijst een omgeleide pagina naar een andere URL dan het redirectdoel, dan ontstaat er een conflict dat de crawlefficiëntie verstoort.

Bij e-commerce websites of dynamische platformen ontstaan foutieve canonicals vaak door het gebruik van URL-parameters (zoals ?color=blue of ?sort=asc) of door client-side JavaScript-rendering. Een sorteervariant kan dezelfde inhoud vertegenwoordigen als de basispagina, maar een kleur- of maatvariant heeft mogelijk eigen productinformatie. Bepaal daarom eerst welke URLs werkelijk dubbele of sterk gelijkende inhoud hebben. Wijs varianten niet uitsluitend op basis van de aanwezigheid van een parameter naar de basispagina; kies een representatieve URL die past bij de zichtbare inhoud en het productmodel.

Maakt je website gebruik van JavaScript om de <head> te bouwen of aan te passen? Dan is extra voorzichtigheid geboden. Als het initiële HTML-document een andere canonical bevat dan het document nadat JavaScript is uitgevoerd, kan de zoekmachine de voorkeur negeren of verkeerd interpreteren. De beste werkwijze is om de canonical-tag direct in de ruwe HTML-broncode op te nemen en te zorgen dat scripts dit element na het laden niet meer veranderen.

Stel dat een kmo uit Gent twee pagina's heeft voor een specifieke dienst: https://example.be/diensten/onderhoud (de hoofdversie) en https://example.be/diensten/onderhoud-actie (een tijdelijke landingspagina). Door een configuratiefout in het CMS is op de hoofdpagina per ongeluk een canonical-tag geplaatst die wijst naar de actiepagina:

<link rel="canonical" href="https://example.be/diensten/onderhoud-actie" />

In dit fictieve voorbeeld geeft de tag een onbedoelde voorkeur voor de tijdelijke actiepagina. Als Google die voorkeur overneemt, kan de permanente URL minder duidelijk als hoofdversie naar voren komen. Dat bewijst op zichzelf geen verkeersverlies. Controleer in Search Console welke canonical Google werkelijk heeft gekozen en vergelijk de inhoud van beide URLs voordat je wijzigingen doorvoert.

De stapsgewijze herstelprocedure in dit scenario:

1. Wijzig de canonical-tag op https://example.be/diensten/onderhoud zodat deze naar zichzelf verwijst (self-referencing canonical).
2. Controleer of de tijdelijke actiepagina dezelfde of sterk gelijkende inhoud bevat. Alleen dan kan een canonical naar https://example.be/diensten/onderhoud passend zijn. Bij een inhoudelijk ander aanbod behandel je de actiepagina als een eigen pagina en kies je bewust wat er na afloop mee gebeurt.
3. Controleer of de interne navigatie en de XML-sitemap uitsluitend de URL van de hoofdversie bevatten.
4. Dien de hoofd-URL opnieuw in via de inspectietool van de zoekmachine om een nieuwe crawling aan te vragen.

Na het uitvoeren van de technische correcties is een grondige natest nodig. Controleer de huidige broncode en headers en gebruik de live-URL-test in Search Console om de actuele bereikbaarheid en verwerking te onderzoeken. Die live-test voorspelt niet welke canonical Google zal selecteren. Vergelijk de door jou opgegeven canonical en de door Google geselecteerde canonical in de geïndexeerde gegevens van URL-inspectie. Die gegevens kunnen nog de vorige crawl beschrijven. Noteer de crawldatum en beoordeel na een volgende verwerking opnieuw of Google de bedoelde hoofdversie heeft gekozen.

Er is geen vaste termijn waarin Google de gewijzigde signalen opnieuw verwerkt. Een correcte technische wijziging garandeert ook niet dat de pagina wordt geïndexeerd of hoger verschijnt. Ben je benieuwd hoe de publiek zichtbare signalen en basisstructuur van jouw website er momenteel bij staan? Je kunt gratis de publieke signalen van je website bekijken via Marketing Scan om een eerste inzicht te krijgen in de algemene opbouw en zichtbaarheid van jouw pagina's.