HTTP Status Codes and SEO: What Each One Tells Google

Is Google dropping pages, ignoring a redirect or crawling your site less than before? The cause is often a three-digit number your server sends before any content loads. That number is the HTTP status code. For HTTP status codes and SEO, here is the short answer: 2xx means “process this page”, 3xx means “look somewhere else”, 4xx means “this doesn’t exist”, and 5xx means “try again later”.

Each of those messages changes how Googlebot crawls a URL and whether the URL stays in the index. In this guide I go through the codes that matter, what Google does with each one, and how I check what pages are really returning.

What an HTTP Status Code Is and Why Google Cares

Every time a browser or crawler asks for a URL, the server replies with a status line before the page itself. A normal page load starts with something like HTTP/1.1 200 OK. Visitors never see it. But Googlebot reads it first and decides what to do next based on it.

The codes come in five classes, grouped by their first digit:

• 1xx (informational): in-between responses. They rarely matter for SEO.
• 2xx (success): the request worked and content was returned.
• 3xx (redirection): the content lives at a different URL.
• 4xx (client error): the request was for something that doesn’t exist or isn’t allowed.
• 5xx (server error): the server failed to answer properly.

Google’s own documentation, How HTTP status codes, and network and DNS errors affect Google Search, explains how its crawlers treat the most common codes. One useful idea from it: several different codes can lead to the same result in Google Search. Even so, I always send the code that describes the situation correctly. Other search engines, browsers and AI agents may treat them differently.

2xx Success Codes: The Page Can Be Considered for Indexing

A 200 OK tells Google the request worked. Googlebot passes the content on to the indexing system. This is where people often get confused. A 200 makes a page eligible for indexing, but it doesn’t promise the page will be indexed.

Whether a 200 page ends up in the index depends on everything else Google checks. That includes content quality, duplicate content, canonical signals (hints about which version of a page is the main one) and whether a noindex rule blocks the page. If your pages return 200 and still sit under “Crawled – currently not indexed” in Search Console, the status code is doing its job. The problem is somewhere else.

The other 2xx codes work in a similar way:

• 201 Created and 202 Accepted are handled like 200. With a 202, Google waits a limited time and then passes on whatever content it has received.
• 204 No Content means there is nothing to process. Google can’t index content that isn’t there. In Search Console, this kind of page can show up as a soft 404.

Soft 404s: A 200 That Looks Like an Error

A soft 404 happens when a page returns 200 but its content basically says “nothing here”. Common examples include:

• “Product not found” templates that still return 200.
• Empty internal search results pages.
• Category pages with zero items.
• Pages that break because a database connection or a JavaScript file failed to load.

Google spots these from the content and reports them as “Soft 404” in the Page Indexing report. They are usually not indexed. They also waste crawling on URLs that give searchers nothing. In my experience, soft 404s are among the most common problems on online shops.

The fix depends on what the page should be:

1. The page is really gone with no replacement: return a real 404 or 410.
2. The content moved or has a close replacement: return a 301 redirect to it.
3. The page is real and useful but was flagged anyway: run it through URL Inspection and look at the rendered page. Blocked or failing files often leave Google with an almost empty page.

3xx Redirects: How Google Treats 301, 302, 307 and 308

A redirect tells the crawler that the content now lives at another URL. Google ignores any content on the redirecting URL itself and processes the final destination instead. Googlebot follows up to 10 redirect hops in a row. If a chain goes past that, Search Console reports a redirect error.

The key difference between redirect types is how strong the signal is for canonicalization. That means which URL Google picks to show in results.

A “weak signal” doesn’t mean Google ignores a 302. Google still follows it. If a 302 stays in place long enough, with other signals pointing to the target, Google may decide the target is canonical anyway. The problem is that you lose control over the result. If a move is permanent, say so with a 301 or 308. That’s the rule I follow every time.

304 Not Modified

A 304 tells Googlebot the content hasn’t changed since its last visit, so there is nothing new to download. Google’s documentation says it may recalculate signals for the URL. Otherwise the code has no effect on indexing.

