Step 1. Put the bottom line in the first 100 pixels
Open <body> with a <header> containing the h1, a single-sentence answer, and a <dl> of key facts. Retrieval systems chunk documents from the top; if the first chunk contains the complete claim with its numbers, the extracted passage is self-sufficient and citable without further traversal.
Step 2. Flatten the DOM to semantic elements only
Replace wrapper divs with header, nav, main, section, and footer. Target a maximum nesting depth of 7 to 10 elements from the html root. Shallow trees cut readability-extractor traversal cost, reduce token waste in HTML-to-text conversion, and eliminate ambiguity about which text belongs to which heading.
Step 3. Mirror visible facts in JSON-LD
Emit one <script type="application/ld+json"> block per root entity in <head>. Use FAQPage for Q&A content, TechArticle for guides (with author, publisher, image, datePublished, dateModified), and ProfessionalService with a nested OfferCatalog for service listings. Every claim in markup must appear in visible content. Mismatches are policy violations and get filtered.
Step 4. Validate before publishing
Run the page through Google's Rich Results Test and validator.schema.org. Enforce the mechanical invariants in the build: absolute https URLs, ISO-8601 dates, dateModified ≥ datePublished, non-empty required fields, contiguous breadcrumb positions. A build that fails validation should not emit HTML.
Step 5. Track citations per engine
Log which URLs get cited by which engine for which query. Retrieval-augmented engines respond in days; training-data citations lag months. The ledger tells you which structural changes moved citation rate, closing the loop.
Compliance checklist
| Invariant | Target |
|---|---|
| Answer position | First content block, top 100 vertical pixels |
| Max DOM depth | ≤ 8 elements from html root |
| JSON-LD placement | <head>, one script block per root entity |
| Dates | ISO-8601; dateModified ≥ datePublished |
| URLs in schema | Absolute https only |