Which HTTP Status Codes Actually Affect Your SEO?

Which HTTP status codes actually affect your SEO?

Server errors and rate limits do the most damage, because they cut how much Google crawls your whole site. Redirects decide which URL gets indexed. A 404 is usually harmless. Google documents the behaviour for each code, so this is one part of SEO you can check rather than guess.

Status codes are the quietest part of a website. Nobody looks at them until traffic moves. Then everyone looks at them at once, usually in a panic, usually after a migration.

We end up in this conversation on almost every site we inherit. So here is the plain version, taken from Google's own crawling documentation rather than from forum folklore.

What does Googlebot do with a 200 response?

It considers the page for processing. Google's documentation on HTTP status codes, last updated on 4 February 2026, says that for a 2xx response Google "considers the content for processing (for example, in the case of Google Search, for indexing)." That is the normal, healthy path.

The important caveat sits in the same line. A 200 does not guarantee indexing. Google still decides whether the page is worth keeping. Plenty of pages return a perfect 200 and never appear in search, which is a content problem wearing a technical costume.

A 304 Not Modified is the quiet cousin of a 200. Google's crawlers signal that the content is the same as the last crawl. Indexing signals may get recalculated, but nothing dramatic happens. It is a bandwidth saving, not a ranking lever.

When should you use a 301 instead of a 302?

Use a 301 when the move is permanent and you want the new URL in search results. Google's redirects documentation, last updated on 14 April 2026, puts it simply: permanent redirects "show the new redirect target in search results," while temporary redirects "show the source page in search results."

Permanent redirects in Google's framing include HTTP 301 and 308. Temporary ones include 302, 303 and 307. Permanent redirects signal that the target should become the canonical URL. Temporary ones do not influence canonicalisation at all.

Google's status code documentation adds a useful nuance. A 301 is a "strong signal that the redirect target should be processed." A 302 is a "weak signal." Weak does not mean ignored, but it does mean you are leaving the decision to Google instead of making it yourself. For a full walkthrough of planning these, see our guide to website redirects.

Is a 404 actually bad for SEO?

Usually not. A 404 means the page is gone, and Google handles that cleanly. Already-indexed URLs get removed. Newly discovered 404 URLs are not processed. Crawl frequency for those URLs gradually decreases. That is the system working, not a penalty.

Google's crawl budget documentation goes further and treats 404 as the right answer. It recommends returning a 404 status code for permanently removed pages and calls it "a strong signal not to crawl that URL again." Deliberately 404ing dead content is good housekeeping.

The real problem is not the code. It is a 404 sitting behind a link that people and crawlers keep following, or a valuable URL returning 404 by accident after a rebuild. The fix is the link or the redirect, not the status code itself. Our piece on 404 pages and broken links covers how we audit that.

What is the difference between a 404 and a 410?

For Google, less than most people expect. The status code documentation states that a 410 Gone is "handled the same as other 4xx errors," meaning the content is ignored and removed from the index. The same is true for 400 Bad Request and 403 Forbidden, which Google treats as the content not existing.

So a 410 is a clearer statement of intent for humans and for other tools, but it does not buy you meaningfully faster removal from Google. If you need something out of the index urgently, removal requests in Google Search Console are the faster route.

One code in this family does deserve care. A 403 is easy to trigger by accident with a firewall rule, a bot-blocking product, or an over-tight WAF policy. Google will read it as content that does not exist and drop the page. We have seen Cloudflare and similar edge rules take out entire sections this way.

Why do 500 and 503 errors cost you more than a 404?

Because they shrink how much Google crawls the whole site, not just the broken URL. Google's documentation says that for a 500 Internal Server Error, "Google decreases the crawl rate for the site" in proportion to how many URLs are affected. That is site-wide damage from a page-level fault.

Google's crawl budget guidance describes the same mechanism from the other side. It defines a crawl capacity limit as a limit on "the total amount of time your server spends holding connections open for Google," and says that when a site responds with errors or rate-limiting signals, "the limit goes down and Google crawls less." It names 5xx codes and HTTP 429 specifically.

A 503 Service Unavailable is the polite version. It triggers a temporary crawl slowdown, indexed content is preserved at first, but Google eventually removes it if the 503 persists. Using 503 for a planned maintenance window is correct. Leaving it up for a fortnight is not.

What is a soft 404, and why is it worse than a real one?

A soft 404 is a page that returns a 200 while telling the reader the content is missing. Google's documentation describes it as a 2xx response whose content is empty or carries an error message suggesting unavailability. Search Console reports it as an error.

It is worse than a real 404 because you have told Google two opposite things at once. The header says the page is fine. The body says it is not. Google has to guess, and guessing burns crawl on URLs that will never be useful.

The usual culprits are search results pages with no matches, filtered category pages that came back empty, and single-page apps that render a client-side "not found" screen over a 200 response. That last one is common on JavaScript-heavy marketing sites and easy to miss because it looks fine in a browser.

What does a 429 actually tell Google?

That your server is overloaded. Google's documentation is explicit: "Google's crawlers treat the 429 status code as a signal that the server is overloaded, and it's considered a server error." It sits in the same bucket as a 5xx for crawl rate purposes.

This matters more than it used to, because a lot of sites now apply rate limiting at the edge to manage AI crawlers and scrapers. If your rule is too blunt, Googlebot catches the same limit and your crawl rate falls. Check that your bot rules distinguish verified Googlebot from generic traffic.

Google's crawl budget guidance also notes who actually needs to think about this. It targets large sites with a million or more unique pages that change weekly, and medium or larger sites with ten thousand or more unique pages that change daily. Google calls these "rough estimates" and "not exact thresholds." Most B2B marketing sites are nowhere near that, which is why crawl budget panic is usually misplaced. Our crawl budget explainer has the longer version.

Which redirect method should you use?

Server-side, every time you can. Google ranks the methods by reliability and puts server-side redirects first, then meta refresh, then JavaScript. On server-side redirects the documentation says: "This is the best way to ensure that Google Search and people are directed to the correct page."

Meta refresh sits in the middle. An instant meta refresh with a zero second delay is treated as permanent. A delayed one is treated as temporary. That is a subtle difference that catches people out when they add a "redirecting in five seconds" screen.

JavaScript redirects are last. Google says to use them "only if you can't do server-side or meta refresh redirects," because the Web Rendering Service may fail and leave the redirect unprocessed. On a platform where you do not control the server, such as some hosted site builders, this is worth knowing before you plan a migration around it.

What should you fix first?

Start with anything returning 5xx or 429, because those throttle crawling site-wide. Then fix 403s caused by your own edge rules, since those silently delete pages from the index. Then clean up soft 404s, then redirect chains, then ordinary 404s with inbound links.

The Page indexing report in Google Search Console is where most of this surfaces, and it is free. Pair it with a crawl from any decent crawler and a look at your server or edge logs. Between those three you can see every code your site is actually returning, rather than the ones you assume it returns.

Status codes are unglamorous, and that is exactly why they stay broken for years. If you want us to take a look at what your site is telling Google, let us talk. We are at phoenix.studio.