Magento-URL’s en canonicals: voorkom dubbele product- en categoriepagina’s

Daarom is een canonical tag niet zomaar een SEO-vinkje in de Magento-configuratie. Een goede URL-strategie zorgt dat redirects, canonicals, interne links, sitemaps en hreflang allemaal dezelfde voorkeurs-URL aanwijzen. Zodra die signalen elkaar tegenspreken, kiest Google uiteindelijk zelf.

Goed om vooraf te weten: MagentoSEO.nl wijzigt geen Magento-code, URL rewrites of serverconfiguratie. Wij analyseren welke URL’s Magento en aangesloten systemen produceren, bepalen de gewenste SEO-logica, briefen de webbouwer en controleren na implementatie of redirects, canonicals en indexatiesignalen correct werken.

Eerst het verschil: URL, rewrite, redirect en canonical

Deze begrippen worden in gesprekken regelmatig door elkaar gebruikt. Toch lossen ze niet hetzelfde probleem op.

Begrip	Wat gebeurt er?	Wat ziet de bezoeker?	Typische toepassing
URL	Het openbare adres van een pagina	De URL in de adresbalk	Product, categorie, CMS-pagina of filtercombinatie
URL rewrite	Magento koppelt een leesbaar pad intern aan een route	De leesbare URL blijft staan	Een product tonen via /leren-tas.html in plaats van een systeemroute
Redirect	De browser wordt naar een andere URL gestuurd	De adresbalk verandert	Een oude URL key permanent doorsturen naar de nieuwe URL
Canonical	De HTML noemt de voorkeurs-URL van gelijke of sterk vergelijkbare pagina’s	Er verandert visueel niets	Signalen van toegankelijke varianten bij één URL concentreren

Adobe benadrukt in de officiële documentatie over URL rewrites dat een rewrite en een redirect verschillende processen zijn. De Magento-beheerfunctie maakt bij een URL-wijziging normaal gesproken een permanente redirect aan als die optie actief is. Dat is nuttig, maar je moet de uiteindelijke response altijd testen. Een instelling in de beheeromgeving is nog geen bewijs dat iedere oude URL correct doorstuurt.

Een canonical doet bovendien iets anders dan een redirect. De dubbele URL blijft bereikbaar met status 200. Je geeft alleen aan welke versie je als hoofdversie ziet. Google noemt redirects en rel="canonical" sterke canonicalisatiesignalen; opname in een sitemap is een zwakker signaal. Die signalen kunnen elkaar versterken, maar ook tegenspreken. Zie daarvoor de Google-richtlijnen voor canonicalisatie.

Waarom Magento meerdere product-URL’s kan opleveren

Een veelvoorkomende keuze is of een categoriepad onderdeel wordt van een product-URL.

Stel dat een product de URL key leren-laptoptas heeft en in twee categorieën staat. Dan kunnen varianten ontstaan zoals:

• https://shop.nl/tassen/leren-laptoptas.html;

• https://shop.nl/laptoptassen/leren-laptoptas.html;

• https://shop.nl/leren-laptoptas.html.

De inhoud kan op alle drie de adressen hetzelfde zijn. Adobe beschrijft dit scenario expliciet in de documentatie over canonical metadata. Wanneer categorieën in product-URL’s worden opgenomen, kan hetzelfde product via meerdere paden bereikbaar zijn. De productcanonical verwijst in de standaardbeschrijving naar de versie op domein plus product-URL-key, dus zonder categoriepad.

Dat betekent niet automatisch dat ieder Magento-platform categorieën uit product-URL’s moet verwijderen. Er kunnen historische, commerciële of trackingredenen zijn om een bepaald pad te behouden. De belangrijke vraag is of er één consistente voorkeur bestaat en of alle technische signalen die voorkeur ondersteunen.

De vijf belangrijkste oorzaken van dubbele Magento-URL’s

1. Producten in meerdere categorieën

Een product kan in Magento aan meerdere categorieën zijn gekoppeld. Wanneer categorieën in het productpad staan, kan iedere plaatsing een extra bereikbaar adres veroorzaken. Ook merchandising, automatische categorieën of een PIM-import kunnen nieuwe paden introduceren zonder dat het SEO-team dit direct ziet.

2. Gewijzigde URL keys

Een productnaam verandert, een categorie krijgt een betere benaming of iemand maakt URL’s korter. Magento kan vervolgens een redirect voor de oude URL key aanmaken. Toch ontstaan problemen wanneer:

