Vorig jaar hebben we een e-commerce site met 34.000 pagina's gemigreerd van een monolithische WordPress-installatie naar een headless architectuur met Next.js en een headless CMS. Het organische verkeer van de klant was goed voor 72% van hun omzet. Geen druk dus, toch?

De migratie nam 14 weken planning en 6 weken uitvoering in beslag. Toen we de schakelaar omsloegen, daalde het organische verkeer met 3,2% in week één, herstelde zich in week drie en was met 11% gestegen tegen maand twee. Dat is geen geluk -- dat is proces.

Ik heb gezien dat migraties catastrofaal fout gingen. Een concurrent van dezelfde klant was zes maanden eerder gemigreerd en had 's nachts 40% van hun organische verkeer verloren. Acht maanden later waren ze nog steeds niet hersteld. Het verschil tussen een succesvolle grootschalige migratie en een ramp komt neer op voorbereiding, redirectmanagement en het hebben van een rollback-plan waar je echt op kunt vertrouwen.

Dit artikel behandelt alles wat we doen bij het migreren van sites met tienduizenden pagina's. Het is hetzelfde proces of je nu van WordPress naar Next.js gaat, van Drupal naar Astro of een ander platform.

Inhoudsopgave

Een website met 30.000 pagina's migreren zonder SEO-verlies

Waarom grootschalige migraties mislukken

De meeste migratiefouten hebben dezelfde wortels. Dit begrijpen vooraf voorkomt dat je aansluit bij het kerkhof van mislukte launches.

Het redirect-probleem

Op een site met 500 pagina's kun je elke URL handmatig in kaart brengen. Op een site met 30.000 pagina's kun je dat niet. Teams eindigen met regex-gebaseerde redirect-regels die 90% van de URL's dekken en gaan ervan uit dat de resterende 10% zich vanzelf zal regelen. Die resterende 10%? Dat zijn 3.000 pagina's. Waarvan veel je best presterende content.

Een onderzoek van Ahrefs uit 2025 vond dat sites met meer dan 15% geïndexeerde pagina's die tijdens migratie verloren gingen, een gemiddeld organisch verkeerdaling van 34% ervoeren. En herstel duurde gemiddeld 4-8 maanden.

Het pariteitsprobleem

Google geeft niet alleen om content -- het geeft om structuur. Interne linkingpatronen, koppelingenhiërarchieën, structured data, canonical tags, paginahandeling, faceted navigatie. Verander te veel van deze gelijktijdig en Google moet je hele site eigenlijk opnieuw evalueren.

Het timingprobleem

Ik heb teams gezien die maanden hebben doorgebracht aan het perfectioneren van de nieuwe site en daarna de migratie hebben overhaast omdat de leiding ongeduldig is. Je migreert geen site met 30.000 pagina's op vrijdagmiddag. Je migreert niet tijdens je drukste verkeersseizoen. En je migreert zeker niet zonder een geteste rollback-plan.

Fase 1: Pre-migratie audit en crawl

Voordat je iets aanraakt, heb je een compleet beeld van wat er vandaag bestaat. Dit is je baseline, en je zult er voortdurend naar verwijzen tijdens de migratie.

Volledige site-crawl

Voer een volledige crawl uit met Screaming Frog, Sitebulb of een cloud-gebaseerde crawler zoals Lumar (voorheen Deepcrawl). Voor 30.000+ pagina's heb je de cloud-optie nodig -- desktop-crawlers kunnen niet tegen sites van deze grootte, en je hebt de crawldata nodig die je kunt delen met je team.

Vang alles op:

  • Elke URL en HTTP-statuscode
  • Title tags en meta beschrijvingen
  • H1 tags
  • Canonical tags
  • Hreflang tags (indien van toepassing)
  • Interne links (zowel inkomend als uitgaand per pagina)
  • Aanwezig structured data-types
  • Laadtijden pagina's
  • Woordaantal per pagina
  • Afbeeldingen en alt-tekst

Analyticbaseline

