Start here
Why a launched site does not stay finished
WordPress core, the theme and every plugin on a site are written and versioned independently. Each one ships on its own schedule, set by its own author, with no coordination between them.
Core itself changed pace recently. As WordPress explained in A new cadence for WordPress core: “Starting in 2025, WordPress will move to a single major release per year, with WordPress 6.8 ‘Cecil’ marking the final major release for the calendar year.” The stated reason is “the energy and resources being diverted due to ongoing legal matters,” and the post frames the change as reversible: “If those lawsuits are dropped or resolved, we’ll revisit this cadence and strongly consider returning to a three-releases-per-year schedule.” Before this, the core release cycle handbook targeted roughly one major release every four months, alongside security and maintenance point releases as needed.
Plugins and themes follow no such pattern. Some ship weekly. Others go years without a touch. When a vulnerability is disclosed in any one component, the patch that fixes it applies to that component alone. A fix sitting on the plugin author’s server does nothing for a site running the version from before the fix existed, because nobody there applied it.
What actually breaks a site without upkeep
Two failure modes account for most of what goes wrong on a site nobody maintains.
The first is an unpatched security hole: a vulnerability gets disclosed, a patch exists, and the site never receives it. The second is a compatibility break: one component updates, another doesn’t, and the two stop working together. Neither requires an attacker with unusual skill or a site with unusual traffic. Both just require time passing with nobody checking.
Where the vulnerabilities actually concentrate, from Patchstack’s tracking of the first six months of 2025:
| Component | Count | Share |
|---|---|---|
| Plugins | 3,044 | 89% |
| Themes | 386 | 11% |
| Core | 1 | — |
Source: Patchstack, first six months of 2025. Vendor-tracked figure, not an independent industry consensus.
Across the ecosystem, 6,700 new vulnerabilities were identified in that period, and 57.6% required no authentication to exploit.
Patchstack is a commercial vulnerability-disclosure vendor, not a neutral industry body, and there is no independent figure to cross-check these numbers against. Read them as what one vendor’s tracking shows, not as an industry consensus. Even with that caveat, the shape of the finding matches the mechanism above: plugins carry almost all of the disclosed risk, because there are far more of them, written by far more separate authors, patched on far more separate schedules than core ever has to coordinate.
Does a small brochure site really need this
Not every site carries the same exposure. A low-traffic site with minimal plugins, no forms handling sensitive data and no e-commerce carries meaningfully lower risk than one running a checkout or a client portal. For that specific case, manual, infrequent, self-managed updates can be an adequate, honest answer.
A reasoning aid, not a scored model. The two variables and the direction each pushes, with no weighting between them.
The practical test is to count the active pieces of software: WordPress core, the theme, and each plugin. Then ask whether any of them touch money, personal data or file uploads. More components and more of that kind of data both push the case for ongoing maintenance further from optional.
What a security plugin or auto-updates alone still miss
A security plugin can scan for known threats and, in some cases, keep itself current. It does not update the other plugins running on the site, and it does not create an off-site backup unless someone configures that separately.
Turning on automatic updates for everything closes the patching gap, but not the compatibility gap. WordPress can apply some updates in the background, but plugins and themes generally are not auto-updated by default, and even where an update applies cleanly, it can still break a specific plugin and theme combination on your site. An unattended auto-update with no rollback path is itself a known way sites go down, which is a large part of why staging and a tested rollback exist as a step rather than a single button. See how NoDrama tests an update before it goes live.
What monthly maintenance actually has to cover
Three things, and none of them substitute for the others.
Backups
A real backup covers the database and the file system together, on a schedule tight enough that the restore point is actually usable, stored off the live server. A copy that lives on the same server as the site it protects is not a backup for the case where that server is the problem.
Check that your backup destination is off-site, not a folder on the same host.
Update testing
Update testing happens on a staging copy before anything reaches the live site, with a rollback path ready if the update still breaks something once it is live.
After an update, check the specific pages and forms that depend on the updated plugin, not just that the site loads.
Monitoring
Monitoring detects an outage: a site that stopped responding. It does not detect a slow, still-running compromise, and it is not a substitute for patching. It is a detection layer sitting alongside the other two, not a replacement for either.
What this guide does not solve
This guide does not tell you whether your specific site has already been compromised. That takes a scan of the actual site, not an article about sites in general.
It also does not hand you a fixed WordPress-specific number for how often maintenance has to run. The honest answer is “as often as the software underneath keeps shipping updates,” which is continuous rather than a fixed monthly figure, even though most care plans, NoDrama’s included, bill on a monthly cycle.
NoDrama’s care plans cover backups, tested updates and monitoring at three levels of depth.
Conclusion
For most sites running more than a handful of plugins, or handling payments, personal data or file uploads, the answer is yes: ongoing maintenance is not optional, because core, the theme and every plugin keep shipping updates on their own schedules whether or not anyone applies them, and plugins in particular carry the overwhelming share of the disclosed vulnerabilities in the ecosystem. The honest exception is narrow. A near-static brochure site with almost no plugins and nothing touching money or personal data can get by on manual, infrequent, self-managed updates. Everything past that point is a question of how many moving pieces are running and what they touch, not whether WordPress as a platform is somehow dangerous on its own.