HTTP Status Code Checker

Mode This page cannot fetch a URL for you. A browser is not allowed to read another site's response headers — that restriction is the whole point of CORS. Any tool that appears to do it is running the request on a server, which means the URL you typed is in somebody else's log. Capture the headers yourself with curl -I https://example.com/ or your browser's network panel, paste them here, and nothing leaves your machine.

Search Type a number or a word — 410, redirect, maintenance.

Response headers Paste a curl -I dump, or right-click a request in DevTools and copy the response headers. A whole curl -IL redirect chain works — every hop gets decoded.

Code	What it means	Indexable	Passes links
100 Continue	Interim: the server is happy for the client to send the rest of the request. Never a final response and never seen by a crawler as one.	—	—
101 Switching Protocols	The handshake into WebSocket or another protocol. Not a page.	—	—
102 Processing	WebDAV. The server is still working on it.	—	—
103 Early Hints	Sent ahead of the real response so the browser can start preloading. A speed feature, not a result.	—	—
200 OK	The normal success response. The page exists and this is it. Everything else on this list is a deviation from this one.	Yes	Full
201 Created	Something was created. An API response, not a page.	No	—
202 Accepted	Accepted for processing but not finished. Nothing to index.	No	—
203 Non-Authoritative Information	A proxy modified the response on the way through. Treated like a 200, and a sign that something between you and the visitor is rewriting your pages.	Yes	Full
204 No Content	Success with an empty body. Google has nothing to index and will treat the URL as an error.	No	None
205 Reset Content	Tells the client to clear the form it just submitted. Not a page.	No	—
206 Partial Content	A range request — video seeking, resumable downloads. Normal and not an error.	—	—
207 Multi-Status	WebDAV, several results in one body.	No	—
208 Already Reported	WebDAV, avoiding repetition inside a 207.	No	—
226 IM Used	Delta encoding. You will not see this one.	No	—
300 Multiple Choices	Several options and no preferred one. Without a Location header Google has nothing to follow and treats the URL as a soft 404.	No	None
301 Moved Permanently	The permanent move. Google consolidates the old URL into the new one and passes ranking signals in full, usually within a few weeks. Browsers cache it aggressively, so test in a fresh profile.	Target	Full
302 Found	Temporary. Google keeps the old URL indexed and expects it to come back. Left in place for months, Google concludes you meant 301 and treats it as one — so the cost of getting this wrong is the months in between.	Source	To target
303 See Other	Redirect after a form post, always converting to a GET. Treated as a temporary redirect for indexing.	Target	To target
304 Not Modified	Nothing has changed since the crawler's last visit, so no body is sent. This is a good thing — it saves crawl budget. It is not an error and it does not deindex anything.	Unchanged	—
305 Use Proxy	Deprecated and ignored by every client for security reasons.	No	None
307 Temporary Redirect	A 302 that is not allowed to change the request method. A POST stays a POST. Also what a browser does internally for an HSTS-preloaded host.	Source	To target
308 Permanent Redirect	A 301 that is not allowed to change the request method. Passes signals identically. Use it for form endpoints and APIs; use 301 for pages, which every client understands.	Target	Full
400 Bad Request	The request was malformed. Seeing this on a normal URL means something in your stack is rejecting a legitimate request — usually an over-long query string or a character a WAF does not like.	No	None
401 Unauthorized	Authentication required. Google drops the URL and does not keep retrying for long. Correct for a genuinely private area, catastrophic if a plugin starts serving it site-wide.	No	None
402 Payment Required	Reserved. Occasionally used by APIs for a hit quota.	No	None
403 Forbidden	The server understood and is refusing. This is the most common cause of a page that vanishes from Google while looking perfectly fine in your browser: a WAF or bot-protection rule serving 403 to Googlebot only. Confirm with URL Inspection, never with your own browser.	No	None
404 Not Found	The page does not exist. Not a penalty, and a site with thousands of them is not being punished for it. Google retries for a while and drops the URL. Links pointing at a 404 pass nothing at all, which is the only reason to care.	No	None
405 Method Not Allowed	The URL exists but not for that method. Usually something issuing a GET against a POST-only endpoint.	No	None
406 Not Acceptable	Content negotiation failed. Security plugins sometimes serve it to crawlers by accident, which looks identical to a 403 in its effects.	No	None
407 Proxy Authentication Required	A proxy wants credentials. If a crawler sees this, something is intercepting the request.	No	None
408 Request Timeout	The client took too long to send the request. Persistent 408s to a crawler suggest a network or load-balancer problem.	No	None
409 Conflict	The request conflicts with the current state. API territory.	No	None
410 Gone	Deleted deliberately and not coming back. Google removes a 410 faster than a 404 and stops retrying sooner. The honest answer for content you have genuinely retired with no replacement.	No	None
411 Length Required	The server wants a Content-Length header.	No	None
412 Precondition Failed	A conditional request's condition did not hold.	No	None
413 Content Too Large	The request body is too big. Upload endpoints.	No	None
414 URI Too Long	Almost always a redirect loop appending a parameter each time, or faceted navigation that has run away with itself.	No	None
415 Unsupported Media Type	The server will not accept that content type.	No	None
416 Range Not Satisfiable	The requested byte range does not exist.	No	None
417 Expectation Failed	The server will not meet the Expect header.	No	None
418 I'm a Teapot	An April Fools' joke from 1998 that is still in the registry. Some bot-protection services genuinely return it for traffic they do not like, which is how it ends up in a crawl report.	No	None
421 Misdirected Request	The connection reached a server that cannot answer for that host. A shared-certificate or HTTP/2 connection-coalescing problem, and a real cause of intermittent, unreproducible crawl errors.	No	None
422 Unprocessable Content	Understood but semantically wrong. Form and API validation.	No	None
423 Locked	WebDAV resource lock.	No	None
424 Failed Dependency	An earlier request in the same operation failed.	No	None
425 Too Early	The server will not risk replaying an early-data request.	No	None
426 Upgrade Required	The client must switch protocol, usually to TLS.	No	None
428 Precondition Required	The server insists on a conditional request to avoid lost updates.	No	None
429 Too Many Requests	Rate limited. Googlebot reads this as "you are struggling" and cuts its crawl rate, and a sustained 429 eventually costs you indexed pages. The most damaging 4xx a large site can serve.	No	None
431 Request Header Fields Too Large	Usually an oversized cookie.	No	None
451 Unavailable For Legal Reasons	Blocked by legal demand or regional law. For indexing purposes it behaves like a 404.	No	None
500 Internal Server Error	Something broke. Google retries, slows its crawl of the whole site, and after a sustained period starts dropping pages. Worse than a 404 because it suppresses crawling of everything else too.	No	None
501 Not Implemented	The server does not support that method at all.	No	None
502 Bad Gateway	A proxy got an invalid response from upstream. Normally the application behind the proxy has fallen over.	No	None
503 Service Unavailable	Temporarily down. This is the correct code for planned maintenance: serve 503 with a Retry-After header and Google comes back without dropping anything. Serving a 200 maintenance page instead is how you get "We'll be back soon" indexed as your homepage.	No	Held
504 Gateway Timeout	Upstream took too long. Persistent 504s reduce your crawl rate exactly like a 500.	No	None
505 HTTP Version Not Supported	The server refuses that HTTP version.	No	None
506 Variant Also Negotiates	A content-negotiation misconfiguration.	No	None
507 Insufficient Storage	The server is out of space.	No	None
508 Loop Detected	An infinite loop while processing the request.	No	None
510 Not Extended	The request needs an extension the server wants declared.	No	None
511 Network Authentication Required	A captive portal. If a crawler gets this, something on the network is intercepting the request.	No	None
520 Unknown Error (Cloudflare)	Not a standard code. Cloudflare got an empty or invalid response from your origin. Crawlers treat the 52x family as ordinary 5xx errors.	No	None
521 Web Server Is Down (Cloudflare)	Not standard. Your origin refused the connection.	No	None
522 Connection Timed Out (Cloudflare)	Not standard. Cloudflare could not reach your origin in time.	No	None
523 Origin Is Unreachable (Cloudflare)	Not standard. Usually a DNS problem at the origin.	No	None
524 A Timeout Occurred (Cloudflare)	Not standard. The origin accepted the connection but never finished responding.	No	None
525 SSL Handshake Failed (Cloudflare)	Not standard. TLS between Cloudflare and your origin failed.	No	None
526 Invalid SSL Certificate (Cloudflare)	Not standard. Your origin's certificate could not be validated.	No	None

