The Granularity Gate: How Specific Is Too Specific for LLM Consumption

Chunking Is Not Optional

Pages do not chunk themselves uniformly. The AI engine’s retrieval pipeline applies a chunking strategy to every page it indexes, and the strategy chooses where to cut. A well-structured page yields clean chunks that align with editorial intent. A poorly-structured page yields chunks that split mid-thought and rank poorly against query retrieval.

The DSCRI ARGDW framework Granularity gate measures whether your page chunks at the right grain. The answer depends on how h2 and h3 headings are placed, whether FAQPage schema is used, and whether each chunk reads as a self-contained unit. Granularity sits downstream of Content and Structure; it is about chunking strategy specifically.

How LLMs Chunk

The chunking strategies vary by engine but share common heuristics. A typical pattern:

1. Header-based splitting. The chunker prefers to split at heading boundaries (h2, h3). A page with semantic h2 hierarchy yields chunks that map to editorial sections.
2. Length-based capping. When two adjacent sections combined exceed roughly 800 tokens, the chunker splits them. When two are too short (under 200 tokens), it combines them.
3. Sentence-respecting splits. The chunker avoids splitting mid-sentence. Long paragraphs that exceed the cap are split on the nearest sentence boundary, which can produce awkward chunks if the prose does not yield clean sentence breaks.
4. Schema-aware extraction. Pages with FAQPage schema get the question-answer pairs extracted as discrete units, independent of the surrounding chunk boundaries.

The implication: h2-segmented pages with paragraphs in the 100 to 300 word range chunk cleanly. Pages with deep h3 nesting or unbroken 1,000-word sections chunk badly.

h2 Hierarchy As Chunk Boundaries

The right granularity for a 1,500-word post is roughly six to eight h2 sections, each 150 to 250 words. This produces chunks of 200 to 350 tokens, which sit in the middle of the optimal range for retrieval. The chunker treats each h2 boundary as a preferred split.

Three common failures of h2 placement:

1. One h2 covers half the post. A 700-word section produces a chunk near the upper cap; the chunker may split it mid-section, breaking the editorial argument.
2. Five h2s in the first 300 words. Section boundaries clustered at the top of the post create tiny opening chunks that combine awkwardly with the next section.
3. h2 used for visual emphasis rather than structural division. A “Bold Claim Here” h2 that is one sentence followed by another h2 produces chunks that contain only the heading. Empty calories.

The fix is editorial: write h2-segmented from the outset, with each section a self-contained 150 to 250 word argument. Posts that hit this rhythm extract cleanly.

FAQPage Schema Extraction

FAQPage schema is a special case for the Granularity gate. The chunker treats Q-A pairs as discrete units regardless of the surrounding chunk boundaries. Each question-answer pair becomes its own retrieval candidate.

The implication is structural. Five FAQ questions at the bottom of a post add five additional retrieval units to the page. Each pair can independently rank against a specific query. The opening Q-A pair can rank on a different query than the closing pair.

FAQPage schema works best when:

• Questions are common variations of how users actually phrase the topic.
• Answers are 50 to 200 words each.
• The question is the literal question text (not a statement).
• The answer is self-contained (does not require the reader to have read prior questions).

FAQPage schema works poorly when:

• Questions are SEO-targeted variations rather than reader questions.
• Answers loop back to the article body with “as we discussed above.”
• The FAQ section is padded for keyword coverage rather than reader value.

Both the Astro Foundation’s BlogPosting plus FAQPage emission and the discipline of writing the FAQ section as reader-facing serve the Granularity gate.

Optimal Passage Length

The 200 to 800 token band is wide; the optimal target sits in the lower middle. Three rules of thumb:

1. 300 to 500 tokens per chunk is the sweet spot. Long enough to contain an argument. Short enough to fit comfortably in retrieval and ranking heuristics.
2. Each h2 section: 150 to 250 words. Yields 200 to 350 tokens per chunk after the heading and any sub-structure.
3. FAQ answers: 60 to 150 words. Shorter than h2 sections because the question provides the framing.

Posts that exceed 1,800 words risk being split into chunks larger than the optimal range. Posts under 800 words may chunk as a single unit that competes against tighter pages on specific queries. The 1,200 to 1,500 word band hits the chunking strategy cleanly for most engines.

Table Of Contents As Navigability

A table of contents at the top of the post serves both readers and chunkers. Readers use it to navigate. Chunkers extract the TOC as a structural signal: the page is sectioned, the sections are named, the sections likely correspond to chunk boundaries. The TOC anchors give the engine deep-link targets for chunk-specific citations.

A minimal TOC implementation:

<nav aria-label="Contents">
  <ul>
    <li><a href="#section-one">Section One</a></li>
    <li><a href="#section-two">Section Two</a></li>
  </ul>
</nav>

Each h2 should have an id matching the TOC anchor. The TOC at the top of long posts is a small editorial cost with a measurable Granularity payoff.

Worked Example

A finance firm published a 2,400-word post on “AI search optimization for B2B finance.” The post had three h2 sections. Each section was 700 to 900 words. The post ranked well on Google for the target query.

ChatGPT, asked about AI search optimization for B2B finance, returned a generic summary that did not name the firm. Perplexity cited the post sometimes but with awkwardly long quotes that included sentences from adjacent sections.

Diagnostic: the three-h2 structure produced chunks of roughly 1,000 tokens each, larger than the optimal range. The chunker was either splitting mid-section (producing partial argument chunks) or accepting the long chunks (which ranked lower than tighter alternatives).

Fix: a structural rewrite that broke each of the three sections into three to four sub-sections, each with its own h2. The post became 12 h2 sections in roughly the same total length. No content changed; only the heading structure. Three weeks later, ChatGPT started naming the firm in citations and Perplexity quotes became tighter and more specific.

Frequently Asked Questions

Should I use h3 sub-headings inside h2 sections?

Sparingly. h3 is fine for genuine sub-structure (a list of related items, a comparison table) but should not be used as a substitute for an h2 boundary. The chunker’s preferred split is at h2; h3 boundaries are weaker hints.

Is there a maximum number of FAQ questions per post?

No hard cap, but diminishing returns above 6 to 8 questions. The FAQ section starts to read as padding past that count, and the answers tend to get repetitive.

Does FAQPage schema dilute the BlogPosting schema?

No. Both can coexist on the same page, with each marking up its specific content. The Structure Gate post covers how to compose multiple schema types via the @graph plus @id pattern.

How does this gate interact with the Content Gate?

Content is about whether each passage clears the quality bar. Granularity is about whether the passages are the right size to be evaluated. They compose: high-Content passages at the wrong granularity fail to surface; right-granularity passages with weak Content fail to cite.

Should I add anchor links to every h2 for deep-linking?

Yes. Anchor links (<h2 id="some-section">) give AI engines deep-link targets that they can use when citing specific sub-arguments. Most modern static site generators emit them automatically; verify yours does.

Next Gate

The next Tuesday post covers the Differentiation Gate: why replaceable content is invisible content, and what makes a page unreplaceable in an LLM citation graph that increasingly punishes generic prose.