HTTP Status Codes

TL;DR — An HTTP status code is a three-digit number a server sends back with every page it serves, telling the browser or search engine what happened: success, a redirect, a “not found,” or a server error. For SEO the code matters as much as the page itself — it tells Google whether to index the page, follow a redirect, come back later, or drop the URL. The famous one, 404, generally doesn’t hurt your rankings.

What an HTTP status code is

An HTTP status code is the server’s standardized response classification for a request. Evidence for this claim Primary standard or official documentation supporting the adjacent article claim. Scope: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Confidence: high · Verified: 2026-07-14 RFC 9110: Status codes Search engines interpret these responses in their crawl and indexing pipelines, with behavior documented separately from the HTTP specification. Evidence for this claim Primary standard or official documentation supporting the adjacent article claim. Scope: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Confidence: high · Verified: 2026-07-14 Google: HTTP and network errors

Every time your browser (or Googlebot) asks a server for a page, the server answers with a three-digit number before it sends anything else. That number is the HTTP status code, and it’s the server’s one-line summary of what happened to the request. You’ve seen 404 when a page doesn’t exist; 200 is the quiet one that means “here’s your page, everything’s fine.”

The codes come in five groups, sorted by their first digit:

• 1xx — Informational. “Hold on, still working.” You almost never see these.
• 2xx — Success. “Here you go.” 200 OK is the one that matters.
• 3xx — Redirection. “It moved — go here instead.” Redirects live here.
• 4xx — Client error. “Your request has a problem.” 404 Not Found is the star.
• 5xx — Server error. “My fault — I couldn’t serve it right now.”

Why the code matters for SEO

Search engines read the status code first, and it decides how they treat the page:

• A 200 is what you want for a page you want in search — it’s the green light.
• A 301 redirect (permanent) tells Google the page has a new home and to move its ranking signals there. A 302 (temporary) says “this is only for now.”
• A 404 or 410 tells Google the page is gone, and it drops out of the index over time.
• A 500 or 503 server error tells Google something broke; Google backs off and tries again later rather than deleting your pages on the spot.

The thing most people get wrong

404 errors generally don’t hurt your rankings. Google Search Console’s own help says so plainly. If a page genuinely shouldn’t exist, letting it 404 is fine — you can safely ignore those errors. The real cost of a 404 is indirect: you lose whatever traffic and links that page used to have. What you should not do is leave a broken page live returning 200 OK, because Google will happily index the broken version as if it were real content.

Want the full family-by-family breakdown, how Google handles redirects and server errors, the soft-404 trap, and how to check any page’s code? Switch to the Advanced tab.

TL;DR — The status code is a first-class SEO signal, independent of the page’s content. 2xx is necessary but not sufficient for indexing. 301/308 pass a canonicalization signal; 302/307 don’t. 4xx pages get dropped from the index over time, and 404 generally doesn’t hurt rankings. 5xx and 429 make crawlers slow down, not deindex — recovery is gradual once 2xx returns. The trap is the soft 404: a 200 status wrapped around “this doesn’t exist” content, which Google detects at the content layer and treats like a real 404. Match the code to reality, use permanent redirects for permanent moves, and return 503 — not a broken 200 — during downtime.

What a status code actually is

The five response classes come from RFC 9110, the HTTP specification — they’re protocol semantics, not direct SEO scores. Evidence for this claim Primary standard or official documentation supporting the adjacent article claim. Scope: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Confidence: high · Verified: 2026-07-14 RFC 9110: Status codes Google’s documentation, layered on top of that spec, describes likely processing outcomes without guaranteeing exact crawl or index timing. Evidence for this claim Primary standard or official documentation supporting the adjacent article claim. Scope: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Confidence: high · Verified: 2026-07-14 Google: HTTP and network errors

Google’s own documentation is the cleanest definition: “HTTP status codes are generated by the server that’s hosting the site when it responds to a request made by a client, for example a browser or a crawler.” The key idea for SEO is that the code is a signal in its own right, separate from whatever HTML comes after it. A page can look perfect to a human and still be invisible to search because of the number the server sent first.

The five families, through an SEO lens

