200 OK

TL;DR — A 200 OK response is the server saying “here’s the page you asked for, everything’s fine.” It’s the quiet success code you want on every page you’d like to show up in Google. But a 200 by itself doesn’t guarantee the page gets indexed — Google still looks at whether the content is worth indexing. And a 200 on a page that’s actually broken or empty is a bug, not a green light.

What 200 OK means

Every time your browser or Googlebot asks a server for a page, the server answers with a three-digit status code before it sends anything else. 200 OK is the “all good” one — the server found what you asked for and hands it back, normally with the page’s content included. (Technically the spec allows a 200 with an empty body in some cases, but for a page you want people to read, you want a real body every time.) It’s the code you almost never notice, because it’s the one that means nothing went wrong. Evidence for this claim RFC 9110 defines 200 OK as indicating that the request succeeded; the response content depends on the request method. Scope: HTTP semantics for 200 responses; this does not guarantee search indexing. Confidence: high · Verified: 2026-07-14 IETF: RFC 9110 §15.3.1 — 200 OK

Patrick Stox sums it up in three words in the Ahrefs HTTP status codes guide: “200 OK – All good. Everything is successful.”

For the pages on your site that you want people to find in search, 200 is exactly the code you want them to return.

Why a 200 isn’t the whole story

Here’s the part most “what does 200 mean” pages skip: a 200 gets your page considered for indexing, not guaranteed into the index. Two very different things.

Think of the 200 as the ticket that gets you in the door. Once you’re through the door, Google still decides whether the content is worth keeping — is it high quality, is it a near-duplicate of another page, is it thin or empty, does it have a noindex tag telling Google to stay out? Any of those can mean a perfectly healthy 200 page still doesn’t get indexed.

So if a page returns 200 but isn’t showing up in Google, the status code isn’t the problem — the content or the setup is.

The trap: a 200 that’s really “not found”

The sneakiest mistake is a page that returns 200 but whose content says “this doesn’t exist.” An out-of-stock product with a blank page, a deleted article that still loads an empty template, a search results page with zero results — the server sends a cheerful 200, but there’s nothing real there.

Google looks past the code at the actual content, decides the page is empty or an error, and labels it a soft 404 in Search Console — treating it just like a real “not found” page. That’s covered in depth in the soft-404-errors article; the short version is: if a page is genuinely gone, it should return a 404 or 410, not a 200.

The one rule to remember

A page you want in Google should return 200 with real content on it. If the page is gone, use 404 or 410. If it moved, redirect it (301). If it’s a duplicate of another page, use a canonical tag. Want Google’s exact wording, the 200-vs-204 distinction, and how to check what Googlebot actually received? Switch to the Advanced tab.

TL;DR — 200 OK is the standard 2xx success code (RFC 9110 §15.3.1): the server fulfilled the request and, for GET/HEAD, the body is a representation of the resource. It’s heuristically cacheable by default. For SEO it’s necessary but not sufficient — Google’s own doc says the indexing pipeline “may index the content, but that’s not guaranteed,” so quality, duplication, thin content, and noindex still decide the outcome on top of the 200. The classic failure is the soft 404: a 200 wrapped around error/empty content, which Google detects at the content layer and reports as a soft 404 regardless of the code. Contrast 200 (body expected) with 204 (empty body, treated like a soft 404 on pages) and 304 (a caching signal, not an indexing decision). And confirm what Googlebot got — cloaking, bot-blocking, geo rules, and CDN/WAF config can serve it a different code than your browser sees.

What 200 means in the spec

