What a Quarterly Maintenance Visit Actually Covers, and What It Catches

Executive Summary

A quarterly maintenance visit is a fixed list of checks, done four times a year, on the parts of a website that age without anyone noticing. The software under the site gets older. Add-ons fall behind. A backup job quietly stops. A security certificate gets close to its expiry date. A domain’s payment card expires. None of these show up on the home page until the day they break it.

The visit makes each of those problems small. A site that is one minor update behind needs a few minutes. A site that is five years behind needs a project. The visit is how you stay in the first group.

This article walks through what we check, what each check catches, and how to run the same pass yourself. It also explains the annual review that sits on top of the quarterly ones.

Our takeaway: small, scheduled, written-down maintenance costs less than almost any alternative, because it replaces rare emergencies with routine afternoons.

Why do websites need maintenance at all?

A website is not a finished object. It is a stack of software that other people keep changing. The server runs an operating system. On top of that sits a runtime, which is the program that executes your site’s code, such as PHP or Node.js. On top of that sits a content system such as WordPress or a custom CMS. On top of that sit plugins, themes and libraries. Each layer has its own release schedule, and each layer eventually stops receiving security fixes.

You do not have to change anything for the site to get riskier. The code stays the same while the world around it moves. New weaknesses are found in old software. Browsers change what they accept. A host retires an old server image. An email provider tightens its rules about who may send mail from your domain.

We saw the cost of falling behind in October 2026, when two critical PHP flaws were announced. We covered that in the October 2026 PHP emergency. The sites that fared best were the ones already on a supported version. That is what a maintenance schedule buys you: on the bad day, you have one update to install and not a migration to plan.

What is the cadence?

We use three speeds:

• Urgent security releases: within days. When a serious fix ships, it does not wait for the next quarter. We wrote about the first hours of that process in reading a security advisory in the first hours.
• Preventive maintenance: every quarter. The visit described below.
• A full review: once a year. The annual review looks at the whole stack and plans bigger moves ahead of time.

Gary has shipped software for more than 25 years, and this cadence comes from that work. In the past, graphic designers and creative firms ran custom content management systems he built for them. Those clients were on quarterly preventive maintenance updates with an annual review. When similar, smaller security events came along, they came through without trouble, because the quarterly work had already kept everything current. That is the one first-hand example we will offer here. We are not going to dress it up with numbers.

What does a quarterly visit cover?

Six areas. Each one has a specific job, and each one catches a different kind of slow failure.

Area	What we check	What it catches
Runtimes	Version of PHP, Node.js or whatever runs the site, and when its security support ends	A runtime that is about to stop getting fixes
CMS and plugins	Version of the content system, each plugin and theme, and whether any are abandoned	Known weaknesses in add-ons, and plugins nobody maintains
Backups	That backups exist, are recent, are stored away from the server, and can be restored	A backup job that stopped months ago
Certificates	Expiry date of the site’s security certificate, and whether renewal is automatic	The browser warning that scares customers away
DNS and domains	Domain expiry, registrar contact details, DNS records for the site and email	A lapsed domain or an email record that no longer matches reality
Accounts	Who can log in to the host, registrar, email, analytics and the CMS	Former staff or a former developer with active access

Let’s take each in turn.

What do we check on the runtime?

The runtime is the part owners know least about and the part that hurts most when it ages. We record three facts: the version running now, the newest version in the same branch, and the date the branch stops receiving security fixes.

Then we compare. If a newer patch release exists in the same branch, we apply it. If the branch is within about a year of its end date, it goes on the annual review’s agenda. We want a planned upgrade, scheduled while nothing is on fire.

A small point that surprises people: the version a hosting control panel shows may differ from the one your site is actually using. We check from inside the site, not from the dashboard alone. We cover a way to automate that check in checking every PHP install against php.net in 45 lines.

What it catches: a runtime drifting toward end of life, and a mismatch between what the host says and what the site runs.

What do we check in the CMS and plugins?

For a content management system, the work is a short list:

1. Take a backup first, and confirm it finished.
2. Apply updates to the core system.
3. Apply updates to plugins and themes, one at a time where possible.
4. Load the pages that matter: home, contact, booking, checkout.
5. Submit the contact form and confirm the message arrives.
6. Remove anything unused. A deactivated plugin is still code on the server.

