Webflowではrobots.txtを公開フローの一部として扱います。設定場所はSite settings → SEO → Indexingです。
先に本番を確認します
/robots.txtを開き、広すぎるDisallow、誤ったdomain、重複Sitemap:を確認します。
自動sitemapを考慮します
Webflowがsitemap参照を追加しているか確認してからcustom lineを追加します。reverse proxy構成ではdocumented optionも確認します。
保存だけでなく公開します
変更、保存、公開を行い、再度レスポンスを取得します。古い場合はcacheやroutingを調査します。
Content-Signalを別レイヤーにします
Content-SignalはAIによるcontent usageの選好で、robots.txtのcrawler accessとは別の仕組みです。
release前にチェックします
testerとvalidatorで確認し、private previewには認証を使います。
Content-Signalはrobots.txt標準ではありません
Webflowは Content-Signal headerで ai-train=no、search=yes、ai-input=no などの利用希望を表せると説明していますが、提案中のextensionに基づくもので受理済み標準ではありません。robots.txtはcrawler access、Content-Signalは対応先へのcontent use preferenceとして分けます。
Sitemap・publish・domainを別々に確認します
Webflowは通常sitemap参照を自動追加します。手動で追加する前に重複とcanonical domainを確認します。reverse proxyやmulti-siteでは、どの層が /robots.txt と /sitemap.xml を実際に配信しているかを特定します。
Saveだけではliveになりません。publish後のcustom domainを最終確認し、staging domainとは別Originとして検証します。
Publishされたresponseを基準にします
Webflowでは設定を保存しただけではcrawler向けresponseが更新されないため、必ずpublish後のcustom domainで /robots.txt を取得します。staging domainとproduction domainは別originとして扱い、Sitemap lineのhost、広いDisallow、bot-specific groupを比較します。reverse proxyやmulti-site構成なら、Webflowではなく上流のCDNやproxyがroot pathを所有していないかも確認します。
Content-Signalはrobots.txtとは別レイヤーです。robots.txtは「取得してよいか」を伝え、Content-Signalは対応するconsumerへcontent usage preferenceを表します。Webflow自身が提案中の仕組みと説明しているため、すべてのAI serviceが必ず従う標準として扱いません。AI方針を決める際は、crawler accessとusage preferenceを別々に記録します。
Sitemapの重複と移行を確認します
Webflowは通常sitemap参照を自動追加するため、manual lineを追加する前にlive fileを確認します。domain migration時は古いhostのSitemap lineが残っていないか、新domainのXMLがcanonical URLだけを含むかを見ます。問題が起きた場合は、save、publish、domain routing、cacheの順で切り分け、rule自体を何度も書き換えて原因を隠さないようにします。
