URL が robots.txt によってブロックされています：放置か修正か

「URL が robots.txt によってブロックされています」（英語版では "URL blocked by robots.txt"）は、robots.txt ファイルのルールでクロールが禁止されているため Google がその URL をクロールせず、URL がインデックスに登録されていないことを意味します。ほとんどのサイトでは、このステータスは正しい状態です。管理画面、カート、サイト内検索、パラメータ付きの URL は、意図的にブロックされています。損失が生じるのは、検索に表示させたいページをルールが巻き込んでいる場合だけです。やるべきことは、意図的なブロックの中からそうしたページを見つけ出すことです。

2022 年まで、Search Console のインデックス カバレッジ レポートでは、このステータスに 2 つのラベルが使われていました。送信したサイトマップに掲載されている URL には「送信された URL が robots.txt によってブロックされました」、それ以外には「robots.txt によりブロックされました」です。ドイツ語版の Google のヘルプでは、現在このステータスは "URL wird von der robots.txt-Datei blockiert" と記載されており、以前のラベルは "Durch robots.txt-Datei blockiert" でした。レポートに "Indexiert, obwohl durch robots.txt-Datei blockiert"（「robots.txt によりブロックされましたが、インデックスに登録しました」）と表示されている場合、その URL はブロックされているにもかかわらずインデックスに登録されています。このステータスには専用のガイドがあります。

Google によるこのステータスの説明

Google のページ インデックス登録レポートのドキュメント（2026 年 10 月に確認）は、「URL が robots.txt によってブロックされています」を「未登録」の下に挙げ、ページがサイトの robots.txt ファイルによってブロックされたと説明しています。同じドキュメントは「未登録」グループ全体について、これらのページはインデックスに登録されていないものの、「必ずしもエラーが原因ではない」と前置きしています。

ブロックには、判断に関わる 2 つの影響があります。

• ブロックが止めるのはクロールであり、インデックス登録ではない。 Google のドキュメントによると、ブロックしてもページがインデックスに登録されないことは保証されません。他のページからのリンクなど、ページを読み込まずにそのページについての情報を Google が見つけた場合、わずかながらインデックスに登録される可能性があり、その場合は「robots.txt によりブロックされましたが、インデックスに登録しました」に移ります。
• Google はページを一切見ない。 タイトルも、コンテンツも、ページ内のリンクも、canonical も、noindex も見えません。ルールがある限り、ページが自分自身について伝えていることはすべて Google に届きません。

問題なのか：意図的なブロックと偶発的なブロックを仕分ける

まずは、ページ インデックス登録レポートの上部にあるフィルタから始めます。「すべての既知のページ」から「送信されたすべてのページ」に切り替えてください。「送信されたすべてのページ」に表示されるブロック済みの URL は、送信したサイトマップに掲載されているものです。つまり、robots.txt でクロールを禁止しながら、インデックス登録を Google に求めていることになります。ルールの意図が何であれ、この矛盾はほぼ例外なく誤りです。

2026 年 5 月から 10 月に SEOReport の監査に送信され、サイトマップのページを取得できた外部ウェブサイト 29 件のうち、2 件（7%）が、自サイトの robots.txt で禁止している URL をサイトマップに掲載していました。サイトマップの問題として最も多いものではありませんが、サイトがすでに重要だと宣言したページをブロックしてしまう問題です。

偶発的なパターンと修正前後の例

以下のパターンはいずれも、書かれたとおりに機能した結果、意図より多くをブロックしてしまったルールです。

1. ステージング用のファイルがそのまま公開された。 開発用サイトは全体がブロックされており、そのファイルがビルドの他の部分と一緒に本番環境に移ってしまったケースです。

# Before: copied from staging
User-agent: *
Disallow: /

# After: block only what should never be crawled
User-agent: *
Disallow: /cart/
Disallow: /account/

Sitemap: https://www.example.com/sitemap.xml

2. 接頭辞が短すぎる。 Google はルールを URL パスの先頭から照合するため、Disallow: /search は /search?q=shoes だけでなく、実在する記事の /search-engine-basics/ もブロックします。

# Before
Disallow: /search

# After: block only the search results
Disallow: /search/
Disallow: /search?

