Robots.txt の仕様

概要

このドキュメントでは、Google での robots.txt ファイルの処理方法について説明します。robots.txt ファイルを使用すると、Google のウェブサイト クローラが一般公開のウェブサイトをクロールしてインデックスに登録する方法を制御できます。

変更内容

Google は 2019 年 7 月 1 日、robots.txt プロトコルをインターネット標準にするための取り組みに着手していることを発表しました。これらの変更はこのドキュメントに記載されています。

変更のリスト

変更内容は次のとおりです。

• インターネット ドラフト固有の言語であるため、このドキュメントの「要件言語」セクションを削除しました。
• Robots.txt は、すべての URI ベースのプロトコルを受け付けるようになりました。
• Google では、5 ホップ数以上リダイレクトします。ルールがまだ取得されていないため、5 ホップ数以上リダイレクトが行われ、robots.txt が見つからない場合は robots.txt の 404 として処理されます。2xx を返す HTML コンテンツに基づく robots.txt ファイルの論理リダイレクト（フレーム、JavaScript、meta refresh タイプのリダイレクト）の処理は推奨されません。最初のページの内容は該当するルールの検索に使用されます。
• 5xx の場合、robots.txt が 30 日以上アクセスできないときは、robots.txt の最後のキャッシュ コピーが使用されます。使用できない場合、クロール制限は適用されません。
• Google は承認されなかったリクエストや不完全なデータをサーバーエラーとして処理します。
• 「レコード」は、必要に応じて「行」または「ルール」と呼ばれるようになりました。
• Google では、<field> 要素の単純なエラーやタイプミス（「user-agent」を「useragent」と入力するなど）の処理はサポートしていません。
• Google では、現在、500 KiB のサイズ制限があり、その上限を超えたコンテンツは無視されます。
• 正式な構文を、RFC5234 に従った有効な Augmented Backus-Naur Form（ABNF）になるように更新し、robots.txt の UTF-8 文字が対象となるようにしました。
• 「グループ」がより短く、より重要なものになるように、定義を更新しました。空のグループの例を追加しました。
• 廃止された Ajax クロール スキームへの参照を削除しました。

基本的な定義

定義
クローラ	ウェブサイトをクロールするサービスやエージェントです。一般に、クローラは、標準的なウェブブラウザでアクセスできるコンテンツを公開するホストの既知の URL に、自動的に繰り返しアクセスします。（既存のクロール済みページにあるリンクや、サイトマップ ファイルなどのさまざまな手段によって）新しい URL が検出されると、これらの URL も同じ方法でクロールされます。
ユーザーエージェント	特定のクローラまたは複数のクローラを識別するための手段です。
ディレクティブ	robots.txt ファイルで指定される、クローラまたはクローラのグループに対して適用されるガイドラインのリストです。
URL	RFC 1738 に定義されている Uniform Resource Locator です。
Google 固有	この要素は Google の robots.txt 実装に固有のもので、他の団体には該当しない場合があります。

適用性

このドキュメントで規定されているガイドラインは、Google のすべての自動クローラに適用されます。ユーザーに代わってエージェントが URL にアクセスする場合（たとえば、翻訳、手動登録フィード、マルウェア解析の目的で）は、このガイドラインを適用する必要はありません。

ファイルの場所と有効範囲

robots.txt ファイルは、ホストの最上位ディレクトリに配置し、適切なプロトコルとポート番号を使用してアクセスできなければなりません。通常、robots.txt で受け付けられるプロトコルは URI ベースです。Google 検索専用（たとえば、ウェブサイトのクロール）も「http」と「https」です。http と https では、HTTP の条件付きでない GET 要求を使用して、robots.txt ファイルを取得します。

Google 固有: Google では、FTP サイトの robots.txt ファイルも受け付けて適用します。FTP ベースの robots.txt ファイルは、匿名ログインを使用して FTP プロトコル経由でアクセスされます。

robots.txt ファイルに列記されているディレクティブは、ファイルがホストされているホスト、プロトコル、ポート番号に対してのみ適用されます。

robots.txt ファイルの URL は、他の URL と同様に、大文字と小文字が区別されます。

