Block AI training.
Check what else you block.

The short answer

Give the web owner three decisions, not a blanket “block AI” request. Record the provider, intended use, affected pages and effective date. Compare the approved intention with the actual configuration before changing anything. Preserve intended public discovery and private-content restrictions deliberately.

The deliverable is a record of the approved choices and the verified settings. It is not a guarantee that an AI product will cite the company.

1. Problem: one instruction can hide different intentions

Illustrative situation: a company wants to protect its public articles from model training. Its marketing team still wants buyers to find the offer. The instruction sent to the web owner is simply “block AI”. Nobody records the intended treatment of answer generation, search or private pages.

Business consequence: the implementation can differ from what the commercial owner intended, while a dashboard reports only “AI blocked”. This example is hypothetical; no customer traffic loss or actual misconfiguration is claimed.

One concrete piece of evidence

On 30 October 2026, Microsoft described this combination: AI Training: Disallow; AI Grounding: Allow. It says the new preferences begin applying from 1 February 2027 as content is crawled. This is an announced option, not a deployment test.

Read Microsoft's announcement and example.

What the team needs to distinguish

Training

Using material to develop a model, rather than merely reading a page to answer a question.

Answer use, often called grounding

Using retrieved material when producing an answer.

Search discovery

A page being eligible for ordinary search retrieval and indexing.

Crawl access

Whether a requester can fetch the page. Check this separately from permitted content uses.

This Lens covers decisions for public web content. It does not grant access to private information, define legal rights or certify provider compliance. A declared preference, a reachable page and an actual citation are separate observations.

2. Verify: ask for the current evidence

1. Choose two real public pages. Start with the homepage and an important offer page. Identify their commercial owner and the person responsible for web changes.
2. Write the intended uses separately. For each provider and page, record allow, restrict or undecided for training, answer use and search. Describe any narrower permitted scope in plain language.
3. Ask the web owner to show the current settings. Capture relevant robots rules, page directives, response headers and edge restrictions. Record the actual URL, date and capture location, including conflicting or unknown controls.
4. Check the provider's current documentation. Record what the control covers, when it takes effect and whether recrawling or another transition action is required. If the documentation does not resolve the question, mark it unresolved.

Expected output: a record that connects business intent to an identifiable control and its evidence. A browser screenshot alone does not establish what a crawler receives.

Provider scope: keep the dates attached

• Microsoft announced separate preferences for training and use in AI answers, with a phased start from 1 February 2027.
• Google aims to support the shared training control in 2027.
• OpenAI plans to support the shared signal in the coming months and continues to respect its existing crawler controls.

Sources: Google Search Central and OpenAI. A shared vocabulary does not mean identical provider behaviour.

3. Fix: make the implementation match the decision

1. Resolve the intention first. Have the content and commercial owners approve each choice. Send undecided uses back for a decision; do not let a technical default stand in for consent from the owner.
2. Correct the demonstrated mismatch. Ask the web owner to prepare a small change against the approved scope. Save the existing configuration and a rollback copy before deployment.
3. Review side effects. Check the public-page paths and intended discovery separately from private, authenticated and transactional areas. Do not broaden access beyond the approved scope to pursue visibility.
4. Separate present changes from future migration. Give each action a source, owner, due date and effective-date condition. Recheck current provider documentation before applying future settings.

Do not paste a provider-specific directive across the whole site without resolving its purpose and scope. This article deliberately provides an approval and verification procedure rather than an unreviewed global configuration.

Microsoft transition: an existing-control check

According to the Bing Webmaster Tools FAQ, sites using NoArchive or NoCache as of 15 December 2026 need the relevant transition plan. To preserve grounding restrictions, publish page preferences and record the temporary Bing Webmaster Tools choice before 1 March 2027. The temporary choice lasts until Microsoft recrawls the page and finds the new preference, or 30 September 2027, whichever comes first.

Training has no temporary Webmaster Tools setting. After 1 March, those legacy controls no longer express training/grounding preferences. These use controls do not override a Bingbot crawl block or guarantee inclusion.

Assign a review now; recheck the source before the relevant date. This is preparation for announced changes, not evidence that those changes already apply today.

4. Retest: verify configuration, then observe outcomes

After an approved change, fetch the affected public URLs again and retain their returned directives and access results. Compare them with the approved row. If a provider must rediscover the setting, keep that status separate from “configuration verified”.

Then observe representative buyer questions under documented conditions. A later mention or citation does not prove the policy caused it, and an absent answer does not by itself prove the control is wrong. Keep the implementation evidence and answer observations separate.

Command line on macOS or Linux

Replace the example domain and page with your own. Read the robots file and the HTTP headers returned by a normal page request.

curl -fsSL https://example.com/robots.txt
curl -fsSL -D - -o /dev/null https://example.com/your-page

PowerShell

Use the same domain and page in PowerShell.

(Invoke-WebRequest -UseBasicParsing -Uri 'https://example.com/robots.txt').Content
(Invoke-WebRequest -UseBasicParsing -Uri 'https://example.com/your-page').Headers

Look for the applicable crawler group in robots.txt and any X-Robots-Tag response headers. Check the HTML source for page-level robots meta tags. These observations show the published configuration. Provider documentation and crawler reports are the next checks for interpretation and access.

Sources and evidence boundary

• Microsoft Bing announcement, 30 October 2026: the concrete example used in the personal post.
• Bing Webmaster Tools FAQ: scope and transition limitations.
• Google announcement, 30 October 2026: provider-specific implementation plan.
• OpenAI announcement, 30 October 2026: planned adoption and existing controls.

Sources checked 5 November 2026. The register and approval workflow are editorial controls. No live policy experiment, measured traffic impact, universal provider coverage or guaranteed citation is claimed.

About the publisher

VerisAI, founded in 2025, helps B2B services, SaaS, consulting and technology firms in Europe improve how their websites can be read, understood and cited by AI systems. Its AI Readiness Scoring & Monitoring service supports practical website checks. Contact support@verisai.eu.

Frequently asked questions

Can we make one blanket AI-blocking decision?

Record the intended uses first. Training, use in answers, search discovery and crawl access are different questions. Decide the provider and page scope, then have the web owner map the approved intention to current documented controls.

What is the concrete evidence in the LinkedIn post?

Microsoft announced independent training and grounding choices on 30 October 2026, including disallowing training while allowing grounding. This is a documented future option, not a live test on this website.

Do the new Microsoft preferences apply today?

The announced start is 1 February 2027 as Microsoft crawls. Keep preparation, publication of a setting and provider discovery as separate statuses. Recheck current documentation before implementing the migration.

Does the same setting work identically at every provider?

Do not assume that. Keep separate provider rows with their own source and effective date. The Google and OpenAI announcements describe different adoption plans; a common signal does not establish universal implementation.

What should a verified change record contain?

Record the approved decision, the affected URL, the observed setting and the date you checked it. Compare what your site returns with the provider documentation.

What should we do if the current setting is already correct?

Retain the evidence and owner, record the next review date and prepare any documented future migration. Do not invent a website defect or broaden access merely to pursue more AI mentions.