Skip to content
All AI readability rules
SeriousAI Crawler Access4 of 30 ptsCrawlers

How to fix: Bingbot is blocked from crawling

Bingbot is Microsoft's search crawler, and it feeds more than Bing: Bing's index is widely understood to supply the candidate pages ChatGPT search draws on, so a robots.txt rule that disallows bingbot can close an AI answer surface as well as a search engine — even when OAI-SearchBot itself is allowed.

The check

What is this?

This check fails when robots.txt disallows bingbot, Microsoft's search crawler. AccessKnight scores it at 4 points and files it under AI Crawler Access rather than general SEO, because OpenAI names Bing as one of the third-party search providers ChatGPT search sends queries to — so a bingbot block can close an AI surface, not only a search engine.

Here is the whole of the public record, because most writing on this overstates it. OpenAI's help centre says ChatGPT search "sometimes partners with other search providers", and names exactly two: Bing and Shopify. That is the documented claim, and it is the one this check rests on — Bing is a named path into ChatGPT search, sometimes queried.

What neither OpenAI nor Microsoft documents is the stronger version you will read almost everywhere else: that Bing's index is the source ChatGPT search draws from, that Bing indexation is a precondition for being cited, or what share of ChatGPT answers arrive through it. "Sometimes" and "one or more providers" rule out a categorical claim, and independent reporting suggests other indexes are also in play. So allow bingbot — it is a named route, it costs nothing, and it serves Bing Search and Copilot regardless. Just do not let anyone tell you it is the switch that turns ChatGPT on.

The impact

Who does this affect, and why does it matter?

Bing Search is affected directly, and so is Microsoft Copilot, which Microsoft builds on the same index. ChatGPT search is the third surface if the Bing link above holds. Because those surfaces share one crawler, a single Disallow line can close more than the one engine it looks like it closes — which is what makes four points the highest-leverage four in the pillar.

The site owner absorbs the loss quietly, and often on purpose. Bing is a much smaller search engine than Google, so its traffic is easy to write off as not worth the crawl budget, and blocking it feels like tidy housekeeping. The AI surfaces sitting on top of that index are what actually disappear, and no report in Bing Webmaster Tools or Search Console connects the two events for you.

AccessKnight scores this check at 4 of 30 points in the AI Crawler Access pillar. It is not a gating check — a bingbot block does not cap the headline score the way a blocked OAI-SearchBot or a noindex directive does — but it is the second-heaviest check in the pillar, weighted above the three-point checks for ChatGPT-User, Claude, PerplexityBot, and Googlebot.

The weighting reflects reach rather than severity. Allowing bingbot is a precondition for appearing in Bing's own results, and — if the retrieval account above holds — for sitting in the pool ChatGPT search draws candidates from. Blocking it forecloses both. Allowing it delivers neither automatically: it makes the page eligible to be crawled, which is where the work starts rather than where it finishes.

There is a practical argument beyond the score. Bing's index is less contested than Google's, it weights on-page relevance and freshness more heavily against backlinks, and it prunes thin pages harder. A newer domain can earn position in Bing before it earns anything comparable in Google — and if the ChatGPT retrieval account holds, movement there may show up before a Google metric does.

The fix

How do I fix it?

Replace the rule blocking bingbot with an explicit Allow: /, or narrow it to the specific paths you genuinely want kept out. Then confirm in Bing Webmaster Tools that the site is actually indexed, because being crawlable and being indexed are different states and only the second one puts the page in the retrieval pool.

  1. Open https://yourdomain.com/robots.txt and look for a group naming bingbot, plus any wildcard User-agent: * group with Disallow: / that would catch it by default.
  2. Replace the disallow with an explicit User-agent: bingbot group containing Allow: /, or narrow the existing rule to the specific paths you genuinely want kept out of the index.
  3. Write the token in lowercase as bingbot, the spelling Microsoft documents. AccessKnight compares user-agent tokens case-insensitively, so Bingbot resolves to the same group, but matching the documented spelling keeps the file legible for whoever edits it next.
  4. Confirm the site is actually indexed in Bing Webmaster Tools once the crawler is allowed. Being crawlable and being indexed are two different states, and it is the second one that matters for any surface built on that index. Submitting the sitemap there is the fastest route, and IndexNow pushes changes rather than waiting for a recrawl.
  5. Test the file as the crawler itself: curl -sA "bingbot" https://example.com/robots.txt. Getting the file back means the path is open; a 403, a challenge page, or a timeout means a CDN or WAF bot rule is rejecting bingbot before robots.txt is read, and the fix belongs there rather than in the file.
  6. Re-scan with AccessKnight and confirm the check reports 4 of 4.
