Why the redirect chain matters, not just the final destination

A URL that eventually resolves to a 200 OK can still hide real problems along the way — an unexpected extra redirect hop, a redirect through HTTP before reaching HTTPS (a potential security concern), or a slow intermediate hop that inflates real-world load time in a way a simple "does it load" check would never surface. Showing every hop individually — its own status code, headers, and timing — is what makes those in-between problems visible instead of hidden behind a final successful response that looks fine in isolation.

Why this fetches from the server, not your browser

A request from your own browser reflects your specific network path, DNS resolver, and any browser extensions or local overrides (ad blockers, DNS-over-HTTPS settings, VPN routing) — none of which necessarily reflect what a typical visitor, search engine crawler, or another server would experience connecting to the same URL. Fetching from this site's own server gives a consistent, third-party vantage point free of your local browser's specific configuration, which is exactly what's useful when the question is "what does this URL actually return," not "what does it look like from my machine right now."