TLDR;

  • AI systems often retrieve passages, so each passage needs to make sense without nearby text.
  • Put the direct answer first, then add evidence, scope, and caveats close to the claim.
  • Use numbered steps, bullets, tables, or definitions to match the information.
  • Clear headings and semantic markup show how page sections relate, but do not guarantee citations.
  • Structure helps preserve meaning; strong, fresh evidence gives systems a reason to choose your page.

Why does structure matter to an LLM?

AI search systems often retrieve passages rather than use a whole page at once. They split content into chunks, then select a chunk that matches the question. A strong answer elsewhere on the page may not help if the relevant passage is hard to identify.

A passage loses force when its meaning depends on nearby text. For example, “This can cut the time in half” does not say what “this” is or which task takes less time. If a system retrieves that sentence without its context, the claim is unclear.

Name the subject and answer in the passage itself. Instead of “This can cut the time in half,” write “A saved email template can cut the time needed to answer common support questions in half.” The second version tells readers what changes and what task it affects.

Headings help mark where an answer starts and what it covers. A heading such as “How long does setup take?” gives a clearer signal than “Getting started.” Follow it with the answer, then add the conditions that shape it, such as team size or data migration needs.

Use the shape that fits the information. A set of steps is easier to lift when each step has its own label; a comparison is clearer when each option uses the same criteria. For example, a table comparing plans by price, user limit, and storage keeps those details aligned.

These choices make a passage easier to understand when it stands alone. They do not ensure that a system will select or cite it, since retrieval also depends on the question and the system’s methods. Structure is the entry ticket: it helps an answer travel intact beyond the page.

How should a section open?

Open each section with the answer the reader came for. Then give the context, caveats, and evidence that help them judge it.

For example, a section on audit-log retention should state its recommendation before describing the policy background. “Keep audit logs for 12 months” gives the reader the main point at once. The next sentences can explain which records it covers and when a different period may apply.

A buried conclusion makes the reader work to find the answer. “Many teams need to review past account activity, and some rules set minimum record periods; for these reasons, keep audit logs for 12 months” puts the reasoning first. Rewrite it as: “Keep audit logs for 12 months. This gives teams a year of account activity to review; rules for your industry may require a longer period.”

The answer-first version is easier to read on its own. If a system retrieves only the opening sentence, it still contains the recommendation and its subject. The longer version can then add the scope and limits without making the reader infer the conclusion.

Make the first statement specific enough to stand alone. “Use a 30-day trial” names an action and a duration, while “This is a good option” leaves the reader to work out what “this” means. If the recommendation depends on a condition, put that condition in the answer: “Use a 30-day trial for teams that need to test the workflow before buying.”

Then support the answer with evidence that matches the claim. A retention recommendation might cite the applicable policy or explain how the period was set. Do not place a broad claim first and leave the proof several paragraphs later, where it may be separated from the answer.

Put caveats close to the answer they qualify. If a rule varies by country, say so beside the recommendation rather than in a distant note. This keeps the claim clear without making it sound universal.

Answer first does not mean stripping out nuance. It means giving the reader a clear claim, then showing its basis and limits in an order that still makes sense if the section is read in pieces. This makes a passage easier to interpret and attribute, but it cannot ensure that a system will select or cite it.

How do you write a passage that stands on its own?

A passage stands on its own when a reader can identify its subject, scope, and limits without looking elsewhere on the page. Name the thing you mean instead of using “it,” “this,” or “they” when the reference could be lost. Remove phrases such as “as mentioned above,” because a lifted passage may not include the earlier point.

Define an acronym the first time it appears. Write “application programming interface (API)” before using “API” on its own. Give the date, unit, version, and condition that make a number meaningful. A limit of “100 requests” is unclear without a time unit and a statement of what the limit applies to.

Before: “It allows 100 requests per minute, as mentioned above. The limit applies to version 2.4.”

After: “The Basic plan allows 100 requests per minute for the application programming interface (API). The limit applies to API version 2.4. The limit is for each account. The limit applies to paid accounts in the United States from 1 January 2026.”

Keep each sentence to one checkable claim. The revised example puts the request rate, version, account basis, and eligibility in separate sentences. A reader can check each detail without separating it from another claim.

Keep conditions beside the claim they qualify. If a price applies only to annual billing, state that beside the price. If a process differs by country, name the country in the sentence that describes the process. Avoid placing a broad claim in one paragraph and its main exception several sections later.

Use exact terms for the same thing throughout a passage. If “account” means a customer account, do not switch to “profile” unless the terms refer to different things. State who acts when the subject could be unclear. “The buyer sends the invoice” names the actor more clearly than “The invoice is sent.”

Check a passage by reading it without its heading or the paragraphs around it. Replace references that depend on missing context, and add the dates, units, versions, or conditions needed to test its claims. This gives a reader enough detail to interpret the passage, though it does not guarantee that an LLM will select or cite it.

Which formats do LLMs lift most easily?

Match the format to the information. A format that mirrors the content makes each fact easier to identify and keeps related details together when a passage is lifted.

Use numbered steps for a procedure with a set order. For example, “Prepare the file, upload it, then check the result” hides three actions in one sentence. A numbered list shows what to do and in what order:

  1. Prepare the file as a CSV.
  2. Upload the CSV to the account.
  3. Check the import report for errors.

Use bullets for grouped items that have no required order. If a page lists accepted file types, write “The tool accepts these file types:” and give each type its own bullet. Do not number the items unless readers need to follow them in sequence.

