Everyone tells you to test updates on a staging site. Almost nobody tells you how to get one, and the guides that do usually assume you already have a hosting feature you may not have, or route you straight to a plugin. This is the practical version, narrowed to one job: applying a WordPress update to a copy of your site, looking at the result, and then deciding.
That narrowing matters. A copy built to test one update needs to survive an afternoon. It does not need to be a long-lived staging environment, which means the genuinely hard problems of staging, keeping two copies in sync and pushing changes back to production, do not apply here and are not covered below. You are going to make a copy, break it if it breaks, learn from it, and throw it away.
One thing this is not: a copy is not a backup and does not replace one. You still need a backup you have confirmed you can restore before you update the live site, because the copy tells you what will probably happen and the backup is what saves you if it does not.
Version and verification. Written against WordPress 7.0.2, released 2026-07-17, current stable. WordPress 7.1 is scheduled for 2026-08-19. Last verified 2026-07-30 against wordpress.org.
First, check whether your host already gives you this
Two minutes, and for a lot of readers it ends the article.
Log in to your hosting control panel and look for a section called Staging, Test Site, Development Site, or Clone. Many hosting plans include one-click staging and the feature goes unused because nobody mentions it at signup. If yours has it, use it: a host-created copy runs on the same server, the same PHP version and the same stack as your live site, which makes it the most accurate copy you can get.
If you cannot find it, check your host's documentation for the word "staging" before concluding you do not have it. It is sometimes buried inside a WordPress-specific panel rather than the main control panel.
What a copy for testing an update actually has to be
Not identical. Close enough in the places that matter.
It must match on: the WordPress version you are starting from, the same plugins at the same versions, the same active theme, and as closely as possible the PHP version. PHP is the one people get wrong, and it is the one most likely to produce a false result.
It does not need to match on: having current content, having the same domain, having working email, or having your CDN and caching layer in front of it. In fact you want most of those switched off, for reasons in a moment.
How you know whether it matches: open Tools > Site Health > Info on both the copy and the original and compare four things. The WordPress section gives you the version and the environment type. The Server section gives you the PHP version and the server software. The Database section gives you the database version. Active Theme and Active Plugins give you the rest. If PHP and the plugin versions line up, the copy is good enough for this job.
Route one: your host's staging feature
If you have it, this is the route.
- Create the staging copy from the control panel. Most implementations copy files and database together and give you a temporary URL.
- Confirm the copy loads and that you can log in to its admin.
- Compare Site Health > Info between copy and original, as above.
- Change the two settings in the section below.
- Run the update on the copy.
The advantage is accuracy: same server, same PHP, same everything, so a result on the copy is close to a prediction about the original. The limitation is that host staging tools vary enormously in what they copy and how they handle a database that is being written to while the copy is made, which is a reason to make the copy at a quiet hour.
Route two: a local copy on your own computer
If you have no host staging, this is the most reliable free route, and it has become much easier than its reputation suggests. Several free local development applications will set up a complete WordPress install on your own machine in a few minutes and let you import a copy of an existing site into it.
The workflow is the same regardless of which one you use:
- Install the local development tool.
- Create a site in it, or import an export of your live site.
- Set the local PHP version to match your live site's, which you read from Site Health > Info. Most of these tools let you choose. This is the single step that decides whether your test result means anything.
- Match your plugin and theme versions.
- Run the update.
The honest limitation, stated here rather than in a footnote: a copy on your laptop is not your server. PHP version, web server software, memory limits, processor speed and filesystem behavior can all differ, and any of them can produce a difference in behavior. A local copy reliably catches plugin conflicts, editor breakage, layout failures and admin problems, which is most of what goes wrong. It is less reliable for anything involving memory limits, timeouts or server configuration.
That is a real caveat and it does not undermine the exercise. Catching most failures for free, before they are public, is a good trade.
Route three: cloning with a plugin, and how to judge one
There is a whole category of plugins that clone a WordPress site into a staging copy in a subdirectory or subdomain, and several of them are widely used and actively maintained. This site does not name one, for a specific reason: a staging plugin is itself a plugin, it is going to have write access to your files and database, and recommending one whose current maintenance state has not been verified would be exactly the mistake this site's other articles tell you to avoid.
So instead, here is how to judge one yourself, which is more useful than a name:
- Last-updated date within the last few months. Non-negotiable for a plugin with this much access.
- A changelog that names the current WordPress version. Cloning plugins interact with the filesystem and the database more deeply than almost anything else you will install, so a stale one is a genuine risk rather than a theoretical one.
- Recent support threads that are answered. Not just present, answered.
- A stated position on what it does with the copy's database prefix and URLs, because that is where cloning goes wrong.
- Whether it can delete the copy cleanly afterwards. A staging copy you cannot remove becomes a permanently outdated, publicly reachable duplicate of your site, which is a problem you did not have before.
Apply the same tiering logic from checking plugin compatibility: a cloning plugin is a Tier 1 plugin by definition, because it has access to everything.
The two things you must change on the copy before you touch anything
Do these before the update, not after. Both are cases where the default behavior of a working copy causes a real problem.
1. Stop search engines from indexing it. A publicly reachable copy of your site is a duplicate of every page you have. Go to Settings > Reading on the copy and enable the option to discourage search engines. You can confirm it took effect in Site Health > Info, which reports "Is this site discouraging search engines?" as a line item. Note that this setting is a request rather than a wall, so if your host offers password protection on the staging URL, use that too.
2. Stop it from sending email. This is the one that catches people out. A copy of your site has a copy of your order notifications, your form handlers, your membership emails and your scheduled jobs, and unless something stops them, it will happily email your actual customers from the test environment. Host staging tools often disable mail automatically; local installs usually trap it; a plugin-made clone in a subdirectory very often does not. Find out which situation you are in before you click anything, and if you cannot tell, deactivate any plugin whose job involves sending mail.
There is a third, softer one: if the copy shares a caching layer or CDN with the original, disconnect it. Otherwise you will be testing the cache.
Run the update, then run this test script
Applying the update is the easy part: Dashboard > Updates, Update Now. The part everyone skips is what follows, so here it is as a list rather than as "test your site".
Run these in order, on the copy, and write down what you find:
- Load the homepage. Logged out, in a private window.
- Load one post and one page. Check that the layout is intact, not just that they load.
- Load the admin dashboard. Look for error notices at the top.
- Open Posts. This is the screen WordPress 7.0 rebuilt, so if a plugin added columns or filters here, this is where you will see it fail.
- Open the editor on an existing post. Do not create a new one. An existing post exercises whatever blocks and page-builder content you actually use.
- Open Media. Same reasoning as Posts.
- Exercise your single most important action. Submit the contact form, add something to the cart, log in as a subscriber, whatever your site is for. One action, all the way through.
- Open each Tier 1 plugin's own settings screen. A plugin that fails on activation often looks fine until you open its admin page.
- Check Tools > Site Health. Compare the Status tab to what it said before the update.
- Look for something that changed that you did not expect. This is the whole reason for doing this on a copy.
Ten items, ten minutes. The list is short enough to actually run, which is the point.
Reading the result: what it proves and what it does not
If everything passed: you have good evidence that the update will go cleanly on the original, especially if the copy was made by your host on the same server. Not proof. Good evidence.
If something failed: you have found it for free, which is the entire return on the exercise. Now you know which plugin, which screen, and roughly why, and you can decide whether to wait for a vendor update, replace the component, or accept a temporary loss of that feature.
If the copy failed in a way that looks like the environment rather than the software, a memory error, a timeout, a missing PHP extension, treat that as inconclusive rather than as a result. That is the known weakness of a copy that is not on the same server.
Taking the decision back to your live site
The copy informed the decision. It does not perform the update.
On the live site: confirm the backup you can restore, pick a low-traffic hour when you will be at your desk for the following half hour, run the update, then run the same ten-item script above. The full sequence is the twenty-minute pre-update checklist, and if the live update goes wrong despite the copy having passed, rolling back without losing content covers the three separate rollback procedures and the case where a backup restore is the better call.
Do not push the updated copy over the live site. That is a migration, it is a different and much riskier operation than an update, and the whole reason this method is safe is that the copy is disposable.
What not to do with the copy afterwards
Delete it. A staging copy left running is an unpatched, publicly reachable, increasingly outdated duplicate of your site, with your data in it, that nobody is watching. If the host created it, remove it from the control panel. If a plugin created it, use the plugin's own removal function rather than deleting the folder by hand, so the database tables go with it.
If you would rather keep a permanent staging environment, that is a reasonable thing to want and it is a bigger subject than one update, because it introduces the problem of keeping two copies in step. For the narrower job of deciding whether to click Update, the disposable copy is the right tool, and what actually happens during an update explains the mechanism you just watched, which makes the next one easier to read.
If you are preparing specifically for 2026-08-19, the 7.1 release guide has the by-site-type answer on whether to update on day one, and this method is how you replace that judgment with an observation.
