【テクニカルSEO】robots.txtの設定でよくある間違い7つを徹底解説
2025年12月4日
ライター:西村 彰悟
SEO

robots.txt とは、検索エンジンやChatGPTなどのクローラー(Webページを巡回するボット)に対して、自分のウェブページをどのようなルールでクロールして欲しいかを伝えるためのテキストファイルです。

一見シンプルな仕組みであるがゆえに、誤った使い方をされてしまうことも少なくありません。

本コラムでは、 robots.txt のよく間違い7つをご紹介します。ご自身のサイトが当てはまっていないか、ぜひチェックしてみてください。

  1. robots.txtをアクセス制限の仕組みと誤解している
  2. インデックス対象外のページを指定するために robots.txt を使う
  3. robots.txt をURLの正規化に使用する
  4. robots.txt でCSS・JavaScriptの読み込みをブロックしている
  5. User-Agent:* をすべてのボットに向けた指示と誤解している
  6. robots.txtに正規表現を使っている
  7. サブドメイン違いのページを制御しようとしている
  8. まとめ

robots.txtをアクセス制限の仕組みと誤解している

robots.txt はクローラーによるトラフィックを管理するために使用されるものであり、アクセス制御のためのものではありません

These rules are not a form of access authorization.

RFC 9309: Robots Exclusion Protocol, Section 1 Introduction より)

セキュリティ上の理由でクローラーに見られたくないページは次のような手段で制御しましょう。

  • アクセス元IP制限
  • Basic認証
  • ログイン状態でないと見れないようにする

また、robots.txt の指示は各クローラーが自主的に従うものであり、 robots.txt を見ないクローラーも存在します。たとえばByteDance社のクローラー Bytespider は robots.txt でブロックしても効果がありません(執筆時点)。

インデックス対象外のページを指定するために robots.txt を使う

原則的に robots.txt が制御するのはクロールであり、インデックスではありません。検索結果に載せたくないページの制御には noindex を使用します。

Google検索では robots.txt でブロックされたページはクロールされなくなりますが、重要なページからリンクされている等の理由でページの内容を確認せずにインデックスする場合があります。

検索エンジンがページの内容を確認しなくなるので、もしページ内に noindex が設定されていても検索エンジンは気づくことができません。つまり、noindex と robots.txt によるブロックは併用できません

よく「 robots.txt が無視された」と耳にしますが、これはドキュメントに記載されている仕様通りの結果です。

Google では、robots.txt ファイルでブロックされているコンテンツをクロールしたりインデックスに登録したりすることはありませんが、ブロック対象のURLがウェブ上の他の場所からリンクされている場合、そのURLを検出してインデックスに登録する可能性はあります。

robots.txt の概要とガイド | Google 検索セントラル  |  Documentation  |  Google for Developers, robots.txt ファイルの制約について)

Googleがページの中身を確認せずにインデックスしたページが検索結果に表示されている様子

Googleがページの中身を確認せずにインデックスしたページが検索結果に表示されている図

robots.txt でブロックされた状態のままGoogle検索にインデックスされているページはGoogle Search Consoleのページレポートでも確認できます。

robots.txtにブロックされた状態でインデックスされたページがGoogle Search Consoleのページレポートに「robots.txt によりブロックされましたが、インデックスに登録しました」という項目で表示されている様子

robots.txt をURLの正規化に使用する

膨大な組み合わせが発生するサイト内検索の絞り込みパラメータ(ファセットナビゲーション)、無限の検索キーワードが発生するサイト内検索結果ページなど、クロールさせる意味がなく、検索エンジンの有限のクロール能力を著しく浪費する可能性があるページを robots.txt でブロックすることには意味があります

一方で、重複URL問題に対応する目的(URLの正規化)で robots.txt を使うことはできません。URLの正規化を行いたいときは次の何れかの方法で対応します。

  • utmパラメータなど、インデックスされたくないパラメータ付きのURLで開かれる可能性があるページ → canonical タグを使って正規化
  • 複数のURLで同じページが表示されるとき(例 : www. の有無・ index.html の有無・ URL末尾のスラッシュの有無) → 301リダイレクトを用いていずれかのURLに統一

また、次のようなページを robots.txt でブロックしてしまった場合、検索エンジンがリンク先ページを発見できなくなったり、リンク元ページとリンク先ページの繋がりを評価することが難しくなったりすることがあります。

  • SEO上重要なサイト外リンク・サイト内リンクのURLに含まれるパラメータ
  • リンクをクリックしてページが表示されるまでのリダイレクト中に経由するページ