RFC 9110 (HTTP Semantics) is the current authority, and §15.3.1 is blunt: “The 200 (OK) status code indicates that the request has succeeded.” What the body contains depends on the request method. For the methods that matter for pages — GET and HEAD — the content is a representation of the target resource. The RFC also qualifies this: aside from responses to CONNECT, a 200 is expected to carry content unless the message framing explicitly signals zero length — so “a 200 always has a body” is a shorthand, not an absolute. In practice, for a page you want indexed, that shorthand is the target: a real body, not an empty one. A 200 is also “heuristically cacheable” by default unless a cache-control directive says otherwise, which is why validator headers like ETag and Last-Modified matter on pages that get re-crawled a lot. Evidence for this claim RFC 9110 defines 200 OK as indicating that the request succeeded; the response content depends on the request method. Scope: HTTP semantics for 200 responses; this does not guarantee search indexing. Confidence: high · Verified: 2026-07-14 IETF: RFC 9110 §15.3.1 — 200 OK

Technically speaking, 200 isn’t only for pages. The RFC lays out what “success” means per method:

For non-GET methods you’ll often not see a 200 — MDN notes successful PUT or DELETE requests “often do not result in a 200 OK response,” with 201 Created or 204 No Content being more common. None of that is SEO-relevant for page URLs; the one line to carry forward is that for a document you want indexed, 200 with a real body is the target.

Necessary, not sufficient, for indexing

This is the single most important thing to get right, and it’s where most competing glossary pages are flatly wrong. They say “200 means the page gets indexed.” Google’s own documentation says otherwise. For a 200, Google “passes on whatever it received to the next processing step… For Google Search, the next system is the indexing pipeline. The indexing systems may index the content, but that’s not guaranteed.” Evidence for this claim Google passes a 2xx response to its indexing pipeline, which may index the content but does not guarantee that it will do so; error-like content can be classified as a soft 404. Scope: Google Search handling of 2xx page responses and soft 404s. Confidence: high · Verified: 2026-07-14 Google: HTTP status codes and Search

So the 200 is a contract about the HTTP response, not a promise about the page’s fate in Search. After the 200, Google independently evaluates:

• Quality — thin, low-value, or auto-generated pages may not be indexed.
• Duplication — a near-duplicate of a stronger URL may get folded into that URL rather than indexed on its own (this is what the canonical-tag exists to control).
• Directives — a noindex in a meta tag or X-Robots-Tag header keeps the page out even with a perfect 200.

Patrick’s Ahrefs guide draws the same line at the family level: “Most 2xxs will allow pages to be indexed. However, 204s will be treated as soft 404s and won’t be indexed.” The 200 makes a page eligible; it doesn’t make it indexed.

The soft 404 trap

The sharpest illustration of “200 isn’t the whole story” is the soft 404. Google’s status-codes doc spells out the mechanism: “If the content suggests an error for Google Search, an empty page or an error message, Search Console will show a soft 404 error.” Notice what that means — the classification is based on the rendered content, not the HTTP code. Google’s indexing pipeline looks past the 200 at what’s actually on the page, and if it reads like “not found,” it’s bucketed and reported like a real 404.

The gut-check cases: a discontinued product whose page now loads an empty template, a deleted article that still returns a 200 shell, a filtered category page or search result with zero items and a “nothing here” message. Each returns a technically correct 200 while telling both users and Google there’s nothing to see.

This site has a dedicated soft-404-errors article for the detection mechanics and fixes — I won’t re-run them here. The takeaway for the 200 discussion is simply: returning 200 on a page that’s genuinely gone is the setup for a soft 404. The fix is to make the code match reality.

A related trap: transport success isn’t application success

Worth a bounded aside since it comes up in API and monitoring circles: the HTTP layer and the application layer can disagree. An API endpoint can send 200 with a JSON error object sitting in the body; a page can send 200 while a backend dependency failed silently and rendered a broken block instead of the real content. The status line says “delivered fine” — that’s all it’s claiming. Whether the payload is actually correct is a separate question the status code doesn’t answer. Practitioners are genuinely split on whether an API should signal an error with a non-200 status or with a 200 wrapping an error payload; that’s a contract each team chooses, not an HTTP rule. For this site’s SEO focus, the page-level version of the same problem is the soft 404 above — the fix is the same in spirit: don’t trust the status line alone, look at what the body actually contains.

200 vs. 204 vs. 304 — don’t conflate them