有効な robots.txt の URL の例

robots.txt の URL の例
http://example.com/robots.txt	有効: http://example.com/ http://example.com/folder/file 無効: http://other.example.com/ https://example.com/ http://example.com:8181/ 一般的なケースです。他のサブドメイン、プロトコル、ポート番号に対しては無効です。同じホスト、プロトコル、ポート番号のすべてのサブディレクトリ内のファイルすべてに対して有効です。
http://www.example.com/robots.txt	有効: http://www.example.com/ 無効: http://example.com/ http://shop.www.example.com/ http://www.shop.example.com/ サブドメイン上の robots.txt は、そのサブドメインに対してのみ有効です。
http://example.com/folder/robots.txt	有効な robots.txt ファイルではありません。クローラは、サブディレクトリ内の robots.txt ファイルを確認しません。
http://www.müller.eu/robots.txt	有効: http://www.müller.eu/ http://www.xn--mller-kva.eu/ 無効: http://www.muller.eu/ IDN はその Punycode バージョンと同等です。RFC 3492（リンク先は英語）もご覧ください。
ftp://example.com/robots.txt	有効: ftp://example.com/ 無効: http://example.com/ Google 固有: FTP リソース用の robots.txt を使用します。
http://212.96.82.21/robots.txt	有効: http://212.96.82.21/ 無効: http://example.com/（212.96.82.21 でホストされている場合でも無効） ホスト名に IP アドレスが指定されている robots.txt は、ホスト名にその IP アドレスを使用するクロールに対してのみ有効です。その IP アドレスでホストされているすべてのウェブサイトに対して自動的に有効にはなりません（ただし、robots.txt ファイルを共有している場合は、共有しているホスト名でも使用できます）。
http://example.com:80/robots.txt	有効: http://example.com:80/ http://example.com/ 無効: http://example.com:81/ 標準のポート番号（http の場合は 80、https の場合は 443、ftp の場合は 21）は、既定のホスト名と同等です。[portnumbers] もご覧ください。
http://example.com:8181/robots.txt	有効: http://example.com:8181/ 無効: http://example.com/ 標準以外のポート番号の robots.txt ファイルは、そのポート番号で利用可能なコンテンツに対してのみ有効です。

HTTP 結果コードの処理

一般に、robots.txt ファイルを取得した場合の結果は次の 3 種類です。

• 完全許可: すべてのコンテンツをクロールできます。
• 完全不許可: クロールできるコンテンツはありません。
• 条件付き許可: robots.txt 内のディレクティブによって、特定のコンテンツをクロールできるかどうかが決まります。

HTTP 結果コードの処理
2xx（成功）	「条件付き許可」のクロールで結果が成功であることを示す HTTP 結果コード。
3xx（リダイレクト）	HTTP/1.0 の RFC 1945 で定義されているように、5 ホップ数以上リダイレクトした後、停止して 404 として処理します。許可されていない URL への robots.txt のリダイレクトの処理は推奨されません。ルールがまだ取得されていないため、5 ホップ数以上リダイレクトが行われ、robots.txt が見つからない場合は robots.txt の 404 として処理されます。 2xx を返す HTML コンテンツに基づく robots.txt ファイルの論理リダイレクト（フレーム、JavaScript、meta refresh タイプのリダイレクト）の処理は推奨されません。最初のページの内容は該当するルールの検索に使用されます。
4xx（クライアント エラー）	すべての 4xx エラーは同じように扱われ、有効な robots.txt ファイルが存在しないものとみなされます。制限はないものとみなされます。これは、クロールの「完全許可」です。 これには、401「未認証」と 403「禁止」の HTTP 結果コードも含まれます。
5xx（サーバーエラー）	サーバーエラーは一時的なエラーとみなされ、クロールが「完全不許可」になります。 リクエストは、サーバーエラー以外の HTTP 結果コードを取得するまで再試行されます。503（サービス利用不可）エラーでは、頻繁に再試行が行われます。robots.txt が 30 日以上アクセスできない場合、robots.txt の最後のキャッシュ コピーが使用されます。利用できない場合、Google ではクロールの制限はないものとみなします。 クロールを一時的に停止するには、503 HTTP 結果コードを提供することをおすすめします。 Google 固有: サイトが誤って構成されているためにページ不明の 404 ではなく 5xx が返されていると判断できる場合、Google はそのサイトからの 5xx エラーを 404 エラーとして扱います。
要求の失敗または不完全なデータ	DNS またはネットワークの問題（タイムアウト、無効な応答、接続のリセットやハングアップ、HTTP チャンクのエラーなど）が原因で robots.txt ファイルを取得できない場合の処理は、サーバーエラーとして扱われます。
キャッシュ	通常、robots.txt のコンテンツがキャッシュされている期間は最長で 24 時間ですが、（たとえば、タイムアウトや 5xx エラーのために）キャッシュされているバージョンを更新できないと、さらに長くキャッシュされる場合があります。キャッシュされている応答は、他のクローラと共有できます。Google は max-age Cache-Control（リンク先は英語）HTTP ヘッダーに基づいて、キャッシュ期間を延長または短縮する場合があります。

