Qu'est-ce que le staging et comment le créer sur votre compte d'hébergement?

TL;DR

• Staging is een kopie van je website waarop je wijzigingen test voordat ze live gaan. Zelfde bestanden, zelfde database, andere adres.
• Je hebt het nodig zodra een fout je bezoekers of je omzet raakt. Bij een webshop is dat vanaf dag één.
• Veel hostingpartijen hebben een stagingfunctie met één knop. Heb je die niet, dan kan het via een plugin of handmatig.
• Zet je stagingomgeving altijd op noindex en achter een wachtwoord. Anders belandt je testversie in Google en concurreert die met je echte site.
• Google adviseert bij een migratie zelf om een testomgeving met beperkte toegang te gebruiken. Hetzelfde principe geldt voor elke wijziging.
• De grootste valkuil: je database. Nieuwe bestellingen en formulierinzendingen komen op je live site binnen, niet op staging.
• Test altijd je formulieren, je betaalproces en je site op mobiel. Dat zijn de drie dingen die het vaakst stuk zijn zonder dat je het ziet.

Introductie

Je wil een plugin bijwerken, je thema aanpassen of een nieuwe pagina bouwen. Je doet het op je live site, want dat is de site die je hebt. En dan blijkt je contactformulier niet meer te werken, of staat je halve homepage scheef. Terwijl je bezoekers meekijken.

Dat is precies waar staging voor bestaat. Een stagingomgeving is een kopie van je website waarop je alles kunt uitproberen zonder dat iemand er iets van merkt. Werkt het, dan zet je het live. Werkt het niet, dan gooi je de kopie weg en is er niets gebeurd. In deze blog leggen we uit wat staging is, wanneer je het nodig hebt, hoe je het aanmaakt en welke fouten je moet vermijden.

Wat is staging?

Staging is een aparte, niet-openbare kopie van je website waarop je wijzigingen test voordat je ze doorvoert op je echte site. De kopie heeft dezelfde bestanden, dezelfde database en dezelfde instellingen, maar staat op een ander webadres en is afgeschermd voor bezoekers en zoekmachines.

Je werkt dan met twee omgevingen naast elkaar:

• Productie. Je live site, de site die je klanten zien. Hier wijzig je niets waarvan je niet zeker bent.
• Staging. Je testkopie. Hier mag alles stuk.

Sommige bedrijven werken met drie omgevingen en zetten er nog een ontwikkelomgeving voor, maar voor een mkb-website zijn twee genoeg.

Het woord “staging” komt uit softwareontwikkeling en betekent zoiets als de wachtruimte vóór de livegang. Andere namen die je tegenkomt: testomgeving, acceptatieomgeving of preview. Inhoudelijk is het hetzelfde.

Wanneer heb je een stagingomgeving nodig?

Zodra een fout op je website je iets kost. Bij een webshop is dat direct: een kapot afrekenproces betekent gemiste omzet, en dat merk je pas als iemand belt. Bij een bedrijfswebsite met een contactformulier is het bijna zo urgent, want een formulier dat stil stopt met versturen zie je niet in je statistieken.

Je hebt staging in ieder geval nodig als een van deze dingen geldt:

• Je hebt een webshop. Elke wijziging aan je thema, je betaalmethoden of je verzendregels test je eerst.
• Je site levert aanvragen op. Formulieren zijn het meest fragiele onderdeel van een WordPress-site en breken vaak bij een plugin-update.
• Je gebruikt veel plugins. Meer plugins betekent meer kans dat twee updates elkaar in de weg zitten.
• Er werken meerdere mensen aan je site. Dan wil je een plek waar iemand iets kan uitproberen zonder overleg.
• Je gaat iets groots doen. Een nieuw thema, een grote pagebuilder-update, een migratie of een redesign.

Wanneer je zonder kunt: een eenvoudige site met een handvol pagina’s, geen formulieren en weinig plugins, waar een half uur haperen niemand raakt. Ook dan geldt: maak wel een back-up voordat je iets doet.

Hoe maak je een stagingomgeving aan?

Er zijn drie manieren, en de eerste is voor bijna iedereen de beste. Kijk eerst in het beheerpaneel van je hosting of er een stagingfunctie zit. Bij veel WordPress-hostingpakketten maak je met één knop een kopie aan en zet je wijzigingen later met een tweede knop terug naar je live site.

