How to Update WordPress Safely: Core, Plugins and PHP Without Breakage

Learning to update WordPress safely is the highest-value skill a site owner can have, because updates sit on both sides of the ledger at once: they are the single most effective security control you have, and they are also the single most common way working websites get broken. Almost every hacked WordPress site I have cleaned in twelve years was running something outdated; almost every “the site is suddenly white” email I receive starts with “I just clicked update”. The answer to that tension is not to stop updating, and it is not to click update and pray. It is process.

This guide is the process I use across the client sites I maintain for small businesses and agencies in Germany, the UK, the US and Australia: why updates genuinely cannot wait, the step-by-step safe update routine, which auto-updates to switch on and which to never touch, how core, theme, page-builder, WooCommerce and PHP updates each need slightly different handling, what to do when an update does break something, and how often to run all of this depending on the kind of site you own. None of it needs a developer’s skills – just a developer’s discipline.

Table of contents

• Why updates cannot wait: the CVE window
• Why updates break sites – and what that tells you
• The safe update routine, step by step
• Auto-updates: what to enable and what to keep manual
• Core updates: minor vs major
• Theme and page-builder gotchas
• WooCommerce update discipline
• PHP version updates: the one everyone postpones
• When an update breaks something: rollback options
• Update cadence by site type, and tooling
• The abandoned plugin problem
• Frequently asked questions

Why updates cannot wait: the CVE window

When a security vulnerability is found in a plugin, theme or WordPress core, it is disclosed publicly as a CVE (a catalogued vulnerability) at roughly the same time the patched version is released. From that moment a race starts. Attackers read the same disclosure you do, diff the patched code against the old code to see exactly what was fixed, and build an exploit for it. For a serious vulnerability in a popular plugin, automated exploitation of unpatched sites typically begins within 24 to 48 hours of disclosure – sometimes within hours. The attacks are not personal and not manual: bots scan the whole internet for sites still running the vulnerable version and exploit them in bulk.

That is the window that matters. A site that applies security updates within a day or two is ahead of almost all automated attacks. A site that updates “when someone remembers” – which in practice means every few months – spends most of its life inside the exploit window of something. The pattern in my inbox is depressingly consistent: the hacked sites were not targeted because they were valuable; they were harvested because they were running a plugin version with a known, published, scripted exploit. If that has already happened to you, my hacked site recovery guide covers the cleanup; this post is about never needing it.

• Updates are patches first, features second. The changelog line you care about is “security fix”, and it is often deliberately vague to avoid handing attackers a map.
• Popularity increases risk, not safety. A vulnerability in a plugin with two million installs is worth automating; obscure plugins get less attacker attention but also less auditing.
• “The site works fine” is not a security status. A site can run beautifully while being wide open. Working and safe are different properties.

Why updates break sites – and what that tells you

The other side of the ledger is real, and pretending otherwise loses people’s trust. Updates break sites in predictable ways: a plugin update conflicts with another plugin or with the theme; a theme update overwrites customisations that were made in the wrong place; a major page-builder release changes how it renders existing layouts; a PHP version jump exposes deprecated code in an old plugin; a WooCommerce update ships new template files while the theme still overrides the old ones. Notice the pattern – breakage is almost never random. It comes from interactions between components, and it clusters around major versions, page builders, template overrides and old code.

That predictability is good news, because it means the risk can be managed with a routine instead of luck. The three habits that eliminate most of the damage are embarrassingly simple: have a backup you can actually restore, test risky updates somewhere that is not the live site, and update in small batches so that when something does break, you know exactly which update did it. The disasters I get called into share the opposite profile: forty updates applied in one click, on the live site, on a Friday evening, with the last backup dating from the hosting signup. The update did not destroy that site. The missing process did.

The safe update routine, step by step

Here is the routine in full. It reads long; once practised it takes 20 to 40 minutes per site, and less on small sites.

