robots.txtとは？書き方・設定方法・SEOへの影響を解説
「robot.txtってどう書けば良いのか」「設置場所は決まっているのか」「設定を間違えるとSEOにどう影響するのか」——テクニカルSEOの初学者から実務担当者まで多くの人が抱える疑問です。なお正式名称は「robots.txt」（複数形）ですが、検索エンジンでは「robot.txt」「robots txt」「ロボッツテキスト」など複数の表記で検索されているため、本記事では正式名称で統一して解説します。robots.txtは、検索エンジンのクローラ（Googlebotなど）に対して「どのページをクロールしてよいか／してほしくないか」を伝えるためのテキストファイルで、SEOにおける技術的な土台のひとつです。
本記事では、robots.txtの基本概念から、構文の書き方、ファイルの設置方法、用途別の記述例、SEOへの影響、2026年に重要性が高まっているAIクローラ（GPTBot・ClaudeBot・Google-Extendedなど）への対応、確認・テスト方法、よくあるミスまでを体系的に解説します。「robot.txt」「robots.txt」で情報を求めているWeb担当者・SEO担当者・エンジニアが、自社サイトの設定を正しく行えるようになる実務ガイドとして役立ててください。
robots.txtを正しく扱うには、まずその役割と「できること・できないこと」の境界を正確に理解することが重要です。多くのSEO上のトラブルは、robots.txtを誤解した使い方に起因しています。
robots.txtとは、Webサイトのルートディレクトリに配置するテキストファイルで、Googlebotをはじめとした検索エンジンのクローラ（ロボット）に対して、サイト内のどのURLにアクセスしてよいか／してほしくないかを伝えるための仕様です。1994年に提案された「Robots Exclusion Protocol（REP）」というプロトコルに基づいており、2022年にはIETFによってRFC 9309として正式に標準化されました。実務的には、サイトの管理画面・テスト環境・検索結果ページ・パラメータ付きURLなど、検索エンジンにインデックスさせる必要がない領域へのクロールを抑制し、クロールバジェットを重要なページに集中させる役割を担います。
robots.txtでできるのは、あくまで「クローラがそのURLにアクセスするのを抑制する」ことだけです。具体的には、特定のディレクトリやファイルへのクロール制限、特定のクローラだけを対象にした制限、サイトマップ（sitemap.xml）の場所の通知などが可能です。一方でrobots.txtでできないこともあります。第一に、すでにインデックスされているURLを検索結果から削除することはできません。インデックス削除には別途noindexメタタグやSearch Consoleの削除ツールを使う必要があります。第二に、robots.txtでブロックしたURLでも、外部リンクが多数存在する場合はGoogleがURLそのものを検索結果に表示することがあります（タイトルとスニペットが空の状態で表示）。第三に、robots.txtは「お願い」レベルの指示であり、悪意のあるクローラやスクレイパーは無視する可能性があります。機密情報の保護目的にrobots.txtを使うのは適切ではありません。
robots.txtと混同されやすい仕組みに、meta robotsタグ（noindex/nofollow）とsitemap.xmlがあります。robots.txtが「クロール（アクセス）を制御する」のに対し、meta robotsの`noindex`は「クロールはされるが、検索結果へのインデックス登録を拒否する」指示です。つまりrobots.txtで「クロールするな」と指示したURLにはGoogleがアクセスできないため、ページ内のnoindex指示も読み取れず、結果として検索結果に表示され続けるという矛盾が起こり得ます。インデックスから外したいURLには、robots.txtでブロックせず、noindexメタタグまたはX-Robots-Tag HTTPヘッダーを使うのが正解です。sitemap.xmlは「検索エンジンにクロール対象のURLを伝える」ためのファイルで、robots.txtとは正反対の役割を持ちます。両者は併用するのが標準で、robots.txt内の`Sitemap`ディレクティブでsitemap.xmlの場所を通知します。
robots.txtの構文はシンプルで、いくつかの基本的なディレクティブ（指示）を組み合わせて記述します。最低限押さえるべきディレクティブを順番に解説します。
User-agentディレクティブは、続くルールがどのクローラに適用されるかを指定します。すべてのクローラを対象にする場合は`User-agent: *`と書き、特定のクローラだけを対象にする場合は`User-agent: Googlebot`のようにクローラ名を指定します。主要な検索エンジンクローラには、Google検索の`Googlebot`（画像用に`Googlebot-Image`、動画用に`Googlebot-Video`なども存在）、Bingの`bingbot`、Yandexの`YandexBot`などがあります。1つのrobots.txt内で複数のUser-agentブロックを記述でき、各ブロックは空行で区切ります。クローラは自分に最も具体的に一致するルールに従うため、`User-agent: *`と`User-agent: Googlebot`の両方がある場合、GooglebotはGooglebot向けの指示にだけ従います。
Disallowは、続くパスへのクロールを禁止する指示です。`Disallow: /admin/`と書けば`/admin/`配下のすべてのURLへのクロールが抑制されます。`Disallow: /`はサイト全体のクロール禁止、`Disallow:`（値なし）はサイト全体のクロールを許可することを意味します。Allowは、Disallowでブロックされた範囲の中から特定の例外を許可するために使います。たとえば`Disallow: /private/`で`/private/`をブロックしつつ、`Allow: /private/public.html`と書けば、その特定ファイルだけはクロール可能になります。パスの記述では、ワイルドカード`*`（任意の文字列にマッチ）と末尾アンカー`$`（URLの末尾を指定）が使用可能です。たとえば`Disallow: /*.pdf$`はすべてのPDFファイルへのクロールを禁止する記述です。
Sitemapディレクティブは、サイトのsitemap.xmlの絶対URLをクローラに伝えるために使います。User-agentブロックには属さず、ファイル内のどこに書いても有効です。記述例は`Sitemap: https://example.com/sitemap.xml`のようになります。複数のsitemap.xmlがある場合は、Sitemap行を複数記述できます。Sitemapディレクティブを書いていなくても、Search Consoleでsitemap.xmlを直接送信していれば検索エンジンに伝わりますが、両方記述しておくのが推奨です。
Crawl-delayは、クローラのリクエスト間隔を秒単位で指定するディレクティブですが、Googleは2019年以降このディレクティブを公式にサポートしておらず、無視されます。BingやYandexは引き続き解釈しますが、Googleの動作を変えたい場合はSearch Consoleの「クロール頻度の設定」を使うのが正解です。Crawl-delayをrobots.txtに書いても害はありませんが、Googleには効かないことを理解した上で記述しましょう。サーバ負荷が高い場合は、サーバ側のレート制限やキャッシュ最適化で対応する方が現実的です。
robots.txtは「どこに」「どんな形式で」設置するかが厳密に決まっています。配置を間違えると、せっかく書いた指示がまったく機能しません。
robots.txtは、各ホスト（ドメイン+サブドメイン）のルートディレクトリ直下に配置する必要があります。たとえば`https://example.com/`というサイトのrobots.txtは`https://example.com/robots.txt`でアクセスできなければなりません。サブディレクトリに置いた`/blog/robots.txt`のようなファイルは、検索エンジンに認識されません。サブドメイン（`blog.example.com`など）はそれぞれが独立したホスト扱いになるため、サブドメインごとに別のrobots.txtが必要です。プロトコル（http/https）とポート番号も区別されるため、HTTPS対応サイトでは必ずHTTPS版のrobots.txtも適切に配信される必要があります。
robots.txtはプレーンテキストファイルで、UTF-8エンコーディングが推奨です。BOM（Byte Order Mark）が付いていると一部のクローラが正しく解析できないため、BOMなしのUTF-8で保存します。Googleはrobots.txtを最大500KiB（約512,000バイト）までしか読み込まないため、これを超える内容は無視されます。実務では数KB〜数十KBに収まることがほとんどなので、上限を意識する必要は通常ありません。改行コードはCRLF（Windows形式）でもLF（Unix形式）でも動作しますが、Webサーバの慣習に合わせてLFを推奨します。コメントは`#`から行末までで、ルールの説明や運用メモを残すために活用できます。
WordPressでは、テーマやプラグインによって動的にrobots.txtが生成されることが多く、Yoast SEOやAll in One SEOなどのSEOプラグインから直接編集できます。物理ファイルを置く場合は、WordPressルート（`wp-config.php`と同階層）にrobots.txtを配置します。Next.jsでは、`public/robots.txt`に静的ファイルを置く方法と、`app/robots.ts`または`app/robots.js`で動的に生成する方法があります。動的生成では、環境変数で本番／ステージングのrobots.txtを切り替える運用がベストプラクティスです。Payloadのようなヘッドレスマイヘッドレス構成では、フロントエンド（Next.jsなど）側のpublicフォルダにrobots.txtを配置します。クラウド配信（CloudFront、Vercel、Netlifyなど）では、配信エッジでrobots.txtが正しく返されるかを必ず確認してください。
実務でよく使う典型的なrobots.txtの記述例を、用途別に整理します。コピー＆ペーストのベースとして活用してください。
もっとも単純な例は、サイト全体をすべてのクローラに公開する設定です。記述は`User-agent: *`と`Disallow:`（値なし）の組み合わせで、サイトマップを併せて通知します。実際の記述イメージは、User-agent行ですべてのクローラを対象に指定し、Disallow行を空値にしてブロック対象なしを示し、最後にSitemap行で`https://example.com/sitemap.xml`を通知する3行構成です。新規サイトの初期設定としてもっとも基本的な書き方です。
WordPress管理画面（`/wp-admin/`）や、社内向けの管理ディレクトリ（`/admin/`、`/staging/`など）をクロールから除外したい場合は、Disallowディレクティブで該当ディレクトリを指定します。`User-agent: *`の下に`Disallow: /wp-admin/`、`Disallow: /admin/`、`Disallow: /staging/`を並べて書きます。WordPressの場合、`/wp-admin/admin-ajax.php`はサイトの動作に必要なため、`Allow: /wp-admin/admin-ajax.php`という例外指定を併せて記述するのが標準です。
サイト内検索結果ページ（`/search?q=...`）やフィルタリング・ソート用パラメータ付きURLは、検索エンジンにとって価値の低い重複コンテンツになりやすいため、クロール対象から除外することが推奨されます。記述例としては、`Disallow: /search`や`Disallow: /*?sort=`、`Disallow: /*?filter=`のようにワイルドカードを使ってパラメータを含むURLをまとめてブロックします。クロールバジェットの最適化につながり、重要ページのクロール頻度が向上します。
特定のファイルタイプへのクロールを制御したい場合は、ワイルドカードと末尾アンカーを使います。たとえばすべてのPDFファイルをブロックするなら`Disallow: /*.pdf$`、特定の画像ディレクトリをブロックするなら`Disallow: /private-images/`と記述します。ただし、画像SEOやFAQリッチリザルトを狙っている場合は、画像をブロックすると検索結果上での視覚的露出が減ることに注意が必要です。安易にブロックせず、画像が検索流入に貢献しているかをSearch Consoleで確認してから判断しましょう。
2026年現在、ChatGPTやClaudeなど生成AIサービスのクローラ（学習用クロール）に対して、自社コンテンツを学習データとして使われたくない場合の対応が一般化しています。OpenAIの`GPTBot`、Anthropicの`ClaudeBot`、Googleの`Google-Extended`、Common Crawlの`CCBot`などを個別にブロックするには、それぞれにUser-agentブロックを作成してDisallowを記述します。たとえば`User-agent: GPTBot`+`Disallow: /`でGPTBotをサイト全体からブロックしつつ、`User-agent: Googlebot`+`Disallow:`（値なし）でGoogle検索のクロールは許可する、といった選択的な設定が可能です。後述の通り、AI bot対応は2026年のテクニカルSEOで重要なテーマになっています。
robots.txtは正しく設定すればSEOにプラスに働き、誤ると検索評価を一気に失う両刃の剣です。SEOへの影響を3つの観点から整理します。
Googleは各サイトに「クロールバジェット」と呼ばれるクロール可能なURL数の上限を割り当てており、大規模サイトでは特にこれが検索評価に影響します。価値の低いURL（検索結果ページ、パラメータ付きURL、管理画面など）をrobots.txtでブロックすることで、重要なページにクロールリソースを集中でき、新規ページや更新ページのインデックス速度向上につながります。数十万ページ規模のECサイトやメディアサイトでは、robots.txt最適化だけでオーガニック流入が10～20%改善するケースも報告されています。サイト規模が大きいほど、適切なrobots.txt設計のSEOインパクトは大きくなります。
robots.txtでもっとも怖いのは、誤って重要ページや全サイトをブロックしてしまう設定ミスです。特に多いのが、`Disallow: /`（サイト全体ブロック）をテスト環境用として書いたまま本番にデプロイし、サイト全体が検索結果から消えるという事故です。また、CSSやJavaScriptファイルをブロックすると、Googleがページを正しくレンダリングできず、モバイルフレンドリーやCore Web Vitalsの評価に悪影響が出ます。Googleは2014年以降、CSS/JSのクロール許可を強く推奨しており、これらをブロックする理由は通常ありません。robots.txtの変更は本番環境に反映する前に必ずSearch Consoleの「robots.txtテスター」で検証し、想定外のURLがブロックされていないかを確認することが鉄則です。
繰り返しになりますが、robots.txtは「インデックスから外す」目的には使えません。すでにインデックスされているURLをrobots.txtでブロックしても、Googleはそのページにアクセスできなくなるだけで、URL自体はインデックスから消えず、外部リンクが多ければタイトルなしの状態で検索結果に表示され続けます。「特定ページを検索結果から削除したい」場合は、robots.txtでブロックせず、ページ内に`<meta name="robots" content="noindex">`を記述するか、HTTPヘッダーで`X-Robots-Tag: noindex`を返す対応が正しい方法です。Googleが対象ページをクロールしてnoindex指示を読み取ることで、初めて検索結果から除外されます。
2023年以降、生成AIサービスがWeb上のコンテンツを学習データとして大量にクロールするようになり、robots.txtの役割は「検索エンジンへの指示」から「AI学習可否の表明」へと拡大しました。2026年現在、テクニカルSEOにおいて欠かせない論点になっています。
代表的なAIクローラには、OpenAIが運用する`GPTBot`（ChatGPTの学習用クロール）、Anthropicが運用する`ClaudeBot`、Googleが「Google検索のクロールとは別系統で」AI学習用に運用する`Google-Extended`があります。これらは検索エンジンのクロールとは目的が異なり、ブロックしても検索順位には直接影響しないとされています。たとえば`Google-Extended`をブロックしてもGoogle検索のオーガニック順位には影響せず、Googleの生成AI（Geminiなど）が学習データとして使うのを抑制する効果だけが得られます。他にも`PerplexityBot`、`CCBot`（Common Crawl）、`Bytespider`（ByteDance）、`Amazonbot`、`Applebot-Extended`など、複数のAI関連クローラが存在します。自社の方針に応じて、許可／不許可を個別に設定する運用が一般化しています。
AIクローラに対する方針は、企業のコンテンツ戦略によって異なります。コンテンツが事業の競争優位そのものであるメディア企業や報道機関では、無断学習を防ぐためにAI bot全体をブロックする傾向があります。一方、ブランド認知や指名検索の獲得を重視する企業では、生成AIに引用されることを「ゼロクリックブランディング」のチャンスと捉え、AIクローラを許可する判断もあります。AI Overviewsや対話型AI検索からの引用は、クリックされなくてもブランド接触として認知資産を積み上げます。重要なのは、自社の事業目標に照らして方針を決めること、そしてrobots.txtで「AIクローラを許可している／していない」を明確にしておくことです。曖昧なまま運用すると、後から方針変更したときに既に学習されたデータを取り消すことは困難です。
2024年以降、AI向けに最適化された別のテキストファイル「llms.txt」を提案する動きも広がっています。llms.txtはサイトのコンテンツ構造をLLMに分かりやすい形でまとめたファイルで、`/llms.txt`にMarkdown形式で配置します。llms.txtはrobots.txtの代替ではなく補完的な仕組みです。robots.txtで「アクセス可否」を制御し、llms.txtで「サイト概要や主要コンテンツの場所」をAIに伝える、という役割分担です。2026年現在は標準化途上で、すべてのAIサービスが対応しているわけではありませんが、AI検索への可視性を意識する企業では先行的に導入する動きが増えています。
robots.txtを設置した後は、必ず動作確認を行います。誤った記述で重要ページをブロックしてしまっていないか、複数の方法で検証しましょう。
もっとも確実な確認方法は、Google Search Console（GSC）の「設定」→「robots.txt」レポートです。Googleが現在認識しているrobots.txtの内容、最終クロール日時、エラーや警告の有無が表示されます。また、GSCの「URL検査」ツールで個別URLを入力すると、そのURLがrobots.txtでブロックされているかどうかを確認できます。本番環境にデプロイする前後で必ずチェックする習慣をつけることで、致命的な事故を防げます。
もっとも単純な確認は、ブラウザで`https://example.com/robots.txt`にアクセスし、想定通りの内容が表示されるかを目視チェックすることです。HTTPステータスコードが200で返されているか、文字化けしていないか、改行が正しく表示されているかを確認します。404が返ってくる場合はファイルが正しく配置されていないか、配信設定に問題がある可能性があります。robots.txtが存在しない場合、検索エンジンは「すべてクロールしてよい」と解釈するため、特に問題がなければ放置しても致命的ではありませんが、Sitemap通知などの利点を活かせなくなります。
Screaming Frog SEO SpiderやAhrefs、Semrush、SitebulbなどのSEO監査ツールには、robots.txtを解釈してクロール挙動をシミュレートする機能があります。本番デプロイ前にローカルでクロールを実行し、想定外のURLがブロックされていないか・想定通りのURLだけがブロックされているかを総合的に検証できます。大規模サイトのrobots.txt変更では、Search Consoleでの個別URL確認に加えて、こうしたツールでの全体シミュレーションを併用するのが2026年のベストプラクティスです。
robots.txtに関連する代表的なミスと、その対策を整理します。多くは事前のレビューと検証で防げるものです。
もっとも多く深刻な事故が、ステージング環境用の`User-agent: *` + `Disallow: /`をそのまま本番デプロイしてしまうケースです。サイト全体が数日でインデックスから消失し、オーガニック流入がゼロに近くなる被害が発生します。対策は、環境変数によるrobots.txtの動的切り替え（本番ではフルアクセス許可、ステージングでは全ブロック）、デプロイパイプラインでの自動チェック（`Disallow: /`が本番に紛れ込んでいないか）、デプロイ後の必須確認項目としてrobots.txt検証をチェックリストに含めることです。
古いSEOガイドラインの影響で、`Disallow: /css/`や`Disallow: /js/`と書いているサイトが今も散見されますが、これは現在のSEOでは逆効果です。GoogleはCSS/JSをクロールできないとページを正しくレンダリングできず、モバイルフレンドリー判定やCore Web Vitalsの評価に悪影響が出ます。対策はシンプルで、CSS/JSのDisallowを削除することです。最新のGoogle公式ガイドラインでも「CSS、JS、画像ファイルへのアクセスを許可してください」と明記されています。
Googleが2019年9月に正式にサポートを終了した`Noindex:`ディレクティブをrobots.txt内に書いているケースがあります。これは現在のGoogleでは無効で、書いてもインデックス除外の効果はありません。対策は、noindexしたいページにはmeta robotsタグまたはX-Robots-Tag HTTPヘッダーを使うことです。robots.txtはあくまで「クロールの可否」を制御する仕組みであり、インデックスの可否とは別物だという基本に立ち返って整理しましょう。
robots.txtのパスは「前方一致」でマッチするため、`Disallow: /admin`と書くと`/admin`、`/admin/`、`/admin/users`、`/admin-panel`もすべてブロックされます。`/admin/`配下だけをブロックしたい場合は、末尾にスラッシュをつけて`Disallow: /admin/`と書くのが正しい記述です。また、大文字と小文字は区別されます。`Disallow: /Admin/`は`/admin/`にはマッチしません。サイトのURL構造に合わせて正確に記述しましょう。複雑なパターンを使う場合は、Search ConsoleのrobotsテスターやサードパーティのrobotsバリデータでURLマッチを事前確認するのが安全です。
Sitemapディレクティブは、絶対URLで記述する必要があります。`Sitemap: /sitemap.xml`のような相対パスではクローラが解釈できません。`Sitemap: https://example.com/sitemap.xml`のように、プロトコルとドメインを含めた完全なURLで記述しましょう。また、HTTPS化したサイトでhttp://から始まる古いURLを残したままにしているケースもあります。HTTPS版のURLに揃えることで、クローラの混乱を防げます。
robots.txtは、検索エンジンクローラに対して「サイト内のどのURLにアクセスしてよいか／してほしくないか」を伝えるためのテキストファイルで、テクニカルSEOの基本中の基本です。User-agent・Disallow・Allow・Sitemapという少数のディレクティブの組み合わせで、サイト全体のクロール挙動を制御できます。
ファイルは必ずドメインルート直下（`https://example.com/robots.txt`）にUTF-8のプレーンテキストとして配置し、HTTPS版・各サブドメインそれぞれに用意します。WordPressやNext.jsなどCMSごとに設置方法が異なるため、自社の構成に合った方法で運用しましょう。
SEOへの影響は両刃の剣で、適切な設定はクロールバジェットを最適化して重要ページのインデックスを促進する一方、`Disallow: /`の本番混入やCSS/JSのブロックといった誤設定は検索評価を一気に失う深刻な事故につながります。Search Consoleのrobots.txtレポートとURL検査、サードパーティツールを組み合わせて、変更時の検証を徹底することが鍵です。
2026年は、生成AIサービスのクローラ（GPTBot・ClaudeBot・Google-Extendedなど）への対応がrobots.txt運用の新しいテーマになっています。AI学習を許可するか／ブロックするかは、コンテンツ戦略や事業目標に応じて慎重に判断し、明示的にrobots.txtで表明する運用が標準化しつつあります。さらにllms.txtのようなAI向け補完ファイルも登場しており、テクニカルSEOの守備範囲は確実に広がっています。
robots.txtの設定は、コンテンツSEOやSEO効果測定と並ぶテクニカル基盤の柱です。NeX-Rayのような統合ダッシュボードで、Search Consoleのクロール統計やオーガニック流入の変動を継続的にモニタリングしておくと、robots.txt変更による影響を素早く検知できます。基本構文と運用ルール、AI時代の新しい論点までを押さえて、自社サイトの健全な検索可視性を支える土台を整えていきましょう。
「オウンドメディア 費用対効果」で検索する経営層・マーケティング責任者・オウンドメディア担当者向けに、費用対効果の基本定義（ROIとROASの違い、なぜ測定が難しいのか）、運営コストの全体像（初期費用・運用費・ツール費・人件費）、得られる成...
「コンテンツマーケティング seo」で検索する経営者・マーケティング責任者向けに、両者の違い（目的・範囲・時間軸・主要KPI）から、重なる領域（コンテンツSEO）と独立する領域、2026年に両方を組み合わせる必要性（AI Overviews...
SEOの効果とは何かという基本定義から、Google公式見解に基づく成果が出るまでの期間（4ヶ月〜1年）、ドメイン状態別の目安（新規サイト半年〜1年・既存サイト3〜6ヶ月・YMYL領域1年以上）、フェーズ別の進捗イメージ、SEO効果測定の具...
