\n crawl errors<\/a>
\n on redirecting pages were shown in
\n Webmaster Tools<\/a>.
\n It’s time to make this a bit clearer and easier to diagnose! While it used to be that we would
\n report the error on the original—redirecting—URL, we’ll now show the error on the
\n final URL—the one that actually returns the error code.\n<\/p>\n
Let’s look at an example:<\/p>\n
![](\"https:\/\/alienroad.com\/wp-content\/uploads\/kb-gorsel\/g-ad15775d2f2f.png\")
<\/p>\n
\n URL A redirects to URL B, which in turn returns an error. The type of redirect, and type of error
\n is unimportant here.\n<\/p>\n
\n In the past, we would have reported the error observed at the end under URL A. Now, we’ll instead \n This change may also be visible in the total error counts for some websites. For example, if your \n Note that this change only affects how these crawl errors are shown in Webmaster Tools. Also, \n We hope this change makes it a bit easier to track down crawl errors, and to clean up the
\n report it as URL B. This makes it much easier to diagnose the crawl errors as they’re shown in
\n Webmaster Tools. Using tools like
\n cURL<\/a> or your favorite
\n online server header checker<\/a>,
\n you can now easily confirm that this error is actually taking place on URL B.\n<\/p>\n
\n site is moving to a new domain, you’ll only see these errors for the new domain (assuming the old
\n domain redirects correctly), which might result in noticeable changes in the total error counts
\n for those sites.\n<\/p>\n
\n remember that having crawl errors for URLs that should be returning errors (for example, they
\n don’t exist)
\n does not negatively affect the rest of the website’s indexing or ranking<\/a>
\n (also as discussed on Google+<\/a>).\n<\/p>\n
\n accidental ones that you weren’t aware of! If you have any questions, drop by in the
\n Google Webmaster Help Forum<\/a>.\n<\/p>\n