WordPress Maintenance: What Actually Needs Doing

Website maintenance is one of those line items that looks optional right up until the moment it very obviously was not. The sites I am asked to rescue are almost never victims of anything sophisticated. They ran outdated software for a year, something automated found them, and nobody had a recent backup.

This is what maintenance actually involves, how often each task genuinely needs doing, and — the part most guides skip — which of it you can handle yourself and which needs a developer.

The short answer

Keep WordPress core, plugins and themes current; hold verified off-site backups you have actually tested restoring; monitor uptime and security; and review performance, links and search data on a regular cycle. Most of it is routine and much of it you can own. The parts that need a developer are the ones where a mistake is expensive to undo.

Why this matters more than it sounds

Three things degrade a WordPress site left alone.

Security drift. Vulnerabilities in popular plugins become public knowledge, and automated scanning finds unpatched sites quickly. This is not about being targeted; it is about being reachable.

Breakage. Plugins update independently. Left long enough, the gap between components grows until an update that should have been routine breaks something.

Quiet decay. A contact form stops delivering. A certificate lapses. An image-heavy page gets slower each time content is added. Nobody notices, because nobody is looking — and a contact form silently failing for three months is a genuinely expensive problem.

A realistic maintenance schedule

Updates

WordPress core

Minor releases are usually security and maintenance fixes and should be applied promptly — most installations handle these automatically, which is correct. Major releases deserve a staging test first, particularly on a site with a page builder and a meaningful plugin list.

Plugins

The largest ongoing risk and the most frequent task. Security releases should be applied quickly. Feature releases can wait for your regular window. Update in small batches rather than clicking "update all" — if something breaks, you want to know what caused it.

Themes

Less frequent, but a customised theme updated carelessly can lose those customisations. If a theme has been modified directly rather than through a child theme, updating will overwrite the work. That is worth establishing before you press the button, not after.

Elementor and Elementor Pro

Keep the free and Pro versions in step — mismatched versions are a common source of odd behaviour. Pro also requires a valid licence to receive updates, so an expired licence quietly means an unpatched component. Because Elementor is responsible for how pages render, test a major update on staging before applying it to a live site.

Backups

The one thing that turns a disaster into an inconvenience. Requirements:

• Automated — anything manual eventually stops happening.
• Off-site — a backup on the same server is not a backup if the server is the problem.
• Complete — database and files. Either alone is not a restorable site.
• Retained — several versions, because a problem discovered on Friday may have started on Monday.
• Tested — an untested backup is a hypothesis. Restore one to a staging site annually and confirm it actually works.

Security monitoring

Beyond staying current: enforce strong passwords and two-factor authentication on administrator accounts, limit login attempts, keep the number of administrators small, and review user accounts periodically — old accounts for people who left are a standing risk.

File integrity monitoring will tell you if something changed unexpectedly, which is usually how a compromise is detected. And remove abandoned plugins entirely; a plugin that has not been updated in years is a liability whether or not it is active.

Broken links and forms

Links rot. External sites move, internal pages get renamed, and each broken link is a visitor hitting a dead end. A quarterly crawl catches them.

Forms deserve their own attention because they fail silently. A deliverability change, an expired API key or a plugin conflict can stop submissions without any visible error. Submit a real test through every form monthly and confirm it arrives. This is the single highest-value thing a client can own, and it takes two minutes.

SSL and certificates

Most certificates renew automatically, but automation fails occasionally and an expired certificate produces a browser warning that stops visitors instantly. Monitor the expiry date rather than assuming. Also check for mixed content — a page served over HTTPS that loads an image over HTTP will show as insecure.

Performance

Sites get slower gradually: images added at full resolution, a plugin here, a tracking script there. Reviewing quarterly catches drift before it becomes a rebuild.

Check field data rather than only a one-off lab score — how the site performs for real visitors at the 75th percentile is what matters. The detail is in Core Web Vitals explained, and if you are on a builder, how to keep an Elementor website fast covers the specifics.

