HTTP Status Code Checker

See the HTTP status code a URL returns, follow its redirects hop by hop, and check response time, key headers and the TLS certificate. Paste up to 500 URLs to find broken links and redirects in one batch.

Single & Bulk Check

GET, HEAD or POST

Redirect Analysis

Export to CSV

2xx

Success

Request completed successfully

3xx

Redirect

Resource moved to new location

4xx

Client Error

Bad request or resource not found

5xx

Server Error

Server failed to fulfill request

Broken Link Checks

Find URLs in a list that return 404, 410 or server errors

Quick Availability Check

See whether a site or API endpoint responds right now

Migration Testing

Verify redirects after site redesign or domain change

URLs and results aren't saved

No Registration Required

Free

Requests are made from Orbit2x's server with the user agent "Orbit2x-StatusChecker/1.0"

How the HTTP Status Code Checker Works

When you press Check, Orbit2x's server sends a real HTTP request to the URL and reports what came back: the three-digit status code, any redirects, how long the server took to start responding, and a few useful headers. It is a quick way to confirm that a page loads, that a removed page really returns 404 or 410, or that a redirect lands where you expect.

How to Check a URL's Status Code

Enter the full URL, including https:// or http://. If you leave the scheme off in bulk mode, https is assumed. http:// and https://, or www and non-www, are different URLs and can return different codes, so check the exact version you link to.
Pick a method. GET is what browsers and search engine crawlers send, so it is the right choice for most checks. HEAD asks for headers only; most servers answer it the same way as GET, but some reject it with 405 or return a different code. POST is sent with an empty body, which is mainly useful for confirming that an endpoint exists.
Choose whether to follow redirects. With it on, the checker requests each Location in turn, up to 10 redirects, and lists every hop with its status code. With it off, you see only the first response, for example a single 301.
For many URLs, switch to Bulk Check and paste up to 500 URLs, one per line. Bulk checks always use GET. Duplicates are removed, and lines that aren't valid URLs are listed separately instead of being checked. Parallel requests (1–50) controls how many URLs are checked at the same time; when checking your own small server, a lower number is gentler.

Example

Checking http://github.com with redirects on typically shows two hops:

1. 301  http://github.com 2. 200  https://github.com/

That is one redirect (HTTP to HTTPS) followed by a 200 OK. The exact result depends on how the site is configured when you check it.

What the Results Mean

