It usually goes like this. You log in, see a cluster of little red update badges, click “Update All”, and go to make a coffee. When you come back, the homepage is a jumble of unstyled text, or worse, a white screen. What you didn’t know was that the page builder update needed a newer version of your theme, the two conflicted, and there was no backup to fall back on. Two hours on the phone to a developer later, the site is back online, but your afternoon has gone.
None of that was bad luck. It was the absence of a process. Updating WordPress isn’t dangerous, but “click everything at once and hope” is, and it’s how most small sites get broken. This post walks through the right order to update your plugins, themes and core, what to check before and after, and how to handle the updates that carry more risk. Follow it and that lost afternoon doesn’t happen.
The Right Order to Update
Most guides treat updating as a single action: click the button, done. It isn’t. The order you update things in genuinely matters, because WordPress is a stack of parts that all depend on each other — and updating them in the wrong sequence is how you create the conflicts you were trying to avoid. Here’s the order, and the reasoning behind each step.
- WordPress core first. Core is the foundation everything else is built on. Plugins and themes are written to work with whatever version of core is currently installed, so updating core first means everything you update afterwards is building against the correct target rather than an outdated one. Do this before touching a single plugin.
- Security patches immediately. Any update flagged as a security release in its changelog shouldn’t wait for your normal cycle. These are the ones where the gap between a vulnerability being disclosed publicly and your site being scanned for it is measured in hours, not days. If you see “security fix” in the release notes, apply it now, out of order if you have to.
- Plugins next — high-risk ones via staging. Not all plugins carry the same risk. Page builders (Elementor, Divi, Beaver Builder), WooCommerce, payment gateways and membership plugins are the ones to treat carefully, because they touch almost everything on the site, such as layout, checkout, and user accounts, so a conflict has more surface area to go wrong. Run these on a staging copy first, confirm nothing breaks, then apply to live. (If you’re not set up for that yet, start here with what a WordPress staging site actually is.)
- Lower-risk plugins. Contact forms, SEO plugins, analytics integrations — these do smaller, more contained jobs, so the odds of an update breaking something are lower. On a well-maintained site with a recent backup, these can usually go straight to live without staging. Update them, but you needn’t agonise over each one.
- Themes last — especially customised ones. Theme updates can overwrite customisations, so if you’ve made changes directly to your theme (rather than through a child theme), a routine update can wipe them. Check the changelog first, and if you’ve customised anything, test on staging before you apply it live.
In short: work from the foundation up, deal with anything security-flagged the moment you see it, and take the most care over the updates that touch the majority of your site.
Before You Update Anything
Three things before you click a single update button. None of them take long, and each one is the difference between a quiet afternoon and a stressful one.
Take a backup. Off-site, recent and complete, so that if something breaks you’re looking at a five-minute restore rather than a rebuild — if that’s not already running automatically, our Daily Backups service handles it.
Check your staging site. For the high-risk updates — page builders, WooCommerce, core version jumps etc, run them on staging before they go near live; set that up first if you haven’t.
Read the changelog. One minute in a plugin’s release notes will flag known conflicts or breaking changes, and it’s worth doing for any major version jump. The difference between a minor bump and a major one is usually where the trouble lives.
How to Check After Updating
The checks most people skip are the ones that catch a problem while it’s still cheap to fix. Do these immediately after updating, and not the next day. The sooner you spot something, the easier it is to pin down which update caused it.
Open your homepage in an incognito window (so you’re seeing the live cached version a visitor sees, not your logged-in view) and confirm it loads and renders correctly — layout intact, images showing, no unstyled text. Then work through the things that actually earn the site money: submit a test enquiry through your contact or booking form and confirm it goes through; if you run WooCommerce, add a product to the basket and complete a test checkout end to end. Open the WordPress admin and check the dashboard for new error notices or warnings, and glance at Site Health under Tools → Site Health for anything freshly flagged. Finally, clear your site cache — a caching plugin or host-level cache can keep serving the old version of a page and mask a problem that’s actually there, or invent one that isn’t.
If all five come back clean, the update’s done. If one doesn’t, you’ve caught it early and you know roughly where to look.
What to Do When an Update Breaks Something
Don’t panic. Most breakages are recoverable, and the ones that feel catastrophic usually aren’t.
Restore from backup first, investigate second. If the site is broken for visitors, get the working version back up before you do anything else. Don’t try to debug a broken live site while customers are landing on a white screen. Restore first, then work out what happened on a copy.
If you were on staging, you’re already in the right place. The whole point of staging is that a broken update there touches nobody. Troubleshoot at your leisure, and don’t push to live until it’s fixed.
If you didn’t use staging and don’t have a recent backup, this is the hardest version of the situation — but not a hopeless one. Our guide to a failed WordPress update walks through the DIY recovery steps in order, and if you’d rather hand it to someone, the update broke my site fix page is the fast route to hands-on help.
One honest observation: if restoring from a backup feels daunting, or you’re not certain you have a reliable recent one, those are the two things worth solving before the next update cycle — not during the next emergency.
How Often Should You Update?
For most sites, at least monthly. Security patches are the exception — apply those as soon as they land, rather than waiting for your normal cycle. Major version updates to core, page builders and WooCommerce deserve a bit more care: test on staging, read the changelog, and don’t run them on a Friday afternoon when there’s no one around to notice if something goes sideways over the weekend.
A word on automatic updates, because the honest answer sits in the middle. WordPress can apply updates automatically for both core and plugins, and for security patches that’s sensible — you want those on as fast as possible, and the risk of a security fix breaking your site is low. For major plugin updates, automatic is riskier: a page builder or WooCommerce conflict at three in the morning, with no one watching and no chance to test on staging first, is a far worse position than the same conflict caught deliberately during a Tuesday afternoon update. The sensible setting for most sites is auto-updates on for security and minor releases, off for the big ones you’d rather apply by hand.
The Process Is the Point
Almost every update that ends badly comes down to one of two things: skipping the process (no backup, no staging, no post-update check) or treating every update as carrying the same risk when they plainly don’t. A minor security patch and a major page builder release are not the same job, and the routine above is built around that difference.
Done properly, a monthly update cycle takes maybe 30 to 45 minutes. It feels like overhead right up until the afternoon it saves you two hours of emergency recovery and a phone call you didn’t want to make. That’s the trade the whole process is built on.
Two ways to go from here. If you want to understand staging properly before your next cycle with how to set one up and when it’s worth the effort, start with what a WordPress staging site actually is. And if you’d rather not run updates, staging and monitoring yourself every month, that’s exactly what our WordPress Maintenance service is for — the whole routine, handled, so it’s off your plate.
Update WordPress core first, then apply any security-flagged patches immediately, then your plugins — high-risk ones (page builders, WooCommerce, payment and membership plugins) tested on staging first, lower-risk ones (contact forms, SEO, analytics) applied directly on a well-maintained site. Update themes last, especially if they’ve been customised. The logic is to work from the foundation up and give the updates with the most reach the most caution.
Not blindly. Clicking “Update All” is how most sites break, because it applies high-risk and low-risk updates in one undifferentiated action with no chance to test the risky ones or spot which update caused a problem. Take a backup first, update in order, and test the high-risk plugins on staging before they go live. Updating in sensible batches also means that if something breaks, you know which update to look at.
Don’t panic, and don’t try to debug a broken live site. If visitors are seeing errors, restore from your most recent backup first, then investigate what went wrong on a staging copy. If you were already testing on staging, you’re in the right place: troubleshoot there and don’t push to live until it’s fixed.
At least monthly for most sites, with security patches applied as soon as they’re released rather than held for the monthly cycle. Major updates to core, page builders and WooCommerce warrant more care — test on staging and check the changelog before applying. Keeping to a regular cycle is safer than long gaps followed by a large batch of overdue updates all at once.
