robots.txt によるブロック（GSC ステータス）

TL;DR — Search Console の “Blocked by robots.txt,” (翻訳)「robots.txt によるブロック」は、Google がページを見つけたものの、あなたの robots.txt ファイルがクローラーに入らないよう指示しているため読まなかったことを意味します。通常は意図したもので問題ありません。ブロックの通常の結果であり、エラーではありません。問題になるのは、Google に表示したかったページをブロックした場合だけです。

このステータスの意味

Google Search Console の ページのインデックス登録 レポートを開き、“Blocked by robots.txt,” (翻訳)「robots.txt によるブロック」 (翻訳)「robots.txt によるブロック」をクリックすると、Google がインデックス登録しないと判断した URL の一覧が表示されます。理由は単純です。Google は URL を見つけましたが、サイトの robots.txt ファイルがクローラーに取得を許可していません。 Evidence for this claim Google reports Blocked by robots.txt when crawling is disallowed and warns that this does not guarantee the URL cannot be indexed by other means. Scope: Google Search Console report terminology and documented Search behavior; the label alone may not prove the underlying root cause. Confidence: high · Verified: 2026-07-14 Google: Page indexing report このラベルが示すのはクロールのブロックであり、ほかのシグナルによって URL が決してインデックス登録されないことを保証するものではありません。

私がまず伝えるのは、慌てないでくださいということです。このステータスは通常、意図したものです。あなた（または CMS、プラグイン）が内部検索結果、ファセットナビゲーションの URL、ステージングパス、カートやチェックアウトの URL などを意図的にブロックしたなら、ここに表示されるのはまさに想定どおりです。Google がブロックを確認したのであって、間違いを指摘しているのではありません。

覚えておくべき 1 つの考え方

robots.txt はクロールを制御しますが、インデックス登録は制御しません。 この 2 つは別のものです。 ページを robots.txt でブロックすると Google はページを 読み取れなくなりますが、Google から削除されるわけではありません。検索結果からページを削除する方法でもありません。私自身も「ページをブロックするとどうなるか」をテストしました（詳細は Advanced タブ）。要点は、ブロックはクロールを完全に止めるということです。 Evidence for this claim Google says robots.txt manages crawler access and is not a mechanism for keeping a page out of Google. Scope: Google Search Console report terminology and documented Search behavior; the label alone may not prove the underlying root cause. Confidence: high · Verified: 2026-07-14 Google: robots.txt introduction

問題なのか

1 つだけ確認します。これらの URL をブロックするつもりでしたか。

• はい、意図的です → そのままにします。意図どおりに機能しています。
• いいえ、そのページは Google に載せるべきです → 修正すべき唯一のケースです。URL を捕捉している robots.txt のルールを見つけ、削除または緩和してからインデックス登録をリクエストします。

関連しますが別のステータスとして、「Indexed, though blocked by robots.txt」 (翻訳)「ブロックされているがインデックス登録済み」も表示されることがあります。こちらは除外ではなく警告です。Google がブロックされた URL を（通常はほかのページからリンクされているため）それでもインデックス登録したことを意味します。同じ原因で結果が逆です。この状態は別の記事で扱っています。 Evidence for this claim Google reports Blocked by robots.txt when crawling is disallowed and warns that this does not guarantee the URL cannot be indexed by other means. Scope: Google Search Console report terminology and documented Search behavior; the label alone may not prove the underlying root cause. Confidence: high · Verified: 2026-07-14 Google: Page indexing report

robots.txt には、何かを非公開にする機能もありません。これはアクセス制御ではなくリクエストです。行儀のよいボットは従いますが、従うことを強制できません。また、リンク、スクリーンショット、robots.txt を完全に無視するスクレーパーなどを通じて URL が別の場所に現れることも止められません。機密コンテンツを含むページは、Disallow ではなくログインまたはパスワードで保護してください。

避けるべき間違い

多くの人は robots.txt でページをブロックして Google から 削除しようとし、念のため同時に noindex タグも追加します。しかし、それは機能せず、逆効果になります。Google がページをクロールできなければ noindex を見ることができず、ページが Google に残る可能性があるためです。ページを検索から実際に削除するには、逆のことをします。Google にクロールを許可し、noindex を追加します。

完全版（ブロックしている正確なルールの見つけ方、noindex + disallow の衝突、私自身の実験結果）を読みたい場合は、Advanced タブへ切り替えてください。

