Skip to content
bobob

HTTP Status Checker

Check HTTP status, request-profile reachability, redirect diagnostics, final URL, response headers, pasted header blocks, CSP drafts, and a copyable public URL report.

Checked by our serverThe address you enter is looked up by this site's server.

Input and result

What you type is kept in this browser only. Reopen to restore your last run.

Use cases

  • Inspect status codes and response headers
  • Trace public redirect chains and final URLs
  • Compare public, Googlebot Smartphone, and Google InspectionTool request-profile reachability without treating the result as indexing proof
  • Capture cache-control, etag, 304, x-vercel-cache, and cf-cache-status evidence before checking stale deploy caches
  • Capture 500, 502, 503, 504, CDN, and upstream timeout evidence before checking deploy logs
  • Copy a public URL report for deploy handoffs or issue trackers
  • Copy a security header report from pasted DevTools or curl response headers
  • Review redirect diagnostics for HTTPS finish, host changes, and canonical target
  • Triage browser certificate or mixed-content symptoms by confirming the final public HTTPS response and headers
  • Parse copied HTTP headers for cache, cookie, CORS, and security review
  • Check CORS origin and credential headers before treating a browser preflight error as an app bug
  • Check HSTS, CSP, X-Content-Type-Options, Referrer-Policy, Permissions-Policy, and frame protection readiness
  • Draft a CSP header before validating pasted response headers
  • Debug canonical, apex, www, and HTTPS redirects

Examples

Common input
https://www.google.com
Check public URL status, Googlebot or URL Inspection request-profile reachability, cache/CDN header evidence, 5xx/CDN timeout evidence, HTTPS redirect diagnostics, final response headers, pasted header blocks, CORS signals, generated CSP policies, and copyable public URL/security header reports.
Typical output
200 OK, 304, or 5xx evidence / request profile and user-agent evidence / cache-control, etag, x-vercel-cache, or cf-cache-status / final HTTPS URL / redirect diagnostics / public URL report / security header report / CORS and mixed-content notes / parsed headers / CSP header
Use this as a quick sanity check before copying results.
Canonical domain
https://bobob.app
Checks whether apex redirects to the final canonical host and protocol.
Sitemap status
https://www.bobob.app/sitemap.xml
Confirms important crawler files return reachable 200 responses.
Googlebot profile
https://www.bobob.app/tools/http-status-checker
Use the Googlebot Smartphone or URL Inspection profile before treating a crawl issue as app logic.
Cache header check
https://www.bobob.app/
Captures cache-control, etag, x-vercel-cache, cf-cache-status, and 304 clues before a deploy-cache follow-up.

Common mistakes

  • Private, localhost, and reserved URLs are rejected by the server route.
  • Redirect chains can end on a different host, path, protocol, or locale than expected.
  • Some servers respond differently to HEAD, GET, bot user agents, or cached requests.

Before you copy

  1. 1Check status code, final URL, content type, and cache headers together.
  2. 2Confirm canonical and redirect behavior for both apex and www domains.
  3. 3Use DNS Lookup next when the status result suggests a domain routing issue.

Sources

  • 301 and 308 differ in how the method is replayed

    For historical reasons a 301 allows the client to replay a POST as a GET. A 308 requires the method and body to be preserved (RFC 9110). The difference shows up the moment a form submission hits a redirect.

    Basis: RFC 9110

  • 404 and 410 read differently to a crawler

    410 (Gone) is for when the server knows the resource is permanently gone and no forwarding address is known (RFC 9110). 404 only says “not here right now”, so a crawler keeps coming back for a while.

    Basis: RFC 9110

  • Serving 200 with an error page is the worst case

    2xx means the request was received, understood and accepted (RFC 9110). Answer 200 for a page that does not exist and both browsers and search crawlers take it as success, so the dead URL stays in the index.

    Basis: RFC 9110

FAQ

Why does HTTP Status Checker use a server route?

Browsers cannot perform this check reliably by themselves, so the tool sends only the entered host or URL to a small server route.

Should I test private internal systems here?

No. Use public endpoints only and avoid private hostnames, credentials, or internal infrastructure details.

Why does a browser work while this checker fails?

Servers can respond differently by method, headers, geolocation, cache, bot filtering, or redirect policy.

What should I inspect besides status code?

Check final URL, redirect chain, content type, cache-control, response headers, CORS headers, and whether canonical host or protocol changed.

Can this replace a certificate expiry audit?

No. Use it to confirm the public HTTPS final URL, redirects, HSTS/CSP headers, and copied header evidence before checking certificate details in the browser or hosting platform.

Can this fix a 500 or 502 response?

No. Use it to capture the public status, redirect chain, timing, and headers, then check deploy logs, environment values, upstream services, or CDN settings with that evidence.

Can this purge a CDN or browser cache?

No. Use it to capture the public status, redirect chain, cache-control, etag, last-modified, and CDN cache-status headers before checking platform cache, purge, or redeploy settings.