Google による robots.txt の指定の解釈

Google の自動クローラーは Robots Exclusion Protocol（REP）をサポートしています。つまり、Google のクローラーは、クロールする前に対象サイトの robots.txt をダウンロードして解析し、そのサイトのどの部分をクロールできるかについての情報を抽出します。この REP は、ユーザーが管理するクローラー（フィードの購読など）や、ユーザーの安全性を高めるためのクローラー（マルウェア解析など）には適用されません。

このページでは、Google による REP の解釈について説明します。元の標準については、RFC 9309 をご覧ください。

robots.txt ファイルとは

サイトのセクションがクローラーにアクセスされないようにするには、robots.txt ファイルを作成して、適切なルールを含めます。robots.txt ファイルとは、どのクローラーにサイトのどの部分へのアクセスを許可するかを記述した、シンプルなテキスト ファイルです。たとえば、example.com の robots.txt ファイルは次のようになります。

# This robots.txt file controls crawling of URLs under https://example.com.
# All crawlers are disallowed to crawl files in the "includes" directory, such
# as .css, .js, but Google needs them for rendering, so Googlebot is allowed
# to crawl them.
User-agent: *
Disallow: /includes/

User-agent: Googlebot
Allow: /includes/

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

robots.txt を初めて使用する場合は、まず robots.txt の概要をご覧ください。robots.txt ファイルを作成するためのヒントもご確認ください。

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

robots.txt ファイルは、サイトの最上位ディレクトリに配置し、サポート対象プロトコルでアクセスできるようにする必要があります。robots.txt ファイルの URL では、他の URL と同様に、大文字と小文字が区別されます。Google 検索の場合、サポート対象プロトコルは HTTP、HTTPS、FTP です。HTTP、HTTPS の場合、クローラーは HTTP の条件付きでない GET リクエストで robots.txt ファイルを取得します。FTP の場合は、匿名ログインによって標準の RETR (RETRIEVE) コマンドを使用します。

robots.txt ファイルに記述したルールは、robots.txt ファイルをホストするホスト、プロトコル、ポート番号のみに適用されます。

有効な robots.txt の URL の例

次の表に、robots.txt の URL と有効な URL パスの例を示します。 列 1 は robots.txt ファイルの URL です。列 2 では、robots.txt ファイルが適用されるドメインと適用されないドメインを例示しています。

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

エラーと HTTP ステータス コードの処理

robots.txt をリクエストした際にサーバーから返される HTTP ステータス コードによって、Google のクローラーによる robots.txt ファイルの扱い方は異なります。次の表には、Googlebot による HTTP ステータス コードに応じた robots.txt ファイルの扱い方がまとめられています。

エラーと HTTP ステータス コードの処理
2xx (success)	成功を示す HTTP ステータス コードが返されると、Google のクローラーはサーバーが提供する robots.txt の処理に進みます。
3xx (redirection)	Google は、RFC 1945 に定義されているとおり、少なくとも 5 ホップ数以上リダイレクトした後で停止し、robots.txt の 404 として処理します。リダイレクト チェーンのいずれかの URL が許可されていない場合も、クローラーはリダイレクトが原因でルールを取得できないため、同様に処理します。 Google は、robots.txt ファイルの論理リダイレクト（フレーム、JavaScript、メタ リフレッシュ タイプのリダイレクト）には従いません。
4xx (client errors)	429 以外の 4xx のエラーが返されると、Google のクローラーは有効な robots.txt ファイルが存在しないものとみなします。つまり、Google はクロールの制限はないものとみなします。 クロール頻度を制限する目的で 401 および 403 ステータス コードを使用しないでください。4xx ステータス コード（429 を除く）はクロール頻度に影響しません。 クロール頻度を制限する方法については、こちらをご覧ください。
5xx (server errors)	robots.txt リクエストに対してサーバーから明確な応答がないため、Google は一時的な 5xx および 429 のサーバーエラーと解釈し、サイトが完全に許可されていない場合と同様に処理します。Google は、サーバーエラー以外の HTTP ステータス コードを取得するまで robots.txt ファイルのクロールを試行します。503 (service unavailable) エラーの場合、再試行が頻繁に行われます。robots.txt に 30 日以上アクセスできない場合、Google は robots.txt の最後のキャッシュ コピーを使用します。使用できない場合、Google はクロールに対する制限はないと見なします。 クロールを一時的に停止する必要がある場合は、サイト上のすべての URL で 503 HTTP ステータス コードを返すことをおすすめします。 Google は、サイトが誤って構成されているためにページ不明の 404 ではなく 5xx が返されていると判断できる場合、そのサイトからの 5xx エラーを 404 エラーとして扱います。たとえば、5xx ステータス コードを返すページのエラー メッセージが「ページが見つかりません」の場合、Google はそのステータス コードを 404 (not found) と解釈します。
その他のエラー	DNS またはネットワークの問題（タイムアウト、無効な応答、接続のリセットや遮断、HTTP チャンクのエラーなど）が原因で robots.txt ファイルを取得できない場合は、サーバーエラーとして扱われます。

キャッシュ

