SEOのためのrobots.txtの使い方

このガイドで扱う内容

この記事ではrobots.txtが何を制御し、何を制御しないかを説明し、正しい構文と実用的な例を示し、実行できるコマンドラインチェックを紹介し、一般的なミスからの復旧手順を列挙します。さらに、2026年の検索環境で有効な検証のコツも紹介します（mobile-first indexing は Google のデフォルトであり、Google は July 2024 以降それを採用し、early 2024 に従来のキャッシュページを削除しました）。

robots.txtとは何か、何を制御するか

robots.txt はサイトのルートに置かれるプレーンテキストのファイルで、良識あるウェブロボットにクロール指示を伝えます。これは Robots Exclusion Standard の一部です。ファイルを使ってクローラーに取得してよいパスを指示します。これはクロールを制御するものであり、インデックス化やランキングを直接制御するものではありません。

押さえておくべき重要な区別:

クロール（crawling）とインデックス化（indexing）とランキング（ranking） — robots.txtはクロール（エージェントが取得するかどうか）に影響します。クロールがブロックされたURLでも、他のページからのリンクなど外部要因で検索エンジンが取得せずにそのURLをインデックス化することはあり得ます。

robots.txtはあくまで指示であり、準拠するクローラーのみが従います。悪意あるボット、スパム収集ツール、一部のスキャナーは無視する可能性があります。

robots.txtはアクセス制御の代替にはなりません。プライベートなコンテンツにはHTTP認証、パスワード保護、サーバー側の制御を使用してください。

robots.txtを置くべき場所と基本ルール

robots.txtは、ルールを適用したい正確なホストとプロトコルのサイトルートから配信される必要があります。区別される例:https://example.com/robots.txt と https://sub.example.com/robots.txt。サブフォルダにrobots.txtを置いてドメイン全体を制御できると期待してはいけません。

このガイド内の便宜上と例では、標準的なテストパスは http://www.yoursite.com/robots.txt.

robots.txtの構文と一般的なディレクティブ

最小限のrobots.txtはUser-agentごとにグループ化されたディレクティブを使います。ディレクティブ名は大文字小文字を区別しません。以下の例は主要なクローラーの多くがサポートする標準トークンを使用しています:

ディレクトリを全クローラーからブロックする例:

User-agent: *

Disallow: /private/

ディレクトリを禁止しつつ特定のファイルだけ許可する（Googlebotのようなパーシングに有用）:

User-agent: *

Disallow: /images/

Allow: /images/logo.png

Sitemapsはrobots.txtに宣言してクローラーにあなたのXML sitemap:

Sitemap: http://www.yoursite.com/sitemap.xml

パターンマッチング: 主要な検索エンジンはrobots.txtのパターンでアスタリスク(*)ワイルドカードと行末のドル記号($)をサポートします。非標準のCrawl-delayディレクティブは一部のエンジンで無視されます（GoogleはCrawl-delayをサポートしていません）。

実用的な例

1) すべてのクローラーに全てを取得させる（デフォルトの安全な選択）:

User-agent: *

Disallow:

2) 単一のクローラー（例: 特定のエージェントを全コンテンツから除外する）:

User-agent: BadBot

Disallow: /

3) レンダリングに必要なリソースの取得をクローラーから禁止する（よくある誤り — トラブルシューティング参照）:

Disallow: /static/js/

CSS/JSをブロックすると、Googleがユーザーと同じようにページを把握できなくなる可能性があります。Googleはモバイル版を主要な基準としてcrawling and indexing、および評価時にCore Web Vitalsをレンダリング済みページから評価するため、レンダリングに必要なリソースをブロックしないでください。

robots.txtの検証とトラブルシューティング方法

サイト外から実行できる基本チェック:

ファイル本体を取得: curl http://www.yoursite.com/robots.txt — これはクローラーが見るファイルの内容を返します。

ヘッダーのみ確認: curl -I http://www.yoursite.com/robots.txt — HTTPステータス（200 vs 4xx/5xx）と Content-Type を確認します。-I はレスポンスヘッダーのみを返します。

ブラウザでの受け取り方を確認: https://www.yoursite.com/robots.txt をブラウザで開き、curlと同じ内容か確認してください。

/robots.txtへの実際のクローラーリクエストや、ブロックされたページを取得しようとするGooglebotなどのエージェントをサーバーログで調べてください — ログはクローラー挙動を示す最も信頼できる第三者シグナルです。

サイトを所有している場合に実行すべきチェック:

個別ページについてはGoogle Search ConsoleのURL Inspectionを使い、GoogleがそのURLを取得またはインデックス化したかを確認してください。URL Inspectionは所有するプロパティに対して権威ある情報を提供します。

robots.txtを変更した後はサーバーログとSearch ConsoleのPerformanceレポートを監視し、重要ページのクロール挙動を確認してください。

よくある問題の兆候と対処法

誤ってCSS/JSをブロックした — 症状: クローラーがページを異なる見え方でレンダリングする; 対処法: Disallowから該当リソースのパスを外し、クローラーが取得できるようにする。

robots.txtが404/5xxを返す — 症状: 一部のクローラーがサイトを完全にクロール可能とみなすか、クロールを一時停止する可能性がある; 対処法: 200を返し正しいContent-Typeの有効なrobots.txtを復元する。

間違ったサブドメインにrobots.txtを置いてホストやプロトコル全体をブロックしてしまった — 症状: クロールログからページが消える; 対処法: 正しいホストにrobots.txtを追加し（リダイレクトも確認）する。

ページがクロールからブロックされているのにスニペットなしで検索結果に出る場合、そのURLはコンテンツ取得なしに外部のシグナルでインデックス化されたことを示します。こうしたURLを検索結果から削除するには、適切なHTTP認証を使う、ページを削除する、またはページ自体でnoindexディレクティブを返す（noindexはクローラーがページを取得する必要があるため、noindexを使う場合はrobots.txtでブロックしないでください）。

チェックリスト: robots.txt を安全に展開・確認する

対象の正確なホストとプロトコルのサイトルートにrobots.txtを配置する。

curl（本文とヘッダー）とブラウザでファイルをテストする。

CSS、JavaScript、またはレンダリングに使われるその他のアセットを、クローラーにレンダリングさせたくない明確な意図がない限りブロックしないでください。

robots.txtでsitemapsを宣言してクローラーがインデックス可能なURLを発見しやすくする。

変更後はサーバーログとSearch Consoleでクロール挙動を監視する。

手順を追うリファレンスが必要なら、テクニカル SEO ガイドを読む（クロール可能性と Core Web Vitals の広い文脈について）。

2026年の追加考慮点

Googleがモバイル版をクロールとインデックス化の主要な基準として使用し、従来のキャッシュページがearly 2024に削除されたため、robots.txtで意図的にクローラーから隠したコンテンツは最新のAI駆動の概要やSearch Generative Experience機能で表出しにくくなる可能性があります。AI概要やリッチなSERP機能で使われることを望む場合は、クローラーがページを取得してインデックスできるようにし、適切に構造化データを使ってください。

FAQ