Website overstappen zonder onnodig SEO-verlies

Eerst vaststellen wat werkelijk moet veranderen

“De website is oud” is een begin van een gesprek, geen technische diagnose. Misschien zit het probleem in het ontwerp. Misschien kan de software niet meer goed worden bijgehouden. Misschien zijn de pagina's prima, maar is het aanvraagproces onduidelijk. Die oorzaken vragen niet automatisch dezelfde oplossing.

Wij zouden eerst drie lijsten maken: wat goed werkt, wat aantoonbaar misgaat en wat je wilt verbeteren. Het eerste lijstje voorkomt dat nuttige functies verdwijnen omdat niemand eraan dacht. Het tweede maakt de aanleiding concreet. Het derde voorkomt dat wensen tijdens de bouw ongemerkt als noodzakelijke reparaties worden behandeld.

Bij een fictief installatiebedrijf kan de huidige site bijvoorbeeld goede aanvragen via één specifieke dienstenpagina opleveren. De eigenaar vindt de homepage verouderd, maar die dienstenpagina verdient behoud van haar uitleg en bereikbaarheid. Je kunt het ontwerp vernieuwen zonder het complete verhaal opnieuw uit te vinden. Dat is vaak een belangrijker uitgangspunt dan een nieuw platform kiezen.

Een WordPress-specialist kan helpen beoordelen of behoud en verbetering binnen de bestaande omgeving logisch zijn. Een andere techniek kan passend zijn, maar moet een probleem oplossen. “Moderner” is op zichzelf geen acceptatiecriterium. Schrijf op wat na afloop eenvoudiger, betrouwbaarder of beter bruikbaar moet zijn.

Een urgente patch en een herbouw zijn twee verschillende trajecten

Wanneer een beheerder vaststelt dat een beveiligingsupdate nodig is, wil je die beslissing niet laten wachten op een ontwerptraject. Een nieuwe site vraagt voorbereiding, inhoud, tests en overdracht. De bestaande omgeving blijft in de tussentijd bestaan. Bespreek dus apart wat er nu nodig is en wat later structureel kan verbeteren.

Het omgekeerde geldt ook. Een geslaagde patch bewijst niet dat een verouderde website weer prettig te beheren is. Misschien blijft de contentstructuur onlogisch of kost iedere normale wijziging veel moeite. Dat zijn geldige redenen om een migratie te onderzoeken, maar het zijn andere redenen dan de directe beveiligingsmelding.

Wij zouden beide trajecten afzonderlijk vastleggen. Bij de acute maatregel horen de betreffende omgeving, controle en verantwoordelijke beheerder. Bij de herbouw horen de gewenste functies, planning en overgangsvoorwaarden. Zo kan niemand later een ontwerpbesluit verwarren met de bevestiging dat een actuele technische fout is opgelost.

Wil je eerst begrijpen hoe onderhoud gecontroleerd wordt uitgevoerd, lees dan PHP updaten met aandacht voor uitval. Voor de samenhang tussen de onderdelen is er WordPress, PHP en plugins. Een migratieplan begint pas goed wanneer duidelijk is welke bestaande problemen het wel en niet overneemt.

Houd een hostingverhuizing en een URL-wijziging uit elkaar

Google maakt in zijn documentatie onderscheid tussen een verhuizing waarbij zichtbare URL's gelijk blijven en een verhuizing waarbij die adressen veranderen. Bij alleen een andere hostingomgeving is er dus een ander vertrekpunt dan bij een nieuw domein of nieuwe paginapaden. Bron: Google Search Central over hostingwijzigingen.

Voor jouw project is dit onderscheid praktisch. Laat de bouwer vóór de start aangeven welke van de volgende zaken veranderen: hosting, techniek, domein, URL's, inhoud en navigatie. Hoe meer tegelijk verandert, hoe lastiger het wordt om achteraf vast te stellen waardoor een verschil is ontstaan. Wij kiezen daarom liever bewust welke veranderingen samen nodig zijn.

