Content Structure for AI Visibility: Headings, Chunks and Schema

Content structure for AI visibility means building each page from clean headings, self-contained chunks and schema that matches the visible text. AI engines break pages into passages and pick the ones that best answer a query, so structure decides whether your answer can be found, lifted out and quoted accurately.

This page covers structure only: how to lay a page out. For how to write the sentences, see the answer-first writing method.

Why does structure affect AI visibility?

Retrieval-based systems do not hand a language model your whole article. They split content into passages, score those passages against the question, and pass the best few to the model. The retrieval-augmented generation approach described in the original RAG paper is the foundation for most of this.

Where the split falls is not in your control, but the signals around it are. Clear headings, short sections and one idea per section make a split more likely to land on a complete thought.

AI Mode also searches for several sub-questions at once, a pattern called query fan-out. A page with a section for each plausible sub-question gives retrieval more to match.

What heading structure works best?

Use a plain hierarchy:

• One H1 that states the topic. The template renders it from the title field.
• H2s for the main questions a reader would ask next.
• H3s for sub-points that belong inside one H2.
• No skipped levels, and no headings used only for styling.

Write headings as specific labels. “How do I check if GPTBot is blocked?” beats “Checking things”. If you could swap the heading onto a different article without anyone noticing, it is too vague.

What are macro, micro and atomic chunks?

Think of three levels, each with a different job.

Level	What it is	Typical size	Job
Macro	An H2 section	150 to 400 words	Answers one main question
Micro	An H3 or a block under an H2	60 to 150 words	Covers one sub-point
Atomic	A paragraph, list item or table row	1 to 3 sentences	States one verifiable fact

These sizes are a working rule from editing practice, not a published standard. Adjust to the topic.

The test for any chunk: if someone saw only this section, would they get a correct, complete answer to its heading? If a chunk begins with “As mentioned above” or “This is why,” it fails.

How do you write a chunk that stands alone?

1. Open with the answer to the heading in the first sentence.
2. Name the subject instead of using a pronoun that points back to an earlier section.
3. Add one concrete supporting detail: a number, a named example, a step.
4. Stop. A second idea gets its own heading.

Here is the same fact written badly and well.

Bad:  It also depends on this setting, which we covered earlier.
Good: A robots.txt rule that disallows GPTBot stops OpenAI using the site for model training, but does not affect OAI-SearchBot.

When should you use tables and lists?

Use them when the content has the shape of a table or list:

• Tables for comparisons across the same attributes (plans, tools, crawlers, pros and cons).
• Numbered lists for sequences where order matters.
• Bullets for parallel items that are each a complete thought.

Do not format prose as bullets just to look scannable. A list of three-word fragments is harder to extract meaning from than a sentence.

What schema should support the structure?

Structured data tells search engines what a page contains in a format they can read directly. Google’s introduction to structured data is clear on the main rule: markup should reflect content that users can see on the page.

For a typical article, three types are worth having:

• Article, with headline, author, datePublished and dateModified.
• FAQPage, only if the page visibly contains those questions and answers.
• Organization (site-wide), so the publisher is a clearly identified entity.

A minimal Article block:

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Content Structure for AI Visibility: Headings, Chunks and Schema",
  "author": { "@type": "Person", "name": "Alessandro Benigni" },
  "publisher": { "@type": "Organization", "name": "GeoGen", "url": "https://geogen.io" },
  "datePublished": "2025-12-13",
  "dateModified": "2026-10-11"
}

Keep the markup in sync with the page. Out-of-date or invented properties create mismatches that do more harm than leaving them out. Entity markup goes deeper in the entity SEO guide.

What is a good template for common page types?

How-to guide

1. Direct answer: what the outcome is and how long it takes.
2. Requirements list.
3. Numbered steps, one H3 per major step.
4. Troubleshooting table: symptom, cause, fix.
5. FAQ.

Definition or explainer

1. One-sentence definition, then why it matters.
2. How it works.
3. Example.
4. Comparison with the nearest alternative, as a table.
5. FAQ.

Comparison

1. Verdict in the first paragraph.
2. Summary table.
3. One H2 per option with pros, cons and best-for.
4. Selection criteria.

What structural mistakes cost the most?

• Walls of text with no internal signposts.
• Fragmented pages, where every sentence has its own heading and no section says anything on its own.
• Skipped or decorative headings, such as an H4 used because it looked smaller.
• Key answers in images, accordions or tabs that do not exist in the initial HTML.
• Two topics under one heading, which dilutes what the passage is about.

How do you check your structure?

Read only your headings, top to bottom. They should outline the argument. Then read the first sentence under each: it should answer its heading. Run the page through a crawl view to confirm the text is in the HTML, and use the content audit checklist to score a batch of pages the same way.

To see whether restructured pages are actually being cited, GeoGen tracks citations for your prompts across AI engines every day.