Chunking
The unglamorous step that decides your visibility: before a page can be retrieved, it is cut into passages small enough to embed one at a time. How you are chunked is how you are found. A self-contained passage embeds into a clear, findable point in meaning space, while a fragment that leans on the paragraph above it embeds into a muddy point that no question ever lands near.
AI systems do not retrieve pages, they retrieve chunks, so a passage that cannot stand on its own is a passage that cannot be found, no matter how good the page around it is.
What Chunking Actually Is
A retrieval system cannot embed an entire webpage into a single useful vector. Squeeze five hundred words into one point in embedding space and every distinct idea on the page averages into a vague blur that sits near nothing in particular. So before indexing, the page is broken into smaller units called chunks: a paragraph, a few sentences, a section under one heading. Each chunk is embedded into its own vector and stored in a vector database. This splitting step is chunking, and it is also called text splitting.
The crude version is fixed-size chunking: cut the text every N tokens or characters, say every 500 tokens, and move on. It is fast and predictable, but blind. It will happily slice through the middle of a sentence, split a definition from its term, or strand a price three words into a new chunk. To soften this, systems add overlap: each chunk repeats the last sentence or two of the one before it, so an idea straddling a boundary survives in at least one complete piece. Overlap costs storage and some duplication, but it buys back context that a hard cut would have destroyed.
The smarter version is semantic chunking: instead of cutting at an arbitrary character count, the splitter looks for natural boundaries where the topic actually shifts, often by embedding consecutive sentences and starting a new chunk where their meaning diverges. The goal is that every chunk contains one coherent idea and nothing bleeding in from the next. Structure-aware splitting, cutting on headings, list items, or paragraph breaks, is a close and often more reliable cousin, because a well-built page already marks its own semantic boundaries with markup.
Watch: Chunking Strategies in RAG: Optimising Data for Advanced AI Responses by Mervin Praison, a clear walkthrough of fixed-size, recursive, and semantic chunking and why the choice changes what gets retrieved. Source: YouTube.
Why Chunking Decides Whether AI Can Cite You
When someone asks ChatGPT, Perplexity, Google AI Overviews, or Gemini about your category, the engine does not read your homepage. It embeds the question and pulls the nearest chunks from its index, then reasons over and cites those passages. This is the retrieval half of retrieval-augmented generation, and the unit it works on is the chunk, not the page. Your beautifully argued article is invisible to the model as a whole. Only its passages compete for retrieval, one at a time.
That is why a chunk's self-sufficiency is decisive. Imagine a paragraph that opens with "As mentioned above, it cuts response times by half." Embed that in isolation and the vector is a fog: what cuts response times, which product, whose service? The subject lived in the previous paragraph, which now sits in a different chunk. When a buyer asks "which mediation service resolves cases fastest," that foggy vector sits nowhere near the question, and the passage is never retrieved. A model with an SBERT-family embedder can only match on the meaning actually present inside the chunk. Meaning that depends on context outside the chunk simply does not exist as far as retrieval is concerned.
The Tradeoffs You Are Actually Tuning
Chunk size is a genuine tension, not a setting with one right answer. Split too large and each chunk carries several ideas, so its embedding averages them into a diluted point that matches many questions weakly and none of them strongly. Split too small and a chunk loses the context that made it meaningful: a lone sentence like "It is fully licensed and bonded" is precise but unmoored from whatever "it" was. The practical sweet spot for prose tends to be a few sentences to a short paragraph, one complete thought, large enough to stand alone and small enough to stay sharp.
Size: coherence versus precision
Bigger chunks preserve context but blur the vector. Smaller chunks sharpen the vector but can strip away the subject. Aim for one self-contained idea per chunk, not one paragraph and not one sentence by reflex.
Overlap: insurance against bad cuts
Repeating a sentence or two across the boundary keeps an idea whole even when the split lands mid-thought. It costs duplication, but it rescues facts that a hard cut would otherwise orphan.
Method: fixed-size versus semantic
Fixed-size is fast and dumb. Semantic and structure-aware splitting cut on real topic boundaries, so each chunk holds one idea. You do not control a search engine's splitter, but you control how cleanly your page hands it those boundaries.
What This Means for Your Website
You do not run the retriever, so you cannot set its chunk size. What you can do is write pages that survive any reasonable chunking, and that is a real, learnable craft. Make every passage stand on its own. Name its subject explicitly rather than leaning on "it," "this," "the above," or "as we saw earlier." A sentence should still make sense if a reader parachutes into it cold, because that is exactly how a retriever meets it.
Front-load the subject: open a section with "Practical Family Mediation resolves most divorce cases in..." rather than "We resolve most cases in..." Keep a fact and its context in the same breath, so a price, a claim, or a qualification does not get stranded from the thing it describes. Use real headings and short, focused paragraphs, because clean structure gives structure-aware splitters honest seams to cut on. None of this is keyword stuffing. It is writing so that any single passage, lifted out of your page, still says something true and complete about your business. That is retrieval legibility at the level of the paragraph.
Write every paragraph as if it will be read alone by a stranger, because in retrieval it will be. The model never sees your page. It sees one chunk, and it judges you entirely on what that chunk can say by itself.
How AIOInsights Reads This Signal
AIOInsights does not grade you on the word "chunking." It grades the observable conditions that decide whether your passages survive being split and retrieved: whether sections state their subject explicitly, whether facts sit beside the things they describe, whether headings and paragraph structure give a splitter clean boundaries to cut on. Those signals live inside the Semantic Clarity pillar, because a page that reads clearly to a human paragraph by paragraph is the same page that chunks cleanly for a machine.
Every one of those checks is real and deterministic. We do not run your site through a live splitter and report a number that drifts on each pass. We evaluate the structural and linguistic properties that decide, ahead of time, whether your passages will stand on their own when a retriever cuts them apart. You can read exactly how in our scoring methodology.
Check How Retrievable Your Site IsKeep reading the lexicon: RAG, Embeddings, and Retrieval Legibility.