この場合は robots.txt 側でのブロックを避けるか、サイト側のリンクURLやリダイレクト設定をrobots.txtでブロックされないものに変更します。

robots.txt でCSS・JavaScriptの読み込みをブロックしている

「クロールによるサーバー負荷を軽くしたい」という理由で、CSS・JavaScriptファイルのクロールを robots.txt でブロックしているサイトを見かけますが、検索エンジンがページの内容を正しく評価することができなくなってしまいます。特別な事情がない限りページの描画に必要なリソースはブロックしないようにしましょう。

Google Search Consoleのライブテストでページの表示が崩れていたり、ページレポートで「ソフト404」が多発している場合、ページの描画に必要なリソースを robots.txt でブロックしている可能性があります。

クロールによるサーバー負荷を軽減したい場合はCDNやキャッシュの活用が有効です。

12 月のクロール情報: HTTP キャッシュ保存  |  Google Search Central Blog  |  Google for Developers

「Google検索結果にCSS・JavaScriptファイルが出てこないようにブロックしている」という話も聞くことがありますが、これらのファイルはインデックス対象ではないので対策不要です。

Google によるインデックス登録が可能なファイル形式 | Google 検索セントラル  |  Documentation  |  Google for Developers

User-Agent:* をすべてのボットに向けた指示と誤解している

User-Agent: * 向けのルールは、個別に指示を受けていない「その他」のクローラーが従うためのルールです。たとえば、次の robots.txt は検索エンジンのクロール能力を浪費するページをブロックするためにDisallowルールが設定されていますが、Bing検索のクローラーである Bingbot に対してはDisallowルールが適用されません。

