Updates: why they belong on a staging site first

Updates belong on a staging site first, because that is where you see whether something breaks before your visitors do. Putting them off is no alternative: attacks on known holes in WordPress plugins are automated and often start within hours. Clicking "Update all" directly on the live site usually works — and when it does not, the site is down and you do not know which of the eleven updates was to blame. A staging site is the path between the two mistakes: a copy of the website where you try things out before it counts.

Why updates cannot wait

Patchstack, a WordPress security vendor, counts 11,334 new vulnerabilities in the WordPress ecosystem for 2025 in its report "State of WordPress Security in 2026", 42 percent more than the year before. 91 percent of them were in plugins, 9 percent in themes, and six in WordPress core itself.

And it happens fast. For the heavily exploited vulnerabilities, the median time to the first mass exploitation was five hours; about half of the high-impact vulnerabilities were exploited within 24 hours.

That means: nobody picked your website. A program scans the web for sites running a particular plugin version. Your site is not too small to be interesting — to that program it is one line in a list.

What WordPress already does itself

WordPress takes some of the work off your hands, and it is worth knowing which part:

What	How	Since
minor core releases (maintenance and security)	update themselves by default; WordPress strongly discourages switching this off	—
plugins and themes	auto-updates can be switched on per plugin and per theme; WordPress checks twice a day and sends an email	5.5
fatal error protection	on a fatal error WordPress shows an error message and emails a link to recovery mode	5.2
rollback for plugin auto-updates	after the update WordPress requests the home page; if a fatal PHP error occurs, the previous version is restored	6.6

This is a safety net, not a test. The rollback only detects fatal PHP errors on the home page. A form that no longer sends mail, a broken layout or a broken checkout go unnoticed. Major core releases, theme changes and big jumps in central plugins therefore still belong on the staging site.

What a staging site is

A second copy of your website — with the same content, the same plugins, the same settings — that is not publicly reachable and where you can try things out without anyone noticing.

Many hosts offer this with one click: create a copy, work on it, then discard it or push it live. Where they do not, a copy can be set up on a subdomain.

Two conditions make it useful:

• It has to be current. A copy from six months ago tests a website that no longer exists. Refreshing it belongs in regular maintenance, and always before bigger projects.
• It has to be protected. A publicly reachable copy creates duplicate content. Google writes that content which is not meant to be public has to be protected with a password. Password protection at server level keeps out search engines and the curious alike.

The routine that works

Before:

1. Make a backup. WordPress.org itself advises backing up before every update. Do not rely on last night's backup — make a fresh one and check that it is there.
2. Bring the staging site up to date.
3. Read the changelogs. For a new major version of a plugin, they often say what changes fundamentally. Those are the updates worth a closer look.

On the staging site:

4. Update one at a time, not everything at once. With five plugins at once you will not know which one it was if something fails. It is also the method WordPress.org recommends for troubleshooting: switch all plugins off and switch them back on one by one.
5. Check briefly after every step.

Checking means, specifically:

• Does the home page still look right?
• Do the forms work — and does the email actually arrive?
• Click through the most important pages: home, services, contact.
• Check the browser console (F12) for JavaScript errors.
• Look at the mobile view.

The email point is the one most often missed. A form that shows a confirmation has not sent an email yet. Check the inbox, not the screen.

After:

6. Transfer to the live site — depending on the setup, by pushing the staging site live or by repeating the same steps.
7. Run the same check again on the live site. It is not identical to the staging site: a different address, a different cache, real form recipients, a real payment connection.
8. Clear the cache. Otherwise you see the old version and take it for the new one.

What comes first

Not every update is equally urgent.

• Security updates come first. If an update closes a hole that is already being exploited, the risk of waiting is greater than the risk of a display glitch. Then you install first and check afterwards — not the other way round.
• Minor core releases run automatically anyway.
• Major core releases and major versions of central plugins — page builder, shop, forms — belong on the staging site.

