Robots.txt：このファイルがクローラーやAIボットをどのように制御するか

robots.txtは、ウェブ上で最も古い制御ファイルの一つですが、それでもなお誤って設定されていることがよくあります。このファイルは、検索エンジンのクローラーがウェブサイトのどの領域にアクセスできるかを指定するだけでなく、AIシステムがコンテンツをトレーニングデータやリアルタイムの回答に利用するかどうかを決定する役割も、ますます重要になってきています。これがサイトの技術的基盤とどれほど密接に関連しているかは、クロールと読み込み時間に関する当サイトの記事で解説しています。さらに、サイトマップは、どのページがインデックス登録の対象となるかを示しています。

Robots.txt ファイルの具体的な役割

従来の検索エンジンのクローラーを制御する

AIクローラーと新たなボットの動向

Robots.txt の適切な管理とテスト

Robots.txt：実務でよく見られるミス

Robots.txtとタグ管理の連携

Robots.txt ファイルの具体的な役割

このファイルはドメインのルートディレクトリにあり、単純なテキスト形式のルールで構成されています。各ルールは「User-agent」という項目を通じて特定のクローラーを対象とし、「Disallow」または「Allow」によって、そのクローラーがアクセスできるパスを指定します。Google、Bing、その他の検索エンジンは、クロールを行う前にこのファイルを読み取り、通常は指定内容を確実に遵守します。

ルートディレクトリにたった1つの誤った「Disallow」エントリがあるだけで、ドメイン全体がGoogleのインデックスから除外されてしまう可能性があります。

そのため、このファイルはウェブサイトにおいて最も繊細な技術的調整要素の一つと言えます。スラッシュの書き忘れや、パスが広すぎただけで、本来表示されるべき領域が表示されなくなってしまうこともあります。このファイルを変更した場合は、新しいバージョンを公開する前に、必ず結果をテストする必要があります。

特定のボットへのアクセスを個別に許可する
ディレクトリ全体をクロール対象から除外する
サイトマップへのパスを設定する
重要なページにクロール予算を割り当てる
インデックス登録から重複コンテンツを保護する

従来の検索エンジンのクローラーを制御する

Googlebot、Bingbot、および同様の検索エンジンのクローラーは、アクセスするたびにrobots.txtを再読み込みします。特定のUser-Agent行を使用することで、各ボットごとに個別のルールを定義することができ、例えばBingにはGoogleとは異なる領域を表示させるといった設定が可能です。 Google Search Consoleには、変更が実際に反映される前に、個々のURLを最新のrobots.txtファイルと照合して確認できる専用のテストツールが用意されています。特に、フィルタページやショッピングカートのパスを持つ大規模なオンラインショップでは、適切な設定を行うことで、貴重なクロール予算が無関係なページに浪費されるのを防ぐことができます。

検索エンジンごとに独自のルールを設定する
フィルターページとカートページを除外する
変更を行う前には必ずテストツールを使用する
必要に応じてクロール遅延を設定する

AIクローラーと新たなボットの動向

従来の検索エンジンに加え、現在ではGPTBot、ClaudeBot、Google-Extended、CCBotなど、robots.txtを読み取るAIクローラーの数が増加しています。独自のユーザーエージェントエントリを設定することで、これらのシステムがトレーニングデータとしてコンテンツを収集することを許可するか、あるいはリアルタイムの回答に利用することを許可するかを指定できます。この制御は、現在では適切な技術的可視性戦略の不可欠な要素となっており、当社のSEO/GEO監査でも確認されています。また、サイトのリニューアルの際も、robots.txtの確認は最初のステップの一つであり、意図しないブロック設定が新しいサイトに移行しないようにする必要があります。さらに、構造化されたランキング要因にも注目したい方は、当社の「オンページ最適化」に関する記事で、より詳細なアプローチをご覧いただけます。

GPTBotとClaudeBotを個別に許可する
AIトレーニング用のGoogle-Extendedについては別途取り決める
リニューアルのたびにルールを確認する
技術的な可視性を定期的に監査する

Robots.txt の適切な管理とテスト

このファイルは一度きりの作業ではなく、サイト構造に大きな変更があるたびに更新する必要があります。新しいディレクトリの追加、パスの変更、あるいはコンテンツ管理システムの変更により、実際にクロールされるべき領域が頻繁に変化します。Search Consoleを定期的に確認することで、本来は不要になったブロックにGoogleが遭遇していないか、あるいは重要な領域が誤ってブロックされたままになっていないかを確認できます。また、技術的な分析を行う外部ツールを活用すれば、実際の可視性の問題に発展する前に、ファイルの最新バージョンと以前のバージョンの違いを可視化することができます。

構造の変更があるたびにファイルを確認する
Search Consoleの警告を定期的に確認する
古いロックが現在も有効かどうかを確認する
本番稼働前の変更内容を記録する

Robots.txt：実務でよく見られるミス

最もよくあるミスは、Disallow設定の範囲が広すぎて、本来は単一のディレクトリのみを対象とするはずが、誤ってウェブサイト全体の領域をブロックしてしまうことです。また、後の行で以前の許可設定が取り消されるような矛盾したルールも、クロール動作が不明確になる原因となることがよくあります。特にコンテンツ管理システム（CMS）を切り替える際、パス構造が完全に変わっているにもかかわらず、このファイルが変更されずに引き継がれてしまうことがよくあります。

もう1つの典型的な問題として、時間の経過とともに変化するURL構造が挙げられます。その結果、古い「Disallow」ルールは、とっくに存在しなくなったパスを指し示してしまう一方で、実際に機密性の高い新しい領域は保護されないままになってしまうのです。

Disallowエントリの範囲を広すぎないようにする
矛盾する規則を徹底的に整理する
システム変更後にファイルを再検証する
古いパスを定期的に削除する

Robots.txtとタグ管理の連携

Google Tag Managerのようなツールは、多くの場合、追加のドメインから外部スクリプトを読み込みますが、それらのスクリプト自体も独自のクロールルールを設定している場合があります。自サイトの robots.txt だけに注目していると、別のドメインに埋め込まれたスクリプトが全く異なる設定を持っていることに気づきにくくなります。

複数のサービスが連携しているような複雑な構成の場合、自社のメインドメインだけでなく、関連するすべてのドメインについて定期的に現状把握を行うことが重要です。