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://www.example.com/robots.txt |
サブドメイン上の robots.txt は、そのサブドメインに対してのみ有効です。
有効:
無効:
|
https://example.com/folder/robots.txt |
有効な robots.txt ファイルではありません。クローラーは、サブディレクトリ内の robots.txt ファイルを確認しません。 |
https://www.exämple.com/robots.txt |
IDN はその Punycode バージョンと同等です。RFC 3492(リンク先は英語)もご覧ください。 有効:
無効:
|
ftp://example.com/robots.txt |
有効:
無効:
|
https://212.96.82.21/robots.txt |
ホスト名に IP アドレスが指定されている robots.txt は、ホスト名にその IP アドレスを使用するクロールに対してのみ有効です。その IP アドレスでホストされているすべてのウェブサイトに対して自動的に有効にはなりません(ただし、robots.txt ファイルを共有している場合は、共有しているホスト名でも使用できます)。
有効:
無効:
|
https://example.com:443/robots.txt |
標準のポート番号(HTTP の場合は 有効:
無効:
|
https://example.com:8181/robots.txt |
標準以外のポート番号の robots.txt ファイルは、そのポート番号で利用可能なコンテンツに対してのみ有効です。
有効:
無効:
|
エラーと 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 の Google は、robots.txt ファイルの論理リダイレクト(フレーム、JavaScript、メタ リフレッシュ タイプのリダイレクト)には従いません。 |
4xx (client errors) |
|
5xx (server errors) |
robots.txt リクエストに対してサーバーから明確な応答がないため、Google は一時的な クロールを一時的に停止する必要がある場合は、サイト上のすべての URL で
Google は、サイトが誤って構成されているためにページ不明の |
その他のエラー | 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 は次のフィールドをサポートしています。
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/ |
一致:
不一致:
|
/*.php |
一致:
不一致:
|
/*.php$ |
一致:
不一致:
|
/fish*.php |
一致:
不一致:
|
ルールの優先順位
robots.txt ルールと URL との一致判定を行う際、クローラーはルールのパスの長さに基づいて最も限定的なルールを使用します。ワイルドカードを含むルールが競合する場合は、最も制限の少ないルールを使用します。
以下に、URL に対して Google のクローラーがどのルールを適用するかについて、具体例を示します。
例 | |
---|---|
https://example.com/page |
allow: /p disallow: /
適用するルール: |
https://example.com/folder/page |
allow: /folder disallow: /folder
適用するルール: |
https://example.com/page.htm |
allow: /page disallow: /*.htm
適用するルール: |
https://example.com/page.php5 |
allow: /page disallow: /*.ph
適用するルール: |
https://example.com/ |
allow: /$ disallow: /
適用するルール: |
https://example.com/page.htm |
allow: /$ disallow: /
適用するルール: |