Website verhuizen zonder Google-positie te verliezen

Wie zijn website verhuist, is meestal bang voor één ding: dat de pagina’s die nu bezoekers opleveren straks nergens meer te vinden zijn. Die angst is terecht, maar de oorzaak zit zelden waar je hem verwacht. Een nieuwe host of een nieuw ontwerp kost je geen positie. Adressen die zonder wegwijzer verdwijnen wel. Dit stuk legt uit hoe je die wegwijzers maakt, in welke volgorde, en wat je controleert nadat de nieuwe site live staat.

Eerst: welke verhuizing is het eigenlijk

Google onderscheidt twee soorten verhuizing, en ze vragen een andere aanpak. Verhuis je alleen naar een andere hosting of een andere CDN en blijven alle adressen gelijk, dan is er in de kern één actie: de DNS-instellingen van je domein wijzen naar de nieuwe plek. Google beschrijft die route in de handleiding voor een verhuizing zonder adreswijzigingen (geraadpleegd op 20 september 2026).

Veranderen er wel adressen, bijvoorbeeld door een nieuw domein, een nieuwe mappenstructuur of de overstap van HTTP naar HTTPS, dan gelden de regels uit de handleiding voor een verhuizing met adreswijzigingen (geraadpleegd op 20 september 2026). Alles hieronder gaat over die tweede soort, want daar gaat het mis. Ga bij de eerste soort ook niet lichtzinnig te werk, maar je hebt dan geen adreskaart nodig, alleen een goede test en een nette overschakeling.

Verhuis één ding tegelijk

De verleiding is groot om alles in één keer te doen: nieuw domein, nieuw systeem, nieuw ontwerp, nieuwe teksten. Doe dat niet. Google raadt aan om je wijzigingen één voor één te plannen (geraadpleegd op 20 september 2026). Als je positie na de verhuizing zakt, wil je weten waardoor. Verander je vier dingen tegelijk, dan weet je dat nooit, en kun je ook niets gericht terugdraaien.

Plan de verhuizing bovendien in een rustige periode. Heeft je bedrijf een seizoen of een dag in de week waarop het rustig is, dan raken minder bezoekers een eventuele fout. Reken verder op schommelingen. Google schrijft dat het bij een middelgrote site een paar weken of langer kan duren voordat de nieuwe adressen de oude in de zoekresultaten vervangen (geraadpleegd op 20 september 2026). Een dip in de eerste dagen is dus normaal en geen reden om in paniek terug te draaien.

Maak eerst de kaart, dan pas de verhuizing

Het belangrijkste werk gebeurt voordat er iets verhuist. Maak een lijst van elk adres dat nu bestaat en zet er het adres naast waar die pagina straks staat. Google noemt dit een adreskaart, in het Engels een URL mapping (geraadpleegd op 20 september 2026). Zonder die kaart verhuis je op gevoel, en gevoel vergeet de pagina die ooit één keer goed scoorde en sindsdien niemand meer opviel.

Zo bouw je de lijst op:

• Haal de adressen uit meerdere bronnen: je sitemap, een crawl van je eigen site en het prestatierapport in Search Console. De sitemap alleen mist adressen die er ooit hebben gestaan.
• Zet bij elk adres wat het nu oplevert: vertoningen en kliks uit Search Console, en of andere sites ernaar linken. Dat bepaalt de volgorde waarin je dingen controleert.
• Geef elk adres een bestemming: de pagina die dezelfde vraag beantwoordt. Bestaat die niet meer, dan is een foutmelding eerlijker dan een omleiding naar iets anders. Google vraagt dan om een 404 of 410 als foutcode (geraadpleegd op 20 september 2026).

Stuur niet alles naar de voorpagina

Dit is een veelgemaakte fout, en wij maakten hem zelf ook. Als je niet weet waar een oud adres heen moet, is de voorpagina de makkelijke uitweg. Google waarschuwt daar expliciet voor: veel oude adressen naar één irrelevante bestemming sturen, zoals de voorpagina, kan als soft 404 worden behandeld (geraadpleegd op 20 september 2026). Bij een soft 404 telt de omleiding niet als bewijs dat de inhoud is verhuisd.

Op 22 juli 2026 hebben we onze eigen omleidingstabel doorgelopen met de gegevens van Search Console over de drie maanden tot en met 19 juli 2026. Het bleek dat 40 van onze 49 omleidingen naar de voorpagina wezen, terwijl Google zulke omleidingen als soft 404 kan behandelen (geraadpleegd op 20 september 2026). Een aantal van die oude adressen kreeg nog steeds vertoningen. Dat zegt iets: mensen zochten nog steeds naar die inhoud en Google liet ze het oude adres nog zien, alleen kwamen ze op een pagina die hun vraag niet beantwoordde. We hebben er 30 herricht naar de pagina die de oorspronkelijke vraag wel beantwoordt. De meetmethode is eenvoudig en herhaalbaar: exporteer de omleidingen, exporteer de vertoningen per adres, en kijk welke bestemmingen niets met de zoekvraag te maken hebben.

Leg de omleiding permanent en in één stap

Voor een verhuizing is een permanente omleiding de juiste keuze. Google legt uit dat een 301 of 308 het signaal geeft dat de nieuwe bestemming de canonieke is, en dat een tijdelijke omleiding zoals 302 of 307 het oude adres in de zoekresultaten houdt (geraadpleegd op 20 september 2026). Een tijdelijke omleiding leggen bij een blijvende verhuizing is dus een subtiele manier om je eigen verhuizing te blokkeren.

