Every time a browser or crawler requests a URL, the server replies with a three-digit status code before any content. The code says whether the page loaded (2xx), moved (3xx), was not found or not allowed (4xx), or failed on the server side (5xx). Search engines rely on these codes to decide what to index, what to drop, and how fast to crawl, so a wrong code can undo good content.
The five classes
Status codes are defined in RFC 9110. The first digit gives the class.
- 1xx Informational: interim responses, rarely relevant to SEO
- 2xx Success: 200 OK means the content is served and can be indexed
- 3xx Redirection: 301 and 308 are permanent, 302, 303 and 307 are temporary, 304 Not Modified tells the client its cached copy is still valid
- 4xx Client error: 404 Not Found, 410 Gone, 403 Forbidden, 429 Too Many Requests
- 5xx Server error: 500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable
How Google reacts to each class
Google's documentation describes the behavior. A 2xx response passes content on to indexing, though a 200 does not guarantee indexing. 3xx responses are followed, up to 10 hops. 4xx responses (except 429) mean the URL is not indexed, and previously indexed URLs are gradually removed; 404 and 410 are handled very similarly. 5xx responses and 429 cause Googlebot to slow its crawl rate temporarily, and URLs that keep returning server errors are eventually dropped from the index.
That makes 503 the right answer for planned maintenance: it signals a temporary problem rather than a missing page. Adding a Retry-After header tells clients when to come back.
HTTP/1.1 503 Service Unavailable
Retry-After: 3600
Content-Type: text/htmlSoft 404s and other mismatches
A soft 404 is a page that returns 200 but shows an error or empty state, such as "No results found" or "This page doesn't exist". Google tries to detect these and treats them like 404s, but it reports them as a problem in Search Console because the server is sending the wrong signal.
Single-page apps are especially prone to this. A client-side router can show a not-found screen while the server still answers 200 for every path. The fix is returning a real 404 from the server, or, if that is not possible, adding a noindex robots meta tag to the error view.
Checking status codes
Use a crawler for sitewide checks, curl -I for single URLs, and the URL Inspection tool in Search Console to see what Googlebot received. Browser developer tools show the code in the Network tab, but note that a service worker or cache can mask what the server really sends.
Example
A marketplace that returned 200 for everything
Picture a SaaS integrations marketplace, built as a client-side app, at apps.example.com/integrations/[name]. When an integration is retired, the app shows a friendly "not available" message but the server still answers 200. Over time, hundreds of retired listings sit in Google's index as near-empty pages.
Moving the listing page to server rendering lets the server return 404 (or 410) for retired slugs and 301 for renamed ones, and the index cleans itself up as Google recrawls.
Common mistakes
Serving errors with a 200
Error and empty-state pages should send an error status. A 200 tells crawlers the page is real content.
Using 404 or 500 for maintenance
Planned downtime should return 503 with Retry-After so crawlers know to come back rather than drop pages.
Blocking crawlers with 403 by accident
Bot protection and WAF rules sometimes return 403 to Googlebot or other legitimate crawlers. Check your firewall logs after enabling new rules.
Questions
Both lead to removal. Google has said it treats them almost the same; 410 may be processed slightly faster. Use whichever your stack makes easiest, as long as removed pages stop returning 200.
No. A 200 makes a page eligible. Google still decides whether to index it based on quality, duplication and other signals.
It tells a crawler that sent a conditional request that the page has not changed since its last fetch, so it can skip downloading it. Supporting it can make crawling more efficient.
