HTTP Status Codes and SEO: 200, 301, 404, 5xx

Every time you open Google Search Console, you probably see some of these: 404, 403, 5xx. You're already familiar with them. Then, in a meeting, the developer says "that page is returning a 301" or "we're getting a bunch of 500 errors," and someone asks: is that bad for SEO?

The answer depends on what the URL is supposed to do.

A 404 can be completely normal. A 301 can be exactly what you want. A 200 can still hide a problem. A 403 can stop Googlebot from accessing a page, and repeated 5xx errors can mean the server is struggling to respond.

HTTP status codes tell browsers, search engines, and other crawlers what happened when they requested a URL. Knowing what each response means makes it easier to read Search Console's Page indexing report (more in our indexing guide), interpret what your crawler is flagging, and follow what your developer is saying in the next meeting.

What HTTP Status Codes Mean

When a browser, Googlebot, or another crawler requests a URL, the server returns an HTTP response with a three-digit status code. The first digit tells you the family:

For SEO, the question isn't "is this status code good or bad?"

The better question: is this response correct for this URL?

200 OK

A 200 OK means the server successfully processed the request. For a normal indexable page, it's the expected response.

GET /technical-seo/
200 OK

But 200 does not mean the page should be indexed. A page can return 200 while also carrying:

• A noindex directive
• A canonical pointing elsewhere
• Very little useful content
• Duplicate content
• Incorrect metadata
• A soft 404 condition

What to verify on 200 pages:

• The intended content is actually returned
• The URL isn't a soft 404
• The page isn't accidentally noindex
• The canonical is appropriate
• Internal links point to the correct URL
• Important pages are accessible to crawlers

The Redirect Family: 301, 302, 307, 308

Four redirect codes cover two questions: is the move permanent or temporary, and must the HTTP method be preserved?

For SEO, permanent redirects signal that the destination should replace the old URL in the index, while temporary redirects signal the original URL is expected to come back.

301 Permanent Redirect

A 301 says the resource has permanently moved, for example /old-page/ → 301 → /new-page/. Common uses:

• Changing URL structures
• Consolidating duplicate pages
• HTTP to HTTPS
• Replacing an old page
• Domain migrations
• Retiring outdated URLs

A redirect isn't automatically correct just because it's a 301. Check where it goes.

302 Temporary Redirect

A 302 is a temporary redirect, such as /seasonal-page/ → 302 → /current-page/. The key distinction is intent: use it when the original URL is expected to return.

• Temporary promotions
• Short-term URL changes
• Temporary maintenance
• A/B testing

The classic SEO mistake is a 302 left in place for months after a URL has permanently moved. If the move is permanent, a 301 or 308 is usually more appropriate.

307 Temporary Redirect

A 307 is also temporary, but it preserves the HTTP method, so a POST stays a POST. You'll also often see 307s generated internally by browsers enforcing HSTS, which redirects HTTP requests to HTTPS before they reach the server.

From an SEO perspective, the question stays the same: is it temporary, and does it lead to the correct destination? Unexpected 307s on ordinary pages, where you expected a normal page or a permanent redirect, are worth investigating.

308 Permanent Redirect

A 308 is the permanent counterpart to 307: a permanent redirect that preserves the request method and body. Like a 301, it works for permanent URL changes. The SEO checks are identical:

1. Does the redirect belong there?
2. Is the destination correct?
3. Is there a redirect chain?
4. Is there a redirect loop?

404 Not Found

A 404 means the requested resource couldn't be found. 404s are not automatically an SEO problem. Every website accumulates URLs that no longer exist, and a 404 is appropriate when:

• A page was intentionally removed
• A URL was mistyped
• An old URL has no suitable replacement
• A temporary URL has expired

The problem is when important URLs return 404 unexpectedly, which a broken link audit will surface. If an internal link points to /products/seo-crawler/ and that URL returns 404, visitors and crawlers can't reach the intended page.

Prioritize 404s that are:

1. Linked from important pages
2. Included in XML sitemaps
3. Receiving organic traffic
4. Holding valuable backlinks
5. Created by a recent site migration
6. Easy to map to a relevant replacement

A 404 found only from random external requests is very different from one linked throughout your own site.

410 Gone

A 410 Gone means the resource was intentionally removed and isn't coming back. The difference from 404 is primarily semantic:

For a deliberately removed page like /obsolete-service/ with no replacement, a 410 communicates that intent clearly.

403 Forbidden

A 403 means the server understood the request but refused to fulfill it. Common triggers:

• Access-control rules
• Security systems
• Firewall configuration
• Bot protection
• Authentication requirements
• Server permissions
• CDN or WAF rules

A page returning 403 to Googlebot can't be crawled normally, and the same applies to other crawlers, including AI search crawlers such as OAI-SearchBot and PerplexityBot. Bot protection that's too aggressive is one of the most common causes. See how to fix 403 errors blocking AI crawlers.

But not every 403 is an SEO problem. Some URLs are meant to be private. Ask one question:

Should this URL be publicly accessible to search engine crawlers?

If yes, find out why the crawler is getting a 403.

429 Too Many Requests

A 429 means the server is rate limiting the client for making too many requests in a given period. It's usually tied to:

• Rate limits
• API protection
• Bot protection
• Aggressive crawling
• Server resource controls

