「robots.txtによりブロックされました」は取りに行かなかったという報告です

サーチコンソールの「ページ」を開いたら、robots.txtでブロックされている、という意味の行にURLが並んでいた。

「ブロック」という言葉が強いので、まず自分がどこかを塞いでしまったのだと思います。しかも調べに行くと、よく似た名前の項目がもう1つ出てきます。読んでいる解説がどちらの話なのか、読者側では区別がつきません。

結論を先に書きます。この項目は、Googleがそのページを取りに行かなかったという事実の報告です。取りに行っていないので、Googleはそのページの中身について何も判断していません。だから意図してブロックしたURLなら、この行はそのままで構いません。

直す理由があるのは「そのURLを検索結果に出したいのに、ブロックされているとき」と、「消したつもりなのに、検索結果にURLが残っているとき」の2つだけです。

この項目は何を言っているのか

robots.txtは、どのURLにアクセスしてよいかをクローラーに伝えるファイルです。公式ドキュメントの定義はこうです。

robots.txt ファイルとは、検索エンジンのクローラーに対して、サイトのどの URL にアクセスしてよいかを伝えるものです。これは主に、サイトでのリクエストのオーバーロードを避けるために使用するもので、Google にウェブページが表示されないようにするためのメカニズムではありません。
— Google公式「robots.txt の概要とガイド」

伝えているのは「取りに行っていいか」だけで、「検索結果に出すか」ではありません。レポートに出ているのも、その1点だけです。公式ヘルプの説明の全文はこうなっています。

このページはサイトの robots.txt ファイルによってブロックされました。この確認には robots.txt テスターを使用できます。robots.txt でブロックされていても、他の方法によってページがインデックスに登録されることがあります。たとえば、Google がページを読み込む以外の方法でそのページに関する他の情報を検出した場合に、ページがインデックスに登録される場合があります（ただし、そうした事例はごくまれです）。Google のインデックスに確実に登録されないようにするには、robots.txt によるブロックを削除して noindex ディレクティブを使用します。
— ページのインデックス登録レポートの公式ヘルプ

そして同じヘルプは、この状態を「たいてい意図的なものだ」と書いています。修正の検証をリクエストする機能を説明する箇所です。

ウェブサイトに関する問題によっては、修正して検証することに常に意味があるとは限りません。たとえば、robots.txt により URL がブロックされているという問題は、意図的である場合がほとんどです。各問題への対処の必要性については、状況に応じてご判断ください。
— Google公式ヘルプ

未登録であること自体も、このヘルプは問題として扱っていません。「「未登録」は、必ずしも URL にとって不適切な状態であるとは限りません」と書いたうえで、「URL が正当な理由（想定内のサイトの robots.txt ルール、ページの noindex タグ、重複した URL、削除したが代わりがないページの 404 など）でインデックスに登録されないのは問題ありません」と続けています。いちばん先に挙がっているのが、まさにこの行です。

⚠️ 文言について1つ補足します。この状態を指す言い回しは、公式の中でも2通り確認できました。2026年9月8日にページのインデックス登録レポートの日本語ヘルプの本文を取得して検索したところ、「robots.txt によりブロックされました」という並びは1か所しかなく、それは後述する警告側の項目名の一部でした。このページで未登録側の見出しになっているのは「URL が robots.txt によってブロックされています。」です。さらに別のヘルプ「robots.txt によってブロックされているページのブロックを解除する」は、URL検査での表示を「robots.txt によりブロックされています」と書いています。照合したのはこの2ページの本文だけで、Search Consoleの画面表示そのものは確認していません。この2つは呼び方が揺れているだけで、指しているものは同じです。ただし「robots.txt によりブロックされました」は警告側の項目名の一部で、意味がほとんど逆になります(後述)。

なぜ、ブロックした覚えのないURLまで並ぶのか

robots.txtの判定が、ページを取りに行く前に、URLのパスだけを見て行われるからです。Googleはそのページを開いていません。中身も、そのルールが何本のURLに当たるかも見ないまま、通すか通さないかが決まります。これから挙げる3つは、全部この1点から出ています。

① 止まる範囲を決めているのは、URLの一覧ではなくパスのパターン

robots.txtに書くのは「このURLとこのURL」ではなく、パスの書き出しです。だから1行が、書いた人の想定より広く効きます。公式の解釈ドキュメントには一致例の表があり、そのうち/fishの行はこう説明されています。

/fish で始まるすべてのパスが一致します。一致判定では大文字と小文字が区別されます。
— Google公式「Google による robots.txt の指定の解釈」

