Wat er de week na een migratie naar PrestaShop misgaat
De dag van de lancering verloopt bijna altijd goed. Dat is een vals signaal
Een migratie die “werkt”, in de strikte zin dat de nieuwe webwinkel draait en bestellingen aanneemt, is relatief eenvoudig te realiseren: producten, prijzen, voorraad en orderhistorie zijn gestructureerde gegevens, importtools verplaatsen ze vrij goed en op de eerste dag lijkt alles in orde. De echte problemen verschijnen niet op de dag van de lancering, maar zeven tot tien dagen later, wanneer bezoekers binnenkomen met een oude URL uit hun bladwijzers, wanneer Google zijn crawl hervat met de kaart van adressen die het kende, en wanneer iemand merkt dat een functie “die er eerder was” is verdwenen, niet omdat iemand haar bewust heeft verwijderd, maar omdat geen enkele importtool er ooit rekening mee heeft gehouden. Dit artikel gaat niet over hoe u migreert (daarvoor bestaan gespecialiseerde diensten, dat is niet ons vak): het gaat over wat u de week erna moet controleren, zodra de webwinkel online is en de lijst met problemen vanzelf begint te groeien.
Dode URL’s, niet bij tientallen: bij honderden
Het meest onderschatte probleem is de schaal. Wie migreert, verwacht “een paar URL’s” te moeten corrigeren, niet de hele structuur van de adressen. In de praktijk deelt bijna geen enkel platform het URL-schema van een ander: een catalogus die op WooCommerce onder /product/product-naam/ stond, op Magento onder /categorie-naam/product-naam.html of op Shopify onder /products/product-naam, komt op PrestaShop terecht met weer een ander schema, dat vaak het numerieke id van het product in het adres bevat. Elke URL die een zoekmachine had geïndexeerd en elke link die een andere site of een klant had opgeslagen, wijst nu naar een pad dat in de nieuwe webwinkel eenvoudigweg niet bestaat. Bij een catalogus van een paar duizend producten, met de categorieën, de geïndexeerde filterpagina’s en de redactionele inhoud, loopt het aantal door te sturen URL’s ook voor een middelgrote webwinkel gemakkelijk op tot enkele honderden: dit is geen randgeval dat alleen voor grote catalogi geldt.
De goede werkwijze, die bijna nooit op tijd wordt toegepast, is om vóór de omschakeling de volledige lijst te exporteren van de URL’s die het oude platform had laten indexeren (uit Google Search Console, niet uit de sitemap van de oude site, die vaak al onvolledig is), en het redirectplan op te bouwen als onderdeel van het migratieproject, niet als correctie nadat de eerste meldingen over verloren verkeer binnenkomen.
De cookiebanner die landen niet meer van elkaar onderscheidt
Een meertalige migratie die haastig is uitgevoerd, neemt bijna altijd teksten en instellingen over die voor de hoofdtaal zijn bedacht, en de configuratie van de cookietoestemming is een van de eerste plekken waar dat opvalt: een banner die het publiek eerst correct per taal of per land onderscheidde, valt na de migratie soms terug op één enkele standaardwaarde, of toont, nog erger, een onvertaalde tekst voor de andere talen (wij hebben in september 2026 in onze eigen module voor cookietoestemming precies zo’n gebrek gevonden en verholpen, niet door een migratie maar om dezelfde onderliggende reden: teksten die slechts twee van de vijf talen dekten). Het loont de moeite om de toestemmingsconfiguratie direct na de omschakeling in elke actieve taal opnieuw te controleren, en niet alleen in de hoofdtaal waarin de tests daadwerkelijk zijn uitgevoerd.
De compliancegegevens die de importtool niet eens kon zoeken
Importtools verplaatsen goed alles wat op het oorspronkelijke platform al als begrip bestond: prijs, beschrijving, afbeeldingen, categorieën. Een veld als “GPSR-fabrikant”, “veiligheidswaarschuwing voor dit specifieke product” of “gemachtigde in de EU” bestond op het oude platform vaak helemaal niet als gestructureerd gegeven, en geen enkele importtool kon het dus overzetten, simpelweg omdat er geen bronveld was om te kopiëren. Het echte risico is een gemigreerde webwinkel die ervan uitgaat dat “als het eerder goed was, het nu ook goed is”, terwijl de compliancelacune, als die er was, er al vóór de migratie was en de migratie haar alleen zichtbaarder maakt doordat u de productgegevens van voren af aan moet heroverwegen.
De interne zoekfunctie die bij nul begint
Als de vorige webwinkel een zoekmachine had die in de loop van de tijd was afgesteld, met synoniemen die met de hand waren toegevoegd nadat klanten een term hadden gezocht zonder iets te vinden, stopwoorden die op de taal van de catalogus waren afgestemd, en een relevantievolgorde die na maanden observeren van wat klanten werkelijk aanklikten was bijgesteld, dan reist niets van die afstelling mee met een productimport. Het is werk dat is gedaan aan het gedrag van de zoekfunctie, niet aan de gegevens van de catalogus, en geen enkele migratietool kan het verplaatsen, omdat het niet eens een “gegeven” is in de gebruikelijke zin: het is opgebouwde configuratie. Het typische symptoom is een daling van de conversies uit de interne zoekfunctie in de eerste weken, niet omdat de nieuwe zoekmachine op zichzelf slechter is, maar omdat die begint met een generieke afstelling in plaats van met maanden aan correcties.
De productfeeds die nog naar het oude schema wijzen
Een Google Shopping-feed of marketplacefeed is gebouwd op de URL’s en de identifiers van het oorspronkelijke platform. Tenzij u de feed na de migratie volledig opnieuw opbouwt op het nieuwe adresschema, blijft elke advertentie wijzen naar een URL die een redirect of, nog erger, een 404 teruggeeft: boven een bepaald percentage kapotte links begint Google Merchant Center de feed te markeren en kan het de weergave van de advertenties opschorten, wat directe en onmiddellijke commerciële schade is en niet alleen een probleem voor de organische vindbaarheid.
Een checklist voor de eerste week
- Vergelijk de lijst met geïndexeerde URL’s van vóór de migratie (uit Search Console) met wat vandaag een 200 teruggeeft: voor elke ontbrekende URL is er ofwel een permanente redirect naar de gelijkwaardige inhoud nodig, ofwel een bewuste afsluiting als de inhoud echt niet meer bestaat.
- Controleer de cookiebanner in elke actieve taal en in elk actief land, niet alleen in de hoofdtaal.
- Controleer de compliancegegevens van de producten (GPSR inbegrepen) opnieuw, uitgaande van de aanname dat de import ze niet heeft overgezet, want dat is vrijwel zeker het geval.
- Volg de conversies uit de interne zoekfunctie de eerste twee weken apart: dat is het snelste signaal om te weten of de configuratie van de zoekfunctie opnieuw moet worden gedaan.
- Bouw de productfeed opnieuw op met het nieuwe URL-schema voordat u de campagnes hervat, niet nadat u de daling hebt vastgesteld.
Kort samengevat
De week na een migratie is geen rustige inloopperiode: het is het moment waarop de problemen verschijnen die de dag van de lancering niet kon laten zien. URL’s die niemand heeft doorgestuurd, instellingen zonder bronveld om te kopiëren, maandenlange afstellingen (zoekfunctie, toestemming, feeds) die nooit als “gegeven” hebben bestaan om te migreren. Een redirectbeheer met 404-monitor, zoals cll_seoredirect, helpt om die lacunes te ontdekken op het moment dat ze ontstaan, in plaats van nadat bezoekers ze al hebben opgemerkt, maar de checklist hierboven blijft geldig, welke tool u ook gebruikt.
