What actually breaks a WordPress site
It helps to know what you are defending against, because the real causes are duller than the ones people worry about. In rough order of how often they cause damage:
- A plugin that stopped being maintained upstream, left installed because it still worked.
- An update applied directly to the live site that conflicted with the theme.
- A contact or quote form that silently stopped delivering, usually after a host or email change.
- An expired certificate, which turns every visit into a browser warning.
- A PHP version going end of life, so the host upgrades it and something old stops running.
- A backup that existed but had never been restored, discovered on the day it was needed.
Notice that four of those are invisible. Nothing errors, nothing looks wrong, and the only symptom is that the leads stop. That is the argument for monitoring rather than checking in occasionally.
Updates: staged, tested, then shipped
Automatic updates on a live site are a reasonable default for a personal blog and a bad one for a business site, because the failure mode is a white screen during business hours. The alternative is not slower, it is just ordered differently:
- Apply updates to a staging copy of the site first, not to the live one.
- Load the pages that matter after updating: the homepage, a service page, the checkout if there is one, and anything with a custom block or form.
- Submit the forms. Do not assume they work because the page renders.
- Ship to live once that passes, with a backup taken immediately before.
- Keep a written record of what changed, so a problem reported three days later has somewhere to start.
Security releases are the exception and should go out quickly. Feature releases can wait a week; letting other people find the regressions first is a legitimate strategy.
Backups you have actually restored
An untested backup is a belief, not a backup. The questions worth answering before you need the answer are how old the newest copy is, where it lives, and how long a full restore takes.
Specifics that matter more than the schedule:
- Off the server. A backup stored on the same host is gone with the host.
- Outside the region. A storm that takes out power across Lee County should not take the backups too.
- Both halves. The database and the uploads folder are separate things, and a backup of one is not a backup of the site.
- Restored at least once, on purpose, to a staging site, so the procedure is known rather than improvised.
- Retained long enough to reach back past a problem you did not notice immediately. Seven days of backups does not help with damage done three weeks ago.
Monitoring: uptime, and the forms
Uptime monitoring is table stakes and takes ten minutes to set up. Checking every few minutes from outside your network and alerting a phone is enough; the point is learning about an outage before a customer tells you.
Form monitoring is the part almost nobody does, and it is the one that costs the most. For a contractor or a practice the quote form is the business, and a broken form generates no error and no complaint. Send a real test submission on a schedule and alert if it does not arrive, and check delivery again after every update and every change to email hosting or DNS.
Worth watching alongside those: the certificate expiry date, mixed-content warnings, and whether the site is still being indexed rather than quietly blocked.
The plugin audit nobody wants to do
A site that has been running for five years usually carries thirty plugins, and typically about a third of them are doing nothing. Every one is code running on your server and a door someone can try. The audit sorts them into three piles:
- Remove: installed for something you no longer do, or duplicating what the theme or another plugin already provides.
- Replace: abandoned upstream, last updated years ago, or carrying known vulnerabilities.
- Keep: load-bearing. These need to be identified explicitly, because the risky part of cleaning up is deleting something that turns out to hold the site together.
Do this on staging, one at a time, with the pages checked after each removal. It is slow and it is the single highest-value thing you can do to an inherited site. It usually makes the site faster as a side effect, for the reasons in why is my website slow.
PHP, hosting, and the things under the site
WordPress runs on PHP, and PHP versions reach end of life on a published schedule. Hosts eventually force the upgrade, and an old plugin or a custom theme written for an older version is where that goes wrong. Knowing your PHP version and testing the next one on staging turns a forced outage into a scheduled afternoon.
The same goes for the host itself: whether backups are included or merely advertised, whether there is a staging environment, and whether support answers in hours or days. Cheap hosting is usually a false economy on a site that generates leads, but the upgrade is a decision to make deliberately rather than during an incident.
The content checks that catch quiet rot
Software maintenance keeps the site running. These keep it correct, and they are worth a pass every quarter:
- Broken internal and external links, including the ones inside old posts.
- Hours, phone numbers, addresses, and service areas, especially after a move or a new location.
- Prices and anything with a date in it, including seasonal pages left up out of season.
- Staff names and photos on an about page nobody has opened in two years.
- Images uploaded at full camera resolution since the last cleanup, which is how a fast site slowly stops being one.
Scheduling it around a Florida year
Maintenance here has a calendar whether you plan one or not. Two things follow from that.
First, hurricane season changes what backups are for. Off-site and out-of-region stops being a best practice and becomes the whole point, and your team needs a way to post a closure or reopening notice from a phone, possibly from somewhere without power.
Second, the heavier work belongs in the slow months. Plugin audits, PHP upgrades, and anything with a real chance of breaking should land in late summer, not in the weeks before the winter season when the site is carrying the year's traffic. Nothing risky should ship in December.
What a care plan should include
If you are paying someone for maintenance, these are the lines worth having in writing. The absence of any of them is the thing to ask about:
- Updates applied on staging and tested before going live, not pushed straight to production.
- Backups off-site, with a stated retention period and a restore that has been rehearsed.
- Uptime and form-delivery monitoring, with alerts going to a person.
- A stated response time for something being broken, and who to contact outside business hours.
- A monthly summary in plain language of what changed and what was found.
- An allowance for small content changes, so a new price list does not need a separate invoice.
- Clear ownership: the domain, the hosting account, and the code are yours, and you can leave with them.
That is roughly what my website maintenance service covers. For sites I have maintained over years rather than built and handed over, the Nielsen and Athlean-X case studies are the long-running ones.
Doing it yourself
This is all doable in-house, and for a simple site with a technical owner it is a reasonable choice. The honest test is not whether you can do the tasks, it is whether they will still happen in month seven, during a busy season, when nothing appears to be wrong.
If the answer is no, the cheapest version of outside help is not a full plan: it is monitoring plus a quarterly pass, so the invisible failures get caught and the rest waits for a scheduled afternoon. That is usually enough to prevent the outages that actually cost money.