How to Monitor Client Websites (Before They Break)

The worst way to find out about a problem on a client’s site is from the client.

It happens to every agency eventually. A nameserver changes, a redirect breaks, a performance score tanks after a plugin update, and by the time you’re across it, the client has already noticed and is already annoyed.

What you’ll learn: what’s worth monitoring on client sites, and how to catch problems before they turn into conversations.

Most problems on client sites don’t announce themselves

When something breaks obviously, like a white screen or a 500 error, someone notices fast. The harder problems are the ones that look fine on the surface.

A DNS record changes and traffic routes somewhere unexpected. A domain’s nameservers transfer mid-project. An SPF record breaks during a hosting migration and lead emails start landing in spam — proposals go unread, follow-ups disappear, and the client thinks their pipeline has just dried up. A Lighthouse performance score that was sitting at 90 last month is now at 58, and nobody knows when it changed or why.

None of these send an alert. They accumulate until a client asks why their Google ranking has dropped, their contact form stopped working, or their site “feels slower than it used to.”

What’s actually worth monitoring on client websites

Standard uptime tools only check if a server responds. They miss the quiet failures that still ruin a client’s week.

Not everything needs daily attention, but a few categories matter more than most people realise.

DNS records are the foundation of everything. A changed A record, MX record, or nameserver can affect email delivery, site availability, and security, sometimes all three at once. DNS changes can happen through a registrar the client controls, through a hosting migration, or through unauthorised access. Knowing that something changed, and when, is the starting point for working out why.

Core site files tell you a lot about how a site presents itself to the web. robots.txt controls what search engines can crawl. security.txt (defined in RFC 9116) gives security researchers a way to report vulnerabilities. ads.txt protects against ad fraud if the site carries advertising. These files are easy to break during a deploy, and rarely checked after launch.

Performance scores move. A Lighthouse score reflects the current state of the site, and that changes every time someone installs a plugin, updates a theme, or adds a third-party script. A single score tells you where things stand today. A trend tells you whether you have a problem.

SSL certificates expire. Most hosts handle auto-renewal, but not reliably enough to assume it’ll always work. A lapsed certificate takes a site from a green padlock to a full browser warning without notice.

Why “I’ll check when something comes up” doesn’t work

Most agencies don’t actively monitor client sites between projects. They check in when they’re working on something, and rely on the client to flag anything unusual.

The problem is that clients often don’t know what unusual looks like. A slow site might just be “how the internet works” to someone who doesn’t benchmark. A DMARC policy set to none offers no protection against spoofing, but the site looks perfectly normal to a business owner. A DNS record that changed three weeks ago won’t surface until something downstream breaks.

By the time there’s a visible symptom, the invisible damage has usually already happened, to search rankings, to email deliverability, to user trust.

What does a sensible setup for monitoring client websites look like?

You don’t need to watch everything constantly. You need to know quickly when something changes.

A reasonable setup covers:

• DNS change detection: not just “is the site up” but “did any record change, and what was it before”
• Core site file checks: robots.txt, security.txt, ads.txt, and increasingly llms.txt, a newer file that shapes how AI tools read a site
• Lighthouse score history: not the current score in isolation, but how performance, accessibility, best practices, and SEO scores have been trending
• SSL expiry monitoring: enough lead time to act before it becomes urgent

The goal is a short list you can scan quickly, and a reliable alert when something changes unexpectedly.

A quick audit checklist

Run through this for each site you manage. If you can’t answer most of these from memory or a dashboard, you’re relying on the client to notice first.

• When did the DNS records last change? Do you have a record of what they were at launch?
• Does the site have a robots.txt? Has it been reviewed since the last major deploy?
• Is there a security.txt file at /.well-known/security.txt?
• What is the current Lighthouse performance score? What was it three months ago?
• When does the SSL certificate expire?
• If the site runs advertising, is there a valid ads.txt?

If you found gaps in that list, kant.au gives you a single place to check DNS history, site files, and Lighthouse trends across every domain you manage. Add a domain and get a read in a few minutes.