Content-Signal and usage-control declarations express opposed preferences at /
content_signals_conflict_with_bot_rules · Review item
Review the two original declarations together. If both should state the same usage preference, align them with your policy and reaudit the site.
Severity: Notice. Review item: opposed explicit preferences, not a formal contradiction or demonstrated consumer failure.
Why it matters
Usage-control tokens can communicate restrictions on training or grounding. Ordinary crawler access does not itself grant or forbid a data use.
What to do
- Read the source-bound Content-Signal and determining explicit Allow shown together at /.
- If no training is intended, align the usage-control rule to that preference. If use is intended, review whether the no signal is still appropriate.
- Run a subsequent full audit of the same site after changing the original declarations.
When to leave it as it is: Keep intentional preferences after reviewing how your consumers use each declaration. This finding is a policy review, not proof of enforcement behavior.
What we read
Original direct current HTTP 200 robots.txt, exact declared groups and the admitted bot purposes.
Only Google-Extended training/grounding and Applebot-Extended training usage controls; a no signal plus explicit winning same-group Allow at /.
An unambiguous inherited wildcard can apply when the token has no own group. Wildcard signals are not transferred into own named groups.
Example & evidence
Illustrative same-site declaration correction; no live result.
User-agent: Google-Extended
Content-Signal: ai-train=no
Allow: /User-agent: Google-Extended
Content-Signal: ai-train=no
Disallow: /Confirm & check again
Check for yourself: Read the official usage-control purpose for the exact token. Do not equate an ordinary search or training crawler’s access with this signal’s meaning.
Check again: Full audit — A subsequent full audit uses the shared evaluator and lifecycle for the same site. Unknown or insufficient coverage never proves a fix. No new Verify executor is required.
Limits & sources
GPTBot, CCBot, ordinary search crawlers and search access-versus-use examples do not create this finding. no+winningDisallow is aligned; yes+Disallow is not automatically a conflict.
Implicit default Allow, cross-group winning Allow, aliases, path scope, duplicates and multiple effective signal groups remain not checked, including a malformed second declaration.
Independent definite preferences survive unknown companions, but insufficient coverage never proves a fix. Removing only Allow leaves implicit permission unverified.
A complete checked signal removal or declared alignment may reconcile. Comments do not prove Cloudflare management, hosting, adoption or enforcement.
Confidence: High High for the two original declarations and admitted usage purpose, with explicit review-item limits.
Sources
- Cloudflare, Content Signals Policy — Defines the declared search, training and AI-input preferences. Checked 4 October 2026.
- Google, Google common crawlers — Documents the Google-Extended usage-control purpose in the frozen bot reference. Checked 9 September 2026.
- Apple, Applebot — Documents Applebot-Extended training controls in the frozen bot reference. Checked 9 September 2026.
Editorial review: 2 November 2026