Keep your site as fresh as launch day

You launch the site. Everything’s checked, every link works, every page is exactly as the client signed it off. Then you move on — because that’s the job, there’s always a next one. And the site keeps living without you. The client edits a page and accidentally removes a heading. A plugin update quietly 404s a URL that used to rank. An SSL certificate ticks down to its last fortnight. None of it announces itself.

The frustrating part is that a launch is the one moment you had a perfect record of how the site should be — and then you walked away from it. Monitoring is built to not walk away. It keeps that record, re-crawls the site on a schedule, and tells you what drifted from the version you approved. Not “is the server up?” — plenty of tools answer that — but “is the site still right?”, which is the part that quietly breaks between visits.

Uptime tells you the server answered. That’s not the same as “fine.”

There’s no shortage of tools that ping your site every minute and email you when it stops responding. They’re useful, and monitoring includes that basic availability check too. But “up” is a low bar. A site can return a confident 200 OK on every request while:

• a key page silently 404s because a slug changed
• a contact form stops emailing you and just shows a thank-you screen
• the meta description that earned a page its click-through has vanished
• an h3 that anchored a section disappeared in a botched edit
• an image stopped loading and now there’s a broken icon above the fold

A baseline you already have

Monitoring doesn’t ask you to describe what “correct” looks like. You already produced that record the moment you crawled the site: the full inventory of pages, links, headings, metadata and resources as they stood when you approved them.

That first crawl — or the audit your launch project was built from — becomes the baseline. Everything after is measured against it. There’s nothing extra to configure; the thing that audited the site is the thing that remembers it.

Crawl on a schedule, diff against the last

You pick a cadence that suits the site — daily for something busy, weekly for a brochure site, whatever fits — and Website-Toolkit re-crawls automatically. Each run does one thing that an uptime ping fundamentally can’t: it compares two full crawls of the same site and classifies what moved.

The comparison is specific about direction:

• A page that started failing — was a clean 200, now returns a 404 or a server error. That’s a regression.
• A link that newly broke — fine last crawl, dead this one.
• An issue that appeared — a missing meta tag, a vanished heading, a broken image that wasn’t there before.
• A page or issue that recovered — the redirect you fixed, the link that came back.

The loop closes: a regression becomes a project to-do

Here’s where monitoring stops being just an alert and becomes part of the toolkit. A newly-broken link or a missing tag can drop straight into a linked project’s to-do tab — into the same buckets (Links, SEO, Resources, Content) the results page uses, so a monitoring-found task sits right alongside the ones you added by hand.