WordPress staging site opzetten — voorkom dat je productie-site sloopt

De ergste support-tickets zijn niet de hacks of de servercrashes. Het zijn de "ik heb een plugin geüpdatet en nu doet de site het niet meer" momenten — en bijna altijd was het te voorkomen geweest. Een staging-site is je veiligheidsnet: een exacte kopie van je productie-site waar je veilig kunt experimenteren zonder dat bezoekers het merken.

In dit artikel: wat een staging-site precies is, vier manieren om er één op te zetten (van eenvoudig tot specialistisch), en wat je vooral wel en niet moet doen ermee.

Wat is een staging-site?

Een staging-site is een geïsoleerde kopie van je live website waar je wijzigingen kunt testen zonder risico. Dezelfde files, dezelfde database, dezelfde plugins — maar op een andere URL en op een andere database. Bezoekers van de echte site zien er niets van.

Wat je er typisch op test:

• WordPress core updates (vooral major versies zoals 6.x → 7.x)
• Plugin- of theme-updates
• Nieuwe plugins voordat je ze op productie zet
• PHP-versie wijzigingen (cruciaal — een PHP 7.4 site overzetten naar PHP 8.2 kan plugins breken)
• Custom code-wijzigingen in functions.php of templates
• Performance-experimenten (caching plugins, image optimization)
• WooCommerce-flow tests (van product naar checkout naar e-mail)
• Compatibiliteit met nieuwe PHP-extensies

De vier manieren om een staging op te zetten

Niet elke methode is voor elke site geschikt. Hier zijn de vier opties met hun voor- en nadelen.

Methode 1: Via managed hosting (eenvoudigst, soms duurder)

Veel managed WordPress-hosting biedt staging als ingebouwde feature. Eén klik in het dashboard en je hebt een complete kloon op een test-URL. Vaak nóg een klik om wijzigingen terug te pushen naar productie.

• Voordelen: zero setup, automatische sync, backup ingebouwd, technische details verstopt
• Nadelen: vaak alleen op duurdere hostingpakketten, vendor-lock-in, beperkt in hoeveel staging-sites je tegelijk hebt
• Voor wie: niet-technische site-eigenaren die geen rompslomp willen

Hosters die dit standaard bieden: Kinsta, WP Engine, SiteGround, Cloudways. Bij sommige Nederlandse hosters zit het in de hogere pakketten.

Methode 2: Via een plugin (gemakkelijk, werkt overal)

Plugins als WP Staging, Duplicator of BlogVault Migrate maken een kopie binnen je hosting. Geen aparte hosting-feature nodig — werkt op vrijwel elke WordPress installatie.

• Voordelen: werkt op elke hosting, gratis basisversie beschikbaar, redelijk eenvoudig
• Nadelen: gebruikt jouw hosting-resources, terug-naar-productie sync vereist soms premium-versie, niet alle plugins werken even goed
• Voor wie: site-eigenaren met basis WordPress-kennis die geen managed hosting hebben

WP Staging is voor de meeste mensen de beste optie. Gratis voor één staging-site, ~€90/jaar voor de Pro-versie met push-back functionaliteit.

Methode 3: Manueel via een subdomein (technischer, maximale controle)

Maak een subdomein aan zoals staging.jouwsite.nl, kloon je site daarheen via SSH/SFTP en mysqldump. Volledige controle, geen plugin-magie. Hoe het werkt:

1. Maak een subdomein aan via je control panel (cPanel, Plesk, DirectAdmin) — staging.jouwsite.nl
2. Maak een nieuwe database aan voor de staging
3. Op SSH:

   # Files kopiëren
   rsync -av --exclude='wp-config.php' \
     /home/user/public_html/ \
     /home/user/staging.jouwsite.nl/
   
   # Database dumpen en importeren
   mysqldump prod_db > prod.sql
   mysql staging_db < prod.sql

4. Maak een nieuwe wp-config.php in de staging-map met de staging database-credentials
5. Search-and-replace alle URL's in de database via WP-CLI:

   wp search-replace 'https://jouwsite.nl' 'https://staging.jouwsite.nl' \
     --path=/home/user/staging.jouwsite.nl/

6. Voeg een noindex toe in de staging om Google buiten te houden — via robots.txt of een meta-tag
7. Voeg HTTP basic auth toe via .htaccess zodat alleen jij de staging kunt bezoeken

• Voordelen: maximale flexibiliteit, gratis, leert je de onderliggende techniek
• Nadelen: tijdsintensief, vereist SSH-kennis, push-back is handmatig werk
• Voor wie: ontwikkelaars en gevorderde site-eigenaren die geen plugin willen

Methode 4: Local development (snelst voor ontwikkeling)

Niet op een server, maar op je eigen computer. Tools als Local by Flywheel, LocalWP, MAMP of DevKinsta draaien WordPress lokaal. Geen internet nodig om aan je site te werken.

• Voordelen: razend snel, geen serverbelasting, ideaal voor langdurige projecten, werkt zonder internet
• Nadelen: omgevings-verschillen tussen lokaal en server, plugins die HTTPS verwachten kunnen issues geven, deploy naar productie vereist extra stappen
• Voor wie: ontwikkelaars die regelmatig met WordPress werken

Local by Flywheel (gratis) is voor de meeste mensen de beste keuze: setup is letterlijk drie klikken, en het ondersteunt verschillende PHP-versies om compatibiliteit te testen.

Welke methode voor wie?

Een snelle decision tree:

• Heb je managed hosting met staging-feature? → Methode 1 gebruiken
• Werk je niet wekelijks aan je site, wil je geen technische rompslomp? → Methode 2 (WP Staging plugin)
• Heb je SSH-toegang, wil je het structureel goed inrichten en heb je meerdere sites? → Methode 3 (subdomein)
• Bouw je actief WordPress sites en wissel je vaak van project? → Methode 4 (lokaal)

De workflow: wat doe je op staging?

Een staging-site is alleen waardevol als je 'm gebruikt. De typische workflow:

1. Sync staging met productie: kopieer de huidige productie-site naar staging. Via plugin: één klik. Via manuele methode: rsync + database dump
2. Voer wijziging door op staging: update plugin, installeer nieuwe theme, wijzig PHP-versie
3. Test alles wat raakvlak heeft: niet alleen de homepage. Klik door checkout, formulieren, login, edge cases
4. Werkt het? → Push wijziging naar productie (zie hieronder hoe)
5. Werkt het niet? → Reset staging, probeer iets anders, of zoek naar de oorzaak zonder dat je productie raakt

Belangrijk: test op staging voor je iets op productie doet, niet andersom. "Even op productie kijken hoe het uitvalt en als het problemen geeft op staging fixen" werkt niet.

Het lastige deel: terug naar productie

Hier worden veel staging-projecten alsnog rampen. Je hebt iets getest op staging, het werkt, en nu moet je dezelfde wijziging op productie krijgen. Drie aanpakken:

1. Re-do op productie (eenvoudig, voor losse wijzigingen)

Als je op staging gewoon één plugin hebt geüpdatet en het werkt: doe dezelfde update op productie. Geen sync nodig — je weet nu dat het veilig is. Werkt voor 80% van de wijzigingen.

2. Push staging → productie (voor complexe wijzigingen)

Als je veel hebt veranderd op staging (theme aangepast, content toegevoegd, custom code), wil je staging in z'n geheel naar productie. Tools als WP Staging Pro doen dit met een knop, BlogVault Migrate ook.

Manueel via rsync + database dump kan ook, maar pas op: als productie ondertussen wijzigingen kreeg (nieuwe orders, blog posts), overschrijf je die. Daarom:

• Doe productie-sync alleen op rustige momenten (nacht, weekend voor B2B)
• Zet productie eerst in maintenance mode (zie .htaccess artikel)
• Maak vlak voor de push een verse backup van productie
• Test direct na de push of alles werkt

3. Selectief porteren (beste voor content + code mengingen)

Sommige wijzigingen wil je porteren (theme-aanpassingen), andere niet (test-content op staging). Dan moet je selectief zijn — bijvoorbeeld alleen de gewijzigde files, of alleen specifieke database-tabellen. Vereist meer technische kennis.

Veelvoorkomende fouten

Staging is open voor zoekmachines

De #1 fout. Google ziet een complete kopie van je site op staging.jouwsite.nl en indexeert 'm. Resultaat: duplicate content, ranking-issues, en soms wordt de staging zelfs het primaire resultaat in zoekresultaten.

Oplossing: HTTP basic auth via .htaccess plus noindex meta-tag plus X-Robots-Tag: noindex header. Drielagige verdediging.

Mail vanuit staging gaat naar echte klanten

Klant test bestelproces op staging, krijgt orderbevestiging — naar het echte e-mailadres dat in de database staat. Resultaat: verwarde klant, soms duplicaat-orders.

Oplossing: install plugin "WP Mail Logging" of "Disable Emails" op staging. Of gebruik een SMTP-trap zoals MailHog/Mailtrap die mails alleen lokaal vasthoudt.

Staging is niet up-to-date

Je hebt een staging gemaakt drie maanden geleden, en getest met die oude versie. Maar productie is intussen 3x geüpdatet — je test in feite een onbestaande situatie. Sync staging met productie elke keer voordat je iets test.

Productie database overschrijven met staging

Per ongeluk bij een sync 'm verkeerde kant op gaan, en alle echte orders/customers/blog-posts zijn weg. Maakt altijd vóór de sync een backup van productie, ook al duurt dat 5 minuten extra.

HTTPS-mismatches

Productie draait op HTTPS, staging op HTTP. Resultaat: redirect-loops, "mixed content"-fouten, broken cookies. Zorg dat staging óók HTTPS gebruikt — bv. via Let's Encrypt, of self-signed cert + browser-uitzondering.

Cron jobs blijven draaien

Staging stuurt nu zelf nieuwsbrieven, plaatst geplande blog-posts, of stuurt Google Analytics events. Alles dubbel ten opzichte van productie. Schakel wp_cron uit op staging via wp-config.php:

define('DISABLE_WP_CRON', true);

Wanneer schakel je hulp in?

• Je site is groter dan 5GB of de database meer dan 1GB — dan zijn standaard staging-plugins onbetrouwbaar en heb je een specifieke setup nodig
• WooCommerce of LMS site met live klanten en orders — de sync-back is hier complex en risicovol
• Je hebt custom code in functions.php of plugins die per omgeving config moeten hebben (DEV / STAGING / PROD constants)
• Je werkt met meerdere developers tegelijk en hebt een Git-gebaseerde workflow nodig
• Multi-site WordPress — staging voor multi-site is duidelijk anders dan single-site
• Je hebt structureel staging nodig (wekelijks updates) en wil het automatiseren

Voor de meeste sites is een eenvoudige plugin-staging genoeg. Maar zodra het een commercieel-kritische site is met regelmatig updates, betaalt de tijd-investering in een goede staging-workflow zich razendsnel terug — gewoon door één keer geen catastrofe op vrijdagmiddag.