ファイル形式

予期されるファイル形式は、UTF-8 でエンコードされた書式なしテキストです。 このファイルは、CR、CR/LF、または LF で区切られた行で構成されます。

有効な行だけが考慮され、他のすべての内容は無視されます。たとえば、取得したドキュメントが HTML ページである場合、有効なテキスト行のみが使用され、その他は警告やエラーなしで破棄されます。

文字エンコードで UTF-8 のサブセットではない文字が使用される場合、ファイルの内容が誤って解析される場合があります。

robots.txt ファイルの冒頭に省略可能な Unicode BOM（バイトオーダー マーク）がある場合は、無視されます。

有効な各行は、フィールド、コロン、値で構成されます。スペースは省略可能です（ただし、読みやすくするために使用することが推奨されます）。「#」文字を使用して、ファイル内の任意の場所にコメントを含めることができます。コメントの開始から行の終わりまでのすべての内容は、コメントとして処理され、無視されます。一般的な形式は <field>:<value><#optional-comment> です。行の先頭と末尾にある空白文字は無視されます。

<field> 要素では大文字と小文字が区別されません。<value> 要素は、<field> 要素によっては大文字と小文字が区別される場合があります。

<field> 要素の単純なエラーやタイプミス（「user-agent」を「useragent」と入力するなど）の処理はサポートされていません。

適用される最大ファイルサイズは、クローラごとに異なる場合があります。最大ファイルサイズを超えた内容は無視されます。Google では、現在、500 KiB のサイズ制限があります。robots.txt ファイルのサイズを減らすには、robots.txt ファイルのサイズが大きいディレクティブを統合します。たとえば、除外したマテリアルを別のディレクトリに配置します。

正式な構文または定義

RFC 5234 に記述されている、Augmented Backus-Naur Form（ABNF）の説明です。

robotstxt = *(group / emptyline)
group = startgroupline                    ; We start with a user-agent
        *(startgroupline / emptyline)     ; ... and possibly more user-agents
        *(rule / emptyline)               ; followed by rules relevant for UAs

startgroupline = *WS "user-agent" *WS ":" *WS product-token EOL

rule = *WS ("allow" / "disallow") *WS ":" *WS (path-pattern / empty-pattern) EOL

; parser implementors: add additional lines you need (for example, Sitemaps), and
; be lenient when reading lines that don’t conform. Apply Postel’s law.

product-token = identifier / "*"
path-pattern = "/" *(UTF8-char-noctl)    ; valid URI path pattern; see 3.2.2
empty-pattern = *WS

identifier = 1*(%x2d / %x41-5a / %x5f / %x61-7a)
comment = "#" *(UTF8-char-noctl / WS / "#")
emptyline = EOL
EOL = *WS [comment] NL         ; end-of-line may have optional trailing comment
NL = %x0D / %x0A / %x0D.0A
WS = %x20 / %x09

; UTF8 derived from RFC3629, but excluding control characters
UTF8-char-noctl = UTF8-1-noctl / UTF8-2 / UTF8-3 / UTF8-4
UTF8-1-noctl    = %x21 / %x22 / %x24-7F  ; excluding control, space, '#'
UTF8-2          = %xC2-DF UTF8-tail
UTF8-3          = %xE0 %xA0-BF UTF8-tail / %xE1-EC 2( UTF8-tail ) /
                  %xED %x80-9F UTF8-tail / %xEE-EF 2( UTF8-tail )