Je hoeft een adres niet te veranderen omdat de achterliggende techniek verandert. Een bestaande dienstenpagina kan vaak op hetzelfde publieke pad blijven staan. Of dat in jouw omgeving mogelijk is, moet de bouwer controleren. Het uitgangspunt is behoud waar dat zinvol is, niet automatisch nieuwe adressen maken omdat een nieuw systeem dat standaard doet.

Vraag ook naar taalversies, downloads en campagnepagina's. Een verhuizing is zelden alleen de homepage plus het hoofdmenu. Soms komt een waardevolle bezoeker binnen via een oud document of een link die maanden geleden gedeeld is. Die route moet bewust worden behouden, doorverwezen of beëindigd.

Maak een inventaris op basis van gebruik, niet alleen van het menu

Het hoofdmenu laat zien wat je bezoekers nadrukkelijk aanbiedt. Het laat niet noodzakelijk alle bestaande pagina's zien. Er kunnen artikelen, oude campagnes, bestanden of specifieke dienstpagina's buiten staan. Daarom zou onze inventaris verschillende bronnen combineren: de huidige structuur, beschikbare verkeersgegevens en wat medewerkers dagelijks delen met klanten.

Vraag bijvoorbeeld welke links in offertes, automatische e-mails en advertentiecampagnes voorkomen. Die informatie zit niet altijd in de website zelf. Een planner gebruikt misschien een specifieke afspraaklink. Een verkoper stuurt een download mee. Als die routes verdwijnen, kan het probleem pas later zichtbaar worden terwijl de nieuwe homepage al lang is goedgekeurd.

Geef iedere gevonden route een eigenaar of reden. Waarom bestaat deze pagina? Voor welke vraag is zij bedoeld? Is de informatie nog correct? Zo wordt de inventaris meer dan een technische export. Je kunt dan onderscheid maken tussen inhoud die behouden moet blijven en materiaal dat bewust mag worden samengevoegd of verwijderd.

Zet onduidelijkheden apart. “Niet gevonden in de navigatie” betekent niet “niet gebruikt”. Een route zonder bekende eigenaar kan nader onderzoek vragen. Het is verstandiger zo'n beslissing expliciet te maken dan alle onbekende pagina's stilletjes te laten verdwijnen bij het omzetten naar een nieuwe structuur.

Bescherm de pagina's die aanvragen ondersteunen

Niet iedere URL is even belangrijk voor het bedrijf. Wij zouden bij de voorbereiding extra aandacht geven aan pagina's die een duidelijk aanbod uitleggen, relevante bezoekers trekken of regelmatig in verkoopgesprekken worden gebruikt. Dat hoeft niet altijd de pagina met de meeste bezoeken te zijn. Een bescheiden dienstenpagina kan commercieel belangrijker zijn dan een breed gelezen artikel.

Maak per belangrijke pagina een korte inhoudskaart. Daarop staan de hoofdvraag, het aanbod, het werkgebied, het bewijs en de vervolgstap. Die kaart helpt bij het vernieuwen van het ontwerp. De vorm mag veranderen, maar de bezoeker moet de kern nog steeds kunnen begrijpen zonder naar ontbrekende details te zoeken.

Bij een fictieve dakdekker zou een pagina over dakinspectie bijvoorbeeld niet moeten verdwijnen in een algemene pagina over “alles voor uw dak” zonder dat iemand die keuze beoordeelt. Het kan zinvol zijn om inhoud samen te voegen, maar dan moet de nieuwe pagina de relevante vraag ook werkelijk beantwoorden.

Dit is inhoudelijk werk naast de technische verhuizing. Via technische SEO kun je de controles op bereikbaarheid en indexeerbaarheid begrijpen. De afweging welke uitleg een klant nodig heeft, vraagt daarnaast kennis van jouw aanbod. Beide horen in hetzelfde project, maar zijn niet hetzelfde vakje op een checklist.

Maak voor veranderende adressen een routekaart

Wanneer URL's daadwerkelijk veranderen, wil je per oud adres weten waar het naartoe gaat. Google adviseert een mapping tussen oude en nieuwe URL's en noemt monitoring onderdeel van de verhuizing. Het waarschuwt ook dat zoekposities tijdens een grote wijziging kunnen schommelen. Dat is de reden dat wij geen verliesvrije migratie beloven. Bron: Google, site moves with URL changes.

