Bing Splits AI Training vs Grounding: March 1, 2027

Quick Takeaways (read this first)

• Bing now separates “AI Training” from “AI Grounding.” Training can be controlled via robots.txt (site/path) or per-page meta/HTTP header. Grounding is page-level only (meta/HTTP header)—no site-wide robots.txt switch.
• If you used NoArchive/NoCache as a proxy AI control, you have a deadline. Bing opens temporary transition preferences in Bing Webmaster Tools (BWT) on Dec 15, 2026; to keep grounding restrictions you must publish the new grounding directive on pages and record the temporary preference in BWT by Mar 1, 2027.
• New control surface = new failure mode. A single misapplied header template can unintentionally suppress Copilot/Bing citations across your entire site.
• Make this governance, not a one-off tech change. Decide grounding policy by page class (news, docs, UGC, product, paywalled) and enforce via CMS templates or edge/CDN headers.
• Measure it like permissions. Segment Bing/Copilot visibility by directive state (allow vs disallow vs disallowextended) and by page class.

What changed: Bing introduced a real “permissions layer” for AI visibility

For most teams, “AI visibility” has been a fuzzy blend of SEO, content quality, and luck. This week, Bing made it operational. In Bing’s new documentation, Microsoft formalized separate publisher controls for:

1. AI Training — whether your content can be used to train generative models.
2. AI Grounding — whether your content can be retrieved, used to inform answers, and cited as a source in Bing/Copilot-style experiences.

This isn’t a minor terminology update. It’s a new configuration surface that can change whether you show up as a cited source—especially if your team historically treated caching directives (like NoArchive or NoCache) as a shorthand “don’t use my content for AI.”

Microsoft lays out the rules and the migration path in the New AI Preferences documentation in Bing Webmaster Tools, including the time-boxed transition window tied to NoArchive/NoCache.

AI Training vs AI Grounding: the practical difference (with examples)

Here’s the simplest way to think about it:

• Training is “learning from your content to improve a model over time.”
• Grounding is “using your page right now as evidence to answer a user’s question—and potentially linking/citing it.”

Example 1: Your API docs (SaaS)

You might be fine with grounding (so Copilot cites your docs for “How do I rotate API keys in Product X?”), but you may prefer to restrict training if your docs include proprietary implementation details.

With the new split, you can do exactly that—but only if you implement it intentionally.

Example 2: Your news content (publisher)

Newsrooms often want to be cited (grounding) because citations drive brand authority and referral traffic, but they may want to limit training reuse. The split lets you say “cite us, don’t train on us.” Previously, many teams used blunt tools that accidentally reduced both.

Example 3: Your user-generated content (community/UGC)

UGC is where risk management matters: you may want to restrict grounding for certain sections (e.g., unverified medical/legal advice) while leaving grounding open for vetted knowledge base pages. The page-level grounding control makes that possible—at the cost of implementation complexity.

The non-obvious (and urgent) part: Grounding is page-level only

Bing’s documentation is explicit: you can control AI Training at the robots.txt level (site-wide or path-based) or at the page level (meta tag / HTTP header). But AI Grounding is page-level only.

That’s the big operational change for AEO/GEO teams: there is no single global “do not ground my site” switch in robots.txt. If you want to restrict grounding, you must publish a directive on the page itself (or via an HTTP header).

Why this becomes a new failure mode

We’ve seen teams treat new AI directives like “just another robots rule” and roll out a broad header template. That’s dangerous here. Because grounding is page-by-page, a single wrong default can:

• remove your eligibility to be cited in Copilot/Bing answers for entire templates (docs, blog, help center),
• reduce “citation share” for high-intent topics,
• create a silent traffic drop that looks like “AI stopped citing us” rather than “we blocked ourselves.”

If you’re already tracking Bing’s AI outcomes, pair this change with your monitoring stack. Our guide on Bing’s Citation Share as a GEO KPI is a useful baseline because it treats citations as a measurable surface—not vibes.

The migration window you can’t ignore: NoArchive/NoCache (Dec 15, 2026 → Mar 1, 2027)

The most time-sensitive part of Bing’s update is the transition for sites that historically relied on NoArchive or NoCache. According to the Bing AI Preferences documentation:

• Dec 15, 2026: Bing Webmaster Tools opens “temporary grounding transition preferences” for eligible sites.
• Mar 1, 2027: To maintain grounding restrictions, you must (a) publish the new AI Grounding preference on your pages and (b) record the temporary preference in BWT.
• Temporary preferences expire: Sep 30, 2027 or earlier upon recrawl.

Contrarian insight: this is less about “AI ethics” and more about release management

Most organizations will fail this migration for boring reasons: incomplete inventories, inconsistent templates, and unclear ownership between SEO, legal, product, and infra. The win isn’t “choosing the perfect policy”—it’s making sure your policy is actually expressed reliably at scale.

