HTTP Status Codes for SEO: Which to Use and When (Guide)

Use 200 for pages you want indexed, 301 or 308 for permanent moves, 302 or 307 for temporary ones, 404 or 410 for pages that no longer exist, and 503 for short planned downtime. Googlebot reads each code as an instruction about crawling and indexing, so the wrong code sends the wrong signal.

The HTTP Archive Web Almanac 2024 SEO chapter found canonical tags on 65% of mobile pages and 69% of desktop pages, and 83.9% of mobile sites returned a 200 status for robots.txt. Even the basic technical files on a site are a status code question before they are anything else.

What a status code tells Googlebot

Every time a crawler asks your server for a URL, the server answers with a three digit number before it sends anything else. That number is the status code. Browsers hide it from visitors, but Googlebot reads it first and decides what to do with the page based on it: process the content, follow somewhere else, forget the URL, or come back later and more slowly.

When I audit a site, status codes are one of the first things I check, because they are the cheapest place for a serious problem to hide. A page can look perfect in a browser and still return the wrong code. A deleted product that shows a friendly message but answers with 200, or a campaign page that has been redirected with a temporary code for three years, will quietly work against you.

The codes are grouped by their first digit. 2xx means success, 3xx means the content is somewhere else, 4xx means the request cannot be served, and 5xx means the server failed. The rest of this guide covers what Google does with each group, using Google’s documentation on HTTP status codes as the reference.

The codes that matter, in one table

Code	Meaning	How Google treats it	Use it for
200	OK	Content is considered for processing, with no guarantee of indexing	Live pages you want in search
301 / 308	Moved permanently	Strong signal that the target should be processed	Permanent URL changes and merges
302 / 307	Temporary redirect	Weak signal that the target should be processed	Genuinely short term detours
404	Not found	Content not used, URL dropped if previously indexed	Pages that do not exist
410	Gone	Handled as a 4xx, like 404	Pages removed on purpose
429	Too many requests	Treated as a server overload signal	Rate limiting a misbehaving client
503	Service unavailable	Crawling slows down temporarily	Planned maintenance

The Google treatments in that table come straight from the documentation. The “use it for” column is my own working rule, built from those treatments.

Rather have an expert do this for you?

Hand it over and get back to running your business.

Hand it over to me

2xx: a 200 is permission, not a promise

A 200 tells Google the page loaded and its content can be processed. It does not mean the page will be indexed. Google’s documentation says plainly that a 2xx code does not ensure indexing. Whether the page is indexed depends on quality, duplication, and many other signals.

The common 200 mistake is the opposite one: serving 200 for a page that should not exist. If your site returns a normal 200 response for a deleted product, an empty search result or a mistyped URL, with a “sorry, nothing here” message in the body, Google may treat it as a soft 404 because the content suggests an error. The fix is to make the server say what the page says. If it is gone, return a 404 or 410.

The other quiet failure is a 200 on a URL you never meant to publish, such as a staging copy, a tag archive with no posts, or a parameter variation. I cover how to keep those out of the index in noindex vs canonical vs robots.txt.

3xx: permanent or temporary decides what Google shows

Redirects are where status codes have the biggest effect on visibility. Google’s redirect documentation splits them into two groups. Permanent redirects (301 and 308) show the new target in search results. Temporary redirects (302, 303 and 307) show the source page.

That one distinction is the whole decision. Ask what you want people to see in the results a year from now.

The old URL is retired for good: use 301 or 308. This covers a changed slug, a merged page, a new domain or a move from HTTP to HTTPS, which I cover in HTTPS and mixed content.
The old URL will return: use 302 or 307. This covers a seasonal landing page that is swapped out for a few weeks, or a short A/B test.
You are unsure: you almost certainly mean permanent. Temporary redirects left in place for years are one of the most common faults I find in older sites, usually because a plugin or a developer defaulted to 302.

Redirects also stack up. A 301 that points to another 301 that points to a third URL is a chain, and it wastes time for both users and crawlers. I give that its own guide in redirect chains and loops, so here I will only say: every redirect you create should point at the final destination in one step. If you are moving a whole site, the sequence matters even more, and my website migration SEO checklist covers it.

4xx: 404, 410 and the codes people misuse

Google does not use the content of any URL that returns a 4xx code. A previously indexed URL is removed from the index, and the crawling frequency for it gradually decreases. That makes a 404 a perfectly healthy answer for a page that has genuinely gone. A site with some 404s is not penalised for having them. The real risk is a 404 on a URL that still earns links or traffic, which is a lost opportunity rather than a punishment.

404 or 410?

Google’s documentation treats 4xx codes as one group, so do not expect 410 to behave very differently from 404. My own rule is to use 410 when I removed something deliberately and want that intent recorded, such as discontinued products or expired listings, and to let everything else fall to 404. It is a clarity habit, not a ranking tactic.

When a redirect is better than a 404