Een bruikbare routekaart bevat meer dan twee kolommen. Voeg de reden van de wijziging toe, de eigenaar van de inhoud en de test die erbij hoort. Is een pagina hernoemd, samengevoegd of niet meer relevant? De technische uitkomst volgt uit die beslissing. Een onduidelijke inhoudskeuze wordt niet automatisch goed door er een redirect bij te zetten.

Stel dat twee verouderde uitlegpagina's worden samengevoegd tot één actuele handleiding. Dan wil je kunnen uitleggen hoe de nieuwe pagina de oude vragen opvangt. Als een dienst volledig is gestopt en er geen passende vervanger is, moet je een andere keuze maken. Forceer geen schijnbaar nette route die bezoekers op een ongerelateerd aanbod laat landen.

Laat de routekaart vóór publicatie beoordelen door iemand die het bedrijf kent. Een technische uitvoerder kan adressen correct koppelen, maar weet niet vanzelf of twee diensten inhoudelijk gelijkwaardig zijn. Juist die combinatie van technische controle en inhoudelijke beoordeling voorkomt veel verwarring.

Redirects zijn begeleiding, geen afvalbak

Een permanente redirect is bedoeld voor een blijvende verplaatsing. Google beschrijft hoe redirects aan gebruikers en zoekmachines duidelijk maken dat informatie op een ander adres staat. Kies de uitvoering op basis van de werkelijke verandering en laat de respons controleren. Bron: Google Search Central over redirects.

Wij zouden niet tevreden zijn met de mededeling dat “alle oude links ergens uitkomen”. De bestemming moet passen bij de vraag waarmee iemand binnenkomt. Een bezoeker die een handleiding verwacht en op een algemene verkooppagina belandt, is niet goed geholpen. De route kan technisch reageren en toch inhoudelijk verkeerd zijn.

Test daarom een representatieve verzameling oude links alsof je een bezoeker bent. Open de link, bekijk het uiteindelijke adres en lees de eerste informatie die je ziet. Controleer ook links uit echte oude e-mails of documenten, voor zover je daarvoor bevoegd toegang hebt. Dat is een andere proef dan alleen de nieuwe navigatie doorklikken.

Bewaar de resultaten met datum en omgeving. Als later een probleem wordt gemeld, kun je zien wat eerder is getest. Een routekaart die alleen op papier klopt, is onvoldoende. De gepubliceerde inrichting moet het gewenste gedrag daadwerkelijk laten zien.

Controleer inhoud en technische signalen samen

Een nieuwe pagina kan de juiste tekst tonen en toch een verkeerd canoniek adres bevatten. Het canonieke adres helpt zoekmachines begrijpen welke versie de voorkeur heeft bij vergelijkbare pagina's. Google beschrijft canonicalisatie als een verzameling signalen, niet als een garantie dat iedere voorkeur wordt overgenomen. Bron: Google over canonieke URL's.

Voor ons betekent dit dat een controle niet bij de zichtbare kop stopt. We willen weten welke pagina publiek bedoeld is, welke versie een concept is en welke URL in verwijzingen wordt gebruikt. De bouwer moet die keuzes consistent doorvoeren. Een eigenaar hoeft niet iedere HTML-regel te lezen, maar kan wel om een controleverslag vragen.

Let ook op de presentatie van belangrijke informatie. Zijn prijzen, openingstijden en contactmogelijkheden nog op de juiste plek? Is een afbeelding met tekst vervangen door echte, leesbare tekst? Zijn documenten bereikbaar? Een migratie kan technisch geslaagd lijken terwijl de uitleg die bezoekers nodig hebben onbedoeld is ingekort.

Vergelijk daarom niet alleen schermafbeeldingen. Gebruik de inhoudskaarten van de belangrijkste pagina's. Beantwoordt de nieuwe versie nog steeds dezelfde essentiële vragen? Waar de inhoud bewust verandert, hoort een reden bij. Zo blijft vernieuwing een bewuste verbetering in plaats van een toevallig gevolg van een ander sjabloon.

