【ITニュース解説】A 200 response isn't a passing crawl check: a five-site audit

システムエンジニアを目指す皆さんは、Webサイトの動作を確認する際、「HTTPステータスコード200」という数字を目にすることが多いだろう。これは「リクエストが成功した」という意味で、多くの場合は「ページが正常に表示された」と解釈される。しかし、このニュース記事が指摘するのは、その解釈が常に正しいとは限らないという重要な点だ。単に200が返ってきたからといって、Webサイトが意図した通りに機能しているとは限らないのである。

この問題意識から、Webサイトの「手動アクセス監査」の重要性が浮き彫りになる。これは、単なるステータスコードの確認に留まらず、実際にサーバーから返されるレスポンスの中身を詳細に検査する作業を指す。特に、検索エンジンやAIエージェントといった自動クローラーがWebサイトをどのように認識するかは、ビジネス上極めて重要だ。記事では、5つの自社サイトを例に挙げ、具体的にどのような問題が見つかったかを解説している。

監査では、それぞれのサイトに対して、次の4つのパスをテストしている。まずは、サイトのトップページである「/」。次に、検索エンジンのクローラーに対して、どのページを巡回してよいか、あるいは巡回してはいけないかを指示する「/robots.txt」。そして、サイト内のページのリストを提供する「/sitemap.xml」。最後に、AIエージェント向けの特別な情報を提供する可能性のある「/llms.txt」というファイルだ。これらのパスそれぞれに対して、サーバーがどのようなHTTPステータスコードを返し、どのような種類のコンテンツ（Content-Type）を送り、そのコンテンツの長さ（ボディ長）はどのくらいか、さらにはコンテンツの内容が全く同じであるかどうかをチェックするために「SHA-256」というハッシュ値を記録している。トップページに関しては、さらにHTMLの中にタイトル、見出し（H1）、説明（description）、正規URL（canonical link）といった要素が含まれているかも確認する。

実際にこれらのテストを実行した結果、いくつかの興味深い発見があった。特に顕著だったのは、「Living Traditions」というサイトで発生していた問題だ。このサイトでは、「/robots.txt」「/sitemap.xml」「/llms.txt」の全てが、HTTPステータスコード200を返したにもかかわらず、その中身は期待されるプレーンテキストやXMLではなく、サイトのトップページと同じHTMLコンテンツだった。さらに、これら3つのパスとトップページのコンテンツのバイト数とSHA-256ハッシュ値が完全に一致していたことから、これは「キャッチオール」と呼ばれる問題であることがわかる。これは、サーバーが存在しないURLへのアクセスを受け取った際に、エラーを返すのではなく、代わりにトップページのような特定のページを返してしまう設定が原因で起こる。つまり、ファイルが存在するかのように見せかけているだけで、本来の機能は果たしていない状態だったのだ。

しかし、この「キャッチオール」問題が直ちに「検索エンジンからのサイトのブロック」を意味するわけではない、と記事は注意を促している。例えば、Googleのrobots.txtの解析に関するドキュメントには、たとえダウンロードしたコンテンツがHTMLであっても、その中から有効なルールを抽出しようと試みると記載されているからだ。したがって、「robots.txtがHTMLを返したからGoogleにブロックされた」と安易に結論付けるべきではない。修理の際には、意図されたファイルを明示的に提供し、存在しないパスに対しては適切なHTTP 404 Not Foundを返すように設定を変更すべきだ。そして、この修正が実際に検索ランキングや引用に影響を与えたかどうかは、別途測定する必要がある。

一方で、「PlainData」と「PayMatch」というサイトでは、「/llms.txt」に対してHTTP 404 Not Foundが返され、そのコンテンツタイプもプレーンテキストだった。これは、意図しないHTMLを返す「キャッチオール」とは異なり、ファイルが存在しないことを正直に伝えているため、「正直な不在」として記録される。このような場合、監査の目的は、そのファイルが存在しないこと自体を問題視するのではなく、「なぜ存在しないのか」「提供するべき情報なのか」といった議論を促すことにある。すべてのサイトに特定のファイルが存在することを義務付けるべきではない。また、「Agent Tools API」というサイトでは、「/sitemap.xml」が404 JSONを返していた。APIサイトでは一般的なHTMLマーケティングページとは異なるため、同じルールを画一的に適用することは適切ではないという指摘は、監査における柔軟な判断の重要性を示している。

さらに、記事は、一部のサイトでメタデータ（meta descriptionやcanonical link）が不足していたからといって、それが直ちに検索エンジンがそのページを利用できない証拠となるわけではない点も強調している。Googleの公式ドキュメントでは、正規URLの指定が必須ではないと明記されており、Google自身が最適な正規URLを選択できるとされている。したがって、「これらのタグがないとAI検索の可視性が保証されない」と結論付けるのは早計であり、適切なタスクは「明示的な説明や正規URLの設定が、ページの明確さや一貫性を高めるか検討する」といった内容になるべきだ。

このような監査を自分で行うために、記事にはPythonを使った簡単なコード例が示されている。このコードは、指定されたURLにアクセスし、ステータスコード、コンテンツタイプ、ボディ長、そしてコンテンツのハッシュ値を表示する。これは、Webサイトの基本的な応答を検査するための、非常に実践的な方法だ。監査結果を記録する際には、観察されたURL、観察日時、ステータス/タイプ、発見された証拠、次のタスク、そして再テスト結果といった項目を明確に記録することが推奨される。

まとめると、このニュース記事は、HTTPステータスコード200という一見成功を示す指標が、Webサイトの実際の動作を完全に反映しているわけではないという重要な教訓を提供している。システムエンジニアを目指す皆さんにとって、サーバーからの応答を単なるステータスコードだけでなく、そのコンテンツの中身まで深く掘り下げて確認する姿勢は、Webサイトの健全性を確保し、潜在的な問題を早期に発見するために不可欠なスキルとなるだろう。Webサイトの監査は、表面的な状態だけでなく、その裏側にあるサーバーの挙動や設定、そしてそれが検索エンジンやユーザーにどう影響するかを理解するための、深い洞察をもたらす貴重なプロセスなのである。