The starting point is a claim from outside our data. In an analysis of the ChatGPT retrieval stack published on 2026-08-17, Olivier de Segonzac reported that on the consumer product, “an opened page ends up cited 74% of the time. A page merely retrieved but never opened, 7%.” That study ran on 1,200 answers, 88,000 search results and 26,900 distinct pages captured by a browser extension. We hold the same layers in our own logs from a different surface, the OpenAI API, so we can ask the question again there. We have written before about which pages ChatGPT cites, and the answer there was that citations are assembled on the search results page. 99.7% of citations matched a URL from the result lists the model was shown, and only 1.2% matched a page it actually opened. That finding is about where citations come from. It says nothing about the rare visits themselves. This piece is about those rare visits. When the model does open a page, what does it open, what does it do inside, and does opening change anything.
Opening a page is the exception, and it stopped being quite so exceptional
DecaGEO logs every step a model takes between a prompt and its answer. Three step types appear in the trace:search (the model issues one or more queries and is shown a list of result URLs), open_page (it fetches the body of one of them), and find_in_page (it searches for a string inside a page it has opened).
Over nine weeks, 2026-07-12 through 2026-09-06, across 6,426 responses:
Data note: DecaGEO retrieval logs, OpenAI API, US, 10 B2B software categories, weeks of 2026-07-12 through 2026-09-06 (weeks start on Sunday), 714 responses per week.
search steps are counted as steps and not as queries, since one step can carry several. The 16,239 steps carried 62,022 queries.
Opening is roughly one page per fifteen answers. But the rate is not flat across the window.
Weekly open_page step counts, out of a constant 714 responses per week. Source: DecaGEO retrieval logs, OpenAI API, US, weeks of Jul 12 to Sep 6, 2026.
gpt-5.4 to gpt-5.6-terra produced 17 and 16 opens. The seven weeks after produced between 49 and 61, every week. Read this as directional and not as a measured generation effect. The earlier model is observed for only two weeks in this window, so its entire observed band is two weeks wide. What we can say is that in the seven weeks under the current model, the lowest week has been nearly three times the highest of the two weeks before it.
What it opens is mostly a pricing page
Classifying all 416 opened URLs by a rule on the host and path:
Data note: same window and population as above, one row per
open_page step. Classification is a rule on the URL, first match wins: help/support/docs/knowledge/developers subdomains or a path containing /docs, /hc/, /support/solutions, /kb/, /help/ or /article(s)/ become docs and help. Then a path containing /pricing, /plans, /price or /subscription becomes pricing. Then a bare root becomes homepage, /blog becomes blog, and /features, /platform, /product, /solutions or /software becomes features. Everything else falls into Other.
Other is 17% of what was opened and it stays as its own row rather than being folded anywhere. Reading the 71 URLs in it, most are capability pages living under vendor-specific names that no generic rule can catch (creatio.com/crm, traackr.com/influencer-discovery-platform, figma.com/ai/), along with PDFs and datasheets on asset hosts (web-assets.zendesk.com/pdf/...) and a handful of terms and policy pages. We leave them unabsorbed so the rule stays generic and anyone can re-run it.
Three opened blog posts in nine weeks, against 178 pricing pages. When the model spends its rarest action, it spends it on the page that states what something costs.
The 47 in-page searches are the interesting part
Afind_in_page step records the literal string the model looked for inside a page it had already fetched. Forty-seven of them exist in our entire log. That is a small number and we are not going to slice it by category or by week. Here is all of it, grouped by what the string was.
Data note: all 47
find_in_page steps in DecaGEO retrieval logs, weeks of 2026-07-12 through 2026-09-06. Duplicate strings are collapsed in the right-hand column and counted in full in the middle one. Grouping was done by hand over the full list.
Thirty-four of the 47 strings are a price, a plan limit, or a plan name. Eight more are feature and contract labels (Webhooks, Lead scoring, Dedicated account team, Indemnif on a Canva legal page), and those deserve as much attention as the money strings, because they are the model checking whether a capability is included in a tier rather than what the tier costs.
And where did it run those searches? Under the same classification rule as the table above, 36 of the 47 were on a pricing or plans URL. Four more were on a bare homepage, and in each of those four the string was either Pricing or $, which is the model landing on a front page and going looking for the price. The remaining seven were three features or product pages, a blog listicle, a Freshdesk support article, a Zoho plan-comparison PDF, and a Canva legal page.
One of those three features pages is the pattern in miniature. On hubspot.com/products/marketing/social-media, a page about social media publishing, the string the model searched for was How much does. It arrives with a price question and runs it against whatever page it has in front of it.
Every one of those strings is a match against rendered page text. A plan name in a comparison graphic, a price injected by client-side JavaScript after load, a tier table in a screenshot, none of them is reachable by a string search. If a page’s $29 is an image, a $29 search on that page has nothing to match against.
Does opening actually pay?
This comparison covers the five weeks from 2026-08-09 through 2026-09-06 and holds everything else fixed: same model, same responses, the only difference being whether the host was opened or only shown in a result list. The unit is a (response, host) pair. A pair counts as cited when the final answer of that same response carries a citation whose hostname is that host.
Data note: DecaGEO retrieval logs, OpenAI API (
gpt-5.6-terra), US, weeks of 2026-08-09 through 2026-09-06. Host is the URL with scheme, path and query string removed. The two rows are disjoint. 244 of the 253 opened pairs also appeared in a result list, and they are counted in the opened row only. Leaving them in both rows moves the second row to 53,717 pairs and 19.1%.
Citation rate per (response, host) pair, opened hosts against hosts shown in results but never opened, week by week. Source: DecaGEO retrieval logs, OpenAI API (gpt-5.6-terra), US, weeks of Aug 9 to Sep 6, 2026.
Most of the gap is how often the host showed up at all
The model does not pick which page to open at random, so the two rows of that table are not two random halves of one population. Count, inside each response, how many times a host appeared across all the result lists the model was shown, and split both populations by that count.
Data note: same five weeks, same pairs, same host definition. The count is result entries for that host in that response, not distinct URLs, since the same URL can be returned by several of the fan-out queries. The “shown only” columns sum to the 53,473 pairs and 10,177 citations in the previous table. The opened columns sum to 244 rather than 253, because nine opened hosts never appeared in a result list at all. Three of those nine were cited.
The first row carries the 19.0%. Forty percent of the hosts the model was shown appeared exactly once in that response, and those are cited 0.6% of the time. Drop that row and the rest of the shown-only population is cited at 31.3% (10,051 of 32,115). Opened hosts are not distributed like the shown ones. They average 4.47 result appearances against 3.78.
Follow the two rate columns down the table and the advantage narrows at every step, and in the bottom row it is gone. Among hosts the model saw five or more times, being opened is associated with a lower citation rate (34.1%) than not being opened (36.5%), on 82 pairs against 14,569.
So “opening roughly doubles the rate” is true as stated and misleading as an instruction. Opening and citing are both downstream of a third thing, how insistently the host keeps coming back in the fan-out. What survives the split is narrower. For a host the model has seen only once or twice, an open is associated with a large jump. For a host it has already seen five times, opening adds nothing we can detect.
The opened page that gets cited is usually not the pricing page
Splitting the same 253 opened pairs by what kind of page was opened turns the intuitive story upside down.
Data note: same 253 pairs, same window, same classification rule as the earlier table. We read all 253 URLs by hand to check the rule rather than trusting it. Row counts under about 30 are directional only.
The pricing page is the page the model opens most (115 of the 253 pairs) and cites least (30 of those 115, 26%). The docs or help article is the page it opens second-most (50 pairs) and cites most (40 of 50, 80%). Two checks on that 80% before leaning on it. Forty-two of the 50 sit on a host whose first label is one of
help, support, docs, developers, knowledge, crmsupport or helpcenter, and 38 of those 42 were cited, so the effect is not carried by a few odd rows. Those subdomains also carry few other URLs, which means host-level matching is if anything stricter there than on a marketing domain, where any cited URL on the domain counts.
And the two page types are not separate topics. Twenty of those 50 docs and help URLs have “pricing” or “plan” in the address (help.brevo.com/.../About-Brevo-s-pricing-plans, support.omnisend.com/.../omnisend-pricing-plans-2026, docs.midjourney.com/.../Comparing-Midjourney-Plans), and 17 of those 20 were cited.
The working model we take from this is a mechanism rather than a proven chain. A marketing pricing page is where the model goes to verify a number, and a help-centre plan article is what it is willing to name as the source. That is consistent with what we found on the results surface, where citations are picked from result lists and a docs page is a more quotable result than a marketing page. It also means the two surfaces are not competing. You want the price checkable on the pricing page and explained on a documentation surface.
Independent evidence, and its limits
A controlled experiment supports the price half of this from outside our data. “What Gets Cited: Competitive GEO in AI Answer Engines” (Vishwakarma, Kumar and Jamidar, SIGIR ‘26, DOI 10.1145/3805712.3808445) ran 252,000 head-to-head trials in which two documents compete for the first citation, across six models. The authors name four factors as gatekeepers, “unanimous across all six models with large effects”, and one of the four is Price Not Mentioned. Their phrasing is that failing on any one of the four “can eliminate citation odds regardless of other content strengths”. Two cautions travel with that. Their corpus is 50 B2C product categories with two review blog posts each, which is consumer review content and not B2B vendor sites. And their six models (Gemini-2.5-Flash, GPT-5-Nano, GPT-5-Mini, GPT-5.2, Claude-3.5-Sonnet, Kimi-K2-Thinking) do not include the model we observe. When the paper reports an odds ratio as “>>10k”, that is not a multiplier to quote. The authors state that “when preference is nearly deterministic, estimated ORs become very large under quasi-separation, we report them as >>10k where applicable and treat them as indicating a decisive win for variant A”.A check we also ran
We looked for the same pattern in DecaGEO’s own page-audit data and could not use it. Once the counts are normalised, the share of pricing-related patterns is flat across rank bands (9.8%, 9.9%, 11.4%). The audit data supports no pricing claim in either direction.What the data suggests doing
Everything below is observational. These are patterns in what the model did, not outcomes measured after a site changed anything, so they are working hypotheses and the list is written as such.- Prices, plan names and limits as selectable page text. The 47 in-page searches are literal string matches.
$29,Standard,10,000andWebhookseither exist as text on the rendered page or they do not. Anything living only in an image, a canvas, or a script that runs after fetch is out of reach of the one action where the model is explicitly looking for it. - Tier labels a buyer would type. The six plan names in the 47 are
Basic,Core,Flex,Pro,StandardandFreshdesk Omni. Five of the six are ordinary words. That is an observation about these 47 steps and not a measured claim about naming in general. - A feature-to-tier mapping in text, not only in a graphic. Eight of the 47 strings were a capability or contract label rather than a price.
Lead scoring,WebhooksandDedicated account teamare the model asking which tier includes a thing. - The plan explanation on a documentation surface as well as a marketing one. In our data the opened page that ends up cited is the help-centre plan article far more often than the marketing pricing page, 40 of 50 pairs against 30 of 115.
- Repeat appearances in the result lists, ahead of any of the above. The depth table carries the widest gap on this page, and a host that surfaces once is barely cited at all whatever its pages contain. A page that never reaches a result list is not in any of the other populations here, and a
site:yourdomain.com pricingquery that returns nothing is the version of that problem you can check in a browser.
FAQ
Does ChatGPT read my pricing page?
Rarely, and less often than it reads your result-list entry. In DecaGEO’s logs for the nine weeks ending 2026-09-06, the model opened a page 416 times against 16,239 search steps, roughly once per fifteen answers. When it did open something, 43% of the time it was a pricing, plans or subscription page.What is find_in_page?
A step in the model’s retrieval trace recording that it searched for a literal string inside a page it had already opened. We have 47 of them in nine weeks. The strings are visible in the log, and they are mostly prices ($29, € / month), plan names (Pro, Standard) and plan limits (10,000).
Does getting my page opened make a citation more likely?
In our five-week window, hosts the model opened were cited in that response 39.5% of the time (100 of 253 pairs), against 19.0% for hosts that only appeared in the result list (10,177 of 53,473 pairs). That headline gap shrinks once you account for how often the host appeared in the results at all, and among hosts seen five or more times it disappears (34.1% opened against 36.5% not opened). Traces show actions and not reasons, so none of this establishes that opening causes citation.Should I move my pricing into my documentation?
Our data suggests adding, not moving. Pricing pages are what the model opens to check a number. Help-centre plan articles are what it opens and then cites, at 80% of 50 opened pairs. Both surfaces are doing different jobs in the same answer.Why can’t the model find prices rendered in JavaScript or images?
Because the action in question is a literal text search on the fetched page. A$29 search returns nothing if the page text does not contain $29. We have not measured this failure directly, since a find_in_page step in our log records the string searched for and not whether it was found. The inference is from what the mechanism is, not from a measured miss rate.
How we measured
DecaGEO issues a fixed grid of brand-free commercial prompts weekly through the OpenAI API (US) across 10 B2B software categories, and records what the model searched, opened and cited for each answer. The model label on those runs changed once in the period, fromgpt-5.4 to gpt-5.6-terra, at the week of 2026-07-26.
Two windows, not interchangeable. Step counts, the 416 opened URLs and the 47 in-page searches use 2026-07-12 through 2026-09-06 (nine weeks). The opened-against-shown comparison uses 2026-08-09 through 2026-09-06 (five weeks), the span in which a “shown in results” population exists to compare against. No figure here mixes the two.
The unit for the citation comparison is a (response, host) pair, deduplicated. Host is the URL with scheme, path and query string stripped, so www.klaviyo.com/pricing?x=1 and www.klaviyo.com/pricing are one host. A pair counts as cited when the model cited any URL on that host in that same answer. There is no vendor filter and no page-type filter, so every host the model saw or opened is in the population.
The 53,473 / 10,177 / 19.0% in the comparison table is the shown-in-results population with the 253 opened pairs subtracted. Leaving them in gives 53,717 / 10,274 / 19.1%. The opened pairs are 0.5% of the shown population and cannot move it.
Page classification is the host-and-path rule printed in full in the data note under the second table, first match wins. All 253 URLs in the five-week set were read by hand to confirm it was not mislabelling. The 47 in-page searches were pulled in full with their URL and search string; the grouping into six rows was done by hand on that list. Nothing was sampled.
Limitations.
- The in-page search sample is 47 steps. It is a positive observation (these searches happened, these strings were used), which is what it is being used for. It is not a rate, and it cannot be split by category or week without dissolving.
- The opened-against-shown gap is adjusted for exposure depth and nothing else. Splitting by how often the host appeared in the results removes most of it and reverses the sign in the deepest stratum. Category, vendor size and what kind of page the host mostly offers are not controlled for, and with 253 opened pairs they cannot be stratified further without the cells emptying.
- A trace records actions, not intentions. Every causal reading in this piece is an interpretation of a sequence of logged steps.
find_in_pagerecords the string searched for, not whether it was found. The claim that image-rendered prices are unfindable follows from what a string search is, not from a measured miss rate.- Host-level matching is coarser than URL-level matching. Our earlier page-type analysis matched at URL level, so its rates are not comparable to these.
- One surface, one query spectrum. Brand-free commercial category prompts issued through the OpenAI API in the US. Consumer ChatGPT, other regions, and navigational or support queries are different populations and nothing here should be carried to them unconditionally.
- The generation comparison rests on two weeks of the earlier model, which is its entire observed band, not a sample of a longer one.
DecaGEO tracks how AI engines recommend and cite software brands, weekly, category by category. See the live category boards.