DEV Community

Cover image for Why Having a Staging Site Is Good for Your Sanity
mark l chaves
mark l chaves

Posted on • Updated on


Why Having a Staging Site Is Good for Your Sanity

Don't want to lose sleep over your website going down? Get a staging site.

You have a successful website. You're happy because you got your site up and running quickly on a tight budget.

Now, your website is the main source of your customers and sales. As your business grows so does your need for more functionality and plugins.

A few times a month, you make content updates and do software upgrades to your site all by yourself. You've never had any problems—you think running a website is a piece of cake.

The Nightmare

Then, one day after you just updated a dozen or so plugins, you start getting emails from customers, WordPress, and even Google. The emails say that you have a serious issue with your site.

You bring up your browser and try to pull up your site. All you get is a blank white screen.

This nightmare scenario happens all too often. The good news is, it can easily be avoided if you use what's called a staging site or staging environment.

Use a Separate Copy of Your Live Site

A staging site is a separate copy of your live website. The key words being: separate and copy.

Because a staging site is separate from your live site, you can do things like upgrading WordPress, your theme, and your installed plugins without affecting your live site. And, since a staging site is a copy of your live site, you can make changes and test the changes on a staging site as if it was your live site.

The Benefits of a Staging Site

After you verify that the changes you made on staging look good and work the way they should, then you can make those same changes on the live site. Testing updates on a staging site before applying the updates on your live site helps ensure:

  • Your site is still fully functional and continuing to deliver your online offerings.
  • There's no disruption of your online presence that you rely on to promote your brand awareness and preserve your credibility.
  • There's no loss of revenue and customers because of unplanned downtime.
  • No search engine penalties from non-working pages or missing content (e.g., 404 or 500 errors).
  • There's no loss of precious site content or customer data—namely for membership and eCommerce sites.
  • Your brand, credibility, and domain authority are protected.

Your Live Site Shouldn’t be Your Test Site

Staging sites don't have to be just for testing plugin updates. They can be an entire development environment for a new site, a place for troubleshooting and fixing an issue, or even a performance and scalability testing lab.

If you care about your business and your customers, you shouldn't be experimenting or making untested updates on your live site.

Does the phrase, "a copy of your live site" set off your SEO warning bells? Don't worry. You can password protect staging site (recommended). You can also tell search robots not to index your staging site. That means they won't affect SEO standings of your live site.

OK, just because you have a staging site doesn't mean you're completely in the clear. They can be misused just like any other tools in your toolkit.

In this article, I'll guide you through 8 best practices for using a staging site.

Please note that I'll use the words staging site, staging environment, and staging to all mean the same thing. I'll also refer to the live site as production.

8 Best Practices for Your Staging Site

1. But First, Take a Selfie Backup

A young Balinese man takes a selfie before a cremation ritual in Ubud, Bali by mark l chaves

A full backup means that all the files that make up your site are copied to a safe location. This is opposed to a partial backup where you can select to back up only parts of your site. A full backup includes WordPress core files, theme files, media files, and database (DB) files.

I recommend that you always make a full backup of your live site before creating the staging site copy. You can quickly restore everything back to normal from the full backup if needed.

You should always take another full backup of your live site when you make any changes to it.

These full backups are your insurance policy for when the live site becomes corrupted at any point during the process.

It's important to note that there's a difference between a daily backup and an instant (unscheduled) backup—sometimes called a snapshot. A snapshot taken just before updating the live site is good to practise for minimising data loss.

2. Disable Email Notifications

While working in staging, you should disable all email notification.

You definitely don't want to inadvertently flood your customer's inboxes if the work you're doing on staging is kicking out email notifications all over the place.

There are plugins that can temporarily disable notifications, yet log them for you as if they are sent. This is an awesome way to test emails without spamming everyone.

3. Clear Your Cache

It happens to all of us.

After we make a simple change we reload the page to see it, and it's not there. We hit reload a couple more times—still nothing.

We go back to the change. The change looks good.

We hit the save button just to be extra sure. We click reload again. Nothing.