If a removed page has a close replacement, redirect it with a 301. If it has no replacement, do not send it to the homepage. A redirect to something unrelated tends to be read as a soft 404 and is a poor experience for the visitor. Return a real 404 or 410 and give users a helpful error page with search and links to key sections.

401 and 403 are not crawl controls

Google specifically says not to use 401 and 403 to limit the crawl rate. They tell crawlers that access is denied, not that the server needs a break. If a firewall rule or a security plugin returns 403 to Googlebot by mistake, important pages can disappear from view. I check server logs or a crawl with a Googlebot user agent when a site loses indexed pages for no clear reason.

5xx and 429: server errors and crawl rate

Server errors tell Google the problem is on your side, not the page’s. According to Google, 5xx errors and 429 prompt crawlers to temporarily slow down. URLs already in the index are preserved for a while, but they are eventually dropped if the errors continue. Once the server starts returning 2xx again, Google gradually increases the crawl rate back up.

That has practical consequences:

Short outages are survivable. A planned maintenance window should return 503 rather than a 200 page saying “back soon” or a 404. The 503 says this is temporary.
Long or repeated outages cost you. If errors persist, pages can drop from the index, and the slower crawl means new and updated content is picked up later. This is part of why server performance belongs in any conversation about crawl budget.
Intermittent errors are easy to miss. A page that works for you but fails one request in twenty will not show up in a browser test. Look at server logs and the crawl stats in Search Console.

The code to avoid during maintenance is 404, and the code to avoid on a broken template is 200 with an error message. In both cases the code says the opposite of what is true.

How to check the status code of any URL

You do not need special software for a single page, and a crawler handles whole sites. This is the process I follow.

Open your browser developer tools, go to the network panel, and reload the page. The first request shows the status code. Tick the option to preserve the log so redirects are not hidden.
For a handful of URLs, a command line request that shows response headers will print the code and any redirect location without loading the page.
For a whole site, run a crawler and export the list of URLs grouped by status code. Review 3xx, 4xx and 5xx separately.
Cross-check against Search Console. Pages reported as not found, as having redirects, or as server errors show what Google actually saw, which can differ from what you saw.
Test with a Googlebot user agent as well as a normal browser, in case a firewall or bot rule treats them differently.

Make sure you look at the status of the final URL and every step before it. A page that ends in 200 after three redirects is fine for a visitor but not fine for efficiency.

Which status code to use: a decision table

Situation	Correct response	Common mistake
Live page you want indexed	200	200 on thin or duplicate variations
Slug changed permanently	301 or 308 to the new URL	302 left in place
Two pages merged into one	301 from the old to the merged page	Redirecting to the homepage
Short promotional detour	302 or 307	Using 301 and forgetting to undo it
Product discontinued, no replacement	404 or 410 with a helpful page	200 with “not available” text
Site down for maintenance	503	404 or a 200 holding page
Bot hammering the server	429, then fix the cause	Blocking with 403
Private area	401 or 403, or a login wall	Leaving it open at 200

Mistakes I see most often

Homepage redirects for every deleted URL. It feels tidy and it harms relevance. Use a close match or a real 404.
Soft 404 patterns. Empty categories, expired offers and internal search pages that answer 200 with almost no content.
Redirecting to a URL that itself redirects. This is how chains and loops are born, and it is covered in the redirect guide linked above.
Mixing the signals. A 301 to a page that carries a noindex tag, or a canonical pointing at a URL that returns 404, contradicts itself. Pick one clear instruction per URL.
Trusting the browser. Plugins, CDNs and caches can return different codes to crawlers than to you.

If you want the wider picture, the same checks sit inside my WordPress technical SEO checklist, which also covers the settings that cause these problems in the first place.

Questions about HTTP status codes

Does a 404 error hurt my SEO?

Not by itself. Google drops 404 URLs from the index and crawls them less over time. A 404 only hurts when it is on a page that still has links, traffic or internal links pointing to it, in which case a 301 to the closest replacement is better.

Is a 302 redirect bad for SEO?

A 302 is fine when the move really is temporary. Google treats it as a weak signal that the target should be processed and keeps showing the source page. It is a problem when it stays in place for a permanent move, because the new URL may not be the one that appears in results.

Should I use 404 or 410 for deleted pages?

Both are handled as 4xx errors, and the practical difference in Google’s documentation is small. I use 410 for content I removed deliberately and 404 for the rest, mainly so the intent is clear to anyone reading the logs later.

What status code should I return during maintenance?

Return 503 with a short message. It tells crawlers the outage is temporary, and Google slows crawling instead of treating the pages as gone. Keep the downtime brief, because repeated or prolonged server errors can lead to pages being dropped from the index.

Status code problems are easy to fix once you can see them, and invisible until you look. If you would like someone to check yours alongside the rest of your crawl and indexing setup, my technical SEO services start with a full review, and you can request a free audit to see where your site stands.