Serhii LypiiEen WordPress staging omgeving zet ik anders op dan de meeste tutorials voorschrijven, omdat dezelfde site over een jaar Drupal of Laravel naast zich kan hebben. Dat klinkt ver gezocht, maar in mijn ervaring kiezen ondernemers vaker dan ze denken voor een uitbreiding of migratie. Een staging-aanpak die alleen werkt met één specifieke WordPress-plugin staat dan in de weg.
Hieronder beschrijf ik de workflow zoals ik hem voor klanten opzet. Met een paar bewuste keuzes vooraf is een staging-omgeving niet een snel-klik-klusje, maar een fundament dat blijft staan. Ook als je site over een jaar groeit naar een hybride stack.
Waarom een WordPress staging omgeving anders is dan een back-up
Mensen halen deze twee vaak door elkaar. Een back-up is een momentopname die je terugzet als er iets kapot is. Een staging is een werkbare kopie waarop je dingen test voordat ze live gaan.
Een back-up is statisch. Je raakt hem niet aan, je laat hem liggen, je hoopt hem nooit nodig te hebben. Een staging is actief. Daar test je plugin-updates, ontwerp-wijzigingen, een nieuw thema, een WooCommerce-betaalkoppeling. Pas als het op staging werkt, gaat het naar productie.
Een derde misverstand: “ik draai het wel direct op live, het is een kleine wijziging.” In mijn ervaring is dat de manier waarop sites op vrijdagmiddag plat gaan. Iemand klikt op “Update”, een plugin breekt het thema, en het rolt zich door naar de checkout. Staging kost iets meer tijd vooraf en bespaart paniek achteraf.
Drie routes: plugin, hosting-knop, of handmatig op subdomein
Er zijn drie manieren om een staging op te zetten. Ze hebben allemaal hun plek.
Plugin-route. WP Staging is gratis, WP Stagecoach en BlogVault zijn betaalde alternatieven. Eén klik en je hebt een kopie op een subfolder. Werkt prima voor blogs en marketingsites. Nadeel: lock-in op één plugin, en bij grotere sites (WooCommerce met veel orders, multisite) loopt het mis.
Hosting-knop. Veel managed hosts (Kinsta, Cloudways, SiteGround, Combell, om enkele te noemen) bieden een native staging-knop. Meestal stabieler dan een plugin, want het draait op infrastructuurniveau. Nadeel: gebonden aan die hoster. Verhuis je, dan moet je opnieuw nadenken.
Handmatig op een subdomein. Eigen subdomein (bijvoorbeeld staging.jouwsite.nl), eigen database, kopie van bestanden, URL-rewrite via WP-CLI of een database-tool. Meer werk vooraf, maar hoster- en plugin-onafhankelijk. Dit is wat ik in de meeste gevallen kies, zeker als er een vermoeden is dat de site of de hoster nog gaat veranderen.
Wat ik kies en waarom
Mijn voorkeur ligt bij hosting-native staging waar die beschikbaar is en stabiel werkt, anders handmatig op subdomein. De plugin-route gebruik ik zelden, en alleen voor kleine sites zonder e-commerce.
De reden is simpel: hosting-native staging praat met de webserver, niet door WordPress heen. Een plugin moet via PHP een hele site klonen, en bij grote uploads-mappen of veel WooCommerce-orders crashed dat regelmatig. Hosting-native heeft toegang tot file-system-level kopieën en kan synchroniseren zonder PHP-limieten.
Handmatig op subdomein heeft een ander voordeel: ik hou de configuratie expliciet. Een .env-achtige scheiding tussen staging en productie (andere database-credentials, andere SMTP-instellingen, andere Stripe-keys) maak je dan zelf in wp-config.php met een conditionele check op WP_ENV of het hostname. Dat principe komt direct terug als je later een Laravel- of Drupal-omgeving naast WordPress zet.
Database-sync: de stap waar staging meestal misgaat
WordPress-data is serialized. Dat betekent: als je in de database een URL wilt vervangen, breekt een simpele search-replace de PHP-arrays die om die URL heen staan. Bijvoorbeeld widget-instellingen, theme-options en Yoast-data.
Daarvoor gebruik ik WP-CLI’s search-replace. Die snapt serialized data en herstelt de arrays correct na een vervanging. Een voorbeeld:
wp search-replace 'https://jouwsite.nl' 'https://staging.jouwsite.nl' --skip-columns=guid--skip-columns=guid is belangrijk: de guid mag niet veranderd worden, dat is een unieke identifier per post. Wie hem wel verandert, krijgt RSS-readers in de war.
Geen WP-CLI beschikbaar? Dan is WP-CLI search-replace docs je referentie, of je gebruikt Interconnect/IT’s Database Search Replace script. Die laatste upload je naar de root van je staging-site en draait via de browser. Niet vergeten te verwijderen na gebruik; het is een open script dat iedereen kan misbruiken.
Bij WooCommerce een extra regel: orders, klanten en betalingen ga je nooit terug-syncen van staging naar live. Een test-bestelling op staging mag niet terechtkomen in de productie-boekhouding. De richting van sync is altijd één kant op: live naar staging, niet andersom.
Indexering blokkeren en credentials separeren
Een staging-site die door Google geïndexeerd wordt is een duplicate-content-probleem en een lek van interne info. Drie maatregelen, ik gebruik ze meestal allemaal:
robots.txt + noindex meta-tag. Niet waterdicht, maar wel de eerste laag. WordPress heeft onder Instellingen > Lezen een vinkje “discourage search engines” dat een noindex-header toevoegt. Goed beginnen, maar niet vertrouwen op alleen dit.
Basic auth via .htaccess. Een browser-prompt om gebruikersnaam en wachtwoord voor de hele staging-omgeving. Zo serieus eenvoudig dat het me verbaast hoe weinig dit standaard is. Twee regels in .htaccess, één htpasswd-bestand, klaar.
Aparte database-credentials. Staging draait op een eigen database-user met een eigen wachtwoord. Als iemand staging-toegang krijgt, kan hij niet bij productie. Hetzelfde voor SMTP (dummy of MailHog), Stripe (test-keys), Mollie (test-mode), en welke API-koppeling dan ook waarvoor live-keys risico betekenen.
Eén keer per project tijd nemen voor deze setup bespaart elke keer paniek wanneer iemand “even iets” wil testen.
Van staging naar productie zonder backup-restore-paniek
De gevaarlijkste fase: deploy van staging naar live. Hier gaan sites stuk. De val is dat mensen de hele staging-database over productie heen kopiëren, en daarbij hun live-content, orders en gebruikers overschrijven.
Wat ik doe in plaats daarvan:
Code en config via Git of SFTP. Het thema, eventuele custom plugins, child-theme-aanpassingen, en wp-config-wijzigingen verhuizen via versiecontrole of een gerichte file-upload. Niet de hele wp-content-map kopiëren, alleen wat is gewijzigd.
Database-tabellen selectief. Heb je nieuwe plugin-settings, ACF-velden of een Yoast-config aangepast op staging? Die zitten in wp_options, wp_postmeta en plugin-specifieke tabellen. Per geval bekijken: kun je het opnieuw doen op live (vaak het veiligst), of moet je specifieke rijen exporteren en importeren?
Content niet syncen. Posts, pages, comments, orders blijven op live. Wijzigingen aan content doe je rechtstreeks op productie, niet op staging. Staging is voor code en config, niet voor blogposts.
Voor een gemiddelde wijziging duurt de deploy zelf 10 tot 30 minuten als je de checklist hebt. Een back-up vooraf is standaard, ook bij kleine deploys. Verbeteren boven herbouwen werkt alleen als je niet bij elke deploy het risico loopt opnieuw te moeten beginnen.
Hoe deze workflow ook voor Joomla, Drupal en Laravel werkt
Het principe achter een goede staging is platform-onafhankelijk: kopie van data + URL-rewrite + index-blokkering + getest deploy-pad. Wat verandert is de tooling per stack.
Joomla heeft Akeeba Backup als de facto kloon-tool: maakt een complete site-snapshot, restore op een subdomein, met ingebouwde URL-rewrite. Hetzelfde indexering-blokkering-principe geldt, hetzelfde deploy-pad voor code en config.
Drupal heeft drush sql-sync om databases tussen omgevingen te synchroniseren, plus Configuration Management voor het scheiden van code en data. Je commit de config in Git, de content blijft per omgeving uniek. Cleaner dan WordPress in dit opzicht.
Laravel kent .env-files voor per-omgeving-configuratie en php artisan migrate --pretend om migraties te previewen voordat je ze draait. Staging is hier vaak een aparte server of Docker-container, niet een subdomein op dezelfde stack.
In alle gevallen geldt: de source-code is van jou, dus de staging-omgeving moet kunnen meereizen als je later van stack wisselt. Een staging die alleen werkt met één specifieke WordPress-plugin is een gevangenis als je gaat groeien.
Voor doorlopend onderhoud waarbij staging als standaard wordt opgezet en gebruikt, kun je terecht bij doorlopend onderhoud met staging als standaard. Ik werk dan op standaard uurtarief van 70 euro per uur, zodat je staging-werk en updates uit dezelfde pot komen.
