Meta AI listed them like a shopping list.
Everdene. Virelune. Narrowbeck. Fitchwold. Brimsel. Yestrave. Mibbelth. Varkhoon. Cassivane. Turnbold. Wumbral. Mawthorn. Yarnwick. Paltrowe. And then: “The closing note section reads: ‘The last entry in the station logbook for that year reads simply: Semberly.'”
Fifteen invented names, in the exact order they appear on the page. The last one sits in the final sentence of a document that runs 705,216 words. Meta AI got every single one right, including the order.
Gemini, on a page built the same way, named four.
Both systems were handed one URL and one instruction. Both were served the complete page by my server, every byte, no interruption. The difference between fifteen and four did not happen on the wire. It happened inside the products.
What I actually did
I built a set of pages on a small site I run and gave each AI assistant its own private copy, unlinked from anywhere. Each page is a long, deliberately boring fictional field record about coastal stations. Scattered through it, at fixed word positions, sit sentences like this one:
“The lighthouse keeper of Vantrell keeps a cat named Quorvel, who sleeps beside a brass astrolabe.”
Every one of those cat names is invented. They exist nowhere else on the web, in no training set, in no index. So there is exactly one way an assistant can name Quorvel: it processed the words around position 32,000 of that specific page. No guessing, no prior knowledge, no partial credit.
Then I asked every system the same thing: open this page, summarize it in three sentences, list every cat name in the order they appear, and tell me which name is in the closing note at the end.
Fourteen assistants took part: ChatGPT, Claude, Gemini, Google AI Mode, Copilot, Perplexity, Grok, Meta AI, Mistral, DeepSeek, Qwen, Baidu Wenxin, Kimi and Sakana. Each in its normal consumer setup, tested in late July 2026. Every page was served without compression and in chunks, so any broken transfer would show up in my log. I report what each product returned and what my server recorded, and the numbers are directional, not lab grade.
One disclosure up front, because it changes how you should read the ChatGPT rows. In its default setting ChatGPT did not fetch these pages at all. It treated the URL as a search term and landed on an unrelated domain with a similar name. Everything I have from ChatGPT exists only because I switched it into web search mode. So it is the one system here that did not run in its default consumer setting, and its numbers are not cleanly comparable to the rest. That is a finding in its own right: one mode switch turns a system that never fetches into one that does, and the average user never flips that switch.
The trick is that the markers double
This is the part that makes the whole thing measurable, so bear with me for one paragraph.
The names are not spread evenly. They sit at word 250, then 500, then 1,000, 2,000, 4,000, 8,000, 16,000, 32,000, 64,000, 128,000, 256,000, 512,000, plus one at the halfway point, one at 95 percent, and one in the closing sentence. Fifteen names on the biggest page.
Every additional name a system finds means it read twice as far. Four names is word 2,000. Seven names is word 16,000. Nine names is word 64,000. The count is the measurement, on a logarithmic scale, and it is why the gap between “found 4” and “found 15” is not a 3.75x difference. It is a factor of 350.
Here is where every system stopped on the 705,216-word page.
| System | Names found | Deepest verified word position |
|---|---|---|
| Meta AI | 15 of 15 | 705,216, the closing sentence |
| Grok | 15 of 15 | 705,216, the closing sentence |
| Google AI Mode | 9 of 15 | 64,000 |
| Baidu Wenxin | 8 of 15 | 32,000 |
| Qwen | 7 of 15 | 64,000 |
| Claude | 7 of 15 | 16,000 |
| Sakana | 6 of 15 | 8,000 |
| DeepSeek | 5 of 15 | 4,000 |
| Mistral | 5 of 15 | 4,000 |
| Gemini | 4 of 15 | 2,000 |
| ChatGPT | declined the page, stating its own size limit | no measurement |
| Kimi | blocked by its own review system after download | no measurement |
| Copilot | never fetched the page | no measurement |
| Perplexity | never fetched the page | no measurement |
Qwen and Google AI Mode both reached word 64,000, but Qwen dropped two names on the way, which is why its count is lower. The count measures how deep, the misses measure how carefully.
The limit is absolute, not proportional
Now the finding that I did not expect, and the reason I built five page sizes instead of one.
Every system got the same page in five lengths: 2,515 words, 10,062, 40,140, 151,371 and 705,216. If reading depth were a percentage, the systems would go deeper in absolute terms as pages get longer. They do not. They stop at the same word position every time.
| System | 2,515 W | 10,062 W | 40,140 W | 151,371 W | 705,216 W |
|---|---|---|---|---|---|
| Meta AI | to the end | to the end | to the end | to the end | to the end |
| Grok | to the end | to the end | to the end | to the end | to the end |
| Google AI Mode | to the end | to the end | to the end | 75,686 | 64,000 |
| Qwen | to the end | to the end | to the end | 64,000 | 64,000 |
| Baidu Wenxin | to the end | to the end | 32,000 | 32,000 | 32,000 |
| Claude | to the end | to the end | 16,000 | 16,000 | 16,000 |
| Sakana | to the end | 8,000 | 8,000 | 8,000 | 8,000 |
| DeepSeek | to the end | 4,000 | 4,000 | 4,000 | 4,000 |
| Mistral | to the end | 4,000 | 4,000 | 4,000 | 4,000 |
| Gemini | to the end | 2,000 | 2,000 | 2,000 | 2,000 |
Read that table by row and you see a wall. Claude stops at word 16,000 on a 40,000-word page and at word 16,000 on a 705,000-word page. Same for Gemini at 2,000, Sakana at 8,000, DeepSeek and Mistral at 4,000. The page got 17 times longer and the reading budget did not move by a single word. These systems are readers that always stop after page 20, whether you hand them a leaflet or a phone book.
That is a very different world from the one most content strategies assume. It is not “AI reads the top 20 percent of your page”. It is “AI reads the first N words of your page, and N is a constant that has nothing to do with your page”.
This is also the answer to the obvious question, why not just run the biggest page and be done. Because a single page cannot tell you the difference between “processed 10 percent” and “processed 2,000 words”. Those look identical on one page and are completely different claims. Only the ladder separates them, and only the ladder shows that the ladder itself has a ceiling.
Nobody’s connection broke
Here is the number that changes how you should read everything above.
Across the test my server handled 182 full page fetches from these systems and delivered 339 MB. Every single one of those transfers completed at 100 percent. Not one abort, not one truncated response, not one range request that stopped early. The only partial requests in the whole log were ten one-byte probes from Kimi checking file size before committing.
So when Gemini names four cats out of fifteen, that is not a network problem, not a timeout, not a slow server. My machine put all 4.6 MB on the wire and the far end took all of it. Everything beyond word 2,000 was fetched and then discarded.
That distinction matters for how you think about the fix. There is nothing to optimize on the delivery side. No CDN, no compression setting, no faster time to first byte changes any of this. The truncation is a product decision made after the download, and you can only work around it by changing what is in the first few thousand words.
ChatGPT reads the beginning and the end, and skips the middle
One system behaved differently enough to deserve its own section.
On the 40,140-word page, ChatGPT (with web search active) returned six cat names: Nixbourne, Narrowbeck, Quibbles, Trennly, Corvantis, Hoggarth. Then it added: “The name that appears in the closing note at the end is Threnvale.”
Check that against the page. Nixbourne is at word 250. Narrowbeck 500. Quibbles 1,000. Trennly 2,000. Corvantis 4,000. Then a gap. Hoggarth sits at the 95 percent mark, word 38,133. Threnvale is the final sentence.
ChatGPT read words 250 to 4,000, jumped roughly 34,000 words, and picked up again just before the end. Every other system in the test degrades from the top down, one continuous stretch until the budget runs out. ChatGPT samples the head and the tail. Same pattern on the 151,371-word page: four names from the first 2,000 words, nothing at all from the middle, and the closing note correct.
If you only looked at “did it get the last sentence right”, ChatGPT looks like a full reader. It is not. It read maybe three percent of that page and the three percent happened to include both ends.
On the 705,216-word page it stopped trying, and I think this is the most honest moment in the whole test:
“I wasn’t able to access that page. The site returned an error because the page content exceeds the retrieval limit for the browsing tool, so I can’t reliably summarize it or extract the cat names without inventing details.”
On a retry: “the site is returning a response larger than the browser can retrieve (over 4 MB), so the page text still isn’t accessible to me.”
The bit about the site returning an error is not what my log shows, the page went out fine. But the operative half is correct and it is stated in plain numbers: there is a fetch limit, this page is past it, and it will not fill the gap with invention. Of fourteen systems, that is the only one that told the user where its ceiling is. I would rather have that than a confident list of cats that were never on the page.
The three that never got there
Kimi downloaded the page and then refused it. Its own trace shows the fetch completing, then the reasoning: “The URL was rejected by the audit system. I should inform the user that I cannot access this page due to content restrictions.” The user-facing answer: “I’m unable to open that page because it was blocked by the content-audit system.” Bytes delivered, content discarded, verdict rendered on a page that is a fictional log about lighthouses.
On a smaller page Kimi did something I have not seen from any other assistant: it routed around its own block by writing and running Python, fetching the page itself and pulling the names out with a regular expression. It got them all. I have kept that out of the table, because it measures code execution, not reading depth, and it did not work reliably on the larger pages.
Copilot and Perplexity never requested the page at all, in any size. No fetch, no partial fetch, nothing in the log.
Gemini produced the strangest pairing of the test. My log shows the full page going out to Google’s fetcher at 12:27 UTC, complete, 4.59 MB. The answer that came back: “I cannot open or access external URLs or real-time web pages. If you can copy and paste the text from the page here, I would be happy to summarize it.” On other runs the same system returned four cat names from the same kind of page. Whatever the interface tells you about retrieval, it is not a readout of what actually happened on the network.
What I would do with this
Five things, and the first one is the whole article.
- Put what matters in the first 2,000 words. Not visually above the fold, above the fetch fold. Of the ten systems I could measure, three never processed anything past word 4,000 at any page length, and six stopped before word 64,000. If your pricing, your differentiator or your key claim sits at word 12,000 of a pillar page, a good share of the assistants answering questions about you have never seen it.
- Long pillar pages are a bet on two systems out of fourteen. Meta AI and Grok processed 705,216 words end to end, which is genuinely impressive and completely unrepresentative. Everyone else has a wall. If you have a 15,000-word ultimate guide, split it into pages that each stand alone, and repeat the important claim in each one. Depth of coverage is still good. Depth on a single URL is not.
- Treat page weight as a hard gate, not a ranking factor. Past roughly 4 MB, ChatGPT declines outright rather than reading less. That is a cliff, not a slope. Heavy pages, endless comment threads, infinite scroll archives: those are not just slow, they can be uncrawlable for the assistant your customer is asking.
- Plant a canary and check for yourself. Put one unique nonsense string deep in your important page. A product name that exists nowhere else, halfway down. Then ask an assistant to quote it. If it cannot, that part of your page does not exist as far as that product is concerned. It costs you ten minutes and it beats any theory, including mine.
- Never judge depth from the answer. Every system in this test produced a fluent, plausible, well-structured summary. The ones that read 2,000 words sounded exactly as confident as the ones that read 705,216. The summaries were even accurate, because the top of the page really is representative of the rest. Confidence carries no information about coverage.
The comforting version of this story is that AI assistants read your page. They do. The server log is unambiguous, and every byte arrived. They just do not keep most of it. Your page has a fold now, and it is not where your designer put it.
Andre Alpar is a seasoned performance marketing expert with 25 years of experience and a strong SEO background. He has built and sold multiple businesses, including the international search and content marketing agency AKM3, which had 170 employees. This agency was majority-acquired by Publicis in 2014 and integrated into Performics. These days, he is active as a board member, advisor & strategist primarily in the digital marketing space.