Redirects are useful, but an unnoticed chain can add latency, waste crawl budget, and send visitors through obsolete URLs before they reach the final page. A scheduled web cron check can verify every hop, record response times, and alert when a loop or unexpected destination appears.
What a redirect-chain check should detect
A reliable check follows 301, 302, 303, 307, and 308 responses while preserving each hop. It should report the original URL, status code, Location header, elapsed time, final URL, and total hop count. Treat missing Location headers, malformed destinations, loops, cross-domain surprises, and excessive hops as failures.
Define the expected route
Document the canonical destination for every important legacy, campaign, and HTTP URL. A plain HTTP address may be expected to move once to HTTPS, while an old product page may legitimately redirect to a replacement. Monitoring is useful only when it compares the observed path with a known intention.
{
"start": "http://example.com/old-page",
"expected_final": "https://example.com/new-page",
"max_hops": 2,
"timeout_ms": 8000
}Build a safe measurement endpoint
Create a protected endpoint that performs a HEAD request when supported, then falls back to GET when necessary. Disable automatic redirect handling so the code can inspect every response. Resolve relative Location values against the current URL, keep a visited-URL set to detect loops, and stop at a strict maximum hop count.
Do not accept arbitrary public targets. Allowlist your own domains, block private network ranges, cap response size, and apply a timeout to every request. These controls prevent the checker from becoming an open proxy or an SSRF path.
Schedule useful checks
Run high-value redirects every 10 to 30 minutes and lower-risk migrations a few times per day. Return HTTP 200 only when the final URL, hop count, and latency budget are acceptable. Return a non-2xx status for loops, timeouts, unexpected hosts, HTTPS downgrades, or the wrong canonical destination so the web cron service can trigger an alert.
If checks might run longer than their interval, apply the lock pattern from How to Prevent Overlapping Cron Jobs. For transient network failures, use the backoff guidance in Cron Job Retry Strategies.
Choose actionable thresholds
- Hop count: prefer zero or one redirect for common entry points and document any exception.
- Total latency: alert after repeated breaches unless the chain is broken.
- Destination: fail immediately if the final host or path is not approved.
- Loop detection: stop as soon as a URL repeats.
- Security: flag HTTPS-to-HTTP downgrades and redirects to unknown hosts.
Store evidence for diagnosis
Record a compact trace for each run: timestamp, status codes, destinations, per-hop timing, total timing, and failure category. Redact sensitive query values. A trace helps distinguish a CDN rule, application middleware, CMS migration, or domain configuration problem.
Respond to an alert
- Reproduce the chain from a second network location.
- Compare every Location value with the migration or deployment plan.
- Check CDN, reverse-proxy, web-server, and application rules in that order.
- Remove redundant hops instead of increasing the allowed maximum.
- Confirm that the final page returns a healthy status and correct canonical tag.
Redirect monitoring complements automated broken-link checks: one finds dead destinations, while the other proves that important redirects remain short, secure, and intentional.
Production checklist
- Allowlist targets and block internal addresses.
- Cap hops, request time, and response size.
- Validate the exact final URL, not only its status code.
- Alert immediately on loops and protocol downgrades.
- Retest after CDN, routing, CMS, or domain changes.
A small scheduled checker turns redirects from hidden configuration into observable infrastructure. With expected routes and strict limits, a web cron job can catch slow or broken chains before they affect search engines and users.