HTTP Status Codes for SEO: 301 vs 302 Redirects, 404s and Crawl Budget

Every time a browser or a search engine crawler asks your server for a page, the server answers with a three-digit number before it sends anything else. That number is the HTTP status code, and it tells the requester what happened: here is the page, the page moved, the page is gone, the server fell over. Google reads that number on every single request, and it decides what gets indexed, what gets dropped, and how much of your site gets crawled at all. This guide covers the codes that matter, when a 404 is the right answer, when to use a 301 versus a 302, how long to keep a redirect live, and why status code hygiene and your XML sitemap have a direct effect on crawl budget.

What Is an HTTP Status Code?

A status code is the server’s one-line answer to a request. It comes back in the HTTP response header before any HTML is sent, which means Googlebot knows the outcome of a request before it reads a word of your content. Codes are grouped into five families, and the first digit tells you the family:

• 1xx (informational): the request was received and is being processed. You will almost never deal with these.
• 2xx (success): the request worked and content is being returned.
• 3xx (redirection): the content lives at a different URL.
• 4xx (client error): the request was wrong. The URL does not exist, or the requester is not allowed to see it.
• 5xx (server error): the request was fine, but the server failed to handle it.

You can see the code for any URL in your browser’s developer tools under the Network tab, in Google Search Console via the URL Inspection tool, or across the whole site with a crawl (see our site crawling guide).

200 OK: The Only Code an Indexable Page Should Return

A 200 means the server found the URL and is returning the content. This is the code every page you want in Google must return: every service page, product page, collection page, blog post and the homepage.

The rule that follows from this is simple and it is the one most sites break: if a URL is meant to rank, it must return 200, be canonical to itself, and appear in your XML sitemap. If it fails any of those three, fix that before you spend another dollar on content or links.

Two related codes worth knowing:

• 201 Created and 204 No Content turn up in forms and APIs, not in pages you want indexed.
• 304 Not Modified is returned when a crawler asks “has this changed since I last saw it?” and the answer is no. A correctly configured server returning 304s to Googlebot saves crawl resource on pages that have not changed, which matters on large sites.

The 3xx Family: Redirects

A 3xx tells the requester the content is somewhere else. The four that matter:

• 301 Moved Permanently. The URL has moved and is not coming back. Google transfers the ranking signals to the destination and, over time, drops the old URL from the index and replaces it with the new one.
• 302 Found (temporary). The content is temporarily somewhere else. Google keeps the original URL indexed and keeps the ranking signals attached to it, because you have told Google the original is coming back.
• 307 Temporary Redirect. The stricter modern version of a 302. It preserves the request method (a POST stays a POST). For SEO purposes Google treats 307 the same way it treats 302.
• 308 Permanent Redirect. The stricter modern version of a 301, treated the same way by Google.

In practice, most platforms and most redirect plugins give you a 301 or a 302, and those are the two decisions you will actually be making.

301 vs 302: How to Choose

The question to ask is not “is this a big change or a small change?” It is: is the original URL ever coming back?

If the answer is no, use a 301. If the answer is yes, and you can name roughly when, use a 302.

Use a 301 When

• A page has been permanently deleted and an equivalent page exists.
• You changed a URL slug, moved a page into a different folder, or restructured the site.
• You migrated to a new domain, or moved from HTTP to HTTPS, or consolidated www and non-www.
• You merged two thin, overlapping pages into one stronger page.
• A discontinued product has a genuine replacement or a closely matching category page.

Use a 302 When

• A product is out of stock for a defined period and the URL will be reused when it returns.
• You are running an A/B test and sending a share of traffic to a variant.
• A page is temporarily down for a rebuild and will return at the same URL.
• You are geo-redirecting or device-redirecting users to a regional or mobile version.
• A seasonal campaign page is dormant and will be switched back on next season.

The consequence of getting this wrong runs in both directions. A 302 used where you meant a 301 leaves Google holding the old URL in the index and slows the signal transfer to the new page. A 301 used where you meant a 302 tells Google the original URL is dead, and when you switch the content back on you have to earn its position again from a standing start.

How to Implement a Redirect Properly

Setting the redirect rule is about a third of the job. The rest is cleanup, and skipping it is what leaves sites full of redirect debt.

Where you set the rule depends on the platform. On WordPress, Rank Math and Yoast both include a redirect manager, and Redirection is the usual standalone plugin. Shopify, Squarespace and Wix each have a URL redirect tool built into the admin. On a custom build, redirects are set at server or CDN level. Wherever you set them, the same steps apply.

1. Redirect to the Closest Real Equivalent

