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.
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.
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.
- 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.
- 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.
- 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.
- 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.
- 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.
- Re-scan with AccessKnight and confirm the check reports 4 of 4.
User-agent: *
Allow: /
User-agent: bingbot
Disallow: /User-agent: *
Allow: /
User-agent: bingbot
Allow: /
User-agent: OAI-SearchBot
Allow: /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.
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.”
Frequently asked questions
Does ChatGPT use Bing's index?
Does allowing bingbot mean my pages will show up in ChatGPT?
Is it safe to block bingbot if I only care about Google traffic?
I allowed bingbot but AccessKnight still reports it blocked. Why?
Do I need both bingbot and OAI-SearchBot allowed?
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.
- Bing Webmaster Blog — Announcing user-agent change for Bing crawler bingbot
- OpenAI — Overview of OpenAI Crawlers (OAI-SearchBot and ChatGPT's search features)
- OpenAI Help Centre — ChatGPT Search (names Bing among its third-party search providers)
- Google Search Central — How Google interprets the robots.txt specification