Most AI visibility tracking focuses on the final answer.
Did ChatGPT mention your company? Did it cite your website? Did it link to one of your pages?
But there is an earlier step that matters just as much.
Before ChatGPT can cite your website, it first has to find it.
When ChatGPT researches companies, products, or vendors, some of its searches are aimed at specific domains. Sometimes those searches return pages from the website it was looking for.
Sometimes they return nothing.
And that creates an important question for anyone working on AI visibility:
What happens when ChatGPT searches your website and gets nothing back?
Does it try again with a different query? Does it change how the search is scoped? Or does it simply move on to another company?
I went through three exported ChatGPT conversations from July and August 2026 to find out.
The behaviour was noticeably different a month apart.
In July, I found cases where ChatGPT searched a domain, got nothing back, and made no dedicated second attempt.
In August, ChatGPT started going back for domains that had just gone silent. And in one conversation, when the second attempt also failed, it switched to another search type.
There was another pattern worth paying attention to.
In the security-vendor conversation, every vendor ChatGPT retried eventually appeared in the final answer. The two vendors it did not retry were also the two that disappeared from the answer.
That does not prove the failed searches caused their exclusion.
But it shows why the retrieval step matters.
TL;DR: What I Found in ChatGPT’s Search Behaviour
I analysed three ChatGPT conversation exports from 5 July, 24 August, and 26 August 2026.
In July, I found domains that ChatGPT searched once, failed to retrieve, and did not specifically search again.
In August, I found two examples where the next search matched the domains that had just failed.
In one of those conversations, five domains failed again on the second attempt. ChatGPT then switched to a different search type called slow, and all five returned results.
The sample is small.
There are two examples of an exact retry and one example of escalation to the slow search type.
So this is an observation of how ChatGPT search behaved in these conversations, not a claim that every ChatGPT search follows the same process.
What I Analysed
The three conversations covered very different topics.
The 5 July conversation was about shirt brands under ₹6,000.
The 24 August conversation was about penetration-testing vendors.
The 26 August conversation was about choosing a MacBook for SEO work.
Instead of analysing only ChatGPT’s answers, I looked at the searches happening underneath them.
The conversation export records the searches ChatGPT wrote, the domains those searches targeted, and what came back.
That gives us a view into the retrieval layer — the stage that determines what information ChatGPT gets to see before it writes the final answer.
There is one important caveat before we get into the evidence.
The July conversation used gpt-5-5-thinking. Both August conversations used gpt-5-6-thinking.
The questions were different too.
So this is not a controlled experiment where one variable changed and everything else stayed the same. It is a comparison of three real ChatGPT conversations.
With that in mind, the search sequences are still revealing.
In July, a Failed ChatGPT Search Could Simply End There
The July conversation gives us a useful baseline.
On 5 July, ChatGPT searched for the clothing brand Snitch and explicitly named snitch.co.in.
Nothing from Snitch came back.
Later in the same conversation, ChatGPT searched linenclub.com.
Again, nothing from the named website came back.
Neither domain received a dedicated second search.
The conversation simply continued.
That matters because both brands had already made it into ChatGPT’s search process. ChatGPT knew about them and had decided they were worth checking.
But once those domain searches came back empty, there was no clear recovery attempt.
For Snitch and Linen Club, one failed search was the end of the line.
That is the July baseline.
ChatGPT’s Search Tool Changed Before the August Tests
Something else changed between the July and August exports.
Suganthan Mohanadasan documented a rewrite of ChatGPT’s search-call format on 21 August.
Using captures from the same account, he found JSON-style search calls on 16 August and the newer pipe-delimited format on 20 August.
That gives him a much tighter window for the format change than my exports can establish.
I am not going to re-document that syntax here. He has already done that work.
The question I am interested in comes after the search is made:
What does ChatGPT do when that search fails to return the website it was looking for?
The August conversations give us a clearer answer.
In August, ChatGPT Started Going Back for Missing Domains
On 24 August, I asked ChatGPT to recommend penetration-testing vendors.
Its first search targeted eight vendor domains.
Five returned no results from the named domain: Bishop Fox, HackerOne, NCC Group, SecureLayer7, and TAC Security.
The next search went back for three of those five: Bishop Fox, HackerOne, and NCC Group.
SecureLayer7 and TAC Security were not searched again.
The second pass also searched NetSPI again and introduced two additional vendors: Astra Security and QualySec.
So this first transition was not a perfect retry of everything that had failed.
But Bishop Fox gives us a useful example of why a second search can matter.
Bishop Fox First Returned Nothing, Then Seven URLs
The first Bishop Fox search was:
fast|site:bishopfox.com penetration testing services Bishop Fox|3650
No Bishop Fox result came back.
Instead, the search returned results from other domains, including UnderDefense, Cobalt, Stingrai, Synack, and NetSPI.
ChatGPT then searched Bishop Fox again using a different form of domain scoping:
fast|Bishop Fox penetration testing services official|3650|bishopfox.com
This time, seven Bishop Fox URLs came back.
They included its services pages, penetration-testing pages, get-started page, and homepage.
Same company.
Same conversation.
The first search returned nothing from Bishop Fox. The second returned seven URLs.
The important difference is the two scoping styles Suganthan documented: putting the domain inside the query versus passing the domain separately.
Here you can see that Bishop Fox search is not there.
One search later, you can see Bishop Fox was searched seven times.
This matters because it is very easy to see a failed domain search and conclude:
“ChatGPT can’t find my website.”
But that is not what this example proves.
The evidence only tells us that one search formulation failed to return Bishop Fox.
A different formulation found seven pages immediately.
That is a much more useful distinction.
The Clearest Retry Came One Search Later
The next step is where the pattern becomes much stronger.
After the second search, five domains were still returning nothing:
NetSPI, HackerOne, NCC Group, Astra Security, and QualySec.
Nothing was added.
Nothing was removed.
Every domain that had just failed became a target in the next search.
And this time, ChatGPT changed the type of search it was using.
The earlier searches were labelled fast.
The new searches were labelled slow.
All five domains returned results.
That exact match between the failed domains and the next search is why this looks like a retry process rather than ordinary search expansion.
Suganthan documented a related case involving Profound.
In his capture, ChatGPT initially searched profound.ai even though the company uses tryprofound.com. That search returned nothing, but a later broader search found the correct domain.
He was cautious about interpreting that as a reliable recovery mechanism.
That caution is appropriate.
What makes this August capture interesting is that the next search was aimed precisely at the domains that had just failed.
The Same ChatGPT Retry Pattern Appeared Again Two Days Later
The 26 August conversation gives us a second example.
I was searching on ChatGPT for the recommendation of MavBook for the person who is into SEO.
ChatGPT was researching which MacBook would be suitable for SEO work.
One search targeted Apple and Screaming Frog.
Apple returned seven results.
Screaming Frog returned none.
The next search focused only on Screaming Frog and reformulated the terms using quotation marks.
Five Screaming Frog results came back.
This time, ChatGPT did not need the slow search type.
So the August exports contain two examples of exact retry behaviour.
On 24 August, five failed domains were all searched again.
On 26 August, the single failed domain was searched again.
The deeper slow-search step appears only once.
That distinction is important.
I have two examples of retries.
I have one example of escalation to slow.
The Vendors ChatGPT Retried Also Made the Final Answer
The penetration-testing conversation has another pattern worth looking at.
Cobalt returned six results in the first search and appeared in the final answer.
Synack returned one result in the first search and eleven in the second. It appeared in the final answer.
Bishop Fox returned nothing initially, then seven results on the retry. It appeared in the final answer.
NetSPI returned one result in the first pass, nothing in the second, and seven in the third. It appeared in the answer.
HackerOne returned nothing in the first two searches, then six results in the third. It appeared in the answer.
NCC Group followed the same basic pattern: no results in the first two passes, followed by seven in the third. It appeared in the answer.
Astra Security and QualySec first appeared in the second search. Both returned nothing there, both were searched again in the third pass, and both returned seven results.
Both appeared in the final answer.
Then there were SecureLayer7 and TAC Security.
Both were searched in the first pass.
Neither returned a result.
Neither was searched again.
Neither appeared in the final answer.
Among the five domains that failed in the first pass, three were searched again.
All three made the final answer.
Two were not searched again.
Neither made the final answer.
That is three out of three compared with zero out of two.
Outcome table showing results by pass and whether each vendor appears in the final answer. Keep all result counts visible and visually emphasise SecureLayer7 and TAC Security.
Both missing companies are Indian security vendors, but the more important point is that ChatGPT itself had already introduced them as candidates.
It knew about them.
It intended to check them.
Each received one silent search.
Neither received a second attempt.
Neither survived into the final answer.
That does not prove that retrieval failure caused their exclusion.
The export cannot tell us that.
ChatGPT may simply have revised its shortlist for another reason.
The defensible observation is narrower:
The two vendors that were not searched again are also the two that did not make the final answer.
ChatGPT Search Results Are Not Stable From One Query to the Next
NetSPI gives us another useful lesson.
The first search returned one NetSPI result.
The second returned nothing.
The third returned seven.
Same company. Same conversation. Three different retrieval outcomes.
That means ChatGPT website visibility is not necessarily stable even within a single conversation.
A successful search does not guarantee that the next query will find the same site.
And one failed search does not prove the domain is unavailable.
The search formulation matters.
For anyone measuring AI visibility, this is a reason to be cautious with one-query tests.
ChatGPT Also Used a Second Search Type
Across the two August conversations, I counted 33 relevant search-tool lines.
Twenty-seven were fast searches. Five were slow searches. One was a product search.
The important part is not simply that slow was rare.
It is where those five slow searches appeared.
All five happened together in the security-vendor conversation, immediately after the fast searches had failed again on those same domains.
The slow searches also differed from the fast ones in several ways.
Suganthan documented the third field in fast searches as a freshness window measured in days.
The slow searches I found did not contain that field.
All five also used quoted, exact-phrase search terms.
And their results included snippet text.
The slow pass returned 34 snippets ranging from 122 to 164 characters, with an average length of 152 characters.
The fast results in that same conversation did not include snippet text.
I would not interpret this as evidence that the slow search is reading entire pages.
The export does not support that conclusion.
The safer finding is simpler:
A second search type exists, and in this conversation ChatGPT used it after repeated failures on the same domains.
No slow line appears in Suganthan’s published write-up.
If this search type only appears under a relatively narrow failure condition, that absence would make sense. Most searches may never need to reach it.
But with one example, we cannot establish a universal trigger.
You can check this by searching for the “web.run” in the JSON file.
The results are stored separately in metadata.search_result_groups.
Those two fields answer different questions.
content.text tells you what ChatGPT searched for.
search_result_groups tells you what came back.
Most of this analysis comes from comparing those two things in chronological order.
For example, in the 24 August conversation, one search asked for seven domains.
Only two returned results.
Five were missing.
The next search named those same five domains.
That is the retry.
There is one limitation worth understanding.
The export does not contain a field that literally says “zero results.”
When I describe a domain as silent, that is inferred from absence.
The search explicitly names the domain, but no result from that domain appears in the corresponding result groups.
The method also only works when a search names a domain.
Open-web searches do not provide a specific domain to compare against.
This Is Search, Not Crawling
There is another technical distinction that matters.
These exports show searches and search results.
They do not show whether a crawler tried to visit your server and failed.
So when I say ChatGPT searched Bishop Fox and returned nothing, I mean that the scoped search did not return a Bishop Fox result.
I do not mean that ChatGPT tried to crawl bishopfox.com and the website blocked the request.
Those are different questions.
If you want to know whether an AI crawler actually visited your website, server logs are the better source of evidence.
A Failed ChatGPT Search Does Not Mean Your Website Is Not Indexed
This may be the most practical takeaway from the entire analysis.
Bishop Fox failed on one search and returned seven URLs on the next.
NetSPI appeared in one search, disappeared in another, and then returned seven results later in the same conversation.
So be careful with statements like:
“ChatGPT cannot find our website.”
Usually, you do not know that.
What you know is:
“One search formulation did not return our website.”
That is a much more useful problem to investigate.
The difference could come from domain scoping, the language used in the query, entity clarity, how your category is described on your website, or simple retrieval instability.
And importantly, a failed search does not prove that a website or page is not indexed.
These exports cannot establish that.
Two Simple ChatGPT Visibility Tests to Run on Your Website
You do not need to reproduce ChatGPT’s entire search system to learn something useful from this.
I would start with two simple checks.
Test 1: Search Your Domain With Your Main Category
Search:
site:yourdomain.com your category
Look at what surfaces.
Do your important commercial pages appear quickly?
Does the query return unrelated pages?
Does it struggle to surface your website at all?
This roughly approximates the first Bishop Fox search.
The goal is not to recreate ChatGPT’s retrieval system perfectly.
You are testing whether your site resolves clearly for the category you want ChatGPT to associate with your company.
Test 2: Repeat the Search With the Category in Quotes
Then run the same category or service phrase in quotation marks.
Exact-phrase reformulation was enough to recover Screaming Frog in the 26 August conversation.
Again, this does not reproduce ChatGPT’s internal search process.
It tells you whether the visibility of your website changes substantially when the search becomes more specific.
If it does, you may not have an indexing problem.
You may have a query-sensitivity problem.
What This ChatGPT Search Analysis Does Not Prove
Three conversations are not a study.
The July conversation used a different model version from the August conversations.
The questions covered different industries and different types of recommendations.
Even the two August conversations, captured only 48 hours apart, did not behave identically at the platform level.
The sample sizes also need to remain separate.
I found two instances where the next search exactly matched the domains that had just failed.
I found one instance where repeated failure was followed by the slow search type.
Those are observations, not universal rules.
A failed domain search also does not prove that your website is not indexed.
And this analysis cannot tell us why OpenAI designed the search process this way.
What it can show is a behaviour worth watching.
In July, I found domains that failed once and received no dedicated second attempt.
In August, I found two conversations where ChatGPT went back for the domains that had just failed.
And in one of those cases, another search type appeared after repeated failure.
For anyone working on AI visibility, that changes the question.
It is no longer only:
Did ChatGPT find my website?
It is also:
What happened after it didn’t?