Each WordPress install at Kinsta can have its own free WordPress staging environment, completely separate from the live production site. This is great for testing new WordPress versions, plugins, code, and general development work. Create a dev site in minutes and share it with your team.
If you want to add additional staging environments, need a staging environment that more closely matches your live environment, or need to do resource-intensive site testing or development, check out our Premium Staging Environment add-on.
Create WordPress Staging Environment
We’ve made creating a WordPress staging site as easy as possible. In MyKinsta, click on WordPress 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 Create new environment from the dropdown menu.
In the Create new environment modal/pop-up that appears, give your environment a name, select Standard environment, and click the Create environment button.
The environment name must be between 3 and 12 characters long.
Next, you’ll be prompted to select the type of environment you want to create. There are three options.
- Clone an Existing Environment: This option allows you to clone an existing environment (live or any Premium Staging Environment) to the new Standard Staging Environment.
- Install new WordPress: This option installs a fully functional blank WordPress site, ready for you to use immediately.
- Don’t install WordPress (empty environment): This option installs all the necessary software to run a WordPress site (web server, PHP, MySQL, etc.) but does not install WordPress itself. This is a good option for users migrating to Kinsta with Duplicator or setting up a Bedrock/Trellis installation with a custom file structure.
Option 1 – Clone an Existing Environment
The Clone an existing environment option allows you to clone any existing environment (live or Premium Staging Environment) to the new Standard Staging Environment.
If you want to change the environment name, you can do so here. The environment name must be between 3 and 12 characters long.
Environment to Clone
Choose an existing environment to clone to the new Standard Staging Environment.
Option 2 – Install New WordPress
The Install new WordPress option includes several fields to customize your site. Here’s what you need to know about each field.
If you want to change the environment name, you can do so here. The environment name must be between 3 and 12 characters.
WordPress Site Title
This allows you to set the site title for your WordPress site. Depending on your theme, it will be visible to site visitors in the browser tab and other places. You can change the site title in WordPress settings after site creation.
WordPress Admin Username
You will use this to log in to your WordPress installation. You will be able to add additional users later on. We recommend choosing something other than “admin” for the username for maximum security.
WordPress Admin Password
You will use this password to log in to your installation. We automatically enforce strong passwords to protect users. You can use the generate new password option (reload icon) if you want a new one. Here’s how you can change your WordPress password later on.
WordPress Admin Email
WordPress uses the admin email address to send important notifications.
Select a Language
Select the language you would like to use in WordPress. You don’t have to write content in the same language as your WordPress interface, so feel free to choose your native tongue, even if you are writing content in English.
Install WordPress Multisite
Select this box if you would like to create a WordPress Multisite installation. Once selected, you may choose between a Subdomain or Subdirectory install.
If you are creating an ecommerce website, WooCommerce is the most popular ecommerce plugin out there. Check this box to install it automatically.
Install Yoast SEO
Yoast SEO is the most popular SEO plugin for WordPress, with over 3 million installs and a 5 out of 5-star rating. Check this box to install it automatically.
Install Easy Digital Downloads
If you are creating a site to sell digital products, Easy Digital Downloads is a complete eCommerce solution for selling digital products. Check this box to install it automatically.
Option 3 – Don’t Install WordPress (Empty Environment)
If you want to change the environment name, you can do so here. The environment name must be between 3 and 12 characters long.
Creating the Standard Staging Environment
When you’re ready, click the Create environment button.
Accessing Your Staging Environment
Creating the new environment may take a few minutes. When it’s ready, you can select the new Standard Staging Environment in the Environment selector dropdown next to the site name.
Each environment has a color-coded circle by its name: green for Live, black for Standard Staging, and orange for Premium Staging. You will then have a separate control panel with 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 Standard Staging Environment follows this format:
If you have an older staging site, your URL may look like one of these:
You can also add a custom domain to your staging site if you prefer to use a custom domain.
If you have SSL enabled on your live site and clone the site to staging, 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:
Delete and Refresh Staging Environment
If you need to remove your staging site, go to WordPress Sites > sitename and switch to the staging environment. Scroll to the bottom of the page and click the Delete 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-environmentname) in the field provided, then click the Delete environment button.
To refresh your staging environment, delete it, create a new one, and choose Option 1 – Clone an Existing Environment. This newly cloned 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. The benefit of this method is that if you’ve added a custom domain, it won’t be deleted, and you won’t need to add it each time you refresh staging.
Push Staging to Live
To overwrite your live site’s database or 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 directly to your existing staging environment. Check out how to restore a WordPress backup to staging. Note: All staging backups will remain intact when restoring a live backup to staging.
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 you 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.
If you cannot 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 several 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.
2. Staging Environment Credentials
If the staging environment is a clone of your production site, your WordPress admin login credentials will be the same for both your live and staging sites unless you change them after creating your staging environment.
By default, indexing is turned off for Staging sites, so they don’t harm the SEO on your live/production site. This is done with the combination of a WordPress setting and an HTTP header that we automatically add.
You can see the WordPress setting 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.
Kinsta temporary URLs and staging URLs also have a robot-restricting
X-Robots-Tag: noindex, nofollow, nosnippet, noarchive HTTP header, meaning the temporary URLs won’t be indexed by the search engines. These headers cannot be removed from Kinsta temporary URLs or staging URLs. If you need these headers removed from the staging site, you’ll need to add a custom domain to it.
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://stg-sitename-environmentname.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 licensed by domain name may require a custom domain (instead of a Kinsta staging subdomain) to work properly. Note: once you’ve added a custom domain name to your staging site, you may 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 clone your site to staging and use 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://stg-sitename-environmentname.kinsta.cloud/yourcustomlogin
6. Staging Should Be Used For Development/Testing Only
The Standard Staging Environment only has 2 PHP workers, has no option to enable Kinsta’s CDN, and may go to sleep after 24 hours of inactivity. Accordingly, it should be used for development and testing only. Staging environments (Standard and Premium) aren’t designed to be used for live production sites, and there may 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 (even if you clone your live site to staging), 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.
If you’re running a WordPress multisite network, it may or may not work with our staging environment, depending on how your multisite is set up.
- 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 subdomain multisite that requires HTTPS, you’ll need to add a custom domain with a wildcard SSL certificate to your staging site so the subdomains can be covered by an SSL certificate. This is because the SSL certificate provided for the default staging URL can only cover the staging subdomain (e.g. stg-sitename-environmentname.kinsta.cloud), so any additional subdomain level (e.g. subsite.stg-sitename-environmentname.kinsta.cloud) cannot be covered.
- 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 manually run a search and replace in the database.
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.