The WordPress Maintenance Jobs That Actually Matter Each Month

Once a month, give the site forty minutes. Apply updates behind a snapshot, confirm last night’s backup exists somewhere off the server, click through the two or three journeys that make you money, check the PHP version against its end-of-support date, and read the error log. That is the whole routine. Everything else sold as WordPress maintenance is either quarterly work or a report nobody reads.

The monthly list, in the order that matters

Order matters because each step changes the risk of the next one. Snapshot before you touch anything, so the rest of the list is reversible. Check the backup before you update, because the moment you want it is five minutes after an update went sideways. Update core, then plugins, then the theme. Then test, then read the logs, then look at speed.

1. Snapshot. Take an image or an on-demand backup and note the time. Ninety seconds.
2. Verify the off-server copy. Confirm the latest backup exists somewhere your hosting account cannot delete, and note its date.
3. Update core, plugins, theme. In that order, reading the changelog for anything that touches payments, forms or the page builder.
4. Walk the money paths. Home page, a form submission, a basket and checkout step, an admin login. Logged out, and on a phone.
5. Read the error log. Not for fun. For the deprecation warnings that tell you what breaks on the next PHP version.
6. Check one performance number. Same page, same tool, every month, recorded in the same note.
7. Write two lines. What you changed and anything that looked odd. Next month’s you will be grateful.

Forty minutes covers that for a site with fifteen plugins. If it regularly takes two hours, the cause is almost always plugin sprawl or a page builder that needs a manual cache rebuild after every update, and both are worth fixing once rather than paying for monthly.

Updates: what to automate and what to watch

Automatic updates are a risk trade, not a best practice, and the honest answer is to split your plugins into two groups. Automate the ones with narrow responsibilities and no custom code around them: SEO plugins, backup plugins, security plugins, utility plugins. Keep manual control over page builders, payment gateways, membership plugins, and anything a developer has hooked into.

The safety net is real but narrower than people assume. WordPress has attempted rollback for failed core auto-updates since version 3.7, and version 6.3 extended the same protection to manual plugin and theme updates: if the update process fails partway, the previous version is restored so the site stays up. What no version of WordPress does is undo an update that installed perfectly and then broke a template, which is the failure mode you will actually meet.

Keep an eye on how often core itself ships. WordPress’s release archive shows 7.0 landing on 20 May 2026 and 7.1 on 19 August 2026, with 7.1.1 on 17 September and 7.1.2 five days later on 22 September. Pairs of releases days apart are normal, and the archive is explicit that only the most recent release in the current branch is actively maintained. A monthly cadence catches those; a quarterly one does not.

The vulnerability picture you are maintaining against

It helps to know the shape of what you are defending against, because it explains why the advice is what it is. Patchstack’s State of WordPress Security in 2026, covering calendar year 2025, counted 11,334 new vulnerabilities across the ecosystem, a 42% increase on the year before. Of those, 4,124 were judged serious enough to need a mitigation rule, and 1,966 carried a high severity score, meaning they were likely targets for automated mass-scale attacks. More high-severity issues were found in that single year than in the previous two combined.

The distribution is the part that should change your behaviour. 91% of the new vulnerabilities were in plugins and 9% in themes. Six were in WordPress core, and the report describes those as low priority. Your core install is not the problem. Your plugin list is.

Two of those figures deserve a second look. Patchstack found 46% of vulnerabilities had no fix from the developer at the point of public disclosure, which means ‘update promptly’ is a necessary habit rather than a sufficient defence. And in two separate penetration tests against popular hosting providers’ security stacks, only 12% of known-exploited WordPress attacks were blocked in the first study and 26% of a broader set in the second. Your host’s firewall is not the layer protecting you.

Then there is timing. The research put the weighted median time to mass exploitation for heavily targeted vulnerabilities at five hours, with roughly half of high-impact vulnerabilities exploited inside 24 hours. If a plugin you use is on that list, a monthly cycle means you may be exposed for weeks. Which is why the monthly routine should be paired with an alert feed for your specific plugin list, so genuinely urgent patches jump the queue.

PHP versions and the date you should have in your diary

PHP support dates are published years in advance and still catch people out, usually because nobody owns the diary entry. Each PHP branch gets two years of active support, then two more years of security fixes only, and then nothing. Here is where the current branches stand according to php.net.

