OAI-AdsBot: Why ChatGPT Ads Cannot Reach Your Landing Page

Most ChatGPT Ads troubleshooting advice is about bids, budgets and creative. This is about the failure that happens before any of that matters: OpenAI tries to look at your landing page, cannot, and the ad does not run.

The crawler that does that looking is OAI-AdsBot. It is not GPTBot, it is not OAI-SearchBot, and allowing either of those does not allow it. This post covers what OpenAI actually documents about it across two surfaces, the three layers that block it in practice, and some numbers we pulled ourselves on 2026-09-23 that change how you should think about IP allowlisting.

The one sentence that decides whether your ad runs

OpenAI's advertiser guidance is unusually direct about the requirement:

You must allow OAI-AdsBot. We recommend allowing both OAI-AdsBot and OAI-SearchBot.

— Advertiser Guidance for Allowing OpenAI Web Crawlers

The reason is stated on the same page: when you submit an ad, OpenAI may visit the landing page to check it complies with policy, and may also use the landing page content to work out when the ad is relevant to show. So crawlability is not only a review gate — it is an input to targeting quality.

Why "we already allow OpenAI" is usually wrong

This is the part that catches teams who consider themselves well-configured, because they have thought about AI crawlers — just not about this one.

OpenAI's developer documentation lists four agents and is explicit that the settings are independent of one another:

Source: Overview of OpenAI Crawlers, read 2026-09-23.

Read that table again with an advertiser's eyes. The bot most sites deliberately allow — GPTBot — is the one with no bearing at all on whether your ad clears review. The bot that decides it is the one least likely to appear in a hand-curated allowlist, because it only shows up in your logs after you start advertising.

We checked our own site while writing this, and it is a fair example of the trap. soku.ai/robots.txt carries a deliberate block of explicit AI-crawler permissions — GPTBot, ClaudeBot, Google-Extended, PerplexityBot and Applebot-Extended each named and allowed. Neither OpenAI ads crawler was on that list. Nothing was broken, because the wildcard User-agent: * rule above it allows everything. But the curated list — the one written by someone who had clearly thought about AI crawlers — omitted both bots that matter for ChatGPT Ads. We have added them in the same change as this post.

The numbers OpenAI links to but does not summarise

The help centre points at adsbot.json and searchbot.json for stable IP ranges without saying what is in them. We fetched all four files on 2026-09-23:

Two things are worth drawing out, and both are our reading rather than OpenAI's statement.

OAI-AdsBot has by far the smallest published footprint. Two prefixes — 130.131.229.128/25 and 20.168.90.128/25 — 256 addresses in total. That is small enough to paste into a firewall rule without argument, which is a genuinely useful fact if your security team's objection to allowlisting is scale.

It is also the stalest file. GPTBot and ChatGPT-User were regenerated on 2026-09-22, the day before we looked. The AdsBot file still carried a 2026-05-12 creation time. A file that has not moved in four months is either a very stable range or a file that is not being maintained at the same cadence as the others, and you cannot tell which from the outside. That is precisely why OpenAI's own note on stable IP ranges tells you not to lean on IP alone:

Because crawler infrastructure may evolve over time, your engineering team should avoid relying solely on short-term IP observations from logs. Instead, validate traffic through a combination of user-agent identification, verified bot programs where supported, firewall allowlists, robots.txt behavior, and provider-level bot verification systems.

Use the IP file as belt-and-braces. Identify on the user agent.

The exact user-agent strings

From the developer documentation, read 2026-09-23. The AdsBot string is fixed; the SearchBot version number may change.

Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko); compatible; OAI-AdsBot/1.0; +https://openai.com/adsbot

Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36; compatible; OAI-SearchBot/1.4; +https://openai.com/searchbot

One detail that saves log-reading time: when OpenAI fetches robots.txt specifically, it may append a robots.txt marker to the user-agent string, so that site owners whose logs do not record paths can still tell a robots.txt fetch from a page fetch.

The three layers, in the order they stop you

OpenAI's guidance describes the blocking layers in sequence, and the order matters because fixing the wrong one changes nothing.

1. robots.txt

If robots.txt disallows the path, crawling stops immediately — nothing downstream gets a chance. The documented shape is plain:

User-agent: OAI-SearchBot
Allow: /

User-agent: OAI-AdsBot
Allow: /

If your robots.txt is generous by default this layer is probably already fine. It is the layer people check first because it is the one they control, which is also why it is rarely the actual problem.

