Interesting argument in the comments about why Google have been treating 410s the same as 404s:
"people misuse status codes and we need to be flexible."
Standards exist for a reason.
Shouldn't we rather educate people, or give them additional options for crawl settings (should they find themselves in an environment without much influence on specific status codes). I feel we're not doing people a favour if we change how we interprete standards here and there (unless, maybe, that is necessary to provide a specific functionality?).
Because at the end of the day, this removed control off those folks who used specific status codes on purpose.
Examples where I find the distinction between 404s and 410s helpful:
1. I set rules for 410s on purpose, so if I spot these in crawl reports, I know it's what we wanted (or if not, our testing wasn't great and the rules need to be changed). If I spot 404s, I know it's not one of our rules and I need to investigate differently.
2. Golden were the days when we needed to get something out of the index fast and the fastest way just appeared to be to have them respond with a 410. Yes, there are other ways, just none nearly as fast and neat as these were, at least in my experience. (Sure we can do a custom HTTP x-Robots-Tag... and then some more settings because not all search engines do accept them. Get my point?)
Now if you're an international technical SEO and have read until here, leave me a comment: Which search engines have you found still treat 410s differently from other status codes? Which other standards would you wish to be treated as they are, rather than adding one's own flavour to them?
![View profile for Gary Illyes, graphic]()
404 (Not found) errors are not to be afraid of and you don't need to scramble to fix them, at least not most of the time.
A HTTP 404 status code is for cases when a URL on your server is not mapped to a resource, so from your perspective it can be one of these two buckets: the URL SHOULD return content and a 200 status code, or the URL was indeed not supposed to return content. This second bucket could be split further, specifically URLs that could be useful to users and URLs that are absolutely useless. So we have:
1. the URL SHOULD return content and a 200 status code. For example, you accidentally deleted the HTML mapped to the URL, or you messed up something with your database.
You should fix these as soon as possible, especially if the URL is important to your users and thus site.
2. the URL was indeed not supposed to return content, which can be either
a) the URL COULD be useful to users. You should probably think about mapping these URLs somehow to a piece of content on your site by eg. redirecting. Some cases I've seen that fall into this category are broken links from high user-traffic pages; the users tap on the link, they find a 404 error even though you have the perfect content for them.
b) the URL is absolutely useless. From a user's perspective, there's nothing you should do about these. If you do, you just mislead them. Some cases I've seen that fall into this category is off-site links to content that you don't have (say you changed business and you don't sell surströmming anymore).
Unconventional as it may be, you don't need to fix all 404 errors: fix those that actually will help users.
Performance Marketing: solving prickly data problems
6dDavid Bain Have you met Gianna yet? I think this would be a hill you'd like to hear about.