Google和其他人如何对待HTTP 418，因为它不是“真实”错误？

我想知道您是否知道Google和其他搜索引擎如何使用HTTP状态代码处理网站418 I'm a teapot。

根据此Wikipedia文章，它可以用作客户端错误代码（4xx）。我想将这个错误代码用于复活节彩蛋网站，不过该网站应由搜索引擎找到。

根据这4年的博客文章，状态418将被Google忽略。您是否有关于此主题的最新信息？其他搜索引擎如何对状态418做出反应（主要是因为它是4xx码）。

如果您在返回状态为“ 418我是茶壶”的页面上使用Google Search Console中的“作为Google抓取”工具，则它只会报告“错误”，因此无法为该页面请求索引。

在下面的屏幕截图中，带圆圈的“错误”是请求返回418状态的页面的结果。在此阶段尚无更多信息。

根据我的访问日志，Googlebot和Search Console都已访问此页面，但该页面尚未出现在索引中。

为了澄清起见，这是一个新页面，以前没有索引过。它是从已建立索引的页面链接的，该页面也已被重新提交（连同“链接的页面”）以进行索引-如上面的屏幕快照所示。我还提交了包含此页面的XML站点地图（尽管尚未报告“索引”计数 -请参阅下面的“更新”）。老实说，我没有太大希望-如果将其编入索引，我会感到惊讶。不仅因为它是4xx代码，而且因为它不是 2xx成功代码。

通常，您可以执行“以Google身份获取”测试，然后请求将页面编入索引。对于单个页面来说，这通常非常快（“即时”）-但是该选项在上一页中不可用。

根据这条已有4年历史的博客文章，状态418将被Google忽略。

“忽略”表示将其视为200 OK状态。（除非在字面上被忽略，而Google没有做任何事情，否则这与在我的书中被“忽略”并不完全相同？）该博客文章的“问题”在于，他们正在测试已经被索引的页面。返回4xx状态并不一定会使页面从索引中删除，至少不会在相当长的时间内（取决于爬网速度），尽管据报道它们确实等待了“几周”。他们也没有提及Google网站站长工具中报告的抓取错误（由于更改为Google Search Console）。

这不是一个“真正的”错误

还是？它可能在一开始就被实现为“玩笑”，但是可以说确实表明了“错误状态”。我认为4xx代码不被视为“错误状态” 会更加矛盾。而且它仍然是“最新的”。1998年定义此状态代码的原始RFC 2324甚至在2014年用RFC 7168更新。

大多数工具会将418状态视为错误。或仅将200视为成功。当然，“ Apache日志查看器”和“尖叫的青蛙SEO蜘蛛”将418代码视为错误。

据报道，某些Web服务器执行418状态代码：

• /programming/24018008/is-there-a-server-that-implements-http-status-code-418

当检测到CSRF违规时，Stack Exchange甚至会使用以下HTTP状态代码：

• /meta/185426/stack-overflow-returning-http-error-code-418-im-a-teapot

更新2017年3月31日（超过2周）： Google未编制返回418 HTTP状态代码的页面。现在，GSC中的XML网站地图报告显示，在网站地图中提交的两个URL中只有一个已被索引（一个URL返回200并被索引，另一个URL返回418而不被索引）。

顺便说一句，GSC花了将近2个星期的时间来报告站点地图中URL的索引状态，但这与页面实际被索引的时间无关。例如，在提交站点地图时已经对一个页面进行了索引，但是，仅查看站点地图报告，就好像页面仅在提交站点地图后的13天才被索引。

现在，在“抓取>抓取错误”下将返回418的URL报告为“抓取错误”，并且将418声明为响应代码。根据报告，这是在2017年3月16日（提交上面的索引请求后的第二天）“检测到”的，但是，这是在GSC中报告的某个时候。