TL;DR — “Blocked by robots.txt” (翻訳)「robots.txt によるブロック」は、ページのインデックス登録における 除外です。Google は URL を発見しましたが、robots.txt がクロールを禁止したためクロールせず、この状態ではインデックス登録されません。通常は意図的で、問題のない状態です。robots.txt は クロールを制御するのであって、インデックス登録を制御するものではなく、Disallow はインデックスから削除するツールではありません。警告である 「Indexed, though blocked by robots.txt」 (翻訳)「ブロックされているがインデックス登録済み」と混同しないでください（通常、外部リンクなどを通じて Google がブロックされた URL も登録した状態です）。典型的な間違いは disallow と noindex を組み合わせることです。Google はページをクロールできないため noindex を見られず、ページが登録されたままになることがあります。削除するには、クロールを許可して noindex を返します。このステータスを不具合として扱うのは、インデックス登録したかった URL をブロックした場合だけです。

ステータスが実際に示していること

Search Console の ページのインデックス登録 レポートで「Blocked by robots.txt」と表示されるのは、除外状態であり、エラーでも警告でもありません。Google の表現は明確で、ページは “was blocked by your site’s robots.txt file,” (翻訳)「あなたのサイトの robots.txt ファイルによってブロックされた」とされています。さらに Google は、“does not guarantee that the page won’t be indexed through some other means.” (翻訳)「ほかの手段でページがインデックス登録されないことを保証するものではない」という重要な注意書きを加えています。 Evidence for this claim Google reports Blocked by robots.txt when crawling is disallowed and warns that this does not guarantee the URL cannot be indexed by other means. Scope: Google Search Console report terminology and documented Search behavior; the label alone may not prove the underlying root cause. Confidence: high · Verified: 2026-07-14 Google: Page indexing report この注意書きがテーマ全体を 1 行で表しています。詳しくは以下を見てください。

仕組みとしては、Googlebot は URL の存在を知っています（リンク、サイトマップ、または履歴から見つけました）。ルールに従おうとして一致する Disallow に当たり、停止します。取得しなければインデックス登録するコンテンツがないため、URL はこの除外区分に入ります。これは Disallow の 期待される 結果であり、ここにある URL の多くはここにあるべきものです。

クロールはインデックス登録ではない — Disallow で削除できない理由

Google は robots.txt を、信頼できる削除メカニズムではなくクロールアクセスの制御として文書化しています。 Evidence for this claim Google says robots.txt manages crawler access and is not a mechanism for keeping a page out of Google. Scope: Google Search Console report terminology and documented Search behavior; the label alone may not prove the underlying root cause. Confidence: high · Verified: 2026-07-14 Google: robots.txt introduction

これはこのステータスの正確性を支える中心部分です。robots.txt は クロールの制御です。Google は、“is not a mechanism for keeping a web page out of Google.” (翻訳)「ウェブページを Google から締め出すための仕組みではない」と明言しています。URL をブロックすると 取得は防げますが、URL がインデックスから削除されるわけではなく、インデックス削除のツールでもありません。

私の 兄弟ステータスについての Ahrefs 記事で書いたとおり、“crawling and indexing are two different things.” (翻訳)「クロールとインデックス登録は 2 つの異なるものです」。ブロックしたページでも、ほかのページからリンクされれば登録されることがあります。Google はコンテンツを見ることができず、そこに置いた noindex も見られません。これが、このレポートを見た人が犯す最も一般的な間違いにつながります。

“Blocked by robots.txt” と “Indexed, though blocked by robots.txt” の違い

この 2 つは常に混同されますが、原因は同じで結果が反対です。

警告版（ブロックされた URL がそれでも登録され、説明のない裸の URL として表示される）を見ているなら、それは「ブロックされているがインデックス登録済み」のケースで、別の解説で扱います。この記事が扱うのは通常の除外、つまりブロックされ、登録されていない状態です。

ユーティリティ URL では、「それでも登録された」ことを心配しなくてよい場合が多くあります。John Mueller は、WooCommerce の ?add-to-cart= URL が「ブロックされているがインデックス登録済み」として表示されたサイト所有者に対し、それらを登録する必要はなく、robots.txt でブロックして問題ないと説明しました。ブロック中に「登録」されても、非常に具体的な URL 検索を誰かが行わない限り、実際に検索結果へ現れる可能性は低く、通常のユーザーはそのような検索をしません。

noindex + disallow の衝突（逆効果になる最大の修正）

ここが落とし穴です。ページを消したい人が robots.txt で Disallow にし、さらに noindex メタタグを追加します。ベルトとサスペンダーのように見えますが、2 つの指示が矛盾するため機能しません。

Google はルールを直接示しています。“For the noindex rule to be effective, the page or resource must not be blocked by a robots.txt file, and it has to be otherwise accessible to the crawler.” (翻訳)「noindex ルールを有効にするには、ページまたはリソースが robots.txt ファイルによってブロックされておらず、別の方法でクローラーからアクセス可能でなければなりません」。ページが Disallow なら Google はクロールせず、noindex を見られないため、ページが登録されたままになることがあります。私の 「Indexed, though blocked by robots.txt」についての記事にも書いたように、Google がページをクロールできなければ noindex タグを見られず、リンクがあるため登録する可能性があります。