Three codes people mix up, and only one of them is the “here’s your page” success:

204 is a genuine success code, but its empty body gives a crawler nothing to index — so on a page URL it lands in the soft-404 bucket (that’s a separate article; don’t confuse the empty-body case with a normal 200). 304 isn’t even in the same family — it answers a conditional request (If-None-Match / If-Modified-Since) by telling the client its cached copy is still current. It carries no body and says nothing about whether to index; it’s a crawl-efficiency mechanism, not a duplicate-of-200. The common “200 vs 304, aren’t those the same?” question conflates a caching optimization with a success response.

Confirm what Googlebot actually sees

Here’s a gap almost every competing article skips: different requesters can get different codes for the same URL. Your browser can see a clean 200 while Googlebot gets something else — sometimes deliberately (cloaking, which is a spam violation under Google’s Search Essentials), more often accidentally through WAF/bot-blocking rules, geo-IP targeting, CDN edge logic, or an A/B-testing setup that misfires for bots.

So “it’s 200 in my browser” is not proof “Google sees 200.” The correct diagnostic is to check what Googlebot itself received:

• GSC URL Inspection — run a Live Test to see the status and rendered content Google fetches, not what your machine sees.
• Server / CDN logs — the ground truth for what code each user-agent actually got.

A plain curl -I from your terminal is useful, but it’s just one more requester that can hit different edge rules than Googlebot — treat it as a data point, not the final word.

How to check and monitor 200s

• Browser DevTools — Network tab, reload, click the document request, read the Status column.
• Command line — curl -I https://example.com/page for a single request’s headers, curl -IL to follow the redirect chain.
• Google Search Console — URL Inspection reports the crawled status and lets you Live Test.
• Bing Webmaster Tools — its URL Inspection tool is the Bing-side way to confirm what Bingbot received. (Bing doesn’t publish a dedicated “how status codes affect indexing” doc the way Google does — I’d rather say that than invent a Bing policy statement.)
• Crawlers — Screaming Frog and Ahrefs Site Audit surface status codes across the whole site in bulk; the free Ahrefs SEO Toolbar shows the code for the page you’re on.

What “healthy” looks like: your important, canonical URLs consistently return 200 with real content, and the pages that should be gone or moved return 404/410 or a 301 instead of a misleading 200.

The decision, in one line

Match the code to reality. Wanted in the index → 200 with substantive content. Gone for good → 404 or 410 (see 404-not-found). Moved → 301. A duplicate of another URL → point a canonical tag at the preferred version rather than trying to force a non-200 code. The 200 is the green light for pages that genuinely deserve one — nothing more, nothing less.

AI summary

A condensed take on the Advanced version:

• 200 OK is the standard 2xx success code (RFC 9110 §15.3.1): the server fulfilled the request and, for GET/HEAD, the body represents the resource. It’s heuristically cacheable by default. The RFC frames a body as expected, not absolute — a zero-length 200 is technically valid, though a page you want indexed needs a real one.
• Necessary, not sufficient, for indexing. Google’s own doc says the indexing systems “may index the content, but that’s not guaranteed.” Quality, duplication, thin content, and noindex are all judged on top of the 200. Most competing pages get this wrong by saying “200 = indexed.”
• The soft 404 trap: a 200 wrapped around error/empty content gets detected at the content layer and reported as a soft 404 in Search Console — “if the content suggests an error… Search Console will show a soft 404 error.” A 200 on a genuinely gone page is the setup for this. See the soft-404-errors article.
• A parallel trap: the HTTP layer and the application layer can disagree — a 200 can wrap an API error payload or a silently broken backend block. The status line only claims the transport succeeded, not that the payload is correct.
• 200 vs 204 vs 304: 200 = success with a real body (eligible for indexing); 204 = success with an empty body, treated like a soft 404 on page URLs (see 204-no-content); 304 = a caching signal answering a conditional request, not an indexing decision.
• Confirm what Googlebot got. Different requesters can see different codes for one URL via cloaking, bot-blocking, geo rules, or CDN/WAF config. “200 in my browser” ≠ “Google sees 200.” Check via GSC URL Inspection Live Test or server logs, not just a browser or curl.
• Match the code to reality: wanted → 200 with real content; gone → 404/410; moved → 301; duplicate → canonical tag. As Patrick puts it, “200 OK – All good. Everything is successful” — for a page that genuinely deserves to be there.

