How to create a WordPress staging environment

This guide will show you how to create a staging or development environment best used for testing, troubleshooting, and light development. These steps are specific to WordPress, however much of the same process can be followed for other web apps as well.

We also include tips on how best to make your staging site’s changes live. We’ll refer to it as a staging site in this article, however you could call it dev, development or testing.

These steps use our specialized software configuration which makes use of Plesk control panel and Installatron (1-click web apps) for easy web application management. If you are not hosted with us, but your web host uses these tools as well, then this guide will work great for you too.

Not hosting with us?

Want to make creating a staging environment this easy for you too? Switch your hosting to Websavers!

Part 1: Create subdomain

We’ll start by creating a staging subdomain. If your DNS is not hosted with us (ie: managed within Plesk alongside your website) then you will need to create the subdomain DNS A record wherever your DNS is hosted.

  1. Login to Plesk and choose the “Add Subdomain” button
  2. You can enter whatever you like for the name. Some suggestions: dev, new, testing or most commonly staging.
  3. Be sure to select the correct parent domain — this is the the domain you’re making a staging environment for.
  4. If you wish to customize the document root folder name, go for it! Plesk will default to ‘staging.<domain>’ which makes it easy to recognize amongst other domain document roots folders.
  5. Press the OK button to save your changes.

Part 2: Copy the site content to the staging subdomain


  • If you’re building a new site from scratch that will not be sharing any content (like blog posts) from a currently live site and you’ll be using WordPress or another web app to power the site, follow this guide to install the app of your choice, and select the staging subdomain as the install target.
  • If your website is not powered by a web app found in 1-click web apps, see our website cloning guide here. In particular scroll to the section titled “Steps to clone a website not in 1-click web apps.”

In all other cases, follow these steps:

  1. Login to Plesk and choose the 1-click web apps (or Installatron) button to be taken to your list of installed applications.
  2. Find your website app in the list. If you do not see it there, learn how to import it into 1-click web apps here.
  3. Clone your app using the button with the two side-by-side arrows pointing down. More details on this process here. Your destination for the clone will be the new subdomain you created in Part 1.
  4. If you see the option to inform 1-click web apps that the clone will be a staging site, go ahead and check that box — this will allow you to use the sync tool to easily sync changes from staging to live (described below).
  5. You should now lock down the staging site so as to prevent indexing by search engines. Here’s how to prevent indexing with WordPress.

And that’s all there is to it! You’ve now got yourself a staging environment located at the subdomain URL you specified in part 1. Do not prepend it with www (that is not used with subdomains). Your login credentials for your app will be identical to the ones you used on the live site.

Tip to avoid data merging conflicts: if your goal is to complete a bunch of changes on staging and sync them to live, then to make your life easier at go-live time, it’s best to avoid making changes to the live site content whenever possible. If your site admins/publishers must edit existing page content, have them make the same changes on the staging copy of the site as well, or only on staging with the idea that their new content will be published along with the roll out of the new site.

Part 3: How to make your staging changes live

Option A: Selective copy (useful for highly dynamic sites)

If you have a WooCommerce store, or membership site with new data being created daily, it may be tricky to identify the individual content pieces you need to copy from live to staging before then making the staging site live. In such cases a manual copy of changes made to the staging site over to live may be helpful, rather than using the sync tool described below. Here’s a couple helpful tips on this:

Option B: Fully automatic sync

Our sync tool is pretty handy, but despite its name, it’s better at copying than syncing in that it really only overwrites the files and database tables on the destination from the source.

The sync tool does allow us to choose specific tables in the database and specific files not to sync which can be super handy with most databases/apps, but WordPress’s database methodology makes this a bit difficult to utilize. Specifically, WordPress stores all kinds of data in the posts table, including blog posts, pages, menus, and WooCommerce orders.

If new posts of any kind (posts, pages, orders, menu items) have been added to the live site since the staging site was created, that content will be erased and overwritten by the content from the staging site. And so to avoid that new data from being overwritten, you will need to export the new content from the live site and then import it into the staging site. Here’s how:

You will need to do this with all content types where entries have been created anew on the live site since the staging site was created.

An alternative to the built-in WordPress export/import tools is the WP All Export and Import utilities (you will probably need the paid versions). They will help you export and import only new posts/pages/customers/orders/users from live to staging.

Once the staging site is exactly how you’d like it to look, content included, follow these steps to begin the sync to live:

  • Login to Plesk
  • Choose the 1-click web apps (or Installatron) button to be taken to your list of installed applications.
  • Find your live site in the list and click first on the wrench icon, and then on the sync icon with the two arrows in a circle
1-click web apps sync button

On this next screen you’ll see a list of files and a list of database tables. You can deselect those files and tables that you do not want to overwrite on the live site. This can be crucial for sites with a lot of comments, or other live data that should not be overwritten. CHOOSE CAREFULLY which tables you select/deselect here.

If, since the date you created the staging site, you or your site’s users have not altered or added any content to the live site (posts, pages, comments, WooCommerce orders, etc), simply leave everything checked and proceed with the sync to make your staging site live.

If you have only edited files (like the theme or a custom plugin) on the staging site, and nothing in the database, then you can safely uncheck all database tables (the second list on this page) to complete a file-only sync, making your staging changes live.

Excluding Comments or Users

To skip syncing WordPress comments, uncheck the wp_comments and wp_commentmeta tables (as highlighted in the screenshot)

To skip syncing WordPress Users (including WooCommerce Customers), unchecking the wp_users and wp_usermeta tables (not shown in screenshot).

Then at the bottom of the screen you should leave the option to make a backup before syncing enabled, and finally click the Sync button.

And you’re done! If there’s any issue with the live site after the sync, you can always head to the Backups tab and restore the backup that was completed just prior to the sync.

Option C (Old Method): Remove live & clone staging to live

  1. Click the curved arrow button to complete a backup then choose the X button to remove the live app.
  2. Find your staging application install in the list of web apps
  3. Clone your staging app using the button with the two side-by-side arrows pointing down. More details on this process here. Your destination for the clone will be the live domain as we are copying the site from staging to the live URL.
  4. If you get an error like “! An instance of wordpress already exists in this directory”: this means you didn’t remove the app (ie: you need to complete step 1).

SEO TIP: If permalinks/page URLs have changed on the staging site then when it goes live, you will want to ensure you either rename all the new page URLs to the original value OR create 301 redirects for each one that has changed. This is necessary at bare minimum for SEO purposes. Details on creating 301 redirects here.

Not hosting with us?

Want to make creating a development environment this easy for you too? Switch your hosting to Websavers!

About Jordan Schelew

Jordan has been working with computers, security, and network systems since the 90s and is a managing partner at Websavers Inc. As a founder of the company, he's been in the web tech space for over 15 years.

1 Comment

  1. Phil Cheney on October 19, 2018 at 9:31 am

    Very good article!
    It is good to see best practice (development seperate to prod) encouraged by a hosting company!

Leave a Comment