Status code: The code from the final response. With redirects on, that is the page the chain ends on; each earlier hop is listed in the redirect chain. If no HTTP response arrived at all (the domain doesn't resolve, the connection timed out after 30 seconds, or the TLS certificate failed verification), the result says so instead of showing a code.
Response time: The time from sending the request until the response headers arrived, measured from Orbit2x's server. It includes DNS lookup, connecting and the TLS handshake, but not downloading the page, so it will not match the full load time you see in a browser, and it varies with distance between our server and the site. The performance grade is based only on this number: A under 200 ms, B under 500 ms, C under 1 s, D under 3 s, F at 3 s or more.
Security grade: A quick indicator, not a security audit. It starts at 100, subtracts 30 if the URL isn't HTTPS and 10 for each missing header among Strict-Transport-Security (HTTPS only), X-Content-Type-Options and X-Frame-Options. A page can still be protected against framing by a Content-Security-Policy frame-ancestors rule, which this check doesn't read. For a full header review, use the HTTP headers analyzer.
Health score: A rough summary: 100 minus 20 for each listed issue and 5 for each warning, minus a further 30 for a 4xx code or 40 for a 5xx code, never below 0. It is meant to help you sort results, not to measure SEO quality.
SSL certificate: For HTTPS URLs, the certificate's subject, issuer and validity dates. Certificates are verified, so an expired or untrusted certificate shows as a failed request rather than a status code. Fewer than 30 days to expiry is flagged as a warning and fewer than 7 as an issue. The SSL certificate checker shows the full chain.
Redirect warnings: The checker flags redirect loops, redirects without a Location header, more than 10 redirects, chains of three or more redirects, and redirects from HTTPS to HTTP. For a closer look at a single chain, the redirect checker is built for that.

HTTP Status Code Classes

The first digit of a status code gives its class. The codes are defined in RFC 9110 (HTTP Semantics); MDN's status code reference is a readable guide to each one.

Class	Meaning	Codes you're likely to see
1xx	Informational, sent before the final response	100 Continue, 103 Early Hints. The checker reports the final response, so you won't see these as a result.
2xx	Success	200 OK; 201 Created (usually after a POST to an API); 204 No Content (success with an empty body)
3xx	Redirection: the content is at another URL	301 Moved Permanently and 308 Permanent Redirect; 302 Found, 303 See Other and 307 Temporary Redirect; 304 Not Modified (a cache response, not a redirect)
4xx	Client error: the request can't be served as sent	400 Bad Request; 401 Unauthorized (login needed); 403 Forbidden; 404 Not Found; 405 Method Not Allowed; 410 Gone; 429 Too Many Requests
5xx	Server error: the server failed to handle a valid request	500 Internal Server Error; 502 Bad Gateway and 504 Gateway Timeout (a proxy or load balancer couldn't get a good answer from the server behind it); 503 Service Unavailable (overload or maintenance, ideally with a `Retry-After` header)

301 vs 302, and 308 vs 307

301 and 308 say a move is permanent; 302 and 307 say it's temporary. 307 and 308 require the client to repeat the same method (a POST stays a POST), while browsers turn a POST into a GET after a 301 or 302, and 303 always means "fetch the result with GET". The checker follows the same rules when it follows redirects.

401 vs 403

401 means the request needs valid credentials. 403 means the server understood the request but refuses it, which can be a permissions rule or bot protection. A 403 here doesn't always mean visitors are blocked; see the FAQ below.

How Google Treats Status Codes

Google documents how its crawler handles each class in How HTTP status codes, and network and DNS errors affect Google Search. The main points:

2xx: the content can be considered for indexing. A 200 doesn't guarantee indexing, and a page that says "not found" while returning 200 may be treated as a soft 404.
Redirects: Googlebot follows up to 10 redirect hops. 301 and 308 are a strong signal that the target URL should be shown in search; 302, 303 and 307 are a weak signal. Google's redirects guide covers which type to use.
4xx (except 429): treated as "this content doesn't exist". Google handles 404 and 410 the same way, and an indexed URL that keeps returning them is removed from the index.
429 and 5xx: Google slows down crawling. Indexed URLs are kept for a while, but if the errors continue they are eventually dropped.

Practical upshot: make the URLs in your sitemap and internal links return 200, send permanently moved pages straight to their new address with a 301 or 308, and let content that's really gone return 404 or 410. To find the URL list for a site, start from its sitemap; the canonical URL checker helps confirm which version of a page should be linked.

When a Bulk Status Check Helps

After a site migration

Paste the old URLs and check them with redirects on. Each one should end on a 200 page at the new address, ideally after a single 301 or 308. Anything that ends on 404, or bounces through several redirects, needs a redirect rule fixed.

Cleaning up a sitemap

Copy the <loc> URLs from your sitemap and check them with redirects off. A sitemap should list final URLs, so any 3xx, 4xx or 5xx result is a URL to update or remove.

Finding broken outbound links

Export the external links from an article or documentation page and use the 4xx filter to find the ones that no longer work. Use the "No response" filter for domains that no longer resolve.

Confirming a deploy

Check a handful of key pages and API endpoints straight after a release to catch 404s and 5xx errors. This is a one-off check; it doesn't monitor URLs over time or alert you.

Download CSV exports the bulk table (URL, status code, response time, redirect count and any error) for a spreadsheet or ticket.

Limitations

One vantage point. Requests come from Orbit2x's server, not your device. Sites that vary by country, block data-centre IP addresses or serve different content to different networks can return a different code to you.
Bot protection. The requests identify themselves with the user agent Orbit2x-StatusChecker/1.0. Firewalls and CDNs may answer them with 403, 429 or a challenge page even when the site works in a browser.
No page rendering. The page content isn't parsed or run, so redirects done with JavaScript or a <meta http-equiv="refresh"> tag aren't followed, and a "page not found" message served with a 200 (a soft 404) shows as 200.
Public addresses only. localhost, private and link-local IP ranges, and names such as .local and .internal can't be checked, including when a public hostname resolves or redirects to one of them.
Time limits. Each request times out after 30 seconds. A 500-URL batch with many slow sites can take several minutes; split very large lists if the check fails to finish.

What Happens to the URLs You Enter

Your URLs are sent to Orbit2x's server, which requests each one and sends the results back to your browser. This tool doesn't save the URLs or the results. The sites you check will see a request from our server, as they would from any client. Avoid checking URLs that contain secrets, such as access tokens in the query string. See the privacy policy for how the site handles data in general.

Frequently Asked Questions

Why does the checker get 403 or 429 when the page opens fine in my browser?

Usually because the site's firewall, CDN or rate limiter treats automated requests differently from browsers. Our requests come from a data-centre IP with a non-browser user agent. If it's your site and you want automated checks to pass, look at your bot-protection or WAF rules.

Why does HEAD return a different code than GET?

Servers are supposed to answer HEAD exactly like GET without the body, but some frameworks and CDNs don't route HEAD requests the same way, and some reject it with 405 Method Not Allowed. Crawlers and browsers use GET, so treat the GET result as the one that matters.

Why is the response time different from what I see?

It's measured from our server to the site, and it stops when the response headers arrive rather than when the page finishes loading. Network distance, caching and server load all change it from one check to the next, so compare several checks rather than reading too much into one.

Is a 404 bad for SEO?

A 404 for a page that doesn't exist is the correct response. Google says 404s for missing pages don't hurt the rest of the site; the URL just drops out of the index. It becomes a problem when pages you want indexed, or links on your own site, return 404, which is what a bulk check helps you find.

Should I use 404 or 410 for removed pages?

Either is fine. 410 Gone states that the removal is deliberate, which some clients use, but Google treats 404 and 410 the same way.

Can I check a URL on localhost or my company network?

No. For security, the checker only connects to public IP addresses. To test an internal URL, run curl -I https://your-internal-url from a machine on that network; curl -IL also follows redirects.