301-redirect en 404 na een migratie: wat te controleren

Wat een webwinkel verliest wanneer adressen veranderen

Zoekmachines, externe links, bladwijzers en campagnes verwijzen naar exacte adressen. Als die adressen na een migratie of een wijziging van URL’s 404 geven, indexeert Google ze niet: volgens de documentatie worden URL’s die een 4xx-code teruggeven niet geïndexeerd en worden reeds geïndexeerde URL’s uit de index verwijderd. Een permanente redirect zegt daarentegen dat de pagina bestaat en is verplaatst: Google gebruikt dit als signaal dat de bestemming de canonieke URL is en stelt dat 301’s en andere permanente redirects geen verlies van PageRank veroorzaken. Hoeveel verkeer er in de praktijk verloren gaat, hangt van de site af, en daarom meet u dat met Search Console in plaats van op algemene cijfers te vertrouwen.

De HTTP-codes die ertoe doen

Dezelfde RFC preciseert dat 410 de voorkeur heeft boven 404 wanneer de server weet dat de toestand waarschijnlijk permanent is.

Wat PrestaShop 9.1 zelf doet

Het volgende is geverifieerd in de code van PrestaShop 9.1.5, met de bestanden die in de bronnen worden genoemd.

Omleiding naar de canonieke URL

Onder Winkelinstellingen, Verkeer en SEO, Stel URLs in heeft de optie “Omleiding naar de canonieke URL” (PS_CANONICAL_REDIRECT) de waarde 0 (geen redirect), 1 (302) of 2 (301). In de FrontController antwoordt PrestaShop bij GET-verzoeken, als de gevraagde URL niet overeenkomt met de canonieke, met een 301 wanneer de optie 2 is, anders met een 302, en doet het niets bij 0. De officiële documentatie adviseert 301 zodra de wijzigingen zijn afgerond en waarschuwt dat zonder redirect dubbele URL’s kunnen ontstaan. In ontwikkelmodus verschijnt in plaats van de redirect een debugpagina: houd daar rekening mee bij het testen.

De slug van een product of categorie verandert

De standaardregels zetten het id in de URL ({id}{-:id_product_attribute}-{rewrite}.html voor producten, {id}-{rewrite} voor categorieën). De oude URL, met de vorige slug, vindt het object dus nog steeds en de controller vergelijkt die met de huidige: met de optie op 301 wordt omgeleid, bij 0 antwoorden beide adressen en blijven de duplicaten bestaan.

De URL-structuur verandert

De Dispatcher begint met de controller pagenotfound en vervangt die alleen als de URI overeenkomt met een van de huidige routes, de standaardroutes of de aangepaste (PS_ROUTE_*). De code bewaart de eerdere structuren niet: oude adressen die met geen enkele route meer overeenkomen, komen terecht op een pagina die een echte 404-status teruggeeft. Redirects vanuit de oude structuren moeten apart worden aangemaakt.

Product uitgeschakeld of niet meer beschikbaar

Het veld “Omleiding wanneer offline” op de productpagina (redirect_type) heeft tien waarden: default, 404 en 410 (foutpagina), 200-displayed, 404-displayed en 410-displayed (product getoond als uit de catalogus genomen met die code), 301-category en 302-category (redirect naar een categorie), 301-product en 302-product (redirect naar een ander product). Bij default geldt “Standaardgedrag voor uitgeschakelde producten” (PS_PRODUCT_REDIRECTION_DEFAULT). Een verwijderd product bestaat niet meer en de pagina geeft 404.

Categorie uitgeschakeld of verwijderd

Een uitgeschakelde categorie volgt het veld “Redirection when not displayed” (omleiding wanneer niet getoond): standaard 301, naar de dichtstbijzijnde actieve bovenliggende categorie als er geen andere wordt gekozen, of 302, 410, 404. Een verwijderde categorie geeft 404, en Category::deleteRedirections() zet de producten en categorieën die ernaar omleidden terug op het standaardgedrag.

