Content Chunking for SEO: What You Actually Control

Search for content chunking and you land in the middle of an argument. Search Engine Land and Semrush have guides telling you how to do it. Ahrefs has a post calling it overrated. iPullRank has a refutation of what it calls misinformation about chunking. A Reddit thread near the top of the results asks whether the whole thing is a myth. Google, meanwhile, has told you outright to stop.

That is an unusual state for an SEO topic. Normally the disagreement is about how much a tactic is worth. Here the disagreement is about whether the tactic exists.

I went and read all of it, including the primary sources each side is citing, because I wanted to know whether the last year of chunking advice had changed anything about how I write a page. The answer surprised me. The two camps that most loudly disagree about chunking recommend almost exactly the same page. What they disagree about is what to call it.

What is content chunking, and who is arguing about it?

Chunking is the step where a retrieval system splits a document into smaller pieces before it stores or searches them. It exists because models have context limits and because scoring a paragraph against a question is more precise than scoring a whole page against it. Every retrieval-augmented system does it. This part is not controversial.

The controversy starts when the word crosses from engineering into marketing. In an AI pipeline, chunking is something the system does to your document. In SEO advice, “content chunking” has come to mean something you do to your document, in the hope of influencing the first thing.

Those are different activities wearing one name, and almost all of the argument traces back to that.

Here is the timeline, because it is short and it explains the shape of the results page.

Four positions, two of them from the most authoritative sources in the field, and they cannot all be right.

Does Google chunk your pages?

Google’s public answer is that whatever it does internally is not your problem.

On the Search Off the Record podcast published January 8, 2026, Danny Sullivan took the advice head on. As Search Engine Land reported it, he repeated himself for emphasis. “So we don’t want you to do that. I was talking to some engineers about that. We don’t want you to do that.” His reasoning was the usual Google reasoning, that content built for a ranking system rather than a reader tends not to age well, and that the systems keep getting better at rewarding the second thing.

Google’s documentation backs the same line. Its AI features guidance states that “You don’t need to create new machine readable files, AI text files, or markup to appear in these features” and that “There are no additional requirements to appear in AI Overviews or AI Mode, nor other special optimizations necessary.”

Read carefully, none of that says a smaller unit does not exist. It says you are not required to manufacture one. Those are different claims, and the gap between them is where an entire cottage industry has set up shop.

Google has in fact acknowledged the smaller unit before, in plainer language than anything it has said since. When passage ranking rolled out, Google was specific that it was not indexing passages on their own. It still indexed pages, still weighed whole-page signals, and added the ability to consider a passage from a page as one more ranking factor. And the guidance that came with it was the same guidance Sullivan gave five years later, which is that creators had nothing special to do.

So Google’s position has been consistent for half a decade. Passages matter to the system. Manufacturing passages does not help you.

What do the two sides actually recommend?

This is the part that changed my mind about the whole debate, and it takes about ten minutes to verify yourself.

Ahrefs published “SEO Chunk Optimization is Overrated” in August 2025. Despina Gavoyannis argues that chunking happens inside model pipelines, driven by token limits and efficiency, and that none of it responds to your headings or your paragraph lengths. Different systems use different strategies, those strategies change, and your carefully built section may get cut in half regardless. Then she recommends what she calls an atomic content workflow, which is writing self-contained sections that deliver a complete answer on their own.

Mike King published a refutation a week after Sullivan’s remarks, in January 2026. He argues that passages are the atomic unit of meaning across modern architectures, cites Google’s passage-indexing patents and a run of research papers, and demonstrates with embeddings that splitting a paragraph covering several topics improved relevance scoring by 19.24%. Then he recommends structuring content into atomic, self-contained passages.

Put those two prescriptions side by side and the difference disappears.

One of them calls the practice overrated and the other calls it essential, and they hand you the same instruction. Google, for its part, objects to fragmenting a page into bite-sized pieces, which is not what either of them told you to do either.

The uncomfortable conclusion: most of the chunking argument is a fight over vocabulary between people who already agree about the work. The advice that sells is the argument. The advice that helps is one sentence long, and it has been the same sentence since long before anyone said the word chunk.

What are the chunk sizes people keep quoting?

They are real, they are published, and they are being applied to the wrong thing.

If you build on OpenAI’s file search, the numbers are right there in the retrieval documentation. Every file is split into 800-token chunks with 400 tokens of overlap between consecutive chunks, and a response carries at most 10 results by default, with 50 as the ceiling. Those are defaults you can change, on your own uploaded documents, in your own vector store.

That last clause is the whole caveat. It describes what happens when you hand a system a PDF. It does not describe what happens when someone asks ChatGPT a question and the answer cites your blog post. Nobody outside those companies knows the retrieval settings behind web search, and the ones that leak from developer docs are for a different product.

