【ITニュース解説】How to check if robots.txt is blocking Google (and fix it without breaking anything)

robots.txtとは、検索エンジンのクローラーと呼ばれるプログラムに対して、ウェブサイトのどこをどのように巡回してよいか、または巡回してはいけないかを指示するテキストファイルだ。システムエンジニアを目指す上でその仕組みを理解しておくことは非常に重要になる。このファイルは、ウェブサイトのトラフィックや検索エンジンの評価に大きく影響するため、もし誤った設定をしてしまうと、ウェブサイトが検索結果に表示されなくなり、訪問者が激減するといった事態に陥る可能性がある。しかし、ページ自体はブラウザで正常に表示されるため、問題が発生していても気づきにくいという特性がある。

robots.txtファイルは、ウェブサイトのルートディレクトリに配置される。例えば、https://example.comというサイトであれば、そのrobots.txtはhttps://example.com/robots.txtというURLでアクセスできる。ここで注意すべきは、www.example.comやblog.example.comのように、ホスト名が異なればそれぞれ異なるrobots.txtを持つ可能性がある点だ。自分のサイトの正規URL（canonical URL）がどのホストを使っているかを確認し、そのホストのrobots.txtをチェックする必要がある。 ファイルが存在するかどうか、そしてその内容をコマンドラインから確認するには、curlコマンドが便利だ。例えば、curl -sI https://example.com/robots.txt | head -1と実行すれば、robots.txtファイルのHTTPステータスコードを確認できる。このステータスコードは非常に重要だ。例えば、200 OKが返されれば、Googleなどの検索エンジンはそのファイルに書かれたルールに従ってサイトを巡回する。しかし、404 Not Foundや410 Goneが返された場合、検索エンジンは『ルールがない』と判断し、サイトのすべてのページを自由に巡回する可能性がある。さらに悪いケースとして、5xx Server Errorやタイムアウトが発生すると、検索エンジンは安全のために一時的にサイト全体のクロールを停止してしまうことがある。これは、ルールを解釈できないため、どのページを巡回してよいか判断できないためだ。このように、robots.txtが存在しないよりも、壊れたrobots.txtの方が大きな問題を引き起こす可能性がある。