Migratie vanaf een ander platform

Bij een platformwissel verandert bijna elke URL van vorm: producten, categorieën, pagina’s, afbeeldingen en bestanden. PrestaShop kan de oude adressen niet raden, ze moeten worden verzameld en gekoppeld.

1. Verzamel de oude URL’s. Google stelt voor te beginnen met de sitemaps, de serverlogs of de analytics voor de meest bezochte URL’s, het rapport “Links” van Search Console en de lijst uit het CMS. Het prestatierapport heeft de dimensie “Pagina’s” en een exportknop. Neem afbeeldingen, video’s, JavaScript en CSS mee.
2. Koppel elke URL. Google schrijft dat het belangrijk is de URL’s van de oude site te koppelen aan die van de nieuwe en te bepalen waarheen elk moet verwijzen: de meest relevante pagina, één op één.
3. Behandel wat geen equivalent heeft. Google vraagt dat verwijderde inhoud 404 of 410 teruggeeft. Vermijd het sturen van veel oude URL’s naar één niet-relevante bestemming, zoals de homepage: volgens Google kan dat gebruikers verwarren en kan het als soft 404 worden behandeld. Als meerdere pagina’s in één pagina zijn samengevoegd, is die een legitieme bestemming.
4. Vermijd de veelvoorkomende fouten: redirectketens (Googlebot volgt er maximaal 10, maar Google adviseert naar de eindbestemming te verwijzen en, als dat niet kan, idealiter binnen 3 stappen te blijven en in elk geval onder de 5); lussen; 302 in plaats van 301; interne links, canonical, hreflang en sitemaps die op de oude URL’s zijn blijven staan; redirects naar URL’s die niet bestaan; noindex of robots.txt-blokkades uit de ontwikkelfase die actief zijn gebleven; redirects die te vroeg zijn verwijderd.

Wat u in Search Console moet controleren

• Het rapport “Pagina-indexering”: “Niet gevonden (404)”, “Soft 404”, “Pagina met omleiding” en “Fout met omleiding” (te lange keten, lus, te lange of ongeldige URL). Het rapport zelf zegt dat een 404 niet per se een probleem is als de pagina zonder vervanger is verwijderd, en dat u een 301 moet gebruiken als de pagina is verplaatst.
• De “URL-inspectietool”: de Live URL-test volgt redirects, maar geeft niet aan dat er een is gevolgd en toont ook de uiteindelijke URL niet. Om codes en keten te zien hebt u een opdrachtregeltool of een script nodig.
• Sitemaps: dien de sitemap met de nieuwe URL’s in. Die met de oude kan waarschuwingen over redirects tonen, en dat is normaal.
• De tool “Adreswijziging”: alleen nodig bij een overstap van het ene domein of subdomein naar een ander, niet voor HTTP naar HTTPS, www of niet-www, en ook niet voor paden binnen hetzelfde domein.
• Tijdsduur: voor een kleine tot middelgrote site geeft Google enkele weken aan voor de meeste pagina’s, met tijdelijke schommelingen in de zichtbaarheid.

Checklist

1. Lijst van de oude URL’s met bezoeken en links, uit sitemaps, logs en Search Console.
2. Een-op-een mapping; 404 of 410 voor wat geen equivalent heeft.
3. 301 aan serverzijde voor verplaatste inhoud, 302 alleen als het tijdelijk is.
4. Geen ketens: elke oude URL verwijst naar de eindbestemming, gecontroleerd met een script over de hele lijst.
5. Interne links, canonical, hreflang en sitemaps op de nieuwe URL’s.
6. “Omleiding naar de canonieke URL” op 301 wanneer de webwinkel online is.
7. Monitoring van 404’s en “Pagina-indexering” in de weken na de migratie; redirects zo lang mogelijk behouden, in het algemeen minstens een jaar.

