Updates
Update WordPress Without Breaking Things: A Safe Order
The safest way to update WordPress is to back up first, update in the right order (plugins, then themes, then core), and test after each step — not all at once. Most updates are safe if you follow a consistent pre-flight routine; the ones that break sites almost always skip it.
This guide gives you that routine in full, explains why updates go wrong, and tells you exactly when it makes sense to hand the job to someone else.
Why Updates Break Sites (And Why "Don't Update" Is Worse)
Updates break sites for a small set of recurring reasons:
- PHP version mismatch. A plugin or theme built for PHP 8.1 can throw a fatal error on a server still running PHP 7.4, and vice versa.
- Plugin–theme conflicts. Two components that worked fine independently can collide when one updates its API or hooks.
- Customisations in the wrong place. Code edited directly in a theme's files gets overwritten by a theme update. (See why direct theme edits break sites for the full explanation.)
- Untested major-version jumps. Skipping several minor versions and jumping straight to a major release compounds the risk of every skipped change at once.
- Bad timing. Updating during a traffic spike or a WooCommerce checkout window means any breakage hits real customers.
Leaving updates un-applied is not a safe alternative. Outdated plugins are the single most common entry point in WordPress compromises. Security patches are often included in minor point releases with no fanfare. Falling behind by months turns maintenance into a high-stakes catch-up project rather than routine housekeeping.
Before You Touch Anything: The Pre-Flight Checklist
1. Take a fresh, verified backup
A backup you cannot restore is not a backup. Before any update session, create a complete backup — database and files — and confirm you know the restore steps for your specific host or backup plugin. Most managed hosts (Kinsta, WP Engine, Flywheel) have one-click staging and restore. On shared hosting, a plugin such as UpdraftPlus or All-in-One WP Migration can do the same job. Store the backup somewhere off-site, not just on the same server.
2. Check the WordPress and PHP compatibility table
Before running a core update, visit the WordPress PHP compatibility page and confirm your server's PHP version is still supported. Your host's control panel (cPanel, Plesk, or a custom dashboard) usually shows the active PHP version under "PHP Manager" or similar. If a core update bumps the minimum PHP version above what you're running, update PHP first — or you'll break the site immediately on core update.
3. Check individual plugin changelogs
On the Updates screen in wp-admin, each plugin entry links to its changelog. For any plugin flagged as a major version bump (e.g. 3.x → 4.x), read the changelog before updating. Look for notices like "removes support for X" or "changes database schema." WooCommerce, page builders (Elementor, Divi, Beaver Builder), and form plugins are the most likely candidates for breaking changes.
4. Disable caching before you start
Object caches and full-page caches can serve stale data after an update, making a working site look broken or making a broken site look fine. Purge all caches and temporarily disable full-page caching while you're testing.
5. Schedule a low-traffic window
Check your analytics for your quietest hour — often early morning in your primary audience's time zone. Do all updates then, not at midday Friday.
The Right Update Order
Sequence matters. Here is the order that minimises cascading failures:
- Plugins first. Plugins depend on WordPress core's APIs, but core does not depend on plugins. Updating plugins while still on the current core version means you are not introducing two sets of unknowns at once. Update one plugin at a time if the site is business-critical; use "Update All" only if the site is low-stakes and you have a solid backup.
- Themes second. Your active theme should be updated after plugins because some themes bundle their own plugin-like functionality (sliders, shortcodes, custom post types) and updating the theme before those plugins can create momentary mismatches.
- WordPress core last. Core updates are the most reliable and thoroughly tested updates in the ecosystem, but they also touch the most of the codebase. Doing core last means you are not compounding unknown plugin-change risks with a core change simultaneously.
One-click "Update All" is fine for low-risk sites on a good backup. For sites with WooCommerce, a page builder, a membership system, or a lot of active users, updating individually and testing between each update is worth the extra ten minutes.
Testing After Each Update
Testing does not mean glancing at the homepage and moving on. Run through this checklist after each significant update:
- Homepage loads without errors.
- A representative interior page (blog post, product page, or service page) loads correctly.
- Navigation menus and widgets render as expected.
- Any forms on the site (contact, checkout, login) actually submit successfully.
- The wp-admin dashboard loads and you can edit a post.
- No new entries in your PHP error log (accessible via your host's file manager or an error-logging plugin).
If you have a staging environment, run all updates there first and verify the full checklist before pushing to production. Most managed hosts include staging as standard. On shared hosting, a plugin such as WP Staging can create a local clone.
When Something Does Break
If a single plugin update breaks the site, the fastest fix is usually to roll it back to the previous version. You can do this manually by downloading the older version from the plugin's WordPress.org page and reinstalling it via Plugins → Add New → Upload. Our guide on how to roll back a plugin or theme update walks through each method.
If the site is showing a white screen, a critical error message, or is completely inaccessible after an update, see WordPress site broke after an update for the full recovery sequence. The short version: restore the backup, or deactivate all plugins via FTP/SFTP and reactivate them one by one to find the conflict.
How to Harden the Update Process Long-Term
Use a child theme
If you have any customisations in theme files — even a single CSS tweak — move them to a child theme right now. A parent theme update will overwrite every direct edit, silently and completely. A child theme inherits the parent's styles and templates while keeping your customisations separate and update-safe.
Audit your plugin list annually
Every plugin is a potential update conflict. If a plugin has not been updated by its author in over a year, has fewer than a few hundred active installs, or you are not actively using its features, deactivate and delete it. A leaner plugin list is a more maintainable site.
Enable automatic minor-version core updates, disable major ones
WordPress can be configured to apply security-only minor updates (e.g. 6.5.1 → 6.5.2) automatically, while requiring manual approval for major releases (6.5 → 6.6). This keeps you protected against security patches without surprise major-version changes. Add define( 'WP_AUTO_UPDATE_CORE', 'minor' ); to your wp-config.php file to enable this behaviour. Most reputable managed hosts handle this for you.
Keep a simple update log
A plain text file or a shared spreadsheet noting the date, what was updated, and any issues found is invaluable when debugging problems that surface a week after an update session. You will thank yourself the first time you need it.
When to Call a Professional
Handle updates yourself when you have a recent backup, a staging environment or the confidence to use FTP, and a site where brief downtime would not cause significant financial or reputational damage.
Call in help when:
- The site generates meaningful revenue and you cannot afford an hour of downtime.
- You are running a WooCommerce store and the update touches WooCommerce itself, its payment gateways, or the active theme.
- You have fallen months behind on updates and face a large batch of stacked upgrades.
- The site already broke after an update and you are not sure where to start.
If you are already staring at a broken site, Mend's Emergency Rescue gets a senior engineer on the problem fast — most fixes are resolved the same day, with a plain-English report of exactly what failed and what changed. If the site is still working but you want a professional to run the update session safely, a Quick Fix covers exactly that kind of one-off task at a flat, agreed-up-front price.
For ongoing peace of mind — managed updates, backups, security scanning, and uptime monitoring every month — the Mend Care Plan handles the full update routine so you never have to think about it again.
Updates are not something to fear, but they do reward a little preparation. Back up first, update in the right order, test before you call it done, and you will rarely run into trouble. The sites that break are almost always the ones where someone skipped one of those three steps.
Frequently asked questions
Is it safe to use WordPress's "Update All" button?
For low-stakes sites with a current backup, "Update All" is usually fine. For sites with WooCommerce, a page builder, or a membership system, updating one component at a time and testing between each is safer — it makes it much easier to pinpoint which update caused a problem if something goes wrong.
Do I need to update WordPress core as soon as a new version comes out?
Minor security releases (e.g. 6.5.1 → 6.5.2) should be applied quickly. Major releases (e.g. 6.5 → 6.6) are safe to wait a few days on while the community reports any early bugs, but do not delay more than a week or two without a specific reason.
What should I do if I don't have a staging environment?
At minimum, take a verified full backup before every update session and confirm you know how to restore it on your host. Free or low-cost plugins like WP Staging can create a local copy on shared hosting. Many managed WordPress hosts include staging as a standard feature.
Can I turn off automatic updates to stay in control?
Yes, but you should only disable automatic major-version updates, not minor security patches. Staying on an unpatched version to avoid risk is counterproductive — security vulnerabilities in outdated WordPress installs are actively exploited. Configure WordPress to auto-update minor versions and review major ones manually.