Waarom de migratie van een webshop technisch kan „slagen” en toch al het organische verkeer kan verliezen
We werkten onlangs aan het replatforming van een webshop met meer dan 8.000 eigen producten, al meer dan tien jaar actief, die tegelijk via de eigen site en zeven marketplacekanalen verkocht. Technisch verliep het migratieproject van een webshop zonder SEO-verlies precies zoals het hoort — de catalogus verhuisde netjes, de checkout werkte, het design zag er veel beter uit dan de oude versie. Als we hier waren gestopt, liep de nieuwe site het risico om in de eerste maand een groot deel van het in tien jaar opgebouwde organische verkeer te verliezen.
De reden is simpel en wordt vaak genegeerd: Google herkent niet automatisch dat de nieuwe pagina de „voortzetting” van de oude is. Elk adres dat tien jaar lang geïndexeerd stond, vertegenwoordigt opgebouwd vertrouwen — links, klikken, kwaliteitssignalen — strikt gekoppeld aan dat adres. Als het adres verdwijnt zonder expliciete brug naar zijn nieuwe locatie, verhuist dat vertrouwen niet automatisch mee, maar gaat het simpelweg verloren, en de positie in de zoekmachine start voor die pagina bijna weer vanaf nul.
Fase nul: de volledige inventaris, voordat je iets op de site verandert
Vóór er ook maar één regel code wordt geschreven, heb je een volledige lijst nodig van alles wat vandaag geïndexeerd is: een export van URL's uit Google Search Console, een eigen crawl van de oude site en, indien aanwezig, de actuele XML-sitemap. Het gaat niet alleen om productpagina's — categorieën, filterarchieven op attributen en informatieve pagina's verzamelen doorgaans evenveel links en organische klikken, maar zijn precies het type pagina dat wordt vergeten wanneer het team zich alleen op individuele productpagina's richt.
In ons geval had het oude systeem al een bruikbare naamgevingsconventie — de namen bevatten gestructureerd categorie, attribuut en variant. We gebruikten precies dat patroon als basis voor de nieuwe attribuutstructuur, in plaats van vanaf nul een nieuwe taxonomie te verzinnen. Elk bestaand patroon in oude data, hoe „rommelig” het op het eerste gezicht ook lijkt, is echte informatie over hoe de catalogus is bedacht — en vaak ook over hoe mensen die producten daadwerkelijk zoeken.
Het 301-redirectplan — drie soorten mapping, niet slechts één
Het eerste, meest zichtbare type is de product-naar-product-mapping: elk oud adres van een productpagina krijgt een permanente redirect naar het exacte equivalent op de nieuwe site. Dat klinkt simpel, maar bij een catalogus van duizenden producten telt „exact” — een ruwe mapping, naar een categorie in plaats van het precieze product, geeft een veel zwakker signaal aan de zoekmachine dan een punctuele, correct gerichte redirect.
Het tweede type, vaak genegeerd, is de mapping van categorie- en filterpagina's — de pagina's die producten op merk, attribuut of serie tonen. Deze pagina's verzamelen vaak evenveel organisch verkeer als individuele productpagina's, omdat mensen vaak op generieke categorietermen zoeken, niet alleen op exacte productnamen. Ze weglaten uit het redirectplan betekent het verlies van een aanzienlijk deel van het terugkerende verkeer van de site.
Het derde type is de terugvalregel, voor content die echt verdwijnt — producten die definitief uit de verkoop zijn gehaald, samengevoegde of opgeheven categorieën. Hier is de verleiding om alles naar de hoofdpagina te redirecten, maar een generieke redirect naar de homepage is bijna even schadelijk als helemaal geen redirect: het signaleert aan de zoekmachine dat de oude pagina geen relevant equivalent meer heeft. Richt je liever op de dichtstbijzijnde, écht relevante bovenliggende categorie voor de verdwenen content.
| Type mapping | Van toepassing op | Typische fout |
|---|---|---|
| Product → product | individuele productpagina's | een ruwe redirect, naar een categorie in plaats van naar het product |
| Categorie → categorie | archieven, filters op attribuut of merk | volledig weggelaten uit het migratieplan |
| Terugvalregel | definitief verwijderde content | generieke redirect naar de homepage |
Je bouwt op staging en test gefaseerd, niet in één beweging
De nieuwe site wordt volledig gebouwd op een staging-subdomein, compleet gescheiden van de live site, ongeacht hoe klein de catalogus lijkt of hoe urgent de deadline is. De live site blijft gewoon verkopen terwijl het nieuwe systeem parallel wordt voorbereid, en elke configuratiefout tijdens de bouw blijft volledig onzichtbaar voor klanten en voor Google, omdat de stagingpagina nooit geïndexeerd mag worden.
De migratie van de catalogus verdient het om eerst op een kleine steekproef gevalideerd te worden, vóór het volledige volume — in ons project bracht de import van de eerste 150 producten meteen een mappingfout in de velden aan het licht, die de hele catalogus zou hebben getroffen als we meteen op duizenden producten hadden gedraaid. Een kleine batch, handmatig product per product gecontroleerd, kost enkele uren; diezelfde fout die pas na de volledige import wordt ontdekt, kost dagen aan correcties en soms al gepubliceerde, foutieve redirects.
Een automatische import die „zonder fouten is verlopen” betekent niet „correct is verlopen” — controleer altijd handmatig een steekproef, ook als het script succes meldt.
De technische valkuils die in geen enkele offerte vooraf staan
Productbeschrijvingen die uit oude systemen zijn overgenomen, komen soms dubbel gecodeerd binnen — de HTML-tekst verschijnt als ruwe symbolen op de pagina, in plaats van normale paragrafen, omdat ze bij het export-importproces maar gedeeltelijk zijn „gedecodeerd”. Dat zie je meteen bij een visuele controle, maar het blijft volledig onzichtbaar in een automatisch rapport dat alleen zegt dat de import is geslaagd. De simpele regel: controleer met het blote oog een steekproef van echte pagina's, niet alleen de returncode van het importscript.
De tweede, subtielere valkuil: een SEO-plugin kan de titel en de metabeschrijving perfect berekenen in het beheerpaneel, maar ze helemaal niet naar de publieke pagina sturen als hij bij installatie niet volledig is geconfigureerd. Van buitenaf lijkt de site geoptimaliseerd — de editor toont goede scores — maar de broncode die naar Google gaat, bevat die metadata niet. De enige betrouwbare controle is de broncode van de gepubliceerde pagina te openen, niet de score in het interne paneel van de plugin.
De cutover — hoe je overstapt naar het nieuwe systeem zonder dat de verkoop instort
De daadwerkelijke overstap gebeurt in een venster met weinig verkeer, waarbij de oude site nog een tijd bereikbaar blijft, op zijn minst op domeinniveau, precies zodat de 301-redirects ergens vanuit kunnen vertrekken. De oude server direct na de lancering abrupt stopzetten, verandert elk oud adres in een directe fout in plaats van een werkende redirect — precies het scenario dat het hele migratieplan probeert te vermijden.
Wanneer de webshop ook op marketplaces verkoopt via automatische voorraadsynchronisatie, wordt die synchronisatie pas in de allerlaatste fase van de cutover aan het nieuwe systeem gekoppeld, niet tijdens het bouwen op staging. Anders loop je het risico dat een systeem dat nog in test is, verkeerde voorraden of prijzen naar live kanalen pusht, met echte bestellingen erachter — een veel duurdere fout dan welk SEO-probleem dan ook.
Wat je dagelijks in de gaten houdt in de eerste weken na de lancering
Het dekkingsrapport in Search Console wordt voor een paar weken het belangrijkste werkinstrument — elke plotselinge toename van 404-fouten of pagina's „geïndexeerd, maar met problemen” toont precies waar het redirectplan gaten heeft. Snel reageren is enorm belangrijk: een fout die binnen twee dagen wordt opgemerkt en gecorrigeerd, is een klein incident; diezelfde fout drie weken laten liggen, wordt voor die periode onomkeerbaar verloren verkeer.
Posities in de zoekmachine schommelen normaal gesproken enkele weken na elke grote migratie, zelfs als alles correct is uitgevoerd — het is een herkalibratieperiode, niet noodzakelijk een teken van een fout. Het verschil tussen „normaal” en „echt probleem” zie je door het verkeer per grote categorie te vergelijken, niet per individuele term: een wijdverspreide, aanhoudende daling over alle belangrijke categorieën verdient wél meteen onderzoek, niet alleen passieve monitoring. Over de organische groei na migratie hebben we apart beschreven hoe we werken aan SEO voor webshops.
- 01Controleer de eerste twee weken dagelijks het dekkingsrapport in Search Console.
- 02Vergelijk het organische verkeer op grote categorieën, niet alleen op individuele pagina's.
- 03Controleer handmatig, op een steekproef, dat de 301-redirects echt werken, niet alleen dat ze in de configuratie bestaan.
- 04Houd de oude site op domeinniveau bereikbaar zolang de redirects actief zijn.
- 05Evalueer het redirectplan na de eerste maand opnieuw, op basis van de echte fouten die Google meldt.
Bronnen en verder lezen.
Veelgestelde vragen
Hoe lang duurt het om volledig te herstellen na een platformmigratie?
Normaal gesproken een paar weken voordat de posities stabiliseren, als het redirectplan vanaf het begin goed is gedaan. Een migratie zonder redirectplan kan maanden van gedeeltelijk herstel betekenen, niet slechts een tijdelijke onderbreking.
Heb ik ook een 301-redirect nodig voor categorie- of filterpagina's?
Ja — categorieën en filterarchieven verzamelen vaak vergelijkbaar organisch verkeer als individuele productpagina's, en zijn precies het type pagina dat het vaakst wordt weggelaten uit een gehaast migratieplan.
Wat verandert er als de migratie ook een domeinwijziging inhoudt, niet alleen een platformwijziging?
Er komt een verplichte extra stap bij: het hulpmiddel voor adreswijziging in Search Console, naast het 301-redirectplan. Zonder dat is het „verhuis”-signaal naar Google onvolledig, ook al werken de redirects technisch prima.
Hoe weet ik of ik verkeer heb verloren door de migratie en niet om een andere reden?
Je vergelijkt de periode vóór en na de migratie, op dezelfde productcategorieën, gekoppeld aan het dekkingsrapport in Search Console. Een algemene daling, precies op de dag van de cutover, wijst vrijwel altijd op de migratie, niet op een algoritmewijziging.
Loont het om de oude site nog een tijdje actief te houden na de lancering van de nieuwe?
Ja, op zijn minst op domein- en redirectserverniveau — 301-redirects hebben een actieve bron nodig om vanuit te vertrekken. Het abrupt stopzetten van het oude systeem verandert elk geïndexeerd adres in een directe fout.
Wat doe ik met producten die helemaal niet meer in de nieuwe catalogus bestaan?
Je redirect ze naar de dichtstbijzijnde relevante bovenliggende categorie, niet naar de hoofdpagina. Als het product echt geen equivalent meer heeft, is een correcte foutpagina soms eerlijker dan een geforceerde, irrelevante redirect.
Laten we kijken wat we bij jou kunnen automatiseren.
Een gratis sessie van 30 minuten: we vertellen je wat er te automatiseren valt, hoe lang het duurt en wat het kost, met een vaste prijs na de discovery.