Google は、通常 robots.txt ファイルの内容を最大 24 時間キャッシュに保存しますが、（たとえば、タイムアウトや 5xx エラーが原因で）その内容を更新できないと、さらに長く保存する場合があります。キャッシュされている応答は、他のクローラーと共有できます。 Google は max-age Cache-Control（リンク先は英語）HTTP ヘッダーに基づいて、キャッシュ期間を延長または短縮する場合があります。

ファイル形式

robots.txt ファイルは、UTF-8 エンコードされた書式なしテキスト ファイルでなければならず、行の区切りには CR、CR/LF、LF のいずれかを使用する必要があります。

Google は、robots.txt ファイルの先頭の Unicode Byte Order Mark（BOM）など、ファイル内の無効な行は無視し、有効な行のみを使用します。たとえば、ダウンロードした内容が robots.txt ルールではなく HTML であった場合、Google はその内容を解析してルールを抽出し、他はすべて無視します。

同様に、robots.txt ファイルの文字エンコードが UTF-8 でない場合、Google が UTF-8 範囲外の文字を無視した結果、robots.txt ルールが無効と解釈される可能性があります。

Google は現在、robots.txt のファイルサイズの上限を 500 KiB としています。最大ファイルサイズを超えた内容は無視されます。robots.txt ファイルのサイズを減らすには、サイズが増大する原因となっているルールを統合します。たとえば、除外したマテリアルを別のディレクトリに配置します。

構文

robots.txt の有効な行は、フィールド、コロン、値で構成されます。スペースは省略可能です（ただし、読みやすくするために使用することが推奨されます）。行の先頭と末尾にある空白文字は無視されます。コメントを含めるには、コメントの前に # 文字を付けます。# 文字以降はすべて無視されることに注意してください。一般的な形式は <field>:<value><#optional-comment> です。

Google は次のフィールドをサポートしています（crawl-delay などの他のフィールドはサポートしていません）。

• user-agent: ルールを適用するクローラーを指定します。
• allow: クロールを許可する URL パス。
• disallow: クロールを許可しない URL パス。
• sitemap: サイトマップの完全な URL。

allow フィールドと disallow フィールドは、「ルール」（またはディレクティブ）とも呼ばれます。ルールは、常に rule: [path] の形式で指定します（[path] は省略可能です）。既定では、指定されたクローラーに対するクロールの制限はありません。クローラーは、[path] がないルールを無視します。

[path] の値を指定する場合、この値は（同じプロトコル、ポート番号、ホスト名、ドメイン名を使用して）robots.txt ファイルを取得したウェブサイトのルートからの相対パスにします。パスの値は、ルートを意味する「/」で始める必要があります。大文字と小文字は区別されます。詳しくは、パスの値に基づく URL の一致判定をご覧ください。

user-agent

user-agent 行には、どのクローラーにルールを適用するかを指定します。robots.txt ファイルで使用できる user-agent 文字列については、Google のクローラーとユーザー エージェント文字列の一覧をご覧ください。

user-agent 行の値では、大文字と小文字は区別されません。

disallow

disallow ルールは、（disallow ルールと同じグループの）user-agent 行で指定したクローラーにアクセスを許可しないパスを指定します。パスを指定しない場合、クローラーはルールを無視します。

Google は、クロールが許可されていないページのコンテンツをインデックスに登録することはできませんが、URL をインデックスに登録して、スニペットなしで検索結果に表示することはできます。インデックス登録をブロックする方法をご覧ください。

disallow ルールの値では、大文字と小文字が区別されます。

使用方法:

disallow: [path]

allow

allow ルールは、指定したクローラーにアクセスを許可するパスを指定します。パスを指定しない場合、ルールは無視されます。

allow ルールの値では、大文字と小文字が区別されます。

使用方法:

allow: [path]

sitemap

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

sitemap フィールドの値では、大文字と小文字が区別されます。

使用方法:

sitemap: [absoluteURL]

[absoluteURL] の行は、サイトマップまたはサイトマップ インデックス ファイルの場所を指定します。 プロトコルやホストを含む完全修飾 URL でなければなりませんが、URL エンコードされている必要はありません。この URL は robots.txt ファイルと同じホスト上でなくてもかまいません。複数の sitemap フィールドを指定できます。サイトマップ フィールドは特定のユーザー エージェントに関連付けられていないため、すべてのクローラーが使用できます（クロールが許可されていない場合を除く）。

次に例を示します。

user-agent: otherbot
disallow: /kale

sitemap: https://example.com/sitemap.xml
sitemap: https://cdn.example.org/other-sitemap.xml
sitemap: https://ja.example.org/テスト-サイトマップ.xml

行とルールのグループ化

複数のユーザー エージェントに適用するルールは、各クローラーの user-agent 行を繰り返すことでグループ化できます。

次に例を示します。

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 つのグループ。

グループの技術的な説明については、REP の 2.1 節をご覧ください。

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

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

ユーザー エージェントに対して複数のグループが宣言されている場合、特定のユーザー エージェントに適用されるグループのすべてのルールが内部的に 1 つのグループに統合されます。特定のユーザー エージェントのグループとグローバル グループ（*）は結合されません。

例

