How Do I Use the One-Click WordPress Staging Environment?

Each WordPress install at Kinsta can have its own staging environment which is completely separate from your live production site. This is great for testing new WordPress versions, plugins, code, and general development work. Create a dev site in a matter of minutes and share it with your team.

• Create WordPress staging environment
• Delete and refresh staging environment
• Push staging to live
• Restore WordPress backup to staging
• Restart staging environment

Create WordPress Staging Environment

Creating a staging site is incredibly simple. Just click on “Sites” in the left navigation. You’ll see a list of your sites/installs. Click on the one you’d like to add a staging area to. Click on “Staging” from the drop down menu at the top right, then click on the “Create a Staging Environment” button.

Staging environment

The URL structure for every staging area appears as follows: https://staging-sitename.kinsta.com. If you have SSL enabled on your live site, SSL will also be enabled on your staging site.

Please wait 10-15 minutes until the staging is created and DNS propagates. You will then have a separate control panel with your connection information, DNS, backups, tools, and plugins for your staging environment. You can launch phpMyAdmin from right within the dashboard. The URL structure for phpMyAdmin staging will appear as follows: https://mysqleditor-staging-sitename.kinsta.com.

WordPress staging site

Delete and Refresh Staging Environment

You can then easily remove your staging site by clicking “Delete Staging Environment” from the dashboard. When deleting a staging site all of its data will be completely removed, including the databases and files. To delete this environment type the site name, followed by a dash and the word “staging” (SITENAME-staging) in the field below and then click the “Delete This Environment” button.

To refresh your staging environment, simply delete it and create a new one. This will then contain the most recent version of your production database and files for testing. Or you can restore a backup from your production site to staging.

Delete WordPress staging site

Push Staging to Live

If you would like to push your staging site to live you can utilize the push staging to live feature.

Restore a WordPress Backup to Staging

You can also easily restore your WordPress site from a backup and push it directly to your staging environment. Check out how to restore a WordPress backup to staging.

Restart Staging Environment

If for some reason your staging environment is stopped you might see the following error: 501 not implemented.

501 not implemented error

Under your site’s Info tab you will see the option to “Start staging environment.”

Start staging environment

Important Notes Regarding Staging

When you use the staging environment there are a couple important things to be aware of.

1. Caching is Disabled on Staging Sites

Due to the fact that staging environments are for development purposes, debugging, and testing, caching is disabled. If you try to run website speed tests you will see higher than average load times due to the fact that the pages aren’t being served from cache.

2. SEO

Staging sites by default will have indexing turned off so that they don’t harm the SEO on your live production site. Under “Reading” in the settings of your staging’s WordPress dashboard the search engine visibility is checked. This settings adds the following HTTP header onto your WordPress site. x-robots-tag:noindex, nofollow, nosnippet, noarchive

Indexing disabled on staging site

Kinsta temporary URLs also have a robot-restricting robots.txt, meaning the staging-sitename.kinsta.com URL’s won’t be indexed by the search engines.

3. Social Scheduling Plugins

If you use social scheduling plugins such as CoSchedule or Social Networks Auto Poster, it is recommended that you deactivate these plugins on your staging site. Otherwise, they might start sharing to social networks using your staging URL: http://staging-sitename.kinsta.com/. This could then skew your analytics.

4. Make Note of Your Login URL

If you’re using a WordPress plugin that changes your default login URL, this will get copied over to the staging site. Example: http://staging-sitename.kinsta.com/yourcustomlogin

5. Staging Should Be Used For Development/Testing Only

The staging environment should be used for development and testing only. They are not designed to be used as live production sites and there will be things that don’t function correctly. Kinsta is not responsible if you try to use staging for a live site.

6. Disk Space Excluded From Plan Total

To give you as much space as possible, staging sites are excluded from our reporting when calculating your total disk space usage. Only live sites count against your disk space usage.

7. Multisite

Depending on how your multisite is setup, it may or may not work with our staging environment.

• If it’s a subdirectory multisite (example.com, example.com/subsite1, example.com/subsite2) it will work fine with our staging environment.
• If it’s a subdomain multisite (example.com, subsite1.example.com, subsite2.example.com) it will work fine provided the subsites don’t require HTTPS. If the subsites do require HTTPS, you will have to bypass SSL errors on staging to access the subsites. This doesn’t impact functionality in any way.
• If it’s a domain-mapped multisite (loads different subsites at completely different domains, i.e, example.com, example1.com , example2.com) it won’t work without significant manual setup.
  • Option 1: Turn off domain mapping and go back to the standard subdirectory/subdomain setup. Do a search and replace in the database manually.
  • Option 2: Set up staging subdomains for each live domain, add all those to the staging site, and run a search and replace in the database manually.