したがって、インデックスから削除する順序は、多くの人が考えるものと反対です。

1. URL の クロールを許可します（Disallow を削除します）。
2. noindex を返し（meta robots タグまたは X-Robots-Tag ヘッダー）、Google が再クロールして確認できるようにします。
3. 削除された後も noindex を置いたまま、ページをクロール可能にしておきます。後から再びブロックするのは安全な「仕上げ」ではありません。再び Disallow にすると、次のクロールで Google が noindex を見られなくなり、リンクされた URL がほかのページのリンクから再登録されることがあります。これは避けたかった「ブロックされているがインデックス登録済み」の状態そのものです。削除したページのクロール予算が本当に問題なら、認証または削除（404／410）を検討し、robots.txt を再度通る方法には戻りません。

緊急の削除には、Search Console の Removals ツール、パスワード保護、またはページを削除して 404／410 を返す方法のほうが速い選択肢です。

URL をブロックしているルールを見つける方法

3 つのツールにはそれぞれ別の役割があります。1 つのツールにほかの仕事まで期待しないでください。

• URL 検査（GSC）。 特定の URL を貼り付けます。その URL が現在ブロックされているかを確認でき、URL ごとのチェックとして最も速い方法です。
• robots.txt レポート（GSC）。 ドメインプロパティ単位の 監視レポートで、編集可能なテスターではありません。Google が上位ホストについて見つけた robots.txt ファイル、最終取得時刻、取得ステータス、解析警告、ファイル変更後の「再クロールをリクエスト」操作を表示します。Google がファイルを見られることは分かりますが、個々の URL をそのファイルに照らしてテストするものではありません。
• robots.txt バリデーターまたは Google のオープンソース robots.txt パーサー。 特定 URL に一致する行を確認するには、バリデーターに通します。最長で最も具体的な一致ルールが優先され、Allow はより広い Disallow を上書きできます。

問題の行を見つけたら、修正方法は robots.txt の場所によって異なります。ファイルを直接管理しているなら、ルールを削除または修正します（構文にも注意してください）。Wix、Shopify、Squarespace のようなホスティングプラットフォームなら、robots.txt を管理している場合があるため、そのサービス固有のドキュメントに従う必要があります。

インデックス登録したかったページをブロックすると何が起きるか — 私自身の実験

本当に役立つ質問は、「ランキングすべきページを 誤ってブロックしたら、どれほど悪いのか」です。私はこのテストを直接行いました。2023 年 1 月 30 日、実際にランキングしていた 2 ページ（「Top Bing Searches」と「Top YouTube Searches」）を robots.txt でブロックし、その後の変化を追跡しました。

損害は実際にありましたが、予想より小さいものでした。順位は一部で 1 つか 2 つ落ち、いくつかのキーワードは 1〜2 位下がり、逆に上がったものもありました。ブロック中はそのページの強調スニペットをすべて失いましたが、ブロックを解除すると戻りました。検索結果の見え方も悪化し、メタディスクリプションの代わりに「このページについて利用できる情報はありません」と表示され、独自のタイトルも失われました。表示が悪くなったため、クリック数はインプレッション数より大きく落ち、CTR が打撃を受けました。

当時の私の要約はこうでした。“We lost a position here or there and all of the featured snippets for the pages. I expected a lot more impact, but the world didn’t end.” (翻訳)「いくつか順位を失い、ページの強調スニペットをすべて失った。もっと大きな影響を予想していたが、世界が終わったわけではない」。それでも今も支持する結論は、インデックス登録したいページをブロックしないこと。痛手になります。思ったほどひどくなくても、痛手にはなります。 これがこのレポートの正しい見方です。「Blocked by robots.txt」の区分がすべて意図したブロックなら問題ありません。大切なページが入っているなら、外に出してください。

この実験の範囲に関する注意: 2 ページはいずれも、ブロックする前からランキングし、インデックス登録されていました。測定したのは、登録済みページが「ブロックされているがインデックス登録済み」の状態に移った場合の結果です。最初からインデックス登録されていない URL がこの除外区分にある場合の予測ではありません。ここにある URL がそもそも登録されていなければ、ブロックを解除すると Google が通常どおりクロールして検討できるようになるだけです。存在しなかった強調スニペットや CTR の履歴を失うことはありません。

判断ツリー

