Website Maintenance: Four Jobs and Who Does Each

Four jobs with four owners. Most retainers quietly cover two.

Search "website maintenance" and you get feature lists. Plugin updates, uptime monitoring, malware scanning, "unlimited small edits".

Those are products, not a plan.

We do not sell a maintenance retainer, which makes this easier to write honestly. Below is what has to happen, how often, who should do it, and what you can handle yourself. Our SEO guide hub covers the underlying mechanics.

Three of the four announce themselves when they fail — a hacked site, a slow page, a wrong phone number. The fourth does not, and by the time traffic drops the cause is six deployments back.

Website maintenance is four jobs, not one

Each has a different failure mode, frequency and owner. Treating them as one invoice line is why maintenance drifts into "we updated your plugins" reports.

Most retainers sell the first, bundle some of the second, assume you handle the third, and never touch the fourth — the one that costs traffic.

The actual maintenance schedule

This is the table to screenshot. The frequencies suit a site publishing a few times a month; a busy store needs the weekly items without exception.

The weekly twenty-minute check you can do yourself

Nothing here needs code or a server login. It catches the failures that cost you money this week.

1. Open the site on your phone, on mobile data — not office wifi. If it feels slow to you, it is slow to everyone.
2. Submit a real enquiry from an address that is not yours. Forms break silently after plugin and SMTP changes.
3. Check it arrived in both places — inbox and CRM. One without the other is the failure you find a month late.
4. Read your five busiest pages: prices, offers, phone number, address, and any year in the copy.
5. Open Search Console and look only at what changed — new errors in the Page indexing report, anything under Security & Manual Actions. Our Search Console guide covers the monthly read.
6. Glance at the backup log: a file exists, dated yesterday, of a plausible size.

Put it in the calendar on a fixed day. Maintenance that depends on remembering stops in month three.

The monthly and quarterly jobs that need someone technical

Updates are not risky because updating is hard. They are risky because nobody tested the site afterwards.

• Updates, on staging first. Since WordPress 5.6, new installations auto-update for both minor and major core releases, while plugins and themes auto-update only in special cases set by the WordPress.org API for critical vulnerabilities (Updating WordPress — last updated 1 July 2026). On an existing site, plugin updates are a decision somebody makes.
• Plugin pruning. Every plugin is code you did not write, running on every request. The question is not "is it broken" but "is anything still using it".
• Page weight. Adding a script takes five minutes; removing one takes a decision. If nobody can name the report a tag feeds, it goes — our page speed optimisation post has the fixes.
• Backups with both halves. The database holds posts and comments; the files hold core, plugins, themes and uploads. They need separate processes, because the database lives outside the WordPress directory (WordPress Backups — last updated 4 June 2026).

The annual jobs that are cheap to do and expensive to miss

Five items, once a year, each under a day, each of which has taken a site offline for somebody.

• Domain renewal. Expiry date, auto-renew on, registrar contact address somebody still reads. A renewal notice sent to a developer who left in 2023 is the most avoidable outage going.
• Certificate renewal, on a shorter leash than you think. The CA/Browser Forum's TLS Baseline Requirements cap certificate validity at 200 days from 15 March 2026, 100 days from 15 March 2027 and 47 days from 15 March 2029 (version 2.3.1, 4 October 2026). Manual renewal is finished; check annually that automated renewal exists and has fired.
• Licence renewals. An expired plugin or theme licence rarely breaks the site — it quietly stops delivering updates, turning a security job into a security problem.
• A real restore test. "Backups are running" is not the claim that matters; "we restored last week's backup into a clean environment and the site came up" is. WordPress's guidance agrees: back up your automatic backups manually now and then to confirm the process works.
• An accessibility pass. WCAG 2.2 has been a W3C Recommendation since 12 December 2024 and is the version to test against. It is the job that catches a theme update breaking keyboard navigation.

The SEO plumbing that decays silently

This is the section the other maintenance pages do not have. Six things break with no visible symptom. Each has a specific way to detect it.

Internal links pointing at pages you deleted

