HTTP Status Codes for SEO: Redirect and Error Checklist

Every URL on your site answers a request with an HTTP status code before a single word of content is read. That three-digit number decides whether a search engine considers the page for indexing, follows it somewhere else, drops it, or slows down crawling across the whole site. Most ranking problems that look mysterious on small websites turn out to be ordinary status code mistakes: a redirect chain left behind after a redesign, a deleted page that still returns 200, or a temporary redirect that was meant to be permanent.

This checklist explains how Google treats the status codes you will actually meet, then walks through a practical review you can run on a small site in under an hour.

Quick answer

Pages you want indexed should return 200 at their final, canonical URL with no redirect in between. Moved pages should use one permanent redirect (301 or 308) straight to the closest relevant replacement. Removed pages with no replacement should return 404 or 410, not a redirect to the homepage. Temporary situations should use 302 or 307. Server errors (5xx) and rate limiting (429) should be rare and short-lived, because they make crawlers back off.

How Google handles the main status code groups

Google Search Central documents how its crawlers react to each class of response. The short version, based on Google's HTTP status code documentation:

• 2xx (success): the content is passed on for indexing consideration. Indexing is still not guaranteed. If a 200 page looks empty or like an error message, Search Console may report it as a soft 404.
• 3xx (redirection): Google's crawlers generally follow up to 10 redirect hops. Content on the redirecting URL is ignored and the final target is processed instead. 301 and 308 are a strong signal that the target should be canonical; 302 and 307 are a weak signal.
• 4xx (client errors): content is not used. Already indexed URLs that start returning 4xx are removed over time. All 4xx codes except 429 are treated the same way, so 404 and 410 lead to the same outcome.
• 429 and 5xx (server errors): crawlers temporarily slow down. Already indexed URLs are kept for a while, but URLs that keep failing are eventually dropped.

Two practical conclusions follow. First, there is no SEO bonus for choosing 410 over 404; pick whichever your platform supports cleanly. Second, a few minutes of 503 during maintenance is harmless, but days of server errors are not.

1. Build a short URL inventory

You cannot check status codes without a list of URLs. For a small site, combine three sources:

• Every URL in your XML sitemap.
• The pages that receive clicks or impressions in Google Search Console.
• Old URLs you know about from previous redesigns, migrations, or slug changes.

If you do not have a sitemap yet, the XML Sitemap Generator can prepare the markup, but the final file should only list pages that are live and meant to be indexed.

2. Confirm every sitemap URL returns 200 directly

A sitemap should list final destinations, not URLs that redirect. Check each one and flag anything that does not return 200 on the first request.

• Redirecting sitemap URL: replace it with the final target URL.
• 404 or 410 in the sitemap: remove it, or restore the page if its removal was a mistake.
• 5xx in the sitemap: investigate the server or application error before anything else.

Watch the small variations too: http versus https, www versus the bare domain, and trailing slash versus no trailing slash. Each mismatch adds a redirect hop that the sitemap should not need.

3. Collapse redirect chains into one hop

A redirect chain happens when URL A redirects to B, which redirects to C. Chains usually build up over several redesigns. Google can follow them, but every extra hop slows users down, wastes crawl activity, and increases the chance that one link in the chain breaks.

• Update old redirect rules so they point straight to the current final URL.
• Update internal links so they point to the final URL and do not rely on redirects at all.
• Look for loops, where two rules send a URL back and forth.

To see each hop, run curl -sIL https://example.com/old-page from a terminal or open your browser developer tools, enable "Preserve log" in the Network panel, and load the URL. Each response in the chain is listed with its own status code and Location header.

4. Use permanent redirects for permanent moves

According to Google's redirect guidance, permanent redirects tell Google to show the new target in search results, while temporary redirects keep the source URL in results. Choose based on intent:

• Slug changed, page merged, or domain moved: 301 or 308.
• Seasonal page, short promotion, or service temporarily unavailable: 302 or 307.
• No server access: an instant meta refresh is treated as permanent, but a server-side redirect is the most reliable option.

A common mistake is a CMS or plugin that creates 302 redirects by default. If a move is permanent, check the actual status code instead of trusting the setting label.

5. Stop redirecting deleted pages to the homepage

