robots.txt で Googlebot のクロールを制御しましょう。ディレクトリのブロック、クロール頻度の指定、SEO のベストプラクティスを解説します。

要約
robots.txt は、サイトのルートに置くテキストファイルで、検索エンジンにサイトのどの部分をクロールし、どの部分を飛ばすかを伝え、クロールバジェットの管理と非公開ページのインデックス防止に役立ちます。
さらに詳しく知るには、こちらに質問
robots.txt は、検索エンジンがウェブサイトをクロールする方法を管理する、シンプルでありながら強力なファイルです。`https://example.com/robots.txt` に置かれ、Google、Bing、その他のボットがどのページとディレクトリをクロールできるかを指定するルールを含みます。robots.txt は、クロールバジェット(Google が 1 日にクロールするページ数)を管理し、重要でないページへのクロールの無駄を防ぎ、非公開のコンテンツを検索結果から遠ざける助けになります。
ほとんどのウェブサイトには robots.txt ファイルがありますが、多くは設定が誤っています。robots.txt の設定を誤ると、重要なページを誤ってブロックし、順位の可能性を無駄にします。適切に設定された robots.txt は、クロールの効率を高め、サイトのプライバシーを守ります。このガイドでは、robots.txt の構文、ベストプラクティス、実際の例を解説します。
robots.txt は、検索エンジンのボットにクロールの指示を伝える、標準化されたテキストファイルです。ボットがサイトを最初に訪れるとき、ほかのクロールを行う前に `/robots.txt` をリクエストします。ボットはルールを読み、それに従います(ボットが行儀の良いものである場合)。
Google の robots.txt のドキュメントは、この標準の権威ある参照先です。robots.txt の形式は 1994 年に作られ、広く採用されています。主要な検索エンジン(Google、Bing、Baidu)はすべて robots.txt を尊重します。
重要:robots.txt は指針であり、ファイアウォールではありません。行儀の良いボット(Google、Bing)は robots.txt のルールを尊重します。悪意のあるボットやスクレイパーは、robots.txt を無視します。robots.txt は検索エンジンのクロールを管理するために使い、ハッカーやスクレイパーをブロックするためには使わないでください。セキュリティには、サーバーレベルのツールを使います。
robots.txt はシンプルなテキストの構文を使います。各ルールは 2 つの部分からなります。User-agent(ルールが適用されるボット)と、Disallow のパス(ブロックするページ)です。
基本の例:
User-agent: *
Disallow: /admin/
Disallow: /staging/
Sitemap: https://example.com/sitemap.xml
これは、すべてのボット(`*` はすべてを意味します)に、`/admin/` と `/staging/` のディレクトリをクロールしないよう伝えます。Sitemap の行は、サイトマップの場所をボットに伝えます。
User-agent: \* は、すべてのボットを意味します。個別のボットを指定することもできます。
`User-agent: Googlebot` は Google のボットにだけ適用されます。`User-agent: Bingbot` は Bing のボットにだけ適用されます。異なるルールを持つ複数の User-agent のセクションを置くことができます。
Disallow: /path/ は、そのパスをクロールしないようボットに伝えます。Disallow: / は、サイト全体をブロックします。Disallow:(空)はすべてを許可します。1 つの User-agent に複数の Disallow のルールを列挙できます。
Allow: /path/ は、親のディレクトリが禁止されていても、特定のパスのクロールを許可します。例:Disallow: /temp/ としつつ Allow: /temp/important/ とすれば、/important/ のサブディレクトリだけがクロールできます。
パターン 1:管理ページをブロックする
User-agent: *
Disallow: /admin/
Disallow: /user/
Disallow: /account/
これは、管理用、ユーザー用、アカウント用のページのクロールをブロックします。これらのページは、通常、検索エンジンのためのものではありません。
パターン 2:ステージング環境をブロックする
User-agent: *
Disallow: /staging/
Disallow: /test/
ボットがサイトのテスト版やステージング版をクロールするのを防ぎます。
パターン 3:特定のファイルの種類をブロックする
User-agent: *
Disallow: /*.pdf
Disallow: /*.zip
ボットが PDF と ZIP ファイルをクロールするのを防ぎます。インデックスさせたくない PDF が多くある場合に役立ちます。
パターン 4:サーバーに負荷をかけるボットを遅くする
User-agent: AhrefsBot
Disallow: /
User-agent: SemrushBot
Crawl-delay: 10
Ahrefs のボットを完全にブロックします(SEO ツールにサイトをクロールされたくない場合)。Semrush のボットには、リクエストの間に 10 秒の遅延を加えて遅くします。Crawl-delay は、サーバーに過負荷をかける攻撃的なボットに役立ちます。
パターン 5:すべてを許可する(既定)
User-agent: *
Disallow:
これが既定です。空の Disallow は、すべてを許可することを意味します。すべてのコンテンツをクロール可能にしたいなら、robots.txt を完全に省略することもできます。
robots.txt はクロールをブロックします。メタ robots の noindex はインデックスをブロックします。両者は異なる目的を持ちます。
robots.txt を使うのは次のような場合です:クロールバジェットを節約したいとき。クロールすべきでない重複コンテンツがあるとき。ボットに触れさせたくない管理ページがあるとき。攻撃的なボットを遅くしたいとき。
メタ robots の noindex を使うのは次のような場合です:ページをクロールさせたいが、インデックスさせたくないとき(エラーや問題を確認するため)。インデックスを防ぎつつ、内部リンクとクロールは許可したいとき。最終的にページを検索から取り除きたいが、公開は続けたいとき。
例:`/products?page=2` のようなページ分割されたページは、クロールバジェットを節約するために robots.txt でブロックできます(Google は通常、ページ分割を集約するため)。ただし、canonical の関係を特定するためにクロールさせたいこともあります。その場合は、robots.txt の代わりに canonical を使います。
クロールバジェットは、Google がサイトで 1 日にクロールする URL の数です。数百万ページを持つ大規模なサイトでは、すべてのページを毎日クロールしてもらうことはできません。Google は、サイトの権威性と更新頻度に基づいてクロールバジェットを割り当てます。クロールバジェットは有限です。重要でないページに無駄にすれば、重要なページのクロールの頻度が下がります。
クロールすべきでないページをブロックして、クロールバジェットを最適化しましょう。重複コンテンツ、ページ分割された検索結果、ユーザーのアカウントページ、テスト用のページなどです。ブロックするページが 1 つ増えるごとに、Google が重要なコンテンツをクロールするためのバジェットが増えます。
クロールバジェットを無駄にするよくある原因:無限のページ分割(商品の絞り込みが無制限の URL を生む)、異なるパラメーターを持つ重複コンテンツ、すべての URL に付加されるセッション ID、際限なく URL を生成するカレンダーやイベントのページ。これらのパターンを、robots.txt でブロックしましょう。
Google Search Console は、サイトのクロールの統計を表示します。クロールのリクエストを毎日監視しましょう。Google が新しいコンテンツを見つけずに同じページを繰り返しクロールしているなら、robots.txt とブロックの戦略を見直します。
robots.txt にサイトマップの URL を含めましょう。robots.txt ファイルの末尾に `Sitemap: https://example.com/sitemap.xml` を加えます。これにより、Google が XML サイトマップの場所を見つけられます。複数のファイルがある場合は、複数のサイトマップを列挙できます。
例:
User-agent: *
Disallow: /admin/
Sitemap: https://example.com/sitemap.xml
Sitemap: https://example.com/sitemap-news.xml
robots.txt にサイトマップを記載するのは任意です(Google Search Console からサイトマップを送信することもできます)が、ベストプラクティスです。
Google Search Console には、robots.txt のテスターがあります。「設定」>「クロール」>「robots.txt をテスト」に進みます。URL を入力して、robots.txt がブロックするかどうかを確認できます。公開する前にルールを検証するのに、非常に役立ちます。
robots.txt の変更は、公開する前に必ずテストしましょう。たった 1 つの間違い(`Disallow: /` がサイト全体をブロックするなど)が、順位を急落させることがあります。テスターを使って、次のことを確認します。
重要なページがブロックされていないこと。管理ページがブロックされていること。重複コンテンツのパターンがブロックされていること。重要なパスが誤って禁止されていないこと。
robots.txt を公開した後は、Google Search Console のクロールレポートで変化を監視しましょう。クロールの頻度が予期せず下がったなら、重要なコンテンツを誤ってブロックした可能性があります。
間違い 1:CSS と JavaScript をブロックする。robots.txt で `/css/` や `/js/` をブロックすると、Google は CSS と JavaScript をクロールできません。CSS がなければ、Google はページを正しくレンダリングできません。CSS や JavaScript はブロックしないでください。
間違い 2:重要なコンテンツをブロックする。公開する前に必ずテストしましょう。`Disallow: /staging/` のつもりで `Disallow: /p` と打ち間違えると、意図せず `/products/` をブロックしてしまうことがあります。
間違い 3:セキュリティのために robots.txt を使う。機密データの保護を robots.txt に頼ってはいけません。セキュリティ上重要なページは、robots.txt だけでなく認証を必要とするべきです。robots.txt は公開されており、簡単に回避されます。
間違い 4:ドメイン間で robots.txt が一貫していない。複数のドメインがある場合は、robots.txt のポリシーを一貫させましょう。意図せず異なるルールになっていると、クロールの効率の問題を招くことがあります。
間違い 5:サイトマップ自体をブロックする。robots.txt で `/sitemap.xml` を決してブロックしないでください。Google がページを発見するには、サイトマップをクロールする必要があります。
Crawl-delay と Request-rate:これらの指示は、ボットを遅くします。`Crawl-delay: 10` はリクエストの間に 10 秒を加えます。`Request-rate: 1/10` は 10 秒に 1 リクエストを許可します。サーバーに過負荷をかけるボットに使いましょう。Google は、これらの指示の代わりに Search Console の設定を使うことを推奨しています。
Allow の指示:親のパスが禁止されていても、特定のパスのクロールを許可します。例外を設けるのに便利です。例:`Disallow: /temp/` としつつ `Allow: /temp/keep/` とすれば、keep のサブディレクトリだけが許可されます。
Google の robots.txt の仕様は、サポートされているすべての指示を記載しています。ほとんどの機能は、めったに必要になりません。多くのサイトでは、基本の User-agent、Disallow、Sitemap にとどめましょう。
User-agent ごとのルールによって、ボットごとに異なるクロールのルールを設定できます。Googlebot、Bingbot、その他の User-agent に対して、別々にルールを指定できます。Google にはサイト全体をクロールさせつつ、Bing には特定のセクションへのアクセスを制限したい場合に便利です。各ルールのブロックの先頭で User-agent を指定します。
`User-agent: Googlebot` は、Google のクローラーにだけルールを適用します。`User-agent: *` は、すべてのボットにルールを適用します。ルールは、次の User-agent の指示までは、その特定の User-agent に適用されます。異なるボット向けに、複数のルールのブロックを作れます。
Crawl-delay と Request-rate の指示は、ボットにクロールの頻度を伝えます。`Crawl-delay: 5` は、リクエストの間に 5 秒待つようボットに伝え、サーバーの負荷を減らします。`Request-rate: 1/10` は、10 秒に最大 1 リクエストとするようボットに伝えます。Google の robots.txt のドキュメントは、サポートされているすべての指示を詳しく説明しています。
サイトマップの場所の指示は、サイトマップの場所をボットに伝えます。`Sitemap: https://example.com/sitemap.xml` は、ボットを XML サイトマップに導きます。複数のサイトマップを指定できます。ボットがすべてのページを効率よく発見する助けになるので、推奨されます。
Clean-param の指示は、クロール前に URL パラメーターを取り除きます。`Clean-param: utm_source&utm_medium https://example.com` は、example.com の UTM パラメーターを無視するよう Google に伝えます。これにより、Google が追跡付きのリンクを重複コンテンツとして扱うのを防げます。Google が多くのトラッキングパラメーターを自動で処理するので、今ではあまり使われません。
robots.txt ファイルは、Google Search Console の robots.txt テスターでテストしましょう。このツールは、robots.txt によって Googlebot にどの URL がブロックされるかを示します。重要なページを誤ってブロックするのを防げます。
robots.txt は、検索エンジンのクロールを管理し、サイトのプライバシーを守るための、シンプルでありながら重要なファイルです。適切に設定された robots.txt は、重要でないページをブロックし、クロールバジェットを節約し、重複コンテンツが何度もクロールされるのを防ぎます。設定を誤った robots.txt は、重要なコンテンツを誤ってブロックし、順位を急落させることがあります。
robots.txt の変更は、公開する前に必ずテストしましょう。Google Search Console のテスターでルールを検証します。クロールの統計を毎月監視します。重要でないコンテンツをブロックし、クロールバジェットを効果的に管理しましょう。GEO SEO 診断ツールを使えば、robots.txt の設定を監査し、サイト全体のクロールのしやすさとインデックスに関する潜在的な問題を見つけられます。
出典
いいえ。robots.txt でページをブロックすると Google はクロールできなくなりますが、SEO の助けにはなりません。ページをインデックスさせたくないなら、代わりに noindex タグを使いましょう。robots.txt はクロールバジェットの節約に使います。
いいえ。robots.txt で CSS や JavaScript を決してブロックしてはいけません。Google がページを完全に理解するには、それらのリソースへのアクセスが必要です。ブロックすると、Google がコンテンツを正しくレンダリングできなくなります。
一般的に、Google のリクエストが多すぎない限り、クロールの頻度を設定する必要はありません。Google が帯域幅を使い果たしているなら、Crawl-delay の指定を使いましょう。ほとんどのサイトは、Google の既定のクロール頻度に対応できます。
先行導入企業のご紹介