user-agent フィールドの一致判定

user-agent: googlebot-news
(group 1)

user-agent: *
(group 2)

user-agent: googlebot
(group 3)

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

クローラーごとに使用するグループ
Googlebot-News	group 1 が最も限定的なグループであるため、googlebot-news は group 1 に従います。
Googlebot（ウェブ）	googlebot は group 3 に従います。
Googlebot Storebot	Storebot-Google には限定的なグループがないため、Storebot-Google は group 2 に従います。
Googlebot-News（画像をクロールする場合）	画像をクロールする場合、googlebot-news は group 1 に従います。googlebot-news は Google 画像検索の画像をクロールしないため、group 1 のみに従います。
Otherbot（ウェブ）	その他の Google クローラーは group 2 に従います。
Otherbot（ニュース）	ニュース コンテンツをクロールするものの googlebot-news としては識別されない Google クローラーは、group 2 に従います。関連するクローラーに対するエントリがある場合でも、エントリが有効になるのは明確に一致する場合のみです。

ルールのグループ化

robots.txt ファイルに特定のユーザー エージェントに関連するグループが複数ある場合は、Google のクローラーが内部的にグループを統合します。次に例を示します。

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

allow、disallow、user-agent 以外のルールは、robots.txt パーサーによって無視されます。つまり、次の robots.txt スニペットは 1 つのグループとして扱われるため、user-agent a と b の両方が disallow: / ルールの影響を受けます。

user-agent: a
sitemap: https://example.com/sitemap.xml

user-agent: b
disallow: /

クローラーが robots.txt ルールを処理する際、sitemap 行は無視されます。 たとえば、クローラーは上記の robots.txt スニペットを以下のように解釈します。

user-agent: a
user-agent: b
disallow: /

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

サイト上の特定の URL にルールを適用するかどうかは、allow ルールと disallow ルールのパスの値に基づいて決定されます。これは、クローラーが取得しようとしている URL のパス コンポーネントとルールを比較することによって行われます。パスには、7 ビット ASCII 文字以外の文字を、UTF-8 文字または RFC 3986（リンク先は英語）に従って % 記号でエスケープされ UTF-8 でエンコードされた文字として指定できます。

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

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

次の表は、さまざまなワイルドカード文字が解析にどのように影響するかを示しています。

パスの一致の例
/	ルートおよびその下位にあるすべての URL が一致します。
/*	/ と同じです。末尾のワイルドカードは無視されます。
/$	ルートのみが一致します。下位レベルの URL はクロールが許可されます。
/fish	/fish で始まるすべてのパスが一致します。一致判定では大文字と小文字が区別されます。 一致: /fish /fish.html /fish/salmon.html /fishheads /fishheads/yummy.html /fish.php?id=anything 不一致: /Fish.asp /catfish /?id=fish /desert/fish
/fish*	/fish と同じです。末尾のワイルドカードは無視されます。 一致: /fish /fish.html /fish/salmon.html /fishheads /fishheads/yummy.html /fish.php?id=anything 不一致: /Fish.asp /catfish /?id=fish /desert/fish
/fish/	/fish/ フォルダ内のすべての項目が一致します。 一致: /fish/ /fish/?id=anything /fish/salmon.htm 不一致: /fish /fish.html /animals/fish/ /Fish/Salmon.asp
/*.php	.php を含むすべてのパスが一致します。 一致: /index.php /filename.php /folder/filename.php /folder/filename.php?parameters /folder/any.php.file.html /filename.php/ 不一致: /（/index.php にマップされている場合でも一致しない） /windows.PHP
/*.php$	.php で終わるすべてのパスが一致します。 一致: /filename.php /folder/filename.php 不一致: /filename.php?parameters /filename.php/ /filename.php5 /windows.PHP
/fish*.php	/fish と .php をこの順序で含む任意のパスが一致します。 一致: /fish.php /fishheads/catfish.php?parameters 不一致: /Fish.PHP

ルールの優先順位

robots.txt ルールと URL との一致判定を行う際、クローラーはルールのパスの長さに基づいて最も限定的なルールを使用します。ワイルドカードを含むルールが競合する場合は、最も制限の少ないルールを使用します。

以下に、URL に対して Google のクローラーがどのルールを適用するかについて、具体例を示します。

例
https://example.com/page	allow: /p disallow: / 適用するルール: allow: /p。より限定的であるため。
https://example.com/folder/page	allow: /folder disallow: /folder 適用するルール: allow: /folder。複数のルールが競合する場合、Google は最も制限の少ないルールを使用するため。
https://example.com/page.htm	allow: /page disallow: /*.htm 適用するルール: disallow: /*.htm。ルールパスが長く、URL 内のより多くの文字と一致し、より限定的であるため。
https://example.com/page.php5	allow: /page disallow: /*.ph 適用するルール: allow: /page。複数のルールが競合する場合、Google は最も制限の少ないルールを使用するため。
https://example.com/	allow: /$ disallow: / 適用するルール: allow: /$。より限定的であるため。
https://example.com/page.htm	allow: /$ disallow: / 適用するルール: disallow: /。allow ルールはルート URL にのみ適用されるため。