Twelve components, grouped by what they actually protect. A provider that cannot walk through each of these in plain language is probably selling automation, not management.
1. Controlled updates, tested before they ship
“Update everything immediately” is not a maintenance strategy, it is a way to find out what breaks in production. A solid process backs up the site first, checks release notes for known conflicts, stages higher-risk changes before they touch the live site, and then actually tests the result: homepage and landing pages, navigation, forms, logins, checkout or donation flows, Tag Manager containers, and any connected third-party service. An update that finishes without an error message can still quietly break styling, tracking, or a form nobody notices is broken until a lead goes missing.
Server compatibility belongs in this same conversation. As of 2026, WordPress recommends {PHP 8.3 or newer, along with MariaDB 10.11+ or MySQL 8.0+|https://wordpress.org/about/requirements/}, and HTTPS on every install. A plan worth paying for checks theme and plugin compatibility before touching PHP or database versions, rather than treating the server as invisible plumbing underneath the parts people actually look at.
2. Off-site backups that have actually been restored
A backup plan needs a defined frequency, off-site storage separate from the live server, retention, and someone with the authority to approve a restore. Frequency should track how often the site changes; a busy store loses more in an hour than a static brochure site does in a week.
Running a website without a backup is a bit like riding a motorcycle without a helmet. Everything is fine until you hit a bump.
The part most plans skip is proof. A backup that has never been restored is a green checkmark, not a recovery system. A restore test confirms the archive is complete, the credentials still work, the database imports cleanly, and the site can actually come back within a realistic window, before an emergency is the first time anyone finds out otherwise.
3. Security hardening and monitoring someone actually reviews
Patchstack’s 2026 State of WordPress Security report recorded 11,334 new vulnerabilities across the WordPress ecosystem in 2025, a 42 percent increase over the year before, with more high-severity vulnerabilities found that year than in the previous two years combined. Most of that risk sits in themes and plugins built by independent vendors, not WordPress core, which is exactly why plugin selection and vulnerability response need to be ongoing work rather than an annual cleanup.
To truly secure WordPress websites, we need to look deeper than ever before. We need to cover custom-coded plugins, have deep visibility into the JavaScript and PHP packages being used, and more.
That is Oliver Sild, CEO of Patchstack, and it points at the real question to ask a provider: what happens after an alert fires? Is cleanup included, or quoted separately once the damage is done? “We scan the site” and “we manage the incident” are different promises, and a lot of plans only make the first one.
4. Uptime, SSL, domain, and infrastructure monitoring
A plan should watch more than whether the homepage loads. That includes SSL certificate validity, domain renewal dates, DNS changes, storage and server capacity, CDN and caching availability, and recurring PHP or server errors, with alerts reaching a person who can act on them rather than an inbox nobody checks. No Panic Design’s own hosting stack runs on LiteSpeed servers, NVMe cloud storage, and the QUIC.Cloud CDN, because infrastructure is exactly where slow, invisible failures start.
5. Functional testing for forms, payments, and integrations
Forms can look perfectly healthy while notifications quietly stop arriving. Payment, donation, booking, and CRM connections can fail the same way, usually when a credential expires or an update introduces a conflict nobody was watching for. A maintenance plan should list the journeys that actually matter to the business and test them on a schedule, not run a generic scan and call it done. If email deliverability is part of that picture, No Panic Design’s guide to setting up Amazon SES covers why sending infrastructure needs its own configuration and its own testing.
6. Performance and Core Web Vitals
[P] Performance work does not end at launch. New images, fonts, plugins, and third-party embeds change how a site behaves over time. Google’s current thresholds for a “good” experience are a Largest Contentful Paint within 2.5 seconds, an Interaction to Next Paint under 200 milliseconds, and a Cumulative Layout Shift under 0.1, and a maintenance plan should be checking real-user data against those numbers, not just running a lab test once a year and moving on.
7. Search visibility and technical SEO health
Maintenance will not replace a search strategy, but it protects the technical ground that strategy stands on: indexability, canonical URLs, sitemap accuracy, broken links, redirect chains, and Search Console warnings. Google Site Kit keeps Search Console and Analytics visible directly in the WordPress dashboard, which makes this kind of drift easier to catch before it costs traffic. A good provider also flags the content-level drift that technical checks miss, outdated year references, expired offers, pages quietly competing against each other for the same search intent.
8. Database, media, and software housekeeping
Routine cleanup removes what no longer earns its place, unused plugins and themes, expired admin accounts, spam comments, oversized logs, abandoned media, without turning that cleanup into a risky automated purge. WordPress Site Health is a reasonable diagnostic starting point, but it still needs a person behind it. An inactive plugin might be safe to remove, or it might be sitting there for a seasonal campaign that starts next month. Someone needs to know which.
9. Content accuracy and accessibility upkeep
Code can be current while content quietly goes stale, staff bios, service descriptions, dates, downloadable documents. A complete plan defines who owns those reviews. It also includes basic accessibility regression checks when templates change, keyboard navigation, visible focus states, heading structure, alt text, since a redesign or plugin update can undo accessibility work just as easily as it can undo styling. To be direct about scope: supporting accessibility best practices is not the same as certifying WCAG or ADA compliance, and a plan that promises the latter without a dedicated audit is overselling itself. If accessibility compliance is a hard requirement for your organization, that needs to be scoped explicitly with a specialist, not assumed as a side effect of routine maintenance.
10. Privacy and consent accuracy
[P] New forms, pixels, embeds, and vendors can quietly change what data a site collects, which means privacy and consent tooling needs the same ongoing attention as everything else on this list rather than a one-time setup. A lawyer-drafted privacy policy covers the policy document itself, but it does not cover the cookie consent modal or scan that actually enforces it, and that gap catches more organizations than expect it to. No Panic Design’s guide to website privacy policy requirements covers why those policies need to reflect what a site is actually doing, not what it was doing at launch. No Panic Design is a certified reseller of Termageddon for clients who want policies and cookie consent handled directly; ask us about it (if that is not already part of your plan).
11. Ownership records and account access
A technically healthy site can still become a business problem if the domain sits in a former contractor’s account or nobody remembers who receives the renewal notices. A maintenance provider should maintain a working inventory of WordPress core, theme, plugins, hosting, DNS, domain registration, SSL, and premium licenses, along with who controls each one and where recovery access lives. This is the map that makes every other item on this list possible to act on quickly.
12. Reporting, response windows, and a documented incident process
The plan should say, in writing, who can request work, how requests come in, what qualifies as an emergency, and what falls outside the retainer. It should distinguish maintenance from new development; replacing a form that broke after an update is not the same job as building a new workflow. A useful report explains what changed and why it matters, not just how many plugins got updated this month. And if the worst happens, the plan should already say what comes next: verify, contain, restore, patch the cause, and confirm nothing recurs. A scan alert with no investigation attached is monitoring. It is not incident response.