1xx — Informational. Provisional “still working” responses (100 Continue, 101 Switching Protocols). Almost never SEO-relevant, with one modern exception: 103 Early Hints, which lets the server tell the browser to start preloading critical resources before the full response is ready — a small Core Web Vitals win, not an indexing lever.

2xx — Success. 200 OK is what an indexable page returns. But a 200 is necessary, not sufficient: Google can still decline to index a 200 page for quality, duplication, or other reasons. Edge case worth knowing — a 204 No Content (a successful response with an empty body) can get treated like a soft 404, because there’s nothing to index.

3xx — Redirection. This is where the canonicalization distinction lives, and it’s the single most misunderstood part of the topic. Per Google’s redirects documentation:

• 301 (permanent) and 308 — Google follows the redirect and “the indexing pipeline uses the redirect as a signal that the redirect target should be canonical.” Ranking signals consolidate onto the target.
• 302 (temporary) and 307 — Google follows the redirect, “but the indexing pipeline doesn’t use the redirect as a signal that the redirect target should be canonical.” A 302 left in place for a genuinely permanent move is a classic misconfiguration — Google may eventually treat a long-lived 302 like a 301 in practice, but you shouldn’t rely on that.

Google recommends you “use a permanent server-side redirect whenever possible” for permanent moves, and notes a hard ceiling: “By default, Google’s crawlers follow up to 10 redirect hops.” Redirect chains that run longer than that get abandoned. (For the full tour of the eleven redirect types and their SEO impact, I’ve written that up separately at Ahrefs, linked in Resources — this hub is deliberately the map, not the deep dive.) Also in the 3xx family: 304 Not Modified, a caching signal that tells a crawler its cached copy is still current — no direct ranking effect, but it supports efficient crawling on large sites.

4xx — Client error. The page can’t be served because of something on the request side — it’s missing, forbidden, or blocked to this client. Google is explicit: “Google doesn’t use the content from URLs that return 4xx status codes,” and “if a URL was previously used but is now returning 4xx status code, Google systems will stop using the URL over time.” For 404 specifically, “the indexing pipeline removes the URL from the index if it was previously indexed. Newly encountered 404 pages aren’t processed.”

Two important nuances here:

• 404 doesn’t hurt rankings. Search Console Help states it directly: “In general, 404 errors won’t impact your site’s search performance.” The risk from a 404 is losing the traffic and links the page carried, or — at scale — wasting crawl budget.
• Don’t weaponize 401/403 against Googlebot. Google warns: “Don’t use 401 and 403 status codes for limiting the crawl rate. The 4xx status codes, except 429, have no effect on crawl rate.” Blocking Googlebot with a 401/403 doesn’t “slow it down” — it just makes the content invisible.

The individual client-error codes each have their own story — the access-and-auth codes (401, 403), the “gone” codes (404, 410, and the question of which to use), rate-limiting (429), and the legal-block code (451) — and each gets a full treatment in its own article. See “Where to go next” below.

5xx — Server error. The request was fine; the server failed to fulfill it (500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable, 504 Gateway Timeout). The crucial SEO fact: these don’t instantly deindex. Google’s doc: 5xx and 429 server errors “prompt Google’s crawlers to temporarily slow down with crawling,” and “once the server starts responding with a 2xx status code, Google gradually increases the crawl rate.” The slowdown is measured: “the decrease in crawl rate is proportionate to the number of individual URLs that are returning a server error.” Previously indexed URLs are preserved through a blip; only sustained server errors eventually lead to removal.

Crawl vs. index: the mental model that ties it together

Two different questions live behind these codes:

1. Should I crawl this? 5xx/429 say “slow down, try later.” 301/302 say “go here instead.” 429 and the 5xx family are the only codes that actually throttle crawl rate.
2. Should I index this, and under which URL? 2xx = eligible. 4xx = drop it. 301/308 = consolidate onto the target.

The connective thread — and the thing that breaks this model — is the soft 404, where the code and the content disagree.

Soft 404s — the sneaky exception

