robots.txtの一致判定は「後に書いた行が勝つ」仕組みではありません。適用対象のAllowとDisallowを比較し、基本的にはより具体的に一致するパスが優先されます。RFC 9309では、一致するパス長が最も長いルールを最も具体的なものとして扱い、同等のAllowとDisallowならAllowを優先することが示されています。
Googleも実務上同じ最長一致の考え方を案内し、パスルールで*と$をサポートしています。
* と $ の意味
*：0文字以上の文字列に一致$：URLの末尾を示す
例：PDFで終わるパスを対象にする場合。
User-agent: *
Disallow: /*.pdf$
末尾の$があるため、.pdfで終わるパスに絞られます。一方、次はより広く一致します。
Disallow: /*.pdf
末尾の*は不要なことが多い
Googleの一致方法では、次の2つは実質的に同じ範囲を対象にします。
Disallow: /private
Disallow: /private*
/privateは先頭一致するため、/private.htmlや/private/pageも対象になり得ます。ディレクトリだけを意図するなら/private/のように末尾スラッシュを使うと意図が明確です。
行順ではなく最長一致
User-agent: *
Disallow: /products/
Allow: /products/public/
/products/public/widgetには両方が一致しますが、/products/public/の方が具体的なのでAllowが勝ちます。順序を逆にしても、行が後だから勝つという考え方にはなりません。
User-agent: *
Allow: /products/public/
Disallow: /products/
CSSのような「後勝ち」を前提にrobots.txtを設計しないでください。
同じ具体性で競合した場合
RFC 9309では同等のAllowとDisallowが一致した場合、Allowを使うことが推奨されています。Googleも同じ具体性では制限の弱い結果を選ぶと説明しています。
ただし、運用では同点に依存するより、ルールをより明確に書く方が安全です。
パス値は大小文字を区別する
フィールド名User-agentやDisallowは大小文字を区別しませんが、パス値は区別されます。
Disallow: /Admin/
と
Disallow: /admin/
は同じとは限りません。アプリが両方を提供する場合は両方をテストしてください。
クエリパラメータとワイルドカード
ECサイトでは次のようなルールを見かけます。
User-agent: *
Disallow: /*?sort=
ただし複数パラメータの順序が変わると想定外の一致になる場合があります。robots.txtだけで無制限なファセットURLを管理するのではなく、内部リンク、canonical、URL設計も一緒に整理してください。
複雑な正規表現のように使わない
robots.txtのワイルドカードは完全な正規表現ではありません。安定したディレクトリを単純なプレフィックスで表現できるなら、その方が保守しやすいです。
Disallow: /internal-search/
は、意図が分かりにくい複雑なパターンの組み合わせよりレビューしやすくなります。
実URLでテストする
次のルールなら、許可されるURLとブロックされるURLの両方を用意します。
User-agent: *
Disallow: /reports/
Allow: /reports/public/
Disallow: /*.csv$
確認例：
/reports/private/quarterly/reports/public/overview/downloads/data.csv/downloads/data.csv?preview=1/REPORTS/private/quarterly
これでプレフィックス、大小文字、末尾アンカー、重複ルールの思い込みを公開前に見つけられます。
推奨手順
- まず「何を許可・拒否したいか」を文章で書く
- 最小のプレフィックスルールで表現する
- 必要な場合だけ
*や$を追加 - 許可・拒否のテストURLを作る
- 構文を検証
- 対象User-agentで各URLをテスト
- 公開後の
/robots.txtを再取得 - ログで実際のクロールを確認
要点は、行順より具体性が重要ということです。ワイルドカードは必要なときだけ使い、複数ルールが同じURLへ一致する場合は必ず実URLで判定を確認してください。
