What is a staging environment?

It’s an exact copy of your production site but in an “offline” mode. And by “offline” I mean that it will not be accessible for users or search engines. Its purpose is to provide you with a playground in order to make adjustments/changes to the existing site without possibly breaking the live version in the process.

Why do you need a WordPress Staging environment?

The purpose of a staging environment is to make certain changes that you want to test before having them on the live version.

When it comes to small changes, adjusting the color in a CSS file or changing the submit button value, you can do it without creating a staging environment. You shouldn’t go through that process just for a small change, unless you have a very active site and you don’t want to take any kind of risk.

When should you create a staging environment?

• You are about to make major changes to the site and everything needs to be tested; A new theme is developed, a new custom plugin created, new 3rd party implementation and so on.
• You want to fix a bug and it needs a lot of testing and errors might appear on the front-end or certain workflows might get broken;
• There is an ongoing process of changes on the site and you always need a staging that will test new changes before having them sent to production. This might happen if you have long term projects/clients and it’s a great idea to have a pipeline in place staging to production.

How to create a WordPress staging environment?

There are 3 ways of creating a staging environment:

• using tools from your hosting provider
• using a plugin
• manually create a staging environment

No matter the option you choose, I recommend using a subdomain that is located in a different folder compared to the actual production site. If the staging version bursts on fire, you don’t want it touching the production site. This being said you can also have it on a different server, but you’ll want to have the same server configuration.

1. Using tools from your hosting provider

Hosting providers now offer tools to create staging environments on WordPress. WPEngine and Siteground have this staging feature available. I only worked with those, but I’m sure there are many others that do the same thing.

They let you create a staging on a subdomain and then push from that staging back to production when you’re done with the changes.

2. Using a plugin

My go-to plugin when it comes to migration is All in One Migration. It’s an amazing tool and it works perfectly. It’s good to know that this plugin doesn’t have an option to push from the staging to live once you’re done with the changes. You will have to create a copy and move it again through its interface.

On the downside, it’s not as fluid as you might like it.

Another plugin that does this and is created with the staging environment approach in mind is WP Staging. This will allow you to create a staging in a subfolder on your main site in a few moments and on the premium version you also have the option to push changes to the live version.

3. Manually creating a staging environment

This is the most complex way of creating a staging environment. You will have to do everything from creating the subdomain, moving the files, moving the DB, changing the address/path in the DB, etc. It’s not that pretty, but it’s also the one in which you have the most control.

Do the push to live manually

I recommend option #1 or #2, but without the push to live from the hosting provider tools or from the plugin. From my experience, those options are good if you have a stating environment, if you have an e-commerce, membership site or an active blog community, you don’t want to push from staging to live using those tools.

The fact that you can risk overwriting or losing transactions, articles, registration that happened between the 2 moments in time, is something that I wouldn’t take a chance on.

Use the tools from hosting providers and plugins to create a staging environment.

Do the file updates on production directly with a theme/plugin update, have a deploy bot maybe once you do a pull request into the master Github branch or via SFTP.

The WordPress option/settings that you’ve done on staging, you’ll pretty much have to replicate those by hand.

I know that easy staging set-up with push to live sounds good, but it doesn’t always work. Or at least it doesn’t work for every project.

To have in mind

• Remove any cache system on staging. If you have to do a lot of changes or work on a completely new component, the cache will become frustrating. You can activate it once you’ve finished and tested with it.
• Make sure crawlers can’t get to the staging version. Update the robots.txt and block all kinds of foreign access to the staging subdomain.
• Try to use a similar server configuration to what you have on production. Don’t have the staging environment on your own machine (localhost), because you want to test it against the real-world situations.
• Make sure you share the staging link with the client or tester. (you won’t be able to do this if you host it locally)