最新仕様網羅!RFC準拠のrobots.txt正しい記述方法とSEO施策

Are you want to translate this page to English? Please click this link to translate via ‘©Google Translate'!

みなさんこんにちは！　ガノー（Ganohr）です！　(≧▽≦)

皆さんは「robots.txt」の書き方を、正しく理解しているでしょうか?

また、robots.txtは、2022年よりRFC 9309として正式に仕様が策定されていることをご存知でしょうか?

robots.txtはSEO施策において重要であり、適切に作成・更新・管理することは大切です。

この記事では、RFCに準拠した正しいrobots.txtの書き方や、誤動作の少ないrobots.txtの書き方をSEO施策に絡めて解説します。

なお、この記事は非常に膨大な情報を扱っているため、目次から適宜読み進めて頂ければ幸いです。

robots.txtとは?

robots.txtは、ウェブサイト上のコンテンツを検索エンジン等の、機械的にウェブサイト上の情報を収集するソフトウェア≒ロボット（Crawler=クローラー、またはSpider=スパイダー、又は単にボットともいう。本記事ではボットと表記する）の挙動を制御するための基本仕様として『RFC9309』にて定義されている『‘Robots Exclusion Standard’（直訳するとロボット除外基準）』にて使用するファイルです。この仕様は2019年IETF（Internet Engineering Task Force、インターネット技術特別調査委員会）とGoogleにより標準化が進められ、2022年にRFC 9309として策定されました。

実際は1994年頃から2007・2008年頃までにほぼ仕様が決まっており、その仕様を踏襲した形で標準化されています。

https://www.robotstxt.org/robotstxt.html ... 外部サイトへアクセスwww.robotstxt.org

RFC 9309: Robots Exclusion ProtocolThis document specifies and extends the "Robots Exclusion Protocol" method originally defined by Martijn Koster in 1994 for service owners to control ... 外部サイトへアクセスdatatracker.ietf.org

拡張子が「.txt」になっている通り、中身は単なるテキストファイルです。

利点としては簡単な構造のため人間もボット側も把握がしやすい点があります。また一般的なボットの制御機構としては十分に利用方法が浸透している点も利点となります。

またSEO施策のなかでもrobots.txtは重要度が高く、その点も利点と言えるでしょう。

しかし、robots.txtには欠点があり「その仕様をまもらないロボットを取り締まる法律（やルール）がない」という点です。

ただし、これは回転寿司に悪戯をする輩が居ることを盾に、回転寿司チェーンに対して「いたずらに対する対策を行う義務を放棄してきたツケが回ってきた」などと避難するようなものです（と、筆者は考えているため）、これはそこまで気にする必要はありません。

またSEO施策のなかでも重要度が高く、記述が簡単な反面、誤った設定のまま運用されると致命的なミスを引き起こすことがあります。

要は、robots.txtの最大の欠点としては、

なのです。

robots.txtの定義例を他のサイトから参考にする

詳細な書き方を知る前に、実際の例を見てみましょう。

robots.txtはボット向けに公開された情報ですが、人間がアクセスすることも可能です。

robots.txtはSEOにおいても重要なため、各サイトがどのように制御しているのかを見ておくことは理にかなっています。

確認するには、ブラウザのアドレスバーへ確認したいドメイン名の後ろに「/robots.txt」をつけてアクセスします。

【robots.txtの参考例】

• https://www.google.com/robots.txt
• https://www.bing.com/robots.txt
• https://note.com/robots.txt
• https://ganohr.net/robots.txt

この他にも、普段自分がアクセスしているサイトのrobots.txtがどのように定義されていの確認してみるとよいでしょう。

robots.txtの仕様とRFC 9309

robots.txtは、2023年現在RFC 9309として仕様が定義されていますので、この仕様に準拠して記述する必要があります。

RFC 9309: Robots Exclusion ProtocolThis document specifies and extends the "Robots Exclusion Protocol" method originally defined by Martijn Koster in 1994 for service owners to control ... 外部サイトへアクセスdatatracker.ietf.org

この標準仕様を理解し、正しいrobots.txtを作成するよう気をつけましょう。

サイトをアクセスするボット・クローラーを制御するための「明確な仕様」であるため、必ず遵守する必要があります。

• robots.txtの基本仕様
• User-agentディレクティブ
• Disallow・Allowディレクティブ
• robots.txtの拡張的な仕様

robots.txtの基本仕様

はじめに基本仕様を解説します。

robots.txtはUTF8、BOM無しで定義する必要があります

まず、robots.txtはRFC 9309に準拠するためには、UTF8で保存しておく必要があります。

また、BOM（Byte Order Mark）は付けることができません。

しかし、仕様上はUTF8で保存することが規定されていますが、ボットが別のエンコーディングで保存されていることを検出した場合は、エンコーディングの問題を解決しても良いことになっています。

とはいえ、基本的には「UTF8のBOMなしで保存する」ことが前提になっています。

robots.txtの配置は、各ドメインの直下でなければならない

また、robots.txtは必ず一つのドメインごとに、その直下に配置せねばなりません。

例えば当サイトのドメイン「ganohr.net」であれば「https://ganohr.net/」や「https://lionmedia98.ganohr.net/」などのドメインを運用していますが、それぞれのサブドメインの直下である「https://ganohr.net/robots.txt」と「https://lionmedia98.ganohr.net/robots.txt」のようにそれぞれ配置せねばなりません。