Hoe de module SEO-redirects - beheer van 301/302/404 het doet

• Regels voor 301, 302 en 410 met eenvoudig pad, wildcard (* en ?) of gevalideerde regex, en opties voor de query string (negeren, de volledige URL vergelijken of een parameter vereisen). 410 antwoordt met een echte 410-status en X-Robots-Tag: noindex, voordat het thema wordt geladen.
• De redirect gaat af in de hook actionDispatcher, vóór de opbouw van de pagina: eenvoudige regels worden gevonden met een geïndexeerde zoekopdracht op de hash van het pad, wildcard en regex worden op volgorde beoordeeld.
• De 404-monitor registreert ontbrekende URL’s met aantal verzoeken, laatste toegang, referer en user agent (tot 5.000 verschillende URL’s, aanpasbaar); “Create 301” (301 aanmaken) vult de regel vooraf in.
• Maakt een 301 aan wanneer de slug van een product, een categorie of een CMS-pagina verandert, voor elke taal, als geen enkele regel die URL al dekt.
• Importeert en exporteert CSV (kolommen source, target, type, is_regex, keep_querystring, qs_mode, qs_param, qs_value, active), met de telling van geïmporteerde en overgeslagen rijen: handig om de mapping van een migratie te laden.
• Weigert externe bestemmingen die niet op de webwinkel staan of in een lijst van toegestane hosts (bescherming tegen open redirect).

Bekijk de productpagina van de module of lees de handleiding voor installatie en configuratie.

Bronnen

• RFC 9110, HTTP Semantics: secties 15.4.2, 15.4.3, 15.4.9, 15.5.5 en 15.5.11
• Google Search Central: redirects en Google Search, een site verplaatsen met URL-wijzigingen, HTTP-statuscodes
• Help voor Search Console: Pagina-indexering, URL-inspectietool, Adreswijziging, Prestatierapport
• Code van PrestaShop 9.1.5 op GitHub: FrontController, ProductController, CategoryController, Dispatcher
• PrestaShop-documentatie: SEO en URL’s, productbeheer

Veelgestelde vragen

301 of 302 voor een migratie?

301 (of 308) voor definitief verplaatste inhoud: Google gebruikt dat als een sterk signaal, terwijl 302 een zwak signaal is. De documentatie raadt permanente redirects aan wanneer u er zeker van bent dat ze niet worden teruggedraaid.

Is het verstandig alle oude URL’s naar de homepage om te leiden?

Nee. Google raadt af veel oude URL’s naar één niet-relevante bestemming te sturen: dat kan gebruikers verwarren en kan als soft 404 worden behandeld. Beter de meest relevante pagina, of een 404 of 410 als er geen equivalent is.

Hoe lang moeten redirects behouden blijven?

Google geeft aan ze zo lang mogelijk te behouden, in het algemeen minstens een jaar, zodat de signalen naar de nieuwe URL’s overgaan en externe links opnieuw worden toegewezen.

Leidt PrestaShop de oude URL zelf om wanneer de slug verandert?

Ja, als het id in de URL staat en “Omleiding naar de canonieke URL” op 301 staat (bij 302 is de redirect tijdelijk, bij 0 is er geen redirect). Dat gebeurt niet als de URL-structuur verandert: oude adressen die met geen enkele route meer overeenkomen, geven 404.

404 of 410 voor verwijderde pagina’s?

De standaard geeft de voorkeur aan 410 wanneer de verwijdering waarschijnlijk permanent is. Voor Google worden beide codes op dezelfde manier behandeld, net als alle 4xx-codes behalve 429.

Volstaat de module op zichzelf?

Nee. De module beheert regels, 404-monitor, CSV en automatische 301’s, maar de mapping moet door u worden voorbereid. Ketens en lussen tussen de regels worden niet gecontroleerd en interne links, canonical, hreflang en sitemaps worden niet gecorrigeerd: die moeten met een script en met Search Console worden gecontroleerd.