Written byRedevon IT TeamManaged Operations
WordPress Maintenance Plan: What It Should Cover
WordPress runs a substantial proportion of the web, and the reasons for that are also the reasons it requires ongoing attention. Its extensibility—tens of thousands of plugins, themes that modify core behaviour, and a permissive architecture that accommodates almost any requirement—is precisely what creates a maintenance obligation that other platforms do not impose to the same degree.
A WordPress maintenance plan is the arrangement under which that obligation is met: a defined schedule of updates, checks, backups and optimisations, performed by someone accountable for the outcome.
The difficulty is that the term covers an unusually wide range of practice. At one end, a scheduled task applies every available update automatically at 3am on a Tuesday and reports success regardless of outcome. At the other, a managed process assesses each update, tests it against a staging environment, and deploys it with a rollback path.
Both are described as WordPress maintenance. This guide sets out what the work actually involves, so the distinction is legible before you commit to a provider.
For what these arrangements typically cost, see our guide to website care plan pricing. For comparing providers, see what to look for in a maintenance package. This article concerns the work itself.
Why WordPress specifically requires this
Three characteristics of the platform account for most of the maintenance burden.
The plugin ecosystem is the primary attack surface. The substantial majority of WordPress security incidents originate not in WordPress core—which is well-maintained and rapidly patched—but in third-party plugins and themes. A typical business installation runs between fifteen and thirty plugins, each maintained by a different developer to a different standard, each an independent point of failure.
Updates interact. WordPress core, the active theme, and every plugin update on independent schedules. Applied individually without validation, conflicts are routine—particularly where a site uses a page builder, custom post types, or a plugin that modifies core behaviour. The failure is frequently not immediate: a conflict may only surface on a specific template, under a specific user role, or at checkout.
The platform accumulates. WordPress databases collect post revisions, expired transients, orphaned metadata, and spam over time. Media libraries grow without pruning. Performance degrades gradually rather than suddenly, which means it is rarely noticed until it has become significant.
None of these is a defect. They are the cost of a platform flexible enough to build almost anything on, and they are entirely manageable—provided someone is managing them.
The maintenance schedule
Substantive WordPress maintenance operates on a cycle rather than a single recurring task. The table below sets out a schedule appropriate to a business-critical installation.
| Frequency | Task | Purpose |
|---|---|---|
| Continuous | Uptime monitoring with alerting | Outages identified by the provider, not reported by customers |
| Continuous | Security and malware scanning | Detection before exploitation |
| Weekly | Review available core, plugin and theme updates | Assessment precedes application—changelogs read, security releases prioritised |
| Weekly | Apply and test updates via staging | The single most consequential task in the schedule |
| Weekly | Verify backup completion | Confirmation that the backup ran, not assumption |
| Weekly | Check for broken links and 404 errors | These accumulate silently as content changes |
| Monthly | Restore test from backup | Backups are only as good as the last verified restore |
| Monthly | Database optimisation | Clear revisions, expired transients, orphaned metadata and spam |
| Monthly | Performance review against baseline | Core Web Vitals and load times tracked as a trend |
| Monthly | Review user accounts and access levels | Dormant administrator accounts are a common exposure |
| Monthly | Form and checkout functional testing | Silent breakage here is expensive and invisible |
| Quarterly | Plugin audit—remove unused, replace abandoned | Fewer plugins is materially safer |
| Quarterly | Security configuration review | File permissions, wp-config hardening and login protection |
| Quarterly | Media library and storage review | Unoptimised images are the most common performance cause |
| Quarterly | Licence renewal check | Lapsed licences stop security updates |
| Annually | PHP version compatibility assessment | Hosts eventually force the upgrade; better to plan it |
| Annually | Full technical audit | Architecture, hosting fit and accumulated technical debt |
A plan that performs only the continuous and weekly items is doing real work. A plan that performs none of the monthly or quarterly items is applying updates, which is a narrower thing than maintenance.
What each area actually involves
Update management
The distinction between a substantive and a nominal plan is almost entirely located here.
Automatic updates are convenient and, for a simple installation with few plugins, often adequate. For a site with commercial dependency, they represent an unmanaged risk: an update that conflicts with a theme customisation will deploy to production and remain broken until someone notices.
Managed updating means reviewing what has changed, prioritising security releases, applying updates to a staging environment as a set, verifying core user journeys, then promoting to production with a rollback path available. It takes longer. It is also the difference between maintenance and automation.
A reasonable middle position—appropriate to many sites—is automatic application of WordPress core security releases, which are narrow and well-tested, with all other updates managed manually. The important point is that this should be a deliberate policy rather than an unexamined default.
Backups
Every plan includes backups. Considerably fewer include verified restoration.
A backup regime that meets a reasonable standard uses automated daily backups of both files and database, stored off-server rather than on the same host, retained on a defined schedule, and—critically—restore-tested at least monthly. Silent backup failure is common enough that discovering it during an incident should be treated as a foreseeable outcome rather than bad luck.
Security
WordPress security is less about a single product and more about accumulated configuration. A maintenance plan should cover:
- Plugin and theme vulnerability monitoring against disclosed CVEs affecting your installed versions
- File permission review
wp-config.phphardening, including disabling in-dashboard file editing- Login protection, attempt limiting and two-factor authentication for administrator accounts
- Regular malware scanning
- Removal of unused plugins and themes, which remain exploitable while installed even when inactive
That last point is frequently overlooked. An inactive plugin is still on the filesystem and still a potential entry point.
Performance
WordPress performance degrades incrementally as content accumulates, plugins are added, and media libraries grow. Maintenance work in this area covers caching configuration, image optimisation and modern format delivery, database query review, and periodic assessment of whether the plugin set has grown beyond what the site needs.
Measurement against a baseline is what makes this meaningful. Without a trend, a site that has become slow appears normal. Our performance and security optimisation service addresses these issues in greater depth.
Database
WordPress writes a considerable amount of data that is never subsequently read. Post revisions accumulate indefinitely by default. Expired transients persist. Deleted plugins routinely leave their options rows behind. Spam comments remain in the database after moderation.
On a content-heavy site this becomes measurable, and monthly optimisation prevents it. This is unglamorous work that no client ever requests and that meaningfully affects performance over years.
PHP compatibility
PHP versions reach end of life on a published schedule, after which they no longer receive security patches. Hosting providers eventually force an upgrade, and where a site's plugins or custom code are incompatible, that upgrade breaks things.
A maintenance plan should track this in advance and remediate on a planned basis, rather than in response to a host-imposed deadline.
WooCommerce and e-commerce considerations
WordPress installations running WooCommerce carry additional requirements, because the cost of failure is direct.
Checkout testing after every update. A checkout that breaks silently costs money for as long as it goes unnoticed. This should be verified after each update cycle rather than assumed.
Payment gateway compatibility. Gateway plugins update independently of WooCommerce and WordPress core, and lag between them is a recurring source of failure.
Database load. WooCommerce writes substantially more data than standard WordPress—orders, sessions, cart data and product metadata. Optimisation matters more, and sooner.
Peak readiness. Where a store has seasonal peaks, capacity should be tested before the peak rather than discovered during it.
Extended transaction retention. Order data carries legal and tax retention obligations that ordinary content does not. Backup retention policy should reflect this.
What neglect actually looks like
Deferred maintenance rarely produces a single dramatic failure. It produces an accumulation, and the accumulation surfaces in a recognisable pattern.
Months one to three. Nothing visible. Updates pending. Backups possibly failing silently.
Months three to six. Performance measurably slower. A plugin conflict has broken something on a page nobody checks regularly. A contact form has stopped delivering, and the absence of enquiries is attributed to market conditions.
Months six to twelve. A disclosed vulnerability in an outdated plugin remains unpatched. PHP approaches end of life. The update backlog has grown large enough that applying it has itself become a risky project.
Beyond twelve months. Updating in place is no longer straightforward, because the accumulated version gap between core, theme and plugins exceeds what can be safely bridged. The realistic options are a substantial remediation project or a rebuild.
The final position is where the cost becomes apparent. Remediating a neglected installation routinely exceeds several years of maintenance, and it arrives as an unplanned capital cost rather than a predictable operating one.
Managing this in-house
Self-management is a legitimate option, particularly where a site is straightforward and someone internal has both the capability and the time.
The practical difficulty is not capability but consistency. Maintenance is easy to defer, produces no visible benefit when performed, and competes for attention with work that has deadlines. The updates that cause problems are disproportionately those that were deferred.
Where maintenance is handled internally, three provisions should be treated as minimum requirements: automated off-server backups with a tested restore process, a scheduled recurring review that is actually honoured, and a staging environment for testing updates before they reach production.
If those three are not realistically sustainable, the question becomes one of cost comparison rather than principle.
Frequently asked questions
Security releases should be applied within days. Other core, plugin and theme updates are commonly handled on a weekly cycle, allowing changes to be assessed and tested together rather than applied piecemeal.
Core security releases are narrow and well-tested, and automatic application is generally reasonable. Automatic updating of all plugins and themes carries more risk because conflicts deploy directly to production without validation. The policy should be a deliberate decision rather than a default.
There is no fixed threshold; quality and maintenance status matter more than count. Every installed plugin should have an identifiable purpose and an actively maintained release history. Unused, abandoned or duplicate plugins should be removed, including inactive ones.
Hosting provides the infrastructure the site runs on. A maintenance plan covers the ongoing work of keeping the WordPress installation functioning correctly. Managed WordPress hosting commonly includes backups and core updates, but rarely extends to plugin conflict management, performance work or functional testing.
Generally not by default. Most plans include a defined allocation of development time for small changes; substantial new functionality is normally quoted separately. Where ongoing development is expected, a managed platform arrangement is usually a better fit.
It continues working, then degrades: pending updates, silent breakage, accumulating vulnerabilities, and eventually an update backlog large enough that resolving it becomes a project in itself. The costs are deferred rather than avoided.
Summary
A WordPress maintenance plan should operate as a schedule rather than a recurring task: continuous monitoring, weekly update management through staging, monthly restore testing and database optimisation, quarterly plugin and security review, and annual compatibility assessment.
The distinction between substantive and nominal provision is located almost entirely in whether updates are validated before deployment and whether backups are ever actually restored. Both are invisible at the point of purchase and decisive during an incident.
Redevon IT has managed WordPress platforms for clients since 2012, including WooCommerce installations with commercial dependency. If you are assessing managed platform operations, or taking on a site that has gone without maintenance, contact us for a review of its current condition.
Journal