また、「https://ganohr.net/blog/robots.txt」のように、サブディレクトリなどのルートディレクトリ以外には設置できません。

もしもレンタルサーバやレンタルブログがディレクトリ形式の間貸しにしか対応していない場合は、robots.txtは採用できないという訳です。

robots.txtのファイルサイズは500KiB程度までが下限となっている

加えて、robots.txtのファイルサイズは500KiB（500キビバイト、51万2,000バイト）を下限として、それ以上のサイズを解析できなければならないと定義されています。

しかし、

しています。

したがって、基本的には500KiB程度に収めておく方が賢明でしょう。

robots.txtは特定のボットのみが利用するわけではないため、仕様上保証される最下限を守っておく必要があります。

robots.txtのディレクティブとは何か? 実際のサンプルで確認しよう

では実際にrobots.txtの定義例を見てみましょう。

User-agent: Googlebot
Disallow: /tmp/
Allow: /

この例ではUser-agentディレクティブと、Disallowディレクティブと、Allowディレクティブが利用されています。

要するに‘ディレクティブ’（Directive）とは、「robots.txtにて指定される、ウェブサイトへアクセスしてくるボットへの命令」の意味だと思って問題ありません。

robots.txtに使用できるディレクティブは、ディレクティブ名の後ろに:を付ける必要があります。

また、robots.txtのディレクティブの前後や、:の前後には半角スペースや半角タブを含められます。その:の後ろに、ディレクティブの指定内容を記載します。

加えて、必ずディレクティブの内容を記載したら、行の終端に改行コードを付けます。

要は、

これは当たり前ですが、「robots.txt 書き方」などで検索して上位に表示されるサイトがrobots.txtを1行で書いていたり悲惨なので、念のため記述しておきます。

一応解説しておくとサンプルのコードが1行になってるのとかやばすぎなの。robots.txtの各ディレクティブは終端子として改行コード必須だし。
コード掲示時のミスならしょうが無いけど、去年何らかのリライトを行ったにもかかわらずこの状態で放置されてて、担当者が理解していないことがまるわかり…🥵 https://t.co/FpEitsozfm

— Ganohr C（ガノー・シー）🚳ひぐみん推しVTuber (@GanohrC) April 12, 2023

robots.txtには基本的なディレクティブとしては以下の2つがあります。

• User-agent：アクセス制御を行うボットの名称を指定する
• Disallow：特定のパスに対して、アクセスしてくるボットの接続を拒否する

この2つのディレクティブは、とても早い段階からサポートされました。

加えてRFC 9309で定義されているディレクティブとして

• Allow：特定のパスに対して、アクセスしてくるボットの接続を許可する

があります。

更には、RFC 9309には定義されていませんが、一部の有名なボットが認識できるディレクティブとして

• Crawl-delay：アクセスしてくるボットがサイトを巡回する際の巡回速度を指定する
• Sitemap：アクセスしてくるボットに対して、サイトマップのアドレスを通知する

があります。

robots.txtのディレクティブは大文字小文字は気にしなくて良い

robots.txtを記述する上で、様々なサンプルがインターネット上に存在します。

多くの場合、robots.txtのディレクティブは、User-agentのように、概ね先頭を大文字で記述し、残りを小文字で書くことが通例ですが、これはとくに決まりがあるわけではありません。

全部小文字でも、逆に大文字でもどちらでも問題ありません。

むしろRFCのドキュメント内では、全て小文字で記述されています。

したがって、自分が記述しやすく、読みやすい定義を行えば問題ありません。

ただし、各ディレクティブの「内容自体は、大文字小文字を識別する場合」があります。その点は注意してください。

robots.txtの空改行とコメント

robots.txtには適宜、空改行（改行のみの行）を入れたり、コメントを付与することで、より分かりやすい表記を行えます。

例えば、以下のような例です。

# 信頼できる検索エンジンは/tmp/以外のアクセスを許可
User-agent: Bingbot
User-agent: Googlebot
Disallow: /tmp/ # 一時的に生成されるため検索エンジンがアクセスする意味がない
# 信頼できないbotは全て遮断する
User-agent: *
Disallow: /

robots.txtでは、#記号の後ろに書かれた文字は全てコメントとして無視されます。

また、空改行は削除されて解析されるため、意味のある単位で空改行を挿入することで、可読性を高められます。

robots.txtをセキュリティ目的や、インデックスさせないことを目的で使用しない

robots.txtは「ボット運用者とサイト運用者が、双方の信頼関係に基づいて運用するプロトコル」です。したがって、「robots.txtにはセキュリティ対策のための定義を含めてはならない」という原則があります。

これはもっと噛み砕いて言えば、「ウェブサイトのHTMLやCSS、JavaScript上に現れるリソースに対してのみ定義するべき」という意味です。

例えばメール会員向けのログインURLがある場合に、そのURLをインデックスさせないことを目的としてrobots.txtに記載することは誤りです。

そうしたURLが既にインデックスされている場合は、各検索エンジンに対して「検索結果からの除外申請」を行うことで対策します。

あくまでrobots.txtは「これからボットがアクセスしようとする際の制限」であって、「既にアクセス済みの場合に対する制限ではない」のです。

