Een contentaudit kijkt naar titels, meta-descriptions en teksten. Dat is nuttig, maar raakt zelden de laag waar het in Magento echt misgaat: de manier waarop het platform zelf URL’s aanmaakt, filtert en dupliceert. Hieronder vier plekken waar dat gebeurt. Ze beginnen allemaal bij instellingen in de admin, dus je kunt ze zelf vinden, al vraagt het oplossen soms een developer.
Layered navigation en filter-URL’s
Elke combinatie van filters (kleur, maat, merk) kan in Magento een eigen URL opleveren. Klikt een bezoeker drie filters aan, dan staat hij op een URL die niemand bewust heeft gemaakt, maar die Google wel kan tegenkomen en crawlen.
Google noemde faceted navigation in december 2024 “verreweg de meest voorkomende oorzaak” van onnodig crawlen die site-eigenaren bij hen melden (Google Search Central). Googlebot besteedt dan tijd aan duizenden varianten van dezelfde categoriepagina, in plaats van aan de pagina’s die er echt toe doen.
Google geeft grofweg twee routes. Hoeven de filter-URL’s niet gecrawld te worden, blokkeer ze dan via robots.txt (of zet de filters achter een # in de URL, want dat deel negeert Google). Moeten ze wel crawlbaar blijven, zorg dan voor een vaste volgorde van parameters en een 404 bij filtercombinaties zonder resultaten.
In Magento regel je per attribuut of het een filter wordt, via Stores > Attributes > Product > het attribuut > Storefront Properties > “Use in Layered Navigation” (Adobe Experience League). Daar kies je tussen “Filterable (with results)” en “Filterable (no results)”, waarbij die laatste optie ook filters toont die geen resultaten opleveren. Loop die lijst attributen kritisch door: niet elk attribuut dat technisch filterbaar is, moet ook echt een filter worden. Hoe meer filterbare attributen, hoe meer URL-combinaties er kunnen ontstaan.
Robots.txt is geen noindex
Een veelgemaakte denkfout: een URL blokkeren in robots.txt zou hem uit Google halen. Dat is niet zo. Google zegt zelf dat robots.txt “geen mechanisme is om een pagina uit Google te houden” (Google Search Central). Een geblokkeerde URL kan alsnog in de index verschijnen als er elders links naar verwijzen, meestal zonder omschrijving.
Wil je een URL die al in de index staat er juist uit, dan moet Google de pagina kunnen crawlen om de noindex-instructie te lezen. Blokkeer je dezelfde URL in robots.txt, dan ziet Google die instructie nooit en blijft de URL staan (Google Search Central). Robots.txt gaat over crawlen, noindex over indexeren. Wil je iets uit de index halen: eerst noindex en Google laten crawlen, pas daarna eventueel blokkeren.
Canonical-instellingen
In Stores > Configuration > Catalog > Catalog > Search Engine Optimization staan twee instellingen: “Use Canonical Link Meta Tag For Categories” en “Use Canonical Link Meta Tag For Products”. In een standaardinstallatie staan beide op “No” (Adobe Experience League).
Daar staat ook “Use Categories Path for Product URLs”, standaard eveneens op “No”. Staat die instelling wel aan, dan krijgt een product dat in meerdere categorieën voorkomt ook meerdere URL’s, elk met het categoriepad erin. Adobe geeft zelf aan dat je dit kunt voorkomen door het categoriepad uit de productURL te laten, of door een canonical tag te gebruiken zodat zoekmachines niet meerdere URL’s met dezelfde inhoud indexeren (Adobe Experience League).
Zelf checken kost een paar seconden: open de paginabron van een productpagina (rechtermuisklik, “Paginabron weergeven”) en zoek op rel="canonical". Doe hetzelfde op een categoriepagina met een filter aangeklikt. Staat de regel er niet, dan staat de instelling waarschijnlijk nog op de standaardwaarde, en heeft Google voor gefilterde categoriepagina’s en voor producten met meerdere URL’s geen aanwijzing welke versie de echte is.
Staan de instellingen aan, dan wijst een gefilterde categoriepagina naar de categorie-URL zonder filterparameters (alleen een paginanummer blijft staan) en wijst een productpagina naar de product-URL zonder categoriepad. Voor de meeste shops is aanzetten dan de logische stap. Doe dat wel eerst op een testomgeving, zeker als het categoriepad in je product-URL’s staat.
URL-rewrites
Wijzig je een URL key van een product of categorie, dan maakt Magento daar automatisch een 301-redirect voor, via de instelling “Create Permanent Redirect for URLs if URL Key Changed”. Die staat standaard aan (Adobe Experience League). Een overzicht van alle redirects vind je onder Marketing > SEO & Search > URL Rewrites.
Wijzig je dezelfde URL key later nog eens, dan werkt Magento de bestaande redirects bij zodat de oude URL’s rechtstreeks naar de nieuwste URL wijzen. Toch kunnen er kettingen ontstaan, bijvoorbeeld na imports, een migratie of handmatig toegevoegde redirects: een oude URL wijst dan naar een tussenstap, die weer naar de nieuwe URL wijst. In het overzicht herken je dat aan een Target Path dat op een andere regel terugkomt als Request Path. Bij een paar honderd redirects is dat met de hand te doen, bij duizenden niet meer: dan is het werk voor je developer.
Een tweede instelling, “Generate ‘category/product’ URL Rewrites”, staat sinds Magento 2.4.6 standaard uit. Adobe deed dat om de performance te verbeteren: bij het opslaan van een categorie met veel producten werden anders alle rewrites direct opnieuw gegenereerd (Magento GitHub issue 37772, Adobe Experience League). Staat die wel aan, dan maakt Magento voor elk product een eigen rewrite per categorie waarin het staat, per store view. Bij een shop met veel producten, categorieën en store views groeit de url_rewrite-tabel daardoor flink. Staat de instelling bij jou aan en zit het categoriepad niet in je product-URL’s, vraag dan bij het volgende onderhoud of hij nog nodig is.
Dit soort instellingen gaat vaak mis rond een migratie, wanneer URL-structuren en instellingen worden overgenomen zonder dat iemand ze opnieuw doorloopt. Overweeg je een migratie, lees dan wat daarbij komt kijken en het stappenplan voor een migratie.
Dubbele content bij configurable products
Een configurable product, denk aan een trui in meerdere kleuren en maten, bestaat in Magento uit één zichtbaar hoofdproduct en meerdere onderliggende simple products. Die simples horen normaal niet los vindbaar te zijn. Staat de zichtbaarheid van een simple product op “Catalog, Search” in plaats van “Not Visible Individually”, dan krijgt die simple toch een eigen productpagina, met vrijwel dezelfde inhoud als het hoofdproduct (Adobe Experience League).
Het resultaat: twee of meer pagina’s met grotendeels dezelfde tekst, afbeeldingen en prijsinformatie, die in de zoekresultaten met elkaar concurreren in plaats van met andere shops. Dit kan gebeuren bij producten die via een import of een koppeling binnenkomen, bijvoorbeeld een PIM- of feedkoppeling die de zichtbaarheid van varianten niet correct meestuurt.
Zelf checken doe je via Catalog > Products: filter op type “Simple Product” en kijk naar de kolom Visibility. Staat die op iets anders dan “Not Visible Individually” bij producten die onderdeel zijn van een configurable product, dan is dat het moment om uit te zoeken waar die instelling vandaan komt.
Moeten die simples om een andere reden toch los vindbaar blijven, bijvoorbeeld omdat ze ook los verkocht worden, dan is “Not Visible Individually” geen optie en moet een developer kijken naar een andere oplossing, zoals een canonical verwijzing naar het configurable product. Dat is geen standaard Magento-instelling, dus dat bouw je niet zelf even in de admin.
Draai je meerdere store views, dan vermenigvuldigt dit probleem zich: het attribuut Visibility heeft in Magento store view-scope, dus elke store view kan zijn eigen zichtbaarheidsinstelling hebben en dezelfde fout kan op meerdere plekken tegelijk ontstaan. Meer daarover in meerdere store views beheren.
Wat je zelf checkt, en wat een developer oplost
De vier punten hierboven check je zelf in de admin: layered navigation per attribuut, de canonical-instellingen, de instellingen rond URL-rewrites, en de zichtbaarheid van simple products.
Daarnaast is Google Search Console de plek waar je ziet wat er daadwerkelijk gebeurt. In het rapport Pagina’s, onder “Waarom pagina’s niet worden geïndexeerd”, zijn drie meldingen relevant:
- Dubbele pagina zonder door de gebruiker geselecteerde canonieke versie. Google heeft meerdere, bijna identieke pagina’s gevonden en zelf een canonieke versie gekozen, omdat jij er geen hebt aangegeven. De oplossing is een canonical instellen, en zorgen dat interne links en je sitemap consequent naar diezelfde URL wijzen (Google Search Console Help).
- Gecrawld - momenteel niet geïndexeerd. Google heeft de pagina bekeken, maar besloten die (nog) niet op te nemen. Staan hier veel filter-URL’s of losse simple products tussen, dan speelt waarschijnlijk een van de vier punten hierboven.
- URL geblokkeerd door robots.txt. De URL is niet gecrawld, dus een eventuele noindex is ook niet gelezen (zie hierboven).
Zit de oorzaak in de configuratie zelf, in de code, of in een koppeling met een ander systeem, dan is dat werk voor een developer. Een Magento code review brengt in kaart waar precies het probleem zit, en met Magento onderhoud blijven instellingen als deze bij upgrades en nieuwe koppelingen in beeld. Een extra extensie is zelden de eerste stap, zie ook extensies kiezen zonder spijt.
Twijfel je waar het bij jouw shop vastloopt? Neem contact op, dan kijken we mee.
Veelgestelde vragen
Kan ik de canonical-instellingen gewoon zelf aanzetten?
Dat kan, maar check eerst de instelling “Use Categories Path for Product URLs”. Met de canonical voor producten aan wijst elke productpagina naar de URL zonder categoriepad, ook als een bezoeker via een categorie binnenkwam. Dat is meestal precies wat je wilt, maar het is goed om te weten voor je het aanzet. Test een wijziging altijd eerst op een staging-omgeving voordat je live gaat, en controleer na de wijziging in de paginabron of de canonical tag doet wat je verwacht.
Moet ik filter-URL’s blokkeren met robots.txt of met noindex?
Wil je dat Googlebot geen tijd besteedt aan filtercombinaties, gebruik dan robots.txt. Wil je dat specifieke URL’s uit de index blijven, gebruik dan noindex. Combineer de twee niet op dezelfde URL: achter een robots.txt-blokkade leest Google de noindex nooit.
Wat betekent “Dubbele pagina zonder door de gebruiker geselecteerde canonieke versie” in Search Console?
Google heeft meerdere, bijna identieke pagina’s gevonden en zelf gekozen welke in de index komt, omdat jij geen canonical had ingesteld. In Magento wijst dat vaak op canonical-instellingen die nog op “No” staan, of op simple products die los zichtbaar zijn.
Wat gebeurt er met de oude URL als ik een URL key wijzig?
Magento maakt daar standaard een 301-redirect voor aan. Het overzicht van alle redirects staat onder Marketing > SEO & Search > URL Rewrites. Kijk daar vooral na een import of migratie, of als er handmatig redirects zijn toegevoegd.
Lost een contentaudit dit soort problemen op?
Niet rechtstreeks. Een audit op titels, teksten en meta-descriptions raakt deze configuratielaag meestal niet, omdat het om instellingen gaat in de catalogus en niet om content. Filter-URL’s, canonical-instellingen, URL-rewrites en de zichtbaarheid van simple products controleer je apart, in de Magento-admin zelf.