We also look at each add-on’s health. Has it been updated in the last year? Does the author still answer questions? An add-on that has not changed in years is a candidate for replacement, even if nothing is wrong today. The risk is not that it is old. The risk is that when a flaw is found, nobody is there to fix it.

What it catches: known weaknesses in add-ons, plugins that no one maintains, and updates that quietly break a form.

What do we check about backups?

This is the check most owners assume is fine. We verify four things:

• A backup exists and is recent.
• It is stored somewhere other than the server it protects.
• It includes both the files and the database.
• Someone has restored it, at least once, to a scratch location.

The fourth is the one that matters. A backup you have never restored is a hope. During the quarterly visit we do a partial restore, usually the database and a handful of files to a test location, and confirm the site’s data is in them. Once a year we do a full restore drill.

What it catches: a backup job that stopped running, backups stored on the same machine that fails, and archives that turn out to be empty or incomplete.

What do we check on certificates?

A security certificate is what lets the browser show the padlock and load your site over HTTPS. When it expires, visitors see a full-page warning. Most owners never think about it until that warning appears.

We check the expiry date, who issues it and whether renewal is automatic. Automatic renewal is the goal, but automatic things fail silently. A renewal job can break after a server change and nobody hears about it until the certificate runs out. So we check the date directly each quarter, and confirm there is room before it lapses.

If you want to automate this, a short command-line script can read the expiry date of every domain you own and warn when one is close.

What it catches: a renewal job that stopped working, a certificate on a forgotten subdomain, and a domain moved to a new host without its certificate.

What do we check on DNS and domains?

DNS is the address book that points your domain name at your website, your email and other services. It is a small set of records that almost no one looks at, and it controls whether customers can find you and whether your email arrives.

Each quarter we confirm:

• The domain’s expiry date and that auto-renew is on with a payment card that has not expired.
• The registrar account contact email is one a real person reads.
• The records for the website still point where they should.
• The email records, which tell receiving servers which services may send mail as your domain, match the services you actually use today.

That last one matters more every year, because mail providers are stricter about senders than they used to be. If you stopped using a newsletter service last spring and started another, your records should reflect that.

What it catches: a domain about to lapse, stale records pointing to services you no longer use, and email that lands in spam because the records no longer match.

What do we check on accounts and access?

The final area is people. We list every account that can change the website or the services around it: the host, the domain registrar, email, analytics, the CMS, the code repository and any app store accounts. For each one we write down who has access and whether they still should.

This is where we most often find loose ends: a former employee’s login, a developer who finished a project years ago and still has the password, a shared login nobody can tie to a person. Turning on two-step sign-in for the accounts that matter is part of the visit. So is making sure the business, not an individual contractor, owns the registrar and hosting accounts.

What it catches: access that outlived the working relationship, accounts held in someone else’s name, and shared passwords with no owner.

What does the written record look like?

The visit ends with one page the owner can read in five minutes. It has four parts:

1. What we checked and the date.
2. What changed: each update applied, with old and new versions.
3. What needs a decision: a plugin to replace, a runtime branch nearing its end date, a card about to expire.
4. What to expect next quarter.

The record is the most useful part over time. After a year you have four dated pages that show how the site has aged and what was done about it. If something goes wrong, you can see what changed and when. If you hire someone new, they can read the history and see where things stand in an hour.

What goes in the annual review?

The annual review is the quarterly visit’s bigger sibling. Once a year we take the four quarterly records and ask larger questions:

• Which runtimes, frameworks and platforms reach end of life in the next 18 months, and what is the plan for each?
• Which add-ons or services should be replaced?
• Are the backup and restore routines still the right ones for the size of the business?
• Does the access list match the team today?
• What is the yearly cost of the stack, and is it still the right shape?

We keep it separate on purpose. Big decisions deserve their own meeting. If they are squeezed into a routine visit, they either get skipped or get rushed.

A checklist you can run yourself

Here is a version a business owner can run in an afternoon. It will not replace a technical review, but it will show you where the gaps are.

Before you start

• Block three hours on the calendar and set the next one for three months out.
• Write down the logins you will need and where they are kept.

Software

