You wouldn’t jump head first into a lake you haven’t even heard of before testing the waters first and WordPress is no exception. Testing updates and changes before applying them can save your website from total destruction.
Updates can sometimes break your site, but if you test them beforehand, you can find out if the changes are going to wreak havoc without endangering your site or your user’s experience.
The tried and true method of testing is by using a staging site or a local environment, but it can be tricky to know how to use them effectively.
Today, I’ll share more detail on what staging sites and local environments are as well as how to use them with WordPress to achieve the perfect workflow for testing updates and changes before applying them.
As mentioned above, it’s important to have a workflow that includes testing updates and changes you make to your WordPress site.
It helps prevent errors such as your public-facing website breaking or having visual inconsistencies by catching them before they have a chance to spread to your visitors.
Updates and changes you make to your website can sometimes break your site and it happens for two main reasons: The code itself and compatibility.
If a plugin, theme or script you’re using is coded poorly, it has a high potential of breaking some aspect of your website or it can bring your whole website down in one fell swoop.
Unfortunately, plugins, themes, scripts, apps and software in general can be coded well, but still case errors and other issues. Solid code is often referred to as clean code and it can still cause your site to break because code has a lot of variables.
On one hand, that’s a great thing because it means you can do almost anything with code on your WordPress website including creating a social network, an app, a membership, eCommerce or jobs board site, accept appointment bookings, manage customer support tickets and a lot more. The list can go on and on, really.
On the other hand, coding uses programming languages and they’re a lot like written languages in that there are an infinite ways to describe one object such as an apple.
These infinite variables can end up causing compatibility issues, which is when one script clashes with another. It’s like trying to fit together two gears that don’t match. When you put them in a machine, they’re bound to grind together, then break the entire machine in an inelegant, smokey combustion.
When it comes to WordPress, it can be difficult to test it against all the other millions of platforms, apps and other software for compatibility. This means that inevitably, no matter how skilled a developer, some aspect of their code is going to break at some point.
That’s why it’s important to test any change or update you want to apply to your website before you actually go ahead and activate them on your live website. It helps you catch most or all of the errors and issues before they find their way to your visitors.
For details, check out Why Keeping WordPress Updated is Critical and Non-Negotiable.
The best workflow is to test updates before you apply them. You can do your testing on either a staging site or a local environment.
Below, you can find more details on both methods as well as the advantages and disadvantages of both, and which one may be right for your WordPress website.
A staging website is a live site that mirrors your own, but is used for testing purposes. It’s also not meant to be shared with the public so it’s often also password-protected
In this case, mirroring referrers to these two sites in that they are the same other than the fact that:
The staging site is essentially a copy of the original website that you can test on without disrupting the user experience of your original site.
Depending on your needs, running a staging site may or may not be ideal. In order to decide if it’s right for you, it’s important to look at the advantages and disadvantages of creating a staging site.
Because the staging site is live, it reacts the same way your live site does, as long as it’s on the same or a similar server and setup. This is particularly helpful if you want to test the speed of your site, for example, after adding some updates or changes.
It’s also easy to share your staging site. You can give access to others so they can also test updates or changes. They don’t need any extra software and it’s as simple as accessing any other website on the internet.
Given that there aren’t any errors or compatibility issues, any updates or changes such as adding plugins or themes are guaranteed to work. I’ll explain this a bit more later on.
It has the same vulnerabilities as any other live site so it’s not immune to hacking attempts. This also means you need to manage and maintain two whole sites at the same time because of the potential security risk of hosting it on a live server.
If you don’t get hacked, you could still lose access to the site if your internet isn’t working. Similarly, if the server the staging site is on has errors or goes down, you aren’t going to able able to access it and you could potentially lose everything on it.
If you granted access to someone that isn’t trustworthy, they could share their login credentials to anyone and compromise the security and privacy of your staging site.
A staging sites also requires server resources, which means keeping a staging site is a recurring expense that could become costly, especially as your site grows overtime. You may also decide to purchase a domain for it which is another yearly expense.
Lastly, because it’s live, your staging site can only run as fast as the server resources allow. If your server isn’t particularly good or speedy, your staging site could be annoyingly slow.
While the list of cons is longer than the pros, the answer to the above question still isn’t “absolutely nothing.”
Staging sites can still be a great asset if one on your main goals is having an excellent user experience. This is so because your staging site mirrors your original site and it’s essentially the same.
If you run it in the same kind of hosting setup, then the overall user experience of the staging site should be strikingly similar to that of the original site if you decide to push the changes to your live (production) site.
It’s also a particularly great choice if you need to test a caching plugin or one that requires the use of an API to run since these kinds of plugins only work on live websites.
For example, if you want to use W3 Total Cache, WP Rocket, WP Super Cache, Jetpack, the premium version of EWWW image compression and other similar plugins, then a staging site is the way to go.
It could also be the best option if you need to share access to the staging site with your, employees, colleagues or web developers. While it’s possible to share a local environment in certain cases, it’s a lot more straightforward and effortless.
There are many ways to create a staging site. You can use a backup plugin to create a backup of your original WordPress website, then restore the archive on a fresh install that you would then use as your staging site.
For details, check out Protect WordPress from Annihilation with Redundant Backups.
If you have the Multisite network feature enabled, there are also plugins available that can copy your main site or sub-sites in the network to a freshly installed sub-site.
If you choose an option like this, then it’s a good idea to make sure the plugin can copy the staging site to the original website and overwrite it when you want to push the changes you made to your live site.
There are a few quality plugins available that can copy your original site if you’re using Multisite. Some of the best options you can check out Cloner, Duplicator, All-in-One WP Migration and WP Migrate DB Pro.
No matter which option you choose, you can restore from a backup or copy the original site to the staging site again if you need to start fresh or if you made changes that you don’t want to push to your production website at some point.
A local environment is similar to a staging site because it’s used for testing, but unlike a staging site, it’s set up and runs on your computer via a virtual server.
This means it’s not directly connected to the internet in the same way a staging site is since the server isn’t live. It mimics a live server, but a local environment can only be accessed by you and anyone else who uses your computer.
In order to set up a local environment, you also need an app for your computer.
Similar to a staging site, a local environment also mirrors your original, live WordPress website, except:
Essentially, the main and defining difference between a staging site and a local environment is that the latter is a local, offline solution for testing and the former is an online option.
While local environments are strikingly similar to staging sites, it may be important to note that there are different advantages and disadvantages of using a local environment.
What’s not different is the necessity of understanding the pros and cons of the local option to help you decide if it’s the right solution for your WordPress site.
One of the biggest advantages of a local testing environment is that it’s a lot more secure than a staging site since it can only be accessed through your computer. You don’t have to worry about someone misusing their access to let others wrongfully gain entry.
Like most situations, there’s an exception to the rule: your computer is still vulnerable to hackers so if your computer gets a virus, your local testing site is likely to also be compromised. However, since it’s not on a live server, you’re local environment only assumes half the risk of a staging site.
Another advantage is that it’s an offline solution. If your internet goes down, you can still freely work on your local environment. You may not even notice anything is different until you try to send a tweet or otherwise try and hop on the internet train.
Local environments typically run lightning fast because it doesn’t rely on a live server that could be slow. This means that unless your computer is an expensive paper weight, your local environment should load so fast, you can barely keep up.
On a similar note, this also means there aren’t any recurring expenses since a live server isn’t required, though, your local site still takes up storage space on your computer, but that’s free.
Unless you’re using software to create the local environment that requires regular payments, you don’t need to worry about ongoing expenses, especially because there are several free options. Most of the premium options only require a one-time payment as well, unless you opt for ongoing and optional technical support.
Since the local website can only be accessed from your computer, you typically can’t share access unless you set up an intranet system or you’re using an app that has this capability.
Because a local environment is, well, local and isn’t on a live server with your original WordPress website, it’s not going to load at the same rates. As mentioned earlier, a local environment is a lot faster to load than a staging or production website most of the time.
This means that if your goal is to test how fast your website loads after making changes, it’s not going to be able to be accurately tested in a local environment. On the other hand, most other measures of user experience can be effectively tested locally.
You also are required to download and install additional software on your computer in order to be able to set up and use a local website.
Possibly the biggest disadvantage of a local environment is that certain plugins or scripts aren’t going to work. More specifically, any caching or other plugins that require a connection to an API can’t work locally. This means you wouldn’t be able to use any of the plugins mentioned earlier including W3 Total Cache, WP Rocket, EWWW image compression, Jetpack and the like.
If you’re keeping score, there’s definitely a lot more advantages of using a local testing environment over a staging site.
In particular, if security is an important goal for testing on your site, then a local environment is right up your alley.
It’s also the best option if speed and efficiency are priorities for you.
Above all, a local environment is the best option for most situations, but it’s important to weigh the pros and cons and decide for yourself since every site and business’s needs are different.
As previously mentioned, you need to install an app on your computer in order to be able to set up a local testing environment.
There are both free and premium options available. You can check out free apps such as XAMPP and Bitnami. There’s also a free version of MAMP. You can also check out the DesktopServer premium app.
Once you install and run one of these programs, you can use a backup plugin to migrate your live website to your local environment. That would require installing and activating the plugin on both your live and local website, then backing up you live site and restoring it in your local testing environment.
If you need to start fresh, you can delete your local website and start the process over again. You can do this by creating a new installation of WordPress on the app, then restoring your site from a backup to your local site.
Now that you know how to test updates and changes to your WordPress website, when should you do the testing?
Don’t worry, I’m not holding out on you. Here’s the perfect workflow for testing updates and changes to your WordPress website:
Some people prefer to apply all the updates to a live site, then test everything. This is fine in some cases, but it’s not ideal since your live site could break, rendering it unavailable to your visitors, It can also be more difficult to fix the issue.
If you’re a web developer, for example, and you’re absolutely sure the available updates won’t break your site, you don’t care if your website breaks or it’s an unimportant site you use for minor testing, then you can test updates after applying them at your own risk and if you’re comfortable with it.
If you choose this method, then be sure to backup your website before applying any changes to be on the safe side. That way, you can quickly restore your site if something goes awry.
Overall, it’s best to use a staging site or a local environment.
The best workflow for testing updates and changes to your WordPress site is to use a local environment or a staging site since updates can sometimes be volatile.
Or, you can get it all taken care of for you with a reliable maintenance plan so you can worry a ton less and have a lot more time to focus on growing your website and business.
Do you use a staging site or local environment? What does your testing workflow look like and what are your favorite apps or plugins for it? Feel free to share your experience in the comments below.
Discover your innate talents and embrace them as the foundation to personal and business success. Walk away with personalized tips to help you overcome the mental hurdles unique to your brand builder personality.
Take the quiz
Leave one here
Comments