ChatGPT Can't Read a New Domain at First: It Took 7 Days

TL;DR

• Two sites on the same server, behind the same outbound IP and with identical robots.txt files, got opposite results: ChatGPT's built-in web tool read one of them and answered "URL is not safe to open" for the other
• The only real difference was age, because the rejected domain had been publicly live for just 5 days
• Requests sent with six AI crawler User-Agents returned 200 on both sites, which rules out server blocking, robots.txt and crawler policy
• Google had already indexed the new domain and started ranking it while the AI tool was still refusing to open it
• Of the three ways the same assistant could reach the site, only the one that needs the user to grant permission by hand got through, and ordinary users never do that
• Before an AI can cite you there is a crawl admission gate, and that gate does not look at content quality
• A re-test on day 12 succeeded, and ChatGPT correctly summarized the site's positioning and company details, so the switch happened somewhere between day 5 and day 12

Contents

Test setup: two sites on the same stack
Ruling out robots.txt and AI crawler blocking
Google indexing versus AI tool access
Three access paths inside one ChatGPT conversation
Crawl admission before AI citation
Limits of this test
Day 12 re-test: from rejected to readable
What to track next on a new domain

Introduction

Most advice on AI SEO starts from the question of how to write content an AI will want to cite, which leads to structured data, clean paragraphs and quotable claims. None of that is wrong, but all of it assumes the AI can read your site in the first place.

This post records an observation I did not expect. Two sites built on the same architecture, hosted in the same place and configured the same way were treated in opposite ways by an AI tool, and nothing was technically wrong with the one that got rejected. Both sites are mine and both are run from Taiwan, and seobar.dev publishes in Traditional Chinese first, but nothing in the result depends on language: the rejection happened before any content was read.

Test setup: two sites on the same stack

The observation came up during a normal ChatGPT conversation. I asked it to read this site, seobar.dev, and its built-in web tool returned:

URL https://seobar.dev/ is not safe to open (non-retryable error)

I then asked it to read another of my sites, wanderlane.blog. It fetched the page, summarized it and even reorganized the content. Going back to seobar.dev produced the same error again.

Both sites run on the same platform:

Both domains resolve to the same set of IPs, so the difference cannot come from the server, the network or a firewall rule, because every request lands in the same place.

Ruling out robots.txt and AI crawler blocking

Before blaming the domain's age, I tested each variable that could produce a false conclusion. I requested both sites directly with real AI crawler User-Agents:

for ua in \
  "Mozilla/5.0 (compatible; OAI-SearchBot/1.0; +https://openai.com/searchbot)" \
  "Mozilla/5.0 (compatible; GPTBot/1.2; +https://openai.com/gptbot)" \
  "Mozilla/5.0 (compatible; PerplexityBot/1.0; +https://perplexity.ai/perplexitybot)" \
  "Mozilla/5.0 (compatible; ClaudeBot/1.0; +claudebot@anthropic.com)" ; do
  curl -s -o /dev/null -w "%{http_code}\n" -A "$ua" https://example.com/
done

OAI-SearchBot, ChatGPT-User, GPTBot, PerplexityBot, ClaudeBot and plain curl all got a 200 from both sites.

That rules out the following:

• robots.txt, since both files are word-for-word identical and allow the whole site
• Server or CDN blocking, since the same outbound IP served the same User-Agents without trouble
• Crawler policy, since no AI crawler was blocked
• HTTPS or certificate problems, since both certificates were valid and connections worked

The only variables left that could explain the difference are the domain itself and how long it had existed. When I checked the server logs a month after launch, AI crawlers had in fact been visiting all along, but half of their requests went to robots.txt and sitemap.xml rather than to content. The numbers are in AI crawlers and sitemap.xml: nearly 80% of sitemap fetches come from AI bots.

Google indexing versus AI tool access

During the same period seobar.dev looked completely normal from Google's side. Within four days of launch, Search Console showed impressions on 6 pages across 4 queries, 55 impressions in total, and one article started ranking the day after it was published, although far down the results.

A domain that Google had already crawled, indexed and begun to rank was being refused by an AI tool before it read a single page.

Search engine indexing and AI tool crawl admission are two separate decisions, so passing the first tells you nothing about the second.

Three access paths inside one ChatGPT conversation

Within that one conversation the assistant had three different ways to reach the site, and each gave a different result.

The built-in web reading tool is a fetching service run by the provider, not a browser on the user's machine. It refused with URL is not safe to open.

A direct network connection sends the request straight from the assistant's working environment. This path requires explicit permission from the user: the assistant asks to allow network access and a person has to approve it. Once approved, the site answered with HTTP 200.