• ブロックするつもりでしたか。 → そのままにします。意図どおりに機能しています。
• いいえ — インデックス登録したいですか。 → robots.txt のルールを削除／緩和し、インデックス登録をリクエストします。
• Google から完全に消したいですか。 → Disallow は使いません。クロールを許可して noindex（または Removals ツール／削除）を行い、その後もクロール可能にします。後から再ブロックすると noindex ルールが再び見えなくなる可能性があります。
• ブロックされた URL がそれでも Google に表示されていますか。 → それはこのステータスではなく「ブロックされているがインデックス登録済み」のケースです。そちらで扱います。
• ページに機密情報や非公開情報がありますか。 → robots.txt はアクセス制御ではなく、ボットが無視できるリクエストです。Disallow ではなく認証またはパスワード保護を使います。

ちなみに、クロールとインデックス登録の原則は普遍的です。Bing も同じようにクロールで robots.txt を尊重します。Bing から URL を削除する場合も、裸の Disallow ではなく Block URLs ツールまたはクロール可能なページの noindex を使います。

ファイル自体の構文、ワイルドカード、配置場所、できること／できないことについては、robots.txt ガイドを参照してください。上流でインデックス登録の判断がどう行われるかは、インデックス登録ハブを参照してください。

AI サマリー

Advanced 版の要点をまとめます。

• 「Blocked by robots.txt」はページのインデックス登録における 除外です。 Google は URL を見つけましたが、robots.txt がクロールを禁止したためクロールせず、この状態では登録されません。ブロックの通常の結果で、意図的かつ問題のないことが多い状態です。
• robots.txt はクロールを制御し、インデックス登録は制御しません。 Google は “is not a mechanism for keeping a web page out of Google.” (翻訳)「ウェブページを Google から締め出すための仕組みではない」と説明しています。Disallow は取得を止めますが、ページをインデックスから削除しません。
• 警告 “Indexed, though blocked by robots.txt.” (翻訳)「ブロックされているがインデックス登録済み」と混同しないでください。 原因は同じでも結果が逆です。ブロックされた URL が通常は外部リンクを通じて、それでも登録されたことを意味します。ユーティリティ URL なら、Mueller の説明どおり通常の検索に現れにくく、問題ないことが多いです。
• 最大の逆効果は noindex + disallow の併用です。 Google は Disallow されたページをクロールできず、noindex を見られないため、ページが登録されたままになることがあります。Google のルールは、noindex を有効にするにはページが robots.txt でブロックされていてはならない、というものです。
• **ページを実際に削除するには、**クロールを許可し、noindex を返し、Google に再クロールさせ、その後もクロール可能にします。後で再ブロックすると noindex が見えなくなり、リンクから URL が登録される可能性があります。緊急時は Removals ツール、パスワード保護、ページ削除を使います。
• **ブロックしているルールを見つけるには、**URL 検査（URL ごとの確認）と robots.txt バリデーター（一致する行を確認し、最長／最も具体的なルールを優先）を使います。GSC の robots.txt レポートはファイルの取得状態を監視するもので、個々の URL のテストはしません。修正方法はファイルの管理場所によって異なり、ホスティングサービスでは提供者固有の手順が必要な場合があります。
• **Patrick の実験では、**すでにランキングし登録されていた 2 ページをブロックすると、順位をいくつか失い、強調スニペットをすべて失い、検索結果の表示が悪化し、クリック数がインプレッション数以上に落ちました。「世界が終わったわけではない」が「登録したいページをブロックしない」という結果です。これは登録済みページが「ブロックされているがインデックス登録済み」へ移る場合の実験で、未登録 URL の予測ではありません。
• robots.txt はセキュリティ制御ではありません。 ボットが無視できるリクエストです。機密コンテンツは Disallow ではなく認証で保護します。
• 判断ルール: 意図的にブロックした → そのままにする。登録したい → ブロックを解除して登録をリクエストする。削除したい → クロールを許可して noindex を返し、クロール可能なままにする。

公式ドキュメント

検索エンジンの一次資料です。

Google

• ページのインデックス登録レポート — このステータスが表示されるレポートで、“Blocked by robots.txt” (翻訳)「robots.txt によるブロック」と “Indexed, though blocked by robots.txt” (翻訳)「ブロックされているがインデックス登録済み」の定義を逐語的に確認できます。
• robots.txt によってブロックされたページのブロックを解除する — URL をブロックしているルールを見つけて修正する Google の手順です。
• robots.txt レポート — Google が見つけた robots.txt ファイル、取得状態、警告、再クロールのリクエストを示すドメインプロパティレポートです。
• robots.txt の概要 — robots.txt ができることとできないことを説明し、「ウェブページを Google から締め出すための仕組みではない」としています。
• noindex で検索インデックス登録をブロックする — noindex は robots.txt でブロックされていないページでのみ機能するという、noindex + disallow の衝突に関するルールです。

