HTTP status codes for SEO: 301 and 302 redirects, 404 and 410 pages, soft 404s and 5xx errors

Why do HTTP status codes matter for SEO?

Every request to your site returns a three-digit status code, and search engines use it to decide whether to read, follow, keep or forget a URL. Wrong codes cause pages to vanish, signals to scatter and crawling to slow, often without any visible error to users.

How does Google read a status code?

Google's documentation on HTTP status codes and network errors, last updated February 4, 2026, describes how its crawlers react to each class of response. A 2xx hands the content to the next processing step, a 3xx points the crawler elsewhere, a 4xx says the request failed on the client side and a 5xx says the server failed. Each class has different consequences for indexing and crawl rate.

Do status codes affect rankings directly?

Not as a ranking signal in themselves, but they decide which URLs exist in the index at all, and which signals transfer when a page moves. A wrongly returned 404 on a top page can erase its visibility, which is a very direct effect.

How do you see the status code of a URL?

Use browser developer tools in the Network panel, a command-line request that prints headers, a crawler that reports status codes in bulk or the URL Inspection tool in Search Console, which shows the code Google received. Always test as Googlebot would see the page, because firewalls, geolocation and bot protection can return different codes to different clients.

Why can a browser show a page while Google sees an error?

Because the server may treat user agents differently, rate-limit crawlers or serve error pages to unrecognized clients. Test with the live test in the URL Inspection tool.

Where do status codes fit in a technical SEO audit?

They form the base layer: if URLs return the wrong codes, nothing built on top of them works. The checks belong near the start of the technical SEO audit checklist, alongside robots.txt and sitemap reviews.

How often should you check?

Continuously, through monitoring of crawl errors and server logs, plus a full crawl after every release and migration.

What do 2xx codes mean, and what is a soft 404?

A 200 OK response tells Google the page loaded successfully and passes its content on for processing. A 2xx does not guarantee indexing, and when a 200 page looks like an error or is empty, Search Console may flag it as a soft 404.

What is a soft 404?

A soft 404 is a page that tells visitors the content is missing, or shows almost nothing, yet returns a success code. Google's guidance says such pages may be flagged as soft 404 errors, and they are not indexed. Typical sources are empty search result pages, out-of-stock pages with no information, thin category pages with no products and error templates that forget to set the status.

How do you find soft 404s?

Check the Page indexing report for the "Soft 404" status, crawl the site and look for pages with 200 status and very low word counts or error phrases, and use the live URL test to see how Google renders them.

How do you fix a soft 404?

If the content is gone, return a real 404 or 410, or redirect to a closely relevant page. If the page should exist, add useful content so it is not mistaken for an error. For empty search or filter results, return a 404 or noindex the page. The treatment of excluded pages in the guide to Page indexing statuses explains how Google reports them.

Should an empty category page return 404?

If the category is permanently empty and has no purpose, yes, or redirect it. If products will return soon, keep the page live with helpful content and alternatives.

What about other 2xx codes?

A 202 Accepted makes Google wait for a limited, crawler-specific time, and a 204 No Content gives nothing to process, so do not use them for pages you want indexed. Return 200 with real content.

Can a JavaScript-rendered page cause soft 404s?

Yes. If a client-side app shows "not found" for unknown routes but the server returns 200 for every path, Google sees soft 404s. Make the server or edge return the correct status, as the discussion of client-side versus server-side rendering notes.

How do 301, 302, 307 and 308 redirects differ for Google?

Permanent redirects, 301 and 308, are treated as a strong signal that the target should be processed, while temporary redirects, 302, 303 and 307, are a weak signal. Choose the code that matches your intent, because it influences which URL Google keeps in the index.

How does Google treat each code?

Code	Meaning	Signal strength for Google	Use for
301	Moved permanently	Strong	Permanent URL changes, migrations, consolidations
308	Permanent redirect, method preserved	Strong	Permanent changes where the HTTP method must stay the same
302	Found, temporary	Weak	Short-term moves, such as a temporary promotion page
303	See other	Weak	Redirecting after a form submission to a result page
307	Temporary, method preserved	Weak	Temporary moves where the method must stay the same

Does Google treat 301 and 308 differently?

Google handles them the same way, but recommends using the semantically correct code for other clients.

How many redirect hops will Google follow?

Googlebot generally follows up to 10 hops, and ignores the content of the redirecting URL in favor of the final target. That limit is a ceiling, not a target. Site-move guidance advises keeping chains short, and every extra hop slows users and wastes crawl effort. Collapse legacy rules, for example http to https to www to a new path, into a single redirect.

How do you test redirects at scale?

Run a list of old URLs through a crawler or script, record the final URL, status code and number of hops, and compare with your redirect map. The full method appears in the website migration checklist.

When is a temporary redirect the right choice?

