Every server response comes with a three-digit status code, and Google reads every single one of them. Most developers know the basics, but from an SEO standpoint the nuances between a 301 and a 302, or a 404 and a 410, change how Google handles your pages, passes PageRank, and allocates crawl budget. Here is what matters in practice, and what to do when things go wrong.

200 OK — The Baseline

A 200 means the page exists and loaded successfully. It is the expected state for every page you want indexed. If a page returns 200 but carries a noindex directive in the HTTP header or meta tag, Google will still crawl it — it just will not add it to the index. This distinction matters: crawling and indexing are separate events. A page can be crawled indefinitely without ever being indexed if the noindex signal is present.

Clean 200s paired with correct robots.txt rules, canonical tags, and meta robots directives are the foundation of a crawlable site. Without 200 responses on your target pages, nothing else you do technically matters.

301 Moved Permanently

A 301 tells Google and every other crawler that a URL has permanently moved to a new location. PageRank passes through a 301, though there is evidence of a small signal loss in the transfer — especially through redirect chains. Use 301s when you rename a page, restructure your URL paths, migrate to HTTPS, or move to a new domain.

The destination of a 301 should always be a live 200 page. A redirect chain (301 pointing to another 301 pointing to a 200) wastes crawl budget and compounds the signal loss. Audit your redirects regularly and collapse any chain longer than one hop into a direct redirect from origin to final destination. I cover the full distinction between redirect types in my post on 301 vs 302 redirects.

302 Found (Temporary Redirect)

A 302 means the resource has temporarily moved. Google typically does not transfer PageRank for a 302 — it keeps the original URL indexed and treats the destination as transient. That is the correct behavior for A/B tests, short-term campaigns, or maintenance pages. It is wrong for permanent site changes.

The most common mistake I see: agencies reaching for 302s out of caution, worried that making a 301 permanent is risky to reverse later. In practice, this is backwards. If a URL change is permanent, use a 301. If you ever need to revert, you simply change the redirect target — Google will update accordingly within a few crawl cycles. A 302 on a permanent change means the original URL stays indexed, link equity does not consolidate, and you end up with two competing URLs.

404 Not Found

A 404 means the page does not exist. Google will eventually drop a 404 from the index, but it keeps re-crawling the URL for a period before removing it — Google wants to confirm the absence is not a temporary server glitch. True 404s on URLs that were never public are fine. The problem is when important live pages accidentally return 404 after a migration, a CMS update, or a plugin change.

Prioritize 404 fixes for URLs that have inbound backlinks, appear in your sitemap, or were recently live pages with organic traffic. Redirect those URLs with a 301 to the closest relevant page. Do not redirect everything to the homepage — Google interprets homepage redirects from unrelated URLs as soft 404s and does not pass equity.

410 Gone

A 410 explicitly tells Google the resource is permanently gone and will not return. Google processes 410s faster than 404s — it drops them from the index more quickly rather than recrawling to verify. This is the right code for discontinued products, removed services, or deleted thin content you do not want Google spending crawl budget rechecking.

Most CMS platforms default to returning 404 for deleted content. If you are deliberately removing pages and want Google to stop indexing them quickly, configure a 410 response. It signals intent clearly rather than leaving Google to infer permanence from repeated 404 responses over weeks.

5xx Server Errors

500-level errors (500 Internal Server Error, 503 Service Unavailable, 504 Gateway Timeout) tell Google the server failed to respond to the request. Occasional 503s during planned maintenance are acceptable — Google expects temporary downtime. A proper maintenance 503 should include a Retry-After HTTP header specifying when the server will be back, so Google knows not to drop the pages from its index.

Chronic 5xx errors are a serious problem. If Googlebot repeatedly encounters 5xx responses, it reduces its crawl rate for your site and can eventually begin dropping pages. Monitor your server error rate in Search Console under Crawl Stats. A sudden spike in 5xx errors in Crawl Stats is a signal to check your hosting infrastructure and application logs immediately.

How to Audit Status Codes

Screaming Frog, Ahrefs Site Audit, and Semrush all crawl your site and report status codes per URL. Run a full crawl monthly on active sites. Cross-reference your 404 report against your inbound links — any 404 that has backlinks pointing to it is PageRank you are leaving on the table. Redirect those URLs to relevant live pages.

In Search Console, the Pages report under Indexing surfaces crawl errors by type. It flags redirect errors, server errors, and not-found pages that Google has encountered. This is your ground truth for what Googlebot actually sees, because your local crawler and Googlebot may behave differently depending on IP blocks, geolocation rules, or rendering timing. Pair Search Console data with a crawler run to get the full picture.

Common Mistakes I See on Audits

  • Redirecting all deleted pages to the homepage instead of the closest relevant category page
  • Using 302s for permanent redirects because the developer was not sure it was permanent
  • Ignoring soft 404s — pages that return 200 but serve empty or near-empty content
  • Letting redirect chains grow to three or four hops as the site evolves over years
  • Not monitoring 5xx rates in Crawl Stats until ranking drops force an investigation
  • Serving 410 correctly in development but defaulting back to 404 in production because the CMS overrides the custom error handler

What to Do First

If you have never audited your status codes, start with Search Console’s Pages report. Export the error categories, filter for high-priority URLs (linked, sitemapped, or recently live), and build a redirect map. Prioritize by value: high-traffic pages, pages with backlinks, pages from your primary navigation. Work through the list systematically before touching lower-priority noise URLs.

Status codes are one of the most mechanical parts of technical SEO, but they are also one of the most commonly misconfigured. If you want a complete picture of how your site is signaling to Google at the server level, a technical website audit surfaces status code issues alongside crawl, indexation, and rendering data in one prioritized report rather than separate crawl passes.