User-agent: *
Disallow: /search?q=       # サイト内検索結果ページ
Disallow: /*?max-price=    # ファセットナビゲーション(価格絞り込み上限) 
Disallow: /*&max-price=    # ファセットナビゲーション(価格絞り込み上限) 
Disallow: /*?min-price=    # ファセットナビゲーション(価格絞り込み下限) 
Disallow: /*&min-price=    # ファセットナビゲーション(価格絞り込み下限) 

User-agent: Bingbot
Crawl-delay: 5

Sitemap:  https://example.com/sitemap_index.xml

Bingbot向けには個別に User-Agent: Bingbot による指示が行われているため、Bingは User-Agent: * 向けのルールを無視します。

robots.txt の文法について書かれている RFC9309 にも以下のように書かれています。

If no matching group exists, crawlers MUST obey the group with a user-agent line with the “*” value, if present.

RFC 9309: Robots Exclusion Protocol, Section 2.2.1. The User-Agent Line より)

先ほどのrobots.txtの場合、次の何れかの形に修正することで対応できます。

修正例1: 「その他のクローラー向けの指示」を「Bingbotとその他のクローラー向けの指示」に変える

下記のような書き方をすればBingbotにDisallowルールとCrawl-delayルールの両方を見てもらうことが可能です。

User-agent: Bingbot      # Bingbotと
User-agent: *            # その他のクローラー向けのルール
Disallow: /search?q=       # サイト内検索結果ページ
Disallow: /*?max-price=    # ファセットナビゲーション(価格絞り込み上限) 
Disallow: /*&max-price=    # ファセットナビゲーション(価格絞り込み上限) 
Disallow: /*?min-price=    # ファセットナビゲーション(価格絞り込み下限) 
Disallow: /*&min-price=    # ファセットナビゲーション(価格絞り込み下限) 

User-agent: Bingbot      # Bingbot向けのルール
Crawl-delay: 5

Sitemap:  https://example.com/sitemap_index.xml

※ シャープ記号(#)より右側の文字列はコメントとして無視されます

修正例2: Bingbot向けのルールを削除 & その他のクローラー向けにCrawl-delayルールを追加

最もシンプルな記述スタイルですが、思わぬクローラーが現在または将来的に Crawl-delay の影響を受けるリスクがあります。

User-agent: *
Disallow: /search?q=       # サイト内検索結果ページ
Disallow: /*?max-price=    # ファセットナビゲーション(価格絞り込み上限) 
Disallow: /*&max-price=    # ファセットナビゲーション(価格絞り込み上限) 
Disallow: /*?min-price=    # ファセットナビゲーション(価格絞り込み下限) 
Disallow: /*&min-price=    # ファセットナビゲーション(価格絞り込み下限) 
Crawl-delay: 5             # 主にBing向け。Googleには現在非対応

Sitemap:  https://example.com/sitemap_index.xml

修正例3: その他のクローラー向けに書いていたルールをBingbot向けにもすべて記載する

クローラーごとに細かく指示を分けるときに使いやすい記述スタイルです。robots.txtの仕様に詳しくない人でも読みやすいですが全体が長くなってしまうため、今後のメンテナンス時に部分的な変更漏れが起きないよう注意が必要になります。

User-agent: Bingbot      # Bingbot向けのルール
Disallow: /search?q=       # サイト内検索結果ページ
Disallow: /*?max-price=    # ファセットナビゲーション(価格絞り込み上限) 
Disallow: /*&max-price=    # ファセットナビゲーション(価格絞り込み上限) 
Disallow: /*?min-price=    # ファセットナビゲーション(価格絞り込み下限) 
Disallow: /*&min-price=    # ファセットナビゲーション(価格絞り込み下限) 
Crawl-delay: 5

User-agent: *            # その他のクローラー向けのルール
Disallow: /search?q=       # サイト内検索結果ページ
Disallow: /*?max-price=    # ファセットナビゲーション(価格絞り込み上限) 
Disallow: /*&max-price=    # ファセットナビゲーション(価格絞り込み上限) 
Disallow: /*?min-price=    # ファセットナビゲーション(価格絞り込み下限) 
Disallow: /*&min-price=    # ファセットナビゲーション(価格絞り込み下限) 

Sitemap:  https://example.com/sitemap_index.xml

robots.txt の文法にはグループ化や優先順位など分かりづらいものも多く、記述が増えていくほど思わぬ事故が起こりやすい状態になります。編集前にドキュメントに目を通しておきましょう。

Google による robots.txt の指定の解釈 | Google のクロール インフラストラクチャ  |  Crawling infrastructure  |  Google for Developers

robots.txtに正規表現を使っている

robots.txt ではJavaScriptやPythonのような正規表現は使えません。

たとえば、JavaScriptの正規表現であれば「拡張子.pdfで終わるページパス」を /.*\.pdf$ のように表現できますが、 robots.txtの場合、 /*.pdf$ と表現します。似ていますがドット記号とアスタリスク記号の意味が全く異なります。

記号robots.txt上での意味
. (ドット記号)特になし。ただのドット記号
* (アスタリスク記号)「ここに何が入ってもOK」という意味
$ (ダラー記号)URLの末尾

詳しくは Googleのドキュメント「Google による robots.txt の指定の解釈」 をご確認ください。

なお、コンピューターの世界で「正規表現」と言うと、主に「JavaScriptやPythonなどで使われている文字列検索や置換のためのパターン記法」を指しますが、形式言語のような学術の世界で言う正規表現は「決められた文字と、連接・選択・繰り返しなどを意味する記号を組み合わせて書き、その意味として『どんな文字列の集まりを表すか』を指定するための式」を指します。なので学術側の定義に立てば robots.txt で使われる「 *$ によるパターン指定」も正規表現の一種と呼ぶことができます。紛らわしいですね。

サブドメイン違いのページを制御しようとしている

https://example.com/robots.txt に記載されたルールはドメイン・プロトコルが一致する https://example.com のページに対してのみ有効であり、以下のようなページには影響を与えません。

  • https://shop.example.com/search/?q=t-shirts のようなサブドメイン違いのページ
  • https://img.example.com/image01234.png のようなサブドメイン違いのページ
  • http://example.com/aboutus/ のようなプロトコル違いのページ(https・http)

https://shop.example.com/search/?q=t-shirts をクロールブロックするためのルールは https://shop.example.com/robots.txt のURLで確認できる必要があります。

まとめ

robots.txt はとてもシンプルに見えますが、その役割を取り違えると、次のような問題を引き起こします。

  • セキュリティ対策のつもりで書いた設定が、実は何の防御にもなっていない
  • インデックスさせたくないページが、URL だけ検索結果に残り続ける
  • ページの描画に必要なリソースをブロックしてしまい、ページの評価や表示品質に悪影響が出る
  • 正規化や URL 統合のつもりの設定が、かえって挙動を複雑にする

実務では、次の点に気をつけることで robots.txt による事故を防ぐことができます。

アユダンテでは月1でニュースレターの配信を始めました

この記事を書いた人
$uname
西村 彰悟
デジタルマーケティングエンジニア
2020年に福岡の広告代理店からアユダンテに参加。タグマネ、Google Analytics, BQ、Tableau、SEOの技術支援などなど幅広く活躍中。キャンプ、コーヒー。休日は東京散策を楽しんでいる。
最近書いた記事
著書 [PR]