HTTP Status Codes for SEO: 200, 301, 302, 404, 410, 5xx

A page is deleted, a category moves to a new address, a server goes quiet for an evening. In each case the browser and Googlebot receive the same tiny piece of information: a three-digit number. Pick it well and the search engine understands what happened. Pick it badly and you create confusion that can take months to unwind. This guide gives you decision logic by event rather than a list to memorize.

Treat it as a reference. Soft 404s, redirect chains and out-of-stock product pages are deep topics with their own articles, so this page links to them instead of retelling them. The goal is a single map of the codes you will actually use, so you can choose the right response quickly.

What HTTP Status Codes Are and How They Affect SEO

An HTTP status code is a three-digit number a server sends with every response to summarize the outcome. The first digit names the class: 2xx for success, 3xx for redirection, 4xx for client errors and 5xx for server errors. What you see on screen and the code the server returned are independent. A page can look perfectly normal while the server says 404, or the reverse.

For SEO, what counts is how Google handles each code. The Google Search Central page on HTTP status codes, network and DNS errors (Opens in a new tab) describes each class. In short, with a 2xx the content moves on to the next processing step, a 3xx redirect is followed and the target is processed, a 4xx means the content is ignored and not indexed, and a 5xx temporarily slows crawling. The sections below restate that documentation within its limits.

Status codes do three jobs:

• They tell the browser what to do: show the page, go elsewhere or display an error.
• They report the page's state to search engines: present, moved, removed or temporarily unreachable.
• They shape crawl behavior: a server that errors often gets visited less eagerly.

So a status code is not a technical footnote. It is a statement about the page's life in search. When the statement is accurate, every later step gets easier.

200 OK: A Healthy Response and Its Exceptions

A 200 says the request succeeded. Google's documentation says that with a 2xx the content is passed to the next step, which for Search means indexing. The same document is just as clear about the limit: a 2xx status does not mean the page will be indexed. Quality, duplication, noindex or canonical choices can still keep a 200 page out of the index.

Watch for these exceptions to a healthy 200:

• An error page served as 200: The visitor reads a not-found message but the server answers 200. The documentation notes that pages which look like errors may appear as soft 404s in Search Console. Finding and fixing them is covered in the 404 section below, which links to the dedicated guide.
• Empty responses: With a status such as 204 there is nothing for Google to process.
• Dynamic empty pages: A filter that returns no products but still answers 200 creates the same confusion.

The working rule: return 200 only for pages that exist and offer the visitor real value. If the page does not exist, say so with the code and not with a sentence in the body.

301 and 308: When to Use a Permanent Redirect

301 and 308 are permanent redirects: the address has changed and will not go back. According to Google's redirect documentation, the indexing pipeline treats a permanent redirect as a signal that the target should be canonical. The page also advises using permanent redirects when you are sure the redirect will not be reverted. Read it at Redirects and Google Search (Opens in a new tab).

A permanent redirect fits these situations:

1. A page's address (slug) changes for good.
2. You consolidate HTTP into HTTPS, or the non-www and www versions into one.
3. You merge two similar pages and send the old one to the new one.
4. You change domain names.

Simplicity matters more than speed. Send the old address to the final address in one step; a redirect that lands on another redirect forms a chain. The documentation says Googlebot follows a limited number of redirect hops by default, but keeping chains short saves crawl effort and reduces the chance of an error. The steps for cleaning up chains and loops are in redirect chains and loops: how to fix.

Implement redirects on the server whenever you can. The documentation lists server-side redirects as the preferred method, meta refresh as an option only when server redirects are not possible, and JavaScript redirects as a last resort, because if rendering fails Google may never see the redirect.

How to keep link value when addresses change in bulk is a separate subject, handled in preserving backlink value during site migration. The rule to carry from here is short: a permanent change gets a permanent code.

302 and 307: When to Use a Temporary Redirect

302 and 307 are temporary redirects: you are sending visitors elsewhere for now, but the original address will return. Per the documentation, temporary redirects (302, 303, 307) are not treated as a canonicalization signal for indexing, and the source page is kept in results. In other words, a temporary code says this address is still the real one.

Temporary redirects suit these cases:

• Sending visitors to a short-lived campaign page and returning to normal afterwards.
• Pointing a page at other content for a while during maintenance.
• Showing a different address by visitor location or language, as long as the search engine can still reach the main version.
• Routing visitors to a variant during an A/B test.