Bing / Microsoft

• Bing Webmaster Tools ヘルプ — Bing もクロールで robots.txt を尊重します。robots.txt Tester と Block URLs ツールは、同じクロールとインデックス登録の原則に従います。

出典からの引用

Google による記録に残る発言です。各リンクは、出典ページの引用箇所へ直接移動します。

Google — このステータスの意味

• “This page was blocked by your site’s robots.txt file. You can verify this using the robots.txt tester. Note that this does not guarantee that the page won’t be indexed through some other means.” (翻訳)「このページはサイトの robots.txt ファイルによってブロックされました。robots.txt テスターで確認できます。ただし、ほかの手段でページがインデックス登録されないことを保証するものではありません。」 — Google Search Console ヘルプ「ページのインデックス登録レポート」 引用箇所へ移動

Google — robots.txt はクロールを制御し、インデックス登録は制御しない

• “it is not a mechanism for keeping a web page out of Google.” (翻訳)「ウェブページを Google から締め出すための仕組みではありません。」 — Google Search Central「Introduction to robots.txt」 引用箇所へ移動

Google — noindex + disallow の衝突

• “For the noindex rule to be effective, the page or resource must not be blocked by a robots.txt file, and it has to be otherwise accessible to the crawler.” (翻訳)「noindex ルールを有効にするには、ページまたはリソースが robots.txt ファイルによってブロックされておらず、別の方法でクローラーからアクセス可能でなければなりません。」 — Google Search Central “Block Search indexing with noindex” (翻訳)「noindex で検索インデックス登録をブロックする」 引用箇所へ移動

引用する価値のある統計と一次データ

• ランキングページのブロック: 実害はあるが回復可能。 robots.txt で、すでにランキングしインデックス登録されていた 2 ページ（2023 年 1 月 30 日開始）をブロックした私の実験では、順位がいくつか落ち、強調スニペットをすべて失い、検索結果の表示が「このページについて利用できる情報はありません」に変わり、クリック数がインプレッション数より大きく落ちました。要約すると「もっと大きな影響を予想していたが、世界が終わったわけではない」一方、「登録したいページをブロックしないこと。痛手になる」です。これは登録済みページが「ブロックされているがインデックス登録済み」へ移る場合のテストで、未登録 URL の予測ではありません。出典
• 登録されたブロック済みユーティリティ URL は通常無害。 John Mueller によれば、add-to-cart 型 URL を robots.txt でブロックしてよく、ブロックされているが登録済みになっても通常の検索に現れる可能性は低いです。解説
• ウェブ全体で robots.txt ブロックがどれほど一般的か。 私と Xibeijia Guan の調査による、約 1 億 4000 万サイトでどのクローラーを最も多く Disallow しているかのブロック率データです。出典

このステータスを定義する間違い: noindex + disallow

間違い: ページを削除するために Disallow と noindex を組み合わせる。 これは「Blocked by robots.txt」に関連する最も一般的な間違いで、ベルトとサスペンダーのように感じるのに、実際には自滅的なので、あえて名前を付けて指摘する価値があります。ページを Google から消したい人が robots.txt で Disallow にし、さらに念のため noindex メタタグを追加します。機能しません。Google はルールを明確に述べています。“For the noindex rule to be effective, the page or resource must not be blocked by a robots.txt file, and it has to be otherwise accessible to the crawler.” (翻訳)「noindex ルールを有効にするには、ページまたはリソースが robots.txt ファイルによってブロックされておらず、別の方法でクローラーからアクセス可能でなければなりません」。ページが Disallow なら Google はクロールせず、noindex を見られないため登録されたままになります。意図した結果の正反対です。修正は逆で、クロールを許可してから noindex を返します。

神話: 「robots.txt の Disallow はインデックス削除ツールだ」。 そうではありません。Google は、robots.txt は “is not a mechanism for keeping a web page out of Google.” (翻訳)「ウェブページを Google から締め出すための仕組みではない」と直接説明しています。URL をブロックすると 取得は止まりますが、URL はインデックスから削除されません。リンクされたブロック済みページは表示されることもあります（兄弟ステータス「ブロックされているがインデックス登録済み」です）。実際に削除したいなら、クロールを許可した noindex または Removals ツールを使います。

神話: 「Blocked by robots.txt」区分にあるものはすべて修正すべきだ。 通常は逆です。このステータスは、内部検索結果、ファセットナビゲーション、ステージングパスなど、意図した Disallow の期待される結果です。不具合として扱う価値があるのは、本当はインデックス登録したかった URL が誤って一覧に入っている場合だけです。

