Purpose-Built Templates

ZU2B Blueprints

Business in a Box

  • Purpose-built launch kits for local service businesses — website, copy, prompts, SEO, and more.
  • Local Launch Kits →

Website Widgets

  • Working features you install once and own outright — no plugin, no subscription.
  • Chat Widget — Coming Soon

Reference

ZU2B Pulse™

See what visitors experience before they leave — paste any public URL and get a plain-English performance report in seconds.

Scan Your URL Free

A Redirect Looks Broken in Your Diagnostic Tool, But Works Fine in a Real Browser

Field Note #138
🔬 Generalized 🟡 Intermediate ⏱ 30 Minutes ✓ Observation from Experience
You just set up a 301 redirect from an old URL to a new one. You run it through a checking tool — your own script, an AI assistant fetching the page, an automated test — and it reports back that the old page is returning a normal 200 status with the old content, like the redirect never happened. But when you actually open the old URL in a real browser, it correctly bounces you to the new page.

What’s actually happening
Some HTTP-fetching tools follow redirects automatically by default — it’s normal, expected behavior for most use cases. The problem is what that tool then reports back to you: if it silently follows the 301 to its destination and hands you back that page’s content and status code, it can look exactly like “this URL returned 200 with old content” — when what actually happened is “this URL correctly redirected, and I followed it, and here’s what I found at the end.”
A tool that isn’t explicit about distinguishing “the original response” from “the final response after following redirects” will misreport a perfectly working redirect as a routing failure.

How to tell the difference
Check with something that shows you the first hop only, not the final destination:
Browser DevTools → Network tab → Preserve Log → visit the URL → click the very first request in the list (not any request that loads after it) → check its Status column. It should read 301, and its Response Headers should show a Location pointing to the new URL.
A dedicated header-checking tool that explicitly shows redirect chains hop-by-hop, rather than just a final result.

The fix
There often isn’t one — if a real browser confirms the redirect is working, the redirect itself is fine. The “fix” is recognizing that the diagnostic tool’s report was misleading, not chasing a bug that doesn’t exist.

How to avoid it next time
Don’t trust a single automated check that only reports one final status code for a URL you know should redirect. Cross-check with an actual browser and the Network tab’s first request specifically — that’s the one piece of ground truth no tool’s redirect-following behavior can obscure.

Tagged in :

More from the field