Nothing you type here is uploaded, stored or sent anywhere. It all runs in your browser.

Why no browser tool can check a live URL, and what that tells you

A page running in your browser is not allowed to read the response headers of a request to another origin. That is not an oversight, it is the same-origin policy, and it is the reason a malicious page cannot quietly read your webmail. Without a Access-Control-Allow-Origin header granting permission — which no normal website sends — the headers are invisible to JavaScript.

So every status-code checker that takes a URL and shows you a result is running that request on a server. That is a legitimate way to build the tool. It also means the URL you typed, the time you typed it and your IP are in a log somewhere, and on a staging domain or an unannounced launch page that is a genuine leak. This page decodes what you paste and never makes a request. It is a smaller tool and it is one you can use on anything.

The codes that actually change what Google does

200 with nothing useful on it. A "no results" page, an empty category, a soft error page — all 200s, and Google calls them soft 404s and drops them anyway. The code and the content have to agree.
403 served only to crawlers. Your browser gets the page, Googlebot gets refused, and the page disappears with no error you can reproduce. Bot-protection defaults are the usual culprit. This is the single most under-diagnosed technical SEO problem there is.
503 for maintenance. The one 5xx you can use on purpose. With a Retry-After header it tells Google to come back rather than to reassess. The mistake is deploying a maintenance page that returns 200.
429 under load. Googlebot interprets it as a signal to back off and keeps backing off. A rate limiter that does not exempt verified crawlers can cost a large site a meaningful share of its index.
410 instead of 404. Slightly faster removal and fewer retries. Worth using when you are deliberately retiring a section, not worth retrofitting across a site.

