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 any content. Visitors rarely see it, but crawlers act on it: it decides whether a page is read, followed somewhere else, ignored or retried later. A wrong code is a quiet way to lose pages from search, because the page can look fine in a browser.
This guide explains the HTTP status codes a site owner actually meets (200, 301, 302, 304, 400, 401, 403, 404, 410, 429, 500 and 503), what Google does with each one, how to read the code for any URL, and how to choose the right code when you move, remove or pause a page. It is for owners, marketers and developers who have seen an error in a report and want to know what it means before they change anything.
By the end you will be able to check the codes on your own key pages, match each situation to the right response and recognise the mistakes that cause trouble most often.
Short answer: An HTTP status code is the three-digit number a server returns with every response. 2xx means the content can be processed, 3xx sends the client to another URL, 4xx means the content is ignored and indexed URLs are removed, and 5xx makes crawlers slow down. Google does not promise to index a page just because it returns 200.
Before you begin
You need a terminal with curl (or a browser with developer tools open on the Network tab), a list of the URLs you care about, and read access to Google Search Console if the site is verified there. The checks are read-only, so there is no risk, and the first pass takes about fifteen minutes.
Write down what you find before changing any rule on a live site.
How does Google treat each class of HTTP status codes?
The first digit tells you the family. Google's documentation describes how its crawlers treat each family, and the differences matter more than the individual numbers:
| Class | Meaning | What Google's crawlers do |
|---|---|---|
| 2xx | Success | The content is considered for processing, such as indexing. A 2xx does not guarantee indexing. |
| 3xx | Redirection | The crawler follows the redirect and processes the target URL instead. Content on the redirecting URL is ignored. |
| 4xx | Client error | Content is ignored. URLs already indexed are removed, and crawling of the URL gradually decreases. |
| 5xx and 429 | Server error or overload | Crawlers temporarily slow down. Indexed URLs are kept at first but are eventually dropped if the errors persist. |
Two details are easy to miss. First, 4xx codes other than 429 have no effect on crawl rate, so using a 401 or 403 to slow a crawler down does not work; Google's guide to reducing crawl rate says to return 429, 503 or 500 for that, and only for a short time (a couple of hours, or one to two days). Second, a page that returns 200 but shows an error message or an empty page is reported in Search Console as a soft 404, so the number alone is not the whole story. For more on that case, see Soft 404 Errors: How to Find and Fix Them.
Which HTTP status codes do site owners meet most often?
| Code | Name | What it means | What Google does with it |
|---|---|---|---|
| 200 | OK | The request succeeded and the page was returned. | Content goes to the next processing step. Indexing is possible but not guaranteed. |
| 301 | Moved Permanently | The URL has changed permanently; the new URL is in the Location header. |
Followed. A strong signal that the target should be the one processed. |
| 302 | Found | The URL has changed temporarily. | Followed. A weak signal; the original may stay in results. |
| 304 | Not Modified | The client's cached copy is still current, so no body is sent. | Signals may be recalculated; otherwise no effect on indexing. |
| 307 / 308 | Temporary / Permanent Redirect | Like 302 and 301, but the request method must not change. | Treated like 302 and 301 respectively. |
| 400 | Bad Request | The server could not process the request because it looked malformed. | Treated like other 4xx: content ignored. |
| 401 | Unauthorized | The client must authenticate first. | Treated like other 4xx. |
| 403 | Forbidden | The server understood the request but refuses it. | Treated like other 4xx. |
| 404 | Not Found | Nothing exists at this URL (or the server hides that it does). | Content ignored; indexed URLs removed. |
| 410 | Gone | The content was deliberately and permanently removed. | Handled like 404 by Google. |
| 429 | Too Many Requests | The client is being rate limited. | Treated as a server error: crawlers slow down. |
| 500 | Internal Server Error | The server hit a situation it could not handle. | Crawl slows; persistent errors can lead to removal. |
| 502 / 504 | Bad Gateway / Gateway Timeout | A gateway or proxy got a bad answer, or none in time. | Server-error handling. |
| 503 | Service Unavailable | The server is not ready, for example during maintenance or overload. | Server-error handling; the right code for short planned downtime. |
The meanings come from MDN and RFC 9110, and the crawler behaviour from Google's page on HTTP status codes. Google lists 400, 401, 403, 404, 410 and 411 together and treats the content as nonexistent for all of them.
How do I check the status code of a URL?
Run these from a terminal. They are the fastest way to see what a crawler sees before any browser logic gets involved.
# Headers only (HEAD request): status line and Location
curl -sI https://example.com/old-page
# Follow the whole redirect chain and show each hop
curl -sIL https://example.com/old-page | grep -iE '^(HTTP|location)'
# Status code of a normal GET request, nothing else
curl -s -o /dev/null -w '%{http_code}\n' https://example.com/old-page
A typical result for a moved page looks like this:
HTTP/2 301
location: https://example.com/new-page
HTTP/2 200
Some servers answer HEAD differently from GET, so use the third command when the first looks wrong. In a browser, open developer tools, choose the Network tab, reload, and read the Status column.
Step-by-step instructions
Step 1: Build the list of URLs to test
Pick the pages whose failure would cost you most: the home page, main category, product or article pages, /robots.txt, your XML sitemap, any redirected old URL, and one made-up address such as https://example.com/this-page-should-not-exist-12345. Put them in a spreadsheet with a column for the code you expect.
What success looks like: Every URL has an expected code written next to it. The made-up address is expected to return 404.
Step 2: Read the real code for each one
Run the curl commands above for each URL, and record the final status and the number of redirects. Pay attention to the made-up address: a 200 there means the site serves a soft 404, which hides real missing pages from you and from Google. Fixing that is covered in Custom 404 Page for SEO.
What success looks like: The spreadsheet has an expected and an actual column, and every mismatch is highlighted.
Step 3: Match each situation to the right code
Use this table when you have to choose a code rather than just read one:
| Situation | Return | Why |
|---|---|---|
| Page works normally | 200 | Nothing else tells a crawler the page is usable. |
| Page moved for good to another URL | 301 or 308 | Permanent redirects signal the new URL should be the one processed. See 301 vs 302 Redirects. |
| Page moved for a short time | 302 or 307 | Temporary redirects keep the original in play. |
| Page deleted with no replacement | 404, or 410 if you want to be explicit | Google handles both the same way. See 404 vs 410. |
| Content only for signed-in users | 401 (not signed in) or 403 | Crawlers never log in, so these pages will not be indexed. |
| Short planned downtime | 503 with Retry-After |
Signals a temporary condition. See 503 maintenance mode. |
| A client is sending too many requests | 429 | The standard rate-limit response. |
What success looks like: For each mismatch in your spreadsheet you know which row of this table applies.
Step 4: Find the layer that produced the wrong code
A status code can come from the application, the web server, a CDN or a firewall in front of both. A 403 that never appears in your application logs usually came from an earlier layer, so check each layer's log for the same timestamp. HTTP 500 and 503 Errors: Find the Real Website Problem and 403 Forbidden Error: Find Who Is Blocked and Fix the Cause cover the two most common cases.
What success looks like: You can name the layer that sends each wrong code.
Step 5: Compare with what Google reports
Search Console's Page indexing report groups problem URLs under reasons that map straight to status codes: Server error (5xx), Redirect error, Soft 404, Blocked due to unauthorized request (401), Not found (404), Blocked due to access forbidden (403) and Page with redirect. Google says Googlebot never sends credentials, so a 403 for a page you want indexed is treated as incorrect. A "Page with redirect" entry is not an error when the redirect is intended. Open one example URL from each reason in the URL Inspection tool and compare its result with your own curl output. Page Indexing Report Explained covers the other statuses.
What success looks like: Each reason in the report is either explained by something you meant to do or added to your fix list.
Step 6: Fix, retest and watch
Change one cause at a time, rerun the three curl commands, and update the spreadsheet. Search Console updates only after Google recrawls, with no fixed timing. Redirect problems that survive this step are usually chains or loops; see Redirect Chains, Loops, and Incorrect HTTP Status Codes.
What success looks like: Every URL's actual code matches the expected code, and the made-up URL still returns 404.
What do these status codes not do?
A correct code is necessary, not sufficient. A 200 does not mean a page will be indexed, a 301 gives no timetable for the new URL to take over, and a 404 is not a penalty on the rest of your site. Crawvix's check for server errors and unexpected 4xx responses looks at a sample of pages and deliberately ignores 401 and 429.
Final verification checklist
- The home page, key pages,
/robots.txtand the sitemap return 200 on their final URL. - Every redirected URL reaches its destination in one hop with the intended permanent or temporary code.
- A made-up URL returns a real 404 (or 410), not a 200 page that says "not found".
- No page you want indexed returns 401, 403, 429 or any 5xx code.
- Planned downtime uses 503, and nothing else in the site uses it by accident.
- Each Search Console reason you checked is explained or on the fix list.
- Your spreadsheet records the expected and actual HTTP status codes and the date you checked.
Common mistakes to avoid
- Trusting the browser. A page can look right and still return 404 or 200 with an error message. Always read the code itself.
- Using 302 for permanent moves. It is a weak signal and leaves the old URL in play. Use 301 or 308 when the move is final.
- Redirecting every removed page to the home page. Google's site-move guide advises against sending many old URLs to an unrelated page such as the home page; return 404 or 410 for pages with no equivalent.
- Using 403 or 401 to slow a crawler. Google says 4xx codes other than 429 do not change crawl rate. Use 429 or 503 briefly, if at all.
- Returning 200 for maintenance or error pages. It tells crawlers the page is healthy. Use the real code.
- Fixing the symptom in one layer. If a CDN rewrites the code, changing the application changes nothing.
Frequently asked questions
Do HTTP status codes affect SEO?
They affect how crawlers handle a URL: whether the content is read, followed, ignored or retried. Google's documentation describes crawling and indexing effects, not ranking effects, and this guide makes no ranking claim. What the codes control is whether a URL can be crawled and kept in the index at all.
What is the difference between 401 and 403?
A 401 means the client has not authenticated, or the credentials are invalid, and the response names the scheme it expects in a WWW-Authenticate header. A 403 means the server knows who is asking and still refuses. Googlebot does not send credentials, so for indexing purposes both keep the page out.
Is a 404 bad for my site?
No. A 404 is the correct answer for a page that does not exist, and Google treats it as normal. Trouble starts when pages you link to or list in a sitemap return 404, or when missing pages return 200. See Broken Internal Links Audit.
Does a 200 status mean Google will index my page?
No. Google says a 2xx response means the content is considered for processing, and indexing is possible but not guaranteed.
How many redirects will Google follow?
Googlebot generally follows up to 10 hops for general web content, though other crawlers may differ. Aim for one hop; see Redirect Chains and Loops.
Why does Search Console show a code my browser does not?
Googlebot may be served differently from a browser by a firewall, CDN or geo rule, or the problem may be intermittent. Test with curl, check the logs for Googlebot requests, and compare with the URL Inspection tool.
Related guides
- 301 vs 302 Redirects for SEO: Which Redirect to Use and When
- HTTP 500 and 503 Errors: Find the Real Website Problem
- 403 Forbidden Error: Find Who Is Blocked and Fix the Cause
- 503 Service Unavailable and Maintenance Mode for SEO
- Website Uptime Monitoring: Catch Downtime Before Search Engines Do
Official references
- https://developers.google.com/search/docs/crawling-indexing/http-network-errors
- https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status
- https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/401
- https://support.google.com/webmasters/answer/7440203
- https://www.rfc-editor.org/rfc/rfc9110.html
- https://developers.google.com/search/docs/crawling-indexing/reduce-crawl-rate
- https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes
Next step: Try the free website sample to see how your own site does on a few of these checks. This guide provides technical information, not a guarantee of rankings, traffic or index inclusion.
Crawvix Editorial Team
· Published November 4, 2026 · Last updated November 4, 2026 · 11 min read