How to monitor your own website for unexpected changes

On a Sunday afternoon in September 2022, someone got into Fast Company's content management system and replaced every headline on the homepage with an obscene, racist message. The team took the site down and had it back about two hours later. Two days later the same attacker pushed similar messages to Fast Company's Apple News followers, and the site ended up offline for eight days.

That's the dramatic version. The everyday one is quieter. A deploy ships a pricing component that renders an empty table. A CMS editor publishes a draft with placeholder text in the hero. Someone restores last year's privacy policy while fixing a typo. Nobody gets paged, because the site is up and every page loads fine.

I work on Page Deltas, a tool most teams use to watch other companies' websites. This post is about pointing it at your own: which pages to watch, how to brief the AI filter so it knows what "wrong" looks like, how to trigger a check after every deploy, and where it stops being the right tool.

Why your other tools miss it

Most sites already have an uptime monitor. It asks one question, whether the page answers, and a defaced homepage answers perfectly well. So does a pricing page with a broken table. Uptime checks are great at telling you the lights are off. They can't tell you someone repainted the walls.

Server-side tools have a different blind spot. A file integrity monitor watches your own files, so it won't notice when a third-party script (a chat widget, a tag manager, an ad snippet) changes what visitors see. It also won't notice a DNS hijack, where your domain points somewhere else and your servers are untouched. Visualping's guide to website defacement makes the same point, and I think they're right: detection has to look at what the page shows a visitor.

That's what a website change monitor does. It fetches the page from the outside, the way a visitor would, and compares it with the last check. The question you're asking becomes "did this page change in a way we didn't plan?"

Which pages should you watch?

You don't need to watch the whole site. Start with the pages where a bad change costs money or trust the fastest, and where a visitor would probably notice before you do.

The first four rows are page monitors. The last one is a sitemap monitor, which alerts when new URLs show up in your sitemap.xml. It helps with one specific kind of hack, the kind that quietly creates hundreds of spam pages on your domain, but only if your CMS adds those pages to the sitemap.

The Free plan gives you 10 monitored URLs, and a sitemap monitor counts as one. That covers your homepage, pricing page, three top landing pages, two legal pages, and the sitemap, with two slots to spare.

Setting it up

The setup is the same as in our guide to monitoring website changes, with one twist. You're describing what should never happen, rather than what you're hoping to see.

1. Add your pages with a brief

Create a free account, click New monitor, and paste the URL. The description field is the prompt our LLM reads when it decides whether a change matters, so write it like a note to a colleague who's watching the page for you.

For your own homepage, something like this works:

Our own homepage (example.com). We rarely change it outside a release.
Alert me on any change to the headline, hero copy, main call to action,
or prices. Alert me if text appears that has nothing to do with our
product, is offensive, or is in a language we don't publish in.
Ignore the rotating customer logos and the latest-blog-posts teaser.

The ignore line does more work than it looks like. Every page has a widget that changes on its own, and if you don't name it, you'll spend the first week getting alerts about it.

2. Send alerts to two places

Open Channels and add where alerts should go. Slack, Discord, and Microsoft Teams take an incoming-webhook URL. Email asks the recipient to confirm a verification message first, and a signed webhook can feed your own system. Click Send test on each one so you know it arrives.

For your own site, I'd attach two channels of different types, for example Slack plus an email alias for whoever's on call. Each alert goes out once per channel with no automatic retry, so a second channel means a Slack hiccup can't hide a defaced homepage.

3. Check right after every deploy

You don't set a check frequency in Page Deltas. The schedule is adaptive, so pages that change often get checked more often and quiet pages less, and paid plans get priority when the queue is busy. Your own homepage is usually quiet, which is the opposite of what you want right after someone touches it.

The fix is to trigger a check yourself. Every monitor has a Check now button, and the same action is available over the API, so you can add one call to the end of your deploy pipeline:

curl -X POST \
  -H "Authorization: Bearer $PAGEDELTAS_TOKEN" \
  https://api.pagedeltas.com/api/monitors/$MONITOR_ID/check-now

Manual checks are limited to one per minute per monitor, which is plenty for deploys. You create the key under Settings, then API keys (it needs the editor or admin role), and it's shown only once, so put it straight into your CI secrets. Our post on turning a website into a change API covers the rest of the API if you want to script monitor creation too.

What to do when an alert lands

Once that's running, a meaningful change produces one message with a plain-language summary and before and after screenshots. If you use the signed webhook, the body looks like this (the values are made up for the example):

{
  "event": "change.detected",
  "monitor_id": "01HW2X...",
  "monitor_url": "https://example.com/pricing",
  "monitor_name": "Our pricing page",
  "change_id": "...",
  "detected_at": "2026-10-08T07:12:00Z",
  "summary": "The Pro and Business plans no longer appear. The pricing table now shows only the Free plan.",
  "before_screenshot_url": "https://.../before.png",
  "after_screenshot_url": "https://.../after.png",
  "dashboard_url": "https://app.pagedeltas.com/monitors/..."
}

Most alerts on your own site will be changes your team made. That's fine, and it's useful. A quick "that's us, shipped today" reply in the thread turns the channel into a running log of what went live and when. The alert that matters is the one nobody recognizes.

When that happens, the screenshots do two things for you. They show what visitors are seeing right now, and they're a dated record of what appeared, which your security team or your insurer may ask for later. History is kept for 14 days on Free and longer on paid plans (30 days on Starter, up to 730 on Scale), so download anything you need to keep.

Sometimes the first sign isn't an alert at all. It's a customer posting a screenshot. If you want to hear about those too, our sister product KWatch.io sends alerts when your brand name comes up on Reddit, X, Linkedin, Facebook, and Hacker News.

Where it stops

There are a few things this setup won't catch, and you should know them before you rely on it.

We compare the main text of each page. Navigation, footers, and ads are stripped before the comparison, so a spam link injected into your footer won't show up. Neither will a purely visual change, like a swapped logo image with the text left alone.

It isn't an uptime monitor either. If your site goes down, checks fail instead of alerting, and after 10 failures in a row the monitor pauses itself and your admins get a notice. That's far too slow for an outage, so keep your uptime tool for that part.

Between deploys, a change is caught at the next scheduled check, and there's no fixed interval you can count on. If you need a guaranteed check every few minutes on a page, Visualping lets you set the frequency per page and is the better fit there. We also only see public pages, so anything behind your login stays out of reach.

Last, Page Deltas tells you that something changed. It won't tell you how someone got in, and that's still work for your security tools.

Start with your homepage

Add your homepage and pricing page first, adapt the brief above with your own ignore lines, and send a test alert to both channels. Then add the check-now call to your deploy script. The Free plan covers 10 URLs or sitemaps with AI filtering, all five alert channels, and API access, and it doesn't need a credit card. Start monitoring for free.

Julien, Product Manager at Page Deltas