An occasional 429 isn't a major problem (our HTTP 429 rate limiting guide covers crawler settings). A site that repeatedly returns 429 to search engine crawlers is. Google treats persistent 429s much like server errors and slows its crawl rate, so fewer URLs get retrieved.

What to investigate:

1. Which crawler receives the 429s?
2. How often do they occur?
3. Is the limit temporary?
4. Are important pages affected?
5. Is a CDN or WAF generating the response?
6. Are crawl rate settings unnecessarily restrictive?

5xx Server Errors

5xx responses mean the server hit an error while processing the request.

5xx responses matter most when they hit important pages or keep recurring. A short 503 during planned maintenance is very different from thousands of URLs returning 500. Persistent server errors cause Googlebot to reduce its crawl rate, and URLs that keep failing can eventually drop from the index.

Common causes:

• Application failures
• Server overload
• Database problems
• Hosting issues
• Reverse proxy failures
• CDN problems
• Timeouts
• Deployment problems
• Third-party service failures

503 Service Unavailable

A 503 is the right response for temporary downtime such as scheduled maintenance, ideally with a Retry-After header. It tells crawlers to come back later instead of treating the page as gone. The problem is prolonged or repeated 5xx behavior on pages that matter.

Soft 404s

A soft 404 is a page that behaves like a missing page but returns a success code, usually 200. For example, /removed-product/ returns 200 OK, but the page says "Product no longer available" or "Page not found."

The server says success; the content says it doesn't exist. That's why status code auditing can't stop at the numbers.

The right fix depends on the page:

How Status Codes Affect Crawling

Search engines can't crawl a page they can't successfully retrieve. The response a crawler receives decides what happens next:

The final result matters, but so does the path to get there. A crawler might encounter any of these:

Patterns that reveal crawl problems

• Large numbers of 404 URLs
• Internal links to 404 pages
• Redirect chains
• Redirect loops
• Long-running 302s
• Important pages returning 403
• Repeated 429 responses
• Large numbers of 5xx errors
• 200 pages behaving like 404s
• Sitemap URLs returning non-200

How to Audit Status Codes

A useful status code audit starts with the URLs that matter. Pull them from every source available:

• XML sitemaps
• Internal links
• Navigation
• Canonical tags
• Redirects
• Backlink data
• Previous crawls
• Google Search Console
• Analytics data

Crawl them and record each response. A basic audit table looks like this:

1. 1Crawl the siteRecord status codes for every discovered URL, not just the 200s. Errors and redirects reveal what normal browsing hides.
2. 2Group URLs by responseBucket into 200, 301, 302, 307, 308, 403, 404, 410, 429, and 5xx so patterns stand out.
3. 3Check redirect destinationsVerify destination URL, final response, relevance, chain length, and loops.
4. 4Check internal linksA 404 no one links to may just be an old URL. A 404 in the main navigation is an obvious problem. Find the source pages and fix the links.
5. 5Compare with XML sitemapsSitemap URLs should be ones you want crawled and indexed (see sitemap URLs returning non-200). A sitemap full of 404, 301, 403, or 5xx URLs needs attention.
6. 6Compare historical crawlsUse audit comparison to see what changed. Status changes expose problems introduced by migrations, redesigns, hosting or CDN changes, deployments, and redirect updates.

Why crawl comparison matters

The change tells you far more than knowing the site currently has 280 404s. Something broke between crawls, and that's where to look.

Which Responses Require Action?

Not every non-200 response needs fixing. The right action depends on what the URL is supposed to do.

Prioritize by urgency

HTTP Status Code Audit Workflow

For a practical technical SEO audit, work in this order:

1. 1Crawl the websiteCollect every discovered URL and its HTTP status.
2. 2Group responsesSeparate 2xx, 3xx, 4xx, and 5xx.
3. 3Review 3xxCheck destinations, chains, loops, and temporary redirects.
4. 4Review 4xxSeparate genuine dead URLs from broken internal links and blocked pages.
5. 5Review 5xxLook for recurring failures and affected URL patterns.
6. 6Check soft 404sFind 200 responses that behave like missing content.
7. 7Check XML sitemapsMake sure sitemap URLs resolve correctly.
8. 8Check internal linksFind pages linking to broken or redirected URLs.
9. 9Compare historical crawlsSpot sudden jumps in errors or redirects after site changes.
10. 10Fix according to intentDon't try to make every URL return 200.

Checking a Few Pages vs. Auditing the Whole Site

You don't always need a crawler to check one URL. For a single page or a handful, inspect the HTTP response headers directly from the command line.

curl.exe -I https://example.com/page/

curl -I https://example.com/page/

The response shows the status and headers the server returned:

HTTP/2 200

HTTP/2 301
location: https://example.com/new-page/

Add -L to follow redirects and see every hop in a chain. This is handy when a developer says a specific page returns a particular response and you want to verify it yourself.

But checking five URLs manually is very different from checking an entire website. To find which pages across the site return 3xx, 4xx, or 5xx responses, redirect unexpectedly, or behave like soft 404s, you need something that crawls the site and organizes the results.

That's where SiteAuditLint helps. Instead of checking URLs one by one, run a site-wide crawl of the website and pinpoint the pages that need attention because of incorrect status codes, redirects, broken URLs, server errors, and other technical SEO issues.

The goal isn't to make every URL return 200. It's to know which response each URL should return, whether it actually does, and which pages need your attention.