Each WordPress install at Kinsta can have its own WordPress 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.

Prefer to watch the video version?

Create WordPress Staging Environment

We’ve made creating a WordPress staging site as easy as possible. In MyKinsta, click on Sites in the left navigation. You’ll see a list of your sites/installs. Select the site you want to create a staging environment for, click on the Environment selector next to the site name, and select Staging from the drop-down menu.

Change to your WordPress staging environment in MyKinsta.
Change to your WordPress staging environment in MyKinsta.

On the next screen, click on the Create a Staging Environment button to start the process.

Create a Kinsta staging environment.
Create a Kinsta staging environment.

Accessing Your Staging Environment

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.

To quickly visit your staging site, go to the Domains tab in your staging environment and click on the Open URL link. You can also quickly get to your staging site’s WordPress admin by clicking on the Open WordPress admin link.

URL Structure and Domain

The default URL structure of your staging environment follows this format:


If you have an older staging site, your URL may look like this instead:


You can also add a custom domain to your staging site if you prefer to use a custom domain instead.

Additional Notes

If you have SSL enabled on your live site, SSL will also be enabled on your staging site.

You can launch phpMyAdmin from right within MyKinsta. On the Info tab, click on the Open phpMyAdmin link. The URL structure for phpMyAdmin staging follows this format:


Kinsta staging environment in MyKinsta.
Kinsta staging environment in MyKinsta.

Delete and Refresh Staging Environment

If you need to remove your staging site, go to Sites > Your Site and switch to the Staging environment. Scroll to the bottom of the page and click the Delete Staging environment button.

In the modal/pop-up that appears, confirm you understand what will be deleted, type the site name followed by a dash and the word “staging” (SITENAME-staging) in the field provided, then click the Delete environment button.

Delete a staging environment in MyKinsta.
Delete a staging environment in MyKinsta.

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

Push Staging to Live

To overwrite your live site’s database, files or overwrite the entire site with your staging site, you can utilize the push staging to live feature.

Restore a WordPress Backup to Staging

You can also 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. Note: When restoring a live backup to staging, all staging backups will remain intact.

Restart Staging Environment

In certain situations, we may stop a staging environment as part of a server troubleshooting process. If you notice your staging environment has been stopped and see a 501 not implemented, a 502 error, or a 521 error when visiting your site, you can restart the staging environment in MyKinsta by going to your site’s Info page and clicking Start Staging Environment.

Restart your staging environment in MyKinsta.
Restart your staging environment in MyKinsta.

If you are unable to restart your staging environment or don’t see the button in MyKinsta, please open a new chat with our Support team for further assistance.

Important Notes Regarding Staging

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

1. Page Cache Settings for Staging Sites

Because staging environments are for development purposes, debugging, and testing, Kinsta’s full-page caching and OPcache are disabled by default. If you run website speed tests, you will see higher than average load times since the pages aren’t being served from cache. If you want to enable caching on a staging site, click on the Enable Cache button on the Tools page of your site’s staging environment. When caching is enabled on a staging site, the Clear Cache button will be enabled and can be used to clear the cache.

Enable caching for a staging environment.
Enable caching for a staging environment.

2. Staging Environment Credentials

Because the staging environment is a copy of your production site, your WordPress admin login credentials will be the same for both your live site and staging site, unless you change them after creating your staging environment.

3. SEO

Staging sites, by default, will have indexing turned off so that they don’t harm the SEO on your live production site. You can check this by going to Settings > Reading in your staging site’s WordPress dashboard. The option to discourage search engines from indexing the site is checked beside Search Engine Visibility. This setting adds the following HTTP header onto your WordPress site. x-robots-tag:noindex, nofollow, nosnippet, noarchive

Search engine indexing disabled on staging site.
Search engine indexing disabled on staging site.

Kinsta temporary URLs (including staging URLs) also have a robot-restricting X-Robots-Tag: noindex, nofollow, nosnippet, noarchive HTTP header, meaning the staging-sitename.kinsta.com URLs won’t be indexed by the search engines.

4. 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, which will look something like: https://staging-sitename.kinsta.cloud. This could then skew your analytics.

Some plugins like the Jetpack plugin will automatically run in staging mode on Kinsta staging environments. You will see a message: “You are running Jetpack on a staging server.” While in staging mode, your staging site will act like your production site in virtually all ways, except no data is passed up to WordPress.com, and you cannot disconnect the staging site (to prevent an issue that would lead to problems with your production site).

Plugins that are licensed by domain name may require a custom domain (instead of a Kinsta staging subdomain) in order to work properly. Note: once you’ve added a custom domain name to your staging site, you may also need to update settings where you manage your plugin license or contact your plugin’s support team.

5. Make Note of Your Login URL

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

6. Staging Should Be Used For Development/Testing Only

The staging environment only has 2 PHP workers, has no option to enable Kinsta CDN, and may go to sleep after 24 hours of inactivity. Accordingly, it should be used for development and testing only. Staging isn’t designed to be used for live production sites, and there will be things that don’t function correctly. Kinsta is not responsible if you try to use a staging environment for a live site.

7. 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.

8. Cron Jobs

Server cron jobs from the live environment are not active in the staging environment, so the live site’s cron jobs won’t fire on the staging environment. Additionally, if you modify the crontab in your staging environment and push staging to your live environment, it will overwrite your live environment’s crontab.

9. Multisite

If you’re running a WordPress multisite network, depending on how your multisite is set up, 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 it’s a domain-mapped multisite (loads different subsites at completely different domains, e.g. 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.

10. Email

Staging environments have mail-sending (transactional email) enabled by default. If you make an order on the staging site, you will receive related emails from the staging site. If you do not wish to have transactional emails sent from your staging environment, you can use a plugin like Disable Emails to stop the site from sending emails.