「418 I'm a Teapot」ステータスを返すページでGoogle Search Consoleの「Fetch as Google」ツールを使用すると、単に「エラー」が報告され、このページに対してインデックス作成をリクエストできません。
以下のスクリーンショットでは、円で囲まれた「エラー」は、418ステータスを返すページをリクエストした結果です。この段階では、これ以上の情報はありません。
私のアクセスログによると、GooglebotとSearch Consoleの両方がこのページにアクセスしましたが、まだインデックスに表示されていません。
明確にするために、これは新しいページであり、以前に索引付けされていません。これは、索引付けされたページからリンクされています。これは、索引付けのために(「リンクされたページ」と共に)再送信されました-上記のスクリーンショットに表示されています。(が、私はまた、このページを含むXMLサイトマップを提出した「インデックス」のカウントはまだ報告されていません - 以下を参照UPDATEを)。正直なところ、あまり望みはありません。インデックスに登録されたとしたら驚きます。4xxコードであるだけでなく、2xx成功コードでもないためです。
通常、「Fetch as Google」テストを実行してから、ページのインデックス作成をリクエストできます。これは通常、単一のページでは非常に高速(「インスタント」)ですが、このオプションは上記のページでは使用できません。
この4年前のブログ投稿によると、ステータス418はGoogleによって無視されます。
「無視」とは、200 OKステータスとして扱われることを意味します。(文字どおり無視され、Googleが「何も」しなかった場合を除いて、私の本で「無視」されているのと同じではありませんか?)そのブログ投稿の「問題」は、すでにインデックスに登録されているページをテストしていることです。4xxステータスを返しても、少なくともかなりの時間は(クロール頻度に応じて)、必ずしもインデックスからページが削除されるわけではありませんが、「数週間」待機していると報告されています。また、Googleウェブマスターツールで報告されたクロールエラーについても言及していません(Google Search Consoleに変更されたため)。
「本当の」エラーではありません
またはそれは?最初は「ジョーク」として実装されていた可能性がありますが、間違いなく「エラー状態」を示しています。4xxコードを「エラー状態」として扱わない方が矛盾するでしょう。そして、それはまだ「現在」です。このステータスコードを定義した1998年の元のRFC 2324は、2014年にRFC 7168で更新されました。
ほとんどのツールでは、418ステータスがエラーとして表示されます。または、200のみを成功と見なします。「Apacheログビューア」と「Screaming Frog SEOスパイダー」は確かに418コードをエラーと見なします。
一部のWebサーバーは、418ステータスコードを実装していると報告されています。
Stack Exchangeは、CSRF違反を検出するときに、このHTTPステータスコードを利用します。
UPDATE 2017-03-31(2週間以上後): 418 HTTPステータスコードを返すページは、Googleによってインデックスに登録されません。GSCのXMLサイトマップレポートは、サイトマップで送信された2つのURLの1つだけがインデックスに登録されていることを示します(1つのURLは200を返し、インデックスが付けられ、もう1つは418を返し、インデックスは付けられません)。
ちなみに、GSCがサイトマップのURLのインデックスステータスを報告するのに約2週間かかりましたが、これはページが実際にインデックス化された時期とは関係ありません。たとえば、サイトマップが送信されたときに1つのページが既にインデックス付けされていましたが、サイトマップレポートだけを見ると、ページはサイトマップが送信されてから13日後にしかインデックス付けされていないようです。
418を返すURLは、[クロール]> [クロールエラー]で「クロールエラー」として報告され、418が応答コードとして示されます。レポートによると、これは2017-03-16(上記のインデックスリクエストを送信した翌日)に「検出」されましたが、GSCで報告される前のいつかでした。