What the headers around the status code are telling you

The code is the headline, not the story. An X-Robots-Tag: noindex on a 200 means the page is fine and still will not be indexed — and because it is a header rather than a tag, it is invisible in view-source and invisible to most browser extensions. A Link: <…>; rel="canonical" header does the same job as the HTML tag and wins arguments you did not know you were having. Vary: User-Agent announces that you serve different content to different clients, which is legitimate for mobile dynamic serving and a red flag anywhere else. All of these are in the header dump and none of them are in the page.

Capturing headers properly

curl -I https://example.com/ gives you one response. curl -IL follows the redirects and prints every hop, which is how you find a chain. Add -A "Googlebot" and compare — if the two differ, you have found your problem, though bear in mind a good bot-protection service checks the reverse DNS and will not be fooled by the user-agent string alone. In DevTools, the Network panel's response headers give you the same thing for a page you are already looking at, cookies and all.

Questions people ask

Why will this tool not just check my URL?

Because it cannot, and neither can any other page running in your browser. Reading another site's response headers from JavaScript is blocked by the same-origin policy. Tools that appear to do it proxy the request through their own server, which works fine but puts your URL in their logs. Paste the headers instead and nothing leaves your machine.

Is a lot of 404s bad for SEO?

No. 404s are a normal part of the web and Google has said repeatedly that having them is not a ranking problem. What matters is which URLs are 404ing: a 404 on a page that has external links pointing at it is throwing away those links, and a 404 on a page that is still linked from your own navigation is a bad experience you control. Fix those two categories and ignore the rest of the report.

Should I use 404 or 410?

410 says "deleted on purpose, stop asking". Google removes it a little faster and retries less. 404 says "not here", which could be temporary. If you are deliberately retiring content with nothing to redirect it to, 410 is more accurate. The difference is small and neither one is worth a migration project.

What is a soft 404?

A URL that returns 200 but has nothing on it worth indexing — an empty search result, a "product not found" page, a category with no items. Google detects the mismatch and treats it as an error anyway, so the 200 buys you nothing. Either put real content on the page or return a real 404.

Does a redirect chain lose link equity?

Not in the way the old advice claims. Google follows several hops and passes signals through them. The real costs are practical: each hop is a round trip for the visitor, each one is a rule that can get dropped in the next migration, and past about ten hops Google stops following. Flatten chains because they are fragile, not because of a percentage.

Do these headers get sent anywhere?

No. The decoder is plain JavaScript in your browser and this page makes no network requests at all. That is the trade-off for not being able to fetch the URL itself.

Related tools

Clean status codes, still no rankings?

Every URL returning the right code is table stakes. What separates two technically perfect sites is which one people link to.

Book a Call More free tools