You retire a service page; eleven others still link to it, so link equity stops reaching the replacement. Detect it with a monthly crawl filtered to internal links returning 404. Search Console's Page indexing report lists a "Not found (404)" reason too, but only for URLs Google has already tried (that help page shows no last-updated date; read 5 October 2026). See 404 errors and orphan pages.

Redirects nobody has maintained since the last migration

Rules accumulate, until one points at a URL that has itself been redirected. Google's documentation explains the stake: a permanent redirect is used as "a signal that the redirect target should be canonical", a temporary one is not (Redirects and Google Search — last updated 14 April 2026). Crawl your redirect list as a URL list rather than reading the rules file, and flag any entry taking more than one hop or ending in an error.

A plugin update that changed your markup

An update shifts a heading level, drops a canonical tag, or rewrites your title template across hundreds of pages, and nothing looks different to a human. Detect it by crawling the same twenty URLs after every update round, diffing titles, H1s, canonicals and meta robots against the previous crawl. Mass title changes also quietly create keyword cannibalisation.

A staging site left indexable

Staging was blocked in robots.txt, so nobody added a noindex rule — then a stray link got it indexed anyway. Google is explicit that noindex only works if the page is not blocked by robots.txt and stays accessible to the crawler (Block search indexing with noindex — last updated 10 December 2025).

<meta name="robots" content="noindex">   <!-- every staging page -->
X-Robots-Tag: noindex                     # or as a response header

HTTP authentication is better, because it does not depend on anyone remembering. Detect a leak with a site: search on the staging hostname each quarter; our robots.txt generator keeps the syntax honest.

Structured data that quietly stopped validating

Schema breaks when a plugin changes output or a required property vanishes from a template. Google requires markup to be "a true representation of the page content", and warns that issues can trigger a manual action that costs the page its rich-result eligibility (Structured data general guidelines — last updated 10 July 2026).

Run one URL per template through the Rich Results Test each quarter, on the rendered page rather than the source — Google recommends that tool and URL Inspection because they show the rendered DOM (Fix search-related JavaScript problems — last updated 18 December 2025).

A sitemap full of URLs that 404

Sitemaps are generated automatically, which is why they rot unnoticed. Google says to include the canonical URLs you want in search results, uses lastmod only "if it's consistently and verifiably accurate", and ignores priority and changefreq (Build and submit a sitemap — last updated 8 July 2026).

Crawl every URL in your sitemap monthly, flagging anything that is not a 200 with a self-referencing canonical. Our XML sitemap post covers what belongs in one.

What we see when we take over a site

A first-hand note, with no number attached. Across the sites we inherit as the incoming SEO team, the two things we find most often are redirect rules from a redesign two agencies ago that now point at 404s, and a sitemap still listing URLs consolidated months earlier.

Both had been covered by a maintenance retainer the whole time. Neither was on it. We are not attaching a percentage to that — it is a pattern from our takeover audits, not a measured sample.

What is worth paying someone for — and what is not

No prices here. The question is which of the four jobs needs an outside hand, and the answer is narrower than most proposals suggest.

Worth paying for:

• Updates applied on staging and verified afterwards, by someone who can roll them back.
• Restore tests, PHP and server versions, certificate automation.
• The SEO plumbing — crawl, redirect review, schema check, sitemap reconciliation — and fixing what it finds, the part most plans quietly exclude.

Not worth paying for:

• Plugin updates as a deliverable. On a healthy site that is a button.
• Uptime monitoring as a line item. Free tiers do this competently.
• "Unlimited small edits" you could make in the editor faster than writing the request email.
• Malware scanning reported as an achievement when nothing was found.

The test for whether a retainer earns its fee. Read last month's report. If it is a list of plugin versions and a green uptime figure, you are paying for something a one-click update does. A report worth the money names what it found, what it fixed and what it is watching — a redirect chain repaired, four orphaned URLs relinked, a schema warning cleared. Three months of nothing found means either an unusually stable site or nobody looking.

Where to go from here

Put the weekly twenty minutes in the calendar this week, then pick one quarterly job that has never been done — the redirect review or the restore test — and do it once. Clearing years of SEO plumbing debt is slower: expect three to six months before relinked pages show as meaningful organic movement.