A soft 404 is a page that returns a success code (200) but whose content says the item doesn’t exist — an empty page, a “sorry, not found” message, or a thin/blank result. Google detects the problem at the content layer, regardless of the HTTP code: “if the content suggests an error for Google Search, an empty page or an error message, Search Console will show a soft 404 error.”

Why care, if the page “loads fine”? Because it wastes crawl budget. Google’s large-site guide is blunt: “soft 404 pages will continue to be crawled, and waste your budget.” They usually come from misconfigured CMSes or JavaScript frameworks that return 200 for routes that don’t exist. The fix is to make the code match reality — return a real 404 (or 410) so Google can drop the URL cleanly. There’s a dedicated soft-404 article in this cluster.

404 vs. 410 — does it actually matter?

Barely, for SEO. John Mueller settled this in a 2024 clarification: “The difference in processing of 404 vs 410 is so minimal that I can’t think of any time I’d prefer one over the other for SEO purposes,” adding that “Google does not penalize for 404’s (those pages drop out of the index though).” A 410 (Gone) can signal permanence marginally faster and documents intent more clearly for humans and other tooling — the historical Matt Cutts framing was that 410 removal ran “a little faster,” a few days at most. Use 410 when you’re certain the removal is permanent; 404 when the page might return or you’re unsure. Google’s crawl-budget guide is happy with either: “a 404 status code is a strong signal not to crawl that URL again.” The dedicated 404-vs-410 article resolves the nuance in full.

Using status codes for downtime and migrations

For planned downtime, maintenance, or a migration window, return 503 Service Unavailable — not a broken 200. John Mueller’s guidance is direct: “if something goes drastically wrong with your hoster, and you can’t host your website anymore, please return a ‘503 Service unavailable’ HTTP result code.” His reasoning covers the two anti-patterns to avoid: “returning an error page with ‘200 OK’ will result in us indexing the change of content like that (and if all of your pages return the same error page, then we may assume that these URLs are duplicates). Redirecting to a temporary page will result in that redirect being used for indexing.” The implementation trick when the origin is fully down: point DNS at a temporary server that serves 503s.

Keep it short, though. Gary Illyes: “Serving a 503 status code for an extended period of time will cause a decrease in crawl rate,” but “10-15 minutes every now and then is not ‘extended’ by any means, so you should be fine.” Rule of thumb: 503 is for hours, not weeks — leave it up for weeks and Google starts treating the pages as actually gone. The 503 article covers the migration pattern in depth.

How to check a page’s status code

• Browser DevTools — open the Network tab, reload, click the document request, read the Status column.
• Command line — curl -I https://example.com/page for the headers of a single request, or curl -IL https://example.com/page to follow the whole redirect chain.
• Google Search Console — the URL Inspection tool reports the crawled status.
• Bing Webmaster Tools — its URL Inspection tool does the same for Bingbot.
• Crawlers — Screaming Frog SEO Spider and Ahrefs Site Audit crawl the whole site and surface status codes, redirect chains, and 4xx/5xx URLs in bulk; the free Ahrefs SEO Toolbar shows the code for the page you’re on.

One genuine gotcha the competitor guides skip: a single check only tells you about that one request. Status can vary by request method, user agent, authentication, region, and time, plus whatever cache or CDN sits in between — so a clean result from your desk doesn’t guarantee what Googlebot saw. A compact diagnostic workflow:

• Method — a HEAD request should carry the same headers as GET, but servers are allowed to omit fields that require generating content, so a HEAD check isn’t proof of what a real GET returns. Re-test with GET if the two disagree.
• User agent — bot-detection, geo-blocks, or cloaking can serve Googlebot a 200 while a browser gets a 403 (or vice versa).
• Region — if you suspect geo-blocking or a region-specific CDN rule, retest from more than one location or IP.
• Cache — rule out a stale cached response (browser cache, CDN edge cache) before concluding the origin itself is misbehaving.
• Chain — record the full redirect chain, not just the final code; a mid-chain hop can be the actual problem.
• Logs — when a code doesn’t match what you expect, check what Googlebot actually saw. Your server logs are the ground truth a single browser or checker result can’t give you.

A note on Bing