1. Via je hosting. De makkelijkste route. In je beheerpaneel staat vaak een knop als “Staging aanmaken” of “Create staging site”. De omgeving is meteen afgeschermd en de synchronisatie terug naar productie is ingebouwd. Bij ons zit dit standaard in onze WordPress hosting.

2. Via een plugin. Heeft je hosting geen stagingfunctie, dan zijn er plugins die een kopie voor je maken op een subdomein of submap. Werkt goed voor een eenvoudige site. Let op dat je een plugin kiest die actief wordt onderhouden, en test de terugweg naar productie voordat je erop gaat vertrouwen.

3. Handmatig. Je maakt een subdomein aan, kopieert de bestanden, exporteert en importeert de database en past je configuratiebestand aan. Dit werkt altijd en geeft je de meeste controle, maar het is precies werk. Vergeet je een stap, dan wijst je testomgeving naar je live database, en dat is het scenario dat je juist wilde voorkomen.

Wat je in alle drie de gevallen doet nadat de kopie er staat:

• Zet de omgeving op noindex. Zodat Google hem niet indexeert.
• Zet er een wachtwoord op. Via je hosting of met een basic auth-wachtwoord op de map.
• Schakel e-mails uit. Anders sturen je testbestellingen echte bevestigingsmails naar echte klanten.
• Zet je betaalkoppelingen op testmodus. Bij een webshop is dit de belangrijkste van de vier.

Waarom moet je stagingomgeving uit Google blijven?

Omdat een geïndexeerde testomgeving met je echte site concurreert op dezelfde inhoud. Google ziet dan twee bijna identieke sites en kiest zelf welke hij toont. Dat kan je testversie zijn, met een adres als staging.jouwsite.nl, en dan sturen je zoekresultaten bezoekers naar een omgeving die niet af is.

Zo houd je het dicht:

• Een noindex-tag of een X-Robots-Tag-header op de hele omgeving. Google legt de mogelijkheden uit in de documentatie over de robots-metatag.
• Een wachtwoord op de omgeving. Dit is sterker dan noindex, want dan komt er niets binnen. Google adviseert bij een migratie zelf een testomgeving met beperkte toegang.
• Geen links naar je staging. Zet het adres niet in een openbaar document, een mail met een openbare archieflink of een ticketsysteem dat indexeerbaar is.

En dan de belangrijkste stap, die het vaakst wordt vergeten: haal de noindex weg voordat je live gaat. Zet je een nieuwe site live door je stagingomgeving naar productie te kopiëren, dan gaat die noindex mee. Je nieuwe site staat dan online en verdwijnt vervolgens rustig uit Google. Dat is een van de klassieke fouten na een livegang, en hij is pas na weken te zien.

Hoe test je wijzigingen in je stagingomgeving?

Werk met een vast lijstje in plaats van rondklikken op gevoel. De onderdelen die het vaakst stuk zijn na een wijziging zijn je formulieren, je afrekenproces en je weergave op mobiel, en dat zijn precies de drie dingen die je niet ziet als je alleen even naar je homepage kijkt.

Loop na elke wijziging deze punten langs:

• Je formulieren. Vul ze echt in en controleer of de melding aankomt. Niet alleen of het formulier er staat.
• Je afrekenproces. Bij een webshop: hele bestelling doorlopen in testmodus, inclusief betaalmethode, verzendkosten en de bevestigingsmail.
• Mobiel. Op een echt toestel, niet alleen in het smalle venster van je browser.
• Je belangrijkste pagina’s. Homepage, je twee of drie best bezochte dienstpagina’s en je contactpagina.
• Je inlogpagina en je beheerpaneel. Klinkt overbodig, maar een kapot beheerpaneel na een update komt voor.
• Je snelheid. Een grote wijziging kan je pagina zwaarder maken zonder dat je het ziet.
• Toetsenbordnavigatie. Leg je muis weg en probeer je formulier in te vullen met Tab.

Noteer wat je hebt getest. Bij de volgende update loop je hetzelfde lijstje af, en dan weet je zeker dat je niets overslaat omdat je haast had.

Hoe zet je wijzigingen live vanuit staging?