The PHP version is easily forgotten, even though everything runs on it. Each PHP version gets two years of full support and two further years of security fixes only; after that, nothing. The PHP project warns that users of an end-of-life version may be exposed to unpatched security vulnerabilities. WordPress recommends PHP 8.3 or newer. Switching is usually one click at the host — and that is exactly why it belongs on the staging site, because old plugins can break on it.

If something breaks anyway

On the staging site: nothing. That is what it is for. Find the cause, replace the plugin or go back to the old version, carry on.

On the live site:

1. Stay calm. Changing more things in a hurry makes the search harder.
2. Check the inbox. When WordPress reports a critical error on the site, it sends an email with details and a link to recovery mode to the administrator's address.
3. Deactivate the plugin you updated last.
4. If you cannot get into the admin area: use file access to rename the plugins folder inside wp-content, for example to plugins-old. WordPress then no longer finds the plugins and switches them all off. Afterwards, rename it back and switch them on one by one.
5. If that does not help: restore the backup.
6. Then find the cause before trying the same update again.

A white page is usually a PHP error, caused by a plugin or the theme. WordPress.org advises switching on debug mode in wp-config.php and reading the log in wp-content/debug.log — it usually says which file is affected. Switch debug mode off again afterwards.

The rhythm

Updates done "when there is time" do not get done. A fixed rhythm works:

Monthly: check and install WordPress core, plugins and themes, check the PHP version, check backups, run a security scan, look at the error log, test the contact form all the way to the inbox, measure loading time.

Quarterly: go through the plugin list, clean up the database, check the certificate, check for dead links, refresh the staging site.

Yearly: a full security review, check the hosting plan and domain renewal, check the privacy policy and imprint are current, spot-check accessibility.

The gap that care does not close

An honest addition: according to Patchstack, 46 percent of vulnerabilities had no fix from the developer at the time of disclosure. Even a model updater then has a gap — and faster updating does not close it, because there is nothing to update.

The usual answer is a protective layer in front that blocks the attack pattern before the plugin itself is fixed. Security vendors such as Patchstack sell such rules. For a small business-card site this is often more than needed. For a business whose website takes enquiries or orders, it is the obvious addition.

This is not an argument against updates, but against taking updates for the whole answer.

What to do

1. Set up a staging site if you do not have one. Ask your host — many include it. And protect it with a password.
2. Stop updating directly on the live site. Even if it has gone well so far.
3. Leave minor core updates on and consider auto-updates for simple, well-maintained plugins — with a backup behind them.
4. Set a fixed date. One fixed day a month.
5. Check the PHP version. The most often overlooked point.
6. Refresh the staging site regularly. An outdated staging site tests the wrong website.
7. And if this is too much for you: that is exactly what maintenance contracts are for. Not because it is complicated, but because it has to be regular — and regularity is the first thing to go next to day-to-day business.

Sources

• Patchstack, State of WordPress Security in 2026 — 11,334 vulnerabilities in 2025, plus 42 percent, 91 percent plugins, 9 percent themes, 6 in core, 46 percent without a fix, five-hour median, about half within 24 hours: patchstack.com
• WordPress.org, Upgrading WordPress — backup before updating, automatic minor releases, troubleshooting by switching plugins on one by one: developer.wordpress.org
• WordPress.org, Plugin and themes auto-updates — since 5.5, twice a day, email notification: wordpress.org
• Make WordPress Core, Merge Proposal: Rollback Auto-Update — rollback on a fatal error via a request to the home page, recovery mode since 5.2: make.wordpress.org
• Make WordPress Core, WordPress 6.6 Field Guide — rollback for plugin auto-updates in 6.6: make.wordpress.org
• WordPress.org, Common WordPress Errors — critical error and email, renaming the plugins folder, debug mode and debug.log: developer.wordpress.org
• WordPress.org, Requirements — PHP 8.3 or newer recommended, end-of-life versions as a security risk: wordpress.org
• PHP, Supported Versions — two years of full support, two years of security fixes, warning about end-of-life versions: php.net
• Google Search Central, Control what you share with Google — protect private content with a password: developers.google.com
• WordPress.org, Hardening WordPress — keep plugins updated: developer.wordpress.org