Bing’s public guidance on status codes is thinner than Google’s — there’s no single canonical “how status codes affect crawling” doc as detailed as Google’s, and no Bing rep quote on the topic surfaced when I looked. Directionally it’s the same advice: return accurate codes, fix persistent 4xx/5xx, and use permanent redirects for permanent moves. I’d rather say that plainly than manufacture a Bing quote that doesn’t exist.

Where to go next: the HTTP error codes cluster

This hub is the overview. The HTTP Error Codes sub-hub goes deep on the codes you actually end up troubleshooting, each in its own article:

• 401 Unauthorized and 403 Forbidden — the access-and-auth codes, and why you shouldn’t use them to throttle crawling.
• 404 Not Found, 410 Gone, and 404 vs 410 — the “this page is gone” family and which code to reach for.
• 429 Too Many Requests — rate-limiting, and how it (unlike other 4xx codes) affects crawl rate.
• 451 Unavailable For Legal Reasons — the legal/regulatory block, distinct from a 403.
• 500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable, and 504 Gateway Timeout — the server-error family, crawl slowdown, and the 503-for-maintenance pattern.
• Soft 404s — the 200-that’s-really-an-error, and how to fix it.

Each of those is nested under this hub and listed in the sidebar. For how redirects consolidate ranking signals, see Canonicalization; for how crawlers throttle on 5xx/429, see Crawling.

AI summary

A condensed take on the Advanced version:

• The code is an SEO signal, separate from content. A perfect-looking page can be invisible to search because of the number the server sends first.
• Five families: 1xx informational (103 Early Hints helps Core Web Vitals); 2xx success (200 is necessary but not sufficient for indexing); 3xx redirects; 4xx client errors; 5xx server errors.
• Redirects: 301/308 are permanent and pass a canonicalization signal; 302/307 are followed but don’t. Google follows up to 10 redirect hops.
• 4xx: Google stops using 4xx content and drops 404 URLs from the index over time. 404s generally don’t hurt rankings (Search Console Help). Don’t use 401/403 to throttle Googlebot — only 429 and 5xx affect crawl rate.
• 404 vs 410: the processing difference is “so minimal” (Mueller) it rarely matters; 410 for certain-permanent removals, 404 otherwise.
• 5xx / 429: crawlers temporarily slow down, not deindex; crawl rate recovers gradually once 2xx resumes. Only sustained errors cause removal.
• Soft 404: a 200 status with “doesn’t exist” content — Google detects it at the content layer, treats it like a 404, and it wastes crawl budget.
• Downtime: return 503 (hours, not weeks), never a broken 200 — Google would index the broken content.
• Checking codes: DevTools Network tab, curl -I/curl -IL, GSC/Bing URL Inspection, Screaming Frog / Ahrefs Site Audit. A single check only proves that one request — method, user-agent, region, and caching can each change the result — so confirm the redirect chain and check server logs for what Googlebot actually saw.

Official documentation

Primary-source documentation from the protocol spec and the search engines.

The underlying spec

• RFC 9110 — HTTP Semantics, §15 Status Codes — the actual protocol definition of the five status-code classes. Worth knowing: RFC 9110 defines request/response semantics, not SEO outcomes — everything below is Google’s own documentation of how it interprets those codes for Search.

Google

• HTTP status codes, network and DNS errors, and Google Search — the canonical doc: what codes are, 4xx removal behavior, soft 404s, and 5xx/429 crawl slowdown.
• How Google Search handles redirects — 301/302/307/308, the canonicalization distinction, and the 10-hop follow limit.
• Optimize your crawl budget — 404/410 as a “strong signal,” and soft 404s wasting budget.
• Fix Search Console errors (404 / crawl errors) — the source of “404 errors won’t impact your site’s search performance.”
• John Mueller — “503s” — the definitive first-party statement on returning 503 during downtime and the 200/redirect anti-patterns.

Bing / Microsoft

• Bing Webmaster Tools — URL Inspection — check indexing status, crawlability, and HTTP response codes for a specific URL.
• Bing Webmaster Tools — Crawl error alerts — the Crawl report listing URLs with crawl errors and their status codes.

Quotes from the source

On-the-record statements from Google and its representatives. Each link is a deep link that jumps to the quoted passage on the source page.