間違い: コストを確認せず、ランキングさせたいページをブロックする。 「整理」や「クロール予算の節約」のためにランキングさせたいページをブロックするのは、見た目より危険です。私自身の実験では、ランキングページを 2 つブロックすると、ブロック中に強調スニペットをすべて失い、検索結果の表示が「このページについて利用できる情報はありません」に悪化したため、クリック数がインプレッション数より大きく落ちました。順位自体はおおむね維持されましたが、関心のあるページへの robots.txt ブロックは、単なる整理ではなく実際の意思決定として扱ってください。

「Blocked by robots.txt」トリアージチェックリスト

Search Console でこのステータスを開いたら、上から順に確認します。

• ページのインデックス登録レポートを開き、「Blocked by robots.txt」をクリックして、影響を受けた URL の実際の一覧を確認します。
• 各 URL（または URL パターン）について、これをブロックするつもりだったかを問います。
• 意図したブロックなら、内部検索、ファセットナビゲーション、ステージング、カート／チェックアウトなどはそのままにします。その URL ではステータスが意図どおり機能しています。
• 意図していない、または分からない場合は、URL 検査で URL を確認し、現在ブロックされていること（古いスナップショットではないこと）を確かめます。
• robots.txt Tester（または別の robots.txt バリデーター）で URL を捕捉している具体的なルールを見つけます。最長で最も具体的な一致ルールが優先され、Allow はより広い Disallow を上書きできます。GSC の robots.txt レポートはファイルの取得状態を監視するもので、個々の URL をテストしません。
• 同じ Disallow URL に noindex も依存していないことを確認します。この組み合わせは機能しません。目的が削除なら、クロールを許可して noindex を返します。
• ブロックルールを削除または緩和します。robots.txt を直接管理しているなら直接行い、ホスティングプラットフォームが管理しているなら Wix、Shopify、Squarespace などのドキュメントに従います。
• ブロックを解除した URL のインデックス登録を Search Console でリクエストします。
• このステータスを 「Indexed, though blocked by robots.txt」 と混同していないことを再確認します。そちらは反対の結果（それでも登録済み）で、別の修正が必要です。
• 数週間後に区分を再確認し、件数が期待どおりに推移したかを確認します（修正した URL は減少、意図的なブロックは横ばい）。
• URL に機密コンテンツがあるなら、非公開にするため Disallow に頼らず、認証またはパスワード保護を追加します。

判断ツリーを使う

「Blocked by robots.txt」区分にある URL について、正しい対応にたどり着くまで 1 度に 1 つの質問に答えます。

メンタルモデル

1. クロール ≠ インデックス登録。 この 2 つを混同すると、ステータス全体が分かりにくくなります。robots.txt は クロール（Googlebot がページを取得するか）を制御しますが、インデックス登録（URL が Google のインデックスに入るか）を直接制御しません。Disallow されたページは クロールによって登録されませんが、ほかのページからリンクされれば、コンテンツなしで登録されることがあります。2 つの考え方を分けると、このステータスの混乱の大半が解消します。

2. 1 問トリアージ。 何より先に、これをブロックするつもりだったかを問います。はい → そのままにします。意図どおりに機能しています。いいえ → 修正すべき唯一のケースです。この 1 問で、区分にある URL のほとんどを正しく分類できます。

3. ページを削除するには、本能を逆にする。 Disallow と noindex を「念のため」組み合わせる自然な対応は、まったく逆です。Google は取得しないページのディレクティブを見られません。正しい順序は、直感と反対の クロールを許可し、その後 noindex を返すです。ページを消すために Disallow に手を伸ばしたくなったら、このモデルを適用するサインです。

4. robots.txt はクロール予算のツールであり、検索結果のツールではない。 内部検索、ファセット、ステージングなど、価値の低い、または無限に増える URL 空間からボットを遠ざけ、見つけてほしいページへクロールの労力を向けるために使います。検索結果に何を表示するかを操作するものではありません。その役割は noindex、パスワード保護、または削除が担います。

区分の件数を追跡する（存在だけを見ない）

注目すべき 1 つの数字は、ページのインデックス登録レポートの「Blocked by robots.txt」行に時間とともに入っている URL 数です。単一のスナップショットでは、修正が効いたのか、新しい意図しないブロックが増えているのか分かりません。

「Blocked by robots.txt」区分の件数の推移