Send the old URL to the page that most closely matches what the user was looking for. If no close match exists, send it to the relevant category or service parent, not the homepage. Mass redirects to the homepage are treated by Google as soft 404s, which means you get none of the signal transfer you were hoping for and a warning in Search Console instead.

2. Take the Origin URL Out of the Sitemap, But Only for a 301

Your sitemap is the list of URLs you are asking Google to crawl and index. For a permanent move, the origin URL comes out the moment the redirect goes live and the destination goes in. Leaving 301’d URLs in the sitemap produces “Page with redirect” notices in Search Console and burns crawl requests on URLs that will never be indexed again.

A 302 is the opposite case, and this is where most people apply the rule too literally. The whole point of a temporary redirect is that the origin URL is still the real address and still holds the ranking signals, so leave it in the sitemap. You want Google to keep crawling it: partly because that URL still matters, and partly because a crawl is how Google finds out the page has returned to 200. Pulling it from the sitemap tells Google to deprioritise the one URL you are waiting to bring back. Search Console will flag it as “Page with redirect” for as long as the 302 is live, which is expected and clears itself when you take the redirect down.

3. Update Every Internal Link

Change the internal links, navigation entries, buttons and canonical tags that point at the old URL so they point at the new one directly. The redirect exists to catch external links and old bookmarks, not to paper over your own site’s links. Every internal link left pointing at a redirect costs an extra request on every crawl and slows the page for users.

Run a full site crawl to get the complete list of pages linking to the old URL. Working from memory always misses some, and the ones it misses are usually buried in footers, sidebars and old blog posts.

4. Never Chain Redirects

URL A redirects to B, B redirects to C, C redirects to D. Each hop costs a crawl request and dilutes the signal. When you add a new redirect, check whether anything already redirects into the URL you are moving, and repoint those rules at the final destination so every chain is a single hop. Redirect loops, where A points to B and B points back to A, make the page completely uncrawlable.

5. Log It, With a Date

Keep a redirect log: origin URL, destination URL, type, the date it went live, and the reason. Without a log you can never safely clean up, because nobody remembers why any given rule exists.

How Long Should You Keep a Redirect?

Google’s guidance is to keep a permanent redirect live for at least a year. That is the floor, not a target to beat. A year is long enough for Google to fully process the move, drop the old URL from the index and reassign the signals to the new one.

Our house rule is to review every 301 at the 12 month mark and retire the ones that have gone quiet, for one practical reason: redirect rules are evaluated on requests, they accumulate silently, and a site carrying hundreds of stale rules is slower to serve and harder to debug every time something breaks. Nobody sets out to build a redirect map with 800 rules in it. It happens because no one ever takes any of them down.

Before you retire a redirect, check three things:

• Does the old URL still get traffic? Check referral and direct traffic to the old URL in analytics over the last 90 days.
• Does the old URL still get impressions? Check Search Console for the old URL. If Google is still surfacing it, the move has not finished processing.
• Does anything still link to it? Check your backlink data. A redirect carrying live external links stays, regardless of age, because taking it down throws away the link equity.

If all three come back clean, retire the rule and let the old URL 404 or 410. If any of them come back with something, leave the redirect in place and check again in six months.

The 4xx Family: Client Errors

A 4xx means the request itself was the problem. These are the codes you will spend the most time on.

404 Not Found

A 404 means the URL does not exist. It is not an error to be eliminated, and this is where most sites get the strategy wrong: they see 404s in a crawl report, assume all of them are bad, and blanket-redirect the lot.

When a 404 Is the Correct Answer

Leave the 404 in place when:

• The page genuinely no longer exists and there is no close equivalent to send people to.
• The URL was never real: a typo in someone else’s link, a mangled tracking parameter, a scraped or spam URL.
• It is a discontinued product with no replacement and no ongoing search demand.
• It is expired content with no successor: a finished event, a closed job listing, a superseded promotion.
• The URL is a spam probe (requests for /wp-admin.php, /xmlrpc.php and similar on sites that do not have them).

A clean 404 tells Google to drop the URL and stop asking. That is the outcome you want. Forcing a redirect where no equivalent page exists is worse than a 404: you send the user somewhere irrelevant, and Google treats it as a soft 404 anyway.

When to 301 a 404 Instead

Convert the 404 into a 301 when:

• The URL has external backlinks pointing at it. This is the strongest reason of all, because a 404 throws that link equity away.
• The URL still receives real traffic, from bookmarks, old email campaigns, printed material or QR codes.
• The URL still gets impressions or clicks in Search Console, which means people are still searching for it.
• The page was renamed or moved rather than removed, and the content still exists somewhere.
• A genuinely equivalent page exists that answers the same need.