Google — what status codes are, and how 4xx / 404 behave

• “HTTP status codes are generated by the server that’s hosting the site when it responds to a request made by a client, for example a browser or a crawler.” — Google Search Central docs. Jump to quote
• “Google doesn’t use the content from URLs that return 4xx status codes.” Jump to quote
• “In general, 404 errors won’t impact your site’s search performance.” — Google Search Console Help. Read the doc

Google — soft 404s and crawl budget

• “If the content suggests an error for Google Search, an empty page or an error message, Search Console will show a soft 404 error.” Jump to quote
• “soft 404 pages will continue to be crawled, and waste your budget.” Jump to quote
• “a 404 status code is a strong signal not to crawl that URL again.” Jump to quote

Google — 5xx / 429 crawl slowdown, and 401/403 misuse

• 5xx and 429 server errors “prompt Google’s crawlers to temporarily slow down with crawling.” Jump to quote
• “Once the server starts responding with a 2xx status code, Google gradually increases the crawl rate.” Jump to quote
• “Don’t use 401 and 403 status codes for limiting the crawl rate. The 4xx status codes, except 429, have no effect on crawl rate.” Jump to quote

Google — redirects and canonicalization

• “Googlebot follows the redirect, and the indexing pipeline uses the redirect as a signal that the redirect target should be canonical.” (301 / 308) Jump to quote
• “Googlebot follows the redirect, but the indexing pipeline doesn’t use the redirect as a signal that the redirect target should be canonical.” (302 / 307) Jump to quote
• “By default, Google’s crawlers follow up to 10 redirect hops.” Jump to quote

John Mueller, Google — 503 for downtime

• “if something goes drastically wrong with your hoster, and you can’t host your website anymore, please return a ‘503 Service unavailable’ HTTP result code.” Read the post
• “Returning an error page with ‘200 OK’ will result in us indexing the change of content like that (and if all of your pages return the same error page, then we may assume that these URLs are duplicates).” Read the post

John Mueller, Google — 404 vs 410

• “The difference in processing of 404 vs 410 is so minimal that I can’t think of any time I’d prefer one over the other for SEO purposes.”
• “Google does not penalize for 404’s (those pages drop out of the index though).” Relayed via Search Engine Journal’s April 2024 write-up of a Reddit r/SEO reply; corroborated by Search Engine Roundtable. Coverage

Gary Illyes, Google — 503 and crawl rate

• “Serving a 503 status code for an extended period of time will cause a decrease in crawl rate.”
• “Fortunately for you, 10-15 minutes every now and then is not ‘extended’ by any means, so you should be fine.” Relayed via Search Engine Journal’s coverage of a Google SEO Office Hours session, April 2024. Coverage

Which status code should I return?

Work top-down — the first match wins.

The page moved to a new URL.

• Permanently? → 301 (or 308). Google consolidates ranking signals onto the target.
• Only for now (A/B test, geo-swap, short campaign)? → 302 (or 307). No canonicalization signal — don’t leave it in place for a permanent move.

The page is gone and isn’t coming back.

• Certain it’s permanent? → 410 — signals permanence a touch faster.
• Might return, or you’re not sure? → 404 — Google drops it from the index over time either way. Either is fine for SEO; the difference is “minimal.”
• Whatever you do, don’t return 200 with a “not found” message — that’s a soft 404, and Google will keep crawling it and waste budget.

The page requires login or is access-restricted.

• → 401 (needs auth) or 403 (forbidden). Do not use these to slow Googlebot down — they don’t throttle crawl rate, they just hide the content.

Something’s temporarily broken, or you’re doing maintenance/a migration.

• Planned downtime, hours not weeks? → 503, ideally with a Retry-After header. Google backs off and comes back; it won’t index the maintenance page.
• Server genuinely erroring? → 500/502/504 — Google slows crawling and preserves indexed URLs through a blip. Fix it before it becomes sustained.
• Rate-limiting a flood of requests? → 429 — the one 4xx code that does slow Google’s crawl rate.

The content blocked for a legal reason (court order, GDPR, licensing, country-level ban) → 451, which signals a legal block, distinct from a plain 403.

