How to Monitor a Client's Website for Changes
To monitor client websites for changes, you need a check that runs on every client site without you remembering to do it, compares each result with the previous one, and alerts you only when something that affects search or tracking has moved. When you run SEO or marketing for clients, you are responsible for sites you do not control, and their developers ship changes without looping you in.
The pattern is familiar in agency work. An in-house developer pushes a release on a Thursday. The site still loads, so nothing looks wrong. Three weeks later organic traffic dips, the client asks why, and the expectation is that you already knew.
Decide what counts as a change worth hearing about
Watching every pixel of every page produces so many alerts that people stop reading them. The useful set is narrower, and it splits into things that decide whether pages can rank at all and things that decide how well they perform.
The first group is indexing. A <meta name="robots" content="noindex"> tag or an X-Robots-Tag: noindex header, a new Disallow line in robots.txt, or a canonical pointing to another URL can each take pages out of Google. The XML sitemap belongs here too, because a plugin update or migration that drops URLs from it is one of the most common ways pages fall out of the index.
The second group is on-page and technical. Title tags, meta descriptions and H1s are rewritten by CMS updates and SEO plugin changes more often than you would expect. Uptime matters, as do SSL certificate and domain expiry, since either can take a site offline overnight. Marketing tags (GA4, Google Tag Manager, the Meta Pixel) and the cookie consent banner round it out, because a missing tag breaks the client's reporting without producing a single error.
Visual changes to copy, images or layout are mostly outside this list. Clients edit those legitimately every week.
How the common methods compare
| Method | What it catches | What it misses | Scales to a portfolio? |
|---|---|---|---|
| Manual checks (view source, a crawler, Search Console) | Anything, if you look at the right page on the right day | Changes you did not think to check for | No, beyond a few sites |
| Visual diff tools such as Visualping | Visible changes on the specific URLs you add | Head tags, headers, robots.txt; pages you did not add | Poorly, it works per URL |
| Uptime monitors such as UptimeRobot | The site being down, often SSL | Everything that breaks while the site is up | Yes, but for one problem |
| SEO change monitoring | Indexing, metadata, sitemap and tag changes across the site | Real-time changes if it runs daily; rankings | Yes |
Visual monitors are genuinely good at watching a competitor's pricing page. They report that pixels changed, not that a canonical now points to staging. There is more on that trade-off in our Visualping alternative comparison. Uptime tools are essential, but most SEO damage happens on sites that are responding with a 200, which is the gap covered in the UptimeRobot alternative piece.
Setting it up across thirty sites
- Add each client domain once and let the tool read the sitemap, so new pages are covered without anyone adding URLs by hand.
- Connect Search Console for every client property as well. It will not alert you quickly, but it is where you confirm what Google did about a change.
- Send alerts to a Slack channel per client, or per account manager, so the person who can call the client's developer sees it first.
- Agree internally who responds to which alert type. A
noindexon a product category needs a same-day call; a changed meta description can wait for the weekly review.
When an alert fires
Open the URL in a private window and check the change is real, not a cached page or a geo-redirect. Then decide whether it was intentional. A copywriter improving a title needs nothing from you. A canonical that now points to staging.clientsite.com needs the developer today. Send the client the URL, the old value, the new value and the date, and ask what was released. Over time that question gets your team added to the deploy notifications.
Doing this with Deltio
Deltio was built for this workflow. You add a client site, it reads the sitemap and pages once a day and compares them with the previous check, and it sends a Slack and email alert for that site describing what changed on which URL. The checks cover noindex, robots.txt, canonicals, title, meta and H1, sitemap URLs, uptime, SSL and domain expiry, GA4, GTM, Meta Pixel and the cookie banner. The honest limit is timing: a daily cycle means you hear about a change on the day it is detected, not minutes after the deploy.
Frequently asked questions
- Should I tell clients that I am monitoring their sites?
- Yes. It is a service they benefit from, and it gives you a reason to ask to be told about releases in advance. Most clients respond well to "we noticed this change on Tuesday" when it arrives before they have spotted a problem themselves.
- What if the client's developer blocks monitoring tools?
- Firewalls and bot protection such as Cloudflare's can block automated checks, which shows up as failed or blocked requests. Ask the developer to allow the monitoring tool's user agent or IPs. If they refuse, you are back to manual checks and Search Console for that site.
- How do I monitor a staging site before it goes live?
- Staging is usually password-protected and deliberately set to noindex, so change monitoring there creates false alarms. It is more useful to monitor production and run a manual SEO scan right after the launch, when a staging setting carried over is most likely.
- How many alerts should I expect per client site?
- On a stable site, very few. Busy e-commerce and news sites generate more, mostly title and meta description edits and sitemap additions. If one site floods the channel, look at whether a template is changing on every deploy, since that usually points to a real problem.