WordPress Care Plans: What Maintenance Should Cover Beyond Updates

Ask most website providers what their maintenance covers and the first answer is usually the same: “we keep WordPress and the plugins updated.” Updates matter. But a company website is a sales tool that has to stay online, stay clean, deliver every inquiry and report what it produces. Updating plugins covers only a small part of that, and the published vulnerability data shows it is not even enough to keep the site secure.

This guide sets out what a WordPress maintenance plan should cover beyond updates, how to tell a real care plan from a monthly “update and invoice” routine, and the questions to settle before you sign one.

Why “we update plugins” is not a care plan

Patchstack, a WordPress security vendor, publishes an annual report on vulnerabilities in the WordPress ecosystem. These are vendor figures drawn from its own database and research programme, so read them as one well-documented source rather than an industry census. Even so, the direction is clear.

• In its State of WordPress Security in 2025 (updated March 2025), Patchstack counted 7,966 new vulnerabilities found in 2024. It said 96% were in plugins and 4% in themes, with only seven in WordPress core, and that 33% were not fixed in time for public disclosure.
• Its newer State of WordPress Security in 2026 (updated February 2026) reports 11,334 new vulnerabilities in 2025, a 42% rise on 2024. By Patchstack’s count, plugins accounted for 91% and themes for 9%, and core had six, all low priority. The report also says 46% of vulnerabilities did not receive a fix from the developer in time for public disclosure.
• The same 2026 report puts the median time to mass exploitation for heavily exploited vulnerabilities at five hours, and estimates that roughly half of high-impact vulnerabilities are exploited within 24 hours.

Put those numbers together and the weakness of an update-only plan is obvious. If almost half of new vulnerabilities have no patch when they become public, there is nothing to update to. If attacks begin within hours, a provider who logs in once a month to click “update all” is weeks behind. Patchstack’s own conclusion in the 2026 report is that website owners cannot rely on plugin updates as a security measure. Bear in mind that Patchstack sells vulnerability mitigation, so it has an interest in that conclusion; the underlying point about unpatched flaws still stands.

Two further points from the data are relevant to company sites. First, the 2026 report says premium or freemium components made up 29% of the valid vulnerability reports Patchstack received, so paying for a plugin is no guarantee it is safer. Second, in Patchstack’s own 2025 penetration tests of common hosting-level defences, those defences blocked only 12% of attacks against WordPress-specific vulnerabilities. “Our host handles security” is not a plan either.

What a WordPress maintenance plan should actually cover

A useful way to judge any website maintenance service is to ask what it protects: the site’s security, its availability, the inquiries it generates, and your ability to recover when something breaks. The table below is our suggested baseline for a corporate or B2B WordPress site. It is editorial advice, not a formal standard, so adjust it to the size and risk of your site.

Each of these is worth a closer look.

Security: from updating to managing vulnerabilities

Keep the boring baseline in place

WordPress already does part of the work. Its upgrade documentation says existing installations receive minor core updates, such as maintenance and security releases, by default, and translation files are also auto-updated; it strongly discourages switching these off. Since WordPress 5.5, administrators can enable automatic updates plugin by plugin and theme by theme, and WordPress runs those auto-updates twice a day by default. A care plan should state which components update automatically and which are held back for testing, and why.

The WordPress hardening guide adds the rest of the baseline: delete plugins you do not use, use strong passwords, enable two-step authentication, lock down file permissions as far as possible, and treat intrusion detection and monitoring as very important. None of this is advanced. It is simply often skipped.

Plan for the vulnerability with no patch

This is where a real plan differs from a routine. The provider should hold an inventory of every plugin and theme on your site and watch disclosures for those exact components. When a serious vulnerability is published without a fix, the plan should say what happens: disable or replace the plugin, apply a virtual patch or firewall rule if your setup supports it, or restrict the affected feature until a fix ships. Patchstack’s 2026 report recommends automated measures that can mitigate new vulnerabilities in less than five hours, and says the first 24 hours after an exploitable vulnerability is published are critical.

A short plugin list makes all of this easier. Every plugin you remove is one less thing to monitor, update and test.

Backups you have actually restored