同じ行に挙がっている一致・不一致の例が、この記事でいちばん見てほしいところです。

⚠️ この表は公式の「パスの一致の例」から/fishの行だけを抜き出したものです。同じ表には/や/$、/fish/、/*.phpなど他の行もあります。

フォルダを1つ止めたつもりが、同じ文字で始まる別の記事まで止まっている。これが「ブロックした覚えのないURL」の正体としてよくある形です。大文字と小文字が区別される点も、意図とずれる方向に働きます。

止まるのは記事だけではありません。公式は画像やスクリプト、スタイルファイルについて「それらのリソースがないと Google のクローラーがページを把握しにくくなる場合はブロックしないでください。ブロックすると、それらのリソースを利用しているページを Google が適切に分析できなくなります」と書いています。広めに書いた1行が、記事の見え方まで変えることがあります。

② 効くrobots.txtはホストごとに1つで、継承されない

「自分のサイトのrobots.txt」を1つ開いても、原因のファイルとは限りません。Search Consoleのrobots.txtレポートのヘルプは、こう書いています。

robots.txt ファイルはサブドメインまたは親ドメインに継承されません。また、1 つのページに適用されるのは、1 つの robots.txt ファイルのみです。
— Google公式ヘルプ「robots.txt レポート」

同じヘルプは、そのページに効くファイルの探し方も書いています。「URL のトップレベル ドメイン（.com、.org、.co.il など）の後の部分を削除して、末尾に「/robots.txt」を追加します」という手順で、例として「https://images.example.com/flowers/daffodil.png」のrobots.txtは「https://images.example.com/robots.txt」になると書かれています。ブロックされているURLのホストを見て、そのホストのrobots.txtを開いてください。

そして、そのファイルを置いたのが自分とは限りません。公式は、ブロックを解除する手順の中でこう書いています。

ウェブサイト ホスティング サービスを使用している場合（たとえば、Wix、Joomla、Drupal などでサイトを構築している場合）、robots.txt ファイルの更新方法は各ホスティング サービスによって異なるため、ここでは正確なガイダンスを提示できません。
— Google公式ヘルプ「robots.txt によってブロックされているページのブロックを解除する」

Googleがサービス名を挙げたうえで案内を書けないと明言しているということは、「robots.txtはこうなっているはず」という一般論では当たらないということです。自分のサイトのファイルを実際に開いて読むところからしか始まりません。

③ ページの中は一度も読まれないので、ページに書いた指示は届かない

取りに行かない以上、そのページに何が書いてあってもGoogleには届きません。だからrobots.txtでのブロックは、検索結果から消す方法として機能しません。公式ドキュメントの言い方はこうです。

ウェブページが robots.txt ファイルでブロックされている場合、検索結果にその URL が表示されることはありますが、説明は表示されません。
— Google公式「robots.txt の概要とガイド」

解釈のドキュメントにも、同じことがもう少し機械的な言い方で書かれています。「Google は、クロールが許可されていないページのコンテンツをインデックスに登録することはできませんが、URL をインデックスに登録して、スニペットなしで検索結果に表示することはできます」。URLだけが残る、という状態がここから生まれます。

この性質があるので、同じURLにnoindexとrobots.txtのブロックを同時にかけると打ち消し合います。なぜそうなるのか、どちらを先に外すのかはサイトマップは必要か・robots.txtの書き方、個人ブログはほぼ不要に書きました。この記事では、その仕組みと外す順序の一般論には踏み込みません(警告側の項目については、後で専用の記事へ渡します)。

混同しやすい、もう1つの項目

同じレポートには、robots.txtという言葉が入った項目が2つあります。片方は未登録の理由、もう片方は警告で、意味はほとんど逆です。

項目名はページのインデックス登録レポートの日本語ヘルプの見出しから取りました(2026年9月8日時点)。警告についてこのヘルプは「これらの問題によってページがインデックスに登録されないわけではありませんが、Google によるページの認識とインデックス登録の能力は低下します」と説明しています。

警告のほうが出ているときは、消したつもりのURLが検索結果に残っています。そちらはこの記事とは打ち手が逆で、robots.txtのブロックを外すところから始まります。説明文の全文と、公式が示している手順は「インデックスに登録されましたが、robots.txtによりブロックされています」は警告ですにまとめました。この記事では扱いません。

noindexそのものの探し方・外し方は「noindexタグによって除外されました」は正常、直すのは意図と違うときだけに書いています。なお、サイトマップの送信時に出る「robots.txt にアクセスできません」は、これとは別のエラーです。あちらはファイルを取りに行けなかった側の話で、原因も直し方も違います(サイトマップの「robots.txt にアクセスできません」はサーバー側の問題です)。

判断は2つに分かれる

先に、並んでいるURLを読んでください。ブロックが意図どおりかどうかで、やることが変わります。

この一覧の件数を0にする作業ではありません。検証の説明にある「常に意味があるとは限りません」は、まさにこの行のために書かれた一文です。意図したブロックが並んでいるだけなら、そこで終わりです。

インデックスされない原因はrobots.txtだけではありません。全体の切り分けはインデックスされない原因は2系統に分かれる、確認できるものから潰すに整理しています。この記事はrobots.txtの行だけを扱います。

外すと決めたとき、どこを見るか

公式は、この状態に対する手順そのものを1ページにまとめています。最初にやるのは、そのURLが本当にrobots.txtで止まっているかの確認です。

検査結果で、[ページのインデックス登録] セクションのステータスを確認します。[robots.txt によりブロックされています] と表示されている場合は、それが問題です。
— Google公式ヘルプ「robots.txt によってブロックされているページのブロックを解除する」

URL単位の確認にURL検査を使うことは、robots.txtレポートのヘルプ側にも書かれています。「特定の URL が robots.txt ファイルによってブロックされているかどうかをテストする場合は、URL 検査ツールを使用します」という一文です。

ファイルそのものの状態を見るのがrobots.txtレポートです。ただし公式は「このレポートは、ドメインレベルのプロパティでのみご利用いただけます」と条件を書いています。パス付きのURLプレフィックスでプロパティを作っている場合は、このレポートが出てきません。

ルールを直したあとに、急いで押したくなるのが再クロールのリクエストです。ここも公式が先回りして書いています。

Google では robots.txt ファイルの再クロールを頻繁に実施しているため、通常は再クロールをリクエストする必要はありません。
— Google公式ヘルプ「robots.txt レポート」

リクエストできる場合として挙がっているのは、重要なURLのブロックを解除してすぐ知らせたいときと、取得エラーなどを直したときです。前者には「リクエストしてもブロックを解除した URL がすぐに再クロールされるとは限りません」という但し書きが付いています。robots.txtが読み直されることと、そのURLが取りに来られることは別々です。

レポート側の検証についても、公式ヘルプは所要時間を書いています。「検証は通常 2 週間ほどで完了しますが、それより長くかかる場合もあります」。翌日に件数が減らないのは失敗ではありません。

URL検査の表示ごとに次の一手がどう変わるかはサーチコンソールでインデックスを確認する方法、URL検査の表示ごとに次の一手が違うにまとめてあります。robots.txtそのものの書式と最小構成はサイトマップは必要か・robots.txtの書き方、個人ブログはほぼ不要にあります。

片付いた後にやること

この行を読み終えると、たいていは「意図したブロックだった」で終わります。そのとき残るのは、すでに検索結果に出ているページのほうをどうするかという問題です。

ここから先は、クロールの話ではなく順位とクリックの話になります。使う道具も変わります。選択肢としては、たとえば次のような分かれ方をします。

• サーチコンソールの検索パフォーマンスをそのまま見る。追加の道具は要りませんが、表示回数・クリック数・掲載順位を自分で見比べる手間がかかります
• Looker Studioなどにつないで表を作る。自由に加工できますが、作るまでの設定が要ります
• スプレッドシートにCSVを落として並べ替える。誰でもできますが、毎月同じ手順を踏むことになります
• リライト候補の抽出に特化したツールを使う。判断は速くなりますが、道具ごとに前提と得意分野が違います

検索パフォーマンスのどこを見るかはサーチコンソールでリライト記事をどう選ぶ？迷わない判定基準と手順にまとめています。

よくある質問

「robots.txtによりブロックされました」とはどういう意味ですか

サイトのrobots.txtのルールに当たったため、Googleがそのページを取りに行かなかった、という意味です。公式ヘルプは「このページはサイトの robots.txt ファイルによってブロックされました」と説明しています。ページの中身が問題だと言われているのではありません。

これはエラーですか。直さないといけませんか

意図して止めたURLなら、直す必要はありません。公式ヘルプは「たとえば、robots.txt により URL がブロックされているという問題は、意図的である場合がほとんどです」と書き、対処の必要性は状況に応じて判断するよう案内しています。直すのは、読ませたい記事が混ざっているときだけです。

ブロックした覚えがありません。どこを見ればいいですか

まず、ブロックされているURLと同じホストのrobots.txtを開いてください。公式ヘルプは「robots.txt ファイルはサブドメインまたは親ドメインに継承されません。また、1 つのページに適用されるのは、1 つの robots.txt ファイルのみです」と書いています。トップページのファイルを見ても、サブドメインのURLの原因は分かりません。そのうえで、当たっているルールを特定します。ブロックを解除する手順の公式ヘルプは、ホスティングサービスを使っている場合は更新方法が各サービスで異なるため正確なガイダンスは示せないとしており、提供元のドキュメントを調べるよう案内しています。

1行しか書いていないのに、たくさんのURLが止まっています

robots.txtに書くのはURLの一覧ではなく、パスの書き出しだからです。公式の解釈ドキュメントは/fishについて「/fish で始まるすべてのパスが一致します」とし、一致する例に/fishheadsや/fishheads/yummy.htmlを挙げています。フォルダを止めたつもりでも、同じ文字で始まる別のURLに当たります。同じ説明に「一致判定では大文字と小文字が区別されます」ともあり、逆に/Fish.aspは一致しない例として挙がっています。

robots.txtでブロックすれば、検索結果から消せますか

消せません。公式ドキュメントはrobots.txtについて「Google にウェブページが表示されないようにするためのメカニズムではありません」と書き、「ウェブページが robots.txt ファイルでブロックされている場合、検索結果にその URL が表示されることはありますが、説明は表示されません」と説明しています。これが起きている状態が、警告の「robots.txt によりブロックされましたが、インデックスに登録しました」です。公式ヘルプはこの場合、ブロックを削除したうえでnoindexを使うよう案内しています。併用したときに打ち消し合う仕組みはサイトマップは必要か・robots.txtの書き方、個人ブログはほぼ不要にまとめました。

ルールを外しました。いつ戻りますか

Googleがrobots.txtを読み直し、そのうえでそのURLを取りに来たときです。公式ヘルプは再クロールのリクエストについて「リクエストしてもブロックを解除した URL がすぐに再クロールされるとは限りません」と書いています。レポート側の検証は公式ヘルプいわく「通常 2 週間ほどで完了しますが、それより長くかかる場合もあります」です。翌日に画面が変わらないのは失敗ではありません。

まとめ

• これは、Googleがそのページを取りに行かなかったという報告。中身は読まれていないので、記事の内容が悪いと言われているわけではない
• 意図して止めたURLなら、直すところはない。公式ヘルプは「robots.txt により URL がブロックされているという問題は、意図的である場合がほとんどです」と書いている。件数を0にする作業ではない
• 判定は、取りに行く前にURLのパスだけで決まる。だから書くのはURLの一覧ではなくパターンで、公式の例では/fishが/fishheadsにも当たる
• 効くrobots.txtはホストごとに1つで、サブドメインにも親ドメインにも継承されない。ブロックされているURLと同じホストのファイルを開く
• robots.txtは検索結果から消す仕組みではない。公式は「検索結果にその URL が表示されることはありますが、説明は表示されません」と明記している
• 似た名前の警告「robots.txt によりブロックされましたが、インデックスに登録しました」は意味が逆。消したつもりのURLが残っている状態で、公式の案内はブロックを削除して、さらにnoindexを使う

ここから先は、私が作ったツールの話です。

リライトレーダーは、この記事の「片付いた後にやること」で書いたすでに検索結果に出ているページの側を扱います。 Search Console のエクスポートをZIPのまま落として貼るだけで、掲載順位4.0〜20.5位・表示回数100回以上のページだけを拾い、改善余地スコアの大きい順に並べます。判定と候補3記事の改善余地スコアの確認、そのうち1記事分の診断カードまでは無料で、残りの診断カードが2,980円(税込)の買い切りです。月額課金や自動更新はありません。ログインも不要です。CSVファイルそのものはブラウザの外に出ません(送るのは、診断カードを出すときは選んだ1ページのURL・数値・入力したキーワード、「ページタイトルを取得する」を押したときは判定に出たページのURL最大10件です)。

⚠️ ただし、向かない人がいます。robots.txtのブロックを探しに来た人には、この時点では向きません。robots.txtもクロールもインデックス登録も扱っていません。読むのは、すでに検索結果に出ているページの4つの数字だけです。そもそもブロックされているページは「ページ」CSVにほぼ出てきません。検索結果に表示された記録が少ないからです(この記事で書いたとおり、ブロックされたまま検索結果に出ることはあります)。また、表示回数が2桁で止まっているサイトにも向きません。判定の条件が表示回数100回以上なので、対象になるページが1つも出ないからです。