HTTP Status Codes for SEO: Complete Guide to Redirects, 404s, and Crawl Errors

By Guy Sheetrit, CEO of Over The Top SEO

Why HTTP Status Codes Are a Core SEO Signal

Every URL on the web returns an HTTP status code when requested. These three-digit codes tell browsers—and search engine crawlers—exactly how to interpret the server’s response. For SEO, status codes govern three critical functions: crawlability (whether Googlebot can access your pages), indexability (whether those pages should appear in search results), and PageRank flow (how link equity transfers between URLs).

Errors in status code implementation cost sites significant organic traffic. A single misconfigured 302 instead of a 301 on a high-authority URL can result in split PageRank. A redirect chain of 5+ hops may cause Googlebot to abandon crawls entirely. Understanding and auditing HTTP status codes is foundational technical SEO.

The Complete HTTP Status Code Reference for SEO

2xx Success Codes

200 OK is the standard successful response. Pages returning 200 are fully crawlable and indexable. 204 No Content returns no body—not appropriate for indexable pages. 206 Partial Content is used for range requests; Google handles these for large files but they should not be used for standard web pages.

3xx Redirect Codes

301 Moved Permanently is the correct redirect for permanent URL changes. Google transfers PageRank (link equity) through 301s, though the transfer may not be instantaneous—Google’s John Mueller confirmed in 2022 that some PageRank loss can occur in chains, making direct redirects preferable. Use 301 for: domain migrations, HTTP→HTTPS moves, www/non-www consolidation, URL restructuring, content consolidations.

302 Found (Temporary Redirect) signals that the original URL should remain the canonical. Google does not reliably transfer PageRank through 302s and may continue indexing the original URL. Use 302 only for genuine temporary redirects—A/B tests, maintenance pages, geo-redirects for non-SEO purposes. Never use 302 for permanent moves.

307 Temporary Redirect is the HTTP/1.1 equivalent of 302, with stricter method preservation (the HTTP method—GET, POST—is preserved on redirect). For SEO purposes, 307 behaves identically to 302. 308 Permanent Redirect is 301 with strict method preservation; for standard page redirects, 301 remains the standard choice.

4xx Client Error Codes

404 Not Found tells Googlebot the page doesn’t exist. Google removes 404 pages from its index after confirming the error across multiple crawls. 404s are not inherently harmful for pages that were never important or never indexed. However, 404s on previously-indexed pages with inbound links waste link equity—those links should be redirected to relevant live pages.

410 Gone explicitly signals that a resource has been permanently deleted with no replacement. Google deindexes 410 pages faster than 404s—within days versus weeks. Use 410 when you want rapid deindexation of removed content: discontinued products, merged categories, deleted blog posts with no suitable redirect target.

401 Unauthorized and 403 Forbidden prevent crawling entirely. Pages behind authentication or with explicit access blocks will not be indexed. Ensure these are intentional—accidental 403s on public pages will deindex them. 429 Too Many Requests indicates rate limiting; Googlebot will back off and reduce crawl rate when encountering 429s.

5xx Server Error Codes

500 Internal Server Error and 503 Service Unavailable tell Googlebot the server failed. Google treats temporary 5xx errors as crawl failures and retries; if 5xx errors persist for days, Google begins deindexing affected pages. 503 with a Retry-After header is the correct response for planned maintenance—it signals Googlebot to return later without deindexing.

301 vs 302: The SEO Decision Framework

The single most common SEO redirect error is using 302 when 301 is correct. Here’s a definitive decision framework:

• Use 301: Domain migrations, HTTPS upgrades, www/non-www changes, URL restructuring, merged/redirected pages, discontinued products with alternatives, expired promotional pages
• Use 302: A/B split testing (temporary), country/language detection redirects (when original URL should remain indexed), maintenance pages (short-term), OAuth flows
• Use 307/308: When you need strict HTTP method preservation in APIs or form submissions
• Use 410: Permanently deleted content with no suitable redirect destination

Redirect Chains and Crawl Budget

A redirect chain occurs when URL A redirects to URL B, which redirects to URL C, and so on. Chains waste crawl budget and risk PageRank degradation at each hop. Google’s crawlers may abandon chains beyond 5 hops; some evidence suggests PageRank attenuates with each redirect step in a chain, even for 301s.

Common causes of redirect chains: incremental site migrations (HTTP→HTTPS→new domain), CMS URL structure changes applied over multiple years, legacy campaign URLs never cleaned up, trailing-slash normalization layered on top of existing redirects.

To audit redirect chains: use Screaming Frog (Site Explorer > Response Codes > Redirection > filter “Multiple Redirects”), Ahrefs (Site Audit > Issues > Redirect chains), or the command-line tool curl -sIL [URL] to trace the full chain manually. Collapse all chains to single-hop direct redirects to their final destination.

Soft 404s: The Hidden SEO Problem

A soft 404 is a page that returns HTTP 200 but displays “page not found,” empty content, or a near-empty templated page. Google’s crawler identifies soft 404s and excludes them from indexing, but they waste crawl budget during identification. Common soft 404 scenarios:

• CMS search results pages with no results (return 200 instead of 404)
• Category pages with all products removed but the template still live
• User profile pages for deleted accounts
• Faceted navigation pages with invalid filter combinations
• Custom “page not found” pages served with 200 status codes