Official documentation

Primary-source references for what 200 is and how Google handles it.

HTTP spec & browser reference

• RFC 9110 §15.3.1 — 200 OK — the authoritative definition: request succeeded, per-method body semantics, heuristic cacheability.
• MDN — 200 OK — plain-language framing, cacheable-by-default, and the PUT/DELETE nuance (201/204 are common instead).

Google Search Central

• How HTTP status codes, and network and DNS errors, affect Google Search — the 2xx handling language (“may index the content, but that’s not guaranteed”) and the soft-404 cross-reference.
• Soft 404 errors — Page indexing report — Google’s own definition of the 200-that’s-really-an-error and why returning a success code for a gone page is a bad practice.
• Cloaking — why a URL can serve one code/content to users and a different one to Googlebot, and why that’s a violation when done to manipulate rankings.

Bing / Microsoft

• Bing Webmaster Tools — URL Inspection — the Bing-side way to confirm the HTTP response Bingbot received for a URL. (No Bing-authored “how status codes affect indexing” doc exists.)

Quotes from the source

On-the-record statements. Each link is a deep link that jumps to the quoted passage on the source page.

The HTTP spec

• “The 200 (OK) status code indicates that the request has succeeded.” — RFC 9110, HTTP Semantics, §15.3.1. Read the section

MDN Web Docs

• “The HTTP 200 OK success status response code indicates that a request has succeeded. A 200 OK response is cacheable by default.” Jump to quote

Google Search Central — 2xx / 200 handling

• “Google passes on whatever it received to the next processing step (which is product specific). For Google Search, the next system is the indexing pipeline. The indexing systems may index the content, but that’s not guaranteed.” — Google’s HTTP status codes doc, the 200 entry. Google’s status-code doc

• “If the content suggests an error for Google Search, an empty page or an error message, Search Console will show a soft 404 error.” — same doc, the soft-404 cross-reference. Google’s status-code doc

Patrick Stox — Ahrefs

• “200 OK – All good. Everything is successful.” — from my HTTP Status Codes guide on the Ahrefs blog. Jump to quote

• “Most 2xxs will allow pages to be indexed. However, 204s will be treated as soft 404s and won’t be indexed.” — from the same guide, on how Google handles the 2xx family. Jump to quote

200 OK — quick reference

What it is

200 vs. its confused siblings

Which code should this URL return?

• Wanted in the index → 200 with real, substantive content.
• Gone for good → 404 or 410 (see 404-not-found).
• Moved to a new URL → 301.
• Duplicate of another URL → keep the 200, add a canonical tag to the preferred version.
• Empty on purpose (API/beacon) → 204 (see 204-no-content) — never on a page.

Fast facts

• A 200 makes a page eligible for indexing, not indexed — Google decides separately based on quality, duplication, thin content, and noindex.
• A 200 on a page that’s actually gone/empty is a soft 404 in Google’s eyes.
• Different requesters can see different codes for one URL — confirm what Googlebot got via GSC URL Inspection or server logs, not just a browser or curl.
• Check codes with: DevTools Network tab, curl -I / curl -IL, GSC/Bing URL Inspection, Screaming Frog, Ahrefs Site Audit/Toolbar.

Common myths about 200 OK

“A 200 status code means the page is indexed.” False. 200 means the server successfully returned content; indexing is a separate downstream decision. Google’s own doc says the indexing systems “may index the content, but that’s not guaranteed.” Quality, duplication, thin content, and noindex are all judged on top of the 200.

