「ホームページを制作してもらったけど、Googleになかなかインデックスされない」「SEO対策をお願いしたとき、制作会社に『robots.txtを確認します』と言われたけど、よくわからなかった」——そんな経験はありませんか？
実はrobots.txtは、設定が正しければ問題ないのですが、ちょっとしたミス設定がサイト全体をGoogleに認識されない状態にしてしまう、とても影響力の大きいファイルです。知らないうちに問題が起きていても気づきにくいため、発注者として最低限の知識を持っておくことが重要です。
「SEO対策をしているのになぜか成果が出ない」「制作会社との打ち合わせで何の話をしているかわからない」——そういった状況を避けるためにも、このページでrobots.txtの役割と、気をつけておきたいポイントをわかりやすく解説します。
この記事では、robots.txtとは何か・なぜ重要なのか・よくあるミス・発注者として確認すべきポイントを、専門知識ゼロからでもわかるよう説明します。
robots.txtとは何か
robots.txt（ロボッツテキスト）とは、Googleなどの検索エンジンの自動巡回プログラム（クローラー）に対して「このページは見てください」「このページは見ないでください」というルールを伝えるためのテキストファイルです。
Webサイトのルート（最上位の場所）に設置され、クローラーがサイトを訪れたとき、まず最初にこのファイルを読みに来る仕組みになっています。つまり、クローラーへの「最初の案内役」といえます。
ファイルの場所は必ず https://あなたのドメイン/robots.txt です。たとえば https://example.com/robots.txt のような形になります。ブラウザのアドレスバーにそのURLを入力すると、誰でも中身を見ることができます。
中身はとてもシンプルなテキストで、以下のような内容が書かれています。
User-agent: *
Disallow: /admin/
Disallow: /private/
Sitemap: https://example.com/sitemap.xml
User-agent: *→ すべてのクローラーに対してDisallow: /admin/→/admin/フォルダは巡回しないでくださいSitemap:→ このURLにサイトマップがあります
これだけのシンプルな構成で、サイトの巡回を制御できます。
類似用語・関連用語との違い
robots.txt と noindexタグの違い
似た目的に使われるものとして「noindex（ノーインデックス）タグ」があります。両者の違いは、「クロールを止める」か「インデックスを止める」かです。
robots.txtはクローラーがページに「来る・来ない」を制御します。一方、noindexタグはクローラーがページを読みに来た上で「Googleの検索結果に登録するかどうか」を制御します。
つまり、robots.txtで巡回禁止にしてしまうと、Googleはそのページの内容を一切読まないため、noindexの指示も読めません。このことが、よくある設定ミスの原因になっています（詳しくは「よくある失敗・問題点」のセクションで解説します）。
robots.txt と XMLサイトマップの違い
XMLサイトマップは「このページを積極的に巡回してください」とクローラーを誘導するものです。一方、robots.txtは「このページは来ないでください」と制限するものです。
両者は反対の役割を持ちますが、robots.txtの中にXMLサイトマップの場所を記載することで、セットで機能させることができます。
robots.txt と .htaccessの違い
.htaccessはサーバー側でアクセスを制御するファイルで、ユーザーのアクセス自体を遮断できます。一方、robots.txtはあくまでクローラーへの「お願い」であり、クローラーがルールを守ることを前提としています（悪意あるボットはrobots.txtを無視することもあります）。
robots.txtが重要な理由
クロールバジェットを効率的に使える
Googleのクローラーは、一つひとつのサイトに無限に時間を使えるわけではありません。特定のサイトに対して「このくらいの量を巡回する」という上限があり、これを「クロールバジェット」と呼びます。
小規模サイトではあまり意識する必要はありませんが、数百〜数千ページ以上のサイトでは、不要なページ（管理画面・テスト用ページ・重複URLなど）にバジェットを使わせないことが重要です。
robots.txtで不要なページを巡回対象から外すことで、Googleに本当に見てほしい重要なページへ効率よくバジェットを集中させることができます。
不要なページが検索結果に出るのを防げる
管理画面のログインページ・会員限定ページ・テスト中のページ・重複コンテンツなどが検索結果に表示されてしまうと、ユーザーが混乱したり、サイトの評価が下がったりする可能性があります。
robots.txtでこれらのページをクロール対象から除外しておくことで、意図しないページが検索結果に現れるリスクを下げられます。
AIクローラーによるコンテンツの無断学習を防げる
近年、ChatGPTやGeminiなどのAIサービスの普及にともない、Webサイトのコンテンツを学習データとして収集するAI専用クローラーが急増しています。代表的なものにOpenAIの「GPTBot」やGoogleの「Google-Extended」などがあります。
robots.txtでこれらのクローラーを個別にブロックすることで、自社コンテンツがAI学習に無断使用されることを防ぐ対策ができます。
よくある失敗・問題点
robots.txtはシンプルなファイルですが、1文字のミスがサイト全体に大きな影響を与えます。実際に起きやすいミス事例を紹介します。
すべてのページをクロール禁止にしてしまう
最も深刻なミスが、次のような設定です。
User-agent: *
Disallow: /
これは「すべてのクローラーに対して、すべてのページへの巡回を禁止する」という意味です。たった2行ですが、この設定ではGoogleがサイトのどのページも読めなくなり、検索結果に一切表示されない状態になります。
驚くことに、これはサイトのリニューアル時や開発環境のテスト中によく発生するミスです。「テスト中はGoogleに見せたくない」という意図でこの設定を入れておき、本番リリース後に外し忘れてしまうケースが後を絶ちません。
必要なページを誤ってブロックしている
たとえば、管理画面フォルダ /admin/ だけブロックしようとして、誤って /a から始まるすべてのページをブロックしてしまうケースがあります。スラッシュの位置や書き方によって、意図しない範囲までブロックされてしまうことがあるため注意が必要です。
robots.txtで禁止してからnoindexを書いている
「検索結果に出したくないからnoindexタグを書いたのに、念のためrobots.txtでもブロックした」という二重対策は、実は逆効果になることがあります。
前述のとおり、robots.txtでクロールをブロックするとGoogleはそのページを読めません。そのため、ページ内に書いたnoindexの指示もGoogleに届きません。結果として、Googleが過去に収集した古い情報を検索結果に残し続けるケースがあります。
「ページを検索結果に出したくない」場合は、robots.txtでブロックするのではなく、noindexタグを使うのが正しい対処法です。
テスト環境と本番環境で設定が混在している
テスト環境用のrobots.txtをそのまま本番サーバーにアップロードしてしまうミスも珍しくありません。テスト環境では「すべてブロック」の設定が必要なこともありますが、それを本番に持ち込んでしまうと大変なことになります。
更新が古いまま放置されている
サイトの構造が変わったのに、robots.txtが古いままになっているケースです。リニューアルでフォルダ構成が変わった・削除したページのパスが残っている・追加したページへのアクセスが誤って制限されているなど、放置するほど問題が複雑になっていきます。
実施すべき施策・活用方法
管理系ページのブロック設定
WordPressのサイトであれば、管理画面（/wp-admin/）や投稿プレビュー（/?p=xxx など）をブロックしておくことが一般的です。これらのページは検索結果に出る必要がなく、クロールバジェットの無駄遣いにもなります。
ただし、テーマCSSやJavaScriptファイル（/wp-content/）はブロックしないよう注意が必要です。GoogleはCSSやJavaScriptを読み込んでページのデザインを確認してランキングを評価するため、これらをブロックすると評価に悪影響が出ることがあります。
AIクローラーの選択的ブロック
AIクローラーへの対応は、現在多くの企業が検討しているテーマです。以下のように、特定のクローラーだけをブロックする設定が可能です。
User-agent: GPTBot
Disallow: /
User-agent: Google-Extended
Disallow: /
User-agent: anthropic-ai
Disallow: /
コンテンツが資産であるメディアサイトや、オリジナルコンテンツを多く持つサイトは検討の価値があります。ただし、AIクローラーをすべてブロックすることが必ずしも正解ではなく、状況によってはAI経由の流入機会を失う可能性もあります。どうするか迷う場合は制作会社に相談してみましょう。
URLパラメーターページのブロック
検索結果の並び替えやフィルタリングで生成される ?sort=price&order=asc のようなURLパラメーター付きページは、内容がほぼ同じ「重複コンテンツ」になりがちです。これらをrobots.txtでブロックすることで、重複による評価の分散を防げます。
ECサイトやポータルサイトなど、URLパラメーターが多用されるサイトで特に重要な設定です。
XMLサイトマップのURLを記載する
robots.txtにXMLサイトマップのURLを記載することで、巡回してほしいページをGoogleに積極的にアピールできます。
Sitemap: https://example.com/sitemap.xml
Google Search Consoleへの送信と合わせて行うことで、より効果的にGoogleへページを知らせることができます。
検索結果に出したくないページの整理
会員専用ページ・購入完了ページ・プライバシーポリシーなど、検索結果に出す必要のないページの扱いを整理しましょう。ただし前述の通り、「検索に出したくないがGoogleに読ませたい（noindexで処理したい）」ページはrobots.txtでブロックしないことが重要です。
実際の設定は制作会社と相談しながら決めることをおすすめします。
制作会社へのrobots.txt確認依頼
「robots.txtの現在の設定を見せてもらえますか？」「本番サイトの設定でブロックしているページを教えてください」——これだけを確認するだけでも、潜在的なトラブルを防げることがあります。
特にサイトをリニューアルした直後・外注先を変更した直後は、必ず確認する習慣をつけておきましょう。
定期的な棚卸し・見直し
robots.txtは設定したら終わりではなく、サイト構造の変化に合わせて定期的に見直すことが重要です。年に1〜2回、制作会社と合わせてレビューする機会を作ることをおすすめします。
実施の4ステップ
robots.txtの設定・見直しをどのように進めればよいか、実際の手順をご紹介します。
ステップ1：現状のrobots.txtを確認する
まず、現在どのような設定になっているかを確認しましょう。ブラウザで https://あなたのドメイン/robots.txt にアクセスするだけで中身を見ることができます。
「Disallow: /」という記述があれば要注意です。全ブロック設定になっている可能性があります。
ステップ2：問題がないか診断する
Google Search Consoleの「robots.txtテスター」（現在はURL検査ツールに統合）やサードパーティの診断ツールを使って、設定が意図どおりに機能しているか確認します。
また、Search Consoleの「カバレッジ」レポートで「robots.txtによりブロックされました」という警告が出ていないかも確認しましょう。
ステップ3：制作会社と連携して修正する
問題が見つかった場合や、設定を見直したい場合は、制作会社に修正を依頼します。このとき「どのページをブロックしたいか」「どのページはGoogleに見せたいか」を事前に整理しておくと、スムーズに進みます。
ステップ4：Search Consoleで反映を確認する
修正後は、Google Search Consoleで意図したとおりにページがクロールされているか・インデックスされているかを確認します。反映には数日〜数週間かかることがあるため、しばらく経ってから再確認するのがポイントです。
効果測定・ツール紹介
robots.txtの設定状況を確認・監視するためのツールを紹介します。
Google Search Console（サーチコンソール）
Googleが無料で提供する分析ツールです。以下の機能でrobots.txtの影響を確認できます。
- URL検査ツール：特定のページがクロール・インデックスされているかを確認できます。「robots.txtによりブロックされています」という表示が出れば、そのページがブロックされている証拠です
- カバレッジレポート：サイト全体でどのページがインデックスされているか・問題があるページはどれかを一覧で確認できます
- サイトマップレポート：XMLサイトマップの読み込み状況と、送信したURLとインデックス数の差を確認できます
Screaming Frog（スクリーミングフロッグ）
SEO専門家が広く使う、サイト全体をクロールして問題を洗い出すツールです。有料ですが、500URL以内であれば無料で使えます。robots.txtの設定によってブロックされているページの洗い出しや、リンク切れの確認などに役立ちます。
robots.txtオンラインバリデーター
検索エンジンから「robots.txt validator」「robots.txt checker」などで探すと、robots.txtの構文が正しいかチェックしてくれる無料ツールが見つかります。設定に不安がある場合はこれらを活用しましょう。
成功事例
事例1：リニューアル後にGoogleからの流入が消えていたケース
あるBtoBサービスの会社が自社サイトをリニューアルしました。リニューアル後、数週間経ってもGoogleからのアクセスがほぼゼロに。調べてみると、開発中に設定した Disallow: /（全ページブロック）のrobots.txtがそのまま本番サーバーに残っていたことが原因でした。
修正後、数週間でGoogleのクロールが再開。1〜2か月後には以前と同水準のアクセスに戻りました。気づくまでに時間がかかったため、その間の機会損失は少なくありませんでした。
リニューアル直後は必ずrobots.txtを確認する——これが教訓です。
事例2：重複URLのブロックでSEO評価が改善したケース
ECサイトを運営する会社が、商品の並び替えやフィルタリングで大量のURLパラメーター付きページが生成されていることに気づきました。これらは内容がほぼ同じ重複ページであり、Googleにとって評価の分散やクロールバジェットの無駄遣いになっていました。
robots.txtでパラメーター付きURLをブロックし、本来の商品ページに評価を集中させる設定を入れたところ、数か月後に主要キーワードでの検索順位が改善しました。
事例3：AIクローラーブロックでコンテンツ資産を守ったケース
専門的な情報を多く持つコンテンツメディアの会社が、AIクローラーによる無断学習への対策としてrobots.txtにGPTBotなどをブロックする設定を追加しました。
技術的な効果の測定は難しいですが、自社コンテンツが競合AIサービスの回答に使われるリスクを減らし、コンテンツ資産を守る経営判断として実施したとのことです。AIに使われるよりも、自社サイトへの流入として価値を享受したいという考え方です。
始める前に確認しておくこと
robots.txtに取り組む前に、以下の点を整理しておくと制作会社とのやりとりがスムーズになります。
現在のrobots.txtは存在するか
ブラウザで https://あなたのドメイン/robots.txt にアクセスして確認してください。「404エラー（ページが見つかりません）」が表示された場合は、robots.txtが設置されていない状態です。
Google Search Consoleは設定済みか
設定が正しく機能しているかを確認するには、Search Consoleの利用が前提になります。まだ設定していない場合は、制作会社に依頼して設定してもらいましょう。
直近でサイトのリニューアルや引っ越しはあったか
リニューアルや移転後はrobots.txtの設定が変わることがあります。制作会社の担当者に「robots.txtの設定は確認済みですか？」と確認してみましょう。
ブロックしたいページの具体的なイメージはあるか
「管理画面は検索に出したくない」「テスト用ページは見せたくない」など、要件を整理しておくと相談がしやすくなります。
外注先の制作会社はSEO基盤の設定も対応しているか
robots.txtはSEO基盤の一部です。「デザインだけ」「コーディングだけ」という外注先には、SEO設定まで任せられない場合があります。SEO視点での設定もお任せできるパートナーを選ぶことが重要です。
robots.txtは小さなファイルですが、設定を誤るとサイト全体がGoogleに認識されなくなるという、大きな影響力を持つ存在です。外注しているからこそ、発注者として「確認すべきポイント」を知っておくことが大切です。制作会社を選ぶときや、現状のサイトを見直すタイミングで、ぜひこの記事を参考にしてみてください。