I exported two ChatGPT conversations a month apart and read the retrieval layer in each. It changed how it searched. It stopped opening pages. Instead, it read a fixed 200-character slice of the page body. It finished the search in one round. What it chose to cite didn’t move at all – 49 listicles retrieved across the two runs, zero cited, in both.
What I looked at
I looked at two B2B software recommendation chats. One was from July 10, 2026, and the other from August 10, 2026. They both used the same gpt-5-6-thinking model.
I read the JSON rather than the answers. I tracked every search the model made, every URL it returned, and every snippet it provided. I also noted which URLs the final answer referenced. 371 unique pages across the two runs.
Most writing about AI visibility describes the output. This focuses on the underlying layer – the part that decides what the model ever gets to see about your site.
Part One: What Changed
It stopped opening pages
Citations in the export carry a type. The “search” tag shows the model cited a snippet from search results. The “view” tag means it opened the page.
| 10 Jul | 10 Aug | |
|---|---|---|
| search citations | 12 | 30 |
| view citations | 3 | 0 |
In July it opened three pages, because the snippets weren’t enough to source a couple of specific claims. In August it opened none – thirty citations, not one page visit.
That single change reshapes everything else. If the model never opens your page, whatever comes back in the snippet is the whole of your case.
And what comes back in the snippet changed
In July, every result carried a search-result snippet – the kind of text a search engine shows on a results page. 123 of them ended in “…Read more”. 63 opened with a date prefix. None were a fixed length.
In August, a different kind of text appeared:
“MODERN MANAGEMENT FEATURES MODERN MANAGEMENT FEATURES IN ENDPOINT CENTRAL Endpoint…”
That’s the rendered page body, starting at the headline, cut at exactly 200 characters.
| 10 Jul | 10 Aug | |
|---|---|---|
| Snippets at exactly 200–203 characters | 0 of 241 | 50 of 198 |
| Snippets ending “…Read more” | 123 | 55 |
| Snippets with a date prefix | 63 | 30 |
| Results carrying a thumbnail | 112 (46%) | 36 (18%) |
| images.openai.com URLs stored | 77 of 105 | 31 of 71 |
August includes both types in the same set: 50 body extracts and 55 classic snippets. This change was not a universal rollout. Body extraction is being applied to some results and not others, inside a single response.
Which is the awkward part for anyone optimising for this. You can’t know in advance whether the model will be shown your meta description or the first 200 characters of your rendered page. Both have to work, because on any given run one of them may be all it gets.
The site: operator was broken in July
This is my favourite thing in the data.
July’s second round issued four searches, each using site: to restrict results to a single domain. Two worked. Two returned nothing at all from the domain they named – and both of those were the smaller sites.
Rather than returning nothing, the engine appears to have dropped the operator and matched on the leftover words – “website”, “integrations”. A sample of what came back instead:
- en.wikipedia.org/wiki/Website
- wix.com/blog/what-is-a-website
- godaddy.com/resources/skills/what-is-a-website
- play.google.com/…id=www.website – an Android app called “Website”
- merriam-webster.com/dictionary/integration
- mulesoft.com/integration/what-is-integration
- bit-integrations.com – a WordPress plugin
Sixteen of the thirty-six results in that round – 44% – were dictionary entries and “what is a website” explainers. It cost an entire extra round: July’s third round did nothing but retry what round two had failed to fetch.
In August, every site: search resolved against the domain it named on the first attempt. No retry round.
So the corpus got tighter
| 10 Jul | 10 Aug | |
|---|---|---|
| Search rounds | 3 | 1 |
| Time taken | 47s | 36s |
| Distinct domains retrieved | 64 | 26 |
| Domains contributing a single page | 35 | 12 |
July’s corpus had a long tail: 35 of its 64 domains contributed exactly one page each, and much of that tail was the junk above – dictionary entries, website builders, an Android app. August’s is a shorter list of more deeply-read sites.
The site: fix and the disappearance of that tail are the same story, and they point the same way: less noise reaching the model, fewer domains competing for its attention.
One new field
A field appeared in August with no July equivalent: inline_cot_expandable_content, carrying a duplicate copy of the search results so the interface can expand them in place.
Two things I want to be careful about. I’m not claiming OpenAI swapped search engines – both runs call the same tool and carry the same internal service marker. And the tool-call format itself was identical in both runs, so this isn’t a wholesale rewrite. It’s the payload and the behaviour that moved.
Part two: what didn’t change at all
Here’s the thing that makes the above worth reading.
Across the two runs, ChatGPT pulled 371 unique pages into its corpus and cited 22 of them. I classified every page by type.
| Page type | 10 Jul retrieved | cited | 10 Aug retrieved | cited | Total | Rate |
|---|---|---|---|---|---|---|
| Product/solution page | 64 | 6 | 106 | 9 | 170 | 9% |
| Editorial blog (non-list) | 37 | 0 | 38 | 0 | 75 | 0% |
| Listicle / “alternatives” | 28 | 0 | 21 | 0 | 49 | 0% |
| Pricing page | 28 | 1 | 10 | 1 | 38 | 5% |
| Homepage | 14 | 2 | 7 | 1 | 21 | 14% |
| Docs/help centre | 7 | 0 | 8 | 1 | 15 | 7% |
| All | 181 | 10 | 190 | 12 | 371 | 5.9% |
Four weeks later, the retrieval layer changed, but the rates stayed the same. Product pages were at 9% and then dropped to 8%. Homepages stayed at 14%, while listicles remained at zero.
124 blog posts and listicles retrieved. Zero cited. All 22 citations came from product pages, homepages, pricing pages or docs.
I checked every cited URL by hand. Not one is a blog post.
26 domains published a listicle. Not one listicle was cited.
Across the two runs, 26 domains put a ranked round-up or comparison page into the corpus. Fifteen of them got no citation at all. Ten had nothing else in the corpus – the round-up was the only page of theirs ChatGPT ever saw.
The eleven that did make the answers were cited on something else:
- One vendor put eight comparison pages into the corpus – X vs Y, the best alternatives to Z. Its citation came from /platform/page.
- Another published two “Best [category] Software” round-ups. It was cited on its homepage.
- A third published a round-up titled “[Our product] Is the #1 Best [category] Software”, ranking itself first on its own site. It was cited from a docs page.
Every one of them published the round-up. Every one got in on something else.
And the tax is regressive
Compare the two runs on one number – the share of listicle publishers that got nothing:
10 July: 75%. Twelve of sixteen. 10 August: 30%. Three of ten.
That gap isn’t the algorithm. It’s the size of the publishers.
July’s set was full of small vendors whose round-up was their only retrieved asset – nine domains had literally nothing else. August’s is dominated by large vendors with deep footprints: one had 28 non-listicle pages in the corpus, another 32, another 22. They published round-ups too, and got cited anyway, on their product pages.
Big domains publish listicles and get cited anyway. Small domains publish listicles and that’s all they get.
The predictor is the column next to the listicle count: how many other pages you have in the corpus.
All ten domains with no other pages got no citation. Ten out of ten. Every domain with fourteen or more pages was cited six out of six, no matter how many round-ups it published. The situation is mixed. Two vendors are on seven pages, and eight pages are missed. Meanwhile, four others made it on eight pages. That middle band is where the tax actually bites.
So a listicle isn’t a wound. It’s a retrieval tax. Retrieval reads a limited number of your pages; every round-up in that set is one page of your own product story that didn’t get read. A vendor with thirty product pages pays it and doesn’t feel it. A vendor whose round-up is the footprint pays it with everything they have.
The question isn’t “should I write listicles?” It’s “do I have enough else for a listicle to be affordable?”
Five things worth testing
- Move your citable facts onto product pages. Every citation here came from a product, homepage, pricing or docs page. Test: take the three claims you most want quoted and put them on a product page, not a blog post.
- Rewrite the first 200 characters of your key pages. That’s the extraction window when body extraction is applied. Test: lead with what the product does and what it costs, then watch whether the text quoted about you changes.
- Assume the page won’t be opened. Zero page visits in the August run. Test: move a pricing or integration claim from mid-page into the opening lines.
- Count your product-surface pages against your blog. If the ratio is 6 to 400, the sample being read is mostly blog and blog scored 0 for 75 here.
- Keep competitors out of your own title tags. Comparison content itself isn’t the problem: an integrations page naming five other products was cited. Ranked-alternatives framing is.
What this isn’t
Two conversations, one model. More than a single test, but not a controlled study.
The behavioural numbers – rounds, timings, how many domains came back – are partly downstream of what each search was looking for. Treat them as what happened in these two runs, not as global constants. The schema and payload findings are cleaner: the 200-character extracts, the thumbnail share, the new field and the zero page opens don’t depend on what was asked.
One more thing, because it cuts in an unexpected direction. The July run had memory and prior conversations available to it; the August run’s export shows none. That’s a real difference between the two – and it makes the citation finding stronger, not weaker. August is effectively a memory-free replication, and it produced the same hierarchy: product pages cited, blog and listicles not.
I can’t tell you why any of this changed. What I can tell you is that the retrieval layer moved noticeably in four weeks, and the thing it rewards didn’t move at all.