• 指標 — GSC のページのインデックス登録レポートで「Blocked by robots.txt」の下にある URL 数を時間の経過とともに記録します。
• 分かること — 区分が期待どおりに動いているかです。意図的にブロックする URL（内部検索、ファセット、ステージング）では、URL 空間が安定している限り件数はおおむね横ばいのはずです。急増は通常、新しいセクションが既存の Disallow パターンに誤って巻き込まれたことを示します。インデックス登録したくて意図的にブロックを解除した URL は、次のクロール後にその URL が区分から外れるはずです。
• 取得方法 — GSC の ページのインデックス登録レポートを「Blocked by robots.txt」行でフィルタし、URL 検査で特定 URL を確認します。古いスナップショットではなく現在のステータスを確認するためです。
• ベンチマーク／現実的な範囲 — 普遍的な目標はありません。サイトのどれだけを意図的に Disallow しているかに完全に依存します。正直な基準は、本当は登録したかった URL がこの区分に 0 件で、それ以外は横ばいであることです。変更が正しい方向に動かしたか判断する前に、自分の件数を基準値として記録します。
• 頻度 — robots.txt を変更した直後に確認します。それ以外は定期的に（月 1 回で十分なサイトが多い）見れば、変化を捉えられます。

手順書: ページを Google から実際に削除する

URL を将来のクロールからブロックするだけでなく、本当に Google のインデックスから外す必要がある場合の、繰り返し使える手順です。

1. 目的がクロール制御ではなく削除であることを確認する。 目的が「クロール予算の無駄を止める」だけなら、通常の robots.txt Disallow が正しいツールであり、この手順書は適用しません。そのページはリンク経由で登録されたままでも問題ありません。この順序を使うのは、ページを実際にインデックスから外す必要がある場合だけです。

2. クロールを許可する。 URL をブロックしている Disallow ルールを削除または緩和します。**robots.txt Tester**で、URL がブロックではなく許可になったことを確認します。

3. noindex を返す。 クロール可能になったページに noindex meta robots タグまたは X-Robots-Tag HTTP ヘッダーを追加します。これが実際の削除指示です。Disallow がその役割を担っていたわけではありません。

4. Google に再クロールして取得させる。 Google は noindex を見るためにページをもう一度取得する必要があります。Search Console でインデックス登録をリクエストして次のクロールを待つ以外に、即時取得を強制する方法はありません。

5. 削除を確認する。 Search Console の URL 検査で、ページの現在の登録ステータスを確認します。「noindex により除外」と報告されれば、削除は機能しています。

6. 再ブロックを仕上げの手順にしない。 ページが落ちた後に Disallow を戻すのは無料ではありません。次のクロールで Google が noindex を見られなくなり、リンクされた URL がほかのページのリンク経由で再び登録される可能性があります。これは避けたかった「ブロックされているがインデックス登録済み」の結果です。クロール予算が問題ならリスクと比較し、本当に永続的に消しておくページなら認証または削除を選びます。

7. 緊急時は待たない。 ページを 今すぐ外す必要があるなら、クロールしてから noindex を返すサイクルを待たず、Search Console の Removals ツール、ページのパスワード保護、または完全削除（404／410）を使います。

すぐ使える AI プロンプト

robots.txt によるブロックを LLM と一緒に検討するための、コピー＆ペースト用プロンプトです。出力は最初の仮説として扱い、重要な内容は行動する前に robots.txt Tester または Search Console の URL 検査で確認してください。

どのルールがどの URL をブロックしているかを確認する

Here is my robots.txt file and a list of URLs. For each URL, tell me whether it
is blocked or allowed, and quote the exact line in robots.txt responsible
(remember: the longest, most specific matching rule wins, and an Allow can
override a broader Disallow). If a URL isn't matched by any rule, say so.

ROBOTS.TXT:
[paste]

URLS:
[paste list, one per line]

ブロックが意図したものかを健全性確認する

I run a [type of site]. Here is my robots.txt file. For each Disallow rule, tell
me what kind of URLs it likely targets (e.g. internal search, faceted
navigation, staging, cart/checkout, admin) and flag any rule that looks broad
enough it might be catching content pages by accident. Don't guess about pages
you can't see — just reason from the rule pattern and ask me to confirm
anything ambiguous.

ROBOTS.TXT:
[paste]

特定ページの noindex → クロールの順序を作成する

I need to remove [URL] from Google. It's currently blocked by this robots.txt
rule: [paste rule]. Walk me through the exact sequence of changes in order
(robots.txt edit, meta tag or header change, what to check in Search Console at
each step) so I don't accidentally leave the noindex tag unseen by Google.

URL を robots.txt ルールに照らしてテストする

変更する前に、どのルールが URL を捕捉しているかを正確に確認します。**robots.txt Tester**は Google のオープンソース robots.txt パーサーから移植したマッチャーでこれを行い、URL ごとの勝者ルールを表示します。最も速く、正確な方法です。ツールを使わず手動で簡単に確認するなら、中心となるロジックは次の Python です。

import re

def rule_matches(path, rule):
    """Very simplified robots.txt path matcher: '*' = wildcard, '$' = end anchor."""
    pattern = re.escape(rule).replace(r'\*', '.*')
    if pattern.endswith(r'\$'):
        pattern = pattern[:-2] + '$'
    return re.match(pattern, path) is not None

