Use semantic HTML to express the actual structure of a page: headings for sections, links for navigation, tables for tabular relationships and controls for actions. Then test both the initial response and the working page. Clear markup helps communicate structure, but it is not proof that an AI system can complete a task or will cite the content.
Separate three different questions
First, what information appears in the delivered HTML? Second, what does a browser display after scripts and styles run? Third, can a person operate the interface with the keyboard and appropriate assistive technology?
These questions overlap but are not interchangeable. A raw response can contain a well-named button whose action is broken. A browser can display readable content that was absent from the initial response. Record the evidence for each view before concluding that the site needs a rendering change.
Start with raw HTML versus rendered content when those views differ. Avoid using “AI readable” as a single binary label that conceals which part was tested.
Review the document outline
Read the page’s headings as a list. They should describe the subject and its sections without requiring surrounding paragraphs to explain each label. Prefer “Check the final response status” over repeated headings such as “Important information.”
W3C’s heading guidance explains using headings to organize content and support navigation. Our audit recommendation is to compare that structure with the article brief: if the important question has no clear section, either the outline or the brief may be incomplete.
Do not select heading levels merely to obtain a font size. Apply visual styling independently so that a template refresh does not silently change the document’s hierarchy.
Example: repair a report page’s information structure
Imagine a fictional audit report made from large styled paragraphs. It shows “Overview,” “Issues” and “Next steps” in bold, but none is a heading. Individual issues are clickable containers with no ordinary links to their explanations.
A focused repair uses real headings for the sections and descriptive links for the explanations. It keeps the existing visual design and avoids building a new interaction system. Google describes generally crawlable links as anchors with an href in its link guidance.
Test that the destinations work without depending on a click handler. Then use the keyboard to follow them in the rendered page. This produces separate evidence for link discovery and actual navigation.
Preserve relationships in tables
When rows and columns carry meaning, use table markup with appropriate headers rather than a grid of visually aligned text. W3C’s table tutorials explain how header relationships communicate the structure.
For a crawler comparison, identify what each column represents and make the difference between search policy and training policy explicit in the text. On mobile, retain those relationships even if the visual presentation changes. A compact layout that removes all labels can make the comparison ambiguous.
Check actions and labels separately
For a form, inspect each field’s label, expected input and error explanation. For a button, check its accessible name and actual effect. Do not assume that a visible icon or placeholder communicates enough information in every interaction state.
The agent readiness checker can provide limited raw control observations. It does not establish computed accessibility, keyboard behavior or successful automation. Use those observations to choose manual tests, not to certify the interface.
Frequently asked questions
Does semantic HTML guarantee AI search visibility?
No. It provides a clear representation of the document’s structure. Discovery, access, retrieval and citation are separate outcomes that need their own evidence.
Must a JavaScript application be rewritten?
Not from a markup warning alone. Identify the missing information or broken interaction, reproduce it in the relevant view, and fix the smallest shared component responsible for that behavior.