Automated website checks: catch regressions before users do

How to set up an automated website check: schedules, comparing scans, alerts that are worth reading, and the expiry dates that need watching most.

Infrastructure · Published: 7 October 2026 · 6 min read · Дмитрий Орлов

A one-off scan answers "how is the site today?". Sites, however, break between scans: a plugin update removes a security header, a new landing page ships without a canonical, the certificate renewal quietly fails. An automated website check turns a snapshot into a time series and answers a more useful question: what changed, and is it worse?

What actually breaks between releases

It is rarely the code you were working on. Regressions come from the edges:

• Configuration drift. A CDN or hosting panel change resets Cache-Control, compression or HSTS.
• CMS updates and plugins. A theme update adds a render-blocking script; an SEO plugin update toggles noindex on archives.
• Content. An editor uploads a 4 MB hero image, links to a page that was deleted last week, pastes an http:// embed.
• Things that expire. Certificates, domains, payment cards at the registrar.
• Third parties. A chat widget or analytics tag starts throwing console errors.

None of these show up in your test suite, and none of them announce themselves. That is the case for checking from the outside, on a schedule.

How often to check

Match the frequency to how fast the site changes and how expensive an outage is:

• Before and after every release — the pair that catches the most. The first scan shows the baseline, the second whether the deploy broke something.
• Daily for shops and sites with frequent content changes.
• Weekly or monthly for a corporate site that changes slowly.
• Hourly or every six hours only where minutes of downtime cost money — and only for a few pages.

More often is not automatically better: every check costs a crawl, and a report nobody reads is noise.

Compare, do not just repeat

The value of automation is in the difference between two reports. A repeat check of a watched site reads the same pages as the previous one, so the comparison is fair. The report then sorts findings into three groups:

• New — not there last time. This is your regression list.
• Fixed — found last time, gone now. Proof that a ticket was really closed.
• Still there — found both times. Your backlog.

A finding counts once however many pages raise it, and the number of affected pages is shown as "before → now", so a problem that spreads from 2 to 40 pages is visible even if it is not new. Alongside, the trend shows how the overall score moved since the previous scan. Read the trend over weeks, not one run: one score drop of 2 points is noise, a steady slide is a signal.

Alerts worth reading

An alert that fires every day is muted within a week. Configure notifications by event, not by run:

1. Critical issues — a dead page, an expired certificate, a blocked crawl. Always on.
2. High-severity issues — missing security headers, redirect chains, forms without labels.
3. Score dropped — compared with the previous check.
4. The check could not run — the site did not answer or refused the scanner. Often the earliest sign of an outage.

Send them where the team actually looks: email for a weekly digest, a Telegram chat for the critical ones.

Expiry dates: the cheapest wins of monitoring

Most dramatic outages are not bugs but dates. Watch three of them:

• The TLS certificate. A 90-day certificate renewed automatically should always have more than 30 days left; if it drops below that, renewal is failing. See certificate expiry.
• The domain registration. Auto-renew fails on an expired card; check the domain expiry date and the email at the registrar.
• Mail and DNS records that a migration may have dropped.

Why these dates are dangerous and how to keep them safe is covered in expiry dates.

Where automation ends

An automated check measures; it does not decide. It will not tell you that a new page is badly written or that a price is wrong. Treat its output as an input to the audit process: new findings go into tickets, fixed ones are closed after a rescan confirms them. For the kinds of errors that most often appear as regressions, see checking a site for errors.

Setting it up with SiteScan

1. Run a scan of the site and look at the report once by hand.
2. Press Watch this site, pick an interval — from hourly to monthly — and how many links each check reads.
3. In the account, open Notifications, choose the events and a channel: email or Telegram.
4. Checks are paid from a token balance, one token per page read; see pricing.

From then on, every report opens with what changed since the last scan.