Most SEO advice still treats a page as the unit of retrieval: one URL, one topic, one ranking. That model has been leaking for years. Google's passage ranking work, featured snippet extraction, and now generative systems that retrieve text spans all operate below the page level. They pull a section, a paragraph, sometimes a list item, and evaluate it largely on its own.
That changes what "well-structured content" means. A page can be coherent end to end and still produce fragments that are useless out of context. Understanding how the splitting works tells you which parts of your writing are load-bearing.
What passage ranking actually changed, and what it didn't
Google announced passage ranking in October 2020 and said it expected the change to affect roughly 7% of queries across all languages once fully rolled out. Danny Sullivan later clarified a widespread misreading: this is passage ranking, not passage indexing. Google still indexes whole pages. What changed is that a specific passage within a page can be scored and used as the reason the page ranks, even when the page overall is about something broader.
The practical consequence is documented behavior you can observe: Google frequently deep-links into a page using a scroll-to-text fragment, so the user lands directly on the relevant span.
https://example.com/guide/#:~:text=Crawl%20budget%20only%20becomesIf you see those in your referrer data or in the SERP, Google has identified a passage boundary inside your document that it considers the answer. You did not define that boundary. The system inferred it.
How an embedding pipeline decides where your page ends
Retrieval-augmented systems — the ones behind most AI answer products, including third-party tools that crawl your site — do something more mechanical. They split documents into chunks before embedding them, because embedding models have fixed context limits and because a vector that averages 4,000 words of mixed topics is too diffuse to match anything precisely.
The common splitting strategies, roughly in order of sophistication:
- Fixed-size character or token windows with overlap. The default in most tutorials and toolkits. Cut every N tokens, repeat the last few hundred characters into the next chunk so a sentence spanning the boundary isn't lost. It ignores your document structure entirely.
- Recursive splitting on separators. Try to split on double newlines first, then single newlines, then sentences, then characters — whatever keeps chunks under the size limit. This respects paragraph breaks when it can.
- Structure-aware splitting. Parse the HTML or Markdown, split on heading boundaries, and prepend the heading trail to each chunk. This is where your
h2andh3structure starts to matter directly. - Semantic splitting. Embed sentences, detect topic shifts, cut there. Better boundaries, much more expensive, less common in production.
You don't control which strategy a given consumer uses. What you control is whether your page produces sane chunks under all of them. A page with clear heading hierarchy, self-contained paragraphs, and no critical context buried three sections above the answer degrades gracefully under naive splitting. A page that reads like a single argumentative essay does not.
What breaks when a section is read alone
These are the failure modes I see most often when you feed real pages through a chunker and read the output:
| Failure mode | What the chunk looks like | Fix |
|---|---|---|
| Orphaned pronouns | "This is why it fails at scale." No antecedent in the chunk. | Restate the subject at the start of each section |
| Headless tables | Rows of data with the <th> row in the previous chunk | Keep tables small; caption them in prose |
| Context-dependent lists | "3. Set it to 604800" — set what to 604800? | Make list items grammatically complete |
| Deferred definitions | Term defined in the intro, used in section six | Define inline on the first use in each major section |
| Heading-only meaning | ### Don't followed by a paragraph that assumes the negation | Write headings as full statements |
None of these are hard to fix. They're all symptoms of writing that assumes linear reading.
Does this mean you should split pages into more URLs?
No, and this is where the advice often goes wrong. Passage-level retrieval exists precisely so that long, comprehensive pages don't get penalized for covering more than one narrow query. Fragmenting a strong page into six thin ones trades a page with internal authority and link equity for six that have neither.
The decision criterion is whether the sections have genuinely different search intents and different audiences. If someone searching for section A would be annoyed to land on a page mostly about B, split. If the sections are steps in one task or facets of one decision, keep them together and make each section self-contained.
This point is contested in practice — some practitioners report better results with tightly scoped pages, and for competitive head terms that's often true because relevance signals concentrate. The honest answer is that it depends on whether your ranking problem is relevance (favors splitting) or authority (favors consolidation).
How to test whether your sections stand alone
Don't guess. Run your own pages through the same treatment:
- Chunk your HTML and read the output. Strip navigation, split on
h2/h3, and print each chunk with nothing else. Any chunk you can't understand is a chunk a retrieval system can't use well either. - Check for scroll-to-text fragments. Search for pages where you hold featured snippets or AI Overview citations and inspect the linked URL. The fragment tells you which span Google selected.
- Do the heading-only test. Read only your
h2andh3text in order. If that sequence doesn't summarize the page, your headings are decorative rather than structural. - Watch for anchor-bearing queries. In Search Console, long-tail queries that match a single subsection are evidence that passage-level matching is already doing work on that URL.
What to actually change
Start with your highest-traffic long pages, not your whole site. For each one:
- Rewrite every
h2so it states a claim or asks the question a reader would ask. "Why passage ranking doesn't mean you should split pages" beats "Considerations." - Make the first sentence under each heading restate the subject in full nouns. No leading "this," "that," or "it."
- Move definitions of terms from the introduction to their first use in each major section, even if it feels slightly repetitive on a linear read.
- Convert any list where items depend on a preceding sentence into items that are complete on their own.
- Keep tables under about ten rows, and put the takeaway in prose next to the table rather than only in the data.
The side effect is worth noting: every one of these changes also helps human readers who arrive from a deep link and scan one section. You're not writing for a chunker. You're writing for the many readers — machine and otherwise — who never see the top of your page.