OAI-AdsBot

OAI-AdsBot is a web crawler run by OpenAI. It visits landing pages that advertisers submit through OpenAI’s ad platform on ChatGPT, checking whether those pages comply with OpenAI’s ad policies and pulling content to inform when and to whom the ad gets shown.

It sits alongside 3 other documented OpenAI crawlers, each with a different function:

The table is worth keeping in view when you see OAI-AdsBot in your logs. OpenAI explicitly states that the data this crawler collects does not feed its generative foundation models. This is a meaningful distinction from GPTBot, whose entire purpose is training data collection.

OAI-AdsBot also does not crawl the open web. It only visits URLs that were explicitly submitted as ad landing pages.

Its User-Agent string:

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

IP ranges: As of June 2026, OpenAI has not published a range file for OAI-AdsBot. The 3 other crawlers each have one (openai.com/gptbot.json, openai.com/searchbot.json, openai.com/chatgpt-user.json), but openai.com/adsbot.json does not exist yet. That gap matters for verification, which is covered in section 3.

Someone submitted one of your URLs as a ChatGPT ad landing page. That submission, not any broad indexing logic, is what triggers a visit.

That advertiser could be your own team, an agency running campaigns on your behalf, or, in some cases, a third party you may not be aware of. OpenAI’s system visits the submitted URL to validate policy compliance, and may return later to refresh its content signals for relevance scoring.

This is worth flagging for security teams: the crawl is not opt-in from the site owner’s side. It is triggered by whoever submitted the URL. If you are seeing OAI-AdsBot in your logs and you are not running ChatGPT ads, the first question to ask is whether an agency, affiliate, or reseller submitted your URL without your knowledge.

In terms of traffic patterns, legitimate OAI-AdsBot visits are event-driven and infrequent. They target the specific landing page URL that was submitted, not sitemaps, directory paths, or unrelated sections of the site. If you are seeing sustained high-volume crawling across a wide range of paths, or activity on domains where you have no active ChatGPT ad campaigns, that is not consistent with how this bot behaves and warrants closer inspection.

OpenAI has not published crawl rate or frequency guidelines for OAI-AdsBot specifically.

How to detect and authenticate OAI-AdsBot

User-Agent matching is a starting point, not a verification method. The string is publicly documented and easy to spoof. Run through the following steps before drawing any conclusions about whether a given request is genuinely from OpenAI.

1. User-Agent identification

Start in your access logs. Look for:

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

This is the string listed on OpenAI’s official crawler page at https://developers.openai.com/api/docs/bots. A match tells you the request is claiming to be OAI-AdsBot. It does not tell you whether that claim is true.

2. Reverse DNS verification

Take the originating IP and run a PTR lookup:

dig -x <IP_ADDRESS>

A legitimate request should resolve to a hostname inside OpenAI’s infrastructure, typically a host under openai.com. If the PTR record points somewhere else or returns nothing meaningful, stop here and treat the request as unverified.

3. Forward-confirmed reverse DNS (FCrDNS)

This step is the one most commonly skipped, and it is the one that actually closes the spoofing gap. Take the hostname you got from the PTR lookup and resolve it forward:

dig <PTR_HOSTNAME>

If the result does not match the IP you started with, the request did not come from OpenAI’s infrastructure. Anyone who controls their own reverse DNS zone can set a PTR record to anything they want, including openai.com. FCrDNS makes that trick fail.

4. IP allowlist cross-check

This step currently has a gap. OpenAI has not published an IP range file for OAI-AdsBot (openai.com/adsbot.json does not exist as of June 2026), so you cannot cross-reference the originating IP against a declared range the way you can for GPTBot or OAI-SearchBot. Keep an eye on OpenAI’s crawler documentation at https://developers.openai.com/api/docs/bots for when that changes.

5. Behavioral fingerprinting

Legitimate OAI-AdsBot traffic is narrow and predictable. Requests go to specific landing page URLs. Crawl volume is low and tied to ad submission events. The bot does not follow chains of internal links or traverse unrelated paths. HTTP behavior is consistent with a headless validation client: no persistent sessions, no JavaScript execution artifacts.

If traffic presenting the OAI-AdsBot User-Agent is hitting a broad range of URLs, crawling at high volume, or accessing pages with no plausible connection to an ad submission, that pattern does not match documented behavior. Treat it as spoofed or abusive.

Should you block OAI-AdsBot?

The answer depends on whether you are actively using OpenAI’s ad platform and on your content control priorities.

If you are not running ChatGPT ads and have no agencies or affiliates doing so on your behalf, there is no good reason for this bot to be on your site. Blocking it is a reasonable call. 

The same applies if you have data governance requirements that restrict automated third-party access to your content, or if you simply do not want OpenAI extracting page content for ad relevance scoring, even absent any model training use.

If you are actively running ads on ChatGPT, the calculus shifts. OAI-AdsBot is what validates your landing pages. Block it, and you may introduce friction into the ad approval process or degrade the relevance signals that determine how your ads get served. If your campaigns are managed by an agency, check with them before implementing a block, as they may be submitting landing page URLs you are not tracking.

On compliance: OpenAI’s documentation does not say that blocking OAI-AdsBot violates its terms of service. That said, if you have a signed advertising agreement with OpenAI, review it before blocking. Ad validation requirements could be part of those terms. If there is any ambiguity, get legal to review it before acting.

One practical note on robots.txt: OpenAI has not confirmed whether OAI-AdsBot honors robots.txt. GPTBot and OAI-SearchBot are documented as respecting robots.txt; OAI-AdsBot is not. If you need a reliable block, server-level controls are the safer option.

How to block OAI-AdsBot

1. robots.txt

User-agent: OAI-AdsBot
Disallow: /

As noted above, OpenAI has not confirmed that OAI-AdsBot respects robots.txt. Use this as a signal of intent, not as a guaranteed enforcement mechanism. For GPTBot and OAI-SearchBot, honoring robots.txt is explicitly documented. For OAI-AdsBot, that documentation does not exist yet.

2. Server-level blocking

Blocking at the server or CDN layer enforces the rule regardless of robots.txt behavior.

nginx:

if ($http_user_agent ~* "OAI-AdsBot") {
    return 403;
}

Apache (.htaccess or VirtualHost):

BrowserMatchNoCase "OAI-AdsBot" bad_bot
Order Allow,Deny
Allow from all
Deny from env=bad_bot

Cloudflare WAF custom rule:

(http.user_agent contains "OAI-AdsBot")

Set the action to Block or Managed Challenge. Bear in mind that User-Agent matching cuts both ways: a spoofed bot can bypass these rules by dropping the string, and a legitimate bot can be impersonated by including it. Layer this with IP-based controls once OpenAI publishes the adsbot.json range file.

3. DataDome’s bot and agent trust management platform

robots.txt and User-Agent matching share the same fundamental limitation: they both take the bot at its word. DataDome’s dedicated bot and agent trust management platform removes that dependency.

With DataDome, OAI-AdsBot can be managed based on verified identity rather than a declared string. That means a spoofed request presenting the OAI-AdsBot User-Agent gets caught, and a legitimate one gets treated correctly. You can allow the bot to reach specific ad landing page paths while blocking it everywhere else, apply rate limits instead of hard blocks if you want to keep ad validation functional, and get a full audit trail of every OAI-AdsBot interaction by URL, timestamp, and response code.

The IP range gap is also relevant here. Because openai.com/adsbot.json has not been published, manual IP allowlisting is not a viable verification layer yet. Bot management platforms like DataDome that maintain their own intelligence databases cover that gap, without requiring you to wait for OpenAI to publish the file.