When a page is removed with no close replacement, redirecting it to the homepage is tempting. It usually does not help. The homepage does not answer the same query, visitors land somewhere unexpected, and Google may treat the redirect as a soft 404 anyway.

Use this decision rule:

• A clearly equivalent page exists: permanently redirect to it.
• A closely related category or guide exists: redirect only if it genuinely satisfies the same need.
• Nothing comparable exists: return 404 or 410 and show a helpful error page with search and navigation.

6. Find soft 404s

A soft 404 is a page that returns 200 but behaves like an error: an empty category, a "product not found" message, or a template with no main content. Search Console reports these in the page indexing report. Fix them by returning a real 404 or 410, by adding genuine content, or by redirecting to a truly equivalent page.

Thin placeholder pages created by themes and plugins are a frequent cause. If a page has no purpose for searchers, it should not answer with 200.

7. Check that error responses are real errors

Request a URL that definitely does not exist, such as /this-page-should-not-exist-2026. It should return 404 or 410. If it returns 200, your site is creating an unlimited number of soft 404s, and every typo or broken backlink becomes a thin indexable page.

Also check that real errors are not hidden behind redirects. A missing page that redirects to a /404 URL which then returns 200 is two problems at once.

8. Watch server errors and rate limits

Because 5xx and 429 responses make Google slow down crawling, recurring errors can delay the discovery of new content across the whole site. Review the server error rows in Search Console and your hosting or application logs. Common causes on small sites include exhausted PHP workers, overloaded shared hosting, aggressive security rules that rate-limit crawlers, and broken plugin updates.

For planned maintenance, a short 503 response with a Retry-After header is the standard approach. Avoid serving a 200 maintenance page, which can be indexed in place of your real content.

9. Review headers that change indexing

Status codes are not the only part of the response that matters. While you inspect each URL, also look for:

• X-Robots-Tag: noindex sent as a header on pages that should be indexed.
• A Link header with rel="canonical" pointing to a different URL than the HTML canonical.
• Unexpected caching headers that keep serving an old redirect after you changed it.

The Meta Tags Analyzer is useful for checking the HTML side of the same page, including the canonical and robots meta tags.

Using the SeoToolls HTTP Headers Checker for this review

The HTTP Headers Checker sends a HEAD request and follows redirects for you. It reports the final status code and the response headers of the final URL, along with notes on security, caching, and compression headers. That makes it a fast way to confirm that a URL ends on 200, or that a removed page really returns 404.

Know its limits before you rely on it:

• It does not list each intermediate hop. To audit a redirect chain hop by hop, use curl -sIL or browser developer tools as described above.
• It stops after five redirects and returns an error instead of a result. If that happens, treat it as a sign the chain is too long.
• A few servers answer HEAD requests differently from normal GET requests. If a result looks wrong, confirm it in a browser.

A simple status code review log

Record each finding so fixes can be checked later. A spreadsheet with these columns is enough:

• URL checked
• Where you found it (sitemap, Search Console, old URL list, internal link)
• Final status code
• Number of redirect hops and final destination
• Expected outcome (200, one permanent redirect, 404/410)
• Fix needed and owner
• Date fixed and date re-checked

Re-check after every redesign, plugin change, CMS migration, or URL structure change. Those are the moments when status code problems are introduced. For the wider audit around this step, see the technical SEO audit guide and the indexable page QA checklist.

Frequently asked questions

Is a 410 better than a 404 for SEO?

Google documents that all 4xx responses except 429 are treated the same way. Use 410 if you want to state that a removal is deliberate, but do not expect a different search outcome.

Do 301 redirects lose ranking signals?

Google treats permanent redirects as a strong signal that the target should be canonical. What usually hurts is redirecting to a page that does not match the original intent, or leaving long chains in place.

How long should I keep a redirect in place?

Keep permanent redirects for as long as people or other sites may still use the old URL. For most small sites, that means keeping them indefinitely unless they create a maintenance problem.

Why does a page show 200 in my browser but an error in Search Console?

The response may differ by user agent, location, time, or request method, or the error may have been temporary. Re-test the live URL in Search Console and compare your server logs for the crawl time.

Can fixing status codes guarantee better rankings?

No. Correct status codes remove technical obstacles to crawling and indexing. Rankings still depend on content quality, relevance, and many signals that no tool can control.