The test is whether a real user landing on the destination would feel like they found what they came for. If yes, redirect. If no, 404.

Whatever You Do, Design the 404 Page

A useful 404 page keeps the site header and navigation, says plainly that the page does not exist, offers site search, and links to the main category or service pages. It must still return a 404 status code in the header. A “not found” page that returns 200 is a soft 404, and Google will keep crawling and trying to index it.

410 Gone

A 410 says the same thing as a 404 with more conviction: this URL existed, it has been deliberately removed, and it is not coming back. Google processes 410s slightly faster than 404s. Use it for bulk deliberate removals such as a discontinued product range or a retired content section. For everything else a 404 is fine, and the practical difference is small.

The Other 4xx Codes Worth Knowing

• 403 Forbidden. The server understood the request and refused it. Check for these carefully: an over-tight firewall or bot rule returning 403 to Googlebot will quietly de-index the affected pages.
• 401 Unauthorized. Authentication required. Expected behaviour on member areas and staging sites, a serious problem anywhere else.
• 429 Too Many Requests. Rate limiting. If your server sends this to Googlebot, Google slows its crawl rate, sometimes for weeks after the underlying cause is fixed.

The 5xx Family: Server Errors

A 5xx means the request was valid and the server failed. These are the most damaging codes on the list, because Google interprets sustained 5xx responses as a site that cannot be relied on and cuts back crawling across the whole domain, not just the failing URLs.

• 500 Internal Server Error. The catch-all failure: a PHP fatal error, a plugin conflict, a broken database query. Fix these the day you find them.
• 502 Bad Gateway and 504 Gateway Timeout. A server in the chain did not respond, or took too long. Usually a hosting, load or CDN problem rather than a code problem.
• 503 Service Unavailable. Temporarily unavailable, try again later. This is the one code in the family you should ever deliberately return.

Use 503 for Planned Downtime

When you take a site down for maintenance or a deployment, return a 503 with a Retry-After header. That tells Google the outage is deliberate and temporary, so it comes back later instead of treating the pages as broken. A maintenance page that returns 200, or worse a maintenance page that returns 404, tells Google your entire site has just been replaced with a “back soon” notice.

The rule of thumb on 5xx: a handful of transient errors across a large site is normal noise. A pattern of them on the same URLs, or a spike across the site, is a priority fix that outranks everything else on your SEO list.

Crawl Budget: Why Any of This Matters

Crawl budget is the number of URLs Googlebot will request from your site in a given period. It is set by two things: how much crawling your server can handle without slowing down (crawl capacity), and how much Google wants to crawl you based on your site’s size, freshness and quality (crawl demand).

Google’s own position is that most sites under a few thousand URLs do not need to think about crawl budget. That is true as far as it goes, and it gets quoted as a reason to ignore the topic. Two things make it worth your attention anyway:

• Every wasted request is a request not spent on a page that earns money. If Googlebot spends its visit following redirect chains, hitting 404s from a migration three years ago and crawling parameter variants of the same collection page, it gets to your new service page later. On an ecommerce site with faceted navigation, wasted crawl can easily be the majority of all crawl activity.
• Status code problems are also indexing and user problems. A 302 that should be a 301 is not just a crawl inefficiency, it is a page that never accumulates the authority it should.

What actually eats crawl budget, in rough order of how often we find it:

• Redirect chains and redirected URLs left in the sitemap and internal links.
• Faceted navigation and parameter URLs generating near-infinite crawlable combinations.
• Soft 404s, which Google keeps re-crawling because they return 200.
• Slow server response times, which directly reduce crawl capacity.
• Thin, duplicate or auto-generated pages such as empty tag archives and paginated author pages.
• Sustained 5xx errors, which cause Google to back off crawling the whole domain.

Sitemap Hygiene: Only 200s Belong in It

Your XML sitemap is the clearest signal you get to send about which URLs matter. It should contain only URLs that return 200, are canonical to themselves, and are not blocked by robots.txt or a noindex tag.

Nothing else belongs in it: no permanently redirected URLs, no 404s, no noindexed pages, no canonicalised duplicates, no parameter variants. Every URL in the sitemap that fails those tests is a crawl request spent on a page that will never be indexed, and a data point telling Google your sitemap is not trustworthy.

The one deliberate exception is a URL sitting behind a 302. Because a temporary redirect means the origin URL is coming back and is still the address holding the ranking signals, it stays in the sitemap for the duration so Google keeps crawling it and picks up the return to 200 quickly.

The maintenance job is short and worth doing monthly:

