Semantic HTML

Semantic HTML matches markup to meaning. A heading is an h2, not a styled div; a list is a ul; tabular data lives in a table; the main content sits inside main and article elements, separated from nav, aside, and footer. This costs nothing visually — CSS controls appearance — but gives every machine reader an accurate map of what each piece of content is and how pieces relate.

The hierarchy matters most: a single h1, logically nested h2-h4 subheadings, and lists and tables used for genuinely list-like and tabular content. Screen readers, search crawlers, and parsers all navigate by this structure.

AI crawlers and retrieval pipelines convert pages into text chunks before anything else happens. Clean semantic structure produces clean chunks: a well-headed section becomes a coherent passage, a proper table survives as structured data, a real list keeps its items. Div soup, by contrast, produces ambiguous text blobs that score poorly in retrieval and rarely get lifted into answers — a direct hit to your citability.

This connects to passage ranking: engines cite self-contained sections, and semantic headings are how those sections get identified and bounded. Many AI crawlers also execute little or no JavaScript, so server-rendered semantic HTML is often the only version of your content they ever see.

Use one h1 per page and descriptive, question-shaped h2s that match how people phrase queries. Open each section with a direct answer sentence so the extracted passage stands alone. Mark up FAQs, comparison tables, and step lists with their proper elements, and layer structured data on top where a schema type exists. Confirm with a text-only render or curl that your content is present without JavaScript rendering — what the crawler cannot parse, the AI cannot cite.