When the move really is temporary: a seasonal page, an A/B test, geographic routing for users or a maintenance redirect. If the change becomes permanent, switch to a 301 or 308. Leaving a 302 in place for years can leave Google unsure which URL to keep.

What about meta refresh and JavaScript redirects?

Prefer server-side redirects. Client-side redirects work only after the page loads and are treated as a last resort for permanent moves.

How do you avoid redirect loops and bad destinations?

Test for loops, where A redirects to B and B back to A, and for redirects that point to 404 pages or to irrelevant pages such as the home page. Redirect to the closest equivalent. When many unrelated URLs redirect to a single generic page, Google may treat them as soft 404s.

Should internal links point to redirected URLs?

No. Update internal links to final URLs, as the principles in the guide to internal linking and crawlable links explain.

What do 404, 410, 401, 403 and 429 tell Google?

A 404 or 410 says the page is gone, a 401 or 403 says access is denied and a 429 says the client sent too many requests. Google ignores content from 4xx URLs and removes indexed 4xx URLs over time, but each code has a different best use.

How does Google handle 404 and 410?

Google's documentation says that content from URLs returning 4xx is ignored, indexed URLs that begin returning 4xx are removed over time, and newly discovered 404 and 410 URLs are not processed, with crawl frequency dropping gradually. A 410 signals an intentional, permanent removal, and a 404 is fine for most cases. Both are better than a soft 404.

Should you prefer 410 over 404?

Use 410 when you are sure a page is permanently gone and want to be explicit, such as after pruning. For ordinary missing pages, 404 is fine. The decision rules in the content pruning and consolidation plan show when removal is right.

What about 401 and 403?

Google says not to use 401 or 403 to limit crawling, since 4xx codes other than 429 do not affect crawl rate. They are for access control: login-protected areas return 401 and forbidden resources return 403. To keep pages out of search, use noindex or authentication, and use robots.txt only for crawl control. The differences are explained in the comparison of noindex versus disallow.

Why is 403 risky for bot protection?

Firewalls and bot protection often return 403 to unfamiliar user agents. If Googlebot is blocked by mistake, pages can drop out. Verify Googlebot by reverse DNS or published IP ranges and allow it.

What is a 429 response?

429 Too Many Requests is treated by Google as a server overload signal and handled like a server error. Returning 429 to Googlebot slows crawling. Use it for abusive clients, but make sure rate limiting does not catch verified Googlebot traffic.

How do you design a useful 404 page?

Show a clear message, a search box, links to popular sections and your main navigation, and make sure the response code is genuinely 404. A friendly page that returns 200 creates soft 404s.

How do you manage broken internal and external links?

Crawl regularly, fix internal links to 404 pages, redirect valuable removed URLs that still have backlinks and keep a list of top external links to dead pages. Orphans and stale links often appear together, as the walkthrough on orphan page identification shows.

Should you redirect every 404?

No. Redirect when a relevant replacement exists or the old URL has links or traffic. Otherwise let it return 404 or 410.

How do 5xx server errors affect crawling and indexing?

Server errors slow Googlebot down. Google's documentation says crawling temporarily slows after 5xx responses, indexed URLs are kept at first but eventually dropped if errors persist, and the crawl rate rises gradually once the server returns 2xx again.

Which 5xx codes matter most?

500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable and 504 Gateway Timeout. Google notes that a 500 reduces crawl rate in proportion to how many URLs fail, and that persistent 502 or 503 errors lead to removal from the index. The practical message is that short outages are survivable but sustained ones are costly.

Is 503 the right code for maintenance?

Yes, for short, planned maintenance, ideally with a Retry-After header. Keep the window brief. Do not leave a 503 in place for days.

How do you detect and fix server errors?

Monitor server logs and uptime, review the Crawl stats report in Search Console for host status problems and spikes in server errors, and alert on error rate rather than waiting for complaints. Fix the root cause: capacity, database queries, plugin faults, deployment mistakes or upstream timeouts. The guide to log file analysis shows how to quantify errors by URL and by crawler.

How quickly does crawling recover?

Google says the crawl rate increases gradually once the server returns successful responses again, so recovery takes time. Stability matters more than a quick patch.

How do slow responses relate to errors?

Slow servers can trigger timeouts and reduce crawl demand even without explicit 5xx codes. Improving speed and caching reduces both risks, as the notes on server response time and crawl frequency describe.

Do DNS and network errors count too?

Yes. DNS failures, timeouts and connection resets prevent Googlebot from fetching pages at all. Google documents these on a separate page, so include DNS reliability in your monitoring.

Which status code should you return in common situations?

Match the code to the real situation: permanent move, temporary move, deleted content, forbidden area, maintenance or overload. The table gives a practical reference for the cases site owners meet most often.

What is the right code for each scenario?

