When and how to set up a staging site for WordPress

In our most recent blog article, I ran through how to avoid WordPress update anxiety by having a process for running updates on your WordPress site. In that article I mention the idea of having a staging site.

First off what is a staging site. A staging site is a duplicate or separate environment that replicates your live website. It serves as a testing ground where you can make changes, experiment with new features, plugins, themes, or content updates without affecting your live site. It allows you to preview and test modifications, troubleshoot issues, and ensure everything works as intended before deploying changes to your live site. A staging site helps minimise potential disruptions, maintain site stability, and provides a safe and controlled environment for website development and updates.

I would say having a staging site is best practice when it comes to running WordPress effectively, but it’s also overkill in cases where the site isn’t super critical because depending on your approach it can be a fair bit of work.

When should you have a staging site?

If the site is not super critical and the problems associated with it going down are minimal, I would probably not have a staging site. Some considerations would be:

How much traffic does the site typically get.
What are the ramifications of the site going down for a short period.
Do you sell products directly on the site (if so you definitely don’t want it going down if you can avoid it).
Do you have a great process for backups and restorations (see this post about that).
How complex are the updates. If it’s an old site with lots of updates to do, that might be a good reason to set up a staging site.
What resources are available to you if it doesn’t work? You don’t want to get stuck without a developer if your site goes down.

What are the options for setting up a staging site?

Assuming you do want to set up a staging site for managing updates there are essentially 4 options.

Have your developer set up a staging site on their local machine. This is quick and easy but it means only the developer can test the site before making changes and the server environment will not mimic your live site perfectly.
Have a staging site up on your live server either in a folder or in a subdomain up on the server. This enables you and your developer to test updates before you make them live in the exact server environment. But there is some risk here of getting the sites confused and adding complexity to the WordPress folder structure. Depending on how the server is set up you might be able to have a seperate file structure for the staging site but often it will just lump the subdomain into the main file structure.
Have your developer set up a staging site on their own publicly-available server. This means you can both access it for testing but it won’t replicate your hosting environment perfectly so there is still some risk that the site will behave differently on your server.
Utilising a managed WordPress hosting staging server feature. This is the best practice. With managed hosting, they have thought of all of this and often have 1-click staging site features where it will set up a totally seperate installation in a different location but under the same server conditions.

Obviously make a decision giving consideration to all the things I mentioned earlier, but if it’s a busy / critical site and you have the time and resources to go with option 4, that is the best bet.

How to set up a staging site

Setting up a staging site can be quite complicated. I won’t go into every last detail here but I have provided a reasonable amount of considerations to think about when setting it up. Again, a lot of these things may be covered already if your host has an inbuilt WordPress staging site feature. And standard disclaimer, if you aren’t sure, make sure you have some WordPress support (shameless plug) on hand.

Add .txt to the .htaccess file in the root to disable it and in the staging site go into settings / permalinks and save it to re-make a new one. .htaccess does lots of things that are out of scope for this article so don’t touch it if you don’t know what you are doing!
Look for backup plugins and disable them and delete any folders or backup files they create. This will just add excess bloat to the staging site. I’ve mentioned in articles I’m not a fan of WordPress backup plugins – much better to have backups sorted at the server level (see this post).
Look for any plugins that integrate with other systems like external CRMs, or any that send emails like checkout drop off emails and disable those. We don’t want the staging site sending any emails to customers. Good idea to ask the client here. You can manually disable plugins by navigating to the plugins directory and re-naming the plugin folder – just put a dot at the start of it. Or if you aren’t too worried about the plugin playing up, you can just launch the staging site with the plugin and disable it via the WordPress interface.
If the site is big use a local tool for working out where most of the size is coming from. I use Disk Inventory X for this on Mac, it’s super quick and free and you can work out really easily where the big files are. It’s very common for me to find massive unnecessary files like backups in the WordPress folders, or images that are unnecessarily large (like to the tune of 20 meg for an image that should be 200k). Remove or optimise anything unnecessarily large in this step.
Add a robots.txt file that disables search engine access to the site (or more accurately discourages it).
Create a new database and user on the staging server.
Update wp-config to new database on the server.
Export the live database and do the following find and replaces in the database SQL file (I’ve been using Sublime Text for this)
- Replace https://sitedomainname.com.au and http://sitedomainname.com.au and http://sitedomainname.com.au and https://www.sitedomainname.com.au and http://www.sitedomainname.com.au and www.sitedomainname.com.au with https://staging.sitedomainname.com.au and https:\/\/www.sitedomainname.com.au and http:\/\/www.sitedomainname.com.au and https:\/\/sitedomainname.com.au and http:\/\/sitedomainname.com.auwith https:\/\/staging.sitedomainname.com.au
After doing those updates search the database file for your live domain and go through the results. If you are using a subdomain you will see reference to the new subdomain (since it includes the main domain). You may see instances where the domain name exists as part of an email address or something like that. But you shouldn’t see the live domain name otherwise and if you do, you might need to do some more finding and replacing.
Set a password protection on the directory using either .htpasswd method or the inbuilt server feature if there is one. It’s important that people and crawlers can’t get into the site.
Once this is all done load the files into the staging environment and the database and navigate to site. With a bit of luck the site will be there with the same data as the live site.

And remember document absolutely everything. when we work with clients we have a shared Google doc with anything that happens on the site. If something doesn’t work as expected down the track, the notes document is critical for tracing back what happened.

I hope this article was useful. If you want some more hands on help with WordPress (Aussie businesses only), check out WP Master. If you have any feedback on the post feel free to hit me up on Twitter @thedannorris.

Photo by Jorik Kleen on Unsplash

About
Latest Posts

Dan Norris

Founder at WP Master

Founder of WP Master - Previously founded Black Hops Brewing and WP Curve. Author of 6 books including The 7 Day Startup.