How to audit HTTP status codes for SEO

Every time Googlebot requests one of your pages, your server hands back a three-digit HTTP status code. That number tells Google whether the page exists, whether it moved, whether it's temporarily down, or whether the server gave up entirely. Get it wrong and you'll see pages dropped from the index, link equity vanishing into redirect chains, and crawl budget burned on URLs that don't deserve it.

This guide sticks to the status codes that actually matter for SEO - not the academic list of all 60+. Four categories, a handful of codes per category, and a working tool so you can check any URL without leaving this page.

Check any URL right now

Paste any URL below. You'll see the status code, the full redirect chain, and any hops that burn crawl budget.

The four categories of HTTP status codes

Every status code falls into one of five buckets, keyed by the first digit. For SEO, you can safely ignore the 1xx range - it's reserved for in-progress handshake signals you'll never emit on purpose. That leaves four groups:

• 2xx - Success. The request worked. 200 OK is what you want on every canonical, indexable page.
• 3xx - Redirection. The resource moved. 301 = permanent, 302 = temporary. SEOs live and die by the difference.
• 4xx - Client errors. Something is wrong with the request, usually that the URL doesn't exist (404) or is blocked (403).
• 5xx - Server errors. The server broke. Frequent 500s or 502s during Googlebot crawls signal unreliability.

The codes you absolutely need to know

200 OK

What to look for in an audit: any page in your top-impressions list (Search Console) that does not return 200. That's a ranking page bleeding equity. The trap: a page can return 200 and still be quietly excluded from the index - robots.txt disallow, a stray noindex tag, or a canonical pointing somewhere else will all do it. So the rule isn't "everything returns 200" - it's "every page you want indexed returns 200 and has nothing else blocking it."

301 Moved Permanently

Where it goes wrong: site migrations and slug renames where someone reaches for 302 "to be safe". A 301 consolidates the old URL's ranking signals onto the new one - without it, the equity stays stuck on a URL that's about to be deleted. Audit move: every redirect on your site that's been in place >30 days should be a 301. If it's a 302, it's leaking ranking signals every day it lives.

302 Found (temporary)

The single most common SEO own-goal. Many frameworks (Next.js, Express, older PHP) default to 302 for redirect helpers, so devs ship them by accident. Google reads 302 as "this move is temporary - keep the old URL in the index" and never transfers equity. If you're auditing a site and you find permanent moves serving 302s, that's almost always your highest-ROI fix on the page: flip them to 301 and watch the new URLs start to rank within weeks.

404 Not Found vs 410 Gone

Use the wrong one and Google keeps re-crawling pages that aren't coming back, burning crawl budget that should go to your live pages. The decision rule:

• Page should exist but is broken right now (routing bug, DB outage) → 404. Google will keep checking.
• Page is gone on purpose and isn't coming back (deleted product, retired blog post, deactivated user) → 410. Google drops it from the index much faster.

Audit move: when you bulk-delete URLs (a discontinued product line, an archived category), serve 410 on the deleted set instead of letting them all 404 - you'll free up crawl budget within days instead of months.

503 Service Unavailable

Where teams get burned: deploys, planned maintenance, and aggressive rate-limiting against bots. If Googlebot hits 500s during a multi-hour window, it can drop pages from the index. Audit move: any planned downtime should serve 503 with a Retry-After header - that combination tells Google "back off, try later" instead of "this site is broken." Same for rate-limit responses you serve to crawlers: a clean 503 beats a 500 or a connection timeout every time.

The biggest mistake: redirect chains

Redirect chains are where status-code hygiene goes to die. They almost always come from history nobody owns: someone renamed /blog/seo-tips to /articles/seo-tips two years ago. Then last quarter the marketing team consolidated it under /learn/seo-tips. Now the original URL hits two redirects before it lands. Multiply by every URL change a 5-year-old site has ever shipped and you have a quiet, compounding crawl-budget tax.

Each extra hop does three things:

1. Burns crawl budget. Googlebot follows the chain, eating requests that could have gone to your new content.
2. Loses link equity. A small percentage at each hop. Three hops can quietly cost you ~15% of the original PageRank.
3. Slows the user down. Each hop is a round-trip, which directly hits your Core Web Vitals.

The fix is mechanical: for every chain like /a → /b → /c, rewrite the source rule so /a jumps straight to /c. Don't delete the intermediate redirect - backlinks may still point at /b - just make sure no chain is more than one hop. The URL checker above renders the entire chain inline, which is the fastest way to find them on your own URLs.

What a clean status-code audit looks like

The full audit takes about 30 minutes for a site under 5k pages. Run it quarterly, plus immediately after any migration or platform change.

1. Sample your top 20 pages. Pull the top 20 by impressions from Search Console. Run each through the checker above. Every one must return 200 in zero hops. Any that don't are the highest-priority fixes - these are pages already earning rankings.
2. Walk your top 50 redirects. Pull your redirect rules (Nginx config, vercel.json, _redirects, whatever owns them). Spot-check the 50 with the most traffic. Each should resolve to a 200 in exactly one hop. If the destination 301s again, you have a chain - fix it at the source.
3. Verify your 404 page. Visit a URL that definitely doesn't exist (e.g. /this-does-not-exist-12345) and check the actual status code, not what the page says. Many CMSes render a "Page not found" template with a 200 response - a soft 404 that confuses Google and wastes crawl budget. The fix is usually a one-line server config change.
4. Audit your 301 vs 302 ratio. In your CMS or framework, search the codebase for 302 and res.redirect(. Anything that's a permanent move should be a 301. This is the single most common quick-win in technical SEO audits.
5. Monitor 5xx rates in Search Console. A handful of 5xx responses during a crawl is normal. Chronic 5xx rates above ~1% are a reliability signal Google will penalize you for. Set a recurring alert in your monitoring tool, not a one-time check.

Grab the one-page checklist

A printable version of the full audit above, plus the exact code snippets for Nginx and Apache to serve each of the key status codes correctly.

Quick quiz: are you ready to audit your own site?

Five questions, takes two minutes. We'll show you the right answer and a one-line explanation after each one.

Next up in Technical SEO

Status codes are the most direct technical signal you can control, but they're just the entry point. From here, the rest of the Technical SEO pillar covers:

• robots.txt - what it actually controls (and what it doesn't).
• XML sitemaps - why a broken one is worse than none.
• Crawlability vs indexability - the two checks Google makes before your page can rank.
• Mixed content and HTTPS - the audit that takes 30 seconds and often reveals a year's worth of debt.