Zet server-side 301’s in voor elke permanente verhuizing en test elke één-op-één mapping in staging vóórdat je live gaat. Geen massale doorverwijzingen naar de homepage, geen redirectketens die linkwaarde laten weglekken. Bouw je migratie zo op, dan houd je enkele weken na livegang zicht op wat er gebeurt en kun je snel bijsturen als het misgaat.
Kort samengevat:
- Alleen server-side 301’s of 308’s gebruiken voor permanente verhuizingen, zonder ketens of tussenliggende pagina’s, om linkwaarde optimaal te behouden.
- Vooraf een nulmeting uitvoeren met verzameling van sitemaps, Search Console, analytics, backlinks en serverlogs, om de juiste prioriteit te bepalen.
- Elke oude URL krijgt één nieuwe URL, tenzij echt niet mogelijk, dan is een 410 of 404 de betere keuze dan een irrelevante redirect.
- Redirects testen vóór livegang met tools als curl en Screaming Frog, en ketens van meer dan één hop voorkomen omdat ze waarde kosten.
- Na livegang dag 0 tot 7 intensief monitoren op crawlfouten, indexatie en verkeer, en bij blijvende achterstand snel ingrijpen met aanvullende redirects of correcties.
Inhoudsopgave
- Stap 1: inventarisatie en nulmeting bij je redirects seo migratie
- Stap 2: redirect-mapping — hoe kies je de juiste bestemming
- Stap 3: implementatiemethoden en de juiste statuscodes
- Stap 4: testen in staging — hoe voorkom je ketens en loops
- Stap 5: wat meet je na livegang en wanneer grijp je in
- Veelgemaakte fouten die je rankings direct kosten
- Ramons praktijkinzicht: de 90 dagen die het verschil maken
- Wanneer redirects níet de juiste oplossing zijn
- Hoe Ramon je helpt bij een schone redirectmigratie
- Bronnen
- Veelgestelde vragen
Stap 1: inventarisatie en nulmeting bij je redirects seo migratie
Elke redirects SEO migratie begint met een nulmeting. Zonder die foto van je huidige site weet je straks niet wat je verloren hebt, en dat merk je meestal te laat.
Verzamel eerst je bronnen. Je hebt er minimaal vier nodig:
- De XML-sitemap van de oude site, voor een compleet overzicht van geïndexeerde URL’s.
- Search Console, gefilterd op pagina’s met clicks en impressies over de laatste 16 maanden.
- Analytics of GA4, voor sessies, conversies en landingspaginawaarde per URL.
- Backlinkdata uit tools zoals Ahrefs, Majestic of LinkGraph, aangevuld met de externe links die Search Console zelf toont.
- Serverlogs, om te zien welke URL’s daadwerkelijk door Googlebot bezocht worden, los van wat je analytics claimt.
Die serverlogs zijn de vergeten bron. Analytics laat zien wat mensen bezoeken, logs laten zien wat Google crawlt. Dat zijn soms twee heel verschillende lijsten, en het verschil kost je punten als je het negeert.
Daarna prioriteer je. Niet elke URL is evenveel waard, dus behandel ze ook niet zo. Een bruikbare vuistregel: geef voorrang aan de belangrijkste URL’s qua organisch verkeer en relevante backlinks. Content zonder verkeer, zonder links en zonder conversiewaarde mag je serieus overwegen te laten vervallen in plaats van te redirecten.
Bouw dit uit in een spreadsheet met kolommen zoals oude URL, verkeer, backlinks, conversiewaarde, voorgestelde nieuwe URL en de beslissing om te redirecten, verwijderen of samen te voegen.
Dit werkblad is je oorlogsplan. Zonder deze lijst improviseer je op de dag van livegang, en improviseren met redirects is dweilen met de kraan open. Een Nederlandse migratiechecklist bevestigt dezelfde volgorde: exporteren, mappen, prioriteren op verkeer en backlinks.
Stap 2: redirect-mapping — hoe kies je de juiste bestemming
De hoofdregel is simpel: één oude URL krijgt één nieuwe URL. Altijd proberen, geen uitzonderingen tenzij je een harde reden hebt.
Waarom die discipline? Omdat elke keer dat je twee of drie oude pagina’s op één nieuwe URL laat landen, je relevantie verdunt. Google ziet een pagina die niet meer precies aansluit bij wat er stond, en de gebruiker ook. Dat voelt in eerste instantie efficiënt, maar in de praktijk lekt er waarde weg bij elke onnodige samenvoeging.
Wanneer een echte één-op-één match niet bestaat, omdat je content structureel hebt herschikt, dan is consolidatie naar een hub-pagina de tweede beste optie. Maar doe dat met een rationale, niet uit gemakzucht. Vraag jezelf af: sluit deze hub qua onderwerp, zoekintentie en diepgang aan bij wat de oude pagina beloofde?
Soms is een redirect helemaal niet de juiste keuze. Zet in plaats daarvan een 410 of 404 in als:
- De oude pagina over een product gaat dat niet meer bestaat en nergens een logisch alternatief heeft.
- De content puur seizoensgebonden of eenmalig was, zoals een actie uit 2019.
- De pagina nooit waarde had, geen verkeer trok en geen backlinks had.
- Doorverwijzen puur zou zijn om “iets” te doen, zonder dat de bestemming relevant is.
Een 410 (“Gone”) is hier eerlijker dan een 404, omdat je Google actief vertelt dat de pagina bewust verwijderd is, niet per ongeluk kwijt. Dat scheelt onnodige herhaalde crawlpogingen.
Voor de lastige gevallen, de one-to-many situaties, geldt één beoordelingsvraag: welke bestemming dekt het grootste deel van de oorspronkelijke zoekintentie? Redirect dan naar de variant die de meeste relevantie heeft, en gebruik interne links naar de rest om waarde te behouden.
Een paar concrete beslisregels die je in elk migratieproject kunt hanteren:
- Bestaat de exacte contentmatch nog? Dan altijd één-op-één.
- Is de content samengevoegd? Redirect naar de dominante pagina, link intern naar de rest.
- Is de content verwijderd zonder alternatief? 410, geen redirect.
- Twijfel je? Kies de optie met de hoogste historische zoekintentie-overlap, niet de makkelijkste technische oplossing.
Stap 3: implementatiemethoden en de juiste statuscodes
Server-side redirects zijn de sterkste optie die je hebt. Punt. Google geeft zelf aan dat server-side 301’s en 308’s het duidelijkste signaal afgeven dat een pagina permanent verplaatst is, en dat crawlers dat sneller en betrouwbaarder verwerken dan alternatieven.
Praktisch betekent dit dat je op serverniveau werkt, niet op contentniveau. Voorbeelden:
- Apache: regels in je
.htaccess-bestand. - Nginx:
rewrite-directives in je serverconfiguratie. - Cloudflare: page rules of bulk redirects via de Cloudflare-interface.
Elk van deze werkt vóórdat de pagina zelf geladen wordt, en dat is precies waarom Google ze het meest vertrouwt: er is geen tussenstap, geen laadtijd, geen risico dat een script niet uitgevoerd wordt.
Het probleem ontstaat zodra je meerdere lagen tegelijk gebruikt. Denk aan een CDN die al iets doorstuurt, terwijl de server ook een regel heeft, en je CMS-plugin er nog een addertje onder het gras in stopt. Dat is geen theoretisch scenario. Veel CMS-plugins zetten per ongeluk tijdelijke 302-redirects in plaats van permanente 301’s, en dat blijft onopgemerkt tot iemand echt de serverresponse controleert. Audit daarom altijd alle lagen samen: CDN, server, CMS en plugin, in die volgorde, en zoek specifiek naar dubbele regels die elkaar tegenwerken of verborgen extra hops veroorzaken.
Pro-tip: Zet nooit blind op je plugin-instellingen. Controleer met een directe serveraanvraag wat er écht terugkomt, niet wat het dashboard beweert dat er gebeurt.
Meta refresh en JavaScript-redirects zijn het laatste redmiddel, niet de standaard. Ze werken pas nadat de pagina al geladen is, wat betekent dat een crawler eerst de oude content ziet en pas daarna de instructie om door te sturen. Gebruik ze alleen wanneer serverzijdig echt onmogelijk is, bijvoorbeeld op een statisch gehost platform zonder serverconfiguratie.
Wat je nooit mag overslaan: de statuscode zelf valideren. Niet aannemen dat je regel werkt, maar checken. Een redirect die in de plugin “301” heet, kan in de praktijk een 302 teruggeven door een conflicterende regel hoger in de laag. Dat verschil bepaalt of Google de linkwaarde als permanent overneemt of als tijdelijk parkeert.
Stap 4: testen in staging — hoe voorkom je ketens en loops
Testen gebeurt vóór livegang, in staging, nooit voor het eerst op productie. Dat is geen luxe, dat is de basisdiscipline die het verschil maakt tussen een schone migratie en weken puinruimen.
Zo pak je het aan: gebruik tools als curl en Screaming Frog om redirects te testen, controleer serverlogs steekproefsgewijs, en test in zowel staging als productie.
De acceptatiecriteria zijn niet onderhandelbaar: maximaal één hop per redirect, het einddoel geeft een 200 terug en is indexeerbaar, en er staat geen noindex of robots.txt-blokkade op de bestemming. Redirectketens van drie of meer stappen zijn een directe reden voor afkeuring, want elke extra hop kost een deel van de doorgegeven rankingkracht. Bij correcte, directe 301’s geef je doorgaans 90 tot 99% van de waarde door. Bij een keten van drie stappen ben je die marge grotendeels weer kwijt.
Verwijder ook elke redirectende URL uit je nieuwe XML-sitemap. Die sitemap mag alleen finale, indexeerbare URL’s bevatten, zoals Moz benadrukt in zijn praktijkgids over redirectbeheer.
Verdeel de verantwoordelijkheid duidelijk: de developer implementeert de regels, de SEO-specialist valideert de statuscodes en de eindbestemmingen, en iemand van hosting of infrastructuur controleert specifiek de edge-rules op CDN-niveau. Als niemand die laatste stap doet, ontstaan precies de verborgen ketens die je in stap 3 al probeerde te voorkomen.
Stap 5: wat meet je na livegang en wanneer grijp je in
Livegang is niet het eindpunt, het is het startschot voor je meetperiode. De eerste zeven dagen zijn kritiek, maar de echte trend zie je pas na een paar weken.
Volg deze kern-KPI’s:
- Organisch verkeer per landingspagina, vergeleken met de oude URL’s uit je nulmeting.
- Dekking in Search Console, specifiek het aantal geïndexeerde versus uitgesloten pagina’s.
- 404- en 5xx-rapporten, wekelijks doorgenomen, niet maandelijks.
- Backlink-landingspagina’s, om te checken of externe links daadwerkelijk op de nieuwe bestemming uitkomen.
- Tijd tot indexatie, oftewel hoe snel Google de nieuwe URL’s oppikt en de oude loslaat.
Bouw je monitoring in drie fasen op. Dag 0 tot 7: dagelijkse checks op crawlfouten en statuscodes. Week 2 tot 4: wekelijkse controle van indexatiedekking en verkeersontwikkeling per pagina. Week 4 tot 12: trendanalyse op totaalniveau, waarbij je beoordeelt of het verkeer zich stabiliseert op het oude niveau of eronder blijft hangen.
Verkeer dat na 12 weken nog niet herstelt tot minstens het niveau van vóór de migratie is een signaal om te patchen, niet om af te wachten. Monitoring van indexatie, verkeer en Search Console-fouten in de eerste weken en maanden is precies waarom migraties vaak alsnog goed uitpakken ondanks een tijdelijke dip.
Bij zo’n alert is de snelste fix vaak een aanvullende redirect die je binnen een uur kunt zetten, niet een volledige herbouw van je mapping.
Veelgemaakte fouten die je rankings direct kosten
Sommige fouten zie je pas als het te laat is. Andere zie je meteen, als je weet waar je moet kijken.
De grootste boosdoeners:
- Alles doorsturen naar de homepage. Dit is de meest voorkomende en meest schadelijke fout. Google ziet duizenden URL’s die plots naar één pagina wijzen, herkent geen relevantie, en devalueert de hele set.
- Verborgen ketens door een combinatie van CDN, server en plugin. Elke laag denkt dat hij de enige regel is, en samen bouwen ze een keten van drie of vier hops die niemand heeft opgemerkt.
- De doelpagina staat op noindex of wordt geblokkeerd in robots.txt. Je redirect werkt technisch perfect, maar de bestemming is voor Google onzichtbaar. Dat is verwijderen, geen migreren.
- Interne links niet bijgewerkt. Redirects zijn een vangnet, geen permanente oplossing voor navigatie. Moz wijst er terecht op dat je interne links altijd naar de definitieve URL moeten wijzen, niet naar een tussenstap.
Herstel je zo’n fout, prioriteer dan op waarde. Fix eerst de URL’s met de meeste historische omzet en backlinks, dan pas de rest. Daarna werk je de interne links bij en haal je verouderde URL’s uit de sitemap.
Bouw dit permanent in je releaseproces in: elke nieuwe migratie of grote contentwijziging krijgt automatisch een redirectcheck, een sitemapcontrole en een steekproef op noindex-tags voordat iemand op “live” klikt. Wortel eruit, altijd.
Ramons praktijkinzicht: de 90 dagen die het verschil maken
De meeste migraties mislukken niet door slechte redirects. Ze mislukken door slechte volgorde.
Ik werk altijd in drie golven. Die groep bepaalt of je site überhaupt overeind blijft, dus die krijgt eerst aandacht, zonder uitzondering. Week 2 tot 4: de rest van de redirectmapping afronden en alle interne links bijwerken naar de definitieve URL’s. Week 4 tot 12: puur trendanalyse, wekelijks kijken of het verkeer terugveert of blijft hangen.
Die volgorde werkt omdat je anders je tijd verspilt aan URL’s die nooit veel opleverden, terwijl je belangrijkste pagina’s liggen te wachten. Dat is als een lekkend dak repareren door eerst de goot te schilderen.
Twee commando’s die ik in bijna elke audit gebruik: curl -I 'https://oude-url.nl/pagina' om direct de statuscode en locatie-header te zien, zonder gedoe met een browser—en als je daarna aan de slag gaat met aanpassingen, is een SEO Content Rewriter een handig hulpmiddel om je doelpagina’s efficiënt te actualiseren. En in Screaming Frog stel ik altijd “follow redirects” in, zodat ketens meteen zichtbaar worden in het exportbestand, in plaats van dat ik ze er handmatig uit moet vissen.
Pro-tip: Zet je eerste checkronde altijd op de dag van livegang zelf, niet een dag later. De meeste desastreuze fouten, zoals een vergeten noindex-tag, ontdek je binnen de eerste uren, niet na een week.
Bekijk mijn volledige 90 dagen migratie-aanpak voor de complete tijdlijn per fase.
Wanneer redirects níet de juiste oplossing zijn
Niet elke oude URL verdient een redirect. Dat klinkt tegen de intuïtie van iedereen die denkt dat “meer redirects” gelijk staat aan “veiliger migreren”, maar het omgekeerde is vaak waar.
Een 410 is eerlijker dan een geforceerde redirect wanneer content écht verdwenen is zonder relevant alternatief. Google waardeert die duidelijkheid, en jij bespaart jezelf een reeks doorverwijzingen die uiteindelijk toch nergens relevant landen. Een slechte redirect naar een niet-passende pagina is vaak schadelijker voor je gebruikerservaring dan een keurige 410.
Soms is herstructureren slimmer dan doorsturen. Als vijf oude pagina’s dezelfde vraag beantwoorden, is samenvoegen tot één sterke pagina met interne links vanaf de andere vier vaak effectiever dan vijf losse redirects die de zoekintentie allemaal net iets anders raken. Die keuze vraagt om nadenken, niet om automatisch elke URL een bestemming te geven.
— Ramon
Hoe Ramon je helpt bij een schone redirectmigratie
Een migratie zonder externe blik is vaak duurder dan je vooraf denkt, zeker als je pas na livegang ontdekt dat de helft van je redirectmapping ontbreekt. Een gerichte scan vóór livegang helpt je precies te bepalen welke URL’s risico lopen voordat je ze verliest.
Wat je krijgt is concreet: een volledige redirectmapping op basis van je verkeer en backlinks, een implementatiecheck op server-, CDN- en pluginniveau, en de 90 dagen monitoring die in de vorige sectie beschreven staat, inclusief directe fixes zodra er iets misgaat. Geen vaag advies achteraf, maar een lijst met de belangrijkste issues die je binnen een dag terugkrijgt.
De eerste stap is simpel: vraag een migratie-scan aan via de Nebber-landingspagina en ontvang een overzicht van je top-issues nog vóór je iets aan de code verandert. Zo weet je waar je staat, voordat je live gaat, niet erna.
Bronnen
Voor de technische details is Google Search Central de eerste plek om te checken, specifiek de voorkeur voor server-side 301’s en 308’s boven alternatieven.
Voor praktijkgerichte uitleg over 301 versus 302 en concrete scenario’s zoals A/B-tests of tijdelijk onderhoud is de uitleg van Shopify een snelle referentie. Voor structured data-checks tijdens een migratie gebruik je Validator. Wil je verder lezen over specifiek HTTPS-migraties, dan legt Ramon dat uit in HTTPS voor SEO, en voor bredere technische checks is de gids technische SEO best practices een goed vervolg.
- Redirects and Google Search | Google Search Central
- 301 Redirects: How to Use Them & How They Affect SEO | Semrush
- Redirects: How To Use, SEO Impact & Types (301 vs 302) – Moz
Veelgestelde vragen
Wat is het verschil tussen een 301 en een 302 redirect?
Een 301 betekent permanent verplaatst en draagt rankingwaarde over; een 302 is tijdelijk en behoudt de indexatie van de oude URL. Shopify beschrijft concrete scenario’s zoals A/B-tests waarbij een 302 wél de juiste keuze is.
Hoeveel linkwaarde verlies je bij een redirect?
Bij een correct geïmplementeerde 301 zonder ketens geef je doorgaans 90 tot 99% van de rankingkracht door, maar elke extra hop in een keten vermindert dat effect.
Hoe lang moet je na een migratie monitoren?
Reken op een minimum van 4 weken voor de eerste trends en 12 weken voor een betrouwbaar beeld van herstel, met dagelijkse checks in de eerste week.
Moet je altijd redirecten of kan een 404 beter zijn?
Als de oude content geen relevant alternatief heeft en geen verkeer of backlinks trok, is een 410 vaak eerlijker en gezonder dan een geforceerde redirect naar een niet-passende pagina.
Kan ik zelf een migratiescan laten uitvoeren?
Ja. Nebber biedt een migratie-scan aan die redirectmapping, implementatiechecks en 90 dagen monitoring combineert, met een directe lijst van top-issues als startpunt.