2. Web protection and bot mitigation

Cloudflare, Akamai and similar services defend against scraping and automated traffic, and OpenAI's guidance says plainly that these systems "can mistakenly block legitimate crawlers, often returning 403 Forbidden errors," because crawler traffic resembles the patterns they exist to stop.

There is one piece of good news documented here that is worth knowing before you open a ticket: OAI-AdsBot is officially verified and allowlisted by Cloudflare. If you are on Cloudflare, verified-bot handling should already recognise it, which narrows your investigation to custom WAF rules and bot-fight settings you added yourself rather than to the platform default.

3. Human verification and anti-bot logic

CAPTCHAs, JavaScript challenges, behavioural analysis and session validation sit inside your application rather than at the edge, so a crawler can clear both layers above and still be stopped here. This is the layer that produces the most confusing symptom: the page is publicly reachable, returns 200 to a normal request, and still fails review.

Product feeds have a second surface you will forget

This is the detail most likely to bite an ecommerce advertiser, and it is one sentence in the guidance:

For product feeds, also allow OAI-SearchBot to crawl the product image URLs. Check firewall, CDN, and bot-protection rules on the image host; a 403 response can block feed processing.

Landing pages and product images usually live on different hosts. The landing page is on your main domain behind whatever rules you tuned for it; the images are on a CDN or object-storage bucket configured by someone else, possibly years ago, and frequently with tighter hotlink and bot rules precisely because images are what gets scraped. Feed processing can fail on the image host while the landing page is perfectly crawlable, and the error surfaces as a feed problem rather than a crawler problem.

If you run feed-based campaigns, audit both hosts. And note this applies to OAI-SearchBot on the image URLs, not only AdsBot — the two bots have different jobs even inside a single feed campaign.

Rate limiting, and why big bulk uploads are a bad idea

OpenAI's guidance notes that large batch uploads or sudden spikes in crawler traffic can trip automated rate limiting. The tell is HTTP 429 in your logs around the time the crawler tried, alongside firewall, CDN and bot-mitigation events.

The documented remedy is unglamorous and effective: upload in smaller batches over a longer period. If you are launching a few hundred ads at once and a portion of them stall in review, the cause may not be the ads at all — it may be that your own infrastructure throttled the crawler that was trying to validate them.

What to do, in order

1. Confirm the failure mode before changing anything. Ask your engineering team whether the landing page returns a successful HTTP response to OAI-AdsBot specifically, not to a browser. A page that is fine in Chrome tells you nothing about this.
2. Name both bots explicitly in robots.txt, even if a wildcard already allows them. An explicit Allow survives the next person who tightens the wildcard.
3. Check Cloudflare or your WAF for custom rules, not the platform defaults — AdsBot is a verified bot on Cloudflare, so a block is more likely to be something you added.
4. Audit the image host separately if you run product feeds, for OAI-SearchBot.
5. Look for 429s if you bulk-uploaded, and split the batch.
6. Re-upload or resubmit affected ads after the fix if the status does not clear on its own. Do not wait for a manual bypass — OpenAI's guidance says not to rely on one.

The Soku view

Two editorial observations, clearly separated from the documentation above.

The first is that this is an unusually cheap problem to prevent and an expensive one to diagnose. The fix is four lines of robots.txt and a firewall rule. The failure presents as ads that do not start, which everyone instinctively debugs as a bidding, budget or policy problem — three places where the answer is not.

The second is about who owns it. Every step in OpenAI's own troubleshooting list routes to "your engineering or security team." That is accurate and it is also the reason these tickets sit: the person watching the ads is not the person who can change the WAF, and the symptom does not obviously belong to infrastructure. If you are standing up ChatGPT Ads, get the crawler access agreed before the first campaign rather than as an escalation during it.

At Soku we run the landing pages and the campaigns in one loop, which means crawler reachability is a deployment concern rather than an escalation — but the underlying checklist above is the same whether or not you use us, and it is worth running once before you need it.

Sources, all read 2026-09-23:

• Advertiser Guidance for Allowing OpenAI Web Crawlers — help centre
• Overview of OpenAI Crawlers — developer documentation
• adsbot.json, searchbot.json, gptbot.json, chatgpt-user.json — published IP ranges

Last verified: 2026-09-23. Crawler IP files change without notice; re-read them before you build a firewall rule from the numbers in this post.