Cloudflareがrobots.txtへ追加するContent Signalsを公開後に確認した記録

public/robots.txtはリポジトリで管理しているが、公開URLで受け取る本文まで同じとは限らない。2026年9月11日にhttps://app-hacks.net/robots.txtの実レスポンスを確認すると、管理対象のSitemap指定の前にCloudflare Managed contentというコメント付きのブロックが追加されていた。ここでは、確認できた文字列だけを記録する。

リポジトリ管理分と公開レスポンスを分ける

リポジトリのファイルは次の内容である。Sitemapの管理責任はサイト側にあり、Astro Sitemap integrationが生成するURLと一致させる。

User-agent: *
Allow: /

Sitemap: https://app-hacks.net/sitemap-index.xml

一方、公開レスポンスにはCloudflareのコメントと複数のUser-agent規則が追加され、その中に次の行があった。

Content-Signal: search=yes,ai-train=no,use=reference

この行の意味やクローラーへの効果は、本記事では推測しない。重要なのは、ローカルのpublic/robots.txtだけを読んで公開内容を断定しないこと、CDN経由の最終レスポンスを別途確認することだ。

確認方法と判断理由

公開URLをHTTPクライアントで取得し、ステータス、Content-Type、本文を確認する。次にリポジトリのpublic/robots.txtと比較し、サイトが管理するSitemap行が残っているか、意図しない変更がないかを見る。管理外の付加行を削除する設定があるかどうかは、この確認だけから推測しない。

robots.txtはSitemapの場所を伝えるファイルであり、Sitemapそのもの、ページのcanonical、検索結果の表示を置き換えるものではない。今回の公開レスポンスではSitemap指定を確認できたため、次は/sitemap-index.xmlを取得し、公開対象の記事だけが含まれるかを別途確認する。

失敗しやすい点

ローカルファイルを正として公開レスポンスを見ないこと、反対にCDNの付加内容をリポジトリの変更としてコミットしないことが必要である。設定やサービス側の更新で結果が変わり得るため、再確認時は取得日時と実レスポンスを優先する。

今回の確認では、Cloudflare Managed contentの開始・終了コメントの間に、複数のクローラー名に対する規則もあった。本文の全行を転載して一般的なポリシーとみなすのではなく、確認日時の公開レスポンスに含まれた事実として扱う。サイト管理者が編集しているAllowとSitemapの行はブロックの外側に残っており、両者を区別して見ることができた。

再確認では、ブラウザの表示をコピーするだけでなく、HTTPで取得したテキストをpublic/robots.txtと比較する。改行やコメントの有無にも目を通すと、ルール自体の差分と表示上の差を混同しにくい。robots.txtを変更する場合も、Sitemap URLを先に壊さないことを確認してから公開する。

下書き記事は現在の公開Sitemapに含まれない実装であるため、記事を公開する際にも、Frontmatterの公開設定とSitemapを合わせて確認する。

公式資料と関連記事

Cloudflare公式: Content Signals Policy — Content Signalsの公式説明を確認できる。
Astro公式: @astrojs/sitemap — Sitemap生成の確認先。
Astroブログの公開前チェック：生成HTML・リンク・メタタグを確認する手順 — 生成物とSitemapの確認を扱う。