Kies verder voor een omleiding die op de server gebeurt, niet in JavaScript. Google noemt JavaScript-omleidingen alleen bruikbaar als je niets anders kunt (geraadpleegd op 20 september 2026). En houd het bij één stap: een oud adres dat via een tussenadres naar het nieuwe gaat, is trager voor bezoekers en geeft meer kans dat er onderweg iets afbreekt.

Google adviseert de omleidingen minstens 1 jaar te laten staan (geraadpleegd op 20 september 2026), zodat Google alle signalen kan overzetten, inclusief de links van andere sites naar je oude adressen. Voor bezoekers geldt dat je ze eigenlijk nooit weg hoeft te halen. Werk wel je eigen links bij, want een omleiding is langzamer dan een direct adres.

Zo deden wij het bij onze eigen blog

Een verhuizing op kleine schaal is een goede oefening, dus laten we onze eigen blog als voorbeeld nemen. Tot en met 14 september 2026 stond de Nederlandse blog van FWRD op /blog/. Op 15 september 2026 verhuisde hij naar /nl/blog/. Vier dagen later, op 19 september 2026, werd /blog/ de Engelse blog, met daarnaast Duitse, Franse, Spaanse en Portugese versies onder een eigen taalmap.

Daar zaten drie keuzes in die je bij elke verhuizing terugvindt:

• Een vaste lijst in plaats van een jokerregel. De handige oplossing was één regel die alles onder /blog/ naar /nl/blog/ stuurt. Maar sinds /blog/ Engelse artikelen bevat, zou die regel elk Engels artikel wegkapen en naar een Nederlandse pagina sturen. Er hebben op het oude adres maar drie Nederlandse artikelen gestaan, dus we hebben die drie als vaste lijst vastgelegd. Alles wat niet op de lijst staat, wordt niet omgeleid.
• Alle varianten van een adres meenemen. Een pagina heeft meer adressen dan je denkt. Naast het artikel zelf verhuisden ook de versie zonder afsluitende slash, de tekstversie voor machines met de extensie .md en de auteurspagina’s. Wie alleen het artikel omleidt, laat de rest achter.
• Bewust iets niet omleiden. De feed van de blog, /blog/rss.xml, hoort sinds die wissel bij de Engelse blog. Als we hem hadden omgeleid naar de Nederlandse feed, zou elke Engelse pagina een feed in een andere taal aankondigen. Dat vonden we pas bij de eerste vertaalronde. Een omleiding moet dus de bedoeling van het oude adres volgen, niet alleen het pad.

Dat laatste is de kern van dit hele stuk: een omleiding is een uitspraak over wat een adres betekent. Die uitspraak moet kloppen, ook als de vraag die erachter zat verandert. Het resultaat is te controleren met een gewone opdracht op de opdrachtregel of in je browser: het oude adres moet met een permanente omleiding in één keer op de nieuwe pagina uitkomen. Zo hebben we het op 15 september 2026 gecontroleerd, en zo hoor je het na te lopen voor elk adres in je eigen kaart.

Wat je direct na de verhuizing controleert

Zodra de omleidingen live staan, is er een korte lijst die je afwerkt. Google noemt de belangrijkste punten in de handleiding voor het starten van de verhuizing (geraadpleegd op 20 september 2026):

• Test de omleidingen. Doe dat voor je belangrijkste adressen met de URL-inspectie in Search Console en voor de rest met een script dat de hele kaart afloopt.
• Controleer of de canonical-verwijzing op de nieuwe pagina’s naar de nieuwe adressen wijst, en niet nog naar de oude.
• Haal de noindex-regel weg die je tijdens het bouwen hebt gezet om te voorkomen dat de nieuwe site te vroeg werd geïndexeerd. Deze fout blijft onzichtbaar tot je positie is verdwenen, want de nieuwe site ziet er gewoon goed uit.
• Controleer je robots.txt. Veel bouwers blokkeren daarin al het crawlen tijdens de ontwikkeling en vergeten dat op te heffen.
• Dien de nieuwe sitemap in bij Search Console.
• Verhuis je naar een ander domein, dan is er ook het hulpmiddel voor adreswijziging in Search Console. Voor een verhuizing binnen hetzelfde domein, zoals van HTTP naar HTTPS of van een map naar een andere map, heb je dat niet nodig.

Kijk daarna in de weken erna dagelijks naar het rapport voor geïndexeerde pagina’s en het prestatierapport, per adres en niet alleen als totaal. Een verhuizing gaat per adres en dus zie je ook per adres of het gelukt is.

Wat er vaak misgaat

Vier fouten liggen voor de hand. De eerste is dat je de kaart maakt van wat je op de site ziet in plaats van wat Google al kent. De tweede is dat je een bouwinstelling als noindex laat staan. De derde is dat je verhuist en tegelijk ook de inhoud herschrijft, waardoor je een dip niet meer kunt uitleggen. De vierde is dat je de omleidingen na een paar weken opruimt omdat de oude site toch weg is.

Wil je dit niet zelf uitzoeken, dan kun je je website laten overzetten, waarbij je bestaande teksten en structuur het startpunt van de nieuwe site zijn. Wil je eerst weten wat er nu op je site staat en wat Google ervan ziet, begin dan met een analyse van je website, en lees hoe vindbaarheid in Google als vast onderdeel van een site wordt geregeld.