Staging vs Production: Why You Need a Safe Place to Test Changes

Changing a live website directly is like repairing an aircraft in flight. Sometimes it works, and when it does not, customers see it. The standard remedy in software is to separate environments: you try changes first in a copy of the site, and only when they behave do you apply them to the real one. This article explains the roles of each environment and how to build a staging setup that is genuinely useful and safe.

The usual environments and what staging is for

• Development: where code is written, typically on a developer's own computer, with fake data and debug tools switched on.
• Staging: a server environment that is as close to production as practical. Final testing happens here, including with real-looking data, the same PHP or Node version and the same web server configuration.
• Production: the live site that real visitors and customers use.

Small projects often skip development as a separate server and use the laptop for it. Having staging, on the other hand, is worth it even for modest sites, particularly for WordPress where an update to a plugin or PHP version can break a page layout or a checkout.

What staging is for

• Testing plugin, theme and framework updates before they reach customers.
• Trying a new PHP or database version and seeing what breaks.
• Rehearsing database migrations, including how long they take.
• Reviewing new features and designs with clients or colleagues.
• Practising the deployment process itself, so the real one is routine.

Keep staging similar, and its data separate

Match production

A test that passes in a different environment proves little. Match the operating system family, runtime versions, web server, PHP extensions and key settings. Differences are the classic source of "it worked in staging". Keep the configuration in files or environment variables, so you can see exactly where staging deliberately differs. If both can run on the same server, give staging its own system user, database and files, so a mistake cannot touch production data.

Separate data and credentials

Staging needs realistic data to be a good test, but never the same live connections:

• Separate database. Never point staging at the production database. A test that deletes records would delete real ones.
• Different credentials for every secret, as described in our article on environment variables.
• Payment gateways in test mode, so no genuine charges happen.
• Email sending disabled or redirected. A staging copy of a shop that emails real customers about test orders is an embarrassing mistake. Route mail to a catcher tool such as Mailpit, which captures messages for inspection instead of delivering them, or turn it off.
• Personal data. Copying a customer database into a less protected environment is a privacy risk. Consider anonymising or trimming it, and apply the same access controls you use in production.

Lock staging away from the public and from search engines

A staging site that is publicly indexed creates duplicate content and may leak unreleased work. Combine several protections. Put it on a separate subdomain such as staging.example.com, and require a login. In Nginx, HTTP basic authentication is easy:

location / {
    auth_basic "Staging";
    auth_basic_user_file /etc/nginx/.htpasswd-staging;
}

Create the password file with htpasswd (from the apache2-utils package on Debian and Ubuntu). As a second layer, tell search engines to stay away by adding a header:

add_header X-Robots-Tag "noindex, nofollow" always;

Password protection is the stronger of the two, because a noindex header only asks politely. In WordPress, also enable the "discourage search engines" setting on staging, and remember not to copy it back to production when you push changes.

A sensible workflow and WordPress staging

The workflow

1. Develop the change locally and commit it to version control.
2. Deploy to staging, preferably with the same script you use for production.
3. Test the changed feature and the critical paths: login, forms, checkout, key pages.
4. Take a fresh backup of production.
5. Deploy to production, then check the site and logs straight away.
6. Keep a rollback ready, as described in our articles on Git and zero-downtime deployments.

Staging for WordPress sites

WordPress adds a particular challenge: content lives in the database, while code lives in files. A common practice is to clone the production site to staging, test the changes there, and then repeat the same updates on production instead of copying the staging database back over live content (which would erase orders and comments created in the meantime). Tools in control panels can simplify cloning; if your Plesk edition includes the WordPress Toolkit, it offers cloning and related features, so check what your plan offers. Remember to update the site URLs after cloning, using the built-in settings or WP-CLI's search-replace, and to reset any live API keys.

A staging site also makes a good sandbox for security checks. You can run scans and try restoring a backup there without risk to live data. Read the security page for ideas on what to test.

Staging with Zebra Hosting

A staging site can live as a separate subscription or domain alongside your live one. See the options on our WordPress hosting page.