Use a table when readers need to compare several options across the same criteria. Give each column a clear header, and keep each row to one option. For example, a plan comparison might use columns for “Plan,” “Monthly price,” and “User limit.” A row with values in those columns lets readers compare the same details across plans without guessing which number means what.

Use plain definitions for terms and concepts. “A service-level agreement (SLA) is a contract that sets the service standards a provider must meet” states the term and its meaning in one sentence. Avoid a definition that starts with “This refers to,” since the term may be missing if the sentence is lifted on its own.

Use question-and-answer blocks when readers are likely to search for a specific question. Put the question in a heading, then answer it directly in the first sentence below. For example, under “Can users export their data?” write “Users can export account data as a CSV file.” Add limits or steps after that answer.

Do not keep essential information only in an image. A diagram can show a workflow, but write the steps in the page text too. A chart can show a price difference, but include the values and labels in text or a table so readers can interpret them without the image. This also gives people who cannot see the image a way to access the information.

Choose the format that lets each item keep its meaning when read apart from the rest. A list or table can make content easier to parse, but it does not ensure that an LLM will use or cite it.

What do headings and markup actually do?

Use headings and markup to show how page parts relate. They give search systems a map of the content, but they do not decide whether a system will quote or cite a page.

Give the page one H1 that names its main subject. Use H2 headings for its main sections, then H3 headings for parts within an H2. Do not jump from H2 to H4: that skips a level in the outline.

For example, an article about choosing a payroll schedule might use “How do you choose a payroll schedule?” as its H1. An H2 could ask “How often should you pay employees?” and an H3 beneath it could ask “What changes when you pay weekly?” The levels show that the weekly-pay question sits within the broader section.

Phrase headings as questions a reader might ask, and make each one specific to its section. “What records should you keep?” tells readers more than “Recordkeeping.” The heading should fit the text below it; a heading that promises a tax answer should not lead into a section about software setup.

Use semantic HTML for the visible structure. Mark the page title with an <h1> element, a main section with <h2>, and a subsection with <h3>. Use paragraph elements for prose and list elements for actual lists; styling plain text to look like a heading does not give it the same heading role in the document.

Schema.org structured data can describe the page and its content in a format that machines can read. Keep its facts aligned with what people can see on the page: do not mark up a review score, price, or FAQ answer that the visible content does not support. Google’s structured data guidelines require marked-up content to be relevant and available to readers.

Structured data does not replace clear page text or guarantee a place in an AI answer. Google says its AI features rely on the same SEO fundamentals as its other search features and do not need special markup. See Google’s guidance on AI features for its current advice. The headings and HTML help a system read the page’s shape; the words still need to make sense to a person.

What can't structure fix?

Structure makes a passage easier to extract, but it does not make the passage worth citing. A model may find a clear answer and still choose another source because relevance, source quality, original data, freshness, and support from other sources also matter.

A page that repeats a common claim gives the model little reason to pick it. For example, “Email subject lines should be clear” is easy to read, but many pages say the same thing. A more useful passage might report results from a company’s own test, such as which subject-line change raised open rates and how the test was run.

Original evidence can make an answer more useful to cite. Name the method, sample, date, and limits so readers can judge what the result shows. A claim based on a small test should not sound like a rule for every business.

Freshness matters when the answer can change. A page that says a tax threshold, software feature, or market figure is current should give the date and point to the source behind it. A well-formed answer with an old figure may be less useful than a newer, less polished one.

Other sources can affect how much weight a claim carries. If several reliable sources report the same fact, that agreement gives a model more support than a claim found on one page alone. Where sources differ, state the scope of your claim and cite the evidence that supports it.

Before publishing, ask two separate questions: can a system lift this passage without losing its meaning, and is there a clear reason to choose it over competing sources? Structure helps answer the first. Strong evidence, a close fit to the question, and information that adds something new help answer the second.

How do you audit an existing page without rewriting it?

Audit the page in place before you rewrite any copy. Check whether its structure helps a reader find and understand each answer, then fix only the gaps that block that work.

  • Does each H2 open with its answer? Read the first sentence under every H2. If the heading asks “How long does setup take?” but the section starts with background, move the time estimate to the top and explain its limits next.
  • Can each section be read alone? Copy a paragraph into a blank document and read it without the rest of the page. Replace “this process” with the process name if the reference is unclear, and add any missing scope or condition.
  • Are acronyms defined? Search for capitalized abbreviations. Change “The SLA covers repairs” to “The service-level agreement (SLA) covers repairs” on first use.
  • Do comparisons and steps use the right format? Put options in a table when readers compare them by shared criteria, such as price and storage. Number actions when their order matters; keep unordered items as bullets.
  • Is key information in text, not only in images? Check charts, diagrams, and screenshots for facts a reader needs. Add the values or instructions in page text if the image is the only place they appear.
  • Does markup match visible content? Compare headings, lists, and any structured data with what a reader can see. If markup names a price or answer that the page does not show, update or remove it.
  • What does the page add that others do not? Identify a piece of evidence, a tested result, or a detail about your own process. If the page makes only a broad claim shared across many sites, add a specific, supported contribution or narrow the claim.

Record each issue beside the section where it occurs. Fix the smallest thing that resolves it: add a missing definition, change a paragraph into numbered steps, or bring a buried answer to the top. Do not rewrite a clear section just to make it sound different.

Run the checks again after edits. A section can be easy to lift and still be passed over; structure helps preserve meaning, but it does not guarantee selection or citation.