• de optie voor een permanente redirect niet is gebruikt;

• een import URL keys opnieuw overschrijft;

• oude rewrites ontbreken of conflicteren;

• meerdere oude URL’s via een redirectketen lopen;

• een redirect naar de verkeerde storeview of categorie gaat.

3. Parameters en sessie-informatie

Campagneparameters, sorteervolgordes, paginering, interne zoekopdrachten en filterparameters kunnen veel URL-varianten veroorzaken. Niet iedere parameterpagina is inhoudelijk een duplicaat, maar trackingparameters veranderen de kerninhoud meestal niet. Een canonical moet dan naar de schone, inhoudelijke URL wijzen.

4. Storeviews en domeinvarianten

HTTP en HTTPS, wel of geen www, storecodes in het pad, afwijkende base URL’s en taal- of landversies kunnen parallel bestaan. Bij internationale shops moet canonicalisatie bovendien samenwerken met hreflang. Een Nederlandse pagina hoort niet blind te canonicaliseren naar de Duitse versie omdat de productinformatie op elkaar lijkt.

5. Externe systemen die URL’s aanmaken of terugschrijven

Een PIM, ERP, feedtool of migratiescript kan URL keys, categorieplaatsingen of storeviewwaarden wijzigen. Daardoor is het URL-landschap geen eenmalige Magento-instelling, maar een dataketen. Wie alleen de huidige HTML controleert, mist mogelijk de oorzaak die de fout iedere nacht opnieuw introduceert.

Canonical of redirect: kies op basis van het gedrag

Een praktisch onderscheid:

• Gebruik een permanente redirect wanneer een URL echt is vervangen en bezoekers de oude versie niet meer hoeven te gebruiken.

• Gebruik een self-referential canonical op de voorkeurs-URL zelf.

• Gebruik een canonical naar de hoofdversie wanneer een alternatieve URL bereikbaar moet blijven maar inhoudelijk geen zelfstandig zoekresultaat hoort te zijn.

• Gebruik geen canonical als pleister voor pagina’s die eigenlijk een eigen zoekintentie, assortiment of content hebben.

• Gebruik geen robots.txt om canonicalisatie af te dwingen. Google kan een geblokkeerde URL nog steeds kennen, terwijl het de canonical in de HTML niet kan uitlezen.

Situatie	Meestal passend	Waarom
Oude product-URL na definitieve naamswijziging	301 naar nieuwe product-URL	De oude URL heeft geen zelfstandige functie meer
Product bereikbaar met trackingparameter	Canonical naar schone product-URL	De parameter-URL kan voor campagnes nodig blijven
Hetzelfde product via verschillende categoriepaden	Eén gekozen URL, ondersteund door canonical en interne links	Voorkomt verspreide signalen over meerdere paden
Twee varianten met eigen voorraad, prijs en zoekvraag	Vaak aparte indexeerbare URL’s met self-canonical	De pagina’s kunnen zelfstandig waarde hebben
Filterpagina zonder unieke zoekvraag	Niet automatisch indexeren; beslis binnen de filterstrategie	Canonicalisatie alleen lost crawlchaos niet op
Product vervangen door een vrijwel identieke opvolger	301 kan passend zijn na inhoudelijke beoordeling	De gebruiker krijgt een relevante vervanging

De beslissing begint dus niet bij de tag, maar bij de vraag: is dit dezelfde pagina, een vervangen pagina of een werkelijk zelfstandige pagina?

Een Magento-URL-strategie in zeven beslissingen

Beslissing 1: bepaal de voorkeursvorm

Leg ten minste vast:

• HTTPS en de gekozen hostnaam;

• trailing slash of geen trailing slash waar dit configureerbaar is;

• wel of geen categoriepad in product-URL’s;

• gewenste suffixen zoals .html en het beleid bij wijziging daarvan;

• storecodes in de URL of niet;

• schrijfwijze van URL keys;

• omgang met hoofdletters, accenten en speciale tekens.

Het doel is niet om de theoretisch mooiste URL te kiezen. Het doel is om één vorm consequent te gebruiken zonder onnodige migratie van bestaande adressen.

Beslissing 2: wijs per paginatype één canonicalpatroon aan

Beschrijf voor producten, categorieën, CMS-pagina’s, zoekpagina’s, paginering en filters wat de canonical hoort te doen. Werk met patronen, niet met losse URL’s. Bijvoorbeeld:

