WordPress updates are not one thing, and treating them as one thing is why maintenance either gets skipped or becomes a recurring source of outages. Security patches, minor core releases, major core releases, plugin updates and theme updates carry different urgency and different risk. A workable policy responds to each on its own terms, applies them in an order you control, and can undo any of them. This article sets out that policy and the parts of it people usually miss.
What kinds of updates are there, and how urgent is each?
Five categories, and the distinction between them is the whole answer.
| Update type | Released | Apply within | Testing before applying |
|---|---|---|---|
| Security patch (core) | When a vulnerability is fixed | 24 hours | Smoke test on staging, or accept the automatic update |
| Security patch (plugin or theme) | When a vulnerability is fixed | 24-48 hours | Staging test proportional to what the plugin touches |
| Core minor release | As needed, several times a year | 1 week | Basic functional check |
| Plugin and theme feature updates | Continuously | Scheduled window, monthly is workable | Staging test, verify affected functionality |
| Core major release | Roughly three times a year | 2-6 weeks | Full regression test on staging |
Two clarifications on that table, because the original version of this article got both wrong.
Minor core releases do not follow a monthly schedule. They ship when there is something to fix, which may be twice in a fortnight or not for months. Major releases have historically averaged around three a year, though 2025 ran a reduced schedule before the project returned to three releases in 2026. Plan for the pattern, not for a date.
And a security patch applied in 24 hours is not the same as a security patch applied blindly. On a site with a straightforward configuration, the automatic update is the right answer and testing is a formality. On a platform with payment integrations and custom code, a fast smoke test on staging costs an hour and is worth it. Speed and testing are not in conflict; the test just has to be proportionate.
Which updates should be automatic?
WordPress applies minor core updates automatically by default, and since version 5.5 you can enable automatic updates for individual plugins and themes. Whether you should is a judgment about blast radius.
Reasonable to automate: minor core releases, and plugins that are widely used, actively maintained, and touch nothing critical. If the plugin breaking would produce a cosmetic problem, automation saves more time than it risks.
Do not automate: anything in the payment or checkout path, anything handling authentication or access control, anything you have customised or extended, page builders and form plugins with a history of breaking layouts, and every major core release without exception.
Never automate on a platform where nobody is watching. Automatic updates are only safe when something notices that the site broke. Uptime and transaction monitoring is what makes automation defensible; without it, automation means finding out from a customer.
How do you apply updates without breaking the site?
The sequence matters less than the discipline. Four rules cover most of it.
Back up first, and know the restore works. A backup you have never restored is an assumption. Verify the restore path on staging at least quarterly.
Test on a recent copy of production. Not on a stale staging site from last year. Most conflicts only appear against real data, real content volume and the real plugin set.
Change one thing at a time when the risk is real. Updating fourteen plugins in one click is fine on a brochure site. On a platform with integrations, batching means that when something breaks you have fourteen suspects.
Check compatibility before a major core release, not after. Before moving to a new major version, confirm your critical plugins support it. This is where the old advice to update core first causes trouble: the new core arrives, a plugin has not caught up, and something that worked yesterday does not.
After any update, verify the things that earn money. Checkout, forms, search, login, the templates that carry your traffic. Automated smoke tests are better than a checklist, and a checklist is much better than nothing.
What about the plugins nobody maintains?
This is the part most maintenance articles skip, and it causes more damage than late updates do.
A plugin that has not been updated in two years is not stable. It is unmaintained, and when a vulnerability is found in it, no patch is coming. The same applies to plugins whose author has stopped responding, and to commercial plugins whose licence has lapsed and which therefore no longer receive updates at all.
Review your plugin list twice a year and sort it into three groups. Actively maintained and still needed. Actively maintained but no longer needed, which should be deleted rather than deactivated, because deactivated code still sits on the server. And unmaintained, which needs a replacement plan with a date on it.
That last group is where the work is, and where it gets deferred indefinitely, because replacing a plugin that currently works is a hard thing to prioritise. It is also considerably cheaper than doing it under incident conditions.
What else needs updating besides WordPress?
Three things that fall outside the update screen and get forgotten.
PHP. Running an unsupported PHP version means no security fixes at the language level, and it eventually blocks WordPress and plugin updates too. Plan PHP upgrades deliberately, test them on staging, and treat them with the same care as a major core release.
The database server and the rest of the stack. Usually the host’s responsibility, but only if someone confirms that.
Dependencies in your own code. Custom themes and plugins pull in libraries. Those libraries have vulnerabilities. Managed dependencies with a lockfile and a periodic audit are what turn this from an unknown into a task.
What happens if you leave it?
The risk is not abstract, and it is concentrated in a specific place.
Vulnerability counts across the WordPress ecosystem run into five figures annually and have been rising, with the overwhelming majority found in plugins and themes rather than in core. Attackers scan for known vulnerable versions automatically. The window between a public disclosure and exploitation attempts is frequently measured in days.
The second cost is compounding. Deferred updates do not stay the same size. A site left for a year does not need one update cycle; it needs a migration project, because the changes have to be applied in sequence, conflicts have to be untangled, and some of the plugins involved will have changed substantially or disappeared.
The third cost is the one that gets noticed last. Updates carry performance and compatibility improvements, so a neglected platform gets slower relative to its competitors without anything visibly failing.
When should you not update?
Deliberate freeze windows are part of a mature policy, not a failure of one.
Freeze non-security updates around peak trading: Black Friday, seasonal campaigns, enrolment periods, product launches. Nothing goes to production during the window except security patches, and those get tested properly first.
Freeze when nobody is available to fix a problem. Friday afternoon updates before a long weekend are how minor issues become three-day outages.
Freeze during a migration or major project, so that changes from two sources do not arrive at once.
The point is that the freeze is declared, has an end date, and is followed by a catch-up cycle. An indefinite freeze is not a policy; it is neglect with better vocabulary.
Who does this, in practice?
Update management fails for organisational reasons more often than technical ones. It is nobody’s job, so it happens when somebody remembers, which is usually after something breaks.
Whatever the arrangement, three things need names attached: who runs the update cycle, who verifies the site afterwards, and who is called when something breaks outside working hours.
Our own Growth & Care service is built around that shape. A monthly cycle covering plugins, themes and extensions, verification of key sections after every update, and correction of anything the update broke, with daily backups and monitoring underneath it. Requests run through a service desk with QA before anything reaches production, and response times are set by an agreed SLA rather than by whoever is free. It is deliberately more boring than it sounds, which is the point.
FAQ
How often should WordPress be updated?
Security patches within 24 to 48 hours. Minor core releases within a week. Plugin and theme feature updates in a scheduled window, monthly for most sites. Major core releases after two to six weeks, once compatibility has been confirmed on staging.
Should I enable automatic updates?
For minor core releases, yes. For plugins, selectively: automate the low-risk ones and keep manual control over anything touching payments, authentication, or code you have customised. Automation is only safe if monitoring will tell you when something has broken.
Should I update plugins or core first?
There is no universal order. What matters is confirming that your critical plugins support the new core version before a major update, changing one thing at a time when the stakes are high, and keeping a rollback path. Assuming a fixed order is how sites end up with a plugin that does not work on the version you just installed.
Is it safe to skip a major WordPress version?
You can, but the update still has to happen eventually and each skipped version makes the eventual jump larger and harder to test. Staying one major version behind is a reasonable position. Staying four is a project.
What should I do about a plugin that is no longer maintained?
Treat it as a security liability with a replacement deadline, not as a stable component. Unmaintained code receives no patches, so a vulnerability discovered in it stays open indefinitely. Replacing it while everything works costs far less than replacing it during an incident.
How long does a proper update cycle take?
For a straightforward site, under an hour a month. For a platform with integrations, custom code and a real staging process, several hours monthly, plus additional time for major core releases. The variable is the number of things that have to be verified afterwards, not the number of update buttons.
Updates keep slipping because they are nobody’s job? That is exactly the gap Growth & Care fills. → Talk to us