また同様に、robots.txtをセキュリティ対策としても利用してはなりません。

User-agentディレクティブ

次に、それぞれのディレクティブを見ていきましょう。

まずは、User-agentディレクティブです。

User-agentに指定できるのは実際はボット名称であり、ウェブ技術でいうUAとは異なる

User-agentディレクティブは、その字面からHTTPプロトコルのUser-Agent（この記事では、以降、HTTPプロトコルのUser-AgentはUAと表記します）を指定すると思われがちですが、実際はボットの名称を指定します。

そのため、User-agentという字面に騙されず、「対処しようとしているボットの指定方法を、必ず調査する」ことが必要です。

例えば以下の記事を参考に、Bingbotを制御するためにrobots.txtを記述したい場合を想定してください。

Bingbotを拒否すべき3+1の理由と遮断方法!百害あって1利無しあなたは未だにBingの巡回を許可しているのでしょうか。Bingは7ヶ月で34万回クロールをしながらも、実際に集客した人数は500人にも満たないのが現状です。Bingを遮断すべき3つの理由とその遮断方法を解説します。 ... 続きを読むganohr.net2019-02-15

この記事ではBingbotの用いるUAとして以下の3つが提示されています。

Mozilla/5.0 (compatible; bingbot/2.0; +http://www.bing.com/bingbot.htm)


Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; bingbot/2.0; +http://www.bing.com/bingbot.htm) Chrome/W.X.Y.Z Safari/537.36


Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/W.X.Y.Z Mobile Safari/537.36  (compatible; bingbot/2.0; +http://www.bing.com/bingbot.htm)

またこの記事ではBingbotに対して5秒単位の再接続を許可する例として以下の例が示されています。

User-agent: bingbot
Crawl-Delay: 5
Disallow: /cgi-bin/
Disallow: /wp-admin/
Disallow: /.tmp/




User-agent: msnbot
Crawl-Delay: 5
Disallow: /cgi-bin/
Disallow: /wp-admin/
Disallow: /.tmp/

このように、robots.txtのUser-agentと、実際にボットがアクセス時に設定してくるUAとは同一ではないことがわかります。

実際に指定するボット名称は、各ボットの仕様を調べる必要があります。

User-agentに指定できるボット名称の調べ方

まず、ある程度信頼できる公開もとによるリストは以下に存在します。

The Web Robots Pages ... 外部サイトへアクセスwww.robotstxt.org

しかし、このリストは非常に古いため、あまり参考になりません。

例えばGooglebotやMSNBotは登録されていますが、最新のBingbotは登録されていません（なお、MSNBotは消失していますが、BingbotはBingbotの指定がrobots.txtに存在しない場合でも、MSNBotの指定があればそれに従います）。

とはいえ、まともに運用されているボットであればウェブサイトへアクセスしてくる際のUAにそのボットの情報や仕様を解説しているページのURLを含めています。

例)BingbotのUA

Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; bingbot/2.0; +http://www.bing.com/bingbot.htm) Chrome/W.X.Y.Z Safari/537.36

このUAの文字列からhttps://www.bing.com/bingbot.htmへアクセスすると、Bingbotの目的や制御方法を把握できます。

有名な検索エンジンのボット名称及び解説URL

【Google検索】

Google クローラー概要（ユーザー エージェント）| Google 検索セントラル  |  ドキュメント  |  Google for DevelopersGooglebot を含む Google クローラーの概要、ユーザー エージェント（User Agent）一覧を確認できます。robots.txt や robots メタタグのユーザー エージェントについても解説します。 ... 外部サイトへアクセスdevelopers.google.com

【Bing】

Bing Webmaster Tools ... 外部サイトへアクセスwww.bing.com

【Yandex】

https://yandex.com/support/webmaster/robot-workings/robot.html ... 外部サイトへアクセスyandex.com

【Baidu】

Baidu.jp、Baidu Spiderに関する御詫びと対処法についてBaidu.jp、Baidu Spiderに関する御詫びと対処法について ... 外部サイトへアクセスwww.baidu.jp

※ 23/04/13 現在、Baiduのボット名称は「BaiduSpider」です。なお、日本国内向けのBaidu検索はサービス終了しており、中国国内向けの検索に特化しています。そのため、日本国内向けのBaiduSpiderに関するリリースは殆どが消失しています。

※ UAにもボットの運用目的を示すURLを付与していないなど、アクセスを許容する理由が殆どありません。

User-agentはボットの指定の開始として認識される

また、User-agentディレクティブは、robots.txtにおける各ボットへの指定の開始であると認識されます。

例えば、以下の定義では、GooglebotとBingbotの定義を行っていますが、Googlebotへの指定は1～3行目、Bingbotへの指定は6～9行目にあります。

User-agent: Googlebot
Disallow: /cgi-bin/
Disallow: /.tmp/




User-agent: Bingbot
Disallow: /cgi-bin/
Disallow: /.tmp/
Disallow: /wp-admin/

先述の通り、改行やコメントは、解析時には除去されるため、実質的に以下のようになります。

User-agent: Googlebot
Disallow: /cgi-bin/
Disallow: /.tmp/
User-agent: Bingbot
Disallow: /cgi-bin/
Disallow: /.tmp/
Disallow: /wp-admin/

これを見ると、Googlebotへの制御内容が1～3行目なことには変わりませんが、Bingbotへの制御内容は4～7行目になっています。

そこから、「各ボットへの制御の開始をUser-agentディレクティブが担っている」ということが直感的に理解できるでしょう。

User-agentグループに対する一括指定

User-agentディレクティブは、複数のボットを一つのグループとして扱い、同じ制御内容を割り当てられます。

その場合は、複数のUser-agentを連続して記述します。

User-agent: Googlebot
User-agent: Bingbot
Disallow: /cgi-bin/
Disallow: /.tmp/
Disallow: /wp-admin/

こうすることで、GooglebotとBingbotに対して、一様に/cgi-bin/と/tmp/と/wp-admin/ディレクトリへのアクセスを禁止できます。

User-agentに指定するボット名称は大文字小文字を区別しない

また、User-agentディレクティブにて指定するボット名称は、大文字小文字を区別しません。

たとえば、

User-agent: bingbot
Crawl-Delay: 5
Disallow: /cgi-bin/
Disallow: /wp-admin/
Disallow: /.tmp/

と、

User-agent: BingBot
Crawl-Delay: 5
Disallow: /cgi-bin/
Disallow: /wp-admin/
Disallow: /.tmp/

は、

全く同じ内容と認識されます。

User-agentの「*」は定義されていない全てのボットを指定する

User-agentディレクティブには全てのボットを意味する*を指定できます。

例えば、以下の定義ではGooglebot以外のアクセスを禁止できます。

User-agent: Googlebot
Disallow: /cgi-bin/
Disallow: /wp-admin/
Disallow: /.tmp/


User-agent: *
Disallow: /

User-agentに同一のボットの定義を複数記述した場合は全てをマージして解析される

User-agentディレクティブで、同じボットの指定を複数行った場合、RFCの仕様としてはそれらを一つに結合（マージ）して解析します。

User-agent: Googlebot
Disallow: /cgi-bin/
Disallow: /wp-admin/


User-agent: Googlebot
Disallow: /.tmp/

この定義では、Googlebotは/cgi-bin/と/wp-admin/だけでなく、/tmp/もアクセスできません。

ただし、これはRFC 9309からの仕様であり、古いボットの一部では、最初に見つかった定義のみを対象とする場合や、最後に見つかった定義のみを対象とする場合があります。

したがって、このような「同じボットに対する制御をUser-agentディレクティブで多重に指定することは避けるべき」といえます。

User-agentには「-」か「_」か半角アルファベット以外は指定でき

User-agent: Googlebot/1.0
Disallow: /cgi-bin/
Disallow: /wp-admin/


User-agent: Googlebot/2.0
Disallow: /.tmp/


User-agent: Googlebot Image
Disallow: /

この定義は、(古い)Googlebot/1.0は/cgi-bin/と/wp-admin/にアクセスができず、新しいGooglebot/2.0の方は/tmp/にアクセスできず、Googlebot Imageは全てのアクセスを禁止しているように見えます。

しかし実際のRFC 9309の定義を読むと、User-agentディレクティブで指定できるのは「半角英字と-と_のみ」であるため、「全ての定義がGooglebotの定義としてはみなされず、本来アクセスして欲しくないディレクトリへアクセスを許す」ことになります。

robots.txtのDisallowとAllowディレクティブ

次に、DisallowディレクティブとAllowディレクティブを確認しましょう。

両者の意味は読んで字の如く「Disallow＝禁止」と「Allow＝許可」です。

DisallowとAllowディレクティブは、先頭一致でサイトのパスに対してのアクセス禁止やアクセス許可を指定します。また、このディレクティブの指定内容は大文字と小文字を識別します。

加えて、パスは必ず/から始める必要があります（後述の閑話休題を参照）。

これに違反する場合、そのディレクティブの指定は無視されます。

例えば以下の記述は「Googlebot」に対して、「/tmp/」ディレクトリや「/tmp」から始まるパスへのアクセスを禁止し、「/blog/」へのアクセスを許可します。

User-agent: Googlebot
Disallow: /tmp
Allow: /blog/

ちなみに、DisallowともAllowとも定義していないパスは、デフォルトでアクセス許可の状態であると認識されます（robots.txtも同様にデフォルトでアクセス許可となります）。

したがって、この定義のAllowディレクティブは意味のない定義になっています。

意味のあるAllowディレクティブの指定例としては、以下のような例です。

User-agent: Googlebot
Disallow: /
Allow: /blog/

これは「Googlebot」に対して全体のアクセス禁止をした後に、「/blog/」配下のパスに対してはアクセスを許可します。

このように、サイト全体へのアクセスを許可したり、禁止したいときは/だけを指定します。

DisallowとAllowは、各ボット及びグループに対する制御の指定開始とともに制御の指定終了と認識される

User-agentディレクティブがボットの指定の開始として認識されるように、DisallowディレクティブやAllowディレクティブは、各ボットへの制御の開始と認識されます。

User-agent: Googlebot
Disallow: /cgi-bin/
Disallow: /.tmp/




User-agent: Bingbot
Disallow: /cgi-bin/
Disallow: /.tmp/
Disallow: /wp-admin/

この例ではDisallow: /cgi-bin/が、User-agentディレクティブの直後に指定されています。

これにより、それ以降に続くDisallowディレクティブ及びAllowディレクティブが直上でUser-agentで指定されたボットに対する制御の開始と認識できるわけです。

逆に言えば、もしも、User-agentディレクティブが連続して記述されてしまうと、「複数のボットをグループとしたものと認識される」訳です。

要は、「User-agentディレクティブの次に現れたAllowやDisallowが単一のボットや複数のボットへの制御の指定開始となり、User-agentディレクティブ直前のAllowやDisallowがボットへの制御の指定終了を意味している」という訳です。

DisallowとAllowの代表的なパス指定例

Disallow:               # 効果のない定義（ただし、特殊な意味があるため後述）
Disallow: /cache/       # キャッシュは頻繁に更新されるため一般的に巡回不要


Allow: /*/index.php     # 全てのディレクトリのindex.phpへの巡回を許可する
Allow: /*/index.htm*    # 〃 index.htmやindex.htmlへの巡回を許可する


Allow: /*.png$          # 基本的にpngは巡回を許可する
Disallow: /*.png?trac   # しかしtracオプションパラメータのついたpngは巡回禁止


Disallow: *.gif$        # GIFは全て巡回禁止（厳密な仕様上は誤りだが…閑話休題を参照）

Disallow: /*.gif$

User-agent: *
Disallow: /*.jpg
Disallow: *.png
Disallow: spam
Disallow: /splog
Disallow: *hoge
Disallow: */huga

DisallowとAllowには定義順序は関係なく、定義の長いものが優先される

User-agent: Googlebot
Allow: /blog/
Disallow: /

先程の定義ではDisallowで/を指定して全体へのアクセスを禁止した後に、Allowで/blog/を許可することで、例外的に/blog/配下のアクセスを許可していました。

これは別に、定義する順番に関係があるわけではないのです。

実際は、仕様として「最も長い定義を優先する」ことが定義されているだけに過ぎません（このことを、robots.txtの仕様では「最も具体的な一致」と言います）。

とはいえ、この仕様はほぼ人間が理解する通りの仕様であるため、問題になることはまずありません(ただし運が悪いと問題が顕在化しますのでテストを忘れずに)。

同じ長さのパスをDisallowとAllowで指定した場合、Allowが優先される

先程は、DisallowディレクティブとAllowディレクティブの優先順位としては、長さをベースとして決定されることを解説しました。

しかし完全に同じ長さで複数のDisallowディレクティブとAllowディレクティブに適合する場合、Allowディレクティブの方を優先することが決まっています。

User-agent: GoogleBot
Allow: /wp-content/$


User-agent: Googlebot
Disallow: /wp-content/*


User-agent: Googlebot
Disallow: /wp-content**

この例では、Googlebotは/wp-content/ディレクトリにアクセスできます。

DisallowディレクティブおよびAllowディレクティブにて指定された文字列長は全て半角13文字(に無理やりしている)ため、Allowディレクティブが優先されるという訳です。

なお、指定するパスには、3つの特殊記号が使用できます。

Disallow及びAllowに指定できる3つの特殊記号―「%」・「$」・「*」

Disallowディレクティブ及びAllowディレクティブには以下の特殊記号を指定できます。

• %：URLエンコード（パーセントエンコーディング）用
• $：パスの終端を指定する
• *：パスの一部を省略して指定する

既に使用例はいくつか紹介していますが、より適切な例をいくつか示します。

User-agent: GoogleBot
Allow /%E3%83%A9%E3%83%BC%E3%83%A1%E3%83%B3/
Disallow /*/%E3%83%A9%E3%83%BC%E3%83%A1%E3%83%B3/

まず、この例はGooglebotに対して「/%E3%83%A9%E3%83%BC%E3%83%A1%E3%83%B3/」ディレクトリへのアクセスを許可しています。この「%E3%83%A9%E3%83%BC%E3%83%A1%E3%83%B3」は「ラーメン」という文字をURLエンコードした文字列です。

ここでは説明用にパーセントエンコーディングをデコードした結果で表記します。

User-agent: GoogleBot
Allow /ラーメン/
Disallow /*/ラーメン/

この例では、Googlebotは/ラーメン/ディレクトリ配下のパスへはアクセスできますが、サブディレクトリにある/ラーメン/ディレクトリにはアクセスできません。

例えば、/ラーメン/お勧め一覧.htmlというファイルを検索エンジンには公開しつつ、/会員向け/ラーメン/東京近郊のお勧め一覧.htmlといったページへのアクセスを拒否できます。

特に、こうした記事は部分部分で同じ内容を扱うことがあるため、そうした「複数の共通項目を持つ要素が重複コンテンツとして誤判定されないよう調整できる」という訳です。

これは例えば、登録会員向けの記事と、検索から訪れた非会員向けの記事をコントロールすることが可能になります。

こうした定義を全パターン記述することは現実的ではないため、うまく特殊記号を活用すると良いでしょう。

robots.txtの拡張的な仕様

次にRFC 9309に定義されていない拡張的な仕様を解説します。

なお、RFC 9309ではこの仕様に準拠したrobots.txtにおいても、標準仕様外のディレクティブを混在できます。

なぜなら、RFC 9309には以下の仕様が定義されているからです。

• robots.txtの解析中にエラーが起きた場合でも、エラーの起こっていない別の行の定義を遵守する必要があると定義されているため
• robots.txtにはもともと利用者オリジナルの定義が含まれることが想定されているため

とはいえ、この仕様は誤った記述をされた場合に重大なミスへつながることがあります（このミスは後述します）。

ひとまず、以下2つの拡張的な仕様を解説します。

• Crawl-delay：アクセスしてくるボットのレート制限を実施する
• Sitemap：アクセスしてくるボットにサイトマップを提供する

とはいえ、この拡張的な仕様についてはあまり効果がないため、採用しないことをおすすめします（理由は後述します）。

Crawl-delayディレクティブ

Crawl-delayディレクティブは、RFC 9309に定義されていないものの、認識するボットがかなり多いディレクティブです。

Crawl-delayはレート制限（Rate Limit）を実現するためのディレクティブであり、一度ボットがウェブサイトのコンテンツへアクセスした後に、再アクセスするまでの待機秒数を指定します。

例えば有名所であれば「BingBot（MSNBot）は2009年8月10付けで、Crawl-delayディレクティブを認識する」ようになりました。

Crawl delay and the Bing crawler, MSNBotSearch engines, such as Bing, need to regularly crawl websites not only  to  index new content, but also to check for content changes and removed cont ... 外部サイトへアクセスblogs.bing.com

ただし、Bingbotよりも重要度の高いGooglebotではCrawl-delayを採用していません。

Googlebot のクロールの割り当てについて  |  Google 検索セントラル ブログ  |  Google for Developers ... 外部サイトへアクセスdevelopers.google.com

BingbotはCrawl-delayに1～30の値を指定できます（範囲外は無指定と認識しますので注意）。

なお、

ことに注意してください。

この理由としては「レート制限は1秒でも遅すぎる」ことを根拠としています。

ただまあ、1秒で遅すぎるとか以前に、ちゃんと集客してから言えよって感じですが…。

Bingbotを拒否すべき3+1の理由と遮断方法!百害あって1利無しあなたは未だにBingの巡回を許可しているのでしょうか。Bingは7ヶ月で34万回クロールをしながらも、実際に集客した人数は500人にも満たないのが現状です。Bingを遮断すべき3つの理由とその遮断方法を解説します。 ... 続きを読むganohr.net2019-02-15

Sitemapディレクティブ

Sitemapディレクティブは、ロボット除外基準という仕様からは逸脱した存在です。

そのため、各種ディレクティブの構文は踏襲するものの、User-agentディレクティブなどの影響を受けないという特徴があります。

具体的には、Sitemapディレクティブはそれ単体で動作します。

そのため、ファイルのどこにでも記述でき、その効力を発揮します。

ファイルの先頭でも、ファイルの最後でも、あまつさえファイルの途中でも…です。

しかし、わかり易さという点で、必ずファイルの先頭か、ファイルの終端にのみ記述するべきです。

# Known Bad Bot
User-agent: trafficinstantly
User-agent: FreakOutAdsTxtBot
Crawl-delay: 30
Disallow: /
# Known Good Bot
User-agent: Googlebot
User-agent: Bingbot
Disallow: /cgi-bin/
# この定義は、別段 User-agentディレクティブには影響されず、単体で解釈される
Sitemap: https://ganohr.net/sitemap.xml

Sitemapディレクティブは完全に修飾されたサイトマップファイルのURL（要はアドレスバーに指定してアクセスできるURL）を指定します。

このとき、指定できるサイトマップのURLには特別な制限はありません。

そのためサブドメインや自身が管理するウェブサイトのサイトマップを一つのルートドメインに配置したrobots.txtに集約するといったことができます。

またSitemapディレクティブは複数の定義を行えます。

Sitemap.xmlには50MB制限があり、制限に引っかかる場合はSitemapを複数に分割する必要があります。

また、Sitemapは場合によってはカテゴリ別やタグなどのタクソノミーによって分割することがあるため、robots.txtにはそうした複数のサイトマップを記述できます。

Sitemap: https://ganohr.net/sitemap_index.xml
Sitemap: https://ganohr.net/sitemap_category_index.xml
Sitemap: https://ganohr.net/sitemap_tag_index.xml

ちなみに、SitemapディレクティブはRFC 9309でも拡張仕様の例として例示されています（とはいえ具体的な仕様は示されていません）。

また、GooglebotもBingbotも採用しており、Crawl-delayよりは指定する意味があるでしょう。

robots.txt の書き方、設定と送信 | Google 検索セントラル  |  ドキュメント  |  Google for Developersrobots.txt ファイルはサイトのルートにあります。robots.txt ファイルの作成方法、例、robots.txt のルールを紹介します。 ... 外部サイトへアクセスdevelopers.google.com

Bing Webmaster Tools ... 外部サイトへアクセスwww.bing.com

Craw-delay及びSitemapディレクティブは代替手段の利用を検討しよう

Crawl-delayディレクティブやSitemapディレクティブは別段必須という訳ではありません。

特にCrawl-delayはGooglebotが不採用であり、指定は完全に無視されます。

最も重要なことは、これらのディレクティブは、検索エンジン毎に「個別の指定方法が提供されている」という点です。

Googlebotへのレート制限を行いたいならサーチコンソールから制御できますし、同様にBingbotへのレート制限を行いたいならBing Web Master Toolで設定できます。

Google クローラーのクロール頻度を管理 | Google 検索セントラル  |  ドキュメント  |  Google for DevelopersGoogle のクロール頻度の高さが原因でサーバーに高負荷がかかっている時に、Googlebot のクロール頻度を下げる方法や、サイトのクロールを停止する方法を紹介します。 ... 外部サイトへアクセスdevelopers.google.com

Bing Webmaster Tools ... 外部サイトへアクセスwww.bing.com

Sitemapも同様に各検索エンジンで個別に指定できます。

サイトマップの作成と送信 | Google 検索セントラル  |  ドキュメント  |  Google for DevelopersGoogle は複数のサイトマップ形式をサポートしています。サイトマップの作り方、Google への送信方法について説明しています。 ... 外部サイトへアクセスdevelopers.google.com

Bing Webmaster Tools ... 外部サイトへアクセスwww.bing.com

したがって、Crawl-delayディレクティブやSitemapディレクティブを採用する場合は、別の代替手法が選択できない場合のみに留めることをおすすめします。

例えば、レンタルブログ等でサーチコンソールへのアクセス権がない場合でしょうか。…でもFTPは許可されている場面って相当なレアケースですね。

また、これらを採用する場合は、必ず次に示す「失敗しないrobots.txtの書き方」を実践してください。

失敗しないrobots.txtの書き方

よくあるrobots.txtの誤りで、致命的なトラブルになる事もあるのにあまり知られていない仕様の紹介で連ツイート。
誤りは表に出ることが少ないので日本語で実例紹介を見たことが無いのですが、公共の面も持つサイトでの誤りを発見したので注意喚起意図で実例を紹介します。(続く

— 辻正浩 Masahiro Tsuji (@tsuj) October 29, 2022

続き)そしてこのサイトは、トップから302で/guest/index.phpに飛ばしています。/guest/はブロックですのでトップがindexに残りつつクロールは出来ない状態となります。
以上、トップページがrobots.txtでブロックされている挙動になる理由でした。
(続く

— 辻正浩 Masahiro Tsuji (@tsuj) October 29, 2022

辻正浩氏はSEOの専門家として有名であり、2022年10月29日に意図しないCrawl-delayディレクティブ指定による不具合を報告しています。

これに対する最も重要な解決方法としては「Googlebot」や「Bingbot」用の公式のテスターを使用することです。

対して、この情報を扱うサイトでは、多くがRFCの仕様を理解せずに情報発信をしているため、様々な嘘や誤謬が広まっています。

あなたも同じミスをするかも？ robots.txtのミスで予想外のページをクロール禁止していた悲劇【SEO情報まとめ】―Web担

あなたの予想とは違うGooglebotのrobots.txt解釈

辻氏が発見したサイトが設置しているrobots.txtには、Googlebotが処理しないCrawl-delayがあった。GooglebotがCrawl-delayを処理しないだけなら問題は起きなかったのだが、Googlebotは「その命令が書かれた行をないものとして扱う」ため、前後のUser-agent指定の関係上、その後に出てくるクロール拒否の指定が自分に向けた指示だと解釈してしまったのだ。

　： 中略

sitemap指定も同様に「ないものとして扱う」動きをする点に注意してほしい（今回の事例では利用していないようだが）。

解決策（根本）robots.txtにDisallow／Allow以外を書くときは下に書く

robots.txtの修正案はいくつかあるが、いちばんのオススメは「ファイル全体の構成を変える」ことだ。

具体的にはファイル全体の構成として、まずDisallowとAllow関連の指定を行い、Crawl-delay関連の指定はその後にもってくる形にするのだ。

#-----------------------------------------

Disallow・Allow系の指定をこの下に置く
-----------------------------------------



User-agent: Bingbot
Disallow: /guest/
Disallow: /content /


……





-----------------------------------------
Crawl-delayの指定をこの下に置く
このブロックにはDisallow系の指定は一切記載しない
-----------------------------------------



User-agent: *
Crawl-delay: 10


User-agent: Bingbot
Crawl-delay: 120


……

　：　後略

この記事は色々と誤っており、せっかく役に立つ一次情報が、二次発信で誤った情報が多数追加されており困ったものです。

まず、GooglebotはSitemapディレクティブを認識します（既に参考URLを提示済み）。

そして、このCrawl-delayを認識しない問題はUser-agent: *の指定を先頭に書き、Disallow: /dummy/やDisallow:だけの行を書いておくだけで回避できます。

そもそも、対処例として掲示されているサンプルでは不具合が起こります（本当に検証した上で情報発信しているのか、良識を疑います）。

やはり、こうした中途半端な情報ソースは鵜呑みにしてはなりません。

「User-agent: *」の指定はファイルの前方にて行う

まず、robots.txtの記載による多くの問題は、User-agent: *がファイルの後半にて行っていることに起因します。

何度も解説してはいますが、User-agent: *は個別指定していない各種ボットに対して、一括で指定を行うものです。

ここで思い出してほしいのが「User-agentディレクティブの指定の終わりを示すのは、AllowディレクティブまたはDisallowディレクティブのみである」という仕様です。

要するに、一括でボットに指定する内容が後半にあると、前方にあるUser-agentのグループしていの一部であると認識されなくなります。

実際、Google等はrobots.txtをこの書き方にしています。

なお、Bingはこの書き方にはなっていませんが後述する方法で対処しています。

仕様を理解した上でUser-agent: *を後半に記述するのは、特に間違いではありません。

全てのUser-agentに対してDisallowにてハニーポットURLを記載する

そして、RFC 9309に「User-agentディレクティブの終わりを示す専用のディレクティブが存在しない」（ように見える）ことが誤動作を引き起こしています。

これはハニーポットURLを記載することで、悪意のあるボットの検出とブロックを手助けすることが目的ではありません（そうした利用も可能ですが）。

一番の理由としては、誤ったrobots.txtの定義における副次的なミスを防ぐ効果がある点です。

もっとも重要なことは、「User-agentディレクティブの指定の終了は、AllowやDisallowディレクティブしかできない」という仕様上の制限を克服できることです。

例えば以下の内容は、Bingbotは正常にクロールできるのに対し、Googlebotは全てのアクセスが遮断されます。

User-agent:Bingbot
User-agent:Googlebot
Crawl-delay: 1


User-agent: *
Crawl-delay: 30

これにハニーポットURLを付与すれば、こうした誤動作は起こりません。

User-agent:Bingbot
User-agent:Googlebot
Crawl-delay: 1
Disable: /cgi-bin/


User-agent: *
Crawl-delay: 30
Disallow:/

そしてこれはUser-agent: *を先頭に出す方が、多くのボットに適切です。

User-agent: *
Crawl-delay: 30
Disallow: /


User-agent:Bingbot
User-agent:Googlebot
Crawl-delay: 1
Disallow: /cgi-bin/

ハニーポットURLを指定するのが嫌なら（というか面倒なら）Disallow: /dummy/と定義しても良いです。

あくまで

です。

ハニーポットURLを設置したくない場合は「Disallow:」のみを記述してもOK

ハニーポットURLを設置することに難色がある場合、単にDisallow:とのみ書かれた行を指定することも可能です。

これはRFC 9309でも仕様としては定義されており、URLは/で始めることが規定されていますが、BNF（バッカス・ナウア記法）を読み解くと「Disallow:やAllow:のみの行が許可されている」ことに気づくでしょう（Bingのrobots.txtは、この仕様を利用しています）。

ただし、実際はRFC 9309ではDisallow:やAllow:のみの定義を許容していながら、その仕様例や挙動に対して特別な解説を行っていません。

そのため純粋に仕様へ準拠するのであればDisallow:やAllow:のみの行を利用するよりも、実際にアクセスを禁止したり許容する定義（ハニーポット、またはdummy等）を記述しておく方がより安全でしょう。

作成したrobots.txtが正しいか検証（テスト）する

これまでRFC 9309に準じた記述方法と、不具合を減らすためのrobots.txtの書き方を解説してきました。

そして必ず「Bingbotの検証はBingが正式に公開しているテスターを、Googlebotの検証はGoogleが正式に公開しているテスターを使って検証する」ことを省略しないでください。

Google Search ConsoleSearch Console でプロパティに関する Google 検索結果データを監視できます。 ... 外部サイトへアクセスwww.google.com

Bing Web マスター ツールBing Web マスター ツールにログインまたはサインアップして、あなたのサイトの検索パフォーマンスを向上しましょう。無料のレポートやツール、リソースにアクセスできます。 ... 外部サイトへアクセスwww.bing.com

私はこの記事を執筆するにあたり、何度もこれらのツールを活用しました。

せっかく便利なツールが公開されているわけですから、ぜひ活用したいものです。

作成したrobots.txtを検索エンジンへ登録・更新する

BingもGoogle検索も、それぞれのテスターにrobots.txtを登録したり更新するための機能がついています。

ですので、更新や登録には別段特殊な方法は必要ありません。

なお、一般的にはサイトのルートディレクトリにrobots.txtを設置すれば数日のうちに、自動的に更新が認識されます。

ただし、各検索エンジンの公開するツールを用いるほうがより迅速に対応できます。

また各種ツールには、実際にrobots.txtをボットに取得させる機能があるため、.htaccess等の指定ミスによって各ボットがrobots.txtを巡回できないような場面でもそのことを即座にを把握できます。

しかし、もしもrobots.txtを巡回できないような場合だと、その現象を把握することは非常に困難です（最近のSearch consoleやBing Web Master Toolはアラートメッセージを飛ばしてくれますが）。

そのため、やはり

と良いでしょう。

最後に

ウェブ担当者は、可能な限り最善をつくすべきです。

robots.txtはSEOにおいては非常に重要な役割を担います。

その反面、結局robots.txtは拘束力がないため、色々な実装が乱立しており混乱を招いてきました。

これまであくまで慣例として運用されてきたrobots.txtがRFC 9309として仕様が明確化されたことで、ウェブ担当者の混乱は減ったと言ってよいでしょう。

しかし、実際はRFCを読めない、または、読む時間を取れないウェブ担当者は多くいます。

そうした方々に、本記事が少しでも役に立てば幸いです。

そして、悲しいかなrobots.txtはSEOに重要なため、検索結果には有象無象の出鱈目な記事が五万とあります。

それらの記事より「少しでも役に立った」と感じた方は、是非ブックマークをして、この記事を社内や知人にでも紹介してください。SNSで紹介していただいてもありがたいです。

以上、ガノー（Ganohr）でした!