• product zonder categoriepad: self-canonical;

• product met categoriepad: canonical naar product zonder categoriepad;

• categorie: self-canonical naar de volledige categorie-URL;

• trackingparameter: canonical naar dezelfde pagina zonder trackingparameter;

• indexeerbare filterlanding: self-canonical als de pagina zelfstandig is toegestaan.

Beslissing 3: maak interne links canonical-first

Een canonical is geloofwaardiger als de shop intern naar dezelfde URL verwijst. Controleer daarom navigatie, breadcrumbs, producttegels, gerelateerde producten, CMS-links en XML-sitemaps.

Wanneer een producttegel naar een categoriepad linkt, de breadcrumb naar een tweede pad, de sitemap een derde URL bevat en de canonical een vierde versie aanwijst, is de technische configuratie misschien geldig maar de strategie niet coherent.

Beslissing 4: definieer URL-wijzigingen als releaseproces

Een URL key wijzigen is geen redactionele kleinigheid. Het kan gevolgen hebben voor organische posities, advertenties, feeds, e-mailcampagnes, externe links en analytics.

Neem daarom op in het wijzigingsproces:

• oude en nieuwe URL vastleggen;

• zoekverkeer en backlinks van de oude URL controleren;

• 301-redirect laten aanmaken;

• interne links direct bijwerken;

• sitemap en feed controleren;

• canonical op de nieuwe URL valideren;

• na livegang statuscodes en indexatie monitoren.

Beslissing 5: voorkom redirectketens

Als URL A ooit naar B ging en B later naar C, moet A bij voorkeur rechtstreeks naar C wijzen. Iedere extra stap vergroot de kans op fouten, vertraagt de route en maakt beheer ondoorzichtig. Google kan redirects volgen, maar een schone directe mapping is beter voor gebruikers en beheer.

Beslissing 6: behandel storeviews als afzonderlijke marktlogica

Een canonical hoort normaal binnen dezelfde taal- of marktversie te blijven. Hreflang verbindt vervolgens equivalente pagina’s tussen landen of talen. Controleer per storeview:

• juiste domein of subdirectory;

• self-canonical in dezelfde taal en markt;

• hreflang naar bestaande, indexeerbare alternatieven;

• geen canonical naar een generieke default storeview;

• consistente base URL in HTML, sitemap en interne links.

Beslissing 7: spreek eigenaarschap af

URL’s worden vaak door meerdere teams beïnvloed. Leg daarom vast wie beslist over URL keys, wie imports beheert, wie redirects implementeert, wie SEO-acceptatie uitvoert en wie incidenten oplost. Zonder eigenaar wordt een URL-probleem al snel “iets van Magento”.

De testmatrix voor iedere belangrijke URL

Een goede controle kijkt niet alleen naar wat in de browser staat. Test iedere representatieve URL op meerdere lagen.

Testlaag	Te controleren	Goed resultaat
HTTP-response	Statuscode en redirectlocatie	Voorkeurs-URL geeft 200; vervangen URL gaat direct via 301
Browser-URL	Eindadres na redirects	Exact de afgesproken voorkeursvorm
HTML-head	Canonical in de broncode	Eén absolute canonical naar de juiste indexeerbare URL
Gerenderde HTML	Wijzigt JavaScript de canonical?	Zelfde doel als in de broncode
Interne links	Menu, tegel, breadcrumb, gerelateerd	Links wijzen rechtstreeks naar de voorkeurs-URL
XML-sitemap	Opgenomen URL	Alleen canonicale indexeerbare URL
Hreflang	Alternatieve taal- en landversies	Bestaande, wederkerige en canonicale doelen
Structured data	url in Product of Offer	Komt overeen met zichtbare en canonicale product-URL
Feed	Productlink en variantlink	Landt op juiste, beschikbare URL zonder onnodige redirect
Search Console	Door Google gekozen canonical	Komt na verwerking overeen met de gebruikerscanonical

Test niet alleen de homepage en één eenvoudig product. Neem verschillende situaties op:

• een product in één categorie;

• een product in meerdere categorieën;

• een product met gewijzigde URL key;

• een configurable product;

• een categorie met paginering;

• een URL met trackingparameters;

• iedere belangrijke storeview;

• een oude URL uit een eerdere migratie.

Veelvoorkomende fouten die technisch klein lijken

Canonical naar een redirect

