HTTP Status Code Checker

An HTTP status checker tells you exactly what a server says when someone, or something, requests a URL. Ours sends the request, follows each redirect one hop at a time, and shows the status code at every step, the final answer, how many redirects it took and the total time. It is the quickest way to confirm that a migrated page returns a 301 rather than a 302, that a deleted page really returns 404 or 410, and that your important pages answer 200.

How to use the HTTP status

1. 1 Paste the URLEnter the full address you want to test, including https:// and any path or query string, for example https://example.co.uk/old-page.
2. 2 Sign in and run the checkUse your free account to run the test. We request the URL from a server in Germany and record each response before following any redirect.
3. 3 Read the redirect chainEach redirecting address is listed with its status code, followed by the final address, its code and the standard name, such as 200 OK or 404 Not Found.
4. 4 Fix and test againChange the redirect or server setting that caused a problem, clear any CDN or plugin cache, then run the check again to confirm the new response.

How the HTTP status checker requests your page

Your browser hides most of what happens when it loads a page. If a URL redirects twice before landing, you only see the final address. Our HTTP status checker makes each request with automatic redirects switched off, so it can record what the server actually returned at every stage.

It sends a HEAD request first, which asks for the headers without the page body and is quick and light on the server. Some servers refuse HEAD and answer 405 Method Not Allowed or 501 Not Implemented, so in that case we ask again with an ordinary GET before deciding on the result. When a response is a 3xx redirect with a Location header, we work out the full target address, request it in the same way, and carry on until we reach a response that is not a redirect, up to ten hops. If the chain comes back to an address it has already visited, we stop and report a redirect loop.

Each request has a short timeout, and the request identifies itself with our crawler user agent rather than pretending to be a browser. That matters: a firewall, bot protection service or security plugin may treat us differently from a visitor, which is useful to know in itself because search engine crawlers are automated too.

What the status code classes mean

HTTP status codes are defined in RFC 9110, the current HTTP semantics standard. The first digit gives the class of response, and the other two narrow it down. You only need a handful of codes to diagnose almost every SEO and website problem.

• 2xx success: 200 OK is what every page you want indexed should return. 204 No Content is normal for some APIs but wrong for a web page.
• 3xx redirection: 301 and 308 are permanent moves, 302 and 307 temporary ones. 303 See Other is mostly used after form submissions, and 304 Not Modified tells a browser its cached copy is still valid.
• 4xx client errors: 404 Not Found and 410 Gone mean the page is not available. 401 and 403 mean access is refused, and 429 Too Many Requests means the client is being rate limited.
• 5xx server errors: 500 is a general application failure, 502 and 504 usually point to a proxy, CDN or load balancer that could not get a good answer from the server behind it, and 503 means temporarily unavailable.

Reading the redirect chain and timing

The result has three parts. The first is the final status and its name, marked as a pass for 2xx and 3xx outcomes and a fail for client errors, server errors, no response or a loop. The second is the redirect count, shown as the sequence of codes, for example 301 then 301. No redirects, or one or two, count as a pass; three or more are flagged as a warning, because every extra hop adds a round trip for visitors and a step that crawlers must follow. The third is the total time for the whole chain in milliseconds.

A long total time is not necessarily a slow page, since a HEAD request does not download the body. It does tell you how long the server and any redirects take before a browser can even start loading content, so a figure well over a second is worth investigating alongside your server response time.

Choosing the right redirect code

Permanent and temporary redirects send different signals. A 301 or 308 tells search engines that the old URL has moved for good, so they should index the new address and pass signals across to it. A 302 or 307 says the original URL will be back, so Google may keep the old address in its index for longer.

The difference between 301 and 308, and between 302 and 307, is the request method. Under RFC 9110, clients may change a POST into a GET when following a 301 or 302, while 307 and 308 require the method and body to be kept. For ordinary web pages either pair works; for forms and APIs, 307 and 308 are the safer choices.

When you move a site to HTTPS or change domain, aim for every old URL to reach its new home in a single hop. A common chain is http to https, then non-www to www, then old path to new path: three redirects that could be one rule.

Status codes and search engine crawling

Search engines act on the status code, not on what the page looks like. A page that shows a friendly "not found" message but returns 200 is a soft 404, and Google may waste crawl time on it or report it in Search Console. Make sure missing pages really return 404 or 410.

Server errors are treated as temporary at first, but if a URL keeps returning 5xx, Google crawls the site more slowly and may eventually drop the page. During planned maintenance, return 503 with a Retry-After header rather than a 200 maintenance page, so crawlers know to come back later.

Redirects are followed, but not indefinitely. Googlebot follows up to ten hops before giving up on a URL, the same limit our checker uses, so a chain that hits that limit here will also fail for Google.

When to run an HTTP status check

Run a check after any change that touches URLs: a site migration, a new CMS, a change of domain, a switch to HTTPS, or a batch of redirects added by a plugin. Test a sample of old URLs from each section of the site, not just the home page.

It is also worth checking pages that have dropped out of search results, links reported as broken in Search Console or Bing Webmaster Tools, and landing pages used in paid campaigns, where a broken redirect wastes money every time someone clicks.

Handling deleted, moved and merged pages

When you remove a page, decide what should happen to the URL rather than leaving it to the defaults of your CMS. If there is a close replacement, such as a newer version of a product or a guide that covers the same topic, a 301 sends visitors and search signals to it. If there is no genuine equivalent, return 404, or 410 if you want to say clearly that the removal is deliberate.

Merging several thin pages into one stronger page is a good use of 301 redirects: point each old URL at the section of the new page that answers the same question. Keep the redirects in place for at least a year, and longer if the old URLs still receive links or traffic, because removing them later turns useful links back into errors. After the work is done, test a sample of the old URLs here and update internal links so they point straight at the new address.

Examples you can copy

curl -I https://example.co.uk/old-page

curl -sIL https://example.co.uk/old-page | grep -iE "^(HTTP|location)"

curl -sL -o /dev/null -w "%{http_code} after %{num_redirects} redirects\n" https://example.co.uk/old-page

Redirect 301 /old-page https://example.co.uk/new-page

Common mistakes to avoid

Frequently asked questions