The most common error is leaving a permanent move on a temporary code. The documentation does not forbid it, but since a temporary redirect does not carry the canonical signal, you should not expect the moved page to appear under its new address when you used 302. When you choose between 301 and 302, ask one question: will this redirect ever be reversed?

A note on numbers: this article makes no claim about how much link value passes through each code. The documentation gives no such figure either; it only describes the strength of the signals, with 301 and 308 as strong and 302, 303 and 307 as weak.

404 Not Found and How It Differs From a Soft 404

A 404 tells the client the requested resource was not found. In Google's documentation, content from 4xx URLs is ignored, Search does not index them and URLs already indexed are removed. A 404 is therefore not a penalty on your site; it is the natural reply for a page that no longer exists. Trouble arises when pages that should exist return 404 by mistake, or when a successor exists and no redirect points to it.

The page adds a useful detail: except for 429, all 4xx codes are treated the same way, and crawl frequency gradually decreases. Search Console may produce error messages for the 4xx and 5xx range, but seeing a message does not always mean an emergency. What matters is whether those URLs are pages that ought to exist.

A real 404 gives the right code. A soft 404 returns 200 for a page that reads like an error. The first is clean; the second confuses the search engine. Detecting soft 404s is not this article's job, so follow the soft 404 guide for that.

When you serve a 404, keep these points in mind:

• Show a helpful error page with a search box, main categories or a link home.
• If your own pages still link to the address, update those links.
• If a genuine replacement exists, consider a 301 instead of a 404.

410 Gone: When to Choose It Over 404

A 410 says the resource has been removed on purpose and will not return. As a statement it is clearer than a 404: 404 means I cannot find it right now, 410 means I removed it deliberately. Because Google's documentation says all 4xx codes except 429 are handled the same way, this article makes no claim that 410 removes a URL from Google faster or more permanently than 404. The documentation has no separate statement on that point.

So why choose 410? Because it records your intent clearly, for your team, for audits and for your own future reference. A 410 makes sense when:

1. Spam or accidentally created pages are removed deliberately and permanently.
2. An expired campaign or event page will never come back.
3. No similar page exists to take its place.

Consider a redirect instead when the removed page has a meaningful successor. For product pages that are sold out or discontinued, the choice between 404, 410 and 301 is worked through in out-of-stock and discontinued product pages and SEO. The short version: successor exists, use 301; permanently gone, use 410 or 404; temporarily unavailable, use 200 or 503 depending on the situation.

5xx Server Errors and Handling Maintenance With 503

5xx codes show that the server could not fulfill the request. In Google's documentation, server errors temporarily slow crawling, content is ignored, indexed URLs are kept at first but dropped eventually if the problem persists, and crawl rate rises gradually once the server returns 2xx again. A 500 lowers the crawl rate in proportion to the number of URLs affected.

That guides maintenance. For a short maintenance window, returning 503 (Service Unavailable) signals that the state is temporary and triggers the behavior the documentation describes for 5xx: crawling slows, but indexed pages are not removed immediately. Keep the window short, because the same page states that URLs which keep returning server errors are eventually removed from Search.

Practical rules for maintenance:

• Schedule it for a low-traffic hour and keep it brief.
• Do not serve the maintenance page with 200; Google treats it as regular content and may take the notice for your page.
• Do not serve it with 404; that sends a message of permanent removal.
• Put only the affected sections on 503, not the whole site.
• Check the error rate in your server logs afterwards; reading logs is explained in server log analysis for SEO.

For unplanned 5xx errors, the real job is finding the root cause: resource limits, a plugin fault, database connections or a bad configuration. Fix the cause rather than juggling the code.

How 429 and 403 Access Codes Affect Crawling

Access codes appear when a server refuses or limits a request on purpose. Google's page draws two distinctions. First, 429 (Too Many Requests) is read as a sign of overload and is treated like a server error, so crawling slows. Second, other 4xx codes such as 401 and 403 do not affect the crawl rate, and the page advises against using 401 or 403 to limit crawling.

Two practical conclusions follow:

• If you need Googlebot to slow down, do not use 403. If the server is genuinely overloaded, 429 or 503 is the signal, though adding capacity is the healthier answer.
• If you want to keep a section out of search, pick the right tool: authentication for members-only areas and noindex for pages you simply do not want listed.
• If you run bot protection or a firewall, make sure it is not blocking the real Googlebot, since that can produce unexpected 403 and 429 responses.