Als je hosting een synchronisatiefunctie heeft, gebruik je die: één knop zet je bestanden en eventueel je database terug naar productie. Zonder die functie kopieer je de bestanden en, indien nodig, de database handmatig terug. Maak in beide gevallen éérst een back-up van je live site.

Hier komt de belangrijkste beslissing van het hele verhaal: wat doe je met je database?

• Alleen bestanden terugzetten. Doe je bij wijzigingen aan je thema, je opmaak of je code. Je live database blijft intact, dus nieuwe bestellingen en formulierinzendingen blijven staan.
• Ook de database terugzetten. Doe je bij nieuwe pagina’s, gewijzigde teksten of instellingen die in de database staan. En dan overschrijf je alles wat er sinds het maken van de kopie op je live site is binnengekomen.

Dat tweede is waar het misgaat. Werk je een week in staging aan nieuwe pagina’s en zet je dan je hele database terug, dan zijn de bestellingen en aanvragen van die week weg. Bij een webshop is dat een ramp.

Hoe je dat voorkomt:

• Houd je stagingperiode kort. Uren of dagen, geen weken.
• Voer inhoudelijke wijzigingen op je live site door, en gebruik staging voor techniek en opmaak.
• Synchroniseer selectief als je hosting dat toestaat: alleen bepaalde tabellen of alleen bestanden.
• Maak vooraf een back-up van productie. Dan kun je terug als het toch misgaat.

Na de livegang controleer je nog drie dingen: staat de noindex eruit, werken je formulieren, en zijn je URL’s ongewijzigd. Dat is vijf minuten werk en het voorkomt de vervelendste fouten.

Wat gaat er meestal mis met staging?

Vijf dingen. De noindex blijft na de livegang staan, de database wordt onvoorzichtig teruggezet, de testomgeving stuurt echte e-mails, de omgeving raakt maanden verouderd, en er wordt getest door alleen naar de homepage te kijken.

De volledige lijst met wat je eraan doet:

• Noindex blijft staan na livegang. Zet het controleren ervan als vaste stap in je livegangchecklist.
• Database overschrijven. Zie de vorige sectie. Kort staging, of selectief synchroniseren.
• Echte e-mails uit je testomgeving. Schakel uitgaande mail uit zodra je de kopie hebt gemaakt.
• Een oude stagingomgeving. Een kopie van drie maanden oud is geen betrouwbare test meer, want je live site is inmiddels veranderd. Maak een verse kopie bij elke serieuze wijziging.
• Staging die blijft staan en niet is afgeschermd. Een verlaten testomgeving met verouderde plugins is een veiligheidsrisico. Ruim hem op als je klaar bent.
• Alleen de homepage checken. Gebruik een lijstje.
• Denken dat staging een back-up is. Dat is het niet. Je hebt beide nodig.

Dat laatste punt verdient nadruk. Staging is er om te testen, een back-up is er om te herstellen. Ze vervangen elkaar niet. Hoe je dat samen inricht staat in onze blog over het perfecte WordPress onderhoudsschema.

Waarom is staging onderdeel van goed onderhoud?

Omdat de updates die je moet doen ook het risico vormen. WordPress zelf is stabiel; het risico zit in je plugins. In 2025 werden 11.334 nieuwe kwetsbaarheden in het WordPress-ecosysteem gevonden, waarvan 91% in plugins en 9% in thema’s. Bij zwaar aangevallen lekken is de mediane tijd tot het eerste misbruik ongeveer vijf uur.

Daar zit de spanning: je moet snel updaten voor je veiligheid, maar snel updaten zonder testen kan je site slopen. Staging lost dat op. Je zet de update op je kopie, loopt je lijstje af, en zet hem daarna live. Dat kost je een kwartier extra en het is het verschil tussen beheerst en hopen.

Praktisch ziet een gezonde routine er zo uit:

• Beveiligingsupdates: zo snel mogelijk, na een korte controle op staging.
• Reguliere plugin-updates: maandelijks, gebundeld, eerst op staging.
• Grote updates (thema, pagebuilder, WordPress-hoofdversie): altijd eerst op staging, met een back-up van productie.
• Na elke ronde: je lijstje aflopen op productie.

Wil je dit niet zelf bijhouden? Dan doen wij het. Bij ons WordPress onderhoud testen we updates op een stagingomgeving voordat ze op je site komen. Vooraf weet je wat we doen en wat het kost.