Situation	Correct response	Why
Page moved to a new URL for good	301 or 308 to the new URL	Strong signal to transfer indexing
Page temporarily moved	302 or 307	Weak signal, keeps the original URL
Page permanently deleted, no replacement	404 or 410	Removes the URL over time
Product discontinued with a close replacement	301 to the replacement or category	Preserves value for users and links
Product out of stock temporarily	200 with accurate availability	The page remains useful
Members-only area	401 or login redirect, plus noindex where needed	Access control, not crawl control
Planned maintenance	503 with Retry-After	Signals temporary unavailability
Empty internal search results	404 or noindex	Avoids soft 404s and thin pages
HTTP version of a page	301 to HTTPS	Consolidates on the secure canonical

What about expired offers and events?

Keep a past event page live as an archive if it has value, redirect it to the current edition if one exists or return 410 if it has no further use.

How should ecommerce sites handle discontinued and filtered pages?

Redirect discontinued products to the closest replacement or category, return 404 or 410 when none exists, and avoid redirecting everything to the home page. Control filtered URLs with canonical tags, noindex and linking rules, not with random status codes. The guidance on clean versus parameterized URLs covers which variants should exist at all.

Should out-of-stock pages return 404?

No, not when stock will return. Keep the page live and show clear availability, which is better for users and preserves rankings.

How do local businesses handle closed locations?

If a branch closes, redirect its page to the nearest location or the main location hub, update the Business Profile to mark it permanently closed and update citations. Do not leave a 404 for a page that customers and the profile still link to. The practices in the guide to local citations help clean up external references.

What about changing a location's URL?

Use a 301, update internal links, the sitemap, the profile and any LocalBusiness markup that contains the URL.

How do HTTPS, www and trailing-slash redirects fit in?

Pick one canonical form of your URLs, protocol, host and trailing slash convention, and redirect every variant to it with a single permanent redirect. This protects ranking signals and avoids duplicate versions of every page.

Which variants should redirect?

http to https, non-www to www or the reverse, uppercase to lowercase where relevant, and trailing slash to your chosen form. Each variant should reach the final URL in one hop. Use the same canonical form in internal links, canonical tags and sitemaps. The role of sitemaps in this alignment is covered in the guide to XML sitemap best practices.

How do you test all variants?

Request each variant of a sample URL and verify that each returns one 301 to the same final address. A crawler configured to follow redirects will report chains.

What about HSTS and mixed content?

HTTP Strict Transport Security tells browsers to use HTTPS, which helps users but does not replace server redirects for crawlers. Fix mixed content so that pages load all resources securely. Verify certificates and renewals, because an expired certificate stops crawling and visitors alike.

Can a redirect rule accidentally block Googlebot?

Yes. Geo or device redirects that send crawlers to the wrong place, or loops triggered by cookies, can break crawling. Test as Googlebot, and exempt verified crawlers from user-specific redirects.

How do mobile and international redirects behave?

Avoid redirecting by device or country unless necessary. When you must, redirect each URL to its direct equivalent, and keep hreflang annotations consistent, as the cautions in the discussion of hreflang and IP-based redirects and in mobile-first indexing best practices describe.

Should Googlebot be redirected like users?

Googlebot should reach the same content as users and be able to crawl every language and region version through links.

How do CDNs, caching and headers interact with status codes?

Content delivery networks, caches and firewalls sit between Googlebot and your server, and they can return their own status codes. Make sure the response Googlebot receives is the one you intend, with the right headers.

Why can a CDN change what Google sees?

Edge servers may serve cached error pages, challenge unknown clients with 403 or 429 or return stale redirects after you change rules at the origin. A cached 404 can linger after you restore a page, and a cached 301 can keep sending users to an old address. Purge caches after changes and verify with a request from outside your network.

How do you test from the crawler's point of view?

Use the live test in the URL Inspection tool, which shows the response Google received, and compare it with a request that carries the Googlebot user agent from an independent network.

Which headers matter alongside status codes?

The Retry-After header on 503 and 429 responses tells clients when to try again. The X-Robots-Tag header can carry noindex for non-HTML files such as PDFs. The Location header must contain an absolute or correctly resolved URL on redirects. Cache-Control settings determine how long intermediaries keep a response, so avoid long caching of error and redirect responses unless you intend it.

Should error responses be cached?

Briefly, if at all. A short cache protects the origin during traffic spikes, but a long one can keep a fixed page looking broken.

How do you handle bot protection and rate limiting safely?

Allow verified Googlebot through challenges and rate limits, using reverse DNS or Google's published IP ranges to verify. Tune thresholds so that normal crawling does not trigger 429s. Review firewall logs for blocked Googlebot requests after each rule change, since a protective rule that returns 403 to a crawler is an outage in disguise.

What if you cannot verify crawlers easily?

