HTTP Status Code Checker — ThreatKestrel

Module Documentation

Run a full scan — every category, one report

Our HTTP Status Checker requests any URL and reports the exact status code returned, following the full redirect chain and showing the response headers at every hop. Use it to diagnose broken pages, verify redirects, and confirm what search engine crawlers actually receive.

What are HTTP Status Codes?

An HTTP status code is the three-digit number a server returns with every response, telling the client what happened. They fall into five families.

Codes in the 200 range mean success. The 300 range means redirection, with 301 signalling a permanent move and 302 a temporary one. The 400 range means the client request was at fault — 404 for a missing page, 403 for forbidden, 429 for rate limited. The 500 range means the server failed.

For search engines these codes are instructions, not diagnostics. A 301 transfers ranking signals to the new URL; a 404 eventually removes the page from the index; a 503 tells the crawler to come back later without penalty. Returning the wrong code is one of the more damaging technical SEO mistakes because it is entirely invisible to human visitors.

Every HTTP response carries a three-digit status code
2xx success, 3xx redirect, 4xx client error, 5xx server error
Search engines treat status codes as instructions
The wrong code is invisible to users but changes how crawlers behave
Redirect chains and loops are a common source of problems

Why HTTP Status Codes Matter

The classic failure is the soft 404: a page that no longer exists returns 200 with a friendly "not found" message. Search engines index it as a real page, so hundreds of empty pages accumulate in the index, diluting the site and wasting crawl budget.

The mirror image is equally damaging. A temporary maintenance window that returns 404 or 500 rather than 503 tells crawlers the pages are gone or broken, and recovery can take weeks. Status codes are also a reconnaissance surface: the difference between 403 and 404 on a protected path reveals whether that path exists.

Soft 404s fill the search index with empty pages
Using 404 instead of 503 during maintenance causes lasting deindexing
302 instead of 301 fails to pass ranking signals to the new URL
Redirect chains waste crawl budget and slow page loads
Differing codes on protected paths disclose whether a resource exists

How This HTTP Status Checker Works

The tool requests the URL and follows every redirect, recording the status and headers at each step.

Validates the URL input against format and SSRF safety checks
Issues an HTTP request to the supplied URL
Records the status code and response headers
Follows each redirect, capturing the status and target of every hop
Reports the full chain and the final destination

How to Use the HTTP Status Checker

Enter the full URL you want to check
Run the check to capture the response and any redirects
Review the status code at each hop in the chain
Confirm the final status is what you expect
Check the number of redirects — more than two is worth simplifying

Understanding HTTP Status Codes

Here are the codes that matter most in practice:

Field / Value	Meaning
`200 OK`	The request succeeded and the response contains the resource. The normal state for any page that should be indexed.
`301 Moved Permanently`	The resource has permanently moved. Search engines transfer ranking signals to the target and update the index. The correct code for any permanent URL change.
`302 Found`	A temporary redirect. The original URL stays indexed. Using it for a permanent move is a common and costly mistake.
`304 Not Modified`	The cached copy is still valid, so no body is sent. A sign that caching headers are working correctly.
`403 Forbidden`	The server understood the request but refuses it. Confirms the resource exists, which is itself an information disclosure on protected paths.
`404 Not Found`	The resource does not exist. Correct for genuinely removed content. The response body should not return 200 with an error message instead.
`410 Gone`	The resource was deliberately removed and will not return. Search engines deindex more quickly than with a 404, which is useful for bulk cleanup.
`429 Too Many Requests`	Rate limiting is active. Should include a Retry-After header so clients know when to retry.
`500 Internal Server Error`	The server failed. Repeated 500s cause crawlers to reduce crawl rate and can lead to pages being dropped.
`503 Service Unavailable`	Temporarily unavailable. The correct code for planned maintenance, and it should carry a Retry-After header so crawlers return without penalising the site.

Common Problems & How to Fix Them

A page that no longer exists returns 200 with a "not found" message in the body. Search engines index it as real content, accumulating empty pages and wasting crawl budget.

Return a genuine 404 status for missing content, or 410 if the removal is permanent. The friendly error page is fine — the status code accompanying it must be correct.

Crawlers interpret these as broken or removed rather than temporarily unavailable, and recovery of rankings can take weeks.

Return 503 with a Retry-After header during any planned downtime. Crawlers then come back later with no lasting penalty.

A temporary redirect keeps the old URL in the index and does not fully transfer ranking signals to the new location.

Use 301 for any permanent change, or 308 where the HTTP method must be preserved. Reserve 302 and 307 for genuinely temporary situations such as A/B tests.

Each hop costs a round trip, dilutes ranking signals slightly, and some crawlers abandon chains after a small number of redirects.

Point the first URL directly at the final destination. When redirect rules accumulate over years, periodically flatten them so old URLs go straight to their current target.

Two rules send requests back and forth, and browsers eventually give up with an error. Users see a completely broken page.

Trace the chain to find the two rules that conflict. The usual causes are a www rule and an HTTPS rule fighting each other, or an application-level redirect duplicating one already applied at the proxy.

Best Practices

Return 404 or 410 for missing content, never 200 with an error page
Use 301 for permanent moves and 302 only for genuinely temporary ones
Return 503 with Retry-After during planned maintenance
Keep redirect chains to a single hop wherever possible
Include Retry-After on 429 responses so clients back off correctly
Check status codes after every deployment and configuration change
Audit the codes crawlers receive, which can differ from what browsers see

Security Recommendations

Be aware that differing codes on protected paths disclose whether a resource exists — returning 404 rather than 403 avoids confirming it
Ensure error responses do not leak stack traces, framework versions or internal paths in the body
Rate limit with 429 and a Retry-After header rather than silently dropping requests
Watch for a sudden rise in 401 and 403 responses, which frequently indicates credential stuffing or enumeration
Avoid redirecting to a URL taken from user input, which creates an open redirect usable in phishing
Return consistent codes and timing on authentication endpoints so responses cannot be used to enumerate valid accounts

Frequently Asked Questions

A page that returns a 200 status while displaying a "not found" message. Search engines treat it as real content and index it, which accumulates empty pages and wastes crawl budget. The fix is to return a genuine 404 status alongside the error page.

Use 301 for permanent moves — it transfers ranking signals and updates the index. Use 302 only when the original URL will genuinely return, such as during an A/B test or a brief promotional redirect.

503 Service Unavailable with a Retry-After header. This tells crawlers the outage is temporary so they return later without dropping your pages. Returning 404 or 500 instead can cause lasting deindexing.

Both indicate the resource is not available. 410 Gone states the removal is deliberate and permanent, which prompts faster deindexing. Use 410 when cleaning up content you are certain will never return.

More than one is worth simplifying, and more than three is a real problem. Each hop adds latency, and some crawlers stop following after a small number. Point the original URL directly at the final destination.

Servers and CDNs frequently vary responses by user agent, cookies, geography or authentication state. Testing with a plain request, without your session cookies, shows what an anonymous crawler actually receives.

A 403 confirms the resource exists, which helps an attacker enumerate your structure. Returning 404 for resources the requester is not entitled to see avoids that disclosure, at the cost of slightly less helpful behaviour for legitimate users.