SEO migratie: nieuwe webshop, dezelfde posities in Google
Bij een migratie verlies je zelden rankings door het nieuwe platform. Je verliest ze door URL's die niet doorverwijzen, content die onderweg korter wordt en een noindex die van staging mee naar live gaat. Wij bouwen de migratie en bewaken de SEO in hetzelfde team. Dus geen SEO-bureau dat achteraf een lijst fouten stuurt, maar redirects, canonicals en structured data die vanaf dag één in de nieuwe shop goed zitten.
- Redirectmapping op basis van Search Console, Analytics en backlinks, niet op aannames
- Volledige crawl van de oude shop, de staging en de live shop, naast elkaar vergeleken
- Acht weken monitoring na livegang, met directe fixes in het platform
Wat is een SEO migratie?
Een SEO migratie is het deel van een webshop-migratie dat ervoor zorgt dat Google je nieuwe shop herkent als dezelfde shop. Elke URL met verkeer, backlinks of omzet krijgt een plek in de nieuwe structuur. Signalen zoals interne links, titels, structured data en canonicals gaan mee. En na livegang meet je of dat ook echt gelukt is.
Het gaat om meer dan platformwissels. Ook een nieuwe URL-structuur binnen Magento, een overstap van Luma naar Hyvä, een domeinwissel, het samenvoegen van twee shops of het toevoegen van een taalversie is een migratie in de ogen van Google. Hoe meer er per URL verandert, hoe groter het risico en hoe langer het herstel duurt.
De rekenstap is eenvoudig. Haalt je shop een groot deel van de omzet uit organisch verkeer, dan is elke week dat categoriepagina's onvindbaar zijn direct zichtbaar in je omzet. De SEO-kant van een migratie is daarom geen bijzaak aan het eind van het project. Het is het document waar het project op rust.
Soorten migraties en hun SEO-risico
Niet elke migratie is even riskant. De vuistregel: hoe meer URL's, templates en content tegelijk veranderen, hoe meer er mis kan gaan.
| Type migratie | Wat verandert er | SEO-risico | Waar het meestal misgaat |
|---|---|---|---|
| Platformwissel (bijv. WooCommerce of Lightspeed naar Magento 2 of Shopify) | URL's, templates, interne links, structured data | Hoog | Ontbrekende redirects, verloren categorieteksten, filter-URL's die ineens indexeerbaar zijn |
| Magento naar Shopify of andersom | URL-structuur door vaste Shopify-prefixen, canonical-logica | Hoog | Elke product- en categorie-URL verandert; redirectplan is het hele project |
| Luma naar Hyvä | Alleen de frontend; database en URL's blijven gelijk | Laag | Structured data, breadcrumbs of headings die in het nieuwe thema ontbreken |
| Domeinwissel of samenvoegen van shops | Hostnaam, soms ook paden | Middel tot hoog | Redirects die naar de homepage wijzen, oude domein te vroeg opgezegd |
| Nieuwe URL-structuur binnen hetzelfde platform | Paden, bijvoorbeeld categoriepad uit product-URL's halen | Middel | Interne links, sitemaps en feeds die nog naar oude paden verwijzen |
| Nieuwe taal of nieuw land erbij | Extra store view of market, hreflang | Middel | Bestaande URL's die verschuiven naar een submap zonder redirect |
Plan een vrijblijvend gesprek over je project
Een half uur via video met de mensen die het werk ook echt doen. Kies hieronder een moment dat jou past.
- Direct met het vaste team, geen tussenlagen
- Concrete feedback op je huidige situatie of plannen
- Eerlijk advies, ook als het antwoord "niet doen" is
- Indicatie van kosten en tijdlijn
Plan een gratis Tech Check
Vrijblijvend jouw uitdagingen bespreken
Of bel direct: 0591-239 299
Redirectmapping op basis van echte verkeersdata
Een redirectplan begint niet bij de nieuwe shop, maar bij een complete lijst van wat er nu bestaat. Alleen een crawl is niet genoeg: die vindt geen URL's die niet meer intern gelinkt zijn maar wel backlinks of verkeer hebben. We combineren daarom vier bronnen: een volledige crawl, de XML-sitemaps, Search Console (pagina's met vertoningen over de laatste zestien maanden) en Analytics (landingspagina's met sessies en omzet). Waar beschikbaar komen daar backlinkdata en serverlogs bij.
Elke URL krijgt een bestemming. Product naar hetzelfde product, categorie naar dezelfde categorie, een opgeheven categorie naar de meest verwante categorie. Nooit massaal naar de homepage: Google behandelt zulke redirects vaak als soft 404, waardoor de waarde van de oude URL alsnog verdwijnt. Producten die niet terugkomen, sturen we naar de categorie waar ze in stonden, of laten we bewust een 410 geven als er geen goed alternatief is.
Prioriteit gaat op data. De URL's die samen het grootste deel van je organische omzet en vertoningen dragen, controleren we handmatig. De lange staart mappen we op regels: een patroon, een SKU-koppeling of een match op URL-key. Daarna testen we het hele bestand automatisch: elke oude URL moet in één stap met een 301 op een URL uitkomen die een 200 geeft. Geen ketens, geen lussen.
Google adviseert redirects bij een site move minimaal een jaar te laten staan. Wij laten ze in de praktijk staan zolang er nog verkeer of backlinks op binnenkomen. Een redirect kost niets, een verloren backlink wel.
Redirects per platform: Magento, Shopify en Laravel
Hoe je redirects inricht, verschilt per platform. Elk platform heeft zijn eigen beperkingen die je vooraf wilt kennen.
Magento 2
Redirects leven in de URL-rewrites-tabel. Zet 'Create Permanent Redirect for URLs if URL Key Changed' aan, en importeer grote redirectlijsten via een script in plaats van met de hand. Let op: duizenden custom rewrites maken de tabel traag als je ze niet opschoont.
Lees verder →Shopify
Redirects beheer je in de admin of via een CSV-import. Shopify voert een redirect alleen uit als er op het oude pad geen pagina meer bestaat. Door de vaste prefixen /products/ en /collections/ verandert bij een overstap vrijwel elke URL.
Lees verder →Laravel en maatwerk
Volledige controle: redirects in een database-tabel met een middleware, of op webserverniveau in nginx. Patronen en regex zijn mogelijk, mits je ze test op ketens en lussen.
Lees verder →Alle migratietrajecten
Het overzicht van alle routes tussen platformen, met per bronplatform wat er technisch meegaat en wat niet.
Lees verder →Crawl voor, tijdens en na de migratie
Drie crawls, dezelfde instellingen, naast elkaar gelegd. Zo zie je per URL wat er veranderd is voordat Google het ziet.
Het vergelijken is waar de waarde zit. Een categoriepagina die op de oude shop 600 woorden tekst had en op de nieuwe 80, is een rankingrisico, ook als de redirect perfect is. Hetzelfde geldt voor een product dat ineens een andere H1 heeft, of breadcrumbs die uit het template zijn verdwenen.
Bij JavaScript-zware frontends crawlen we ook gerenderd. Content die pas na het laden van een script verschijnt, ziet Google later of soms niet. Bij Hyvä en bij Shopify-thema's speelt dat weinig, bij headless-opzetten des te meer.
| Moment | Wat we crawlen | Waar we op letten | Uitkomst |
|---|---|---|---|
| Voor de bouw | De huidige live shop, volledig | Statuscodes, titels, H1's, canonicals, interne links, woordaantal, structured data | Nulmeting en URL-inventaris |
| Op staging | De nieuwe shop achter een wachtwoord | Ontbrekende templates-elementen, canonicals naar staging-hostnaam, filter-URL's, paginering | Lijst met fixes voor livegang |
| Redirecttest | Alle oude URL's tegen de nieuwe omgeving | Eén 301-stap naar een 200, geen ketens, geen 404's | Goedgekeurd redirectbestand |
| Direct na livegang | De live shop en de oude URL-lijst | Noindex, robots.txt, canonicals, sitemaps, hreflang | Bevestiging dat alles indexeerbaar is |
| Week 2, 4 en 8 | De live shop | Nieuwe 404's, verschuivingen in interne links, dubbele URL's | Bijsturing op wat Google echt crawlt |
Staging en noindex: de valkuilen die rankings kosten
De meest pijnlijke migratiefouten zijn geen complexe problemen. Het zijn instellingen die van de testomgeving meegaan naar live.
Staging afschermen
- Staging achter HTTP-authenticatie, niet alleen achter een noindex
- Geen staging-URL's in sitemaps, feeds of e-mails die naar buiten gaan
- Controleren of de staging-hostnaam niet al in de Google-index staat
- Canonicals die naar de staging-hostnaam wijzen, opsporen voor livegang
Bij livegang terugzetten
- Meta robots noindex en X-Robots-Tag-headers verwijderd
- robots.txt zonder Disallow: / en met de juiste sitemapregel
- In Magento: Default Robots onder Content > Design > Configuration op INDEX, FOLLOW voor de live store view
- In Shopify: wachtwoordpagina uit en robots.txt.liquid gecontroleerd
- Canonicals en hreflang met de live domeinnaam
Signalen die mee moeten
- Meta titles en descriptions per URL, niet opnieuw gegenereerd uit een template
- Categorieteksten en FAQ-blokken op categoriepagina's
- Product-, Offer-, Breadcrumb- en Organization-markup
- Alt-teksten van afbeeldingen en bestandsnamen waar die verkeer kregen
- Interne links in content, menu's en footer naar de nieuwe URL's
Buiten de shop
- Google Merchant Center-feed met nieuwe product-URL's
- Search Console en Bing Webmaster Tools voor de nieuwe property, sitemaps ingediend
- Bij een domeinwissel het adreswijzigingstool in Search Console
- Belangrijke backlinks waar mogelijk laten aanpassen naar de nieuwe URL
Wat je de eerste acht weken na livegang meet
Na livegang begint het echte werk. Google moet de oude URL's opnieuw crawlen om de redirects te zien, en dat gaat niet in één dag. Voor een middelgrote shop zie je de meeste verschuivingen in de eerste weken. Bij grote catalogi duurt het langer, omdat Google diep liggende producten minder vaak bezoekt.
We volgen een vaste set signalen. In Search Console: het rapport Pagina's (vooral 'Niet gevonden (404)', 'Pagina met omleiding' en 'Gevonden, momenteel niet geïndexeerd'), de crawlstatistieken en de prestaties per paginatype. In de serverlogs: welke URL's Googlebot bezoekt en welke statuscodes het terugkrijgt. In Analytics: organische sessies en omzet per landingspaginatype, vergeleken met dezelfde periode van vorig jaar zodat seizoenseffecten niet als migratie-effect worden gelezen.
Een tijdelijke dip in de eerste weken is normaal. Blijvend verlies op specifieke categorieën niet. Dat wijst bijna altijd op een concrete oorzaak: een gemiste redirect, een pagina die nu noindex heeft, content die verdwenen is of een canonical die naar de verkeerde URL wijst. Omdat wij de shop zelf gebouwd hebben, lossen we dat op in het platform zelf. Er hoeft geen ticket naar een ander bureau.
Na acht weken leggen we de cijfers naast de nulmeting. Wat is hersteld, wat niet, en waarom. Wat nog openstaat, gaat op de lijst voor regulier onderhoud.
Migreren is ook een kans om SEO-schuld op te ruimen
Een migratie is het moment om dingen recht te zetten die al jaren scheef zitten. Duizenden filter-URL's in de index, dubbele categorieën met bijna dezelfde naam, productpagina's met de leverancierstekst, structured data die nooit gevalideerd is. Je bouwt toch nieuwe templates, dus je kunt het meteen goed doen.
Tegelijk is het verstandig niet alles tegelijk te veranderen. Wie in één migratie het platform wisselt, de URL-structuur omgooit, de categorie-indeling herschrijft én alle teksten vervangt, kan achteraf niet meer zien wat welk effect had. Onze voorkeur: URL's en content zoveel mogelijk een-op-een, en de grote inhoudelijke verbeteringen gefaseerd na livegang, zodat je per stap kunt meten.
Waar de URL-structuur toch moet veranderen, kiezen we voor de structuur die je de komende jaren houdt. Bijvoorbeeld product-URL's zonder categoriepad, zodat een product niet onder drie URL's bestaat en een herindeling van je categorieën niet opnieuw tot redirects leidt.
Wanneer een migratie SEO-technisch beter kan wachten
Midden in je piekseizoen
Na livegang heeft Google tijd nodig. Ga niet live vlak voor Black Friday of je belangrijkste verkoopmaanden; plan het zo dat de herstelperiode in een rustige periode valt.
Lees verder →Zonder nulmeting
Zonder crawl en Search Console-export van de oude shop kun je achteraf niet bewijzen wat er verloren is gegaan, en ook niet herstellen. Eerst meten, dan migreren.
Lees verder →Als alleen de frontend het probleem is
Is je shop traag maar verder gezond? Dan is een frontend-migratie naar Hyvä vaak de veiligere route: zelfde URL's, zelfde data, betere Core Web Vitals.
Lees verder →Als de categorie-indeling nog niet vaststaat
Een nieuwe categoriestructuur betekent nieuwe URL's en dus nieuwe redirects. Leg de indeling vast voordat het redirectplan wordt gemaakt, anders doe je het werk twee keer.
Lees verder →Onze aanpak van een SEO migratie
Zes stappen, uitgevoerd door het team dat ook de migratie zelf bouwt.
- 1
Nulmeting en URL-inventaris
Volledige crawl, exports uit Search Console en Analytics, en waar beschikbaar backlinks en serverlogs. Uitkomst: elke URL die waarde heeft, met verkeer en omzet erbij.
- 2
Doelstructuur en redirectplan
We bepalen de nieuwe URL-structuur en mappen elke oude URL naar de best passende nieuwe URL. Belangrijke URL's handmatig, de lange staart op regels.
- 3
SEO in de templates
Titels, headings, canonicals, structured data, breadcrumbs, paginering en filterregels bouwen we direct in de nieuwe shop. Geen achteraf-plugin.
- 4
Stagingcrawl en redirecttest
We crawlen de nieuwe shop achter een wachtwoord en testen alle redirects automatisch. Fouten gaan terug naar de bouw, niet naar na livegang.
- 5
Livegang-checklist
Noindex eraf, robots.txt goed, sitemaps ingediend, Merchant Center bijgewerkt, Search Console en Bing Webmaster Tools ingericht. Binnen het uur na livegang gecontroleerd.
- 6
Acht weken monitoring
404's, indexering, crawlgedrag en organische omzet per paginatype. Afwijkingen lossen we direct op in het platform, met een eindrapport naast de nulmeting.
Wat je opgeleverd krijgt
- URL-inventaris uit crawl, sitemaps, Search Console, Analytics en backlinkdata
- Redirectbestand met per oude URL de nieuwe bestemming, getest op ketens, lussen en 404's
- Vergelijkende crawl van oude shop en staging, met fixlijst per template
- Livegang-checklist voor noindex, robots.txt, canonicals, sitemaps, hreflang en feeds
- Nulmeting van organische vertoningen, kliks en omzet per paginatype
- Gevalideerde structured data op product-, categorie- en contentpagina's
- Wekelijkse monitoring in de eerste acht weken, met directe fixes
- Eindrapport: herstel per paginatype naast de nulmeting, met openstaande punten
Waarom Coding.nl voor je SEO migratie
Bouw en SEO in één team
Wie de redirects bedenkt, implementeert ze ook. Geen overdracht tussen een SEO-bureau en een bouwpartij waarin details verloren gaan.
Platformkennis tot in de database
We werken dagelijks in Magento 2, Hyvä, Shopify en Laravel. We weten waar elk platform URL's, canonicals en redirects anders afhandelt.
Meten in plaats van hopen
Nulmeting voor, monitoring na. Als RUMvision Gold Partner meten we ook laadtijd en Core Web Vitals bij echte bezoekers, voor en na de overstap.
Eerlijk over timing en route
Soms is de beste SEO-migratie er geen. Is alleen je frontend het probleem, dan zeggen we dat, en kiezen we de route met het kleinste risico.
Verder lezen
- ›Webshop migratie zonder SEO-verlies: redirect-checklist
- ›301-redirects beheren in je webshop: ketens, loops en 410
- ›E-commerce migratie: wanneer en hoe je van platform wisselt
- ›Shopify migratie: de checklist in 9 stappen
- ›Google Search Console voor webshops: de rapporten die tellen
- ›Logfile-analyse voor SEO: wat Googlebot en AI-crawlers doen
- ›Canonical tags in webshops: de 8 fouten die we het vaakst zien
- ›Gevonden, maar niet geïndexeerd in Search Console: oplossen
- ›Van Luma naar Hyvä: het complete migratie-stappenplan
- ›Technische SEO voor webshops — de complete audit checklist
Veelgestelde vragen
Migratie gepland en je wilt je rankings houden?
Vraag een migratiescan aan. We maken een nulmeting van je huidige shop, bekijken welke URL's je omzet dragen en vertellen je eerlijk waar de grootste SEO-risico's van jouw migratie zitten.