A website that launched cleanly rarely stays that way, and the failures are usually mundane. A TLS certificate expires. A contact form quietly stops delivering email. A contractor who left a year ago still has an admin login. A backup job has been failing since spring, and nobody noticed.
None of this needs clever engineering. It needs someone to look, on a schedule, with a clear idea of what they're looking for. This is the routine we'd hand to a small business, or to an agency maintaining many client sites.
Automate the checks that don't need a human
Start with the things that can fail silently and are cheap to watch automatically:
- Uptime: use an external monitor that alerts you, rather than checking by hand.
- Certificate expiry: monitor it, or check it manually.
- Domain renewal: put the date in a calendar with a named owner, and turn on auto-renew where that's safe.
For a quick manual check, two commands cover a lot. The first prints the status code, redirect count, final URL and response time:
curl -sIL -o /dev/null -w "%{http_code} | %{num_redirects} redirects | final: %{url_effective} | %{time_total}s\n" http://example.com
The second prints when the TLS certificate expires:
echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null | openssl x509 -noout -enddate
A homepage that takes more than one or two redirects is worth a look, and a certificate notAfter date inside the next month is worth a reminder.
Then test what a monitor can't. Submit your contact form and confirm the message arrives. Consider a hypothetical bakery site whose order form breaks after an update. The owner finds out three weeks later, from a customer asking why nobody replied. A thirty-second weekly test prevents that.
Treat access and updates as separate problems
Access is mostly subtraction. Once a quarter, list every account with admin rights and ask whether each person still needs it. Remove former employees and contractors. Turn on multi-factor authentication for every admin account, and don't share logins between people. Give editors editor rights, not administrator rights. Fewer admin accounts means fewer ways in and a clearer audit trail.
Updates need two lanes:
- Security patches shouldn't wait for your monthly review. Subscribe to advisories for the software and integrations you run.
- Routine updates can be batched, but take a backup first and, where you have a staging environment, test there. Updates do break things, which is why the order matters.
Use the right performance data
A site can look fine on your laptop and still be slow for real visitors. PageSpeed Insights shows two kinds of data, and it helps to know which is which:
- Field data comes from real Chrome users. Search Console's Core Web Vitals report is built on the same kind of data.
- Lab data is a simulated Lighthouse run. It's repeatable, which makes it good for debugging, but it isn't what your visitors experienced.
Per web.dev, the three Core Web Vitals and their "good" thresholds are:
| Metric | Measures | Good |
|---|---|---|
| LCP (Largest Contentful Paint) | Loading | 2.5 seconds or less |
| INP (Interaction to Next Paint) | Interactivity | 200 ms or less |
| CLS (Cumulative Layout Shift) | Visual stability | 0.1 or less |
Assessment uses the 75th percentile of page loads. Google has changed these metrics before (INP replaced FID), so check web.dev before building alerts around them.
When something is slow, images are the usual first suspect:
- Compare the dimensions you serve with the dimensions displayed. A 3000px photo in a 600px slot is wasted bytes.
- Use modern formats such as WebP or AVIF where your stack supports them.
- Set
widthandheighton images to avoid layout shift. - Lazy-load below-the-fold images, but not the hero image, which is often your LCP element.
Also review third-party scripts each quarter. Analytics, chat widgets and ad tags accumulate, and they can cost more than any image.
Don't chase a perfect score. Fix what the field data says real visitors are experiencing.
Know what Search Console does and doesn't tell you
Search Console is the right free starting point, but it's easy to over-read:
- Page indexing report: shows which URLs Google has indexed and why others weren't. Check it monthly, and always after a redesign or URL change.
- Performance report: compare date ranges to find pages whose clicks or impressions fell. That's your shortlist for content updates, instead of changing things at random.
- Sitemaps, Manual actions and Security issues: quick checks that nothing is structurally wrong.
Two common misunderstandings. First, Search Console is not a broken-link checker. Its "Not found (404)" entries are URLs Google requested and got a 404 for, limited to the past month, and Google notes that a 404 for a removed page with no replacement isn't necessarily a problem. Run a crawler over your own internal links as well. Second, don't expect your meta description to appear as written. Google builds snippets mainly from page content and only sometimes uses the meta description, so write clear titles and treat descriptions as a best effort.
After any URL change, confirm each old URL redirects to its new equivalent in a single hop. Redirect chains are a common leftover from earlier migrations, and the curl command above shows you the count.
Make backups something you've actually restored
A backup is only useful if it contains everything and you can restore it. Three checks:
- Completeness: for most CMS-driven sites that means files and the database. Media uploads are easy to miss.
- Location: a copy stored on the same server doesn't help if you lose that server. The common 3-2-1 guideline is three copies, on two types of storage, with one off-site.
- Restoration: once a quarter, restore a backup to a staging environment and load the site. Until you've done that, you only believe you have a backup.
Decide in advance how much data you can afford to lose. A brochure site that changes monthly and a store taking orders hourly need very different backup frequencies.
Keep an inventory, not just a checklist
Every integration adds a login, an update cycle, and a question about who's responsible. Keep a one-page inventory of each tool or plugin: what it does, who owns it, and when it was last reviewed. We cover how to run that audit in How to Audit a Website Tool Stack, so we won't repeat it here.
It's also the problem we're designing around with SGEN, where backups, user roles, forms and SEO fields live in one admin, so this checklist has fewer places to touch. The routine itself applies to any stack.
The schedule
| When | What | Who |
|---|---|---|
| Automated | Uptime, certificate and domain-expiry alerts | Monitor, with a named person receiving alerts |
| Weekly | Submit forms, load key pages on mobile, skim alerts | Site owner or maintainer |
| Monthly | Search Console (indexing, performance), content review, routine updates after a backup | Maintainer |
| Quarterly | Access review, restore test, third-party script and integration audit, performance trends | Maintainer plus owner |
| As needed | Security patches, redirects after URL changes, content corrections | Maintainer |
Write this down as a one-page runbook with names on it. For agencies, keep one per client. Maintenance mostly fails when everybody assumes somebody else is doing it.
Closing
Nothing here is advanced, which is the point. Sites mostly go wrong because of things that were visible and unowned: an expiring certificate, a forgotten account, a backup nobody tested.
If you only adopt one thing, make it the quarterly restore test. It's the check most likely to surface a problem nobody knew about.
What's the maintenance check that has caught the most real problems for you? I'd like to hear it in the comments.
SGEN is a flat-rate CMS with 23 native modules, hosting and security included. Learn more at sgen.com.
Top comments (0)