A working reference for the status codes that affect crawling and indexing.
HTTP status codes are the server responses that tell a crawler the state of a URL: 200 means OK, 301 a permanent redirect, 302 a temporary one, 404 not found, 410 gone, and 5xx a server error. For SEO agencies, each code signals whether a page can be crawled, indexed, or needs a fix.
What do the HTTP status code classes mean for SEO?
Status codes group into five classes, and each class changes how a search engine treats the URL. The 2xx class confirms a page returned successfully and is a candidate for indexation.
The 3xx class signals redirection, where the distinction between permanent and temporary is the part most likely to leak ranking signals if it is wrong. The 4xx class marks client errors such as missing or removed pages, and the 5xx class marks server errors that can pause crawling if they persist.
- 2xx (success): 200 OK is the normal indexable response; 204 returns no content
- 3xx (redirection): 301 permanent, 302 and 307 temporary, 304 not modified
- 4xx (client error): 404 not found, 410 gone, 401 and 403 access blocked, 429 rate limited
- 5xx (server error): 500 internal error, 503 service unavailable, 502 and 504 gateway issues
How do HTTP status codes affect crawling and indexation?
A search engine has to interpret the response before it can decide what to do with the URL.
A 200 lets the page enter the indexation pipeline, a 301 passes most signals to the redirect target and consolidates them over time, and a 404 or 410 tells the engine to drop the URL, with 410 read as a stronger removal signal than 404.
Repeated 5xx responses can slow or pause crawling for a site because the crawler treats them as a sign the server is under strain.
- 200: eligible for indexation if the page is otherwise allowed
- 301: consolidates ranking signals to the target over repeated crawls
- 302 used for a permanent move: risks signals staying on the old URL
- Persistent 5xx: can reduce crawl rate and drop affected URLs from the index
How do you diagnose status code problems on a client site?
Diagnosis starts with separating intended responses from accidental ones.
Pull the status code for every important URL, then look for the patterns that signal a problem: 301 chains and loops, internal links pointing at redirected or 404 URLs, soft 404s where a thin or empty page returns 200, and canonical tags that point at a non-200 URL.
Cross-reference crawl errors in Google Search Console with a fresh crawl, because a code reported weeks ago may already be resolved or may have moved.
- Map redirect chains and loops, and flatten chains to a single hop
- Find internal links that resolve to 3xx or 4xx and repoint them at the live URL
- Catch soft 404s: a missing page should return 404 or 410, not 200
- Confirm every canonical tag points at a 200 URL, not a redirect or error
What is the fix workflow for each status code?
Each code maps to a defined action, which is what makes a reference page useful during delivery. A permanent move uses a single 301 to the closest relevant page rather than a blanket redirect to the homepage.
A page that should be gone returns 410 or 404 depending on how decisively it was removed. A temporary issue uses 503 with a Retry-After header so the crawler knows to come back. Redirect management and canonical hygiene are the two areas where most ranking signal is recovered or lost.
- Permanent move: one 301 to the most relevant equivalent page
- Removed page: 410 for deliberate removal, 404 for ordinary absence
- Planned downtime or maintenance: 503 with a Retry-After header
- Redirected or wrong canonical: update the target to a single 200 URL
Why does redirect management matter most for agencies?
Across audits, redirect management is where the largest share of recoverable ranking signal tends to sit, because migrations, CMS changes, and URL restructures all create chains, loops, and temporary redirects left in place permanently.
An agency that treats status codes as a recurring monitoring task rather than a one-time audit catches these regressions early, before crawl errors compound and indexation drops. The reference above turns each response into a known fix so the same workflow can be repeated across every client.
How should agencies handle status codes during a site migration?
A migration is where status codes do the most damage in the shortest window, because thousands of URLs change shape at once and every wrong response leaks signal.
Build the redirect map before launch by exporting the full old URL set, matching each old path to its closest live equivalent, and mapping anything with no equivalent to the nearest parent category rather than the homepage.
On launch day, crawl the staging or live environment and confirm every old URL returns a single 301 to a 200 target, with zero chains and zero loops. Keep the old XML sitemap available temporarily so the crawler rediscovers the moved URLs and processes the redirects faster.
- Freeze a complete pre-migration URL inventory with current status codes
- Map every old URL to a single 301 target; flatten any chain to one hop
- Avoid bulk redirecting unmatched pages to the homepage; use the parent section
- Submit the old sitemap for a short window to accelerate redirect processing
- Re-crawl the day after launch to catch redirects that resolved to 404 or 5xx
How do you monitor status codes at scale across a client portfolio?
A one-time audit catches today's problems; monitoring catches tomorrow's. The goal is to detect a status code regression before it shows up as a ranking or traffic drop.
Run a scheduled crawl of each client's priority URL set and key templates, then diff the new status codes against the previous run so any URL that flipped from 200 to 3xx, 4xx, or 5xx surfaces as a change rather than a snapshot.
Pair the crawl with server log sampling, since logs show what the crawler actually received, including intermittent 5xx responses that a single crawl may miss. Alert on the patterns that matter most: new 404s on indexed URLs, fresh redirect chains, and any cluster of 5xx on one template.
- Schedule recurring crawls of priority URLs and template samples
- Diff status codes run over run, not just inspect the latest snapshot
- Sample server logs to catch intermittent 5xx the crawler hit
- Alert on new 404s, new chains, and 5xx clusters by template
- Track time-to-detection as the metric that proves monitoring works
When should a URL be a redirect versus a canonical?
Both consolidate signals, but they answer different questions, and agencies that conflate them create avoidable problems. Use a 301 redirect when the old URL should no longer be reachable: the content moved, merged, or was retired, and a visitor or crawler landing on it should be sent elsewhere.
Use a canonical tag when two URLs both need to stay live and accessible but one is the preferred version for indexing, such as a filtered or parameterized variant of a category page.
The failure modes are mirror images: redirecting a URL that users still need breaks the experience, while canonicalizing a URL that should be gone leaves a duplicate crawlable.
- 301 redirect: the source URL should no longer be reachable at all
- Canonical: both URLs stay live, one is the preferred indexable version
- Never canonical to a URL that returns a 3xx or 4xx response
- Filtered, sorted, or tracking-parameter variants are canonical, not redirect cases
- If you cannot decide, ask whether a visitor still needs to reach the source URL
Which status codes are most often misused, and how do you correct them?
Beyond the headline codes, a handful of responses are misapplied often enough to deserve their own checklist. A 302 left in place after a permanent move is the most common: it should be a 301.
A 307 and 308 are the strict-method equivalents of 302 and 301 and are usually fine, but watch for a 307 issued automatically by HSTS, which can hide an underlying http to https redirect that should be made explicit.
A 403 returned to the crawler when a page is meant to be public points at a firewall or bot rule blocking the user agent. A 429 tells the crawler it is being rate limited, which can throttle crawling of an otherwise healthy site.
- 302 used for a permanent move: change to a 301
- 307 from HSTS: confirm the explicit http to https 301 still exists
- 403 on a public page: check WAF, bot rules, and user-agent blocks
- 429 to the crawler: raise rate limits or fix the trigger, then re-verify
- 401 on a page meant to be open: remove the auth requirement or noindex it
How do you report status code health to a client?
A status code audit is only valuable if the client understands what it means for revenue and risk, so translate codes into outcomes. Lead with the count of indexed or priority URLs that returned anything other than a clean 200, because that is the number tied to lost visibility.
Group findings by impact: signal leakage from chains and wrong redirect types, crawlable waste from soft 404s and duplicate URLs, and crawl risk from 5xx clusters.
Show the trend across audits so the client sees whether the site is getting healthier, and tie each fix to a plain outcome such as recovered ranking signal or reclaimed crawl capacity rather than the raw code.
- Headline metric: priority or indexed URLs not returning a clean 200
- Group by impact: signal leakage, crawlable waste, and crawl risk
- Show the run-over-run trend, not just a single audit snapshot
- Translate each fix into an outcome, not a status code number
- Flag anything new since the last report so regressions stay visible
Inside SEO War Room
- Technical audits, status codes, and indexing
- Predictive rank and traffic forecasting
- Entity, NLP, and semantic SEO tools
- Google patents research library
- White-label, multi-client reporting
- Client workspaces, SOPs, and training
Frequently asked questions
What is the difference between a 301 and a 302 redirect?
A 301 is a permanent redirect that tells search engines the move is final and consolidates ranking signals to the target over time. A 302 is temporary and signals that the original URL will return, so signals tend to stay on the old URL. Use 301 for permanent moves.
Should a removed page return 404 or 410?
Both tell search engines to drop the URL. A 410 (gone) is read as a more decisive, intentional removal, while a 404 (not found) is the ordinary response for an absent page. Use 410 when you are certain the page will not return.
Do 5xx errors hurt SEO?
Occasional 5xx responses are tolerated, but persistent server errors can reduce how often a site is crawled and can cause affected URLs to drop from the index. For planned downtime, return 503 with a Retry-After header so the crawler knows to come back later.
What is a soft 404 and why is it a problem?
A soft 404 is a page that returns a 200 OK status while showing little or no real content, such as an empty results or removed-product page. Search engines may treat it as low quality. A genuinely missing page should return 404 or 410 instead.
Is a redirect chain bad for SEO?
A redirect chain forces the crawler through multiple hops before reaching the final page, which can slow processing and dilute the signals passed along the way. Chains also break more easily, since any single hop that turns into a 404 or loop can strand the URL. Flatten every chain so each old URL points to the final destination in one 301 hop.
What status code should a page return during planned maintenance?
Return a 503 service unavailable with a Retry-After header rather than a 200 or a redirect. The 503 tells the crawler the outage is temporary and that it should come back, which protects the URL from being treated as removed. A 200 served on a maintenance page risks the real content being replaced in the index by the placeholder.
How often should an agency check a client's status codes?
Treat status codes as recurring monitoring rather than a one-time audit. A scheduled crawl that diffs each run against the previous one catches regressions from new content, CMS updates, and template changes before they affect rankings. Higher-traffic or frequently updated sites benefit from more frequent checks, supported by server log sampling to catch intermittent server errors.
References
- Google Search Central documentation: How Google Search handles HTTP status codes, network errors, and redirects during crawling.
- Google Search Console Help: Page indexing and crawl error reports used to verify status codes on client sites.
- MDN Web Docs: Reference definitions for HTTP response status codes and their intended semantics.