robots.txt — Before
User-agent: *
Allow: /

User-agent: bingbot
Disallow: /
robots.txt — After
User-agent: *
Allow: /

User-agent: bingbot
Allow: /

User-agent: OAI-SearchBot
Allow: /
Detection

How does AccessKnight detect this?

AccessKnight fetches /robots.txt from the origin of the final URL after redirects, parses it into per-user-agent groups, and resolves the rules for bingbot against the path / — the site root, not the scanned page's path. User-agent tokens are compared in lowercase, so bingbot, Bingbot, and BINGBOT resolve to the same group. A group naming the crawler wins over the wildcard * group; inside the winning group the longest matching rule decides and Allow wins a tie. No robots.txt at all means everything is allowed. The check is worth 4 points, awarded all or nothing, and the report labels it "Bingbot (Bing — a named ChatGPT search provider) can crawl". Note what it does not do: it reads the declared policy only. It never queries Bing to confirm the page is actually in the index, which is a separate state you have to verify in Bing Webmaster Tools yourself.

On screen right now

What strings mean this?

If one of these strings is in front of you right now — in a config file, an HTTP header, an AccessKnight report, or another checker’s output — it is describing the failure explained on this page.

robots.txt
User-agent: bingbot
robots.txt
Disallow: /
User-agent
bingbot
AccessKnight report
Bingbot (Bing — a named ChatGPT search provider) can crawl
AccessKnight report
Bingbot is blocked — OpenAI names Bing as one of the third-party search providers ChatGPT search sends queries to, so a bingbot block can close that path as well as Bing Search and Microsoft Copilot, even when OAI-SearchBot is allowed.
FAQ

Frequently asked questions

Does ChatGPT use Bing's index?

Be precise about the evidence here, because most sources are not. What OpenAI documents is that OAI-SearchBot surfaces sites in ChatGPT's search features, and that each crawler setting is independent of the others. That ChatGPT search draws its candidates specifically from Bing's index is not stated in either vendor's public crawler documentation — it is the widely-held working assumption AccessKnight scores on, and it is why bingbot sits in the AI Crawler Access pillar rather than under general SEO. Treat it as a commercial arrangement to re-verify, not a documented constant.

Does allowing bingbot mean my pages will show up in ChatGPT?

No, and nobody can honestly promise that. Allowing bingbot removes a blocker and makes the page eligible to be crawled and indexed; whether an answer engine then selects it depends on the quality and relevance of the page against everything else it could have used. What the fix buys you is candidacy. What you do with the page decides the rest.

Is it safe to block bingbot if I only care about Google traffic?

That trade is smaller than it looks. You are not only giving up Bing's search traffic; you are giving up the index Microsoft Copilot is built on, and — on the widely-held but undocumented account of how ChatGPT search retrieves — its candidate pool too. Crawl budget is rarely the real constraint on a normal site, and if it is, narrowing the disallow to specific heavy paths costs you far less than a blanket block on the whole crawler.

I allowed bingbot but AccessKnight still reports it blocked. Why?

Check three things in order. A wildcard User-agent: * group with Disallow: / still applies whenever no group names bingbot specifically, so an Allow line in the wrong group changes nothing. Robots.txt is read from the origin of the final URL after redirects, so an apex-domain edit will not reach a site that redirects to www. And a CDN may still be serving a cached copy of the previous file.

Do I need both bingbot and OAI-SearchBot allowed?

Yes, because they guard different stages. Bingbot determines whether the page can enter Bing's index — which ChatGPT search is widely understood, though not documented by either vendor, to draw its candidates from. OAI-SearchBot determines whether the page can then be fetched and quoted. Allowing only one leaves the path broken at the other end. The two are scored separately, at 4 and 8 points, for exactly that reason.
Sources

Where does this come from?

Every external claim on this page traces to one of the documents below — the vendors’ and standards bodies’ own documentation. What AccessKnight adds is the scan, not the standard.

Is this check
failing on your site?

AccessKnight scans any page against all 18 AI-readability checks — including this one — and shows every issue with a fix. Free, no credit card.

✓ Free — no credit card✓ Nothing installed on your site✓ WCAG + AI readability