You can see how much smaller the unit gets by the time it reaches an answer. Anthropic’s web search documentation specifies that each citation returns cited_text carrying “Up to 150 characters of the cited content”. A hundred and fifty characters is roughly one sentence. The same page notes that simple factual queries typically use one to three searches while comparative research can use ten or more.

So the retrieval unit might be 800 tokens. The citation unit is about a sentence. Your page is neither.

What changed in 2026?

One thing did change, and it pushes selection further out of your hands rather than closer.

Anthropic’s newer web search versions add what the documentation calls dynamic filtering. With basic web search, every result loads into the model’s context. With web_search_20260209 and later, the assistant writes and runs code that filters the results first, so only the relevant content reaches the context window at all. The stated reason is token cost on search-heavy requests.

Sit with that for a second. There is now a programmatic pass between fetching your page and the model reading it, and that pass is written on the fly by the assistant for that specific question. No fixed chunk size. No stable boundary. A filter improvised per query.

If your model of AI search was “the system splits my page into pieces and picks one,” that model is already out of date. The system increasingly writes a small program to go and find the part of your page that answers the question in front of it.

Which, awkwardly for everyone selling chunk optimization, makes the practical advice even simpler. A filter looking for the part of your page that answers a question finds it faster when there is a part of your page that answers a question.

So what do you actually control?

Not the boundary. Not the size. Not the strategy, which differs per system and changes without notice.

You control one thing, and it is the thing all three camps are circling.

Whether a passage survives removal. Take any section of your page, cut it out, and read it with nothing around it. If it still answers a question completely, every system that wants to quote it can. If it opens with “this” or “as we saw above” or “the third reason”, it cannot be lifted by anything, because the meaning lives in the paragraph you did not include.

That test costs nothing, requires no tool, and is falsifiable in ten seconds per section. Compare that to the advice it replaces, which is to guess at a token count you cannot observe for a pipeline you cannot inspect.

A few things follow from it, and they are unglamorous.

• Answer the H2 in the first two sentences under it: if the heading asks a question, the answer should not arrive in paragraph four.
• Repeat the subject instead of using a pronoun at the start of a section. It reads slightly heavier to a human and it makes the section liftable.
• Give one section one job: King’s 19.24% number came from splitting a paragraph that was doing several jobs at once, which is the one manipulation with published evidence behind it.
• Stop writing setup paragraphs that exist only to introduce the next paragraph. They are unquotable by construction and readers skip them anyway.
• Do not fragment the page into a hundred tiny headings. That is the thing Google actually objected to, and it makes a page worse for the humans who still make up most of your traffic.

None of that is new. It is the answer engine optimization checklist, arrived at from a different direction, which is a decent sign the direction is right.

How do you know whether any of it worked?

Here is my real objection to the chunking discourse. Almost none of it is measured.

Both sides argue from mechanism. One says the mechanism means you cannot influence it, the other says the mechanism means you must. Neither position tells you whether the page you just rewrote is now being quoted, because the mechanism is not the outcome. The outcome is whether an assistant names you when someone asks the question your page answers.

That is checkable, and it is the only part of this worth putting on a dashboard. Ask an assistant the question, read the answer, note who got cited. Do it again next month. Everything else in this debate is an argument about plumbing you will never see.

Google will not help you here. Its generative AI report in Search Console counts appearances and withholds the questions, which I went through in detail when I looked at AI search prompts in Search Console. Appearances are better than nothing. They are not an answer to “did the rewrite work”.

ContextBolt SEO is a hosted MCP server. You paste one URL into Claude Code, Claude Desktop or Cursor, and your agent gets live SEO data without a dashboard to log into. Two of its tools bear on this directly. ai_answer runs the question and reports what came back and who was cited, which is ground truth rather than a model of it. ai_visibility tracks how often a brand shows up across AI answers over time. It is $35 a month with 1,000 lookups included, and there is a 7-day free trial with the card upfront and nothing due today.

Being honest about the limits, because this post is about people overclaiming. Those tools tell you whether you are cited. They cannot tell you which passage did it, because no assistant reports that. Nobody sells that, whatever the pitch says.

What to do this week

Pick your three most important pages and run the removal test on every H2 section. Not a skim. Actually cut a section into a blank document and read it cold. On my own pages the failure rate was higher than I expected, and every failure was the same failure, which is a section that opened by referring to something above it.

Fix those openings and stop there. Do not go looking for a token count, do not split the page into fragments, and do not buy a tool that promises to optimize your chunks, because the thing it is optimizing is set by a pipeline that has never read your markup.

Then check whether it worked by asking an assistant the question and seeing who it names. That measurement takes a minute and settles more than a year of argument has.