1. Take a fresh backup – files and database – and know how to restore it. A backup you have never test-restored is a hope, not a backup. Use your host’s snapshot or a plugin like UpdraftPlus, and store a copy off the server. My backup and disaster recovery guide covers the full setup; for updates, the point is that the restore path is proven before you need it.
2. Read the changelogs of the big items. You do not need to read every line of every plugin. Scan the majors: core, the theme, the page builder, WooCommerce, anything payment- or booking-related. You are looking for the words “major”, “breaking”, “template”, “requires PHP”, and any migration notes.
3. Update on staging first when the batch includes anything risky. Risky means: a major version of anything, the theme, the page builder, WooCommerce, or a large batch after weeks of neglect. Most decent hosts offer one-click staging – a clone of the site where updates can fail harmlessly. If you have no staging, at minimum update at a low-traffic time with the backup ready.
4. Update in batches, in order: plugins first, then the theme, then core. Plugins in small groups (I do three to five at a time), refreshing the site between groups. Then the theme. Then core last, once everything around it is current – plugin authors test against the new core version before most sites install it, so this order means you update into tested territory. One batch at a time is what makes diagnosis trivial: if the site misbehaves, the culprit is in the last small batch, not somewhere in forty changes.
5. Run the visual check list. After each batch, and thoroughly at the end: home page, one key landing page, one blog post, the contact form (actually submit it), the menu and search, and on a store the product page, cart and checkout. Check logged out, and check on a phone. Five minutes, catches ninety percent of visible breakage.
6. Deploy to live and re-check. If you tested on staging, repeat the same updates on the live site (do not push the staging database over live – that overwrites real content and orders). Then run the same visual checks on live. Done.

Two scheduling rules make the routine calmer. Update midweek in the morning, never on a Friday or before a holiday – if something goes wrong, you want support channels and your own attention available, not a broken site over a weekend. And keep a one-line log (date, what was updated, anything odd). When something surfaces three days later, that log answers “what changed?” instantly – which is the first question in my guide to fixing common WordPress errors.

Auto-updates: what to enable and what to keep manual

WordPress can update itself, per component. Used well, auto-updates close the CVE window on the things that matter most while you sleep; used carelessly, they redesign your checkout at 3am. The policy that works is a split by risk and urgency, not a blanket on or off.

Enable auto-updates for:

• Minor core releases. These are the security and maintenance releases (6.5.1, 6.5.2). WordPress enables them by default; leave that alone. They are conservative, heavily tested and often urgent.
• Small, single-purpose plugins. An SEO redirect helper, a duplicate-post tool, a lightweight contact form. Low complexity, low blast radius, and their security fixes should land fast.
• Security plugins and firewalls. Their whole value depends on being current.
• Anything you would not notice being off for a day. If a breakage in that plugin would be a shrug rather than an emergency, automation is fine.

Keep manual (staging-first) forever:

• Major core versions (6.x to 7.0) – see the next section.
• WooCommerce and anything touching payments, orders or bookings. Revenue-critical code never updates itself unsupervised.
• Page builders (Elementor, Divi, Beaver Builder and friends). Major builder releases are the most common breakage source I see.
• Your active theme, especially if anyone ever edited it directly.
• Any plugin with template overrides or deep integration – membership, LMS, multilingual plugins.

One honest caveat: auto-updates without monitoring are a quiet risk, because nobody is looking at the site the morning after. Pair them with an uptime monitor (free tiers of UptimeRobot or similar are enough) and the weekly look-over from my maintenance checklist, so an overnight failure is a morning fix rather than a week of silent brokenness.

Core updates: minor vs major

WordPress core deserves its own rules because the two kinds of core release behave completely differently. Minor releases (the third number: 6.5.x) contain security patches and bug fixes only. They are designed to be safe to apply automatically, the project ships them with that promise, and in hundreds of sites under my care I can count the problems they have caused on one hand. Let them auto-install. Blocking minor core updates to feel “in control” mostly means being unpatched for longer.

Major releases (6.5 to 6.6, and especially a 7.0) are feature releases. They change the editor, update bundled libraries, occasionally deprecate old behaviour, and raise the minimum recommended PHP version over time. They deserve the full routine: read the release notes, wait a week or two after release day (the .0 of a major version collects its first bug-fix release quickly, and plugin authors ship compatibility updates in that window), update plugins and theme first, then apply the core update on staging, click through the visual checks with extra attention on the editor and anything JavaScript-heavy, then deploy. A major core update is not scary – it is roughly a 30-minute job with staging – but it is never a casual one-click on live.

Do not, however, let “waiting” become “parking”. Sites that skip four major versions and then must jump years in one leap are the genuinely risky projects – every compatibility problem arrives at once. Staying at most one major version behind, updated on your schedule within a few weeks of release, keeps every individual step small.

Theme and page-builder gotchas

Theme updates have one classic failure mode: the update overwrites files someone edited directly. If you (or a past developer) ever changed the theme’s PHP or CSS files in place, the next theme update silently deletes those changes – this is exactly what child themes exist to prevent. A child theme holds your customisations in separate files that survive parent updates. If you do not know whether your customisations live in a child theme, find out before the next theme update, not after: look under Appearance for a theme whose name ends in “child”, or ask a developer to check – it is a ten-minute question that prevents an ugly surprise. Custom CSS added through the Customiser or a settings panel is stored in the database and survives updates fine; direct file edits do not.

