HTTP Status & Headers Checker
Debug a broken deploy, a misrouted CDN rule, or an unexpected 5xx spike. Run a real HTTP request against any URL and see the raw status, every response header, and the full redirect chain — exactly as Googlebot or a browser would.
Understanding HTTP Status Codes
HTTP status codes are three-digit responses from a server to a client's request. They tell you whether the request was successful, whether there was an error, or whether the resource has moved.
2xx Success
The request was successfully received, understood, and accepted (e.g., 200 OK).
3xx Redirection
Further action is needed by the user agent to fulfill the request (e.g., 301 Moved Permanently).
4xx Client Error
The request contains bad syntax or cannot be fulfilled (e.g., 404 Not Found).
5xx Server Error
The server failed to fulfill an apparently valid request (e.g., 500 Internal Server Error).
How to interpret the results
The checker shows three things: the final HTTP status, every response header grouped by purpose, and the full redirect chain with timings. Read them together — a single 200 is rarely the whole story.
- 200 OK with a
cache-control: public, max-age=0— technically a success, but CDNs will not cache the response. Fine for logged-in pages, bad for a static marketing page. - 301 → 301 → 200 — the destination is reachable, but each extra hop adds latency and costs crawl budget. Collapse multi-step chains into a single redirect.
- 302 where you expected a 301 — search engines treat 302 as temporary and may keep the old URL indexed for months. Switch to 301 once the move is permanent.
- 404 Not Found — the server answered, but the resource does not exist. Compare with a working URL: is it a typo, a missing slug, or a broken route?
- 403 Forbidden — the request was rejected. Typical causes: directory listing disabled, WAF bot challenge, or an IP-based firewall rule.
- 429 Too Many Requests — rate limit hit. Check the
retry-afterheader and back off. - 502 / 503 / 504 — the edge (CDN, load balancer, reverse proxy) could not reach a healthy origin. Look at origin health before blaming the edge.
- Connection timeout with no status — DNS resolved but the server never sent bytes. Firewall, wrong port, or the origin is down.
Common issues and fixes
Redirect loop after forcing HTTPS
Classic symptom: your proxy terminates TLS and forwards plain HTTP to the app, which sees http and redirects back to https. Fix: trust X-Forwarded-Proto in the application (Express app.set('trust proxy', 1), Rails config.force_ssl with a proxy-aware check, Django SECURE_PROXY_SSL_HEADER).
Mixed 200/301 between www and apex
Both example.com and www.example.com respond 200. Google will pick one and may split link equity. Choose a canonical host and redirect the other with a permanent 301 at the edge.
Security headers missing after a CDN switch
Custom origin headers are sometimes stripped by the CDN unless explicitly forwarded. Re-add Strict-Transport-Security, Content-Security-Policy, and X-Content-Type-Options at the CDN layer, not just the origin.
Unexpected 3xx on a POST endpoint
Legacy 301/302 can silently rewrite POST to GET and drop the body. If you cannot remove the redirect, use 307 or 308 so method and payload are preserved.
CORS looks broken but request returns 200
CORS errors show up in the browser console, not in the status code. Check the Access-Control-Allow-Origin header and confirm the preflight OPTIONS request is also returning the expected headers.
What to do next
Once the response looks correct in a one-off check, the next question is: will it still look correct at 3am on a Saturday? Status codes, redirect chains, and security headers drift silently — a CDN rule change, a certificate rotation, or a new deployment can quietly flip a 200 to a 500 without anyone noticing until traffic drops.
- Re-run this check after every deploy as part of a release checklist.
- Add an alert on the specific headers you care about (HSTS, CSP) — not just on status code.
- For high-traffic pages, set up continuous monitoring on FlashMon.app so the next 5xx sends a notification before users tweet about it.
Stop manual checking
Get notified automatically when your status codes or headers change.
Frequently Asked Questions
HTTP status codes are three-digit numbers servers return to describe the result of a client's request. They're grouped into five classes: 1xx (informational), 2xx (success), 3xx (redirection), 4xx (client errors), and 5xx (server errors). The most common are 200 OK (success), 301 Moved Permanently (redirect), 404 Not Found (missing page), and 500 Internal Server Error (server failure). Understanding them is essential for debugging web applications and optimizing site health for SEO.
A 301 redirect is permanent — it tells search engines and browsers that a page has moved forever, transferring accumulated SEO authority (link equity) to the new URL. A 302 redirect is temporary — search engines keep indexing the original URL since the move is not permanent. Using a 302 when you mean a 301 is a common SEO mistake that dilutes ranking value over time. Always use 301 for domain migrations, URL restructuring, and permanent content moves.
HTTP response headers are key-value pairs sent alongside a server's response, providing metadata about the content and connection. They control caching behavior (Cache-Control, ETag), security policies (Content-Security-Policy, HSTS), content type (Content-Type), and server identity. Headers like Strict-Transport-Security enforce HTTPS connections, while X-Frame-Options prevent clickjacking attacks. Inspecting headers is crucial for debugging performance issues, conducting security audits, and ensuring your server is correctly configured.
A redirect loop occurs when page A redirects to page B, which redirects back to page A (or through a longer circular chain). Browsers detect this after a few hops and display "Too many redirects" errors, making the page completely inaccessible. Search engine crawlers also abandon loop-trapped URLs, preventing indexing entirely. This can cause pages to disappear from search results. FlashMon's HTTP checker detects loops immediately, displaying the full redirect chain before they damage your rankings.
The most critical security headers are: Strict-Transport-Security (enforces HTTPS), Content-Security-Policy (prevents XSS attacks), X-Frame-Options (blocks clickjacking), X-Content-Type-Options (prevents MIME sniffing), Referrer-Policy (controls referrer information leakage), and Permissions-Policy (restricts browser API access). Missing these leaves your site vulnerable to common web attacks. FlashMon's HTTP Status Checker audits all recommended headers, showing which are present, which are missing, and their current values.
Manual checks work for occasional audits, but production sites need continuous automated monitoring. Headers and redirect configurations can change unexpectedly due to server updates, CDN configuration changes, or new deployments. FlashMon monitors your HTTP headers and redirect chains continuously, alerting you immediately when a security header disappears, an unexpected redirect appears, or your server starts returning error codes — before your users or search engines are affected.
Different clients look different to a server. Browsers send a User-Agent, accept cookies, negotiate TLS, and often arrive with a referrer. A plain HTTP probe does not. WAFs (Cloudflare, AWS WAF, Akamai) frequently challenge non-browser traffic with 403 Forbidden, 503 Service Unavailable, or a JavaScript challenge page. If this happens, it usually means your site is protected — not broken — but automated uptime checks, SEO crawlers, and Googlebot may also be affected. Whitelist known monitoring IP ranges or relax bot-challenge rules for the /robots.txt and /sitemap.xml paths at minimum.
Both are permanent redirects, but 301 was historically ambiguous about method preservation: many clients silently downgraded a POST to a GET on redirect. 308 was introduced to explicitly forbid that — the method and body must be preserved. For pure SEO link equity on GET pages the two are treated equivalently by Google. Use 301 for canonical page moves (the safe default crawlers understand everywhere) and 308 when you're redirecting API endpoints or form targets and cannot afford a silent method change.
Google flags a page as Soft 404 when the HTTP status says 200 but the content looks like an error page — thin content, an 'item not found' message, a redirect to a homepage instead of a proper 404, or a product page whose database record is gone. The fix is to return a real 404 (or 410 Gone if the content is permanently removed) when the resource does not exist. Check the Coverage report in Google Search Console to see which URLs are flagged, then verify the status with this tool.