What Your Ad Landing Page Must Expose to OpenAI's Crawlers

Your landing page opening in your browser does not prove an ad crawler can read it.

Your browser may have a session, a remembered challenge, or access from an allowed region. A crawler may have none of those. I would check the response it receives before rewriting the page or resubmitting the same ad.

OpenAI’s advertiser crawler guidance identifies OAI-AdsBot as required for landing-page review. It recommends also allowing OAI-SearchBot and specifically calls for SearchBot access to product-feed image URLs. The broader ad-creation page tells advertisers not to block either bot. For a launch checklist, verify both on the public destinations involved.

That is an ads-access requirement, not evidence that an organic ChatGPT answer will cite you.

Separate permission from delivery

Robots rules describe permission to crawl. They do not open a firewall, remove a login, or make a page return useful content. Under the robots exclusion protocol, an absent matching restriction does not require an extra Allow rule just to permit the path. A missing file and an unreachable robots service are also different cases; inspect the actual response.

OpenAI recommends checking robots, CDN or firewall rules, human-verification challenges, authentication and rate limiting. Its guidance also points to published crawler IP ranges and provider verification. A user-agent string alone is not authentication. Keep any exception scoped to verified crawler traffic and the public content you intend to expose.

A small evidence packet beats “it works for me”

This is the diagnostic handoff I would send to whoever operates the site:

Capture	Why it helps
Exact submitted URL, including redirect destination	The ad and the browser may end up on different pages
Request time and timezone	Lets the engineer find the corresponding edge and application logs
HTTP status and whether the body is the landing page or a challenge	A successful-looking status can still contain the wrong document
Relevant robots rule for the specific bot and path	Separates crawl permission from other access failures
Matching CDN rule or application denial, if one exists	Identifies a cause instead of guessing from a screenshot
Image host and image URL for a product feed	The main site working says nothing about a separate asset host
Result after the narrow fix	Confirms the original URL now works without broad security changes

Do not put credentials, visitor records, or raw private logs in a public support thread. A minimal redacted request example is usually a better starting point.

A fictional failure, worked through

Suppose a retailer’s ad fails review. The public product page works in a logged-out browser. Robots permits the page. An engineer then finds the review-time request was denied by a custom CDN rule.

In this hypothetical, the matching log record is the evidence. “We use Cloudflare” would not be enough to blame a default setting, and “robots looks fine” would not clear the whole request path.

The engineer verifies the crawler identity, narrows the relevant rule for the intended public page, and checks the next request. No login is disabled. No private path becomes public. If the page still fails review, the team has ruled out one cause; it has not proved every other requirement passed.

OpenAI advises resubmitting affected ads if their status does not update after access is fixed. That is the last step, not the diagnostic method.

Start with the exact failed destination and a timestamp. Those two facts make the next conversation with engineering much shorter.