De canonical verwijst naar URL B, maar URL B stuurt door naar C. Wijs de canonical direct naar C. Dat voorkomt een onnodige interpretatiestap.

Canonical naar een 404 of niet-indexeerbare pagina

Een canonicaldoel moet bereikbaar en indexeerbaar zijn. Een doel met 404, noindex, loginverplichting of robotsblokkade is geen bruikbare voorkeursversie.

Alle varianten canonicaliseren naar een generieke parent

Dat kan goed zijn wanneer de varianten alleen binnen één parentpagina bestaan. Het is riskant wanneer kleur- of maatvarianten eigen URL’s, content, voorraad en zoekvraag hebben. Beoordeel productarchitectuur, structured data en Merchant Center als één geheel.

Canonical en sitemap spreken elkaar tegen

De sitemap bevat categoriepad-URL’s, terwijl de canonical naar het product zonder categoriepad wijst. Daarmee vertel je Google tegelijk dat beide URL’s belangrijk zijn. Neem alleen de gekozen canonicale URL’s in de sitemap op.

Een bulkregeneratie uitvoeren zonder impactanalyse

Het regenereren van URL rewrites kan nuttig zijn bij ontbrekende of beschadigde rewrites, maar is geen onschuldige SEO-handeling. Laat de webbouwer eerst aantallen, conflicten, storeviews, performance-impact en rollbackmogelijkheden onderzoeken. Maak voor en na de wijziging een crawlvergelijking.

Canonicals gebruiken tegen filterexplosie

Een canonical op duizenden parameter-URL’s kan onderdeel zijn van een oplossing, maar voorkomt niet dat de URL’s worden ontdekt en gecrawld. Voor layered navigation heb je aanvullend beleid nodig voor interne links, parametercombinaties, robots, indexeerbare landings en facetten.

Zo brief je de Magento-webbouwer

Een bruikbare briefing bevat geen losse opdracht als “de canonicals moeten goed”. Geef de gewenste output en acceptatiecriteria.

Neem minimaal op:

• de voorkeurs-URL per paginatype en storeview;

• categoriepadbeleid voor producten;

• regels voor oude URL keys en permanente redirects;

• omgang met parameters en campagnecodes;

• canonicalregels voor producten, categorieën, CMS, filters en paginering;

• vereiste samenhang met interne links, sitemap, hreflang, structured data en feed;

• lijst met representatieve testcases;

• export van oude en nieuwe URL’s bij bulkchanges;

• eisen voor directe redirects zonder ketens;

• monitoring en rollback bij onverwachte impact.

Laat de webbouwer vervolgens aangeven waar de logica wordt beheerd: Magento-configuratie, thema, extensie, maatwerkmodule, webserver, CDN of extern systeem. Dat is essentieel voor toekomstig onderhoud.

Meten na implementatie

Controleer direct na livegang:

• statuscodes van de afgesproken testset;

• canonical in broncode en gerenderde HTML;

• verschillen tussen oude en nieuwe crawl;

• nieuwe 3xx-, 4xx- en canonicalfouten;

• interne links naar redirects;

• sitemap- en feed-URL’s;

• serverlogs voor veel gecrawlde duplicaten;

• Search Console bij representatieve URL’s;

• organische landings en clicks op URL-niveau.

Verwacht niet dat Google iedere canonicalkeuze onmiddellijk overneemt. Canonicalisatie is een interpretatieproces. De snelle kwaliteitscontrole is daarom: zijn alle signalen technisch correct en consequent? De latere controle is: consolideert Google de URL’s inderdaad zoals bedoeld?

De kern: één URL-besluit, overal dezelfde uitwerking

Magento kan prima met duidelijke, stabiele URL’s werken. Problemen ontstaan vooral wanneer categorieplaatsingen, imports, oude rewrites, storeviews en externe systemen ieder hun eigen variant produceren.

De oplossing is geen willekeurige canonicalinstelling. Kies per situatie één voorkeurs-URL, laat redirects, canonicals, interne links, sitemap, hreflang, structured data en productfeeds hetzelfde verhaal vertellen en test de daadwerkelijke output.

Wil je weten waar jouw Magento-shop dubbele URL’s produceert en welke variant Google als hoofdversie zou moeten zien? Vraag dan een Magento-analyse aan. Wij brengen de URL-patronen en conflicterende signalen in kaart, vertalen die naar een concrete briefing voor je webbouwer en controleren de implementatie na oplevering.