Your page ranks on Google, and yet ChatGPT keeps citing someone else. That gap has a name, and it lives inside how your content gets sliced. Before an AI engine can cite you, it breaks your page into small pieces called chunks and judges each one on its own. A chunking audit is how you see those pieces the way the machine does, find the ones that fall apart when they stand alone, and fix them. This guide walks a marketing lead through that exact LLM retrieval audit, step by step, so each retrievable chunk on your page carries a complete answer.
You do not need an engineering degree for this. You need a few free tools, a short checklist, and about an afternoon on your most important pages. Let's start.
Why chunking decides which pages AI cites
Here is the thing most SEO audits miss. AI engines cite pages based on retrievability, not ranking. Analysis of how large language models pick sources shows retrieval and citation run on semantic relevance, entity clarity, and how cleanly a passage lifts out, not on backlink authority. Roughly 88 percent of Google AI Mode citations come from pages outside the organic top ten. Flip that around, and only about 12 percent of AI-cited URLs also rank in Google's top ten for the same query.
So a page can sit at position three and still be invisible in ChatGPT, Perplexity, or Gemini. That is not a bug in your SEO. It is a different game with a different scoreboard.
Chunking is where that game is won or lost. When researchers changed the chunking strategy on the same content, retrieval recall swung by up to nine percentage points. That is a big move for something you never see. The three predictors that keep showing up in citation studies are earned authority, entity clarity, and citation architecture. This audit targets the third one, because it is the one fully under your control.
Quick language check before the steps. A chunk is a contiguous slice of your page that an engine treats as one addressable unit. Retrieval is the moment it pulls chunks that match a prompt. Citation is when it surfaces your URL as the source. A page can be retrieved and still not cited if the chunk does not answer cleanly. This guide assumes you already grasp roughly how chunking works, so we spend our time on the audit itself, not the mechanics.
What a healthy chunk looks like (and a broken one)
You cannot fix what you cannot picture, so let's make this concrete.
A healthy chunk answers a buyer question completely, even when you rip it out of the page and hand it to someone cold. It has six properties. It names its subject in plain text, no "this approach" or "it." It signals its role, so you can tell in seconds whether it defines, compares, warns, or instructs. It carries one complete answer to one question. It states its boundary, what the claim does and does not cover. It makes its proof status visible, so an observation does not read like a hard fact. And it sits early, in the first 100 to 200 words of its section, not buried under a long intro.
A broken chunk loses meaning the moment it is lifted out. Broken chunks come in three shapes, and naming the shape tells you the fix.
Shape A is the split answer. A definition or a numbered step starts at the bottom of one chunk and finishes at the top of the next. The retriever grabs half. Usual cause: a fixed-token chunker with no overlap that ignores your headings.
Shape B is the buried answer. The real answer sits in the middle of the chunk, wrapped in preamble and throat-clearing. All that fluff drags the chunk's meaning off-topic, so the retriever scores it low and skips it.
Shape C is the orphaned answer. The chunk leans on pronouns and back-references like "as mentioned above" or "this matters because." Those resolve on your full page but not in isolation. Lifted out, the chunk is a mystery.
Here is the difference in one pair. Broken: "This matters because it can improve visibility and make systems more likely to use the page." Vague, no subject, no scope. Healthy: "AI citation readiness improves the likelihood that a page can be accessed, retrieved, and cited by AI answer systems, but it does not guarantee the final answer preserves your exact meaning." It names the concept, the mechanism, and the limit. That is a chunk that can stand on its own.
Keep those three shapes in your head. The rest of the chunking audit is finding them and fixing them.
Step 1: Pull your highest-value pages and the prompts you want to win
Start with two lists, not your whole site. List one is the pages you most want cited. List two is the buyer questions you most want to win.
Do not try to boil the ocean here. Pull your top ten pages by importance, and the ten to twenty prompts that map to real buying moments. This is your triage list, and it is where every later step points.
This is a spot where a tracking layer earns its keep. If you run DeepSmith, the AI Visibility Prompts view holds the buyer questions you already track, and the Pages view shows which of your pages AI actually pulls today. Start your audit on the pages the engines are already trying to cite, then work down. Its Sitemap classification tags each page by topic, type, and buyer stage, so thin pages surface before you even open a visualizer.
How to tell this step is done: you have a short, ranked list of pages and a matching set of prompts sitting in one place. Where people go wrong: they audit low-traffic pages no one is searching for, and burn the afternoon before touching the page that matters.
Step 2: Test how AI chunks my page with a visualizer
Now you look at a real page through the machine's eyes. When you type "test how AI chunks my page" into a search bar, this is the tool you are looking for.
Paste your page's body text into a chunking visualizer and watch where the splits land. A few free options, each good at something different.
ChunkViz, built by Greg Kamradt, is the fastest eyeball check. Free, no signup. Paste text in, pick a chunker, set chunk size and overlap, and the tokens render colored by chunk. Try chunk sizes of 256, 512, and 1024 tokens with 10 to 20 percent overlap, and watch how the answer boundaries move.
The LangChain Text Splitter Visualizer, a free Streamlit app, is better for comparison. It runs several splitters side by side, so you can prove a heading-aware split beats a token-only split on the same page. For a bulk job across fifty pages, the underlying LangChain or LlamaIndex libraries let an analyst script the whole sitemap at once.
If you want to test how AI chunks my page across more than one setting, run at least three configs: a 256-token split, a 512-token split, and a 1024-token split. Pages that chunk cleanly on all three are the ones engines will agree are citation-worthy. DeepSmith's Pages view tells you which pages are already earning citations, so you know which ones deserve this three-config treatment first.
How to tell this step is done: you can see your page as a set of colored chunks and point to where an answer breaks across a boundary. Where people go wrong: trusting a single default setting and assuming every engine chunks the way that one visualizer does.
Step 3: Score every chunk on the six healthy-chunk properties
You have the chunks on screen. Now grade them. Score each chunk on the six properties of a healthy chunk, and call it a pass if it clears five of six.
Run down the list for every chunk. Does it name its subject in plain text? Can you label its role in under five seconds? Does one complete answer fit inside it? Does it state a boundary? Can you tell an observation from a hard claim? Does it sit early in its section?
You can make this semi-automatic. A chunk names its subject if its first sentence carries a proper noun or a defined term and does not open with a stray pronoun. It states its role if the first sentence is a verb-led claim, not "In today's fast-paced world." It carries one answer if it resolves every pronoun it introduces. It has a boundary if it holds at least one qualifier like "only when" or "does not apply to." It shows proof status through calibrated language, "is" versus "may" versus "in our testing." It sits early if the section's most citable sentence is the first sentence under the heading.
Turn this into a simple rubric or a Notion table and score fast. You are not writing yet. You are diagnosing.
How to tell this step is done: every chunk on your triage pages has a score and a clear pass or fail. Where people go wrong: rewriting on the fly instead of scoring first, which hides the pattern you need to see.
Step 4: Flag the broken chunks and name their shape
Take every chunk that failed and tag it with its shape: split, buried, or orphaned. This matters because the fix is different for each, and guessing wastes time.
Split answers show up as definitions and numbered steps cut in half at a chunk boundary. Buried answers show up as chunks whose first two sentences are framing, with the real substance hiding in the middle. Orphaned answers show up as chunks stuffed with "this," "it," "they," and "the previous step."
A fast tell for a buried answer: read only the first two sentences of the chunk. If they are setup and not substance, that chunk is a Shape B candidate no matter how strong the rest is. Answer density is your warning light here. A dense passage carries named entities, numbers, and concrete claims. A thin one carries framing and hedging.
How to tell this step is done: each broken chunk has a shape label. Where people go wrong: lumping all the failures together, then applying one generic fix that only helps a third of them.
Step 5: Fix content chunking by restructuring headings and paragraphs
Now the satisfying part. You fix content chunking by shape, and each shape has a recipe.
For Shape A, the split answer, add 10 to 20 percent overlap to the chunker, which is 50 to 100 tokens on a 512-token chunk. Move to a heading-aware splitter so chunks respect your H2 and H3 boundaries. Lift definitions and numbered steps above the fold of their section so each one lands in its own chunk. For a legacy page you cannot restructure, restate the answer at the start of the next chunk so retrieval still finds the whole thing.
For Shape B, the buried answer, move the topic sentence to the front. Front-load the answer: definition first, then evidence, then elaboration. Cut the scene-setting paragraph that reads fine to a human but retrieves as nothing. Strip the hedging stacked before the claim and replace it with a direct statement and one honest qualifier at the end.
For Shape C, the orphaned answer, replace every "this," "it," and "as mentioned above" with the explicit subject. Rebuild the paragraph so its first sentence is a self-contained proposition. For step-by-step content, make each step a complete instruction, "Set the refresh interval to 30 minutes," not "Configure it as described."
The structural rules that produce healthy chunks by default are worth pinning up. One H1 per page that matches the title. Strict nesting from H1 to H2 to H3, no level-skipping, no H4 unless a sub-step truly needs it. Headings of three to twelve words with the key term up front. One buyer question per H2 section, with the H2 naming the question. Paragraphs of three to six sentences, each on a single idea, each led by its topic sentence. And semantic HTML, real heading tags and lists, plus schema like FAQPage and HowTo where the format fits.
Common mistake: fixed-token chunking with no overlap. This is the number one cause of split answers. Many chunkers default to 500 to 1000 tokens with zero overlap, and any sentence straddling the boundary gets quietly sliced. A close cousin: trusting the default separator list. Splitters that ship with separators like paragraph break, line break, and space tend to over-split on spaces and produce short, low-context chunks. A richer list that respects sentence endings produces healthier chunks.
How to tell this step is done: re-read each fixed chunk cold, out of context, and it still answers its question. Where people go wrong: fixing the words but leaving the heading structure that caused the split in the first place.
Step 6: Re-run a retrievability check AI engines actually reward
You changed the page. Now prove it worked, because eyeballing is not the same as measuring. This is your retrievability check: AI retrieval, simulated, before and after.
Re-run the visualizer first and confirm the splits landed where you wanted. Then go quantitative. Pick 10 to 20 buyer prompts, the ones you most want to be cited for. Embed the page with your chosen chunking strategy and retrieve the top five chunks per prompt. Score each retrieved chunk on the six-property rubric. The chunk that gets cited should pass five of six. If it does not, the page still has work.
For the rigorous version, Ragas, a free open-source evaluation library, scores retrieval on context precision, context recall, and faithfulness. It is engineering-grade, so a developer or analyst may need to wire it up, and that is fine. Present it as the rigor option, not the daily default. Capture the rubric score and the Ragas score before and after your fix. The change is real only if both move.
If you run a tracking platform, this is where it closes the loop. DeepSmith's Pages view shows which chunks AI is pulling from your live pages over time, so a retrievability check AI systems run in the wild backs up what your simulation predicted. It tracks mention and citation across the engines it covers, ChatGPT on Pro, plus Perplexity on Grow, Gemini on Scale, and all five including Claude and Google AI Mode on Enterprise. It does not control or guarantee citations. It shows you where you stand and where you moved.
How to tell this step is done: you have a before-and-after number, not just a feeling. Where people go wrong: declaring victory off the visualizer alone and never running the simulation.
Step 7: Lock the pattern into your production system
Here is the honest truth about a one-off audit. It drifts. The next writer picks up the brief and reintroduces the same broken chunks, and three months later you are auditing the same page again.
The fix that lasts moves upstream, into how you produce content in the first place. Store the heading, passage-length, and answer-density rules as structured brand context so every new draft is written that way by default. Check the six properties before publish, not after.
This is where a production platform does real work. DeepSmith's Deep IQ holds your brand voice, product facts, and structure rules as reusable context, and Content Studio writes each draft against them, with citation-ready structure built in during creation rather than bolted on later. Autowrite can take a scheduled piece all the way to published, or your team can review it in Produced Content first. The audit stops being a rescue mission and becomes a verifier: you are checking that the system held, not repairing what it broke.
How to tell this step is done: your structure rules live somewhere every new draft inherits them, not in a doc no one opens. Where people go wrong: fixing ten pages by hand and changing nothing about how the next hundred get written.
Pro tip: audit the page you most want to win first, and simulate more than one retriever. Pull your top pages by citation share or buyer-prompt importance, and score each against a 256-token, a 512-token, and a 1024-token config. The pages that pass on all three are the ones the engines will agree are worth citing.
What to do next
You have the whole loop now: pull your best pages, see how they chunk, score them, name the breaks, fix by shape, prove it, and push the pattern upstream. That is a complete LLM retrieval audit, and none of it needs a research budget. It needs one focused afternoon.
Run the audit on your ten highest-value pages this week. Score each chunk on the six properties. Fix the broken ones. Then set a recurring cadence, because engines re-index on their own clocks and a page that passed last quarter can slip when the index or the prompt set shifts.
Want to see which of your pages AI is already citing, which prompts you are losing, and where this audit will pay off first? Start a free DeepSmith trial and let the data point you at the pages worth fixing.