def find_blocking_rule(path, disallow_rules, allow_rules):
    """Longest matching rule wins; ties go to Allow (mirrors Google's documented
    precedence). Returns the winning rule string, or None if nothing matches."""
    matches = [r for r in disallow_rules if rule_matches(path, r)]
    matches += [r for r in allow_rules if rule_matches(path, r)]
    if not matches:
        return None
    return max(matches, key=len)

# Example
disallow = ["/search", "/*?*sort="]
allow = ["/search/help"]
print(find_blocking_rule("/search/help", disallow, allow))  # -> "/search/help" (Allow wins, longer)
print(find_blocking_rule("/search/results", disallow, allow))  # -> "/search" (Disallow, no competing Allow)

これは Google の実際のマッチャーを単純化したものです（実際の robots.txt 解析にはエスケープやグループ選択など、さらにエッジケースがあります）。考え方の確認には使えますが、重要な判断は本物のテスターで確認してから依存してください。

このステータスの診断と修正に使うツール

• Google Index Checker — ブロックを修正したら、Search Console で Google の実際の回答を確認する前に、ページの観測可能なインデックス可否シグナル（ステータスコード、リダイレクト、noindex、canonical）を確認します。
• URL 検査（Google Search Console） — 特定 URL が現在ブロックされているか、ライブテストでインデックス登録可能か、修正後に Google が再取得したかの情報源です。
• robots.txt レポート（Google Search Console） — Google が上位ホストで見つけた robots.txt ファイル、最終取得時刻、取得ステータスをドメインプロパティ単位で表示し、変更後の再クロールをリクエストできます。

テスト: robots.txt によるブロック

「robots.txt によるブロック」ステータスと、それをめぐるよくある間違いについての 5 問です。各問に答えてから確認してください。

削除が実際に機能したことを証明する

「noindex を設定した」「robots.txt を編集した」だけでは何も証明できません。重要なのは、その後に Google のインデックスがどう反映したかだけです。次のテストで、行った変更と Google が到達した結果を分けて確認します。

テスト 1 — クロールが本当に許可されている

• 実行するテスト — ファイルを編集した後、**robots.txt Tester**で URL をテストします。
• 期待する結果 — URL が許可になり、URL に一致する Disallow ルールがありません（または、より具体的な Allow が広い Disallow に勝ちます）。
• 失敗の解釈 — まだブロックされるなら、別のより具体的なルールが URL を捕捉しているか、編集がデプロイされていません。変更するつもりだった内容ではなく、実際に配信されているファイルを確認します。
• 監視期間 — 配信されたファイルの静的チェックなので即時です。
• ロールバック条件 — なし。次のテストに進む前にルールを修正します。クロールが実際に許可されない限り、下流の処理は何も機能しません。

テスト 2 — noindex が正しく配信されている

• 実行するテスト — クロール可能になった URL で、Search Console の URL 検査 → ライブテスト（またはページを直接取得してレスポンスヘッダー／HTML）を確認します。
• 期待する結果 — ライブテストで noindex が存在します。<head> の meta robots タグ、または X-Robots-Tag HTTP ヘッダーのいずれかです。
• 失敗の解釈 — ここに noindex がないなら、どれだけ待っても削除されません。クロールを許可するだけでは何も削除されません。
• 監視期間 — ライブテストは現在配信されているページを反映するため即時です。
• ロールバック条件 — なし。Google が動作する可能性を持つ前に、このテストを通過する必要があります。

テスト 3 — Google が実際にページを削除した

• 実行するテスト — 前の 2 つのテストに合格した後、URL の URL 検査（ライブテストだけでなく登録ステータス欄）を定期的に確認します。
• 期待する結果 — ステータスが noindex による除外へ変わり、URL が site: 検索や順位追跡データに表示されなくなります。
• 失敗の解釈 — 1 回の完全なクロールサイクル後も登録済みなら、通常は設定の破損ではなくキャッシュ／反映の遅延です。Google は変更に気づくため再クロールする必要があり、即時ではありません。
• 監視期間 — 1〜3 週間。Google がその URL をクロールしていた頻度によります。変更の翌日に判断しないでください。
• ロールバック条件 — 名前付き中止条件 — 完全なクロールサイクル後も登録済みで、サーバーログ上はページが新しくクロールされ続けている場合は、単なる反映遅延だと決めつけません。テスト 1 と 2 を再確認し、キャッシュ層が古い robots.txt を配信していないか、CDN が X-Robots-Tag ヘッダーを削除していないか、2 つ目の競合ルールがないかを調べます。

変更履歴