Browser control drives a built-in browser or a connected Chrome. That interface did not fully load during the session, so it produced no result.

Only the second path worked, and it needed a person sitting there to click approve.

For a brand, this matters more than the technical finding, because ordinary users who ask about a brand in a chat never grant network permissions. They get whatever the default path returns, which in this case was nothing.

One more detail is worth recording. When the tool first failed, the assistant told me "this website cannot be read." Only after I pushed back did it correct itself and say its own tool had blocked the request and the site itself was fine. By then the first version had already been shown to the user, and that version made it sound as if the website was broken.

Crawl admission before AI citation

The error says not safe to open, which is neither "the content has problems" nor "the fetch failed." The refusal happened before anything was opened.

This was a URL-level admission decision rather than a judgment about content quality. Plausible inputs include the domain's registration date, how long it has been publicly live, whether third-party reputation databases list it, and the overall risk rating of its TLD. None of these has anything to do with what you wrote on the site.

Technical foundations and content quality are necessary, but they sit behind the gate. The gate itself only looks at the domain's history, and the one thing a new domain can do about that is let time pass.

This also explains a common misdiagnosis. A site is built, the structured data is complete, the content is written, and still no AI cites it, so the owner keeps rewriting the content. If the blockage is at the admission layer, content changes will produce no response at all, because the content is never being read.

Limits of this test

This is a single observation, not a study.

The sample size is one. One new domain and one older domain, tested once each, so chance cannot be ruled out.

Only one tool was tested. That was ChatGPT's built-in web reading tool. Whether Perplexity, Claude or Gemini were refusing at the same time was not tested.

The reason for the decision is not visible. The error carries no code, so "the domain is too new" is an inference, not a verified finding. A TLD classification, a false positive in a third-party blocklist or some entirely different rule could also explain it.

There is only one point in time. This was the state on day 5. It might open up tomorrow or still be blocked three months from now, and there is currently no way to know.

Within these limits, the only safe statement is this: a technically sound new domain can still be refused at the reading stage by AI tools while everything looks normal on Google's side.

Day 12 re-test: from rejected to readable

On September 8, 2026, the twelfth day after the domain went live, I gave the same assistant the same URL and got the opposite result. ChatGPT opened seobar.dev and read the content.

What it extracted was accurate. It said the site offers SEO and GEO (generative engine optimization) consulting, named who runs it and which company it belongs to, gave the company's tax ID number, and noted that the site explicitly does not guarantee keyword rankings. It even picked up the site's methodological point that measurements are repeated because AI answers are random.

The gap between rejected and readable was no more than 7 days.

The actual reply on day 12. The grey marker after each statement is the source it cited, and everything came from the site itself, with no guessed or misattributed details.

The precision of that number needs to be stated plainly. The rejection was observed on day 5 and the successful read on day 12, with no daily checks in between, so the switch can only be placed somewhere between day 5 and day 12, not on a specific day. A tighter number would require testing the same thing every day from launch.

The change also cannot be attributed to a single cause. Several things happened during that week: the domain got older, the number of articles on the site grew from 3 to 8, Google indexing and rankings kept accumulating, and OpenAI does not publish what its decision is based on or how often it updates. Any one of these, or a combination, could be the reason, and this data cannot separate them.

Even so, the observation gives a practical upper bound: for a new domain with its technical basics done right, acceptance by AI tools is measured in weeks, not months or quarters. For anyone deciding whether to launch on a fresh domain, that difference in scale can change the decision.

What it got right is also worth noting. The company name, tax ID number, person in charge and scope of services were not guessed from body text. They are fields a machine can pick up directly once the site has complete structured data and a thorough About page. After the crawl gate opens, the next question is what the AI actually finds when it reads.

What to track next on a new domain

The value of this observation lies less in its conclusion than in the fact that it can be tracked over time.

The number to record is a date: the day the domain went from rejected to readable, counted from public launch.

There is no public data on this, because getting it requires someone to launch a fresh domain, get the technical basics right from the start and then measure the same thing every day. Most people do not think to record it while building a site, and by the time they need the number the domain is no longer new.

That number is now filled in above, bounded at 7 days. The next stage to follow comes after crawling: once a site can be read, how long until it is actually cited when users ask questions, which is an entirely separate decision. The first citation sample was taken on day 17, running 36 queries three times each on ChatGPT and Gemini, and the results are in ChatGPT vs Gemini citations: only 17.8% of sources overlap.

If you happen to have a new domain, run the curl loop above to test the crawl layer, then ask an AI tool to read your URL. If the two results disagree, you may be standing at the same gate.