Start with the published ranges, test in staging and monitor the Crawl stats report for new spikes in errors after changes.

How do you monitor and audit status codes over time?

Combine a regular crawl, server log analysis, Search Console reports and uptime monitoring. Together they show what your server returns, what Googlebot receives and how that changes after releases.

Which sources should you use?

A site crawler gives status codes for every discovered URL. Server logs show real Googlebot requests with their response codes. The Page indexing report lists errors, soft 404s and redirects, and the Crawl stats report shows response code breakdowns, average response time and host status. Uptime monitoring alerts you to outages as they happen.

What does a healthy Crawl stats report look like?

Mostly 200 responses, a modest share of 301s for retired URLs, few 404s that match intentional removals and almost no 5xx.

What is a practical audit routine?

1. Crawl the site and list all non-200 responses with their sources.
2. Fix internal links to redirected and broken URLs.
3. Review redirect chains and loops, and collapse them.
4. Check soft 404 candidates: 200 pages with thin or error-like content.
5. Compare sitemap URLs with status codes, and remove non-200 entries.
6. Review server logs for 5xx and 429 responses to Googlebot.
7. Check Search Console for new error patterns, then log findings and fixes with dates.

How often should you run the routine?

Monthly for most sites, weekly for large or fast-changing sites, and immediately after releases and migrations.

How do you measure improvement?

Track the number of non-200 internal links, redirect chain length, soft 404 count, 5xx rate and the indexed share of your sitemap. Report them with dates and the actions taken, as the approach in measuring SEO in the AI era recommends for keeping evidence tied to outcomes.

Who should own status codes?

Developers implement them, SEO defines the rules and operations monitors uptime. A shared dashboard keeps everyone aligned.

What does a status code clean-up look like in practice?

This is a fictional example that illustrates the method. The outcomes are invented.

What was the situation?

A fictional online tile shop saw its organic traffic fall after a catalog update. Search Console showed rising "Not found (404)" and "Soft 404" counts, and the Crawl stats report showed Googlebot requests slowing during afternoon peaks.

What did the audit find?

Discontinued products returned 200 with a "product unavailable" message, forming 1,800 soft 404s. A migration had left 3,000 URLs with two-hop redirects. The firewall returned 429 to rapid requests, including Googlebot. Peak-time database load caused 503 responses on category pages for several minutes each afternoon.

What did they change?

They redirected discontinued products to replacements or categories with 301s, returned 410 for items without replacements, collapsed redirect chains into single hops, updated internal links to final URLs, allowed verified Googlebot through rate limiting, added caching and database indexes to stop peak-time 503s, cleaned the sitemap of non-200 URLs and monitored the Page indexing and Crawl stats reports weekly. They noted the dates of each fix and that recovery took weeks and could not be guaranteed.

What did they learn?

No single code was the villain. Several small inconsistencies together told Google that the site was unreliable, and fixing them one by one restored a clean signal.

Which status code mistakes should you avoid?

Most status code problems come from templates and rules written for convenience. They are easy to prevent with explicit rules and monitoring.

What do sites get wrong most often?

Returning 200 for error pages, redirecting every missing page to the home page, using 302 for permanent moves, leaving redirect chains, blocking Googlebot with 403 or 429, leaving 503 in place too long, using robots.txt to hide pages that should return 404, serving different codes to bots and users and forgetting to update sitemaps and internal links after changes.

Which mistake hurts most?

Soft 404s at scale and accidental blocking of Googlebot. Both can remove large parts of a site from the index without any visible warning to users.

How do you build a safety net?

Add status checks to your release process, automated tests for key redirects, alerts for error spikes, and a rule that every removal has a decision: redirect, 404 or 410. Document the decisions in your redirect map.

When should you ask for expert help?

For migrations, large-scale pruning, platform changes and persistent crawl problems where the cause is unclear.

How does AH SEO Agency help with status codes and redirects?

We crawl your site, analyze server logs and Search Console data, classify every non-200 response, design the redirect map and error handling, and give your developers precise rules to implement. We monitor the result and tell you plainly what is a problem and what is normal.

Where do you start?

Book a technical SEO review, plan changes with SEO migration support or request a free SEO audit that includes a status code check.

Summary: how do you use status codes to protect your SEO?

Return 200 only for real content, 301 or 308 for permanent moves, 302 or 307 for temporary ones, 404 or 410 for gone pages, 503 for brief maintenance, and keep servers healthy so that crawling stays steady.

• Permanent redirects are strong signals and temporary redirects are weak signals.
• Googlebot follows up to 10 hops, but one hop is the goal.
• 404 and 410 pages are removed over time, and soft 404s are flagged.
• 429 and 5xx responses slow crawling, and persistent errors can drop pages.
• Monitor with crawls, logs and Search Console, and fix patterns, not single URLs.