Managing which pages are crawled on large sites is a broader topic, treated in crawl budget optimization guide. On a small site, 403 and 429 problems usually come from configuration mistakes and a simple fix settles them.

Checking Status Codes: Browser, Command Line and Search Console

You can check a page's status code in three simple ways, and none of them shows everything alone.

1. Browser developer tools: Open the network tab and reload. The first request lists the status code and any redirect steps. Because browsers follow redirects automatically, enable the option that preserves the log if you want to see each hop.
2. Command line: A tool such as curl can request only headers and print the status line. Run without following redirects to see the first response, and with following to see the whole chain.
3. Search Console: It shows how Google sees a URL and which problems it reports. The tool names and screen layout can change; the logic is to compare the response you see with the response Google saw.

Two traps deserve mention. Your browser cookies and logged-in session may return a different response, so test in a private window or with a session-free tool. And bot protections that respond differently by user agent can split what you see from what Googlebot sees. When in doubt, the server log is the most reliable record of the code the real bot received.

A status problem can also be the reason a page is not indexed. When a page is missing from results, the walkthrough in diagnosing pages not indexed by Google examines status code, noindex, canonical and crawl together.

Which Code in Which Situation: A Decision Guide

Ask these questions in order and most events lead to the right code:

1. Does the page exist and offer the visitor value? If yes, 200.
2. Has it moved permanently to another address? If yes, 301 (or 308).
3. Is it temporarily at another address? If yes, 302 (or 307).
4. Was it removed permanently with no replacement? If yes, 410 or 404.
5. Is it temporarily unavailable, for maintenance or a short outage? If yes, 503.
6. Is the server overloaded and in need of limiting requests? If yes, 429, though fixing capacity comes first.

Consider a hypothetical case. A blog post moves to a new address because a product name changed. Sending the old address permanently to the new one needs a 301. Three months later you publish a new edition and retire the first; if a similar page exists, 301, otherwise 410 or 404. In the same week the server goes down for two hours of maintenance, and for those two hours the answer is 503. Each event needs its own decision, but the logic is the same.

Keep one often-confused rule in mind: will not come back calls for a permanent code, and will come back calls for a temporary one.

Example Template: Status Code Decision Table

The table below is a sample decision log for a fictional site. For your own site, add one row per problem URL group.

The last column is the most valuable one. Choosing a code is not enough; you must verify it was applied correctly. After filling a row, write the check method next to it (browser, command line or Search Console) and test the actual page.

Frequently Asked Questions

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

A 301 is permanent and a 302 is temporary. Google's documentation says a permanent redirect is a strong signal that the target should be canonical, while a temporary one is not a canonical signal and the source page stays in results. Use 301 for changes you will not reverse.

Do 404 errors hurt SEO?

Not by itself. Google ignores the content of 4xx URLs and does not index them, which is the natural reply for a deleted page. The trouble comes when pages that should exist return 404 by mistake or a page with a successor is left without a redirect.

Is a 410 better than a 404?

Google's documentation says it handles all 4xx codes except 429 the same way, so there is no claim that 410 drops a URL faster. A 410 states clearly that the removal is permanent, and you choose it for that intent.

Do 5xx errors affect rankings?

According to the documentation, server errors temporarily slow crawling, their content is ignored and, if they persist, URLs are eventually dropped from Search. No fixed time or outcome can be promised for a short outage, so fix the cause quickly.

Which status code should I return during maintenance?

Use 503 for short maintenance because it signals a temporary state. Do not serve the maintenance page as 200, which counts as normal content, or as 404, which suggests removal. Keep the window brief and check the error rate in your logs afterwards.

How do I check a page's status code?

Open the network tab in your browser developer tools, request only headers with a command line tool such as curl, or look at how Google saw the URL in Search Console. Test without a logged-in session and confirm the bot's response in server logs.

Conclusion and Next Step

No single memorized rule carries you through status codes. What works is classifying the event correctly: permanent or temporary, successor or none, healthy or not. Your answers to those three questions pick the code almost by themselves. After that, confirm in a browser, on the command line or in Search Console that each code is really returned.

A small step for today is to choose the three URL groups that cause you the most trouble and enter them in the table above. If you are weighing a content or ad purchase, the how it works page on Akua Adforce lays out the order steps: selection, cart, payment, seller approval, delivery notification and, when needed, an objection route. The platform runs only that order flow; it does not manage the technical status codes of your own site.