“If Search Console shows a soft 404, my server has a bug.” Not necessarily. Soft 404 isn’t a code your server sends — it’s a label Google applies based on the mismatch between the 200 status and content that reads like an error or empty page. The server is doing exactly what it was configured to do (sending 200); the content is the problem, not the header.

“200 is always good, full stop.” Not always. A 200 on a URL that should have 404’d — a deleted product, an expired listing, an empty search-results page — is actively bad. It invites soft-404 treatment and can waste crawl effort revisiting a URL with nothing to offer.

“My browser shows 200, so Google definitely sees 200 too.” Not guaranteed. Bot-blocking, cloaking, geo-IP rules, and CDN/WAF configuration can serve Googlebot a different response than a human browser gets. Verify via URL Inspection or server logs.

“200 and 204 are basically the same — both mean success.” Both are 2xx, but 204 has an empty body by design. That’s fine for APIs and beacons and wrong for a page you want indexed — a 204 on a page URL gets treated like a soft 404 (see 204-no-content).

“200 vs 304 — aren’t those the same idea?” No. 304 Not Modified is a caching mechanism answering a conditional request (If-None-Match / If-Modified-Since), telling the client to use its cached copy. It carries no body and isn’t an indexing decision — a different concept from a 200.

Why a 200 OK page still fails

Search Console calls the URL a soft 404

Symptom: The URL returns 200, but Page Indexing reports it as a soft 404.

Likely cause: The response body looks empty, broken, or like an error page. Common cases are a discontinued product with no useful product information, a deleted article inside an otherwise complete template, or a zero-result search page.

Fix: Match the response to reality. Restore substantive content if the page should exist, return 404 or 410 if it is gone, or use a 301 if it moved. Re-run URL Inspection’s live test and confirm that the response and rendered content now agree.

Your browser gets 200 but Googlebot does not

Symptom: DevTools or curl shows 200, while Google cannot fetch or index the URL.

Likely cause: A CDN, WAF, geo rule, bot rule, or experiment serves Googlebot a different response. Your own request is not proof of Google’s request.

Fix: Compare a normal request with a Googlebot-user-agent request, then check URL Inspection and server/CDN logs. Correct the edge rule and confirm the live test receives 200 with the same substantive body users receive.

The page is 200 but still is not indexed

Symptom: The status code is healthy, yet the URL remains excluded from the index.

Likely cause: 200 only makes the content eligible for processing. A noindex, duplicate/canonical conflict, or low-value content can still keep it out.

Fix: Stop changing the status code. Check indexing directives, the Google-selected canonical, and the actual content. A successful HTTP response is not an indexing verdict.

200 responses that tell the wrong story

These are simplified examples. The status line is technically successful, but the body determines whether that success is honest.

Empty product shell: misleading 200

HTTP/1.1 200 OK
Content-Type: text/html

<h1>Product unavailable</h1>
<p>There is nothing here.</p>

If the product is permanently gone with no replacement, return 404 or 410. If a useful product page remains—specifications, alternatives, support, or availability information—a 200 can still be appropriate because the page has a real purpose.

Deleted article with a replacement: use a redirect

HTTP/1.1 301 Moved Permanently
Location: https://example.com/current-guide

A templated 200 page saying “article deleted” strands users and invites a soft-404 classification. A relevant replacement should be the destination of a server-side 301.

Zero-result internal search: useful or empty

A 200 can be honest when the page helps users reformulate the search, browse categories, or find alternatives. A thin page containing only “0 results” looks like an error despite the success code. The distinction is the usefulness of the body, not the number 200.

Triage suspicious 200 responses

Paste a crawl export with URL, status, title, canonical, indexability, and a short body-text sample. This prompt separates HTTP success from content and indexing problems.

You are auditing URLs that return HTTP 200. Review the pasted rows without assuming that
"200" means "indexed" or "healthy."

For each URL:
1. Classify it as a substantive page, likely soft 404, redirect-needed page, genuinely gone
   page, duplicate/canonical case, or needs manual review.
2. Cite the exact evidence from the supplied title, body sample, canonical, and directives.
3. Recommend one response: keep 200, restore content, 301 to a relevant replacement,
   return 404/410, or fix canonical/noindex signals.
