One click on "Update now" on Friday at 5 p.m. White screen. Nobody knows which plugin just changed. Last backup is three weeks old — untested. This is not a WordPress curse: it is missing process sold as agility.
Updating WordPress is an operations skill, not a clickable chore. Goal is not to be current at any price — it is to stay current without surprises.
Three layers — and their respective risks
| Layer | Frequency | Common risk |
|---|---|---|
| WordPress core | Regular | Rare alone, conflict with old plugins |
| Plugins | Very frequent | Broken feature, fatal error |
| Theme / builder | Variable | CSS layout, custom templates |
| Host PHP | Yearly | Silent incompatibility then crash |
Updating core without testing plugins is changing the engine without checking belts.
Minimal process that holds
Inventory active plugins, versions, business-critical ones (payment, forms, SEO). Create identical staging: same PHP, same extensions. Immediate backup before prod — files + database, with restore already tested once.
Execution order in staging then prod: core, plugins one by one or homogeneous batch, theme last, cache purge after each step. Smoke test: admin login, homepage, cart, form, test payment if e-commerce.
Automatic updates: where to set the cursor
Core micro-security: sometimes yes on simple sites. WooCommerce and page builders: no without staging test. Document who decides, who validates, what frequency. On simple brochure sites, core security micro-updates may run automatically; on WooCommerce or builder-heavy stacks, treat every major plugin release as a staged change with rollback ready.
Align PHP version with Choosing a PHP version before major upgrade. Many breakages come from a host PHP bump while plugins still target an end-of-life runtime.
The peak: production is not a test environment
Teams without operations time defer updates — then a CVE forces panic upgrade. Small regular process beats weekend catch-up. Document who approves plugin updates and who can roll back production if smoke tests fail after core upgrade.
Decide and move forward without blind spots
Create or request staging at host. Test backup restore this month — a backup you have never restored is only a hope. Set calendar (e.g. Tuesday 10 a.m., outside promos). Keep internal plugin/core changelog with date, owner, and result of smoke tests after each production change. Prepare rollback: FTP access, plugin folder rename, and a one-page runbook the on-call can follow without opening twenty tabs.
See Managed WordPress if you outsource part of the cycle.
Frequently asked questions
What order to update WordPress?
Full backup, then core, plugins, theme — staging first if possible. Never chain multiple changes without intermediate restore point.
Enable automatic updates?
Auto for core micro-security sometimes relevant. Major plugins and WooCommerce: no without staging test.
How to test without staging?
Local clone or minimal subdomain — never Friday evening straight to production.
What if update breaks site?
Backup restore or plugin disable via FTP — procedure prepared in advance, not improvised during outage.
WordPress updates itself in theory. In practice, only human process stops production becoming the lab.