Webサイトを運営していると、テストページや管理画面など、検索結果に表示させたくないページが出てくることがあります。
そのような無駄なクロールを防ぎ、サイト内の重要なページにクローラーのリソースを集中させるために役立つのが「robots.txt」です。
robots.txtは、検索エンジンのクローラーに対して、サイト内のどのページやディレクトリにアクセスしてよいか、逆にアクセスしてほしくないかを指示するためのテキストファイル。
このファイルを適切に設定することで、クロールの効率化を図り、結果としてSEO評価の向上につなげられます。
この記事では、robots.txtの基本的な意味から、できること・できないこと、具体的な書き方や設定方法、さらにはよくあるトラブルへの対処法まで、Webサイトの運用担当者が知っておくべき情報を網羅的に解説します！
robots.txtとは？
robots.txtは、検索エンジンのクローラーに対して、サイト内のどのページやディレクトリにアクセスしてよいか、逆にアクセスしてほしくないかを指示するためのテキストファイルです。
ウェブサイトのルートディレクトリに配置され、クローラーがサイトを訪れた際にまず最初にこのファイルを参照します。
このファイルの主な目的は、クローラーの動きを効率的に制御することにあります。
例えば、テスト環境のページ、管理画面、あるいは検索結果に表示させる必要のない画像やPDFファイルなど、クロールしてほしくないコンテンツへのアクセスを制限できます。
これにより、無駄なクロールを減らし、サイト内の重要なページにクローラーのリソースを集中させることができます。
結果として、優先的にインデックスされたいページにおいて検索エンジンのデータベースに登録される速度が上がり、SEO評価の向上につながるのです。
できることと、できないこと
robots.txtが持つ機能と限界を正しく理解することは、サイト運営において非常に重要です。
できること：クロール制御
robots.txtの最も基本的な機能は、クロール制御です。
クローラーに対して特定のディレクトリやファイルを巡回させないよう指示できます。
例えば、Disallow: /admin/と記述すれば、/admin/以下の全てのページはクロールされなくなります。
これにより、外部に公開すべきでない管理画面や、重複コンテンツとして認識される可能性があるページをクローラーから隠すことが可能です。
これはあくまでクローラーへの「お願い」であり、悪意のあるボットは指示を無視する可能性があるため、機密性の高い情報は別途アクセス制限を設ける必要があります。
できないこと：インデックス削除
robots.txtは、すでにインデックスされてしまったページを検索結果から削除する機能は持っていません。
クローラーはページのクロールを禁止されても、他のサイトからの被リンクなどによってそのページの存在を知っている場合があるためです。
検索結果から特定のページを完全に削除したい場合は、HTMLファイルにnoindexタグを記述するか、Google Search Consoleの「URL削除ツール」を使用する必要があります。
noindexタグがクローラーに認識されるためには、該当ページへのクロールを許可しておく必要があるため、robots.txtでnoindexタグのあるページのクロールを禁止しないように注意してください。
配置場所と取得ルール
robots.txtファイルを正しく機能させるためには、その配置場所とルールを厳守する必要があります。ファイル名は必ず「robots.txt」とし、大文字や小文字を間違えないように注意しましょう。
配置する場所は、ウェブサイトのルートディレクトリです。
例えば、サイトのURLがhttps://example.com/であれば、robots.txtはhttps://example.com/robots.txtに設置する必要があります。
サブディレクトリ（例：https://example.com/blog/robots.txt）に配置しても、クローラーには認識されないため無効になります。
また、サブドメインごとに個別のrobots.txtファイルが必要です。
たとえば、blog.example.comというサブドメインを運用している場合、blog.example.com/robots.txtにも個別にファイルを設置しなければなりません。
example.com/robots.txtのルールは、blog.example.comには適用されないため、それぞれのサブドメインでクロール制御を行う際には注意が必要です。
主要クローラーの違い
robots.txtの指示に従うクローラーは、検索エンジンによって異なります。
代表的なクローラーとその特徴を知ることで、より効果的なクロール制御が可能になります。
| Googlebot Google検索エンジンが使用するクローラーです。robots.txtの記述を正確に解釈し、ルールに従ってクロールを行います。Googlebotには、PC向けのGooglebot、モバイル向けのGooglebot Smartphone、画像用のGooglebot-Imageなど、複数の種類が存在します。 Bingbot MicrosoftのBing検索エンジンが使用するクローラーです。Googlebotと同様にrobots.txtのルールを遵守します。 その他（一般ボット） 世の中には、GooglebotやBingbot以外にも、さまざまな目的を持つクローラーやスクレイピングボットが存在します。これらの中には、robots.txtのルールを無視したり、そもそも読み込まないものもあります。例えば、悪意のあるボットはrobots.txtの指示を無視してサイトのコンテンツを不正に収集しようとすることがあります。そのため、robots.txtはあくまで「紳士的なクローラーへの案内」と捉え、機密性の高い情報や非公開コンテンツはパスワード保護などの別の手段で守るのが安全です。 |
robots.txtはいつ使う？
ファイルを活用すべきタイミングを理解することで、サイトの運用効率を飛躍的に高めることができます。
【前提】必須ではない
robots.txtの利用は、すべてのウェブサイトに必須というわけではありません。
特に、ページ数が少なく、更新頻度も低い小規模なサイトでは、robots.txtを設定しなくても、検索エンジンのクローラーが適切に巡回してくれることがほとんどです。
このようなサイトでは、あえてrobots.txtを設定することで、かえってクロールの妨げになったり、意図しない設定ミスで重要なページがインデックスされなくなるリスクが生じる可能性もゼロではありません。
Googleをはじめとする主要な検索エンジンは、基本的にrobots.txtがなくてもサイト全体をクロールし、インデックスすべきページを判断する能力を持っています。
そのため、まずは無理に設定する必要はない、という前提でrobots.txtの活用を検討するのが良いでしょう。
中〜大規模・高頻度更新サイトでの利点
robots.txtが特にその効果を発揮するのは、ページ数が1000を超える中規模から大規模なウェブサイト、またはコンテンツの更新頻度が高いサイトです。
これらのサイトは、ページ数が多いために、クローラーがすべてのページを効率的に巡回しきれない「クロールバジェット」の問題に直面することがあります。
robots.txtを使うことで、価値の低いページ（例：過去のキャンペーンページ、タグやカテゴリーページなど）や、検索結果に表示させる必要のないテスト環境、管理画面などをクロール対象から外すことができます。
これにより、クローラーは重要なコンテンツ（例：最新の記事、商品情報、サービス詳細ページなど）に集中してリソースを割くことができ、結果として検索エンジンへのインデックスが早まり、SEO評価の向上につながります。
メディアや機密ディレクトリを避けたいとき
ウェブサイトの運営において、特定のコンテンツをクローラーから隠したい場面は多々あります。
たとえば、社員向けの非公開ドキュメント、開発中のテストページ、CMSのログイン画面、あるいは個人情報が含まれる可能性のあるディレクトリなどです。
これらのページが検索結果に表示されてしまうと、セキュリティ上のリスクが生じたり、ユーザーに混乱を与えたりする可能性があります。
robots.txtは、このような機密性の高いディレクトリやメディアファイル（画像、PDFなど）へのクローラーのアクセスを制御するのに非常に有効です。
Disallowディレクティブを使うことで、指定したパス以下のコンテンツをクローラーに巡回させないように指示できます。
これにより、意図しない情報漏洩や、不必要なコンテンツが検索結果に表示されるのを防ぎ、サイトの健全な運用に貢献します。
クロールエラー・負荷が多いとき
Google Search Consoleを利用していると、サイトのクロール状況に関するさまざまな情報が得られます。
もし「クロールの統計情報」レポートでクローラーによる巡回数が異常に多かったり、または「クロールの統計情報」や「インデックス カバレッジ」レポートにクロールエラーが多数表示される場合、それはrobots.txtの活用を検討する良い兆候です。
クローラーがサイト内の存在しないページや、重要でないページを繰り返しクロールしていると、サーバーに余計な負荷がかかるだけでなく、クロールバジェットが無駄に消費されてしまいます。
このような状況を改善するためにrobots.txtを使用すれば、クロールの対象を制限し、サーバーへの負荷を軽減できます。
さらに、クロールエラーの原因となっている特定のパスをクロール対象から外すことで、エラーの発生を抑え、健全なインデックス状況を保つことにもつながります。
Search Consoleのデータを定期的に確認し、サイトの状態に応じてrobots.txtを調整することが、効率的なサイト運用には不可欠です。
他の手段との違い
robots.txtは、クローラーの動作を制御するための有効な手段ですが、サイト運用には他にも様々なツールが存在します。
それぞれの役割と使いどころを理解し、robots.txtと適切に組み合わせることで、より効果的なSEO施策が実現できます。
meta robots／x-robots-tag（noindex等）との住み分け
robots.txtは、クローラーに特定のディレクトリやファイルへのクロールを「許可・不許可」で指示するためのものです。
しかし、クローラーがそのページをクロールしたとしても、そのページをインデックス（検索エンジンのデータベースに登録）するかどうかは別の問題です。
ここで登場するのが、meta robotsタグやX-Robotsタグです。
これらは、ページ単位で検索結果への表示可否を指示するもので、noindexという値を設定することで、クローラーに「このページはインデックスしないでください」と明確に伝えられます。
robots.txtでクロールを拒否すると、クローラーはページの内容を読み込めないため、noindexタグも認識できません。
したがって、検索結果からページを確実に消したい場合は、robots.txtでクロールをブロックするのではなく、ページにnoindexタグを設定し、クローラーにそのページをクロールさせる必要があります。
検索結果から消すときの正しい手順
検索結果からページを完全に消すためには、以下の正しい手順を踏む必要があります。
| ページにnoindexタグを設置する：該当ページのHTMLの<head>セクションに<meta name=”robots” content=”noindex”>を追記します。 クローラーの再訪を待つ：noindexタグを設置したページが、クローラーによって再び巡回されるのを待ちます。クローラーはnoindexタグを認識すると、そのページを検索結果から削除します。 （緊急時）Google Search Consoleの「URL削除ツール」を利用する：ページの削除を急ぐ場合は、Google Search ConsoleのURL削除ツールを使って、一時的に検索結果から削除するリクエストを送信できます。 |
robots.txtはあくまでクロールの制御ツールであり、インデックスの削除ツールではないことを覚えておきましょう。
認証やHTTPステータス（404/410/401/403）の使いどころ
robots.txtによるクロール制御は、あくまで「クローラーへのお願い」です。
より強力な制御やセキュリティが必要な場合は、サーバー側での設定が必要になります。
| 404 Not Found / 410 Gone：存在しないページや削除したページに対して返されるHTTPステータスコードです。これらのステータスコードを返すことで、クローラーはページが恒久的に存在しないことを認識し、検索結果から削除する動きを促します。 401 Unauthorized / 403 Forbidden：パスワード認証が必要なページやアクセスが許可されていないページに対して返されるステータスコードです。これにより、悪意のあるボットや一般のユーザーが非公開コンテンツにアクセスするのを防ぐことができます。 |
robots.txtと異なり、これらのサーバー設定はすべてのリクエストに対して機能するため、セキュリティレベルを向上させたい場合に有効です。
canonical／内部リンク整理との併用
robots.txtは、重複コンテンツの問題を解決するのにも役立ちますが、canonicalタグや内部リンクの整理と組み合わせることで、より効果を発揮します。
| canonicalタグ：重複したコンテンツが存在する場合、正規のURLをcanonicalタグで指定することで、検索エンジンに「このページが本家です」と伝えられます。robots.txtで重複ページをクロール拒否すると、canonicalタグを認識できないため、重複コンテンツとして評価されるリスクが残ります。canonicalタグを設定し、クロールを許可する方が推奨されます。 内部リンクの整理：サイト内のリンク構造を最適化し、重要なページに内部リンクを集中させることで、クローラーがそのページを重要だと認識しやすくなります。同時に、robots.txtで不要なページのクロールを制限することで、クローラーはより効率的に重要なページを巡回できるようになります。 |
これらを併用することで、重複コンテンツによる評価の分散を防ぎ、サイト全体のSEO評価を向上させられます。
robots.txt設定の準備
robots.txtを効果的に設定するためには、事前の準備が必要です。
サイトの構造を把握し、どのようなページを制御したいのかを明確にすることで、意図しないクロール拒否や設定ミスを防ぎ、狙い通りのSEO効果を得ることができます。
許可／拒否したい領域の洗い出し
例えば、以下のようなコンテンツは、一般的にクロールを拒否する候補となります。
| 管理画面やログインページ：公開する必要がなく、セキュリティ上のリスクにもなりうるため。 テスト環境や開発中のページ：本番環境とは異なるコンテンツが含まれるため、検索結果に表示されるとユーザーを混乱させる可能性があるため。 大量の重複コンテンツを生成するページ：フィルター機能やソート機能によって生成される、ほとんど同じ内容のページ。これらをクロールさせると、クロールバジェットを無駄に消費するだけでなく、SEO評価を分散させる可能性があります。 個人情報を含む可能性があるディレクトリ：サイトの会員情報やフォームの送信先など、セキュリティを確保すべき領域。（ただしrobots.txtでセキュリティが担保できるわけではない） |
これらの領域をリストアップすることで、robots.txtに記載すべきディレクティブが明確になります。
URL設計・パラメータの整理
robots.txtの設定をより正確に行うためには、サイトのURL設計を理解し、特に動的なページに付与されるURLパラメータを整理しておくことが重要です。
例えば、https://example.com/products?sort=priceのように、検索結果の並び替えや絞り込みに使われるパラメータは、重複コンテンツを生み出す原因になります。
これらのパラメータ付きURLをクロールさせないよう設定することで、検索エンジンが正規のページを正しく評価できるようになります。
また、URLが正規化されていない場合（例：https://example.com/とhttps://www.example.com/が同じコンテンツを表示している場合）、robots.txtの設定を適切に行わないと、クローラーが重複を誤って認識する可能性があります。
したがって、URLの構造を把握し、どのURLがクロールされるべき「本物」のページなのかを整理しておくことが、robots.txt設定の精度を高める上で不可欠です。
本番・ステージング・開発の扱い方針
ウェブサイトの運用では、本番環境の他に、テスト用のステージング環境や開発環境を設けるのが一般的です。
これらの環境が、誤って検索エンジンにインデックスされてしまうと、ユーザーを混乱させたり、機密情報が露呈したりするリスクがあります。
robots.txtは、本番環境だけでなく、これらのテスト環境でも適切に設定することが非常に重要です。
ステージング環境や開発環境では、すべてのクロールを拒否する設定を最初から入れておくことを推奨します。
例えば、User-agent: *とDisallow: /を記述することで、すべてのクローラーがサイト全体を巡回しないようにできます。
本番環境では、クロールさせたいページを許可しつつ、先ほど洗い出した管理画面や重複コンテンツを生成する領域をクロール拒否する設定を行います。
このように、環境ごとに異なるrobots.txtファイルを準備し、適切な運用方針を定めることが、サイト全体のセキュリティとSEOを両立させる鍵となります。
robots.txtの構文
ここでは、robots.txtで使用される主要なディレクティブ（指示）について解説します。
User-agent（特定／全クローラー）
User-agentディレクティブは、その後の指示がどのクローラーに対して適用されるかを指定します。
| 全クローラーへの指示：User-agent: *と記述すると、すべてのクローラーがその指示に従うことになります。 特定のクローラーへの指示：特定のクローラーにだけ指示を出したい場合は、そのクローラー名を記述します。例えば、User-agent: Googlebotと記述すると、Googlebotにのみ指示が適用されます。User-agentは複数回記述でき、それぞれのブロックに異なる指示を設定できます。 |
もし複数のUser-agentに同じ指示を適用したい場合は、それぞれのUser-agentを個別に記述するか、User-agent: *でまとめて指示を出すかのどちらかになります。
特定のクローラーへの指示は、User-agent: *の指示よりも優先されるため、例えばUser-agent: *でサイト全体をクロール拒否しつつ、User-agent: Googlebotで特定のディレクトリだけを許可するといった使い方も可能です。
Disallow（パス、* と $ の基本）
Disallowディレクティブは、クローラーに特定のディレクトリやファイルへのアクセスを禁止する際に使用します。
| ディレクトリ全体を拒否：Disallow: /private/のように記述すると、/private/以下すべてのページがクロール対象外となります。 特定のファイルを拒否：Disallow: /document.pdfと記述すると、指定したファイルのみがクロールされなくなります。 |
Disallowディレクティブでは、*（アスタリスク）と$（ドル記号）をワイルドカードとして使用することで、より柔軟な制御が可能です。
*は任意の文字列にマッチします。例えば、Disallow: /*.jpgと記述すると、URLの末尾が.jpgで終わるすべての画像をクロール拒否できます。
$はURLの終端を示します。Disallow: /example$と記述すると、exampleというパスそのものは拒否されますが、example/testのようなサブディレクトリは拒否されません。
これらのワイルドカードを組み合わせることで、複雑な条件でのクロール制御が可能になります。
Allow（部分許可、CSS/JSの許可）
Allowディレクティブは、Disallowディレクティブで広範囲にクロールを拒否している中で、特定のディレクトリやファイルだけを例外的に許可したい場合に使用します。
例えば、Disallow: /assets/と設定し、assetsディレクトリ全体をクロール拒否している場合でも、Allow: /assets/style.cssと追記することで、そのCSSファイルだけはクロールを許可することができます。
これは、クローラーがウェブページのレンダリング（表示）を正しく行うために、CSSやJavaScriptファイルへのアクセスを許可する場合によく使われます。
Googleなどの主要な検索エンジンは、ページの表示を正しく理解するためにこれらのファイルへのアクセスを必要とします。
Allowディレクティブは、Disallowディレクティブよりも優先されるため、設定が競合する場合はAllowが適用されることを覚えておきましょう。
AllowはDisallowの後、かつ、Allowで許可したいパスの直前に記述することで、より意図が明確になります。
Sitemap（絶対URL、複数可）
Sitemapディレクティブは、サイトマップの場所をクローラーに伝えるために使用します。
サイトマップには、サイト内の重要なページのURLがリスト化されているため、この情報をクローラーに提供することで、クロールの効率化を促すことができます。
| 記述方法：Sitemap: https://example.com/sitemap.xmlのように、サイトマップの絶対URLを記述します。 複数サイトマップ：複数のサイトマップがある場合は、Sitemapディレクティブを複数行記述することで、すべてをクローラーに知らせることができます。 |
SitemapはUser-agentディレクティブのブロック外に記述しても問題ありませんが、一般的にはファイルの末尾にまとめて記述されることが多いです。
エンジン依存の指示（例：Crawl-delay）
robots.txtには、特定の検索エンジンにのみ有効な独自の指示が存在します。
その代表例がCrawl-delayです。
Crawl-delayは、クローラーがサイトを巡回する際に、次のページをリクエストするまでの間隔（秒数）を指定するものです。
例えば、Crawl-delay: 10と記述すると、クローラーはページを1つ取得するたびに10秒間待機します。
これにより、クローラーによるサーバーへの過度な負荷を抑えることができます。
ただし、Crawl-delayは現在、Googlebotではサポートされていません。
Bingbotなど、一部のクローラーでは有効ですが、すべてのクローラーがこの指示に従うわけではない点に注意が必要です。
Googlebotのクロール速度を調整したい場合は、Google Search Consoleの「クロールレート設定」を利用する必要があります。
コメント／文字コード（UTF-8）／大小文字の注意
robots.txtファイルを作成する際には、いくつかの基本的なルールを遵守する必要があります。
| コメント：行頭に#を記述することで、その行をコメントアウトできます。設定の意図などをメモしておくことで、後からのメンテナンスが容易になります。 文字コード：ファイルはUTF-8で保存する必要があります。UTF-8以外の文字コードで保存すると、クローラーが正しくファイルを解釈できない可能性があります。 大小文字の区別：ディレクティブやパスは大小文字を区別します。例えば、Disallow: /private/とDisallow: /Private/は異なるパスとして扱われます。robots.txtというファイル名も同様で、robots.txt以外の名前（例：Robots.txt）にすると、クローラーに認識されません。 |
これらの基本ルールを守ることで、robots.txtファイルが正しく機能し、サイトのクロール制御を正確に行うことができます。
robots.txtの具体的な作成と設置方法
robots.txtの構文や使い方を理解したら、実際にファイルを作成してウェブサイトに設置する手順を学びましょう。
正確な方法で設置しないと、意図したクロール制御が機能しないため、具体的な手順をしっかり押さえることが重要です。
テキストファイル作成（拡張子なし、UTF-8）
robots.txtファイルはテキストエディタで作成できます。
ファイル名は必ず「robots.txt」とし、大文字や小文字を間違えないように注意が必要です。
また.txtの拡張子はつけますが、一般的なドキュメントファイルとは異なり、特別なフォーマットを意識する必要はありません。
最も重要なのは、文字コードをUTF-8で保存することです。
Shift-JISなどの他の文字コードで保存すると、クローラーがファイルを正しく読み取れず、設定が無視されてしまう可能性があります。
多くのテキストエディタでは、保存時に文字コードを選択できるので、必ずUTF-8を選択してください。
ファイルに記述する内容は、これまでに解説してきたUser-agentやDisallowなどのディレクティブです。
最小テンプレート／推奨テンプレート
robots.txtは、サイトの要件に応じて記述内容が変わりますが、基本的なテンプレートを理解しておくと便利です。
最小テンプレート
特別なクロール制御が必要ない場合、以下の最小テンプレートを使用します。
| User-agent: * Disallow: |
この記述は、すべてのクローラーに対して、どのパスもクロール拒否しない、つまりサイト全体をクロール許可することを意味します。
Disallowの後にパスが何も記述されていないため、実質的にすべてのクローラーにサイトの巡回を許可する最も基本的な設定です。
推奨テンプレート
サイトマップの場所を明記し、サーバーへの負荷を考慮したより丁寧なテンプレートは、以下のようになります。
| User-agent: * Disallow: /wp-admin/ Disallow: /cgi-bin/ Disallow: /search/ Sitemap: https://www.example.com/sitemap.xml |
このテンプレートでは不要なディレクトリをクロール拒否し、さらにSitemapディレクティブでサイトマップのURLを明記しています。
これにより、クローラーは効率的に重要なページを発見し、サイトのインデックス状況を健全に保つことができます。
サイトルートに配置、サブドメインごとの用意
作成したrobots.txtファイルは、ウェブサイトのルートディレクトリに配置する必要があります。
たとえば、サイトのドメインがhttps://example.com/であれば、https://example.com/robots.txtとしてアクセスできる場所に配置します。
サブディレクトリ（例：https://example.com/blog/robots.txt）に配置しても、クローラーには認識されないため注意が必要です。
また、サブドメインを運用している場合は、サブドメインごとに個別のrobots.txtファイルを用意する必要があります。
CMS・CDN環境での注意（キャッシュ／自動生成の干渉）
CMS（コンテンツ管理システム）やCDN（コンテンツデリバリネットワーク）を利用している環境では、robots.txtの設置や更新に際して、いくつかの注意点があります。
| CMSの自動生成：WordPressなどの一部のCMSでは、設定内容に応じてrobots.txtファイルが自動生成される場合があります。この場合、手動で作成したファイルをアップロードしても、CMSの設定が優先されたり、上書きされたりすることがあります。まずはCMSの管理画面でrobots.txtに関する設定項目がないか確認しましょう。 キャッシュの干渉：CDNを利用している場合、robots.txtファイルがキャッシュされることで、更新内容がすぐに反映されないことがあります。robots.txtを更新した後は、CDNのキャッシュをクリアする、またはキャッシュの有効期限が切れるのを待つ必要があります。 プラグインの利用：CMSによっては、robots.txtを簡単に編集・管理できるプラグインが提供されている場合があります。このようなツールを活用することで、手動での設定ミスを防ぎ、より効率的な運用が可能になります。 |
これらの環境特有の注意点を理解しておくことで、設定が意図通りに機能しないといったトラブルを未然に防ぐことができます。
robots.txt記述の確認方法
robots.txtファイルを作成し、サーバーにアップロードした後、その設定が正しく機能しているかを確認することは非常に重要です。
設定ミスがあると、重要なページがインデックスされず、SEOに悪影響を及ぼす可能性があります。
ここでは、robots.txtの設定を検証するための具体的な方法を解説します。
robots.txtファイルの取得状況を確認
Google Search Consoleの「設定」から「robots.txt」を開くことでrobots.txtの読み込み状況を見ることができ、ウェブサイトにアップロードされたrobots.txtファイルを読み込み、特定のクローラーが特定のURLにアクセスできるかどうかをシミュレーションします。
万が一、不適切な記述があった場合はその場で修正し、正確なファイルをアップロードして再クロールをリクエストしましょう。
インデックス状況を確認
Google Search Consoleの「URL検査」ツールで、任意のURLがインデックス登録されているかどうかを確認できます。
URL検査ツールに特定のページのURLを入力すると、Googlebotがそのページをどのようにクロールしているか、インデックスされているかなどのステータスを確認できます。
まだページを更新して間もない場合は「公開URLをテスト」で状態を確認できます。
ライブテストを実行するとリアルタイムでGooglebotがそのページをクロールする際に、robots.txtによってブロックされていないか、noindexタグが検出されていないかなどを確認できます。
もしrobots.txtによってクロールがブロックされていると表示された場合、そのURLは検索結果にインデックスされない可能性があるため、robots.txtの設定を見直す必要があります。
サーバーログでの実地チェック
robots.txtテスターやURL検査は、あくまでGooglebotのシミュレーションです。より確実な方法として、サーバーに記録されるアクセスログを直接確認することも有効です。
サーバーログには、Googlebotやその他のクローラーが実際にサイトを訪問した記録が残されています。
ログを確認することで、robots.txtでクロールを拒否したはずのディレクトリに、クローラーがアクセスしようとした痕跡がないか、逆にクロールを許可した重要なページに、クローラーがきちんと巡回してきているかなどを実地で検証できます。
これにより、robots.txtの設定が正しく機能しているかだけでなく、想定外のクローラーがサイトにアクセスしていないか、サーバーに過度な負荷をかけていないかといった運用状況も把握することができます。
サーバーログの解析ツールを利用すると、より効率的にこれらの情報を確認できます。
よくある質問
robots.txtの運用においては、細かな疑問や特定の状況に対応するための質問がよく寄せられます。ここでは、robots.txtに関する特に多い質問とその回答をまとめました。
サイトマップの複数記載と分割運用はどうすればいい？
複数記載のルール
複数のサイトマップが存在する場合、robots.txtファイル内にSitemapディレクティブを複数行記述することで、すべてのサイトマップをクローラーに知らせることができます。
| Sitemap: https://www.example.com/sitemap_ja.xml Sitemap: https://www.example.com/sitemap_en.xml |
分割運用のメリット
大規模なサイトでは、サイトマップをコンテンツの種類や言語ごとに分割して運用することが推奨されます。
これにより、特定のコンテンツの更新頻度に応じてサイトマップを個別に管理でき、クローラーに効率よく情報を提供できます。
サイトマップは単一のファイルで最大50,000URLまで記述できますが、これを分割することで、変更があった部分だけを更新すればよくなり、管理が容易になります。
ワイルドカードは正規表現なの？（使える記号の範囲）
robots.txtで使えるワイルドカードは、*（アスタリスク）と$（ドル記号）の2種類のみです。
これらは、一般的な正規表現で使われる記号とは異なり、機能が限定されています。
サブディレクトリ運用で独自ポリシーを適用できる？
はい、できます。robots.txtはドメインのルートディレクトリに配置するため、通常はサイト全体に適用されます。
しかし、例えばブログをサブディレクトリで運用している場合など、サブディレクトリ内でのみ特定のポリシーを適用したい場合があります。
この場合、User-agentディレクティブの後に、特定のサブディレクトリ向けのルールを記述します。
| User-agent: * Disallow: /admin/ User-agent: Googlebot Disallow: /blog/search/ |
この例では、すべてのクローラーに対して/admin/ディレクトリをクロール拒否する一方で、Googlebotにのみ/blog/search/ディレクトリをクロール拒否するように指示しています。
このように、User-agentを分けて記述することで、サブディレクトリ単位で異なるルールを適用することが可能です。
画像・動画検索だけを制御したい場合はどうする？
robots.txtでは、Googlebotの中でも特定のクローラーに対して指示を出すことができます。
画像検索や動画検索を制御したい場合は、それぞれのクローラー名を指定してルールを記述します。
| 画像検索：Googlebot-Image 動画検索：Googlebot-Video |
例として、画像検索だけをクロール拒否したい場合は、以下のように記述します。
| User-agent: Googlebot-Image Disallow: /images/ |
これにより、通常のウェブ検索には影響を与えずに、画像検索に表示させたくない画像を管理できます。
同様に、動画検索も個別に制御できます。
ただし、これらのクローラーへの指示も、User-agent: *の指示より優先されます。
一時的に全クロール停止したいときの安全手順は？
サイトのメンテナンスや大規模な改修作業などで、一時的にすべてのクロールを停止したい場合があります。
この時、誤った手順を踏むと、インデックスが削除されるなどの致命的な問題につながる可能性があるため、以下の安全な手順を踏むことが重要です。
robots.txtでの全クロール停止
最も一般的な方法は、robots.txtにDisallow: /を記述することです。
| User-agent: * Disallow: / |
この記述により、クローラーはサイト全体をクロールしなくなります。
しかし、この方法はあくまで一時的なクロール停止であり、インデックスの削除を目的とするものではありません。
HTTPステータスコードの利用
より確実な方法として、メンテナンス中のページに対して503 Service UnavailableというHTTPステータスコードを返す方法があります。
503エラーは、検索エンジンに「一時的にサービスが利用できない状態」であることを伝えるため、クロールは停止されますが、インデックスは保持されます。
メンテナンスが終了したら、通常通り200 OKのステータスコードを返すことで、クローラーは再び巡回を再開します。
サーバーパスワード保護
セキュリティをさらに高めたい場合は、サイト全体をパスワードで保護する方法も有効です。
これにより、クローラーだけでなく、一般のアクセスも遮断できます。
まとめ
今回はrobots.txtの基本から応用まで、Webサイトの運用担当者が知っておくべき知識を網羅的に解説しました。
robots.txtは、正しく使えばサイトのSEOを向上させる強力な武器となりますが、誤った設定は致命的な問題を引き起こす可能性もあります。
この記事で解説した内容を参考に、自社のサイトに合った適切なrobots.txtを設定し、健全なサイト運用とSEO評価の向上を目指しましょう！
Webマーケをお考えなら、「AI×知見×アイディア」のぎあはーとへ！
合同会社ぎあはーとは「AI×プロの知見×アイディア」で強いマーケ戦略を安く、早くお届けする会社です。
| ・月間売上を前年比277.4%に （3,479,415円→9,653,169円） （上場アパレルメーカーM社：2021年 運用1年） ・新規サイトで月間コンバージョン数を31件へ （ メディア系SaaSツールC社：2025年 施策10ヶ月） ・Webイベントで840名の参加者集客 （メディア系SaaSツールC社：2025年 イベント期間30日） |
こんな実績を持つWebマーケティングのプロが、他にできない強い施策を素早く回転させます。
戦略からコンテンツ運用、結果分析までをワンストップで受けつけております。また、コンサルタント業務もお受けしております。
まずは面談による無料のサイト診断ができますので、ぜひお気軽にご相談ください！
