How HTTP status codes, and network and DNS errors affect Google Search

This page describes how different HTTP status codes, network errors, and DNS errors affect Google Search. We cover the top 20 status codes that Googlebot encountered on the web, and the most prominent network and DNS errors. More exotic status codes, such as 418 (I'm a teapot), aren't covered. All issues mentioned on this page generate a corresponding error or warning in Search Console's Crawl Stats report.

HTTP status codes

HTTP status codes are generated by the server that's hosting the site when it responds to a request made by a client, for example a browser or a crawler. Every HTTP status code has a different meaning, but often the outcome of the request is the same. For example, there are multiple status codes that signal redirection, but their outcome is the same.

Search Console generates error messages for status codes in the 4xx–5xx range, and for failed redirections (3xx). If the server responded with a 2xx status code, the content received in the response may be considered for indexing.

An HTTP 2xx (success) status code doesn't guarantee indexing.

HTTP status codes

2xx (success)

Google considers the content for indexing. If the content suggests an error, for example an empty page or an error message, Search Console will show a soft 404 error.

`200 (success)`	Googlebot passes on the content to the indexing pipeline. The indexing systems may index the content, but that's not guaranteed.
`201 (created)`
`202 (accepted)`	Googlebot waits for the content for a limited time, then passes on whatever it received to the indexing pipeline. The timeout is user agent dependent, for example Googlebot Smartphone may have a different timeout than Googlebot Image.
`204 (no content)`	Googlebot signals the indexing pipeline that it received no content. Search Console may show a soft `404` error in the site's Index Coverage report.

3xx (redirects)

Googlebot follows up to 10 redirect hops. If the crawler doesn't receive content within 10 hops, Search Console will show a redirect error in the site's Index Coverage report. The number of hops Googlebot follows is user agent dependent; for example, Googlebot Smartphone may have a different value than Googlebot Image.

In case of robots.txt, Google follows at least five redirect hops as defined by RFC 1945 and then stops and treats it as a 404 for the robots.txt file.

`301 (moved permanently)`	Googlebot follows the redirect, and the indexing pipeline uses the redirect as a strong signal that the redirect target should be canonical.
`302 (found)`	Googlebot follows the redirect, and the indexing pipeline uses the redirect as a weak signal that the redirect target should be canonical.
`303 (see other)`
`304 (not modified)`	Googlebot signals the indexing pipeline that the content is the same as last time it was crawled. The indexing pipeline may recalculate signals for the URL, but otherwise the status code has no effect on indexing.
`307 (temporary redirect)`	Equivalent to `302`.
`308 (moved permanently)`	Equivalent to `301`.

4xx (client errors)

Google's indexing pipeline doesn't consider URLs that return a 4xx status code for indexing, and URLs that are already indexed and return a 4xx status code are removed from the index.

`400 (bad request)`	All `4xx` errors, except `429`, are treated the same: Googlebot signals the indexing pipeline that the content doesn't exist. The indexing pipeline removes the URL from the index if it was previously indexed. Newly encountered `404` pages aren't processed. The crawling frequency gradually decreases. Don't use `401` and `403` status codes for limiting the crawl rate. The `4xx` status codes, except `429`, have no effect on crawl rate. Learn how to limit your crawl rate.
`401 (unauthorized)`
`403 (forbidden)`
`404 (not found)`
`410 (gone)`
`411 (length required)`
`429 (too many requests)`	Googlebot treats the `429` status code as a signal that the server is overloaded, and it's considered a server error.

5xx (server errors)

5xx and 429 server errors prompt Google's crawlers to temporarily slow down with crawling. Already indexed URLs are preserved in the index, but eventually dropped.

`500 (internal server error)`	Googlebot decreases the crawl rate for the site. The decrease in crawl rate is proportionate to the number of individual URLs that are returning a server error. Google's indexing pipeline removes from the index URLs that persistently return a server error.
`502 (bad gateway)`
`503 (service unavailable)`

Network and DNS errors

Network and DNS errors have quick, negative effects on a URL's presence in Google Search. Googlebot treats network timeouts, connection reset, and DNS errors similarly to 5xx server errors. In case of network errors, crawling immediately starts slowing down, as a network error is a sign that the server may not be able to handle the serving load. Already indexed URLs that are unreachable will be removed from Google's index within days. Search Console may generate errors for each respective error.

Debug network errors

These errors happen before Google starts crawling a URL or while Google is crawling the URL. Since the errors may occur before the server can respond and so there's no status code that can hint at issues, diagnosing these errors can be more challenging. To debug timeout and connection reset errors:

Look at your firewall settings and logs. There may be an overly-broad blocking rule set.
Look at the network traffic. Use tools like tcpdump and Wireshark to capture and analyze TCP packets, and look for anomalies that point to a specific network component or server module.
If you can't find anything suspicious, contact your hosting company.

The error may be in any server component that handles network traffic. For example, overloaded network interfaces may drop packets leading to timeouts (inability to establish a connection) and reset connections (RST packet sent because a port was mistakenly closed).

Debug DNS errors

DNS errors are most commonly caused by misconfiguration. To debug DNS errors, do the following:

Look at your DNS records. Double check that your A and CNAME records are pointing to the right IP addresses and hostname, respectively. For example:
```
dig +nocmd example.com a +noall +answer
```
```
dig +nocmd www.example.com cname +noall +answer
```

Check that all your name servers are pointing to the correct IP addresses of your site. For example:

dig +nocmd example.com ns +noall +answer
example.com.    86400  IN  NS  a.iana-servers.net.
example.com.    86400  IN  NS  b.iana-servers.net.
dig +nocmd @a.iana-servers.net example.com +noall +answer
example.com.    86400  IN  A  93.184.216.34
dig +nocmd @b.iana-servers.net example.com +noall +answer
...

If you've made changes to your DNS configuration within the last 72 hours, you may need to wait for your changes to propagate across the global DNS network.
To speed up propagation, you can flush Google's Public DNS cache.
If you're running your own DNS server, make sure it's healthy and that it's not overloaded.