What Is Semantic Chunking?
Semantic chunking is the practice of splitting a document into retrievable passages along boundaries of meaning rather than at a fixed length. It is not summarising.
Semantic chunking is the practice of splitting a document into retrievable passages along boundaries of meaning rather than at a fixed length. It is not summarising, and it is not a rewrite. The words on the page stay the same. What changes is whether a single passage still makes sense once it has been lifted away from everything around it.
Why chunking decides what gets quoted
Answer engines and site search tools do not return documents. They return passages. A query is matched against stored fragments of your page, and one of those fragments becomes the material for an answer, with or without a link back to you.
That changes what a good page looks like. A long, beautifully argued explanation that unfolds across six paragraphs can lose every one of them individually, because no single paragraph carries enough on its own. A competitor with a flatter, duller page wins the citation because one of their sections answers the question start to finish. You are not being outranked in the old sense. You are being out-retrieved, which is a separate problem with a separate fix. If you want what actually changed this month rather than a theory about it, that is the shortest route in.
How a document becomes passages
The chunker never sees your page the way a reader does. It sees a stream of text, and it has to decide where one idea stops.
- Strip the furniture. Navigation, footers, cookie banners and sidebars are discarded so the main content can be isolated. Anything ambiguous here gets carried into your passages as noise.
- Segment on structure first. Headings, paragraph breaks, list items and table rows are the cheapest available evidence of where one idea ends and the next begins. Your HTML is doing work whether you intended it to or not.
- Compare neighbouring segments. Each segment is converted into a vector, a numeric representation of its meaning. Consecutive segments that sit close together in that space are merged; a sharp shift is treated as a boundary.
- Fit the result to a window. Every retrieval system has an upper limit on passage size, so boundaries are chosen inside that constraint. The limit varies by system and changes without notice, which is why writing to a specific number is wasted effort.
- Attach the context. A passage is usually stored with its heading path, page title and URL, so the system knows where it came from. That metadata is what makes attribution possible.
- Embed and index. Each finished passage is stored as a vector. At query time the question is embedded the same way and the closest passages are pulled back, which is the retrieval half of how RAG systems answer questions. RAG stands for retrieval-augmented generation.
| Split at a fixed length | Split on meaning |
|---|---|
| A definition can be cut in half mid-sentence | The definition survives as one retrievable unit |
| A passage may open mid-argument, with no subject | Each passage opens on its own subject |
| Two unrelated topics get stored as one fragment | Topic shifts become boundaries |
| Overlap is added to compensate, inflating the index | Less duplication, cleaner matches |
None of that machinery is yours to configure when the retrieval happens at someone else’s end. The only input you control is the document you hand it.
The blunt version
Chunking gets sold as a settings problem. Choose a size, choose an overlap, tune the splitter. That framing is popular because settings are something a vendor can bill you to adjust. The thing that actually decides whether you get quoted was fixed in your draft, long before anything reached an index.
Retrieval happens at passage level. One section comes back on its own and has to answer the question by itself. So if your third H2 opens with ‘This is why the second approach fails’, that passage is unusable the moment it travels alone. The phrase ‘the second approach’ has no referent once the section above it is gone. No splitter repairs that, because the dependency is in your prose, not in the parsing.
Here is the test. Cover the whole page, uncover one section, and read it cold. If it needs the section above to be intelligible, it will not be cited alone, however good the retrieval stack is.
The rule that follows is simple and slightly uncomfortable. Use pronouns and back-references freely inside a section, and never across one. Every section restates its own subject in its first sentence. To a human reading top to bottom it feels marginally repetitive; to every retrieval system it is the difference between quotable and useless. That trade sits underneath most of getting cited in AI answers.
Example
Say a payroll software company publishes a guide to statutory sick pay. Section one explains who qualifies. Section two opens with ‘Once that threshold is met, the calculation runs as follows’, then gives the full working. Section two is the answer everyone actually wants, and it is the section that can never be quoted, because ‘that threshold’ is defined in a passage the retrieval system did not fetch. Rewriting the first line to name the qualifying threshold, in full, costs one clause and makes the section self-contained. Nothing else on the page changes. The guide reads almost identically to a human, and it becomes retrievable for the query that matters.
FAQ
Does semantic chunking affect my rankings?
Not directly. Ranking decides which pages get listed; chunking decides which passages can be lifted out and used in an answer. A page can rank well and still never be quoted, because every section depends on the one before it. Treat them as two separate outcomes with two separate causes.
Is there markup or a plugin that does this for me?
No. You do not run the chunker, so there is nothing to install. What you control is clean heading structure, real paragraph breaks instead of styled line breaks, and sections that name their own subject. Structural HTML gives the splitter better boundaries to work with, and that is the whole of your influence.
How long should each section be?
Long enough to answer one question completely, short enough that it only answers one. Anyone quoting a specific word or token count is guessing, because the limits differ between systems and change without announcement. Write to the question, not to a number, and the length sorts itself out.
Related terms
- GPTBot — the crawler question that comes before chunking: whether the text is collected at all.
- Social Proof — what happens to a claim once it is quoted away from the evidence that supported it.
- Retrieval-Augmented Generation — the wider system that fetches passages and writes an answer from them.
If a section of your page only makes sense to someone who read the section above it, that section will never be quoted on its own. Fix the first sentence of each one and you have done most of the work.