Detection: Google Search Console > Coverage > Excluded > “Soft 404.” Fixing soft 404s requires either returning a true 404/410 response code, redirecting to a relevant live page (301), or adding sufficient content to justify the 200 status.

How to Audit HTTP Status Codes at Scale

Step 1: Crawl Your Site

Use Screaming Frog SEO Spider (free up to 500 URLs, paid for unlimited) to crawl your full site. The Response Codes tab shows every status code returned across your crawl. Export all 3xx and 4xx URLs as CSV for analysis. Enable JavaScript rendering if your site uses client-side routing (React, Vue, Next.js) to catch dynamic redirect patterns.

Step 2: Cross-Reference Search Console Data

Google Search Console > Coverage tab shows which pages Google has crawled and what it found. Compare your crawl data against GSC’s “Excluded” and “Error” lists. GSC often surfaces 404s and 5xx errors that internal crawlers miss because it represents Googlebot’s actual crawl path, including pages linked from external sources.

Step 3: Check Log Files

Server log analysis reveals what status codes Googlebot actually receives, not what a crawling tool simulates. Access logs show crawl frequency, response codes, and crawl budget consumption by URL. Tools: Screaming Frog Log Analyzer, GoAccess (open source), Botify (enterprise). Filter server logs for user-agent “Googlebot” to extract the SEO-relevant dataset.

Step 4: Monitor With Alerts

Set up automated monitoring for status code changes: Uptime Robot or StatusCake for 5xx alerts on critical pages, Semrush or Ahrefs Site Audit scheduled weekly for 4xx/redirect chain detection, Google Search Console email alerts for crawl anomalies. Catching status code issues within hours of occurrence prevents ranking damage from extended downtime or broken redirects.

HTTP Status Codes and Crawl Budget

Crawl budget—Google’s allocated crawl resources for your site—is finite. For sites under 10,000 URLs, crawl budget is rarely a concern. For large sites (100,000+ URLs), e-commerce platforms, news sites, and aggregators, crawl budget optimization directly impacts indexation speed and ranking. Status codes affect crawl budget efficiency in these ways:

• Redirect chains: Each hop in a chain consumes a crawl request. A 5-hop chain costs 5x more crawl budget than a direct link
• 404/410 pages: Previously-linked 404 pages are recrawled periodically; cleaning them up reduces wasted crawl
• 5xx errors: Server errors cause retry behavior, consuming crawl budget without indexation benefit
• Soft 404s: Crawled and analyzed but not indexed; cleaning them returns that crawl capacity to indexable pages

Use Google’s Crawl Stats report in Search Console (Settings > Crawl Stats) to monitor total crawl requests, average response time, and breakdown by response code. A healthy site shows predominantly 200 and 301 responses with minimal 4xx and zero 5xx.

Special Scenarios: HTTPS Migration, Domain Changes, and Consolidations

HTTP to HTTPS Migration

Every page on your HTTP site should 301 redirect to its HTTPS equivalent. Implement HSTS (HTTP Strict Transport Security) headers to prevent browser-level HTTP access. Ensure internal links, canonical tags, sitemap entries, and hreflang tags all use HTTPS URLs post-migration. Verify in Google Search Console by adding HTTPS as a separate property and confirming indexation shifts from HTTP to HTTPS property over 4-8 weeks.

Domain Migration

Domain migrations are the highest-risk redirect scenario. Execute a complete 1:1 URL mapping (old URL → new URL for every page), implement 301 redirects via server-side rules (not meta refreshes), notify Google via the Change of Address tool in Search Console, and monitor closely for 3-6 months. Expect 10-20% temporary ranking volatility during the transition period—this is normal if redirects are implemented correctly.

Content Consolidation

When merging multiple pages into one (e.g., collapsing 15 thin blog posts into a comprehensive guide), 301 redirect all merged URLs to the single surviving page. Consolidation is a legitimate use of redirects that can concentrate PageRank and improve ranking potential of the surviving page. Update all internal links to point directly to the destination URL to reduce redirect dependency.

Common HTTP Status Code Mistakes and Fixes

Mistake 1: Using JavaScript-based redirects (window.location) instead of server-side 301s. JavaScript redirects are slower, not always followed by crawlers, and provide no PageRank transfer. Fix: implement all SEO-relevant redirects at the server or CDN level (nginx, Apache .htaccess, Cloudflare Rules).

Mistake 2: Redirect loops (URL A → URL B → URL A). These cause browser errors and crawl abandonment. Detection: Screaming Frog flags redirect loops; fix by tracing the redirect chain and correcting the final destination.

Mistake 3: Implementing 301s via meta refresh tags instead of proper HTTP headers. Meta refreshes are a last resort and provide unreliable PageRank transfer. Always prefer HTTP-level redirects.

Mistake 4: Forgetting to update XML sitemaps after redirects. Sitemaps should contain only 200-status URLs. Submitting redirect URLs wastes crawl budget. Audit sitemaps monthly against current status codes.

Mistake 5: Using 302s during site migrations “to be safe.” This is incorrect—a migration is permanent. Using 302s during a migration causes Google to continue indexing old URLs while new URLs fail to accumulate authority.