3. ワイルドカードがランディング ページを巻き込んでいる。 * は任意の文字列に一致し、Google の照合にはクエリ文字列も含まれます。Disallow: /*? はパラメータ付きのすべての URL をブロックするため、/shoes/?page=2 のように、掲載商品を見つけてもらうためにクロールさせたいページ分割されたカテゴリページもブロックされます。

# Before
Disallow: /*?

# After: keep pagination crawlable, block the rest
Disallow: /*?
Allow: /*?page=

ファイルの拡張子にも同じ落とし穴があります。ページの URL が .php で終わるサイトでは、Disallow: /*.php でカタログ全体がブロックされます。

4. 忘れられた Googlebot のグループ。 Google の robots.txt の仕様によると、クローラーは自分の名前を指定した最も具体的なグループだけに従い、具体的なグループと * のグループは結合されません。何年も前の移行のときに書いた User-agent: Googlebot のグループが Googlebot に適用され続け、チームは * のグループだけを編集しているため、ブロックの理由を説明できない、という事態が起こります。

# Before: Googlebot reads only its own group
User-agent: Googlebot
Disallow: /blog/

User-agent: *
Disallow: /cart/

修正するには、古いグループを削除するか、現在のルールをそのグループにコピーします。同じルールは、AI クローラー向けのポリシーでよくある副作用の説明にもなります。特定のボットのために名前を指定したグループを追加したサイトは、共通のルールをそれぞれのグループに繰り返し記述する必要があります。検索と AI のルールを分けておくパターンは、robots.txt と AI クローラーの判断表で紹介しています。

5. レンダリングに必要なリソースをブロックしている。 Disallow: /assets/ や Disallow: /static/ は、ページが読み込む CSS や JavaScript をブロックします。Google の robots.txt の概要によると、重要でないリソースはブロックしても構いませんが、それがないとページを Google が理解しにくくなるリソースはブロックすべきではありません。こうしたファイルがページとしてページ インデックス登録レポートに表示されることはまれなので、ページの側から探します。URL 検査ツールで公開 URL のテストを実行し、「テスト済みのページを表示」から「その他の情報」を開くと、Google が読み込んだページリソースを確認できます。アセット用のホストも確認してください。robots.txt はホスト、プロトコル、ポートごとに適用されるため、cdn.example.com から配信されるファイルはそのホスト自身の robots.txt に従います。ページのコンテンツを組み立てるスクリプトがブロックされると、ブラウザでレンダリングするサイトでは特に影響が大きくなります。これについてはJavaScript レンダリングのガイドで扱っています。

robots.txt のルールを URL に当てはめてテストする方法

Google の判断を予測するのにツールは必要ありません。Google の仕様に従えば 4 つの手順で済みます。

flowchart TD
    A["テストする URL"] --> B["同じホストとプロトコルの robots.txt を開く"]
    B --> C{"Googlebot 用のグループはあるか"}
    C -->|はい| D["そのグループだけを使う"]
    C -->|いいえ| E["* のグループを使う"]
    D --> F["パスに一致する Allow と Disallow をすべて書き出す"]
    E --> F
    F --> G{"一致するものはあるか"}
    G -->|いいえ| H["許可"]
    G -->|はい| I["パスが最も長いルールが優先"]
    I --> J{"Allow と Disallow が同じ長さか"}
    J -->|はい| H
    J -->|いいえ| K["最も長いルールを適用する"]

1. ファイルを選ぶ。 URL と完全に同じホストとプロトコルの /robots.txt を開きます。https://www.example.com/robots.txt は https://shop.example.com/ には適用されません。
2. グループを選ぶ。 Googlebot に一致する、最も具体的な User-agent グループを使います。ユーザー エージェント名は大文字と小文字を区別しません。
3. 一致するルールを探す。 ルールのパスが URL のパスとクエリの先頭に一致すれば、そのルールは一致します。* は任意の文字に一致し、$ は URL の末尾を示します。パスは大文字と小文字を区別するため、/Shop/ は /shop/ に一致しません。
4. 優先されるルールを決める。 パスが最も長いルールが優先されます。Allow と Disallow が同じ長さの場合、Google は制限の緩いほう、つまり Allow を使います。

パターン 3 の修正後のファイルに Disallow: /search を加えたものに、この方法を当てはめると次のようになります。

自分の解釈ではなく Google 自身の解釈を確認するには、その URL で URL 検査ツールを実行します。クロールの詳細にある「クロールを許可?」に robots.txt のルールが Google をブロックしているかどうかが表示され、公開 URL のテストでは、Google がその時点で取得できるファイルが適用されます。Google は robots.txt のパーサーをオープンソースのライブラリとしても公開しており、開発者は公開前の下書きのファイルに対して実行できます。

ルールを修正し、検証する

クロールさせたいページがルールに一致しなくなるよう、ファイルを変更します。広すぎる Disallow を狭めるか、例外に対してより長い Allow を追加するか、残っている古いグループを削除します。そのうえで次の手順を踏みます。

1. 本番のファイルを取得し、キャッシュやビルド時のコピーではなく、編集したものをサーバーが配信していることを確認します：curl -s https://www.example.com/robots.txt。
2. robots.txt の再クロールをリクエストする。 Search Console の robots.txt レポートから行います。Google は通常、このファイルを最大 24 時間キャッシュします。レポートのヘルプでも、重要な URL のブロックを解除したときは再クロールをリクエストする理由になるとされています。レポートには、Google がファイルを最後に取得した日時とエラーや警告が表示されます。エラーのある行は無視されます。
3. 影響を受けている URL のうち 2〜3 件で、URL 検査ツールの公開 URL のテストを実行する。 「クロールを許可?」が「はい」になっているはずです。最も重要なページでは「インデックス登録をリクエスト」を使います。Google のヘルプによると、インデックス登録には 1〜2 週間かかることがあります。
4. ルールを修正したら、ページ インデックス登録レポートでこの問題の「修正を検証」をクリックする。 Google のドキュメントによると、検証には通常最長で約 2 週間かかり、さらに長くかかることもあります。

再クロールに関する Google のヘルプによると、クロールには数日から数週間かかることがあるため、件数は徐々に減っていくと考えてください。その後もレポートに残る URL は、意図してブロックしたものだけになるはずです。

何か月も隠れていたページのブロックを解除する前に、クローラーと同じ視点でそのページを確認してください。ステータスコード、robots メタタグ、canonical です。誰もクロールできなかったページには、忘れられた noindex が残っていることがあり、その場合ページは直ちに「URL に noindex が指定されています」に移ります。これらのシグナルがどう影響し合うかは、インデックス可否の矛盾に関する分析で解説しています。

Search Console では、どの URL がブロックされているかがわかります。SEOReport の完全な診断では、サイトマップに掲載されたページを robots.txt のルールと照らし合わせ、クロールしないよう伝えながら検索エンジンに見つけてもらおうとしているページを特定します。サイト全体の禁止や robots.txt がないことも指摘します。診断が読むのはすべてのクローラー向けに書かれたルールなので、Googlebot 専用のグループについては、引き続き URL 検査ツールで確認する必要があります。

よくある質問

ブロックされた URL が大量にあると、サイトに悪影響がありますか？

いいえ、それだけでは影響はありません。パラメータ付きの URL や検索の URL が数千件ブロックされているのは、robots.txt が役目を果たしている証拠です。数えるべきは、サイトマップに掲載されているブロック済みの URL と、上位表示させたいのにブロックされているページです。損失を生むのはそれらだけです。

robots.txt がない場合やエラーを返す場合はどうなりますか？

Google の仕様では、404 などの 4xx レスポンス（429 を除く）は robots.txt が存在しないものとして扱われ、何もブロックされません。5xx エラーは異なります。Google は最初の 12 時間はサイトのクロールを停止し、その後は最長 30 日間、手元にある最後の正常なコピーを使います。このファイルのタイムアウトや DNS エラーも同じように扱われるため、タイムアウトする robots.txt は、ブロックするルールが 1 つもないサイトのクロールまで止めてしまう可能性があります。

ブロックした URL はサイトマップから外すべきですか？

はい。サイトマップはインデックスに登録させたい URL の一覧なので、robots.txt でブロックしている URL を含めるべきではありません。意図的なブロックはサイトマップから外し、偶発的なブロックは解除してください。ファイルに含めるべきその他の内容は、XML サイトマップのガイドで解説しています。

robots.txt を使って Google からページを削除できますか？

いいえ。robots.txt が制御するのはクロールであり、他のページからリンクされていれば、Google はブロックされた URL もインデックスに登録できます。ページを検索から外すには、Google にクロールさせたうえで noindex を追加します。どのツールが何を担うかは、robots.txt とクロールアクセスのガイドで説明しています。

サブドメインや HTTP の robots.txt は、メインのサイトに影響しますか？

いいえ。ホスト、プロトコル、ポートの組み合わせごとに独自のファイルがあり、Google はサブディレクトリに置かれた robots.txt ファイルを読みません。staging.example.com のブロック用ファイルが www.example.com をブロックすることはありません。ただし、アセット用や CDN 用のホストの robots.txt は、ページが読み込むファイルを Google が取得できるかどうかを決めます。