Read that table against your own server and two dates jump out. If you are on PHP 8.2, security support ends on 31 December 2026 and you are running unsupported software in January. If you are on 8.4, active support ends the same day, which is less urgent but worth planning. Either way the move is the same short job: check plugin and theme compatibility, switch the version on staging, read the error log for deprecation warnings, then switch production.

The error log is the free part of this. Deprecation warnings appear months before anything breaks, and they name the file and the line. Ten minutes reading the log each month turns a PHP upgrade from an afternoon of surprises into a change you already know the shape of. If your hosting plan makes the log hard to reach, that is worth knowing before you renew; our guide to hosting types covers which tiers give you that kind of access.

Backups and the restore nobody tests

The monthly backup job is not ‘take a backup’. Your host or your plugin is already doing that. The job is to confirm a copy exists outside your hosting account, and to know its date. Thirty seconds, and it catches the two failure modes that actually happen: a backup plugin that has been silently failing since a PHP upgrade, and an entire backup history that lives on the server it is supposed to protect.

Once a quarter, restore one. Pull last night’s backup onto staging and time it end to end. The first attempt usually surfaces something specific and fixable: an uploads folder that was never in scope, a hard-coded domain in the database, a missing database user. After that, you know your real recovery time instead of guessing it, and that number is what you should be quoting to anybody who asks how protected the site is.

Performance drift, and how to notice it early

Sites get slower by accident, one plugin at a time, and the only reliable way to notice is a single number recorded monthly. Pick one page, pick one field-data tool, and write the result in the same note each month. When the number moves, you will know which month’s changes to look at, which is a far shorter investigation than starting from scratch six months later.

The scale of what you are watching for: the 2025 Web Almanac put 48% of mobile sites and 56% of desktop sites in the good band for all three Core Web Vitals, and 44% of mobile sites in the good band for time to first byte, meaning under 0.8 seconds. A WordPress site with sensible caching should sit comfortably on the right side of both. If yours does not, our piece on why website speed matters sets out which fixes move the field numbers and which only move the lab score.

Page builders are the usual culprit, and the 2025 Web Almanac’s CMS chapter gives a sense of how widespread they are: it estimates around 60% of WordPress sites use one, with Elementor the largest at roughly 43% of builder usage on mobile, down from about 56% the year before, the native Block Editor at around 18%, WPBakery at 13% and Divi at 10%. The chapter is blunt that builders tend to produce more complex markup and larger CSS and JavaScript payloads, and that performance variance across WordPress sites is driven more by configuration than by core.

Quarterly jobs that masquerade as monthly ones

Some jobs get sold monthly and only need doing a few times a year. Treating them as quarterly is how you keep the monthly list to forty minutes.

The plugin audit is the one with the best return. For each plugin, ask what would break if it were gone, when it was last updated, and whether a core feature now covers it. Patchstack’s research found premium and freemium components made up 1,983 of its valid vulnerability reports, 29% of the total, and that 76% of the issues found in premium components were exploitable in real attacks, with three times more known-exploited vulnerabilities than in free components. Paying for a plugin does not make it safer; it mostly makes it less studied.

What to stop doing

Three things routinely appear on maintenance invoices and are close to worthless. Monthly database optimisation on a small site, which reclaims a few megabytes and occasionally breaks a plugin’s stored settings. Monthly malware scans from a plugin that only checks file hashes, which the 2026 research describes being routinely evaded by malware that injects code into legitimate core and plugin files rather than adding its own. And the automated PDF report with twelve green ticks, which nobody opens and which tells you nothing you would not learn by loading the home page.

Replace all three with the things on the short list. If you are paying somebody for maintenance, ask them for two specific items: the date of the last successful restore test, and the current PHP version with its end-of-support date. Both answers are one line long, and a provider who cannot produce them is selling you reports rather than maintenance.

Eudora Technology runs this routine remotely for clients in Europe, the Middle East, Asia, Africa and the Americas, including the unglamorous parts: reading error logs, arguing for fewer plugins, and testing a restore before anybody needs it. Our web development and hosting page sets out what is included and what we report back. If you also want the checks that matter on small screens, the mobile-first design guide covers what to click through after each update.

If nobody has opened your site’s error log this year and you are not sure what PHP version it runs on, we can do the first month with you and leave you the checklist. Get in touch with Eudora Technology to talk about your project.