WordPress update best practices: the safe update order
Most sites do not break because they were updated. They break because they were updated in the wrong order, on live, with no way back. This is the exact procedure we run every week across a 150 site fleet.
Last updated ยท Reviewed by Ali Yasin Jatoi
Short answer
Back up and verify the restore, clone to staging, update plugins in risk batches, then the theme, then core, then PHP on its own round. Smoke test checkout, forms, login and search after every batch. Never update on a Friday, never on live first, and keep a written rollback anyone can run in ten minutes.
The safe WordPress update order
- Backup, then test the backup. An untested backup is a rumour. Restore it to staging once a quarter so you know the button works.
- Read the changelogs. Two minutes. Anything that says "breaking change", "requires PHP 8.2" or "database migration" gets its own slot.
- Low risk plugin batch. Utilities, admin helpers, SEO plugins. Update together, smoke test.
- High risk plugins, one at a time. Page builders, WooCommerce and extensions, payment gateways, caching, security, membership. Test after each.
- Theme. Confirm your customizations sit in a child theme first, otherwise the update erases them.
- WordPress core. Last, once the plugin layer is stable, so a core release is never blamed for a plugin conflict.
- PHP version, separate round. Never on the same day as a big plugin round.
How often to update WordPress
- Security releases: inside 24 hours. Disclosed plugin vulnerabilities get scanned by bots within about 48 hours.
- Everything else: a fixed weekly window, mid morning, with a human watching.
- WooCommerce stores: same weekly window, but never during a promotion, a launch, or the last week of the quarter.
- Core majors: wait 7 to 14 days after release unless it is a security major. Let other people find the regressions.
Staging rules that prevent breakage
- Staging must be a real clone, same PHP version and same plugin set, or the test proves nothing.
- Block staging from search engines and from sending live email or payments.
- Run the same smoke test script every time so results are comparable week to week.
- If staging passes and live still breaks, the difference is almost always caching, a server level rule, or a licence key that only exists on production.
Rollback plan
Write it down before you need it. Ours is four lines: restore the pre update snapshot, purge every cache layer, confirm checkout completes a test order, then reproduce the failure on staging. Restore first, debug second. Every hour spent debugging a live store is roughly $208 in lost orders on a mid sized site.
Locked out of wp admin after an update? Rename the offending plugin folder inside wp-content/plugins over SFTP. WordPress disables a plugin it cannot find, and admin usually comes straight back.
Locked out of WordPress admin, full fixThe plugins that break sites most often
Ranked by how often they caused a rollback across our fleet:
- Page builders (Elementor, Divi, Avia, WPBakery): editor stops loading, layouts shift.
- WooCommerce plus extensions: checkout fails silently, tax or shipping rules reset.
- Caching and optimization: minification breaks JavaScript, pages render half styled.
- Security plugins: firewall rules lock out admin or block the REST API.
- Custom code snippets: deprecated PHP calls throw a fatal error after a core bump.
Builder specific fixes: Elementor not loading, Avia Layout Builder not loading, critical error after an update.
Updating at fleet scale
Running this on one site is a checklist. Running it on 150 sites (the Pearl Lemon internal fleet the founder managed) is only survivable with standardization: the same plugin bundle, the same hosting tier, the same PHP version, the same staging rule, the same watched window. When every site is different, one update round eats a week. When they are identical, one engineer clears the whole fleet in an afternoon.
Fleet operations playbookFAQs
What are the best practices for WordPress updates?
Six rules. (1) Take a full file and database backup immediately before any update, and confirm it restores. (2) Update on staging first, never straight to live. (3) Update in order: backups, then PHP compatibility check, then plugins one batch at a time, then theme, then core. (4) Never update during business hours or on a Friday. (5) Smoke test the money paths after every batch: checkout, contact form, login, search. (6) Keep a written rollback step so anyone on the team can undo it in under ten minutes.
Should I update WordPress plugins all at once or one at a time?
Batch by risk, not all at once. Group low risk plugins (small utilities, admin helpers) and update them together, then smoke test. Update high risk plugins on their own: page builders, WooCommerce and its extensions, caching, security, membership, and anything touching checkout. If a batch breaks the site you only have four suspects instead of twenty six.
How often should WordPress be updated?
Security releases within 24 hours, because bots start exploiting disclosed plugin CVEs inside 48 hours. Everything else on a weekly window on a fixed day, mid morning, when a person is available to watch it. Monthly is too slow on a WooCommerce site and daily is too noisy for a brochure site.
Should I enable WordPress auto updates?
Auto update core minor releases and any plugin you would not notice breaking. Do not auto update page builders, WooCommerce, payment gateways, caching or security plugins. Those are the ones that take checkout down, and an auto update at 3am means nobody sees the failure until morning.
What do I do if a WordPress update breaks my site?
Do not try to fix forward under pressure. Restore the pre update backup first so the site is live and earning again, then reproduce the break on staging with the same update and find the real conflict there. If you have no backup, deactivate the last updated plugin over SFTP by renaming its folder in wp-content/plugins, which forces WordPress to disable it and usually restores admin access.
Do I need to update PHP as well as WordPress?
Yes, and it is the update most people skip. Plugins increasingly require PHP 8.1 or newer, and a site left on 7.4 gets no security patches at all. Test the PHP bump on staging, watch for deprecation notices from older custom code, then promote. Doing PHP after a big plugin update round makes it far harder to tell which change caused a problem.
Want someone else to run update rounds?
Care plans include weekly staged updates, the smoke test, and the rollback if anything moves. From $99 per month, and if an update we ran breaks something, we fix it at no charge.
30 day money-back guarantee.