We're just about the scream before we realise we should clear our caches.

Assuming your change doesn't have an error, you save your work, and you're looking at the right page, this problem is almost always due to caching.

To save time and your sanity, I recommend disabling your caches while you are making changes in staging. Only enable them when you are doing performance testing or to make sure there are no plugin conflicts if you use a caching plugin.

Make sure you clear your caches on the live site too when you push changes.

Image description

By the way, when we say caches, we mean all caches:

  1. Browser
  2. WordPress
  3. Server
  4. Database
  5. CDN

To top it off, some plugins build their own asset cache. Check your plugin's setting to see if they have one.

So, I get this all of the time, "I don't have a cache." Chances are you do and just don't know it yet.

4. Never Push the Staging DB to Production

Your production database should be the single source of truth. Treat it like your personal gold mine. Therefore, never contaminate it.

This means, never push your staging database to your live site.

Overwriting your production data from staging is never a good idea.

Some automated staging tools don't even permit pushing the staging DB to production. That's a good thing.

5. Don't Rely Only on Partial Backups

As I mentioned above, full backups are the only way to fly.

You might see options in your dashboard for backing up only the database, media, theme, or plugins. When it comes to working with staging environments, don't take partial backups.

You need to make sure you can always restore your complete site—not just pieces of it.

6. Don't Keep Your Backups on Your Website Server

There are two big reasons you shouldn't keep your full site backup on your website.

First, if your server crashes and all files are lost, your most recent full backup is also gone.

Second, your backup file(s) takes up disk space. Depending on the size of your site, your backup files can be humungous. Your available disk space could shrink to nothing if you have an increasing stockpile of backups on your site.

Your site will screech to grinding halt when you're out of disk space.

Just say no.

7. Restrict Access to Staging

Hosting plans that support staging sites usually create them with private access by default. However, you should always check especially if you manually created your staging site.

Staging sites should be controlled environments so you know what's happening to the site at all times. Password protect them.

Otherwise, you can be wasting precious time chasing your tail trying to figure out why the changes you made yesterday aren't working today.

And please remember. You don't want your staging site to show up on search results either.

8. Never do Automatic Updates

If your site is mission-critical, you'll lose revenue and customers when your site goes down.

You should never automatically update your WordPress version, your active theme, and any active plugins. Having auto-updates turned on is a recipe for disaster.

You'll need to check with your hosting provider's policy to see what their default update settings are. If they default to any kind of automatic updates, then you'll need to know how to disable them.

Parting Thoughts

I recommend that you always use a staging site even for updates that seem completely harmless. Conversely, I don't ever recommend using your live site to test changes or try out new things.

Unless of course:

  1. Your live site is private and has no visitors except for you.
  2. Your live site is public, but no one cares if it's up or down.

Cost used to be a factor for skipping staging sites. Luckily, more and more hosting plans include one-click staging environments.

With more support for staging sites, there's no reason to find out the hard way that running your operations without a staging site is a costly mistake.

Let's face it, having a website (whether it's on WordPress or not) requires continuous care and feeding. If you want a healthy and safe website that's always running the latest/greatest features, investing in a staging site is a no brainer.

Websites require continuous care and feeding - Our Millie playing with her ball by mark l chaves

Websites (like fur babies) need constant care and feeding.

Resources (no affiliations)


What is a staging site by WP Engine

Why you need a WordPress staging area and how to use one by Flywheel

How to Set Up a WordPress Staging Site by Elementor

Formidable Forms says to test on a staging site





  1. This article is a lean version of the original I wrote for the Uncanny Owl blog.
  2. Hero image is a photo I made at the Hard Rock Cafe in Kuta, Bali while covering a gig for Mata Jiwa and Navicula in 2018.
  3. All other images by mark l chaves unless otherwise stated.

Top comments (0)

Timeless DEV post...

Git Concepts I Wish I Knew Years Ago

The most used technology by developers is not Javascript.

It's not Python or HTML.

It hardly even gets mentioned in interviews or listed as a pre-requisite for jobs.

I'm talking about Git and version control of course.

One does not simply learn git