Page builders add a second layer of risk because they are effectively a rendering engine for your whole site. A minor builder update is usually uneventful. A major one can change how existing layouts render, alter spacing and defaults, or migrate its data format – and a data migration is one of the few updates that can be genuinely hard to reverse. My builder rules: never auto-update a builder; always staging-test major versions; after updating, check the pages with the most complex layouts, not just the home page; and read the release announcement, because builder vendors are usually upfront about breaking changes and migration steps. The same applies to big theme frameworks with bundled builders. None of this is a reason to avoid updating a builder – unpatched builders are a favourite attack target precisely because they are installed on millions of sites – it is a reason to update them deliberately.

WooCommerce update discipline

A store raises the stakes: an hour of broken checkout is not an inconvenience, it is lost revenue and lost trust, and a botched update can touch order data. WooCommerce updates therefore get the strictest version of the routine, no exceptions.

• Staging is obligatory, not optional. Every WooCommerce major or minor update gets tested on staging with a realistic copy of the site. Test the actual money path: product page, add to cart, checkout with your real payment gateway in test mode, and the order confirmation email.
• Check template overrides every time. Most WooCommerce themes override Woo template files (cart, checkout, product pages). When WooCommerce updates its templates, your overrides may be based on outdated versions – WooCommerce – Status – Templates lists every override and flags outdated ones. An outdated checkout template is how stores end up with subtle, expensive bugs.
• Update the ecosystem together. Payment gateways, shipping plugins and Woo extensions publish compatibility with specific WooCommerce versions. Update them in the same tested batch, not weeks apart.
• Mind database updates. Some WooCommerce releases prompt a database upgrade after the files update. Run it immediately after the update, from a quiet moment, with the backup fresh – never leave a store half-migrated overnight.
• Time it around trade. Update after your daily peak, never during a promotion, never in your busiest season week.

Store owners who find this burdensome are the clients I most often run maintenance plans for, and honestly it is the right call: the discipline matters more on a store, and it is exactly the kind of repetitive, careful work that is cheap to delegate and expensive to skip.

PHP version updates: the one everyone postpones

PHP – the language WordPress runs on – is the update nobody sees and everybody postpones. Old PHP versions stop receiving security fixes entirely a few years after release, so a site on an end-of-life PHP version is running on an unpatched foundation regardless of how current its plugins are. And the incentive is unusually pleasant: each recent PHP major has brought real speed gains, so this is the rare update that makes the site measurably faster for free. Moving a site from an ancient PHP to a current supported version often cuts server response time by a third or more without touching anything else.

The risk profile is different from plugin updates: PHP changes break old code, so the age of your plugins and theme predicts the pain. The safe path:

1. Check where you are. Tools – Site Health shows the current PHP version and warns if it is outdated.
2. Update everything else first. Current plugin and theme versions are far more likely to support current PHP.
3. Test on staging with the new PHP version. Good hosts let you set the PHP version per environment. Switch staging up, click through the site with debug logging enabled, and watch for white screens and warnings. A compatibility scanner plugin can help but produces false positives; the staging test is the real answer.
4. Switch live, watch, and keep the way back. Hosts let you flip the version in the control panel, and flipping back is instant – which makes PHP one of the safest updates to attempt once tested.

If one old plugin blocks the whole migration, that plugin has just identified itself as a liability – see the abandoned plugin section below. Do not let one dead plugin chain your whole site to an unpatched PHP version.

When an update breaks something: rollback options

Even with the routine, sometimes an update misbehaves – a layout shifts, a form dies, or the site white-screens. The difference between a bad five minutes and a bad weekend is knowing your ways back before you need them, so here they are, from fastest to heaviest:

• Deactivate the offending plugin. Because you updated in small batches, you know the suspects. Deactivating a broken plugin restores the site minus that feature – usually an acceptable state while you investigate. If the admin area itself is down, WordPress’s recovery mode emails you a special login link when a plugin or theme fatal error occurs; that link lets you in with the broken component paused.
• Roll the component back a version. The WP Rollback plugin lets you install the previous version of any plugin or theme from the WordPress.org repository in a few clicks. For premium plugins, download the previous release from the vendor’s account area. Rolling back buys time; it is not a place to live, because you are back inside the vulnerability window – pin the version, report the bug to the author, and re-test the new release when it is patched.
• Restore the backup. The full way back, and the reason step one of the routine is non-negotiable. Restore files and database from immediately before the update session and you are exactly where you started. On a store, restore thoughtfully – a database restore discards orders placed since the backup, so prefer component rollback on a live store and full restores within minutes of the break.
• Know when to stop. If the database is involved, if a builder migration went wrong, or if the same component fails repeatedly, stop experimenting and get a professional in – an hour of experienced help is cheaper than a day of guessing.

