WordPress Staging Site: Test Updates Safely

This guide is for bloggers, agency owners and small business owners who run WordPress and want to update plugins, themes or core without testing on the live site. A staging site is a private copy of your website where you can break things safely. Below you will find the three common ways to get one, how to keep it out of Google, how to move changes to the live site without losing data, and a checklist to run before every update.

Contents

Why use staging before updating?
Three ways to get a staging site
Keep staging out of Google
Pushing changes live safely
Pre-update checklist
Key takeaways
FAQ
Sources

Why use staging before updating?

The official WordPress guide to updating says to check that your plugins and themes are compatible with the version you are installing, and it notes there is no single update order that works for every site: some plugins need updating before WordPress, others need a newer WordPress first. It also advises visiting your site afterwards to make sure everything works. Doing that on a copy means a broken checkout page or layout is a lesson, not an outage.

Staging does not replace backups. WordPress.org’s backup documentation says to back up the database “always before an upgrade”, and says a full restore needs both the database and the files. If you have not set up automatic copies yet, see our guide to automatic off-site WordPress backups.

Three ways to get a staging site

Route	Best for	Main trade-off
Host’s one-click staging	Most small sites on a host that offers it	Availability depends on your plan and host
A staging plugin	Hosts with no staging tool	Uses your hosting resources; push features vary by plugin
A local copy on your computer	Developers and heavy testing	Needs local server software and a manual move to live

1. Your host’s one-click staging

This is usually the easiest route. Hostinger’s help page describes it like this: in hPanel, open your WordPress site, click Staging, then Create staging, name it and click Create. It clones your files and database, which can take up to 15 minutes, and the page notes that staging is limited by plan and is not supported on WordPress multisite.

Enjoying this? Get our best tips by email

Practical SEO, link building and content strategies, straight to your inbox.

Bluehost documents a similar flow: Websites, then Manage Site, then Staging, then Create staging site in the Bluehost plugin. Its page says the staging site is not publicly accessible, but it does not explain how search engines are handled, and suggests asking support if that matters. Menu names differ between hosts, so check your own host’s staging article before you start. If you are still choosing a host, our hosting plan guide covers what to compare.

2. A staging plugin

If your host has no staging feature, a staging or cloning plugin from the WordPress.org plugin directory can copy the site into a subfolder or subdomain. Check the plugin’s documentation to see what it copies, whether it can push changes back, and whether it blocks search engines by default. Only install plugins that are actively maintained and compatible with your WordPress version.

3. A local copy

You can also run WordPress on your own computer. The idea follows the backup documentation: export the database, copy the files, import both locally, and update the site URL settings to match your local address. Test the updates there. A local copy is not reachable by visitors or search engines, but moving changes to the live site is manual and error-prone.

Keep staging out of Google

A staging site that gets indexed can create duplicate content and confuse visitors. There are three layers to think about.

The “Discourage search engines” setting

In the dashboard, go to Settings > Reading and tick Discourage search engines from indexing this site. WordPress.org documents that since version 5.3 this adds a robots meta tag with “noindex,nofollow” to your page head. The same page states that it does not block access to your site and that it is up to search engines to honor the request. Treat it as a polite request, not a lock.

noindex versus robots.txt

These are different tools, and mixing them up is a common mistake. Google Search Central explains that a noindex rule, set with a meta tag or an X-Robots-Tag HTTP header, removes a page from Google Search results. robots.txt only controls whether crawlers may fetch a URL, and Google does not support a noindex rule inside robots.txt. Worse, if robots.txt blocks a page, Googlebot never sees the noindex rule on it, so the page can still appear in results if other pages link to it. So a blanket “Disallow: /” on staging is not a reliable way to keep it out of search. Let the crawler reach the page and see noindex, or keep the crawler out altogether with a login.

Password protection

The strongest option is to put a login or password in front of the whole staging site, using your host’s staging protection if it has one. Google’s page on blocking indexing does not discuss password protection, so this recommendation rests on how access control works in general: a crawler cannot read pages it cannot log in to. Use the password as the main barrier and noindex as a backup. Also confirm what your host does by default, since the two host pages above do not describe indexing behavior for staging.

Pushing changes live safely

Hosts typically offer a choice of what to push. Hostinger’s options are files only (themes, plugins and uploads), database only (posts, settings and users), or a full sync. Bluehost offers deploy all changes, files only (the wp-content folder) or database only. Both say pushing overwrites the live site, and Hostinger tells you to back up production first so you can roll back.

The key distinction is this: plugin, theme and core updates are mostly files, while orders, comments, form entries and new user accounts live in the database. A host knowledge-base article from Softsys Hosting warns against replacing the live database with staging’s, because you would lose orders or comments that arrived while you were testing. It recommends pushing code and files, and making any database-stored setting changes by hand on the live site. Bluehost labels deploy all changes as the highest-risk option and notes that edits made on the live site do not sync back to staging.

Practical consequences:

For a store or membership site, prefer a files-only push, or simply repeat the tested updates on the live site.
If you must push a database, it can carry staging’s settings with it, including the search visibility box. Check Settings > Reading on the live site afterwards, because leaving it ticked can hide a live site from search.
Plugin updates sometimes change database tables. WordPress core can also need a database upgrade, so a files-only push may not reproduce what the update did. If the update asks for one, run it on live.

The same discipline helps when testing a pre-release; our post on testing a WordPress beta on staging shows a typical use case.

Pre-update checklist

Take a fresh backup of the live database and files, stored off the server, and confirm you know how to restore it.
Refresh staging from live so the copy is current. Bluehost, for example, uses Clone to Staging for this.
Confirm staging is password protected and that Discourage search engines is ticked.
Review available updates under Dashboard > Updates and read plugin and theme update notes for compatibility.
Apply updates on staging, one group at a time, so you can tell which one caused a problem.
Test key paths: home page, a post, search, contact form, login and, for shops, a test checkout. Turn on email sending only if you are sure staging will not email real customers.
Decide files only, or repeat the updates on live, based on how much live data changes.
Clear caches after going live, as the WordPress update guide suggests, and recheck the site.

Key takeaways

Test updates on a staging copy, but still back up live first.
Use host staging if available, a staging plugin if not, or a local copy for development-style work.
Use a password as the main barrier; noindex is a request, and robots.txt blocking can stop Google from seeing noindex.
Push files rather than the database on sites where orders or comments change.
After going live, recheck Settings > Reading and clear caches.

FAQ

Do I need staging for every small update?

Not necessarily. Many owners reserve staging for major WordPress releases, big plugin changes and theme updates, and for sites where downtime costs money. WordPress.org notes that minor and security core updates can apply automatically in the background on most sites.

Will the Discourage search engines box fully hide staging?

No. WordPress.org says it does not block access and that search engines choose whether to honor it. Add password protection for real privacy.

Why not just block staging in robots.txt?

Google explains that if robots.txt blocks a page, the crawler never sees a noindex rule on it, and the URL can still appear in results when other pages link to it.

What happens to new orders and comments while I test?

They land on the live database only. Pushing staging’s database over live can wipe them, which is why a host article advises pushing files and handling database settings manually.