BingPreview: User Agent, robots.txt, and Why Microsoft's Own Docs Would Not Load
What can and cannot be verified about Microsoft's BingPreview crawler, why its documentation is unreadable to crawlers, and how to control the token.
At a glance
- User-agent token
BingPreview- Full user-agent
BingPreview (no exact string could be confirmed. Microsoft's crawler documentation is a JavaScript application that returned no readable content to a non-rendering fetch on 14 August 2026)- Operated by
- Microsoft
- What it does
- Historically associated with generating page snapshots for Bing results. Microsoft's current, readable documentation does not confirm a live purpose for this token
- Executes JavaScript
- Not documented Microsoft's crawler documentation page could not be read without JavaScript on 14 August 2026, so there is no statement to cite. Vercel's December 2024 crawler study did not test any Microsoft or Bing crawler.
- Obeys robots.txt
- Not documented
- Documentation
- www.bing.com
- Published IP ranges
- www.bing.com
robots.txt
Block BingPreview
User-agent: BingPreview
Disallow: /Allow BingPreview
User-agent: BingPreview
Allow: /Microsoft does not document that BingPreview obeys robots.txt. Treat these directives as a request rather than a control, and verify against your own server logs.
BingPreview is a Microsoft crawler token that shows up in server logs and in nearly every AI crawler comparison table on the internet. What almost none of those tables mention is that the primary source they are all citing cannot actually be read.
What happened when I checked the documentation
On 14 August 2026 I fetched Microsoft’s crawler documentation at bing.com/webmasters/help/which-crawlers-does-bing-use-8c184ec0, the canonical page for this information.
It returned one line of usable content: the page title, “Bing Webmaster Tools - Help Documentation”. No user agent strings, no crawler list, no robots.txt statement, no rendering guidance. The page is a client-side application and its content assembles in the browser after JavaScript runs.
A second attempt at a Microsoft Learn path for the same content returned HTTP 404.
There is a joke in here and it is worth sitting with rather than laughing at. The definitive document on how search crawlers identify themselves is invisible to anything that does not execute JavaScript. Every operator profiled in /bots/ publishes something a fetcher can read. This one does not. If a crawler with a rendering budget the size of Microsoft’s cannot be assumed to see your content, a page that hides its substance behind hydration is making a large bet. That is the whole argument of AI crawlers and JavaScript rendering, demonstrated by accident on Microsoft’s own domain.
What can be verified
Two things.
Microsoft does publish a machine-readable IP range list at bing.com/toolbox/bingbot.json. I fetched it the same day. It is static JSON, it lists 28 IPv4 prefixes, and its creationTime field reads 2024-01-03T10:00:00.121331. That is a genuinely useful file for verifying that a request is really Microsoft. It is also more than two and a half years stale, which is worth knowing before you build an allowlist on top of it.
Your own access log is the second source. Grep it for the BingPreview token and you will learn more about whether this crawler is live on your site than any published table can tell you.
Can it read JavaScript
Undocumented, with less evidence behind it than any other crawler on this site.
There is no readable vendor statement. And unlike the OpenAI, Anthropic, ByteDance, Meta, Perplexity, Google, Apple, and Common Crawl agents, no public experiment covers it either. Vercel’s rise of the AI crawler study of 17 December 2024 is the only instrumented measurement in circulation, and it did not test any Microsoft or Bing crawler.
So the position is: no vendor documentation that renders, and no experimental data at all. If you find a table giving BingPreview a confident yes or no, ask where the number came from. There is nowhere for it to have come from.
How to control it with robots.txt
Block it:
User-agent: BingPreview
Disallow: /Allow it while keeping private paths out:
User-agent: BingPreview
Allow: /
Disallow: /account/
Disallow: /checkout/Since no readable Microsoft source confirms compliance for this specific token, verify rather than assume. Compare your logs before and after.
The practical read
Do not spend much time on this one. The token appears in logs, it is Microsoft, and no readable documentation confirms what it currently does. That is the honest summary and it should not drive an architecture decision.
What should drive one is the thing Microsoft demonstrated for free. Its own help centre is inaccessible to a fetcher without a rendering engine. If that can happen to a search company’s documentation, it can happen to your pricing page. Load your key pages with JavaScript disabled and read what actually comes back.
Common questions
Is BingPreview still active?
Not confirmable from a readable source. Microsoft's crawler documentation page is a client-side JavaScript application and returned no content to a non-rendering fetch on 14 August 2026, so there is no live statement to check the token against. Your access log is the only reliable evidence of whether it still visits your site.
Does BingPreview execute JavaScript?
Undocumented. There is no readable Microsoft statement about rendering for this token, and Vercel's December 2024 crawler study, the only public experiment of its kind, did not test any Microsoft or Bing crawler. Nobody has published a measurement. Treat any confident answer you find as invention.
How do I tell a genuine Bing crawler from an impostor?
Check the source IP against Microsoft's published list at bing.com/toolbox/bingbot.json rather than trusting the user agent header, which is free text. Note that the file's creationTime field reads 2024-01-03, so the list has not been regenerated in over two and a half years.