UTF8-4          = %xF0 %x90-BF 2( UTF8-tail ) / %xF1-F3 3( UTF8-tail ) /
                  %xF4 %x80-8F 2( UTF8-tail )
UTF8-tail       = %x80-BF

行とルールのグループ化

1 つ以上のユーザーエージェント行の後に 1 つ以上のルールが続きます。グループはユーザーエージェント行またはファイルの末尾で終了します。最後のグループにはルールがないため、暗黙的にすべてを許可します。

グループの例:

user-agent: a
disallow: /c

user-agent: b
disallow: /d

user-agent: e
user-agent: f
disallow: /g

user-agent: h

次の 4 つの異なるグループが指定されています。

• 「a」の 1 つのグループ
• 「b」の 1 つのグループ
• 「e」と「f」の両方の 1 つのグループ
• 「h」の 1 つのグループ

最後のグループ（グループ「h」）を除き、各グループには独自のグループメンバー行があります。最後のグループ（グループ「h」）は空です。読みやすくするために、省略可能な空白文字と空白行を使用しています。

ユーザーエージェントの優先順位

特定のクローラに対して有効なグループは 1 つだけです。クローラは、合致する最も限定的なユーザーエージェントのグループを探すことで、正しい行グループを特定しなければなりません。クローラは、他のすべてのグループを無視します。ユーザーエージェントでは、大文字と小文字が区別されます。一致しないテキストはすべて無視されます（たとえば、googlebot/1.2 と googlebot* は両方とも googlebot と同等です）。robots.txt ファイル内のグループの順序は関係ありません。

特定のユーザー エージェントに対して複数のグループが宣言されている場合、特定のユーザー エージェントに適用されるグループのすべてのルールが単一のグループに統合されます。

例

例 1

次のような robots.txt ファイルについて考えます。

      user-agent: googlebot-news
      (group 1)

      user-agent: *
      (group 2)

      user-agent: googlebot
      (group 3)
    

クローラによる関連するグループの選択は次のとおりです。

クローラごとに使用するグループ
ニュース用 Googlebot	使用するグループは group 1 です。最も限定的なグループのみが使用され、他はすべて無視されます。
Googlebot（ウェブ）	使用するグループは group 3 です。
画像用 Googlebot	使用するグループは group 3 です。googlebot-images という限定的なグループはないため、より一般的なグループが使用されます。
ニュース用 Googlebot（画像をクロールする場合）	使用するグループは group 1 です。これらの画像はニュース用 Googlebot によってクロールされるため、ニュース用 Googlebot グループのみが使用されます。
Otherbot（ウェブ）	使用するグループは group 2 です。
Otherbot（ニュース）	使用するグループは group 2 です。関連するクローラに対するエントリがある場合でも、エントリが有効になるのは明確に一致する場合のみです。

例 2

次のような robots.txt ファイルについて考えます。

      user-agent: googlebot-news
      disallow: /fish

      user-agent: *
      disallow: /carrots

      user-agent: googlebot-news
      disallow: /shrimp
    

クローラが特定のユーザー エージェントに関連するグループを統合する方法は次のとおりです。

      user-agent: googlebot-news
      disallow: /fish
      disallow: /shrimp

      user-agent: *
      disallow: /carrots
    

Google クローラとユーザーエージェント文字列もご覧ください。

グループメンバー ルール

このセクションでは、標準的なグループメンバー ルールのみを説明します。これらのルールは、クローラに対する「ディレクティブ」とも呼ばれます。これらのディレクティブは、directive: [path] の形式で指定します（[path] は省略可能です）。既定では、指定されたクローラに対するクロールの制限はありません。[path] がないディレクティブは無視されます。

[path] の値が指定されている場合、値は（同じプロトコル、ポート番号、ホストおよびドメイン名を使用して）robots.txt ファイルを取得したウェブサイトのルートからの相対パスとして認識されます。パスの値の最初には、ルートを意味する「/」を付けなければなりません。path では大文字と小文字が区別されます。詳しくは、後述の「path の値に基づく URL の一致」をご覧ください。