Exporteer de afgelopen 12 maanden Google Analytics en Google Search Console gegevens. Je hebt nodig:

  • Top 1.000 landing pages op organische sessies
  • Top 5.000 queries op klikken en impressies
  • Crawlstats (pagina's die per dag worden gekropen, responsetijden)
  • Core Web Vitals-scores
  • Index coverage-rapport (geïndexeerd, uitgesloten, fouten)

Marker je top 500 organische landing pages. Dit zijn de pagina's die niet kapot kunnen gaan. Punt. Elk daarvan wordt individueel geverifieerd tijdens en na migratie.

Trek backlink-gegevens uit Ahrefs, Semrush en Google Search Console. Kruisverwijzing om elke URL te vinden die externe links naar zich toe heeft. Deze URL's hebben perfecte 301-redirects nodig -- backlink-equity verliezen op high-authority pagina's is een van de snelste manieren om rankings omlaag te halen.

# Voorbeeld: Exporteren en dedupliceren van URL's met backlinks
ahrefs-export.csv + semrush-export.csv + gsc-export.csv
| sort -u 
| awk -F',' '{print $1}' 
> unique_backlinked_urls.txt

wc -l unique_backlinked_urls.txt
# Output: 8.247 unieke URL's met backlinks

Fase 2: URL-mapping en redirectstrategie

Dit is waar migraties gewonnen of verloren worden. Op een site met 30.000 pagina's heb je een systematische benadering nodig die automatische mapping combineert met handmatige verificatie voor kritische pagina's.

De redirectmap bouwen

Begin met het categoriseren van je URL's in patronen. De meeste grote sites hebben een relatief klein aantal URL-patronen dat de meerderheid van de pagina's omvat:

URL-patroon Voorbeeld Paginaantal Strategie
Productpagina's /products/blue-widget-123 18.000 Regex + ID-mapping
Categoriepagina's /category/widgets 450 Handmatige mapping
Blogartikelen /blog/2024/03/post-title 3.200 Slugbehoud
Tag/filterpagina's /products?color=blue 6.500 Evalueer: redirect of noindex
Statische pagina's /about, /contact 85 Handmatige mapping
Gepagineerde pagina's /category/widgets/page/3 1.800 Map naar nieuwe paginering

De drielaagse aanpak

Laag 1: Handmatige mapping (top 500 pagina's) Je pagina's met het meeste verkeer en inkomsten krijgen individueel in kaart gebracht. Een mens verifieert elke redirect. Geen uitzonderingen.

Laag 2: Pattern-gebaseerde mapping (volgende ~25.000 pagina's) Schrijf transformatieregels die oude URL-patronen naar nieuwe converteren. Test deze regels tegen je volledige URL-lijst voordat je ze implementeert.

# Voorbeeld redirect rule generatie
import csv
import re

def generate_redirect(old_url):
    # Productpagina's: /products/blue-widget-123 -> /shop/blue-widget
    product_match = re.match(r'/products/([a-z-]+)-(\d+)$', old_url)
    if product_match:
        slug = product_match.group(1)
        return f'/shop/{slug}', 301
    
    # Blogartikelen: /blog/2024/03/post-title -> /blog/post-title
    blog_match = re.match(r'/blog/\d{4}/\d{2}/(.+)$', old_url)
    if blog_match:
        slug = blog_match.group(1)
        return f'/blog/{slug}', 301
    
    return None, None

# Verwerk alle URL's
with open('all_urls.csv') as f:
    reader = csv.reader(f)
    unmapped = []
    for row in reader:
        old_url = row[0]
        new_url, status = generate_redirect(old_url)
        if new_url is None:
            unmapped.append(old_url)
    
    print(f"Niet in kaart gebrachte URL's: {len(unmapped)}")

Laag 3: Resterende niet in kaart gebrachte pagina's (~4.500 pagina's) Deze zijn je randgevallen. Ga ze handmatig door. Sommigen zijn pagina's die je opzettelijk uit fase haalt (redirect naar dichtst relevante pagina). Sommige zijn URL's die je hebt gemist in je patternanalyse. Laat geen 404's achter voor pagina's met verkeer of backlinks.

Redirect-ketens en lussen

Als de oude site al redirects heeft, kunnen je nieuwe redirects ketens veroorzaken (A → B → C). Los deze op voordat je live gaat. Elke redirect moet direct van oude URL naar uiteindelijke bestemming gaan in één sprong. Redirect-ketens laten PageRank weglekken -- Google's John Mueller heeft meerdere keren bevestigd dat ze ketens wel volgen, maar een directe redirect is altijd beter.

Een website met 30.000 pagina's migreren zonder SEO-verlies - architectuur

Fase 3: Technische SEO pariteitscontrole

De nieuwe site moet technische SEO-pariteit met de oude site behouden -- en deze idealiter verbeteren. Dit is wat we controleren:

Kritieke pariteitspunten

  • Title tags: Hetzelfde of beter. Laat ze nooit leeg tijdens migratie.
  • Meta beschrijvingen: Draag ze over, zelfs als je ze later wilt herschrijven.
  • H1-structuur: Één H1 per pagina, matching de keywordtargeting van de oude site.
  • Canonical tags: Zelfverwijzende canonicals op elke pagina. Als de oude site cross-domain canonicals had, behoud deze.
  • Robots.txt: Blokkeer Googlebot niet per ongeluk bij launch. Ik heb dit vaker zien gebeuren dan me lief is.
  • XML Sitemaps: Genereer nieuwe sitemaps met alle nieuwe URL's. Submit binnen uren na launch.
  • Structured data: Migreer alle schema-markup. Productschema, FAQ-schema, breadcrumbschema -- alles.
  • Interne linking: De interne linkgrafiek van de nieuwe site moet die van de oude site nauw volgen.

Prestatievereisten

Google's Core Web Vitals zijn rankingfactoren. Je nieuwe site moet de prestatiewaarden van de oude site evenaren of verbeteren:

Metriek Goede drempel Doel
LCP (Largest Contentful Paint) ≤ 2,5s ≤ 2,0s
INP (Interaction to Next Paint) ≤ 200ms ≤ 150ms
CLS (Cumulative Layout Shift) ≤ 0,1 ≤ 0,05
TTFB (Time to First Byte) ≤ 800ms ≤ 400ms

Dit is één gebied waar migratie naar een moderne stack zoals Next.js of Astro je eigenlijk voordeel geeft. Statische generatie en edge rendering kunnen TTFB dramatisch verbeteren. We hebben gezien dat TTFB van 1,2s naar minder dan 200ms daalde bij verplaatsing van traditionele WordPress naar Next.js met ISR of Astro met statische output.

Fase 4: Content-migratie en validatie

Geautomatiseerde content-extractie

Voor 30.000 pagina's heb je geautomatiseerde content-extractie nodig. We bouwen doorgaans custom scrapers of gebruiken de API's van de CMS om content in een gestructureerde indeling (meestal JSON of CSV) uit te puilen voordat we naar de nieuwe headless CMS importeren.

Key validaties na import:

  • Tekencodering (let op verbroken speciale tekens)
  • Afbeeldingsverwijzingen (lossen alle afbeeldingen op?)
  • Interne links (zijn deze geüpdatet naar nieuwe URL-patronen?)
  • Ingesloten media (video's, iframes, widgets)
  • Tabelopmaak
  • Codeblokken

Content diff testing

We voeren geautomatiseerde vergelijkingen uit tussen oude en nieuwe pagina's voor onze top 500 URL's. Het script haalt beide versies op, verwijdert HTML en vergelijkt de tekstinhoud. Elke pagina met minder dan 95% tekstovereenkomst wordt gemarkeerd voor handmatige beoordeling.

// Vereenvoudigde contentvergeelijking
const { diff } = require('fast-diff');
const cheerio = require('cheerio');

async function comparePages(oldUrl, newUrl) {
  const oldHtml = await fetch(oldUrl).then(r => r.text());
  const newHtml = await fetch(newUrl).then(r => r.text());
  
  const oldText = cheerio.load(oldHtml)('main').text().trim();
  const newText = cheerio.load(newHtml)('main').text().trim();
  
  const changes = diff(oldText, newText);
  const unchanged = changes
    .filter(([type]) => type === 0)
    .reduce((sum, [, text]) => sum + text.length, 0);
  
  const similarity = unchanged / Math.max(oldText.length, newText.length);
  
  return {
    similarity: Math.round(similarity * 100),
    oldLength: oldText.length,
    newLength: newText.length,
    needsReview: similarity < 0.95
  };
}

Fase 5: Staging environment testen

Lunch een migratie nooit zonder grondige staging-tests. Dit valideren we:

Redirect-testing

Test elke redirect. Ja, alle 30.000. Gebruik een script dat de redirectketen volgt en de uiteindelijke bestemming valideert:

# Test redirects uit mapping-bestand
while IFS=, read -r old_url new_url; do
  response=$(curl -s -o /dev/null -w "%{http_code} %{redirect_url}" "$old_url")
  status=$(echo $response | cut -d' ' -f1)
  redirect=$(echo $response | cut -d' ' -f2)
  if [ "$status" != "301" ] || [ "$redirect" != "$new_url" ]; then
    echo "FAIL: $old_url -> $status $redirect (verwacht 301 $new_url)"
  fi
done < redirect_map.csv

Renderingvalidatie

Als je client-side rendering (CSR) of hydratieintensieve benaderingen gebruikt, verificeer dat Googlebot je content werkelijk kan zien. Gebruik Google's Rich Results Test of het URL Inspection-hulpmiddel in Search Console om weergegeven output te controleren.

Dit is een bijzonder veelvoorkomend probleem met React-gebaseerde frameworks. Als je content JavaScript nodig heeft om te renderen en je hebt SSR of SSG niet correct geïmplementeerd, ziet Google misschien een lege pagina. We gebruiken altijd server-side rendering of statische generatie voor SEO-kritieke pagina's.

Fase 6: Launch-dag uitvoering

De launchcontrole

  1. DNS TTL: Verlaag DNS TTL naar 300 seconden minimaal 48 uur voor migratie
  2. Deploy redirects: Get alle 301-redirects live op de oude server/CDN
  3. Omschakelen DNS: Wijs domein naar nieuwe infrastructuur
  4. Verify redirects: Voer geautomatiseerde redirecttests uit tegen productie
  5. Sitemaps indienen: Dien nieuwe XML-sitemaps in via Google Search Console
  6. Indexering aanvragen: Gebruik het URL Inspection-hulpmiddel om indexering van je top 50 pagina's aan te vragen
  7. Monitor: Kijk naar real-time analytics op afwijkingen
  8. Verify robots.txt: Bevestig dat Googlebot niet is geblokkeerd
  9. Check CDN/caching: Zorg ervoor dat redirect-headers niet onjuist in cache worden opgeslagen

Timing

Launch op een dinsdag of woensdagochtend. Nooit vrijdag. Je wilt minstens 3 volle werkdagen hebben om te monitoren en problemen op te lossen voordat het weekend begint. Vermijd launch tijdens drukke verkeersperioden of grote winkelgebeurtenissen.

We zorgen er ook voor dat iemand de nacht na de launch monitort. Google crawlt vaak agressiever tijdens rustige uren, en als je redirects problemen hebben, wil je dat snel opvangen.

Rollback-plan

Heb een geteste rollback-plan dat in minder dan 15 minuten kan worden uitgevoerd. Dit betekent meestal dat je de oude infrastructuur gedurende minstens 2 weken na migratie parallel blijft draaien. De kosten voor het onderhouden van twee omgevingen tijdelijk zijn niets vergeleken met de kosten van een mislukte migratie.

Fase 7: Monitoring na migratie

Dagelijks monitoring (weken 1-2)

  • Crawlfouten: Controleer Google Search Console dagelijks op nieuwe 404's en serverfouten
  • Indexdekking: Monitor het dekkiningsrapport op dalingen
  • Organisch verkeer: Vergelijk dagelijkse organische sessies met je baseline
  • Rankings: Volg je top 200 trefwoorden dagelijks
  • Serverlogboeken: Analyseer Googlebots crawlpatronen op de nieuwe site
  • Core Web Vitals: Verifieer veldgegevens naarmate deze binnenkomt

Wekelijks monitoring (weken 3-8)

  • Vergelijk organisch verkeer week-over-week
  • Monitor op rankingvolatiliteit
  • Controleer op nieuwe crawlproblemen
  • Verifieer dat redirect-ketens niet per ongeluk zijn gemaakt
  • Monitor backlink-profiel op verloren links

Verwachte verkeerspatronen

Een goed uitgevoerde migratie toont doorgaans:

  • Week 1: 5-15% verkeerdaling (Google verwerkt de wijzigingen)
  • Week 2-3: Herstel naar pre-migratieniveaus
  • Week 4-8: Als de nieuwe site technisch superieur is, zie je vaak een verkeerstoename

Als je een daling van 30%+ ziet die niet tegen week 3 herstelt, is er iets fout gegaan met je redirects of technische implementatie. Dig onmiddellijk in Search Console.

Redirect-implementatie op schaal

Waar je redirects implementeert, doet ertoe. Voor 30.000+ redirects, stop ze niet allemaal in een .htaccess bestand of een Next.js redirects config array -- dat vernietigt de prestaties.

Aanbevolen benaderingen

Edge-level redirects (best voor prestaties) Implementeer redirects op edge/CDN-niveau met Cloudflare Workers, Vercel Edge Middleware of Netlify's _redirects bestand. Edge-redirects voeren uit voordat je applicatiecode, dus ze zijn extreem snel.

// Vercel Edge Middleware voorbeeld
import { NextResponse } from 'next/server';
import type { NextRequest } from 'next/server';

// Laad redirectmap (pre-built bij deploy)
import redirectMap from './redirects.json';

export function middleware(request: NextRequest) {
  const path = request.nextUrl.pathname;
  const redirect = redirectMap[path];
  
  if (redirect) {
    return NextResponse.redirect(
      new URL(redirect.destination, request.url),
      redirect.permanent ? 301 : 302
    );
  }
  
  return NextResponse.next();
}

Database-gestuurde redirects (best voor flexibiliteit) Bewaar redirects in een database en zoek ze op aanvraagtijd op. Hiermee kun je redirects toevoegen, wijzigen en controleren zonder opnieuw in te stellen. Voeg agressief caching toe (Redis of vergelijkbaar) zodat de databasezoeking geen latentie toevoegt.

Hybride benadering (wat we meestal doen) Pattern-gebaseerde redirects op de edge, individuele redirects in een database. Beste van beide werelden.

Internationale en meertalige sites afhandelen

Als je 30.000-pagina site meerdere talen of regio's bevat, vermenigvuldigt de complexiteit. Elke taalversie heeft zijn eigen redirectmap nodig. Hreflang-tags moeten worden geupdate om naar nieuwe URL's te verwijzen. En je moet verifiëren dat de taal-/gebiedstargeteing in Search Console nog steeds correct werkt.

Veelgemaakte fouten:

  • Het vergeten om hreflang-aantekeningen tegelijk over alle taalversies bij te werken
  • Het verbreken van de hreflang wederkerige vereiste (als pagina A naar pagina B wijst, moet pagina B terug naar pagina A wijzen)
  • Taaltaal-specifieke URL-structuren verliezen die Google als signalen gebruikt

Veelgemaakte fouten die rankings vernietigen

  1. 302 gebruiken in plaats van 301: Tijdelijke redirects geven geen volledige link equity door. Controleer je redirectstatuscodes driemaal.
  2. De staging-site blokkeren en vergeten te deblokkeren: Je robots.txt op staging zegt Disallow: /. Je implementeert staging voor productie. Googlebot kan niets crawlen.
  3. Content en URL's tegelijk wijzigen: Google ziet een nieuwe URL met verschillende content. Is het een nieuwe pagina? Een verplaatste pagina? Verminder onduidelijkheid -- migreer URL's eerst, wijzig content later.
  4. Alles naar de homepage omleiden: Lui redirect-implementaties die alle oude URL's naar de homepage sturen vernietigen je longtail-rankings onmiddellijk.
  5. JavaScript-rendering negeren: Je nieuwe React-app ziet er geweldig uit in Chrome. Googlebot ziet een lege <div id="root"></div>.
  6. Niet consistent omgaan met slashes: /products/widget en /products/widget/ zijn verschillende URL's. Kies er één en leid de ander om.
  7. Pagina's verwijderen zonder redirects: Als een pagina verkeer had, heeft deze een redirect nodig. Zelfs als je die content aan het faseren bent, redirect naar de dichtst relevante pagina.

Tools en stack die we gebruiken

Tool Doel Kosten (2026)
Screaming Frog Desktop-crawling €259/jaar
Lumar (Deepcrawl) Cloud-crawling voor grote sites Aangepaste prijzen
Ahrefs Backlink-analyse, rankingtracking Vanaf €129/maand
Google Search Console Indexmonitoring, crawlstats Gratis
Redirectchecker.com Bulk redirect-testing Gratis tier beschikbaar
ContentKing Real-time SEO monitoring Vanaf €99/maand
Custom Python/Node scripts Redirect-mapping, content diffing Je tijd

Voor de werkelijke sitebouw gebruiken we doorgaans Next.js of Astro, afhankelijk van de behoeften van het project, gekoppeld aan een headless CMS zoals Sanity, Contentful of Storyblok. Als je een migratie plant en architectuur wilt bespreken, bekijk onze prijsstelling of neem contact op.

Veelgestelde vragen

Hoe lang duurt het om een website met 30.000 pagina's te migreren? Verwacht 12-20 weken totaal. De planning en URL-mappingfase duurt het langst -- meestal 8-14 weken. De werkelijke technische migratie en launch is doorgaans 4-6 weken. Haast in de planningsfase is de enkele grootste voorspeller van migratiefouten.

Zal ik zeker enig SEO-verkeer verliezen tijdens migratie? Een tijdelijke daling van 5-15% is normaal en verwacht, zelfs met een perfecte migratie. Google heeft tijd nodig om tienduizenden redirects te verwerken en je nieuwe site opnieuw te crawlen. De daling zakt doorgaans binnen 2-3 weken weg. Als je een groter verlies ziet of het herstelt niet, onderzoek je redirects en technische implementatie onmiddellijk.

Moet ik mijn URL-structuur wijzigen tijdens migratie? Alleen als daar een sterke reden voor is. Elke URL-wijziging voegt risico toe. Als je huidige URL-structuur functioneel en beschrijvend is, behoud deze. Als het echt slecht is (bijv. URL's met queryparameters in plaats van schone paden), is de migratie een gelegenheid om dit te repareren -- maar plan je redirectmap dienovereenkomstig.

Kan ik mijn site in fasen migreren in plaats van alles tegelijk? Ja, en voor zeer grote sites is het vaak de veiliger aanpak. Je kunt sectie per sectie migreren -- blog eerst, dan productpagina's, dan categoriepagina's. Dit vermindert risico maar verhoogt complexiteit omdat je twee platforms tegelijk draait, meestal achter een reverse proxy. We hebben dit meermaals met succes gedaan, maar het vereist voorzichtige routingconfiguratie.

Wat gebeurt er met mijn Google Ads tijdens migratie? Update je advertentie-landingspagina URL's naar de nieuwe URL's voor of onmiddellijk na migratie. Als je redirects hebt, werken je advertenties nog steeds, maar de redirect voegt latentie toe en Google Ads-kwaliteitsscores kunnen negatief worden beïnvloed door redirect-ketens. De URL's rechtstreeks bijwerken is altijd beter.

Hoe ga ik om met pagina's die ik tijdens migratie wil verwijderen? Als de pagina organisch verkeer of backlinks had, leid deze om naar de meest relevante bestaande pagina op de nieuwe site. Als het geen van beide had, kun je laten terugkeren naar een 404 of 410 (Gone)-status. Leid niet-relevante pagina's niet naar je homepage um -- Google behandelt massamassakleidingen als zachte 404's.

Moet ik 301 of 308 redirects gebruiken? Gebruik 301 in de meeste gevallen. Beide zijn permanente redirects, maar 301 wordt universeel begrepen door alle bots en browsers. 308 behoudt de HTTP-methode (POST blijft POST), wat uitmaakt voor API-eindpunten maar niet voor SEO-gerichte pagina-redirects.

Wanneer moet ik de oude redirects verwijderen? Behoud deze minstens één jaar, bij voorkeur oneindig. Redirects zijn goedkoop in onderhoud, en het verwijderen betekent dat alle oude bladwijzers, externe links of gecachte zoekresultaten 404's raken. Er is bijna nooit een goed moment om werkende 301-redirects te verwijderen.