Database cleanup

WordPress accumulates post revisions, spam comments, transients and orphaned metadata from removed plugins. On a busy site this adds up. Cleaning twice a year is sufficient.

Two cautions: take a backup first, and be conservative with optimisation plugins that offer to delete broadly. Losing revisions of an important page is an annoying way to save a few megabytes.

Uptime monitoring

Automated monitoring that alerts you when the site stops responding. Without it, the first report typically comes from a customer, which is both slower and more embarrassing. Set it up once and it runs itself.

Analytics, Search Console and SEO monitoring

Analytics tells you what visitors did; Search Console tells you what Google sees. Both need occasional attention or they quietly stop being useful.

Monthly, check that analytics is still recording (tracking codes get lost during redesigns more often than you would expect), and review Search Console for indexing problems, manual actions and coverage changes. If pages have dropped out of the index, you want to know in weeks rather than at the next annual review. What to look for is covered in the technical SEO checklist.

Staging and testing

A staging site is a copy where changes can be tested before they reach visitors. Any site where downtime costs money should have one.

Use it for major core updates, Elementor major versions, new plugins, theme changes and anything structural. It converts "we think this will be fine" into "we checked".

Signs a site is not being maintained

If you have inherited a site, or are not sure whether whoever built it is still looking after it, these are the tells. Any two of them together usually means nobody is.

• The WordPress admin shows a stack of pending updates. The clearest single signal, and the easiest to check.
• Plugins listed as untested with your WordPress version, or last updated several years ago.
• Nobody can tell you where the backups are, or when one was last restored successfully.
• The contact form has not been tested since launch. Send one and see.
• PHP version is well behind current. Old PHP versions stop receiving security fixes.
• Admin accounts belong to people who left.
• No staging site exists, so every change has been made directly on production.
• Search Console is either unverified or nobody has opened it in a year.

None of these are catastrophic on their own. Together they describe a site running on borrowed time.

What a maintenance arrangement should actually include

Maintenance is sold in wildly varying forms, and "we keep your site updated" can mean anything from an automated plugin to genuine oversight. Worth establishing before you sign anything:

• What is updated, how often, and is it tested first — or applied straight to the live site and hoped for?
• Where backups are stored, how many are retained, and has a restore been tested?
• What the response is if the site goes down, and within what timeframe.
• Whether monitoring is in place, or whether you are the monitoring.
• How much content-change time is included, and what happens beyond it.
• Who holds the hosting, domain and licence accounts. They should be in your name, with the developer given access — not the other way round.
• What happens if the arrangement ends — you should be able to walk away with everything.

That last pair matters more than the monthly figure. A cheap arrangement where someone else owns your domain is not cheap.

What you can own, and what needs a developer

Genuinely client-manageable: monthly form tests, keeping content current, resizing images before upload, not installing plugins casually, reviewing user accounts, watching Search Console, and reporting anything that looks wrong. On a well-built Elementor Pro site this extends to all the routine content work — pages, text, images, sections, menus, posts.

Worth a developer: update strategy and execution, backup configuration and restore testing, security hardening and incident response, performance diagnosis, database maintenance, staging management, and anything where a mistake means downtime. That is the division I aim for on every WordPress build — you own the content, I own the things that are expensive to get wrong.

Key takeaways

• Most compromised WordPress sites were simply running outdated software.
• An untested backup is not a backup.
• Forms fail silently — test them monthly, it takes two minutes.
• Performance degrades gradually; review quarterly rather than waiting for complaints.
• Update in small batches so you know what caused a problem.
• Budget for the year after launch, not just the launch.

Where to go next

If you are not sure what state your site is in, the fastest useful check is: when was the last update applied, when was a backup last restored successfully, and does the contact form still deliver? Those three answers usually tell you everything.

You can read more about how I build sites to be maintainable under WordPress development, or get in touch if you would like an existing site reviewed.