Almost every plan promises backups. Far fewer can show that a backup has been restored successfully. WordPress’s own backup guidance sets the minimum: a full backup needs both the files and the database, because you need both to restore a typical WordPress site. It suggests backing up roughly weekly for low-activity sites and daily for busy ones, always before an upgrade, keeping at least three to five recent backups, and storing copies in different places rather than only on the hosting server.

WordPress’s guidance does not set a schedule for test restores, but we recommend that a care plan go one step further and test them. Restoring a recent backup to a staging environment at least once a quarter, and recording the result, answers the only question that matters in an incident: how long until the site is back, and from which date? If a provider cannot tell you when they last restored your site from a backup, assume nobody knows whether the backups work.

Monitoring, hosting and the checks that protect revenue

Monitor the things that fail quietly

Many website problems are invisible to the people who own the site. Google notes in its guidance for hacked sites that hacks are often invisible to users yet remain harmful to anyone viewing the page. A plan should therefore include uptime monitoring with alerts to a person, SSL certificate and domain expiry reminders, malware and file-change scanning, and a connected Search Console Security issues report, which lists hacked content, malware and social engineering that Google has detected on the site. Our technical SEO audit checklist covers the rest of Search Console worth watching.

Keep the server software current

Maintenance is not only inside WordPress. The WordPress requirements page recommends PHP 8.3 or greater and MySQL 8.0 or MariaDB 10.11 or greater, and warns that older releases have reached end of life and may expose the site to security vulnerabilities. According to php.net, PHP 8.2 receives security fixes only until 31 December 2026. If your site runs on 8.2 or older, the plan should include a tested move to a supported version, not just a note in a report.

Test the inquiry path every month

For a B2B company, the most expensive website failure is often not a hack. It is a quotation form that stopped sending email after an update, a WhatsApp button pointing to an old number, or a tracking tag that disappeared, so ad platforms stop receiving conversions and campaigns optimise on nothing. A care plan should include a monthly test (the same checks appear in our B2B website checklist): submit every form, confirm the email arrives in the right inbox, click every call and WhatsApp link, and confirm the key events still record in analytics. Our guide to GA4 key events for lead tracking explains what those events should be.

Response time, content changes and who owns what

The parts of a plan that matter most in a bad week are the ones written least clearly. Before signing, get these in writing:

1. A named response time. How quickly will someone start work if the site is down or hacked, and does that apply at weekends and during Ramadan or Eid holidays? “As soon as possible” is not a response time.
2. What an incident includes. Is malware clean-up covered, or billed separately? Does the plan include finding how the attacker got in, not only removing the visible damage? Google’s hacked-site guidance includes identifying the vulnerability as a step in its own right, and the Search Console Help page says fixing the issue on just some pages will not earn a partial return to search results.
3. The content allowance. Define what counts as a content update, such as text and image edits, a new service page, or a product added to a catalogue, and how requests are sent and confirmed.
4. Ownership and access. The domain, hosting account, WordPress administrator access, licence keys for premium plugins and the backups should be in the company’s name or available to it. If the relationship ends, you should be able to hand everything to a new provider in a day; our guide to choosing a web design company lists the ownership terms to agree at the start.
5. Reporting. A short monthly report should list updates applied, vulnerabilities found and how they were handled, backup and restore status, uptime, form test results and changes made. If a report only says “all plugins updated”, you are paying for one line of the table above.

If the site is already hacked

A WordPress hacked site recovery is easier with a plan. Google’s hacked-site guidance groups the work into four stages: quarantine the site, identify the vulnerability, clean and maintain the site, and request a review. In practice, the order below is the one most experienced teams follow, though the details depend on the site and the attack. Put a maintenance page up or take the site offline so visitors are not exposed. Change every password: WordPress users, hosting, database, FTP or SFTP, and email accounts linked to the site. Check the Search Console Security issues report to see what Google has detected. Restore from a backup taken before the compromise if you have one you trust, then update everything and remove anything unused. Find and close the way in; otherwise the attacker will return. Only when the whole site is clean should you request a review in Search Console; Google asks that the request explain the issue, the steps taken to fix it and the outcome.

After recovery is the right moment to put a proper care plan in place, while the cost of not having one is still fresh.

At RX Designer, care and maintenance is part of our website design service, and examples of our website work are on our websites page. Whoever runs your site, judge the plan against the table above, not against how often someone clicks “update”.