Should You Chunk Content for LLMs?

Chunking is splitting a document into smaller passages so a retrieval system can embed, index and fetch them. The operator of that system picks the chunk size, the overlap between chunks and where the boundaries fall. That happens after a crawler has fetched your page and stored it.

You publish an HTML page. The engine decides how to cut it. A publisher cannot set how ChatGPT, Perplexity or Gemini segments their page. Our definition of chunking covers the term in more detail.

The advice to "chunk your content for LLMs" takes an operator-side term and turns it into a writing instruction. In practice it usually means:

• Short, self-contained sections with one idea per heading
• Context repeated inside every block so it "stands alone"
• Long pages broken into several shorter ones

Some of that is ordinary good writing. None of it is a mechanism that controls how an engine splits your page. Treat it as a style choice for human readers, not a lever for AI answers.

Google addressed this directly. Its guide to optimizing for generative AI features, dated 10 July 2026, rejects chunking as a requirement and states there is no ideal page length.

The same guide says: "You don't need to write in a specific way just for generative AI search." It adds that you don't have to worry about covering every long-tail variation of how someone might search.

Google's AI features page makes the wider point. To appear as a supporting link in AI Overviews or AI Mode, a page must be indexed and eligible to show with a snippet. Google says there are "no additional requirements" and no "special optimizations necessary."

Two caveats keep this honest:

• Scope. These statements cover Google Search, including AI Overviews and AI Mode. They are not first-party statements about ChatGPT, Claude or Perplexity.
• Type of evidence. Google's statements are assertions about its own systems, not a published experiment. They are still the best available evidence for Google surfaces.

For the other engines, the evidence we track contains no first-party guidance asking publishers to pre-chunk, and no live-engine test showing it helps. If you want the length question on its own, see whether there is an ideal content length for AI search.

The research behind most chunking advice is real and useful. It just answers a different question.

A March 2026 study from the University of Canberra (arXiv 2603.06976) compared 36 chunking methods across 5 embedding models and 6 domains. Every method in it is a segmentation strategy the retrieval system applies to documents it already holds. The study asks: if you run a retrieval pipeline, how should you cut documents?

That is a question for engineers building retrieval systems. It is not a question a publisher gets to answer for ChatGPT or Gemini. Reading it as "publishers should chunk their pages" is a category error. We break down the design and its limits in our write-up of the document chunking study.

What it means for you: if a vendor cites chunking research to sell a content rewrite, ask who performed the segmentation in that study. The answer will be the system operator.

Chunking advice belongs to a larger family of formatting and rewriting tactics. Those have been tested, and the results are weak.

• The 252,000-trial factorial (arXiv 2605.25517) found that "formatting-only edits have little impact." Topical relevance and list position were the biggest drivers of being cited first.
• C-SEO Bench (NeurIPS 2025) found most conversational SEO methods "largely ineffective" and often harmful to document ranking.
• A July 2026 critical survey of 45 GEO studies (arXiv 2607.14035) warned that "citation-oriented rewrites can impair retrieval."

There is a bigger limit. These studies placed documents directly inside the model's context, with no live search. So even their positive findings describe what happens after a page is retrieved, not how it gets retrieved. The same survey concluded that no reviewed technique shows a stable, cross-platform causal effect on discoverability.

Our guide to LLM citation optimization covers these studies in depth. The related myth about phrasing is covered in does an AI-friendly writing style exist.

An AI answer passes through four stages. Chunking sits inside the operator's stages, not yours.

The access stage is where publisher actions have documented effects. Those actions work by removing blocks:

• Server-side rendering of the content that matters
• Per-bot robots.txt permission
• Network reachability through your firewall or CDN
• Index eligibility
• Snippet controls such as noindex, nosnippet, max-snippet and data-nosnippet

One on-page action has a modest positive signal. Stating a specific fact (a price, a number, a one-line definition) on a page that can be fetched gives the engine a sentence it can quote. That's a content decision, not a chunking decision. Nobody can promise it gets used.

If chunking is on your roadmap, replace it with checks that have evidence behind them. Work in this order.

1. Check that your key content is in the raw HTML. Vercel's crawler study found ChatGPT and Claude crawlers fetch JavaScript files but "don't execute them. They can't read client-side rendered content." Googlebot renders JavaScript, so this matters most for non-Google engines. Fetch your page with JavaScript off and confirm prices, product names and definitions are present.
2. Check robots.txt bot by bot. OpenAI's crawler docs say each setting is independent. GPTBot governs training. OAI-SearchBot governs ChatGPT search. A blanket AI block can remove you from ChatGPT search without anyone noticing.
3. Check your firewall and CDN. A CDN can return 403 to a crawler that robots.txt allows. The AI Crawler Checker requests a page as each AI crawler and shows which ones get turned away.
4. Check for accidental suppression. Look for data-nosnippet, nosnippet or max-snippet:0 inherited from a template.
5. State your core facts plainly. Put the price, the number or the definition in one clear sentence on a fetchable page.
6. Then structure for readers. Use headings and short paragraphs because they help people scan, not because an engine needs them.
7. Retire the chunking task. Our playbook on retiring unsupported GEO tasks shows how to explain the change to a team or client.

Rewriting a whole library into fragments

A mass rewrite costs real hours and has no tested benefit. The survey cited above warns that citation-oriented rewrites can impair retrieval. Rewrite a page when it's unclear to people.

Splitting one good page into many thin ones

Breaking content into dozens of short pages to create "chunks" can drift toward a pattern Google's spam policies name. Google defines scaled content abuse as "when many pages are generated for the primary purpose of manipulating search rankings and not helping users." Losing Google's index also removes you from AI Overviews and AI Mode, which require indexing.

Padding or trimming to hit a target length

Google says there is no ideal page length. Googlebot does stop reading HTML after 2MB per URL, but Google says most of the web never hits that limit. Write until the reader has what they need.

Building separate AI versions of pages

Some teams make Markdown copies or stripped-down pages for crawlers. Google says its Search does not use such files. Serving AI crawlers different content from what people see also edges toward cloaking, which is a risk, not a tactic. See whether to offer Markdown versions of your pages.

Overcorrecting

"Chunking is a myth, so structure is useless" is not supported either. Clear headings and focused sections still help readers. The honest line: structure is good writing, not a lever for AI answers.