Why updates get postponed
People postpone updates for a sensible reason: an earlier one broke something while nobody was looking. The WordPress documentation is blunt that a current backup should exist before updating plugins and that problems can happen during an update, and it recommends reviewing all the plugins before a bulk update. The trouble is that "review" and "backup" are not the same as "tested". A routine that tries each update on a copy, checks the pages and forms that matter, and ends in a written decision per update replaces the fear with evidence.
- A backup lets you recover; a staging test lets you avoid needing to.
- Decide in advance which pages and forms count as "the site works".
Make the copy behave like a copy
WordPress has a notion of environment type, introduced in WordPress 5.5.0, with values local, development, staging and production, set through an environment variable or a constant, defaulting to production. Hosts are asked to use staging for their staging copies. One side effect is worth knowing: if the type is development and WP_DEBUG is not defined, WordPress turns debugging on. A staging copy should also have outgoing email switched off and payments in test mode, so that testing does not message customers. The WooCommerce conflict guide makes the same point about staging and notes that host-installed drop-ins and must-use plugins still run when you deactivate ordinary plugins.
- Check the environment value on the copy under Site Health, Info.
- Confirm mail is captured or disabled before the first test.
Cut the copy off from the outside world, and keep it private
A copy of a live site carries the live site's settings with it, including the keys that connect it to other services. If those are left in place, testing on the copy can do real things: add a test contact to your CRM or newsletter list, call a webhook or automation tool, count as a conversion in analytics or an advertising tag, or use a live payment key. Before the first test, switch every outside connection off, point it at its sandbox or test mode, or remove its key from the copy, and note what you changed. The copy should not be reachable by the public either. The Reading settings' option to discourage search engines adds a noindex robots tag (since WordPress 5.3), but the WordPress page says it does not block access and that it is up to search engines to honour it, so it is not privacy; put the copy behind a password or an address allow-list at the host. A copy that holds real customer or member records and cannot be made private is a reason not to use it for the test.
- List the outside connections first: CRM, newsletter, webhooks and automation tools, analytics and advertising tags, payment keys, outgoing email.
- Re-check these after every refresh of the copy from live, because a refresh brings the live settings back.
Apply updates in small groups
WP-CLI, the command-line tool, supports updating a single plugin or all of them, and offers --dry-run to preview what would be updated, --exclude to skip named plugins, and --minor or --patch to limit the size of the step. Its --all example turns on maintenance mode during the run, which is another reason to do this on a copy. Updating everything at once makes a failure uninformative; updating a few at a time, and running the checklist after each group, tells you which update caused it. If the dashboard does not show updates at all, check whether DISALLOW_FILE_MODS is set, since the configuration handbook says it blocks plugin and theme installs and updates from the admin.
- Update low-risk plugins first, then the ones that touch forms, payments or layouts.
- Run the checklist after each group and record the result.
Write the decision down
A useful result per update is short: the plugin or theme, the version it moved from and to, pass or hold, the evidence, and, for a hold, the failure that can be repeated from the steps given. Add the order in which to apply the passed updates to the live site and how to reverse each one. A pass means the named pages and forms passed on staging; it is not a guarantee about the live site or pages outside the checklist, and the report should say so.
- Mark security fixes separately; a held security update is a decision for the site owner.
- Keep the previous version available for every update.
How this becomes a service, and what it does not include
The standing staging-test service has a published test price of GBP 145 a month for one site, up to twenty pending updates, a checklist of up to ten pages (the login counts as one) and three forms, and a written pass or hold decision for every pending update; your team applies the passed updates. It tests on a private staging copy with email and outside connections off, and it checks that each month. It does not include backups, uptime monitoring, applying updates live or round-the-clock cover, and a security update is tested in the next monthly test with no earlier test promised. A separate monthly maintenance service (published test price GBP 195 a month) also applies the updates with your approval and checks backups, for sites where nobody else does. Finding the cause of a held update is the separate conflict job. Prices are untested proposals and payment follows the agreed terms.
- Send the theme name, a plugin count and the pages and forms that matter.
- Say who refreshes the staging copy and who applies updates.
Sources and limits
- WordPress documentation: Manage Plugins Checked 2026-10-11.
- It says to always have a current backup before updating plugins and to quickly review all plugins before a bulk update; automatic updates for individual plugins were introduced in WordPress 5.5.
- WordPress developer reference: wp_get_environment_type() Checked 2026-10-11.
- Introduced in WordPress 5.5.0. The values are local, development, staging and production, defaulting to production; it is set by a WP_ENVIRONMENT_TYPE environment variable or constant; when the result is development and WP_DEBUG is not defined, WP_DEBUG is turned on.
- WP-CLI: wp plugin update Checked 2026-10-11.
- Options include --all, --dry-run (preview without applying), --exclude, --minor, --patch and --version; the --all example turns on maintenance mode during the update.
- WordPress developer handbook: wp-config.php Checked 2026-10-11.
- DISALLOW_FILE_MODS blocks plugin and theme installation and updates from the admin area and disables the file editor; WP_AUTO_UPDATE_CORE controls automatic core updates.
- WooCommerce documentation: how to test for conflicts Checked 2026-10-11.
- It advises a backup or staging site first, updating plugins and themes before further conflict testing, and notes that host-installed drop-ins can still cause conflicts.
- WordPress documentation: Settings Reading screen Checked 2026-10-11.
- The Discourage search engines from indexing this site option has added a noindex, nofollow robots tag since WordPress 5.3, and the page says neither it nor the other option blocks access to the site: it is up to search engines to honour the request.