Step-by-step sprint plan (recommended): detect → decide → implement → verify

If you’re an in-house SEO/AEO lead or technical SEO owner, treat this as a 2–4 sprint governance project. Here’s a plan you can actually run.

Step 1: Detect NoArchive/NoCache usage at scale (1–3 days)

You need to know where legacy directives exist before you decide anything.

1. Crawl your site with Screaming Frog or Sitebulb and export:
   • meta robots directives
   • X-Robots-Tag headers
   • cache-related headers if your stack uses them
2. Pull server/CDN config (Cloudflare, Fastly, Akamai) to find global header injections.
3. Sample-check templates: homepage, category, article, docs, product, search results, UGC threads, gated pages.

Deliverable: a spreadsheet mapping URL pattern → template → current directive state.

Step 2: Decide grounding policy by page class (2–5 days with stakeholders)

Don’t decide “site-wide.” Decide per content class. A simple matrix works.

Notice what’s missing: a single universal rule. Grounding is where you win (citations) and where you can self-suppress.

Step 3: Implement directives safely (CMS template or edge headers)

Because grounding is page-level, you’ll implement it one of two ways:

• CMS templates (meta tag): best when you control markup and want template-by-template governance.
• Edge/CDN (HTTP header): best when you need fast rollout, consistent enforcement, or to cover non-HTML (PDF) assets.

Whichever you choose, build a default-allow posture for grounding unless you have a clear reason to restrict. In AEO/GEO, accidental blocking is usually more expensive than accidental allowing.

Pre-deploy safety check (add this to your release checklist)

1. Pick 20 representative URLs across templates.
2. Check response headers with curl -I (or your observability tool).
3. View source for meta directives.
4. Confirm that only the intended templates carry grounding restrictions.

If your org is moving toward verifiable AI-agent traffic, pair this with request validation. Our post on Web Bot Auth and signed agent requests explains how to make AI-agent access measurable and governable.

Step 4: If you’re eligible, set the temporary preference in Bing Webmaster Tools (Dec 15, 2026 onward)

For sites impacted by the NoArchive/NoCache transition, Bing’s process is explicitly two-part:

• Publish the new AI Grounding preference on pages (meta/HTTP header).
• Record the temporary grounding transition preference in BWT.

Don’t treat BWT as optional paperwork. Bing states temporary preferences can expire by recrawl—so implementation without monitoring can still drift.

Step 5: Verify by recrawl + AI citation impact (ongoing)

Verification is not “we shipped headers.” Verification is “Bing recrawled, directives were interpreted, and our citations behaved as expected.”

What to monitor:

• Recrawl coverage: are high-value templates being recrawled quickly enough?
• Citation share by page class: docs vs blog vs product vs UGC.
• Directive-state segmentation: allow vs disallow vs disallowextended.

If you’re already using Bing’s “grounding queries” reporting, this is the perfect moment to add a permissions dimension. (If you’re not, our playbook on Bing Grounding Queries shows how to turn those into a 7-day sprint.)

How to use “DisallowExtended” strategically (instead of all-or-nothing)

One of the most useful hints in Bing’s write-up is the presence of an intermediate option—often referenced as DisallowExtended. Practically, this gives you a middle gear for risk management:

• Allow: maximize eligibility for grounding/citations.
• Disallow: block grounding use cases (strongest restriction).
• DisallowExtended: limit broader grounding use cases while preserving some Microsoft experiences (nuanced control).

Where we recommend considering DisallowExtended:

• UGC and forums: reduce the chance of low-trust content being used as direct evidence while still allowing some discovery pathways.
• Support tickets / changelogs: content is useful, but may be context-sensitive or time-bound.
• Partner pages: you may want limited usage depending on licensing obligations.

The key is to avoid the common mistake of treating grounding restrictions as “privacy.” For many teams, grounding is a distribution channel. Turning it off everywhere is like noindexing your whole site because you dislike scrapers.

Common mistakes we expect to see (and how you can avoid them)

Mistake #1: “We set robots.txt, so we’re done.”

You may be done for training. You’re not done for grounding. Grounding requires page-level directives—so you need template logic or edge rules.

Fix: Add a QA check that verifies page-level directives exist for every restricted template.

Mistake #2: One global header injected by the CDN

This is the fastest way to accidentally suppress citations. A global header is tempting because it’s easy, but grounding needs nuance.

Fix: Implement by path/template with explicit allowlists. Start with a default allow for grounding and only restrict where necessary.

Mistake #3: Treating NoArchive/NoCache as “good enough” until 2027

Bing gave dates for a reason. Waiting until February 2027 is how you end up racing recrawl dynamics, QA gaps, and stakeholder approvals.

