Skip to content

Status code

Wygard fetches every monitored URL and alerts you the moment its HTTP status code changes — a 200 turning into a 404, a fresh 301 appearing, or a redirect chain rerouting somewhere unexpected.

Scope Tier Default Alert
Per URL Basic Always on — cannot be disabled 🔴 Danger

Why it matters

The HTTP status code is the most basic answer your server gives Google: "this page exists, here it is" (200), "it moved here" (301/302), "it's gone" (404/410), or "something is broken" (5xx). Silent changes — a CMS deletion, a redirect rule deployed by mistake, an SSL renewal that left an internal hop on the wrong protocol — pull the page out of search faster than almost any other regression.

Because this test is the bare minimum of any monitoring, it is always on: every URL you add to Wygard gets a Status code test automatically, and you cannot deactivate or delete it. The default severity is Danger.

What Wygard checks

On every run, the crawler:

  1. Sends a request to the monitored URL.
  2. Records the status code of the first hop as the comparison value.
  3. Stores the full redirect chain in history — every URL in the order it was followed — so you can audit how the request was resolved, even when the final response is a clean 200.
  4. Compares the first-hop status against the stored desired value.

The first crawl's status becomes the baseline. A URL that was a 200 should stay a 200; a URL set up as a 301 should keep redirecting to the same target.

Common alerts

  • Status code changed — e.g. 200 flipped to 404, 301, or 503.
  • Redirect target changed — the first hop is still a redirect, but it now points to a different URL than the baseline. Visible in the redirect-chain history.
  • New redirect chain inserted — the URL used to respond 200 directly and now redirects somewhere first, even if it eventually lands on the original page.

Why this test cannot be disabled

If a page returns 404 or 5xx, every other check on the URL is moot — there's nothing to extract a canonical, meta robots, or H1 from. The Status code test runs unconditionally so an outage or broken redirect is the first thing you see, not the last.

About redirect chains

Googlebot follows at most 5 redirect hops before giving up on a URL. Long chains also slow down page load for real users. Wygard records the full chain on every run, so if a chain quietly grows from one hop to four, you'll see the trend in the test history before it becomes a crawl-budget problem.

Responding to an alert

  1. Open the alert and review the diff — Wygard shows the previous status (and chain) versus the new one.
  2. Decide whether the change was intended (you really did retire the URL, or set up a new redirect) or accidental (a deploy bug, a misconfigured rule, a deleted page that should still exist).
  3. If intended, click Set found value as desired to adopt the new status as the baseline.
  4. If accidental, fix the source — restore the page, correct the redirect target, or roll back the deploy. The next crawl will turn the test green automatically.

Pair it with Canonical

Status code tells you whether the URL responds; the Canonical test tells you whether the response declares itself the authoritative version. Both are about "where does this URL point" — one at the HTTP layer, one at the HTML layer.