robots.txtのルールは、User-agentという記述によってグループ化される。User-agentとは、サイトにアクセスするクローラーの種類を識別するための名前だ。例えば、User-agent: Googlebotと書かれていれば、その下にあるルールはGoogleのクローラーにのみ適用される。一方、User-agent: *と書かれている場合は、特定のクローラーが指定されていない限り、すべてのクローラーに適用される一般的なルールとなる。 複数のUser-agentグループがある場合、クローラーは自分に最も具体的なグループのルールを適用し、他のグループのルールは無視する。例えば、User-agent: *で/admin/をDisallow（巡回禁止）とし、さらにUser-agent: Googlebotでサイト全体をDisallow: /と記述した場合、Googlebotは後者のDisallow: /のルールに従い、サイト全体がブロックされることになる。これは、特定のクローラー向けに以前設定したルールが残っている場合に、意図しないサイト全体のブロックを引き起こす原因となることがある。 Googleのクローラーの場合、複数のルールがURLに一致した際、最も長いルールが優先されるという特別な挙動がある。さらに、同じ長さのAllow（巡回許可）とDisallowルールがあった場合は、Allowが優先される。例えば、Disallow: /shop/とAllow: /shop/products/というルールがあったとする。この場合、/shop/cartはDisallow: /shop/という短いルールに一致するためブロックされるが、/shop/products/red-shoesはより長いAllow: /shop/products/というルールに一致するため許可される。 ルールにはワイルドカードも利用できる。*は任意の文字列にマッチし、$はURLの末尾にマッチする。例えば、Disallow: /*?sort=は、URLに?sort=が含まれるソートされたリストページをブロックし、Disallow: /*.pdf$は、拡張子が.pdfであるすべてのURLをブロックする。 特に重要なのが、Disallow: /という一行だ。これは『このホスト上のどのページも巡回してはいけない』という意味で、サイト全体を検索エンジンから隠す強力な指示となる。一方、Disallow:（コロンの後に何も書かない）は、『すべての巡回を許可する』という意味になる。たった一つのスラッシュの有無で、サイト全体が閉鎖されるか、完全に開放されるかが決まるため、記述には細心の注意が必要だ。

設定したrobots.txtが正しく機能するかを確認するには、いくつかの方法がある。最も確実なのは、Google Search Consoleの機能を利用することだ。Google Search Consoleには、robots.txtレポートというものがあり、Googleがサイトのどのrobots.txtファイルを検出したか、いつ最終的に取得したか、そして解析上の問題がないかを確認できる。特定のURLがクロールされるかどうかを確認したい場合は、URL検査ツールを使用する。このツールにURLを入力すると、『クロール可能か？』という項目が表示され、もしrobots.txtによってブロックされていれば『いいえ：robots.txtによってブロックされています』と明確に表示される。 ローカルでテストしたい場合、Pythonには基本的なrobots.txtパーサーが組み込まれている。from urllib import robotparserを使って、例えばrp.can_fetch("Googlebot", "https://example.com/shop/products/red-shoes")のように呼び出すことで、特定のURLがGooglebotによってクロール可能かテストできる。ただし、Pythonのパーサーは、Googleの『最も長い一致ルールが勝つ』という挙動ではなく、最初に一致したルールを採用するため、複雑なAllow/Disallowの組み合わせの場合には、Google Search Consoleのレポートか、Googleが公開しているオープンソースのrobots.txtパーサーを使うのがより正確だ。

robots.txtの機能にも限界があることを理解しておく必要がある。robots.txtは、あくまで『クローラーの巡回を停止する』ためのツールであり、『検索エンジンのインデックスからページを削除する』ためのものではない。つまり、robots.txtでブロックされたURLであっても、もし他のページからそのURLへのリンクが存在すれば、GoogleはそのURLを検索結果に表示してしまうことがある。ただし、通常は説明文なしで表示される。もし特定のページを検索結果から完全に削除したい場合は、そのページのHTMLヘッダにnoindexメタタグを追加するか、HTTPレスポンスヘッダにX-Robots-Tag: noindexを設定する必要がある。この際、Googleがnoindexタグを認識できるように、そのページ自体はクロール可能にしておく必要がある点を忘れてはならない。 また、robots.txtは公開されたアドバイスに過ぎない。これはセキュリティツールではないため、秘密の情報を保護するために使うべきではない。機密性の高い情報は、認証や適切なアクセス制御によって保護する必要がある。

ウェブサイトが意図せずrobots.txtによってブロックされてしまうケースは少なくない。よくあるのが、ステージング環境用のrobots.txtファイルが、本番環境に誤ってデプロイされてしまうというパターンだ。ステージング環境では、開発中のサイトが検索結果に表示されないようDisallow: /が設定されていることが多く、これが本番にコピーされるとサイト全体がブロックされてしまう。 CMS（コンテンツ管理システム）の中には、『検索エンジンのインデックス登録を禁止する』といったチェックボックスがあり、これをオンにすると仮想的なrobots.txtの内容が変更され、サイトがブロックされることもある。 また、特定のセクションをブロックしようとして書いた広すぎるルールも問題を起こしやすい。例えば、Disallow: /pと書いた場合、/print/という意図したパスだけでなく、/products/や/pricing/といった全く関係のないパスもブロックされてしまう。これは、ルールがプレフィックス（前方一致）で適用されるためだ。 Googleは、ウェブページをレンダリング（ブラウザで表示されるように処理すること）して評価するため、ウェブサイトのデザインや機能を制御するCSSファイルやJavaScriptファイルがrobots.txtでブロックされていると、Googleはページを正しくレンダリングできず、レイアウトが崩れた状態と認識する可能性がある。これも検索ランキングに悪影響を与える可能性がある。 最後に、サーバーやCDN（コンテンツデリバリーネットワーク）の変更後にrobots.txtファイルが5xxエラーを返すようになり、Googleがルールを読み取れなくなるケースもある。

もしrobots.txtに問題が見つかった場合、修正は慎重に行う必要がある。変更は最小限にとどめ、問題のあるルールだけを修正するように心がける。修正後は、ファイルが200 OKを返し、新しい内容が正しく提供されていることを確認する。Google Search Consoleのrobots.txtレポートを開き、ファイルの再クロールをリクエストすると、Googleが新しいルールをより早く認識してくれる。そして、数ページで良いので、URL検査ツールを使って『クロール可能か？はい』と表示されることを確認し、意図した通りに機能していることを最終確認する。 robots.txtは、それ自体が自然に壊れることは稀で、ほとんどの場合、誰かが新しいバージョンをデプロイした時に問題が発生する。そのため、新しいリリースが行われるたびにrobots.txtの内容をチェックするか、自動監視ツールを利用して、Googlebotのクロール状況を定期的に監視することが賢明だ。たった5分間のファイル確認が、後になって何週間ものトラフィック損失を防ぐことにつながる。