• Crawl the sitemap URLs and confirm every one returns 200.
• Remove anything that has since been redirected, deleted or noindexed.
• Check the Sitemaps and Pages reports in Search Console for “Page with redirect”, “Not found (404)”, “Soft 404” and “Server error (5xx)”.
• Confirm every new page you have published this month is actually in the sitemap.

On most platforms the sitemap is generated automatically and this mostly takes care of itself. The failures show up on sites with a manually maintained sitemap, sites with a plugin misconfiguration, or sites where redirects were added at server level and the CMS still believes the old URLs are live.

Quick Reference

• 200 OK: the page is fine. Required for anything you want indexed.
• 301 Moved Permanently: the URL has moved for good. Signals transfer to the destination.
• 302 Found: the content is temporarily elsewhere. Signals stay with the original URL.
• 304 Not Modified: unchanged since the last crawl. Saves crawl resource.
• 403 Forbidden: access refused. Check this is not being served to Googlebot.
• 404 Not Found: the URL does not exist. Correct and healthy when there is no equivalent page.
• 410 Gone: deliberately removed and not returning. Processed slightly faster than a 404.
• 429 Too Many Requests: rate limited. Reduces Google’s crawl rate.
• 500 Internal Server Error: the server failed. Fix immediately.
• 503 Service Unavailable: planned or temporary downtime. Serve with a Retry-After header.

Frequently Asked Questions

What is the difference between a 301 and a 302 redirect?

The difference between a 301 and a 302 redirect is permanence: a 301 tells search engines the URL has moved for good and the ranking signals should transfer to the destination, while a 302 says the move is temporary and the signals should stay with the original URL. The question to ask before choosing is whether the original URL is ever coming back. If it is not, use a 301. If it is, and you can name roughly when, use a 302.

Are 404 errors bad for SEO?

404 errors are not inherently bad for SEO, and a site with zero 404s is usually a site that has been over-redirected. A 404 is the correct answer when a page genuinely no longer exists and there is no equivalent to send people to. The 404s worth fixing are the ones on URLs that still attract backlinks, traffic or search impressions, because those represent value you are throwing away.

How long should you keep a 301 redirect in place?

You should keep a 301 redirect in place for at least 12 months, which is Google’s own minimum guidance and the time it takes for a move to be fully processed. After 12 months, review the rule: if the old URL has no remaining traffic, no Search Console impressions and no external links pointing at it, retire the redirect. If any of those still show activity, leave it live and review again in six months.

Should redirected URLs be removed from the XML sitemap?

Redirected URLs should be removed from the XML sitemap when the redirect is a 301, because the URL is gone for good and you want Google to drop it and index the destination instead. A URL behind a 302 is the exception and should stay in the sitemap: a temporary redirect means the origin is still the real address and still holds the ranking signals, so you want Google to keep crawling it and notice quickly when it returns to a 200 status code.

What does a 200 status code mean?

A 200 status code means the server found the requested URL and is returning the content successfully. It is the code every page you want ranking must return, alongside a self-referencing canonical tag and inclusion in the XML sitemap. If a page you are trying to rank returns anything other than 200, that is the first thing to fix.

What causes a 500 internal server error?

A 500 internal server error is caused by the server failing to complete a valid request, most often from a PHP fatal error, a plugin or theme conflict, a broken database connection or an exhausted memory limit. Sustained 500 errors are the most damaging status code problem a site can have, because Google reduces crawling across the entire domain when it decides a site is unreliable.

Does crawl budget matter for small websites?

Crawl budget matters less for small websites, and Google states that sites under a few thousand URLs generally do not need to manage it actively. That said, the work that protects crawl budget is the same work that fixes indexing and user experience problems: clean status codes, no redirect chains, an accurate sitemap and a fast server. Small sites get the benefit without ever needing to think about the budget itself.

What is a soft 404?

A soft 404 is a page that tells the user the content is missing but returns a 200 status code instead of a 404. Google detects these, reports them in Search Console and keeps re-crawling them because the server insists they are valid pages. The two most common causes are a “not found” template that was never configured to send the right header, and mass redirects of deleted pages to the homepage.

Need Help Getting Your Status Codes in Order?

Status codes, redirect maps and sitemap hygiene are unglamorous, and they are usually the fastest wins on a site that has been through a redesign, a platform migration or a few years of content changes. Rank Haus runs this as standard on every technical SEO engagement, from the initial crawl through to the redirect log and the 12 month review. If you want to know what is quietly leaking on your site, get in touch and we will take a look.

Related reading: What Is Technical SEO? and our 50-point technical SEO audit checklist.