Common Redirect Mistakes

• Chains: A redirects to B, B to C, and C to D. Each hop slows crawling and adds a point where things can break. Point A straight to D.
• Loops: two URLs redirect to each other, so Google never reaches any content.
• Redirecting everything to the home page: when removed pages with no real match all redirect to the home page, Google can treat them as soft 404s. A 404 or 410 is more honest.
• Leaving temporary redirects for years: if the move is permanent, switch the 302 to a 301.
• Not updating internal links: redirects are a safety net. Your own menus and content should link to the final URL directly.

Chains are the mistake I see most after a site has been through two or three redesigns.

4xx Client Errors: 404, 410 and Why 429 Is Different

When a URL returns a 4xx code, Google ignores any content on it. If the URL was indexed, Google removes it from the index. If you need a page out of results faster, my guide to the Search Console Removals tool explains when it helps. If Google has never seen it before, it isn’t processed. Over time, Googlebot also crawls that URL less often.

404 Not Found vs 410 Gone

Technically, 404 means “not found” and 410 means “gone, and not coming back”. In Google Search they are handled the same way. Both remove the URL from the index, and both lead to less frequent crawling. Use 410 if it matches what you mean and your platform makes it easy. I wouldn’t spend a week reworking a CMS just to swap one for the other.

The most important point about 404s is that they are normal. Every site that removes products, ends campaigns or fixes typos in URLs creates them. A 404 on a URL that should not exist does not harm the rest of your site in Google Search.

404s are worth fixing when:

• The URL is linked from your own pages, so visitors hit dead ends.
• The URL has backlinks from other sites, which a 301 to the right replacement would keep.
• The URL still gets real traffic or appears in your XML sitemap.
• The page should exist and returns 404 by mistake, for example after a migration.

A good custom 404 page helps people too. It should look like the rest of your site, explain that the page isn’t available, and point visitors to useful sections or search. Just make sure it still returns a 404 status, not a 200. Otherwise it becomes a soft 404.

401 and 403: Access Errors

401 Unauthorized and 403 Forbidden are treated like other 4xx codes, so the URL is not indexed. That’s fine for members-only areas. It’s a problem when a firewall, bot-protection service or badly set up CDN (a network that delivers your site from many locations) starts serving 403 to Googlebot on public pages.

Google clearly says not to use 401 or 403 to slow down crawling. Apart from 429, 4xx codes don’t reduce crawl rate. They just remove pages.

429 Too Many Requests

429 is the exception in the 4xx family. Google treats it as a sign that the server is overloaded. That puts it in the same group as 5xx errors, not with 404. So Googlebot slows down instead of treating the page as missing.

5xx Server Errors: 500, 502 and 503

A 5xx code says the server couldn’t complete the request. Google responds in three ways:

• Googlebot slows its crawling of the site for a while. For a 500, the slowdown depends on how many URLs return errors.
• Pages already in the index stay there at first, but are dropped if the errors continue.
• Once the server returns 2xx responses again, crawling slowly picks back up.

The same ideas cover 502 Bad Gateway and 503 Service Unavailable. A short spike after a deployment or a traffic surge is usually harmless. What costs you indexed pages is days of errors on the same URLs, or a server that times out often.

Network and DNS failures, where Googlebot can’t connect at all, have a similar effect. Crawling slows down, and pages that keep failing can drop out of the index in the end.

Using 503 for Planned Maintenance

When you take a site offline for maintenance, a 503 Service Unavailable is the right response. It tells crawlers the outage is temporary. So they come back later instead of treating your pages as gone.

Many maintenance plugins and holding pages get this wrong. They show a friendly “back soon” message with a 200 status. Google may then crawl that message as the content of every URL on your site. A 404 is just as bad, because it tells Google the pages no longer exist. I always check the status code of a maintenance page before the site goes offline.

Timing matters as much as the code. Google’s guidance on reducing the Googlebot crawl rate says to serve 500, 503 or 429 only for a short period, around one to two days. If Googlebot sees these codes on the same URL for several days, the URL may be dropped from the index. A weekend maintenance window is fine. A two-week rebuild behind a 503 is not.