Fix: Build the migration into your roadmap now: detection → policy matrix → implementation → BWT setting → monitoring.

Mistake #4: Not tying this to broader search volatility

AEO/GEO teams are implementing controls during a period where ranking systems are also moving. For example, Google is actively rolling out a major update: Search Engine Land reports the November 2026 core update is rolling out, and you can corroborate timing on the Google Search Status Dashboard entry for the November 2026 core update.

If your traffic dips after you ship AI directives, you need to separate “we blocked grounding” from “the core update reshuffled rankings.”

Fix: Annotate releases in analytics, keep a change log, and segment Bing AI metrics separately from Google organic.

Three real-world implementation patterns (copy/paste-able playbooks)

Pattern A: SaaS docs team that wants citations, not training

Goal: Keep Copilot/Bing grounding enabled for docs; restrict training for sensitive sections.

1. Allow grounding across /docs/ by default (no restrictive grounding directive).
2. Add training restriction via robots.txt for /internal/ or /beta/ doc paths.
3. Add page-level training restrictions for a handful of high-risk pages (e.g., security runbooks) via header.
4. Monitor citation share for docs pages weekly; if citations drop, audit header changes first.

Pattern B: Publisher with paywall + free previews

Goal: Allow grounding on free preview pages; restrict grounding on paywalled full articles.

1. Create two templates: preview and paywalled.
2. On paywalled pages, apply grounding restriction at page-level (header is often easiest to guarantee consistency).
3. Keep preview pages grounding-allowed so your newsroom still earns citations.
4. Use DisallowExtended on opinion/rumor-heavy categories to reduce risk without going fully dark.

Pattern C: Marketplace/UGC site managing trust

Goal: Avoid grounding on low-trust UGC, keep grounding on policy pages and vetted guides.

1. Classify UGC templates (threads, comments, profiles) and apply DisallowExtended or disallow grounding.
2. Keep grounding allowed for /help/ and /guides/ where you want citations.
3. Implement via CDN rules by path to avoid relying on many product teams shipping consistent tags.
4. Run monthly audits: sample 50 URLs per class, verify headers, and compare citation share trendlines.

FAQ (snippet-ready answers)

Can I control AI Grounding in robots.txt?

No. Bing’s documentation indicates AI Grounding is page-level only—you must use a meta tag or HTTP header per page to restrict grounding.

Can I control AI Training in robots.txt?

Yes. Bing supports controlling AI Training via robots.txt at the site/path level, and also supports page-level controls.

If I used NoArchive/NoCache to restrict AI usage, what do I need to do?

Plan a migration. Starting Dec 15, 2026, eligible sites can set a temporary transition preference in BWT; by Mar 1, 2027, you must publish the new grounding directive on pages and record the temporary preference in BWT to maintain restrictions. Temporary preferences expire Sep 30, 2027 or earlier upon recrawl (per Bing’s documentation).

How do I know if we accidentally blocked grounding?

Look for sudden drops in Bing/Copilot citations (not just clicks), correlate with release dates, and audit headers/meta directives on representative templates.

What to do next (action steps you can assign this week)

1. Run a directive inventory crawl (meta robots + X-Robots-Tag + CDN-injected headers).
2. Create a page-class policy matrix (docs, news, UGC, product, paywall) for training vs grounding.
3. Choose an implementation method: CMS templates (fine-grained) or edge headers (fast + consistent), then stage it.
4. Add a pre-deploy QA gate: 20-URL header/meta verification before production releases.
5. Prepare the NoArchive/NoCache migration plan: schedule work ahead of Dec 15, 2026 and avoid the Feb 2027 crunch.
6. Update reporting: add “AI permissions state” as a dimension in your AEO/GEO dashboards (allow/disallow/disallowextended).

Why this also signals a broader standardization trend

Bing’s split aligns with the wider industry push toward explicit, machine-readable AI preference signals. For example, Anthropic describes how it recognizes training preference signals (including emerging standards) in its Privacy Center documentation on crawling and blocking. And TechRadar notes broader efforts toward a standardized crawling approach, including references to separate grounding-style preferences in its coverage of the proposed standardization push: Google and Microsoft signing onto an OpenAI plan for a new crawling standard.

The practical takeaway: expect more “permissions knobs” like this. Teams that operationalize governance now (inventory, templates, QA, measurement) will move faster later—without self-inflicted visibility losses.

Try it in aeotool.ai (dashboard + Chrome extension)

If you want help turning these directives into an AEO/GEO workflow (inventory → policy → deployment checks → citation impact monitoring), we recommend using the AEO tool dashboard. You can create an account here: https://aeotool.ai/register.

And if you want a quicker, in-browser way to spot potential self-suppression risks (headers, directives, indexability signals) while you review pages, install our Chrome extension: AEO Analyzer Chrome extension.