Everything’s fine and you want the page indexed → 200. Remember it’s necessary but not sufficient — Google can still choose not to index it.

Each of these codes has its own deep-dive article in the HTTP Error Codes cluster.

HTTP status codes for SEO — full reference

The five families at a glance

The SEO-relevant codes, one by one

Three groupings that matter

• Strong signals Google acts on: 301/308 (canonical target), 404/410 (remove from index).
• Mostly UX / access — no crawl-rate effect: 401, 403, 451.
• Operational / temporary — crawl slowdown: 429, 500, 502, 503, 504.

Fast facts

• 200 alone doesn’t guarantee indexing.
• Only 429 and 5xx codes throttle Google’s crawl rate.
• Google follows up to 10 redirect hops; longer chains get abandoned.
• Soft 404 = 200 status + “doesn’t exist” content → treated like a 404, wastes crawl budget.
• 503 for downtime: hours fine, weeks not — Illyes says “10-15 minutes every now and then” is no problem.
• Check with: DevTools Network tab, curl -I / curl -IL, GSC/Bing URL Inspection, Screaming Frog, Ahrefs Site Audit/Toolbar.

Resources worth your time

My writing

• HTTP Status Codes & Their SEO Impact — my full range-by-range reference at Ahrefs (1xx–5xx plus nonstandard codes), the piece this hub builds on.
• 11 Types Of Redirects & Their SEO Impact — the companion deep dive on the 3xx family: which redirect to use and why.
• The Beginner’s Guide to Technical SEO — where status codes fit in the bigger technical picture.

From around the industry

• HTTP status codes, network and DNS errors, and Google Search (Google) — the canonical doc behind most of this hub’s claims.
• How Google Search handles redirects (Google) — the 301/302/307/308 canonicalization distinction and the 10-hop limit.
• “503s” (John Mueller) — the first-party statement on returning 503 during downtime and why a broken 200 is worse.
• Google’s John Mueller Clarifies 404/410 Confusion For SEO (Search Engine Journal) — the “difference is so minimal” quote.
• Google On The SEO Impact Of 503 Status Codes (Search Engine Journal) — Gary Illyes’ “10-15 minutes” guidance.
• The ultimate guide to HTTP status codes for SEO (Search Engine Land) — a thorough per-code reference.
• HTTP Status Codes (Screaming Frog) — practical detection and bulk-export workflows.
• How to check pages for their HTTP status codes (Ahrefs Help) — checking codes with the SEO Toolbar and Site Audit.

Where these quotes come from

The full source list behind the Quotes lens, so you can verify every line yourself:

• HTTP status codes, network and DNS errors, and Google Search — Google Search Central. The “what status codes are,” 4xx, soft-404, and 5xx/429 quotes.
• How Google Search handles redirects — Google Search Central. The 301/308 vs 302/307 canonicalization quotes and the 10-hop limit.
• Optimize your crawl budget — Google Search Central. The “strong signal not to crawl” and “soft 404 pages… waste your budget” quotes.
• Fix Search Console errors — Google Search Console Help. The “404 errors won’t impact your site’s search performance” line.
• “503s” — John Mueller’s personal site. The 503-for-downtime directive and the 200/redirect anti-patterns.
• Google’s John Mueller Clarifies 404/410 Confusion For SEO — Search Engine Journal (relayed Reddit reply).
• Google On The SEO Impact Of 503 Status Codes — Search Engine Journal (relayed Office Hours).

Crawl first, index second

Use this two-stage model whenever a status code creates an SEO question.

Stage 1: can the crawler retrieve a usable response?

• 2xx says the request succeeded, so the content can move forward for processing.
• 3xx sends the crawler to another URL; permanent and temporary codes provide different canonicalization signals.
• Most 4xx responses say the requested content does not exist or cannot be used.
• 5xx and 429 say the server is failing or overloaded, so crawlers may reduce request rate.

If retrieval fails, content quality and on-page optimization cannot rescue that request. Fix the transport or intended URL state first.

Stage 2: should the retrieved content be indexed, and under which URL?