• Find out which version of the server software and content system your site runs. Ask your host or developer if you do not know.
• Look up when that version stops receiving security fixes.
• Check the dashboard for pending updates to the content system, plugins and themes.
• Take a backup before changing anything.
• Apply updates, then load the home, contact and booking pages and submit the contact form.

Backups

• Find the most recent backup and note its date.
• Confirm it is stored away from the server.
• Restore one file or one database table to a scratch location and open it.

Certificates, domains and email

• Look at the certificate expiry date in your browser’s site information.
• Log in to the registrar and note the domain expiry date, the card on file and the contact email.
• List every service that sends email as your domain and compare it to your DNS records.

Accounts

• List who can log in to the host, registrar, email and CMS.
• Remove anyone who should not have access.
• Turn on two-step sign-in where it is offered.

Wrap-up

• Write the one-page record: checked, changed, needs a decision, next quarter.

What does it cost to skip the visits?

We will not invent a figure. Every site is different, and a number without a source would be a guess. What we can describe is the shape of the cost.

A missed quarter is cheap. The gap is small, and it closes in minutes at the next visit. A missed year makes the gap bigger, and updates start to depend on each other: the new plugin needs the new content system, which needs the new runtime. Several missed years can mean a rebuild.

The costs also arrive at bad times. An expired certificate shows up on the day of a promotion. A lapsed domain appears the week a customer tries to book. A backup that cannot be restored is discovered in the middle of a failure. The visit moves those discoveries to a calm afternoon.

For a business with an in-house person who likes this work, the checklist above is enough. For a business that would rather not be the one who notices when something ages, outside help makes sense, and it should come with a written record at the end of every visit.

Conclusion

Quarterly maintenance is plain work. It has six areas, a short checklist for each, and a written record at the end. Its only job is to keep the site from becoming a surprise.

If you remember one thing, make it the backup restore. A site with current software and a restored-and-verified backup can recover from most bad days. A site with neither is relying on luck.

If you would like a second pair of eyes on where your site stands today, the Audit Sprint maps how the work actually moves today and hands you a written plan with fixed-price options. If you would rather have the quarterly visits handled for you, our Care Plans start at $450 a month and cover monitoring, fixes when a vendor changes something and steady improvements, month to month.

Related reading

• The October 2026 PHP emergency: why staying current always costs less
• A runbook for a one-person operation: what to write down first
• Documentation as leverage: runbooks and decision logs for small companies

Frequently asked questions

What is quarterly website maintenance?

It is a scheduled pass, four times a year, in which someone checks the parts of your website and online accounts that age quietly. That means the software versions underneath the site, the content system and its add-ons, backups, security certificates, domain settings and who has access to what. The result is a short written record of what was checked, what changed and what needs a decision.

How long does a quarterly maintenance visit take?

For a small site with one content system, one host and one domain, plan on a few hours of work spread over a day, plus time to write up the results. The time depends on how far behind the site is. A site that has been visited every quarter has small gaps to close. A site that has not been touched in two years can take much longer, because the changes pile up.

What is the difference between a quarterly visit and an annual review?

The quarterly visit applies updates and verifies that things work. The annual review looks ahead. It lists every runtime and framework with the date its security support ends, decides which bigger moves to make this year, and reviews costs and access. We keep them separate so that the big decisions get their own time.

Can I do quarterly maintenance myself?

Yes. Most of the checklist needs patience and a calendar reminder more than special skill. The parts that need experience are upgrading a runtime or a content system without breaking the site, and restoring from a backup. If you do it yourself, write each step down once so the next visit takes less time.

What does a maintenance visit not cover?

It does not rewrite your site, add features or fix design problems, and it does not replace an emergency response when a serious vulnerability is announced. Urgent security releases are applied within days, outside the quarterly schedule. The visit is where the routine, predictable work happens.

How do I know my site needs a maintenance visit now?

Check three things. Can you name the date of your last backup restore test? Do you know which version of the server software and content system your site runs? Is there one person who can log in to your domain, host and email accounts? If any answer is no, schedule a visit before the next quarter.

More from Research

• End-of-Life Software in Plain English: How to Find Out When Your Software Stops Getting Fixes
• Treating visitor text as untrusted when it reaches a model