不許可

disallow ディレクティブは、指定されたクローラがアクセスしてはならないパスを指定します。パスを指定しない場合、このディレクティブは無視されます。

使用方法:

disallow: [path]

許可

allow ディレクティブは、指定されたクローラがアクセスできるパスを指定します。パスを指定しない場合、このディレクティブは無視されます。

使用方法:

allow: [path]

パスの値に基づく URL の一致判定

サイト上の特定の URL にルールが適用されるかどうかは、パスの値に基づいて決定されます。ワイルドカードを除き、パスを使用して URL の冒頭（および、同じパスで始まる有効なすべての URL）と一致するかどうか判定されます。パスには、7 ビット ASCII 文字以外の文字を、UTF-8 文字または RFC 3986（リンク先は英語）に従って % 記号でエスケープされ UTF-8 でエンコードされた文字として指定できます。

Google、Bing などの主要な検索エンジンでは、パスの値として、限られた形式の「ワイルドカード」をサポートしています。サポートしているものは次のとおりです。

• * は 0 個以上の有効な文字を示します。
• $ は URL の末尾を示します。

パスの一致の例
/	ルートおよびその下位にあるすべての URL が一致します。
/*	/ と同じです。末尾のワイルドカードは無視されます。
/fish	一致: /fish /fish.html /fish/salmon.html /fishheads /fishheads/yummy.html /fish.php?id=anything 一致しない: /Fish.asp /catfish /?id=fish 大文字と小文字が区別されます。
/fish*	/fish と同じです。末尾のワイルドカードは無視されます。 一致: /fish /fish.html /fish/salmon.html /fishheads /fishheads/yummy.html /fish.php?id=anything 一致しない: /Fish.asp /catfish /?id=fish
/fish/	末尾の「/」は、このフォルダ内のすべてに一致することを示します。 一致: /fish/ /fish/?id=anything /fish/salmon.htm 一致しない: /fish /fish.html /Fish/Salmon.asp
/*.php	一致: /filename.php /folder/filename.php /folder/filename.php?parameters /folder/any.php.file.html /filename.php/ 一致しない: /（/index.php にマップされている場合でも一致しない） /windows.PHP
/*.php$	一致: /filename.php /folder/filename.php 一致しない: /filename.php?parameters /filename.php/ /filename.php5 /windows.PHP
/fish*.php	一致: /fish.php /fishheads/catfish.php?parameters 一致しない: /Fish.PHP

Google がサポートする非グループメンバー行

Google、Bing などの主要な検索エンジンは、sitemaps.org で定義される sitemap をサポートしています。

使用方法:

sitemap: [absoluteURL]

[absoluteURL] にはサイトマップ、サイトマップ インデックス ファイル、または同等の URL を指定します。この URL は robots.txt ファイルと同じホスト上でなくてもかまいません。複数の sitemap エントリを指定できます。非グループメンバー行であるため、特定のユーザーエージェントには関連付けられません。すべてのクローラが使用できます（不許可に指定されているクローラを除く）。

グループメンバー行の優先順位

グループメンバー レベルでは、特に allow ディレクティブと disallow ディレクティブの場合、[path] エントリの長さに基づく最も具体的なルールは、より具体的でない（短い）ルールよりも優先されます。ワイルドカードを含むルールが競合する場合は、最も制限の少ないルールが使用されます。

例
http://example.com/page	allow: /p disallow: / 判定結果: allow
http://example.com/folder/page	allow: /folder disallow: /folder 判定結果: allow
http://example.com/page.htm	allow: /page disallow: /*.htm 判定結果: undefined
http://example.com/	allow: /$ disallow: / 判定結果: allow
http://example.com/page.htm	allow: /$ disallow: / 判定結果: disallow

robots.txt のマークアップのテスト

Google では、robots.txt のマークアップをテストするための 2 つのオプションを用意しています。

1. Search Console の robots.txt テスター。
2. Google 検索でも使用されている、Google のオープンソースの robots.txt ライブラリ。