Googleの動画シリーズ第2回のテーマはrobots.txt
Google Search Central の公式 YouTube チャンネルは2026年10月21日、Gary Illyes（ゲイリー・イリーズ）氏と Cherry Prommawin（チェリー・プロムマウィン）氏による動画シリーズ「The Non-Canonical Cabinet」の第2回「What can you actually put in a robots.txt?」を公開しました（出典：What can you actually put in a robots.txt? – YouTube）。第1回の URL 編の最後で予告されていたとおり、今回は「robots.txt には何を書けるのか」が主題です。
動画説明文の結論は「robots.txt は美しく退屈なままにしておこう（Keep your robots.txt beautifully boring）」で、次回は 404 ステータスコードを扱うと予告されています（出典：同上）。
本記事は2026年10月26日時点の情報に基づきます。発言内容は動画の英語字幕（YouTube の自動生成字幕、2026年10月26日取得）で確認し、Search Engine Roundtable の報道とあわせて整理しました。動画での発言と、Google の公式ドキュメントや RFC 9309 で裏取りできる事実は区別して書いています。
動画で語られた内容
動画は約9分半で、Search Engine Roundtable も2026年10月21日付の記事で内容を文字起こしとともに報じています（出典：Google On robots.txt Rules For AI Crawlers, Emojis, International URLs & More – Search Engine Roundtable）。字幕で確認した発言の要点は次のとおりです。位置は動画のタイムスタンプで、引用の日本語訳は筆者によるものです（出典：What can you actually put in a robots.txt? – YouTube）。
| 位置 | テーマ | 発言の要点 |
|---|---|---|
| 00:57 | 何のためのファイルか | ルートに置く単純なテキストファイルで、自動化されたボットに「してよいこと・いけないこと」を伝える。ルールは「検索エンジンのクローラー、AI の学習用クローラー、その他の行儀のよいクローラー」に適用され、Googlebot などはコンテンツを見る前にこのファイルを確認する。「これはすべてインターネット標準 RFC 9309 で定義されている」 |
| 02:10 | ASCII アート | # で始まる行は無視されるので「技術的には可能」。ただし「robots.txt は個人的なキャンバスではない」 |
| 03:13 | 書き間違い・独自ルール | パーサーは1行ずつ読み、user-agent・allow・disallow・sitemap を探す。理解できない行は「黙って捨てて次へ進む」ため、「don’t crawl secret page」と書いても守りたいページはクロールされうる |
| 04:04 | user-agent トークン | 「使えるのは英字とダッシュだけ」。絵文字はマルチバイトの UTF-8 文字なので収まらない。英語以外の文字も不可 |
| 04:54 | パスの絵文字・非英語文字 | Google のパーサーは自動で変換して処理できるが、他社や古いクローラーは混乱するかもしれない。「エンコード済みの形を使うべき」 |
| 07:06 | 生成 AI | 「robots.txt はアクセスの希望を伝えるプロトコル（access-preference protocol）」で、「クロール後にデータをどうするかは規定しない」。特定の AI クローラーを止めるには固有の user-agent トークンを正確に書く必要があり、独自の名前は「パーサーがゴミ箱に捨てる」 |
| 08:26 | まとめ | （1）Googlebot を含む行儀のよいクローラーは robots.txt でクロールを制限する、（2）RFC 9309 に従って書く、（3）絵文字や非英語文字のパスはパーセントエンコーディングを使う。締めくくりは「退屈にしておこう。美しく退屈に（Let’s keep it boring. Beautifully boring）」 |
同記事の筆者 Barry Schwartz（バリー・シュワルツ）氏は自身の見解として、「クロールの制御と AI 学習のポリシーは分けて考える」「robots.txt はセキュリティ機構ではない」と付け加えています（出典：同上）。
公式ドキュメントと RFC 9309 ではどう書かれているか
認識するフィールドと無視される行
Google の「Google による robots.txt の指定の解釈」は、サポートするフィールドとして user-agent・allow・disallow・sitemap の4つを挙げ、crawl-delay などほかのフィールドはサポートしないとしています。日本語版には「allow、disallow、user-agent 以外のルールは、robots.txt パーサーによって無視されます」とあり、英語版（Last updated 2026-10-23 UTC）も無効な行を無視すると明記しています。# 以降の無視や 500 KiB の上限も同じページの記述です（出典：Google による robots.txt の指定の解釈、最終更新日 2026-09-11 UTC）。
user-agent トークンの文字種
RFC 9309 の 2.2.1 節は、プロダクトトークンは「大文字・小文字の英字、アンダースコア（_）、ハイフン（-）のみを含まなければならない（MUST）」と定め、照合は大文字・小文字を区別しないとしています（出典：RFC 9309: Robots Exclusion Protocol）。動画では「英字とダッシュだけ（letters and dash）」と述べられていますが、RFC の原文ではアンダースコアも許容されています。実務上は公開されているトークンをそのまま写せばよく、結論は変わりません。
パスのパーセントエンコーディング
RFC 9309 は、ファイルを UTF-8 で書くことを必須とし（2.3 節）、パスに含まれる ASCII 範囲外のオクテットは比較前にパーセントエンコードしなければならないと定めています（2.2.2 節）。Google のドキュメントも同じ例で、「Disallow: /foo/bar/ツ と Disallow: /foo/bar/%E3%83%84 がパーサーによって同等に扱われる」と説明しています（出典：Google による robots.txt の指定の解釈）。Google に限れば日本語のまま書いても結果は同じです。動画がエンコード済みの形を勧める理由は、Google のパーサーは自動で変換できても「他社や古いクローラーは混乱するかもしれない」ためだと説明されています（動画 5:57 付近）。
robots.txt は非公開化やセキュリティの手段ではない
Google の「robots.txt の概要」は、robots.txt は「基本的にはサイトに対するクローラーのトラフィックを管理するために使用され」るもので、「Google にウェブページが表示されないようにするためのメカニズムではありません」と述べ、検索結果に出したくない場合は noindex やパスワード保護を案内しています。制約事項として、クローラーによって構文解釈が異なること、他サイトからリンクされていればインデックスに登録される可能性があることも挙げています（出典：robots.txt の概要、最終更新日 2025-12-18 UTC）。RFC 9309 も「Robots Exclusion Protocol は有効なコンテンツセキュリティ対策の代替ではない」と明記しています（出典：RFC 9309: Robots Exclusion Protocol 3 節）。
AI クローラーと Google-Extended
Google は Google-Extended というトークンを用意しています。公式ドキュメントによると、これは「スタンドアロンのプロダクト トークン」で、Google がクロールしたコンテンツを、Gemini アプリと Vertex AI の Gemini API を支える次世代 Gemini モデルの学習や、Gemini アプリでのグラウンディング、Vertex AI の Google 検索によるグラウンディングに使ってよいかを管理するものです。個別の HTTP リクエスト ユーザー エージェント文字列は持たず、既存の Google のユーザー エージェント文字列でクロールされ、robots.txt のトークンが制御の役割を果たします。「Google-Extended が Google 検索でのサイトの登録に影響したり、Google 検索でのランキング シグナルとして使用されたりすることはありません」と明記されています（出典：Google の一般的なクローラーの一覧、最終更新日 2026-10-19 UTC）。なお同ページは AI による概要（AI Overviews）や AI モードには触れていません。
日本語サイト運営者が実務でどう読むか
1. 日本語パスはエンコード済みの形で書く
/製品一覧/ のような日本語パスをブロックする場合、Google は日本語のまま処理しますが、他のクローラーまで考えるなら %E8%A3%BD%E5%93%81... のようなパーセントエンコード済みの形で書くのが動画と RFC の推奨です。アクセスログやアドレスバーからコピーした URL はエンコード済みのことが多いので、その形を使い、サイト内で統一してください。
2. user-agent に日本語や独自名を書いても意味がない
トークンに使えるのは英字・ハイフン（RFC ではアンダースコアも）だけです。「Googlebot（画像）」のような日本語混じりや独自の「AIボット」といった名称はどのクローラーにも一致せず無視されます。トークンは公式ドキュメントで確認し、綴りを正確に写してください（出典：Google の一般的なクローラーの一覧）。
3. 「書けば効く」と思い込まず、レポートで確認する
自然文のルールは無視されます。綴りやエンコードの形を確認し、Search Console の robots.txt レポートで Google が読み取った内容を確かめてください。公式ドキュメントは、UTF-8 のテキストファイルとしてサイトホストのルートに置くこと、ルールは大文字・小文字を区別することも示しています（出典：robots.txt の書き方、設定と送信、最終更新日 2025-11-26 UTC）。基本の書き方は「robots.txtの記述方法」も参照してください。
4. AI クローラーは「何を止めたいか」で分ける
検索結果には出しつつ Gemini の学習やグラウンディングには使わせたくないなら Google-Extended を Disallow します（検索の掲載や順位には影響しないと公式に明記）。一方 Googlebot を Disallow すれば検索結果への掲載にも影響します。取得済みデータの扱いやルールを守らないクライアントは robots.txt では制御できないため、利用規約や認証など別の手段と組み合わせる必要があります。
5. 非公開にしたいものは認証や noindex で
管理画面や会員限定ページを「見せたくない」目的で robots.txt に書くのは逆効果になりえます。robots.txt は誰でも閲覧でき、リンクされていればインデックスされる可能性も残ります。検索結果から外すなら noindex、見せたくないならアクセス制御、robots.txt はクロール負荷の管理に使う、という役割分担が公式ドキュメントの立場です。
まとめ
第2回の結論は「robots.txt は RFC 9309 に従って退屈に書く」でした。Google が認識するのは user-agent・allow・disallow・sitemap の4フィールドで、理解できない行は黙って無視されます。user-agent トークンは英字とハイフン（RFC ではアンダースコアも）だけ、パスの日本語や絵文字はパーセントエンコード済みの形で書くのが安全です。そして robots.txt が制御するのはクロールまでで、取得済みデータの利用やルールを守らないクライアントは止められません。日本語サイトでは、日本語パスのエンコード、トークンの正確な綴り、Google-Extended の役割、非公開化を robots.txt に頼らないことの4点を押さえておきましょう。本記事は2026年10月26日時点の動画説明文・報道・公式ドキュメントに基づいています。
