01 · Basics
What a staging environment is and why it matters
A staging environment is a non-public copy of your website or online store. That is where updates, new features or a redesign get tested. Only once everything works does the change go live.
Mistakes happen on the copy, not in front of your customers. Whether a plugin update breaks checkout, a theme update wrecks the mobile layout or a new Shopware version no longer supports an extension: on staging that costs time, live it costs revenue and trust.
The short answer
Host staging and plugins are enough for occasional tests on simple websites. For stores and websites that are worked on regularly, a separate environment with automated publishing and version control is the more robust solution.
02 · Overview
The four common options
01
Staging at your web host
One click in the hosting control panel creates a copy, usually on a subdomain. Depending on the provider, changes can be pushed back with a click.
Advantages
- quick to set up
- often included in the hosting plan
- no technical knowledge needed
Limits
- usually the same server infrastructure
- pushing back varies widely: sometimes the whole database, sometimes only files
- version history and anonymization are rarely provided
02
Staging plugins for WordPress
Plugins such as WP Staging create the copy right from WordPress, usually in a subdirectory and in the same database with a different table prefix.
Advantages
- independent of the host
- created in a few minutes
- good for a quick test
Limits
- shares server, storage and usually the database with live
- pushing back often only in the paid version
- not available in this form for Shopware
03
Local development copy
Developers work with a copy on their own computer, for example in a container environment. Ideal for the development itself.
Advantages
- completely separate from live
- fast
- no server costs
Limits
- you cannot view or approve anything there
- pushing back is often a manual upload
- real customer data on a laptop is risky
04
Dedicated staging server with deployment
This is how The Doppelgänger works, managed for you instead of built yourself
The copy runs on a separate server, the code lives in Git, and deployment automation publishes the tested version without FTP.
Advantages
- real separation from live
- traceable versions and rollback
- anonymization possible during copying
Limits
- a lot of effort to set up and maintain
- requires developer know-how
03 · Comparison
Comparison table
| Criterion | Host staging | Staging plugin | Local copy | Own server |
|---|---|---|---|---|
| Isolation from the live site | low to medium, usually the same infrastructure | low, same server, often the same database | high | high |
| Data protection and anonymization | rarely provided | rarely provided | possible by hand | can be built into the copying |
| Changes back to live | one click with some providers, often a full overwrite | often only in the paid version | usually by hand | automated publishing |
| Version history and rollback | hardly, usually just backups | hardly | possible via Git | yes, every release is a version |
| Effort | low | low | medium, developer knowledge needed | high to set up |
| Suitability for stores | limited | limited | only for development | good |
goodfairweak
04 · An honest look
The database problem when pushing back
This is where most staging solutions reach their limits. Say you test a redesign on the copy for two weeks. Meanwhile, things keep happening live:
- 2weeks of redesign on staging
- 3blog posts published live
- 150orders received live
If the staging database is now copied over the live database, the posts and orders are gone. Databases cannot be merged the way text files can.
Code flows from staging to live
Content and orders flow only from live to staging
Code
→ LiveTheme, plugins, extensions and configuration are transferred from staging to the live site.
Content and orders
← Stagingbelong to the live site and flow only from live to staging.
Settings in the database
⇄ Scriptsuch as menus, widgets or plugin options are transferred by script or redone live after publishing.
The first thing to ask about any staging solution: What happens to content and orders created live in the meantime?
05 · Data protection
Personal data in the copy
The staging copy of a store starts out with everything: customer names, addresses, email addresses, order histories. Even copying and storing it is processing under the GDPR. Tests usually do not need real customer data, and data minimization clearly favors anonymization.
There is also a practical risk: a test copy with real addresses can send real emails, such as order confirmations or newsletters. If you anonymize, the problem never arises.
If the copy sits with a service provider, that provider processes the data on your behalf. Under Art. 28 GDPR you need a data processing agreement for that.
Example · One record during copying
| Field | Live | Copy |
|---|---|---|
| Name | Anna Becker | Customer 20417 |
| anna.becker@… | kunde-20417@example.invalid | |
| Address | Lindenstraße 12, Düsseldorf | 1 Sample Street, 00000 Sampletown |
| Orders | 14 orders | 14 orders |
| Carts | products, prices, quantities | unchanged |
Products and order structures stay realistic, without a single real customer name.
06 · Visibility
Search engines and the staging copy
A publicly reachable copy can be indexed and then competes with your live site for the same search terms.
Not enough
robots.txt disallow
Only prevents crawling. A blocked address can still show up in the index if it is linked from somewhere.
Reliable
noindex signal
In WordPress via “Discourage search engines from indexing this site” (Settings › Reading).
Safest
Password protection at server level
Without credentials the copy cannot be reached at all. Best combined with noindex.
Caution
The noindex setting must never travel to the live site.
Otherwise your real website disappears from the search results.
07 · Checklist
Questions to ask any staging solution
Host offering, plugin or agency: these questions separate a workable solution from one that causes trouble when it matters.
- 01
How current is the copy?
Can the live version be pulled again at any time without losing work in progress?
- 02
What is transferred when publishing?
Only code and files, or the database too? What happens to content and orders created live?
- 03
How do you go back?
Is there a way back to the previous state, and does it take seconds, minutes or hours?
- 04
Who can see the copy?
Is it password protected, and can you still review and approve it easily?
- 05
What happens to customer data?
Is it anonymized, and is email sending switched off on the copy?
- 06
Does the environment match the live site?
Same PHP version, database version and extensions? A test on different technology proves little.
08 · Recommendation
Which option fits you?
Small website, rare changes
Host staging or a plugin is usually enough, backed by regular backups.
Host staging or pluginWebsite with regular content and inquiries
A plugin quickly gets confusing when people keep working on the live site in parallel. A separate environment pays off.
Separate environmentOnline store with WooCommerce or Shopware
Ongoing orders make the database problem acute. A separate environment, anonymized copies and automated publishing are the safe choice.
Own server with automated publishingFor Shopware I go into more detail in the guide Shopware 6 updates without downtime.
09 · My solution
Where the Doppelgänger fits in
The Doppelgänger is the fourth option, without you having to run a server or build deployment automation yourself.
Doppelgänger
Live site
- Change and test
- You approve
- ↻ Pull the live version back
- Automated publishing
I set up an exact copy of your WordPress website or Shopware store on a separate server in Germany (Hetzner, Falkenstein data center). Your live site stays with your current host and on your domain. I make and test changes and updates on the Doppelgänger, you review and approve, then automated publishing brings that version live in a few minutes and without downtime.
I can pull the current live version back onto the Doppelgänger at any time, and customer and order data is anonymized in line with the GDPR on every copy. Every change goes into the dossier, and every release is a version I can return to in seconds. More on the pages for WordPress and Shopware.
From a client: JuCad works with the Doppelgänger: every update and every new feature runs on the copy of the store first and goes live only after testing.
Doppelgänger for Shopware
Since our store got its Doppelgänger, where Julian checks every update and every change first, the store has been running absolutely smoothly. Updates are no longer a big project we keep putting off. We see and test new features there before they go live, and only approve them once everything is right. It has made our work noticeably more productive.
Bettina SanioHead of Marketing & Communications, JuCad®
Since 2020in my careShopware 6with the Doppelgänger
Frequently asked questions
Quick answers.
What is a staging environment?
A staging environment is a copy of your website or store that is not publicly reachable. That is where updates, new features or a redesign are tested. Only once everything works is the change transferred to the live website.
Is my host's staging good enough?
For occasional tests on a simple website, often yes. Check whether the copy is protected from search engines, how changes get back to the live site and whether that overwrites content changed live in the meantime. For stores with ongoing orders, that is exactly what is critical.
Can I put real customer data into a staging copy?
A copy is also processing of personal data and needs a legal basis and appropriate safeguards. The GDPR requires data minimization, and tests usually do not need real names, addresses and email addresses. The cleaner way is to anonymize this data while copying.
How do I stop Google from indexing my staging site?
Most reliably with password protection at server level, plus a noindex signal. A disallow in robots.txt only prevents crawling, not the address being added to the search index. If a staging copy is already indexed, password protection plus a removal request in Google Search Console helps.
Do I need a staging environment for a small website?
Not necessarily. For a website with a few pages and hardly any plugins, a good backup and care with updates are often enough. As soon as the website brings in inquiries or revenue, a test copy is cheaper than an outage.
Keep reading
More guides
Shopware
From Shopware 5 to Shopware 6: how to get the migration right
What moves over, what has to be rebuilt and how to keep your search rankings.
Learn more
Costs
Shopware Community Edition over €1 million in sales: what now?
What you lose above €1 million GMV, what Rise costs and why switching systems is rarely cheaper.
Learn more
Security
Cyber Resilience Act: what it means for your website or online store (and what it does not)
Who the CRA obliges, who it does not, and what changes indirectly for website and store owners.
Learn more
WordPress
Critical error after a WordPress update: how to get your website back
Recovery mode, switching a plugin off via FTP, rolling back a version and preventing it in the future.
Learn more
Shopware
From Shopware 5 to WooCommerce: how to get the move right
When WooCommerce fits, what moves over and how to protect your rankings and customer accounts.
Learn more
Costs
Website maintenance: What does it really cost?
Maintenance contracts compared, hours per update round, and what a single incident can cost.
Learn more
Security
NIS2 for small businesses: covered or not, and what your customers are asking now
Who NIS2 covers directly, what customers ask suppliers, and how to answer website questions with evidence.
Learn more
WordPress
How to update WordPress safely without putting your website at risk
Why postponing is risky and which routine keeps core, plugins and WooCommerce safe.
Learn more
Shopware
How to update Shopware 6 without putting your store at risk
Patch, minor or major: a checklist for backups, staging, extensions and rollback.
Learn more
Security
Online store hacked: what to do now
First steps for Shopware and WooCommerce: skimmers, payment providers, customer data, reporting.
Learn more
Shopware
Replacing Shopware 5: which alternative fits your store?
Shopware 6, WooCommerce, Shopify, JTL-Shop and Magento: costs, effort and which one fits whom.
Learn more
Security
PHP2Shell: what the critical PHP flaw means for your website
What the PHP flaw allows, who is affected and why this time your host has to act.
Learn more
Shopware
Shopware 6 update failed? Causes, the way back, security updates
Narrow down the cause, restore safely, and why security updates cannot wait.
Learn more
Security
PHP2Shell: what to do now
Check the PHP version, ask your host, protect the site meanwhile, look for signs of a break-in.
Learn more
Security
Security in the age of AI: what changes for your website
What AI changes about attacks on websites, what is proven, and which defenses really help.
Learn more
Security
Updates are mandatory: what the GDPR requires of website and store owners
What Art. 32 GDPR requires for updates, backups and access, and what supervisory authorities say about it.
Learn more
Security
WordPress hacked: what to do now
First steps, signs, backup or cleanup, the Google warning and the reporting duty.
Learn more