Een preview is een werkplek, geen bewijs van een geslaagde verhuizing

In een preview kun je ontwerp en functies beoordelen zonder de bestaande website meteen te vervangen. Dat is nuttig. Maar een preview kan andere instellingen hebben dan productie. Een formulier gebruikt misschien testgegevens. Een koppeling is nog uitgeschakeld. Een adres verwijst nog naar een tijdelijke omgeving.

Wij zouden bij iedere preview expliciet opschrijven wat echt is en wat gesimuleerd. Kun je een aanvraag versturen? Waar komt die dan terecht? Is een betaling een test of een echte transactie? Zijn getoonde tijden afkomstig uit een actuele agenda? Dat voorkomt dat een overtuigende demonstratie meer zekerheid geeft dan de onderliggende inrichting rechtvaardigt.

De publicatiecontrole moet daarna opnieuw naar de echte omgeving kijken. Het feit dat een testformulier gisteren werkte, bewijst niet dat de productie-instellingen vandaag kloppen. Controleer de functies die voor jouw bedrijf essentieel zijn en gebruik daarvoor afgesproken testgegevens. Voorkom dat tests als echte klanten of omzet worden geregistreerd.

Een AI-assistent kan helpen een testlijst samen te stellen en verschillen te zoeken. Hij mag de betekenis van “live gecontroleerd” niet oprekken. Een geplande test, een geslaagde build en een werkelijk doorlopen gebruikersroute blijven drie verschillende resultaten.

Verlies geen toegang, aanvragen of klantrechten

Bij een informatieve website gaat veel aandacht naar pagina's. Zodra er accounts, afspraken of aankopen zijn, wordt de overgang ingewikkelder. Een bestaand account moet niet verdwijnen omdat het nieuwe ontwerp een ander inlogsysteem gebruikt. Een betaalde klant mag niet opnieuw moeten betalen om dezelfde toegang te krijgen.

Maak daarom een aparte lijst van bedrijfsprocessen. Denk aan inloggen, wachtwoordherstel, formulieren, downloads, afspraakbevestiging en eventuele betalingen. Schrijf bij ieder proces welke gegevens behouden moeten blijven en wie bevoegd is om de overgang te controleren. Gebruik geen volledige klantbestanden in een algemeen projectdocument.

Wij zouden ook de volgorde bespreken. Misschien kan de publieke website al over terwijl een bestaand platform apart blijft functioneren. Dat kan een verstandige keuze zijn wanneer het anders te veel veranderingen tegelijk worden. De bezoeker moet dan wel een duidelijke en werkende route tussen beide onderdelen hebben.

Er is geen universeel migratiescript dat al die afwegingen oplost. De details hangen af van de bestaande techniek en afspraken. Juist daarom is het belangrijk om vóór de offerte te vertellen welke functies bedrijfskritisch zijn. Een webbureau kan niet behouden wat het nooit heeft geïnventariseerd.

Plan publicatie als een gecontroleerde verandering

Een publicatiemoment is geen verrassing aan het einde van de bouw. Spreek af wie beslist dat de nieuwe versie klaar is, wie de wijziging uitvoert en wie bereikbaar blijft voor controles. Geef ook aan wat de reden is om niet te publiceren. Een ontbrekende essentiële test hoort niet automatisch te wijken voor een gewenste datum.

Een praktische afspraak kan zijn dat de vorige omgeving beschikbaar blijft totdat de overeengekomen controles afgerond zijn. Wat daarvoor nodig is, verschilt per systeem. Laat de beheerder uitleggen hoe teruggaan zou werken en welke gegevens daarbij aandacht vragen. Een backup noemen is niet hetzelfde als een uitvoerbaar terugvalplan hebben.

In backup en hersteltest bespreken we waarom je herstel als aparte taak moet bekijken. Bij een migratie is vooral relevant wat er gebeurt met gegevens die na de overgang ontstaan. Een oude kopie terugzetten kan gevolgen hebben voor nieuwe aanvragen of wijzigingen. Die afweging moet vooraf bekend zijn.

