Bij een migratie van PrestaShop 1.7 naar 8, een themawissel, een reorganisatie van de boomstructuur, of gewoon een wijziging van een productslug veranderen honderden tot duizenden URL’s in stilte. Elk van die URL’s heeft SEO-waarde opgebouwd, inkomende links verzameld, en staat misschien met een goede positie in de Google-resultaten. Zonder 301-redirect naar de nieuwe URL verdwijnt dat kapitaal.
Het ergste: het verlies is niet onmiddellijk. U ziet het verkeer langzaam dalen over 3 tot 6 weken, zonder duidelijk incident. Tegen de tijd dat u het begrijpt, heeft u 30 tot 50% van het SEO-verkeer verloren en duurt het 6 tot 12 maanden om het terug te winnen, als het lukt.
Dit artikel ontleedt de mechaniek van de 301-redirects op PrestaShop: wat het native doet, wat het mist, hoe u een nette 404-monitoring opzet, en hoe u de reflex “slug wijzigt → 301-redirect” automatiseert.
Waarom 301-redirects kritiek zijn voor SEO
Een 301-redirect (“Moved Permanently”) zegt tegen Google en de gebruikers: deze URL is definitief verhuisd, dit is het nieuwe adres. Google draagt dan de PageRank over, de historiek van de URL en de opgebouwde backlinks. De nieuwe URL erft het SEO-kapitaal.
Zonder 301 geeft de oorspronkelijke URL een 404 (“Not Found”). Google zet de pagina in de wachtrij voor deïndexatie, de backlinks wijzen in het niets, de PageRank vervliegt. Na 3-6 maanden is de URL uit de index verwijderd. Het kapitaal is verloren.
Enkele auditcijfers, op een shop na een migratie zonder net 301-beheer:
- 40 tot 60% van de door Google geïndexeerde URL’s antwoordt met een 404 binnen 6 maanden.
- Het SEO-verkeer daalt met 25 tot 50% in het daaropvolgende kwartaal.
- De posities op long-tail queries (vaak de meest rendabele) storten als eerste in.
- De externe backlinks (pers, blogs, directories) worden obsoleet en verliezen hun waarde.
Wat PrestaShop native beheert (en wat het mist)
De native SEO & URL’s module
PrestaShop 8 en 9 bieden een tab “Redirects” in Voorkeuren > Verkeer > SEO & URL’s. Daarmee voegt u handmatig 301 / 302 / 410 redirects toe per paar (bron-URL, doel-URL).
Beperkingen:
- Geen beheer via regex of wildcard. Om een hele oude categorie
/oude-producten/*naar/promoties/te redirecten, moet u elke URL handmatig aanmaken. - Geen automatische redirect bij slugwijziging. Wijzigt u de slug van een product, dan gaat de oude URL naar een 404 zonder redirect.
- Geen 404-monitoring op de daadwerkelijk bezochte URL’s.
- Beperkte prestaties. Voorbij enkele duizenden redirects vertraagt de module de routing.
- Geen import/export in CSV om massaal te beheren.
Het .htaccess bestand
Handmatig alternatief: RewriteRule regels schrijven in .htaccess. Performant (Apache verwerkt de regels stroomopwaarts), maar:
- Gevoelig voor syntaxfouten (één verkeerd geplaatste komma en de hele site valt in een 500).
- Moeilijk te onderhouden voor niet-technici.
- Werkt niet op Nginx (dat zijn eigen syntax gebruikt).
- Geen backoffice-interface en geen traceerbaarheid.
De stack die men zou moeten hebben
1. Automatische redirect bij slugwijziging
Wanneer een product, een categorie of een CMS-pagina van slug verandert, moet de oude URL automatisch een 301 naar de nieuwe registreren. Geen handmatige manipulatie, geen risico op vergeten. Het vangnet nummer 1.
2. Monitoring van de 404’s
Alle URL’s die een 404 geven, moeten gelogd worden met hun frequentie en hun referrer. Een URL die 200 keer per maand een 404 geeft, is een bug die prioriteit heeft. Een URL die één keer per jaar een 404 geeft, kan wachten.
3. Massaredirects via regex en wildcard
Voor migraties heeft men patterns nodig. /oude-categorie/(.*) → /nieuwe-categorie/$1 moet in één regel te configureren zijn, niet in 200 entries.
4. Import/export CSV
Vóór een migratie bereidt men de correspondentietabel in CSV voor vanuit de export van de oude en de nieuwe sitemap. Men importeert in één keer in plaats van met de hand in te voeren.
5. Detectie van redirectketens
Een URL die redirect naar een URL die redirect naar een URL is een SEO-antipattern. Google waardeert ketens van meer dan 2 hops af. Een goede tool detecteert en signaleert de ketens.
6. Traceerbaarheid en audit
Wie heeft welke redirect aangemaakt, wanneer, om welke reden? Bij een probleem (verkeersval na migratie) is het kunnen auditen van de 301-regels cruciaal.
Het bijzondere geval van de wijziging van een productslug
Op een actieve shop veranderen de slugs voortdurend. Een product waarvan de naam evolueert (“Zomerjurk 2025” → “Linnen zomerjurk 2025”), een SEO-optimalisatie van een titel, een typocorrectie: elke wijziging van de link_rewrite in ps_product_lang verandert de canonieke URL.
Wordt de 301 niet automatisch aangemaakt, dan gaat de oude URL naar een 404. Over 12 maanden, op een catalogus van 5.000 producten met 10% gewijzigde slugs, gaat het om 500 “verloren” URL’s. Draineerde elk daarvan gemiddeld 50 bezoeken per maand, dan spreken we over 25.000 verloren SEO-bezoeken per jaar, zonder zichtbaar incident.
De correcte reflex: een hook op actionObjectProductUpdateAfter die de wijziging van link_rewrite detecteert en de 301 automatisch aanmaakt, per taal en per shop in multi-shop.
De valkuil van de redirectketens
Klassiek scenario: een product A verandert 3 keer van slug in 6 maanden. Zonder fijn beheer eindigt men met:
/slug-1.html → /slug-2.html/slug-2.html → /slug-3.html/slug-3.html → /slug-4.html
Een request op de eerste URL doet 3 hops vóór aankomst. Google waardeert ketens van meer dan 2 redirects af. Het crawlbudget wordt onnodig verbruikt, en de PageRank vervliegt bij elke hop (verlies van 5 tot 10% per hop volgens de Moz-studies).
De regel: de ketens platslaan. Wanneer een nieuwe redirect wordt aangemaakt, moet het systeem nagaan of de bron-URL al het doel van een andere 301 was, en de oude herschrijven om direct naar het nieuwe doel te wijzen. Geen keten meer, geen hop meer.
Onze module dfredirects: complete 301-manager
Deze stack met de hand implementeren vraagt 7 tot 12 ontwikkeldagen op PrestaShop, plus het onderhoud. Onze module dfredirects voor PrestaShop 8 en 9 industrialiseert de hele mechaniek:
- Redirects 301, 302, 410 configureerbaar vanuit de backoffice, met filterbare en gepagineerde interface.
- Regex- en wildcardpatterns: één regel kan honderden URL’s dekken (
/old-cat/(.*)$ → /new-cat/$1). - Automatische redirect bij slugwijziging van product, categorie, fabrikant, leverancier of CMS-pagina, meertalig en multi-shop.
- 404-monitoring met frequentie, laatste bezoek en referrer. Sorteerbaar op volume om te prioriteren.
- Automatisch platslaan van de ketens: geen cascaderedirects.
- Import/export CSV om massaal te beheren vóór een migratie.
- Traceerbaarheid: auteur, datum, optionele reden per regel.
- Compatibel met PS 8 en 9, zonder Apache/.htaccess afhankelijkheid (werkt ook op Nginx).
- Prestaties: geoptimaliseerde tabel met index, tot 100.000 regels zonder degradatie.
Voor 49 € vermijdt u het verkeersverlies na een migratie en installeert u een duurzaam vangnet tegen de 404-drift.
SEO-veilige migratieprocedure
Stap voor stap de procedure die wij toepassen op migraties PrestaShop 1.7 → 8 of grote herbouwprojecten:
- Vóór de migratie: export van de oude sitemap.xml. Die bevat alle geïndexeerde URL’s.
- Volledige crawl van de oude site met Screaming Frog of equivalent, om alle URL’s op te halen (ook pagina’s buiten de sitemap: filters, paginering).
- Mapping oud → nieuw in CSV: elke oude URL krijgt zijn nieuwe URL. Voor verdwenen URL’s een relevant alternatief doel kiezen (oudercategorie, homepage als laatste redmiddel).
- Import van de CSV in dfredirects vóór of tijdens de omschakeling.
- Test: 50 willekeurige URL’s geverifieerd op een directe 301, zonder keten, naar het juiste doel.
- Indiening van de nieuwe sitemap.xml bij Google Search Console.
- Dagelijkse 404-monitoring gedurende de eerste maand: elke terugkerende 404 wordt omgezet in een 301.
- Audit op 30, 60 en 90 dagen: dekking in Search Console, verloren queries, verificatie van de verkeersstabiliteit.
FAQ
Wat is het verschil tussen 301 en 302?
De 301 is definitief en draagt de PageRank over. De 302 is tijdelijk en draagt niets over. Voor een migratie of een slugwijziging altijd 301 gebruiken. De 302 is voorbehouden aan expliciet tijdelijke gevallen: onderhoud, A/B-test, seizoensredirect.
En de 410 (Gone)?
De 410 zegt tegen Google: deze URL bestaat niet meer en komt niet terug, deïndexeer onmiddellijk. Sneller dan de 404 voor het opschonen van de index. Nuttig voor definitief teruggetrokken producten zonder equivalent. Maar spaarzaam te gebruiken: eenmaal de 410 teruggegeven, is de PageRank verloren.
Hoelang doet Google erover om een 301 in aanmerking te nemen?
De Google-crawl van de oude URL kan enkele dagen tot meerdere weken duren, afhankelijk van de crawlfrequentie. De volledige overdracht van de PageRank naar de nieuwe URL duurt in de praktijk 1 tot 3 maanden. De nieuwe sitemap indienen versnelt het proces.
Kan men tegelijk naar HTTPS redirecten en van domein veranderen?
Ja, en het komt zelfs vaak voor. Een 301 kan protocol (HTTP → HTTPS), domein (oud.com → nieuw.com) en pad combineren. De regel: één enkele 301 per URL, geen keten. Maximaal platslaan.
Hebben de redirects impact op de prestaties?
Een simpele 301 voegt ongeveer 100-200 ms toe aan de responstijd voor de eerste request. Met browsercaching (Cache-Control op de 301) gaan de volgende bezoeken direct naar de nieuwe URL zonder de hop. De kosten zijn verwaarloosbaar buiten meervoudige ketens. Een keten van 3 hops kan daarentegen 500 ms toevoegen, vandaar het platslaan.
Om verder te gaan
Het beheer van de redirects is een van de pijlers van een SEO-veilige migratie. Zie ook onze complete migratiechecklist PrestaShop 1.7 → 8, waarin de 301’s stap 8 van de procedure zijn, en onze gids e-commerce SEO 2026 voor het volledige plaatje van PrestaShop-SEO. Drie complementaire artikelen over dezelfde thematiek: voorbereiden, uitvoeren, beveiligen.
Lees ook: de complete gids e-commerce SEO en Indexing API, IndexNow en AI-bots.
Om in actie te komen: onze modulesselectie voor technische SEO op PrestaShop.