After any rollback, write down what broke and why, if you found out. “Plugin X major versions need a staging test” is site-specific knowledge that makes every future update session safer.

Update cadence by site type, and tooling

How often should all this happen? The honest answer scales with what the site does and how much it changes. Security updates are urgent everywhere; the routine’s depth varies.

On tooling: if you run more than three or four sites, a management dashboard such as ManageWP, MainWP or WP Umbrella pays for itself quickly – one screen for updates, backups and uptime across every site, with per-site update batches and quick rollbacks. For one or two sites, plain WordPress plus a good backup plugin and an uptime monitor is genuinely enough; the tooling matters far less than the rhythm. Updates belong inside a broader maintenance habit – the weekly and monthly checks in my WordPress maintenance checklist – rather than as a standalone panic whenever the admin bar shows a big orange number.

The abandoned plugin problem

Sometimes the reason a site cannot update safely is that a plugin has no updates left: the author stopped maintaining it. The warning signs are visible on the plugin’s WordPress.org page – “hasn’t been tested with the last 3 major versions”, no changelog entries for a year or two, support threads answered by nobody. An abandoned plugin is a slowly expiring asset: every core, PHP and neighbour-plugin update moves the ground under it, and if a vulnerability is found in it, no patch is coming. Several of the worst hacks I have cleaned came through exactly this – a small, forgotten plugin, years dead, quietly exploitable.

The decision is a replacement decision, and it is easier taken early than in an emergency:

• Is it still needed at all? A surprising share of abandoned plugins turn out to power nothing anyone remembers. Deactivate on staging, look for what breaks, and delete happily if nothing does.
• Is the feature now in core or in a plugin you already run? WordPress and the big plugins have absorbed many one-trick features over the years – duplicate posts, custom CSS, sitemaps, basic SEO tweaks.
• Is there a maintained equivalent? For most common needs there are several actively developed alternatives. Migrate on staging, check the content and settings carried over, then deploy.
• Is it niche but essential? Then budget a small piece of custom development to replace it – a focused replacement is often simpler than the old plugin, because it only needs the one feature you actually use.

Rule of thumb: the moment a plugin blocks a PHP update, a core major or a Woo update, its replacement stops being optional and becomes this quarter’s task. Sites do not break on the day a plugin is abandoned; they break two years later, all at once.

Want your updates handled for you?

All of this is exactly what my WordPress maintenance and security plans cover: weekly tested updates with backups and staging, uptime and security monitoring, and a report you can actually read – for owners and as white-label work for agencies, from EUR 15 per hour or a fixed monthly price. See the portfolio for the kind of sites I keep running, or tell me about your site – I reply within 24 hours.

Frequently asked questions

How do I update WordPress safely?

Take a tested backup, update risky items on a staging copy first, then update in small batches in this order: plugins, theme, core. Run a visual check of key pages and forms after each batch, and keep a rollback path ready.

Should I enable WordPress auto-updates?

Partially. Leave minor core releases on and enable auto-updates for small, low-risk and security plugins. Keep major core versions, WooCommerce, page builders and your theme manual with a staging test.

What order should I update WordPress in?

Plugins first (in small batches), then the theme, then core last. Plugin authors test against new core versions, so updating core last means you update into tested territory.

How often should I update WordPress?

Weekly for business sites and stores, at least fortnightly for simple sites – and apply serious security patches within a day or two of release, because automated exploitation of known vulnerabilities starts within about 24 to 48 hours.

Do WordPress updates break websites?

Occasionally, and predictably: major versions, page builders, template overrides and old PHP cause most breakage. A backup, a staging test and small batches turn a potential disaster into a five-minute rollback.

How do I undo a WordPress update that broke my site?

Deactivate the offending plugin (recovery mode emails you a login link if the site is down), roll the component back a version with WP Rollback or the vendor’s previous release, or restore the backup taken before the update session.

Is it safe to update PHP on a WordPress site?

Yes, once plugins and theme are current and you have tested the new version on staging. Hosts let you switch versions instantly in both directions, and modern PHP is significantly faster and still receives security fixes.