Many sites also add a Retry-After header to the 503 to say when the site will be back. It’s part of the HTTP standard and costs nothing to add.

One more warning: keep your robots.txt file available during maintenance if you can. Google has special rules for a robots.txt that returns a server error. If it can’t fetch that file, it may hold off crawling the whole site.

How HTTP Status Codes Affect SEO Day to Day

Most status code problems don’t show up as a sudden crash. They creep in through routine changes: a redesign that changes URL patterns, a plugin update that breaks a template, or a security rule that’s too strict. Here is where I look first:

• Site migrations and URL changes: every old URL with traffic or links needs a 301 to its closest match. If you are rewriting titles in the same project, our guide to title tag best practices covers how to keep the new pages’ titles strong.
• Unexplained traffic drops: before blaming an algorithm change, rule out server errors and accidental 404s. That check comes first even during a rollout like the June 2025 core update, because a technical fault and an update are easy to confuse.
• Bot protection and CDNs: check that Googlebot isn’t getting 403 or 429 responses that real visitors never see.
• Online shop stock changes: decide on a rule for discontinued products. Redirect to a close replacement if one exists. If not, return a 404 or 410, not a 200 “unavailable” page with no other options.

Status codes also matter beyond Googlebot. AI-powered browsers and agents fetch pages too. A clear status code helps them understand whether content exists, has moved or is down for now. We looked at that new type of visitor in our piece on Perplexity’s Comet browser.

How to Check the Status Codes Your Pages Return

You don’t need paid tools to see what a URL returns. These four methods cover most situations.

1. Use Curl From the Command Line

curl is built into macOS, Linux and current versions of Windows. It is my go-to tool for quick checks. To see the response headers for a single URL, run:

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

The first line of the output shows the status, for example HTTP/2 301. The location: header shows where it redirects. To follow the whole redirect chain and see every hop, add -L:

curl -sIL https://www.example.com/old-page/ | grep -iE "^HTTP|^location"

That prints each status and destination in order, so chains and loops are easy to spot. Some servers answer HEAD requests (-I) differently from normal GET requests. If the result looks odd, check with a GET request that throws away the body and prints only the final code:

curl -s -o /dev/null -L -w "%{http_code} %{url_effective}n" https://www.example.com/old-page/

2. Use URL Inspection in Search Console

URL Inspection shows how Google itself sees a URL. Enter the URL and look at the indexing details, including whether the page fetch worked. Then click Test live URL to fetch it again. The live test reports fetch problems such as 404s, server errors and blocked files. “View tested page” shows the rendered HTML and a screenshot, which helps when you’re working out a soft 404.

3. Review the Page Indexing Report

In Search Console, the Page Indexing report groups URLs that aren’t indexed by reason. The reasons linked to status codes include:

• Not found (404)
• Soft 404
• Server error (5xx)
• Redirect error
• Page with redirect
• Blocked due to unauthorized request (401)
• Blocked due to access forbidden (403)
• Blocked due to other 4xx issue

“Page with redirect” and “Not found (404)” are often expected. Focus on URLs you actually want indexed, and on sudden jumps in any group.

4. Check the Crawl Stats Report

Under Settings in Search Console, the Crawl Stats report splits Googlebot’s requests by response. A rising share of server errors, or host availability warnings, points to server problems that a page-by-page check can miss.

Conclusion

The rules for HTTP status codes and SEO are simple once you see them as instructions to Google. Send 200 for real content, 301 for permanent moves, 404 or 410 for pages that are gone, and 503 only for short, real outages. Most problems come from the wrong code, such as a 200 on an error page, a 302 on a permanent move or a 403 on a public page.

As a next step, open the Page Indexing report in Search Console. Pick the reason with the most URLs you care about, and spot-check a handful with curl and URL Inspection. If your crawl checks look clean but rankings moved, compare the timing with the June 2025 core update rollout before changing anything else.