If you run a small practice on WordPress and you haven’t touched the site in a year and a half, I can tell you what is happening on the server right now without logging in. Two plugins are deprecated. One has a known CVE filed against it. PHP is one or two minor versions behind what the host now recommends. The cron is running, but at least one scheduled task has been silently failing for months. The contact form still works, mostly. The booking widget did until last week. This is what WordPress maintenance neglect looks like in slow motion.

I call this the 18-month rule. Not because something explodes on day 547, but because that is roughly when the cost of doing nothing crosses the cost of doing the maintenance you’ve been putting off. Before 18 months, neglect is cheap. After, it gets expensive in ways you can’t schedule.

What actually drifts without WordPress maintenance

WordPress itself is fine. Core updates land, security patches ship, the auto-updater handles minor versions. The drift happens in the layer above core.

Plugins are the loudest source. A typical clinic site runs 15 to 25 active plugins. Even on a healthy site, that means three or four are sold to a new owner each year, two are abandoned by their developer, and one or two add features you never asked for through a banner ad in your admin dashboard. Each acquisition or abandonment is a future maintenance event waiting to happen.

The theme drifts too, especially if it is a commercial theme with its own update channel. Page builders are the worst offenders here. A theme update that touches the page builder’s block schema can quietly break layout on pages you haven’t opened in a year, and you won’t notice until a patient mentions it.

PHP versions move. WordPress’s recommended PHP version creeps forward by about one minor version every 18 months. Hosts follow, sometimes aggressively. If your site is still running on PHP 7.4 when the host quietly forces an upgrade to 8.2, a plugin that uses a deprecated function will throw fatal errors instead of warnings, and your home page goes white.

The asymmetry of small practices

A small practice carries this risk differently than a tech company. There is no engineering team standing by. The person who originally set up the site is often a vendor who has moved on, a family member who built it as a favor, or a staff member who has since left for another job. The institutional memory of what the site is doing and why is thin to begin with, and it evaporates with turnover.

That means the cost of an outage isn’t just the outage. It is the cost of rediscovering what the site does. Which forms route where. What the appointment widget integrates with. Whether the analytics snippet in the footer is still pointing at an account someone still owns. The longer the site has gone untouched, the more of that knowledge is in the heads of people who don’t work there anymore.

What pays for itself

Maintenance on a clinic site doesn’t need to be elaborate. It needs to be regular. The version of this I recommend is a quarterly hour, plus an annual half-day. That is it.

The quarterly hour covers four things. Update plugins and theme to current versions, on staging first, then production. Check that the contact and booking forms still submit and the notifications still arrive. Review the active plugins list and disable anything no longer used. Confirm the backup ran and is restorable.

The annual half-day is where you do the harder work. Audit the plugin list against current alternatives. Anything abandoned or acquired by a sketchy buyer comes out. Check that PHP, MySQL, and the host’s defaults still match what the site expects. Review the analytics setup. Confirm SSL renewal is automated. Look at the actual performance numbers and compare them to last year. Write down what you found, even briefly, so next year’s you doesn’t have to start from zero.

What happens when you skip it

The failure mode I see most often is not dramatic. The site doesn’t get hacked. The home page doesn’t go down. What happens is slower and more expensive.

The booking widget starts failing for one browser. A form submission stops emailing the front desk but doesn’t tell anyone. The site slows down because a plugin update introduced a query that hits the database 40 times per page load. Page speed drops, search ranking drops, organic traffic drops, and three months later someone notices the new patient calls are down. By the time you trace it back, the fix is six hours of work instead of 30 minutes.

This is the same pattern I wrote about in the hidden cost of a broken booking widget. Failures that are invisible to the staff cost more than failures that page the front desk.

If you have already passed 18 months

The way out is not to do a giant rebuild. It is to do the quarterly hour and the annual half-day, but starting with a slightly longer first pass. Plan a half-day, not an hour, to catch up on the backlog. Then resume the quarterly rhythm. The first session will surface two or three issues that need real attention. Triage them, schedule them, and move on. You are not rebuilding the site. You are stopping the drift.

If you don’t have someone in-house who can do this, this is exactly the kind of work I do for small practices. The Plans page lays out how I structure it. The whole point is that maintenance should be boring, scheduled, and small. The dramatic version, the one that ends with a Saturday call to your host, is the version you get when nobody is looking.