Je posities overleven een redesign als elke oude URL in één stap op een werkende nieuwe pagina uitkomt, en als je dat vóór de livegang hebt getest in plaats van erna gehoopt. Google beschrijft die volgorde zelf in Site Moves with URL Changes (bijgewerkt 20 augustus 2026): nieuwe site voorbereiden en testen, een URL-mapping oud naar nieuw maken, serverredirects configureren, en daarna het verkeer op beide sites volgen. Hieronder staat dat draaiboek uitgewerkt tot artefacten die je kunt controleren — een redirect-map in versiebeheer, een pre-launch checklist die automatisch draait, en een baseline waarmee je achteraf kunt bewijzen wat er is gebeurd.
Wat er precies misgaat (en waarom je het pas laat merkt)
Bij een redesign verandert vaak niet alleen het ontwerp maar ook de URL-structuur, de sjablonen en het CMS. De schade ontstaat op vier plekken: oude URL's die op een 404 uitkomen, redirects die via twee of drie tussenstappen lopen, een noindex die uit de ontwikkelfase is blijven staan, en een sitemap die nog naar de oude adressen wijst. Geen van de vier geeft een foutmelding. Je ziet ze pas terug als het indexeringsrapport in Search Console begint te verschuiven — en dat is weken later.
De remedie is niet "beter opletten" maar het probleem controleerbaar maken. Alle vier zijn machinaal te toetsen, en dat is precies wat de meeste opleverprocessen missen.
Stap 1: inventariseer elke URL die iets waard is
Vijf bronnen, niet één
Eén crawl is niet genoeg: een crawler vindt alleen wat intern gelinkt is. Combineer daarom vijf bronnen en ontdubbel de uitkomst tot één lijst.
- Crawl van de huidige site — alle intern bereikbare URL's, inclusief statuscode en titel.
- Search Console — het prestatierapport op paginaniveau (welke URL's krijgen vertoningen en klikken) plus het rapport Pagina-indexering voor wat Google werkelijk kent.
- Analytics — landingspagina's over de laatste twaalf maanden, zodat seizoenspagina's niet ontbreken.
- De bestaande sitemap — vaak staan hier URL's in die nergens meer gelinkt zijn.
- Het linkprofiel — pagina's met externe links naar zich toe. Die verlies je permanent als ze op een 404 uitkomen.
Prioriteren op verkeer, links en conversie
Geef elke URL een prioriteit op basis van drie kolommen: organische klikken, externe verwijzingen en conversies of omzet. Emerce (Kostas Piludis, 30 maart 2020) hanteerde die drie criteria al en ze zijn nog steeds de juiste — hoog geprioriteerde URL's krijgen een één-op-één-bestemming en worden handmatig gecontroleerd, de rest mag in een groepsregel.
Wat je bewust niet meeneemt
Filter- en parametercombinaties, interne zoekresultaten, verlopen campagne-URL's met tracking en paginering die niet meer bestaat. Die redirect je niet en zet je niet in je sitemap. Een 404 is hier het juiste antwoord: hij vertelt Google dat de pagina weg is, terwijl een redirect naar de homepage door Google als soft 404 kan worden behandeld.
Stap 2: de redirect-map als artefact, niet als losse Excel
De redirect-map is de belangrijkste oplevering van een migratie, en hij hoort daarom te leven waar de rest van het project leeft: in versiebeheer, naast de code. Dan heeft elke wijziging een auteur, een datum en een review, en kun je na livegang teruglezen wie welke rij heeft toegevoegd. Een bestand in iemands Downloads-map kan dat niet.
oude_url;status;nieuwe_url;type;prioriteit;eigenaar;getest;testdatum
/diensten/webshop-bouwen;behouden;/webshops;301;hoog;ayham;ja;2026-09-05
/blog/oud-artikel-2019;samengevoegd;/blog/nieuw-artikel;301;laag;senna;ja;2026-09-05
/actie-zomer-2024;vervallen;;410;laag;senna;ja;2026-09-05De kolom status dwingt een beslissing af: behouden, samengevoegd, vervangen of vervallen. De kolom getest wordt niet met de hand ingevuld maar door de testrun uit stap 4. Zo is de map tegelijk plan én bewijs.
Eén-op-één waar het kan
Redirect naar de meest gelijkwaardige nieuwe pagina. Meerdere oude URL's naar één nieuwe pagina mag als die pagina de inhoud daadwerkelijk vervangt; Google waarschuwt in de site-move-documentatie expliciet tegen het redirecten van veel oude URL's naar één irrelevante bestemming, met soft 404's als gevolg. Bestaat er geen inhoudelijke opvolger, geef dan een 404 of 410 in plaats van een verzonnen bestemming.
Ketens: hoeveel hops zijn acceptabel
Volgens dezelfde documentatie houd je ketens idealiter onder de drie hops en in elk geval onder de vijf; Googlebot volgt er tot tien, maar bezoekers merken elke extra stap. In de praktijk ontstaan ketens door stapeling: een oude 301 uit een vorige migratie, plus je nieuwe regel, plus de http-naar-https-redirect. Test daarom vanaf de originele URL, inclusief protocol en www-variant.
| Type | Permanent volgens Google | Wanneer je het gebruikt |
|---|---|---|
| 301 | Ja | Standaard voor een verhuisde pagina |
| 308 | Ja | Als de methode (bijv. POST) behouden moet blijven |
| 302 / 303 / 307 | Nee (tijdelijk) | A/B-test, tijdelijke onderhoudspagina |
| Meta refresh 0 seconden | Ja | Alleen als je geen serverredirect kunt instellen |
| JavaScript-redirect | Ja | Laatste redmiddel, alleen als server- en meta-redirect onmogelijk zijn |
| 410 | n.v.t. | Pagina bestaat definitief niet meer en heeft geen opvolger |
Stap 3: leg je baseline vast vóór de launch
Zonder baseline is "we zijn verkeer kwijt" een gevoel. Exporteer daarom op één vaste dag, uiterlijk een week vóór go-live, vier dingen en bewaar ze bij de redirect-map: het prestatierapport per pagina en per zoekopdracht over de laatste 16 maanden, het rapport Pagina-indexering (aantallen per status), de landingspagina's met conversies uit je analytics, en de huidige Core Web Vitals-velddata. Noteer de exportdatum in het bestand zelf.
Stap 4: de pre-launch checklist die automatisch kan draaien
Alle checks hieronder zijn scriptbaar, en dat is het hele punt: ze draaien op elke build van de staging-omgeving, niet één keer op de avond vóór livegang. De redirect-test leest de map en toetst elke rij op drie dingen tegelijk — één hop, een permanente statuscode, en een 200 op de bestemming.
tail -n +2 redirects.csv | while IFS=";" read -r oud status nieuw type rest; do
[ -z "$nieuw" ] && continue # rijen zonder bestemming (410) apart controleren
eerste=$(curl -s -o /dev/null -w "%{http_code}" "https://staging.jouwsite.nl$oud")
read -r eind code hops < <(curl -sL -o /dev/null \
-w "%{url_effective} %{http_code} %{num_redirects}" "https://staging.jouwsite.nl$oud")
if [ "$eerste" != "$type" ] || [ "$code" != "200" ] || [ "$hops" -gt 1 ]; then
echo "FAIL $oud -> $eind (eerste $eerste, eind $code, $hops hops)"
fi
done| Check | Wat er misgaat als je hem overslaat | Automatisch? | Blokkerend |
|---|---|---|---|
| Redirect-test per rij | 404's en ketens op je waardevolste URL's | Ja | Ja |
| Noindex-check op productie | De hele site verdwijnt uit de index | Ja | Ja |
| robots.txt-check | Crawlblokkade uit de ontwikkelfase blijft staan | Ja | Ja |
| Sitemapvalidatie | Sitemap met 404's, redirects of niet-canonieke URL's | Ja | Ja |
| Canonicalcheck | Ontbrekende, relatieve of tegenstrijdige canonicals | Ja | Ja |
| Interne links | Elke klik loopt via een redirect in plaats van direct | Ja | Nee |
| Steekproef op sjabloonniveau | Titels, koppen en gestructureerde data verdwenen | Deels | Ja |
Noindex: de fout die de meeste schade doet
Google's site-move-documentatie noemt het expliciet: verwijder noindex-regels en robots.txt-blokkades uit de ontwikkelfase vóór de livegang. Dit is de enige fout in dit artikel die je hele site uit de index kan halen, en tegelijk de makkelijkste om te automatiseren — één verzoek naar productie, kijken of er een noindex in de header of de HTML zit, build afbreken als dat zo is.
Canonicals: voorkeuren, geen instructies
Google's canonicalisatiedocumentatie (bijgewerkt 10 juli 2026) is er duidelijk over: de methoden zijn voorkeuren, niet bindend — "While we encourage you to use these methods, none of them are required; your site will likely do just fine without specifying a canonical preference." De sterkte-orde is redirect, dan rel=canonical, dan opname in de sitemap, en ze "can stack and thus become more effective when combined." Dat verklaart ook waarom je canonical wordt genegeerd als hij tegen een redirect in gaat. De vier fouten die diezelfde pagina noemt, controleer je machinaal: tegenstrijdige canonicals per methode, relatieve in plaats van absolute URL's, noindex gebruiken waar rel=canonical hoort, en de self-referencing canonical vergeten.
Staat je nieuwe site in staging? Stuur de staging-URL en je huidige domein, dan draaien we de pre-launch check op redirects, noindex, sitemap en canonicals — met de bevindingen terug vóór je live gaat.
Stap 5: livegang, in de goede volgorde
- Zet de redirects live samen met de nieuwe site, niet erna. Op het moment dat de DNS omschakelt, moet elke oude URL al een bestemming hebben.
- Haal de noindex en de robots.txt-blokkade van staging weg en controleer dat op productie, niet op je lokale kopie.
- Dien de nieuwe sitemap in via Search Console en verwijder de oude daarna. Onthoud dat een sitemap volgens Google geen indexatie garandeert; hij versnelt vooral het crawlen van grotere of complexere sites.
- Werk je interne links bij naar de nieuwe URL's, zodat bezoekers en crawlers niet standaard via een redirect lopen.
- Gebruik de Adreswijziging-tool alleen bij een wijziging van domein of subdomein. Volgens Google is hij niet nodig bij http naar https, bij www naar non-www op hetzelfde domein, of bij een nieuwe padstructuur binnen hetzelfde domein.
- Zorg dat je server de extra crawlbelasting aankan: na een migratie haalt Googlebot in korte tijd veel meer op dan gebruikelijk.
Stap 6: monitoren na livegang
| Periode | Wat je bekijkt | Waar | Wanneer je ingrijpt |
|---|---|---|---|
| Eerste 72 uur | Statuscodes, serverfouten, crawlfouten | Serverlogs, Search Console | Elke 404 of 5xx op een URL uit de baseline |
| Week 1 | Indexering nieuwe URL's, redirects herkend | Rapport Pagina-indexering, URL-inspectie | Nieuwe URL's blijven "Ontdekt, niet geïndexeerd" |
| Week 2–4 | Vertoningen en klikken per URL-groep | Prestatierapport | Een groep zakt terwijl de rest herstelt |
| Week 4–12 | Vergelijking met de baseline, Core Web Vitals | Search Console, analytics | Geen zichtbare hersteltrend |
Hoe lang dat duurt, zegt Google zelf: "for medium-sized websites, it can take a few weeks or more for Google to gradually start showing the new URLs instead of the old ones" — en voor grotere sites langer. Zoomin Marketing (Sanne, 25 juli 2025, bijgewerkt 8 augustus 2025) noemt in de praktijk een doorlooptijd van vier weken tot drie maanden. Een dip in de eerste weken is dus niet automatisch een fout, maar hij hoort wel een hersteltrend te laten zien. Redirects laat je volgens Google minimaal ongeveer een jaar staan, en zo veel langer als redelijk is.
Als het tóch misgaat: de diagnosevolgorde
- Neem je baseline erbij en bepaal welke URL-groep is gezakt. Is het de hele site of één sjabloon?
- Controleer de statuscode van de gezakte URL's vanaf hun oude adres. Een 404 of een keten is direct te herstellen.
- Inspecteer een gezakte URL in Search Console: wat is de door Google gekozen canonical, en komt die overeen met de jouwe?
- Controleer indexeerbaarheid: noindex, robots.txt, en of de pagina zonder JavaScript inhoud teruggeeft.
- Vergelijk de nieuwe pagina inhoudelijk met de oude. Verdwenen tekst, koppen of interne links zijn een veelvoorkomende en over het hoofd geziene oorzaak.
- Pas als bovenstaande vier schoon zijn: kijk naar snelheid. Zie waarom is mijn website traag voor de meetvolgorde.
Wat je van je bureau mag eisen
- De redirect-map als bestand in versiebeheer, met eigenaar en testdatum per rij — geen screenshot van een spreadsheet.
- Een geslaagde testrun over de volledige map, met de uitvoer erbij, gedateerd vóór de livegang.
- Bewijs dat er geen noindex of robots.txt-blokkade op productie staat.
- De baseline-export met datum, zodat de vergelijking achteraf eerlijk is.
- Een afspraak over hoe lang de redirects blijven staan en wie dat bewaakt na oplevering.
- Een monitoringafspraak voor de eerste twaalf weken, met een vast moment waarop jullie de cijfers doornemen.
Veelgestelde vragen
Verlies ik mijn posities bij een nieuwe website?
Niet als de inhoud vergelijkbaar blijft en elke oude URL in één permanente stap op een relevante nieuwe pagina uitkomt. Google stelt dat permanente redirects geen PageRank-verlies veroorzaken; het verlies komt vrijwel altijd van 404's, ketens, verdwenen content of een achtergebleven noindex.
Wat als ik alleen van http naar https of van www naar non-www ga?
Dan gelden dezelfde redirect- en canonicalregels, maar heb je de Adreswijziging-tool niet nodig: die is volgens Google alleen bedoeld voor een wijziging van domein of subdomein.
Wanneer gebruik ik een canonical en wanneer een redirect?
Een redirect als de oude URL weg mag; een canonical als beide URL's bereikbaar moeten blijven, bijvoorbeeld bij filtervarianten van dezelfde productlijst. De redirect is het sterkste signaal van de twee.
Kan ik een redesign en een platformmigratie beter combineren of scheiden?
Scheiden maakt de diagnose makkelijker: verandert alleen het ontwerp, dan weet je bij een dip dat het aan URL's of content ligt. Moet je ze combineren, verhoog dan de prioriteit van de baseline en van de sjabloon-steekproef, want je verandert twee variabelen tegelijk. Wat een traject aan bouwkant kost, staat op onze prijzen.
Hoe houd ik dit op orde na de livegang?
Redirects, sitemap en indexering zijn geen eenmalige oplevering. Zet de checks uit stap 4 als terugkerende controle in je onderhoud; wat daar verder in hoort, staat in wat website-onderhoud kost.