Why models prefer structured content

There is a habit of treating extraction as a cleaning problem: strip the markup, keep the words. It is the wrong frame. Some of that markup is not decoration, it is the document telling you how its parts relate, and once you flatten it that information is gone for good.

The clearest case is a table.

A table, flattened

Here is a pricing table the way a naive text extractor leaves it:

Plan Requests Price Free 1,000 $0 Pro 50,000 $49 Team 500,000 $199

Now ask a model what the Pro plan costs. It has to infer that there are three columns, that the header row defines them, and that position determines which number belongs to which plan. Sometimes it gets it right. On a table with empty cells, or one where a value happens to look like a header, it will not.

The same table with the structure kept:

| Plan | Requests | Price |
| --- | --- | --- |
| Free | 1,000 | $0 |
| Pro | 50,000 | $49 |
| Team | 500,000 | $199 |

Nothing was added. The relationships that were in the HTML are simply still there, and now the question is a lookup rather than a reconstruction. Note the cost: a handful of pipe characters against a category of error that is otherwise silent.

Headings are the document's outline

A heading does two jobs. It labels what follows, and it establishes scope: everything until the next heading of equal or higher level belongs to it. Flatten the levels and the second job disappears.

This matters most when you chunk. A chunk carrying ## Rate limits at the top is self-describing, and the embedding reflects the topic. The same paragraph with the heading stripped is a fragment about numbers. Preserved headings are also the most reliable place to split, because the author already decided where the ideas divide.

Lists mean the items are peers

A bulleted list asserts that its items are alternatives or steps of the same kind. Run them into a paragraph and that reads as prose, and a model summarising it will happily merge two items into one claim neither of them made. Ordered lists are worse: the numbers were doing work, and losing them loses the sequence.

Code has to survive exactly

Whitespace in a code block is semantic. Collapse the indentation of a Python sample and the sample is now wrong, not merely uglier. Anything feeding technical documentation to a model has to preserve fenced blocks byte for byte, and mark them as code so the model does not read them as prose.

Structure the model does not see

Some structure should not be inlined at all. Author, publication date, canonical URL and language are usually declared in the page as JSON-LD or OpenGraph, and they belong in fields beside the content rather than in it.

That is what lets retrieval filter by date, cite a source accurately, or drop a duplicate. Inline the date into the prose and the model might use it; keep it as a field and your pipeline can.

{
  "title": "The Quiet Rise of Underwater Farming",
  "author": "Nadia Okafor",
  "published_date": "2025-11-03",
  "markdown": "# The Quiet Rise of Underwater Farming\n\nTwenty meters …",
  "tables": [
    { "caption": "Yield comparison",
      "headers": ["Crop", "Land yield", "Biosphere yield"],
      "rows": [["Basil", "1.0x", "1.4x"]] }
  ]
}

The table appears twice on purpose: rendered inside the markdown for the model to read, and as structured rows for your code to use. They are different consumers with different needs.

What to keep

A short rule that covers most of it: keep anything that encodes a relationship, drop anything that encodes an appearance.

Headings, lists, tables, code blocks, block quotes and link targets are relationships. Font sizes, colours, grid classes and tracking attributes are appearance. The first set is worth its characters several times over. The second is what makes raw HTML nine times larger than the content it carries.