4. Flag any conclusion that cannot be made from the supplied data.

Do not invent page content, redirect targets, or indexing status. End with a prioritized
manual-check list.

PASTE CRAWL ROWS HERE

Check the response instead of trusting the page

Inspect one response with curl

Run these in macOS, Linux, or WSL. The first command reads the response headers; the second downloads the body as well so you can verify that 200 contains real content.

curl -sI https://example.com/page
curl -sS -D - https://example.com/page -o page.html

Look for a 200 status line, then open page.html. Headers alone cannot expose a soft 404.

Compare a normal request with a Googlebot user agent

url="https://example.com/page"
curl -sS -o /dev/null -w "default: %{http_code} %{size_download} bytes\n" "$url"
curl -sS -A "Googlebot" -o /dev/null -w "Googlebot UA: %{http_code} %{size_download} bytes\n" "$url"

A difference is a reason to inspect CDN/WAF rules and logs, not proof that Googlebot itself received the spoofed request’s response. Confirm the real fetch in URL Inspection.

Check a list for non-200 responses

Put one URL per line in urls.txt:

while IFS= read -r url; do
  curl -sS -o /dev/null -w "%{http_code}\t%{url_effective}\n" "$url"
done < urls.txt

This finds obvious status mismatches. It cannot judge whether a 200 body is substantive, so follow up on suspicious templates and soft-404 reports.

Tools for validating 200 responses

Patrick’s free tool

• Bulk HTTP Status Code Checker — paste up to 500 URLs to collect status codes, final destinations, redirect chains, and latency in one export. Use it to find URLs that are not actually returning 200; then inspect the body and Search Console separately for soft 404s because a status checker cannot judge content quality or indexation.

Search-engine and server evidence

• Google Search Console URL Inspection — compare the indexed result with a live fetch and review the rendered content Google can retrieve.
• Bing Webmaster Tools URL Inspection — check the response Bingbot reports receiving.
• Server and CDN logs — confirm which status code real crawler requests received; logs are stronger evidence than changing a user-agent string in curl.
• Browser DevTools Network panel — verify the document request, response headers, and body for the browser session in front of you.

Test yourself: 200 OK

Five quick questions on what a 200 means for SEO. Pick an answer for each, then check.

200 OK

HTTP 200 OK is the standard 2xx success status code, meaning the server received, understood, and fulfilled the request and is returning the resource. It's the code every page you want indexed should return — but a 200 alone doesn't guarantee Google will index the page.

Related: 204 No Content, Soft 404, Not found (404)

200 OK

HTTP 200 OK is the standard success-class (2xx) status code, defined in RFC 9110 §15.3.1 (HTTP Semantics). It means the server received, understood, and fulfilled the request — and, for the GET and HEAD methods that matter for web pages, the response body is a representation of the requested resource. MDN puts it plainly: “The HTTP 200 OK success status response code indicates that a request has succeeded. A 200 OK response is cacheable by default.”

For SEO, 200 is the code every URL you want in the index should return, with real, substantive content in the body. But it is necessary, not sufficient: Google still decides separately whether to index the content behind that 200. Google’s own documentation says the indexing systems “may index the content, but that’s not guaranteed” — quality, duplication, thin content, and directives like noindex are all evaluated on top of the status code.

The sharpest illustration is the soft 404: a URL that returns 200 but whose rendered content reads like an error, an empty page, or a “not found” message. Google detects this at the content layer regardless of the HTTP code and reports it as a soft 404 in Search Console, treating it like a real 404. So a 200 on a page that’s actually gone is a bug, not a green light — if a page is gone use 404 or 410, if it moved use a 301, and if it’s a duplicate use a canonical tag. Contrast 200 with 204 (a 2xx success with an empty body, also treated like a soft 404 on page URLs) and with 304 Not Modified (a caching signal, not an indexing decision).

Related: 204 No Content, Soft 404, Not found (404)

Changelog