200 OK: when success is (and isn’t) enough for SEO

200 OK is the standard success response: the request worked and the server is returning what was asked for. For a web page, that’s the HTML. It’s the status every page you want in search results should return, but a 200 on its own doesn’t prove a page is healthy or indexable.

What 200 means

RFC 9110, section 15.3.1 says a 200 indicates that the request succeeded, and what the response contains depends on the method: for GET, a representation of the resource; for HEAD, the same headers without a body; for POST, the result of the action. A 200 is cacheable by default, so browsers and CDNs may store it unless Cache-Control says otherwise.

How Google treats a 200

Google’s guide to HTTP status codes and network errors says Googlebot passes 200 content on to the indexing pipeline, which may index it, but indexing isn’t guaranteed. A page can answer 200 and still stay out of results because of:

• a noindex robots meta tag or X-Robots-Tag header;
• a canonical tag pointing to another URL;
• content that looks like an error, which Google may report as a soft 404;
• thin or duplicate content that Google decides not to index.

The soft 404 problem

A soft 404 is a page that says “not found,” “no results” or “this product is no longer available” while the server answers 200 OK. Visitors see an error; crawlers are told it’s a success. Google flags many of these in Search Console’s Page indexing report, and they waste crawling on empty pages. Typical sources:

• custom error templates that never set the status code;
• single-page apps where every route returns the same 200 shell;
• empty internal search or category pages;
• expired listings left online with a one-line notice.

Fix them by returning 404 or 410 when the content is gone, a 301 when a true replacement exists, or real content when the page should exist.

Other 200 pitfalls

Too many URLs answering 200. If http:// and https://, www and non-www, trailing-slash and parameter variants all return 200 with the same page, you create duplicate content. Pick one version, redirect the others and add a self-referencing canonical.

Login walls and error messages served with 200. A members area that shows a login form at the page URL, or a database error printed into a 200 page, can end up indexed as junk. Protected areas should answer 401, and failures a 5xx code.

Setting the right status in code

// PHP: set the status before any output
http_response_code(404);

// Express
res.status(404).render('not-found');

How to check

Run your key URLs through the HTTP status checker to confirm each one returns 200 directly rather than after a redirect. Then use the indexability checker to see whether robots rules, noindex or a canonical override that 200. A healthy response looks like this:

HTTP/2 200
content-type: text/html; charset=utf-8
cache-control: public, max-age=300
etag: "6a1f-5e2c"
last-modified: Tue, 27 Oct 2026 09:12:44 GMT
vary: Accept-Encoding

Frequently asked questions