A 200 only clears the first gate. Google can still choose not to index thin, duplicate, blocked, or error-like content; an error page that returns 200 can become a soft 404. A redirect can be followed while its target still fails indexing. A successful response is eligibility, not a ranking or indexing guarantee.

The practical diagnostic

1. Record the actual status and every redirect hop.
2. Decide whether that response matches the URL’s intended state.
3. If it reaches a usable 2xx page, inspect indexability and canonical signals.
4. If it returns 4xx, decide whether disappearance is intentional.
5. If it returns 5xx or 429, investigate reliability and scope before interpreting search performance.

Check the first response

Run this in a macOS/Linux shell to print headers for the requested URL without following redirects:

curl -sS -D - -o /dev/null https://www.example.com/page

To print only the status code:

curl -sS -o /dev/null -w '%{http_code}\n' https://www.example.com/page

PowerShell equivalent (PowerShell 7+):

$response = Invoke-WebRequest -Uri 'https://www.example.com/page' -Method Head -SkipHttpErrorCheck
$response.StatusCode
$response.Headers

If the server treats HEAD differently, make a normal GET request before drawing a conclusion.

Follow and display the redirect path

-L follows redirects, while -v shows each request and response. Run this in a terminal and inspect the lines beginning with < HTTP and < location:.

curl -sS -L -o /dev/null -v https://www.example.com/old-page

Use the Redirect Chain Mapper when you need a cleaner single-URL or batch view rather than terminal output.

Tools for reading status behavior

• Bulk HTTP Status Code Checker — check up to 500 URLs, see each redirect chain and final destination, filter SEO problems, and export the result. Use it when the question is “which URLs have the wrong code?”
• HTTP Header Checker — inspect complete response headers across redirect hops, including caching, CDN, compression, and selected security signals. Use it when the status alone is not enough.
• Redirect Checker — quickly inspect the final status, destination, and hop sequence for one URL or a small batch.
• Website Down Checker — test current reachability and timing from an external vantage point when a 5xx or timeout may be intermittent.
• Browser DevTools → Network — reload the page, select the document request, and inspect Status Code and Response Headers. This is useful for interactive debugging, but do not confuse a client-rendered error message with the document’s HTTP status.

Test yourself: HTTP Status Codes

Five quick questions on how status codes shape SEO. Pick an answer for each, then check.

HTTP Status Code

An HTTP status code is the three-digit number a server returns with every response to tell a browser or crawler what happened to its request — success, redirect, client error, or server error. For SEO the code matters as much as the content: it tells Google and Bing whether to index a page, follow a redirect, retry later, or drop the URL from the index.

Related: Crawling, Canonicalization, Indexing

HTTP Status Code

An HTTP status code is a three-digit number included in a server’s response to tell the client — a browser or a crawler — what happened to its request. As Google’s documentation puts it, these codes “are generated by the server that’s hosting the site when it responds to a request made by a client, for example a browser or a crawler.”

The codes fall into five families by their leading digit: 1xx informational (“hold on”), 2xx success (“here you go”), 3xx redirection (“it moved”), 4xx client error (“your fault — the page doesn’t exist or isn’t accessible”), and 5xx server error (“my fault — I couldn’t serve the request”).

For SEO, the status code is a signal in its own right, independent of the page’s visible content:

• A 2xx (usually 200) is required for a page to be eligible for indexing — though a 200 alone doesn’t guarantee indexing.
• 301 and 308 are permanent redirects Google treats as a canonicalization signal; 302 and 307 are followed but do not signal canonicalization.
• 404 and 410 remove content from the index over time; Google says 404s generally don’t hurt search performance.
• 429 and 5xx errors make crawlers temporarily slow down rather than instantly deindex, with crawl rate recovering once 2xx responses resume.
• A soft 404 is the mismatch case: the server returns 200 but the content says the page doesn’t exist, so Google treats it like a 404 anyway and flags it in Search Console.

You can check a page’s status code in your browser’s DevTools Network tab, with curl -I from the command line, in Google Search Console’s or Bing Webmaster Tools’ URL Inspection tools, or with crawlers like Screaming Frog and Ahrefs Site Audit.

Related: Crawling, Canonicalization, Indexing

Changelog