Een nieuwe WordPress-website bouwen naast de oude is vaak een logische keuze wanneer je bestaande site moet blijven werken. Je ontwikkelt dan in een aparte omgeving terwijl bezoekers de huidige website gebruiken. Die scheiding geeft ruimte om te testen, maar maakt de overstap niet automatisch risicoloos.
De belangrijkste vraag is wat er tijdens de bouw op de oude website blijft veranderen. Nieuwe berichten zijn relatief eenvoudig te herkennen. Bestellingen, boekingen en klantgegevens vragen om een zorgvuldigere aanpak.
Maak een werkelijk gescheiden testomgeving
Gebruik een aparte ontwikkel- of stagingomgeving met toegangsbeperking. Alleen een moeilijk te raden webadres is geen afdoende bescherming. Voorkom daarnaast dat zoekmachines de testversie als openbare website behandelen.
Beperk welke persoonsgegevens je naar de testomgeving kopieert. Gebruik waar mogelijk fictieve testgegevens. Schakel echte betaalacties, verzendprocessen en automatische marketingberichten uit wanneer ze niet nodig zijn voor de test. Controleer die instellingen opnieuw na het kopiëren van de omgeving.
Spreek af welke inhoud de bron blijft
Bepaal of nieuwe teksten tijdens de bouw in het projectdocument, de oude website of de nieuwe omgeving worden beheerd. Zonder die afspraak ontstaan verschillende versies die iemand vlak voor de livegang handmatig moet vergelijken.
Houd een wijzigingslijst bij van inhoud die op de oude website wordt aangepast. Denk ook aan openingstijden, prijzen en voorwaarden. Het is zonde wanneer een technisch geslaagde migratie verouderde informatie opnieuw publiceert.
Kies de overdrachtsmethode op basis van data
Bij een eenvoudige bedrijfswebsite kun je soms met een korte wijzigingsstop werken. Bij een actieve webshop kan de database intussen nieuwe bestellingen bevatten. Dan is “de nieuwe site over de oude zetten” geen voldoende plan.
Laat de ontwikkelaar bepalen welke onderdelen worden overgezet en welke productiegegevens behouden moeten blijven. De WordPress-documentatie over migreren is een technisch vertrekpunt; de juiste werkwijze hangt af van thema’s, plug-ins en gegevensstructuur. Onzorgvuldig vervangen van domeinnamen in de database kan bovendien gegevens beschadigen.
Test met een realistisch scenario
Neem bijvoorbeeld een aanvraag die binnenkomt vlak voor de overstap. Waar staat die opgeslagen? Ontvangt de verantwoordelijke medewerker nog een melding? Kan een oude bevestigingslink na de verhuizing worden geopend?
Dit soort vragen hoort bij de bouw, niet alleen bij nazorg. Betrek een specialist in WordPress-ontwikkeling bij de technische scheiding en een verantwoordelijke uit het bedrijf bij de procescontrole.
Zorg dat terugdraaien werkelijk kan
Een back-up heeft pas praktische waarde wanneer duidelijk is wat hij bevat en hoe herstel werkt. Bewaar bestanden én de benodigde databasegegevens. Test herstel bij voorkeur vooraf in een aparte omgeving; zie de WordPress-uitleg over back-ups.
Leg bij een terugval ook vast hoe nieuwe aanvragen of bestellingen behouden blijven. Het terugzetten van een oude kopie kan anders het oorspronkelijke probleem oplossen en tegelijk nieuwe informatie verwijderen.
Plan de definitieve omschakeling pas nadat ontwerp, inhoud en kritieke functies zijn goedgekeurd. Combineer dit met technische SEO voor bestaande URL’s en vindbaarheid. Zo blijft parallel bouwen een gecontroleerde voorbereiding, in plaats van twee websites die op het laatste moment haastig moeten worden samengevoegd.