Leg tijdens de publicatie vast wat daadwerkelijk is veranderd. Geen geheime waarden, wel de relevante versie of publicatie en het tijdstip. Daarmee kan een volgende beheerder gericht onderzoeken wat er is gebeurd. Een korte, betrouwbare registratie is nuttiger dan een lange chat vol aannames.

Kijk na de verhuizing naar signalen met context

Google Search Console geeft onder meer inzicht in zoekprestaties en problemen rond het verschijnen van pagina's in Google. Het is daarmee een nuttige bron voor de controle na een migratie, maar niet het volledige beeld van je bedrijfsresultaat. Bron: Google, aan de slag met Search Console.

Vergelijk relevante perioden en kijk naar dezelfde soorten pagina's. Een dag met minder klikken is op zichzelf geen diagnose. Een foutieve aanvraagroute kan bovendien omzet kosten zonder dat het aantal bezoeken direct verandert. Combineer technische meldingen daarom met wat je team merkt aan echte aanvragen en bereikbaarheid.

Wij zouden vooraf bepalen wie de eerste controles uitvoert en welke afwijkingen aanleiding zijn voor onderzoek. Bijvoorbeeld een belangrijke oude URL die niet meer werkt, een contactformulier dat geen bevestiging geeft of een onverwachte blokkade op een kernpagina. Dat zijn concrete signalen waarop je kunt handelen.

Maak ook ruimte voor kleine correcties die pas in gebruik zichtbaar worden. Een migratie is niet mislukt omdat iemand een ontbrekende afbeelding ontdekt. Wel moet duidelijk zijn hoe zo'n melding wordt opgepakt. Het verschil tussen goed en slecht beheer zit vaak in die herkenbare opvolging.

Checklist voor een beslissing over livegang

Voordat wij een overgang afgerond zouden noemen, willen we antwoorden op deze vragen:

1. Is duidelijk waarom we migreren en welk probleem daarmee wordt opgelost?
2. Zijn urgente onderhoudsmaatregelen los van de herbouw beoordeeld?
3. Zijn belangrijke bestaande pagina's en functies geïnventariseerd?
4. Zijn veranderende URL's inhoudelijk beoordeeld en technisch getest?
5. Zijn formulieren, contactroutes en eventuele accounts in de echte omgeving gecontroleerd?
6. Zijn tijdelijke preview-instellingen bewust afgehandeld?
7. Is er een uitvoerbaar terugvalplan dat rekening houdt met nieuwe gegevens?
8. Is afgesproken wie na publicatie kijkt naar bereikbaarheid, aanvragen en zoekprestaties?

Een vinkje hoort bij een bewijsstuk of waarneming. Niet bij “dat zal de bouwer wel gedaan hebben”. Dat hoeft geen zwaar rapport te zijn. Een lijst met gecontroleerde routes, testresultaten en open punten is voor veel projecten al veel duidelijker dan een algemene oplevermail.

Twijfel je aan de huidige afspraken, gebruik dan de beveiligingsvragen voor je webbureau. Wil je alternatieven vergelijken, lees dan over een website voor €75 per maand en bekijk onze prijzen. Een passende keuze begint bij de opdracht, niet bij een migratiebelofte.

Veelgestelde vragen over een websiteoverstap

Lees gericht verder

• PHP-kwetsbaarheid oktober 2026: eerst de actuele situatie vaststellen.
• Website zonder PHP: een techniekkeuze beoordelen.
• PHP updaten met een gecontroleerde aanpak.
• WordPress, PHP en plugins: drie verschillende onderdelen.
• Cloudflare en PHP-veiligheid: geen vervanging voor onderhoud.
• Backup en hersteltest: voorbereiden op teruggaan.
• AI en websitebeveiliging: toegang en controle afbakenen.
• Een volwaardige website voor €75 per maand.
• Twintig vragen aan je webbureau over beheer en beveiliging.

Bij zelf leren kun je je verder voorbereiden. Wil je weten hoe wij naar jouw bestaande website kijken, plan een gesprek. We beginnen met wat werkt, wat behouden moet blijven en wat je wilt verbeteren. Bij over ons lees je wie dat gesprek met je voert.