The traditional search engine results page is changing. In 2026, users increasingly ask complex questions directly to Large Language Models (LLMs) and generative search systems such as Claude, ChatGPT, Gemini, Copilot, and Perplexity.
To adapt to this shift, brands are aggressively exploring Generative Engine Optimization (GEO). But the marketing industry is often overlooking a critical reality: Semantic HTML and WCAG accessibility principles share an important technical foundation with AI discoverability—machine-readable structure. If you are not building an accessible, structured digital estate, you may be making it harder for both people and machines to understand the information your brand publishes.
The Evolution of Search: Why AI Needs Accessibility
Generative systems do not experience a website in quite the same way a person does. While an AI crawler or retrieval system is fundamentally different from a screen reader, both benefit from information that is exposed through clear, programmatically determinable structure rather than relying entirely on visual presentation. Semantic HTML, meaningful headings, descriptive links, accessible names, and clear relationships between content can all make a document easier for software to interpret.
Research into Generative Engine Optimization—including the foundational study from researchers at Princeton University, Georgia Tech, the Allen Institute for AI, and IIT Delhi—has demonstrated that how information is presented can affect its visibility within generative-engine responses. The research also makes clear that generative engines synthesize information from multiple sources rather than simply reproducing a traditional ranked list. Read the GEO research opens in a new window
That does not mean every AI system uses HTML semantics in an identical way. Their retrieval, crawling, indexing, ranking, and generation pipelines are proprietary and constantly evolving. What we can control is the quality of the source itself: whether the information is clearly structured, accessible, current, and easy for machines to interpret.
— GEO: Generative Engine Optimization opens in a new window
(authored by researchers from Princeton University,
Georgia Tech, the Allen Institute for AI, and IIT Delhi)
Caption: Generative engines synthesize information from multiple sources. Clear, programmatically determinable content gives machines a stronger vocabulary with which to interpret the source.
The Trap of the Visual Builder (“Div Soup” & Structural Bloat)
The “no-code” movement democratized web design, but it also introduced a significant architectural trade-off. Platforms featuring drag-and-drop page builders empower users with little coding experience to build visually sophisticated layouts. However, that flexibility can come with layers of generated containers, classes, scripts, and layout instructions. When every button, image, and text block is surrounded by multiple generic wrappers, the resulting document can become unnecessarily complex. Among developers, this is often described as “div soup.”
To a sighted user, the page may look perfectly cohesive. But visual appearance does not tell us whether the underlying document is semantically structured. For assistive technologies, excessive or poorly implemented structure can make navigation and interaction more difficult. For machine-processing systems, unnecessary markup can increase document complexity and make reliable extraction more difficult. The important distinction is not simply how many <div> elements exist, but whether the rendered document exposes a clear, meaningful hierarchy and preserves the relationships between its information.
This is why the authoring environment should never be confused with the finished product:
WordPress (The Builder vs. Native Spectrum)
WordPress spans a wide spectrum. Raw PHP and carefully authored content in the Classic Editor can produce clean HTML, while the modern Gutenberg Block Editor can provide a strong semantic foundation when used thoughtfully. Visual builder plugins such as Elementor, Divi, and WPBakery can introduce additional wrapper layers and proprietary classes, but the decisive question is always what the final rendered DOM actually contains—not simply which editor was used to create it.
Squarespace & Fluid Engine
Squarespace’s grid-based “Fluid Engine” provides powerful visual control through generated layout structures. That abstraction can make the underlying document more complex, particularly when third-party plugins, animations, or custom scripts are introduced. The resulting page should therefore be evaluated by its rendered semantics, keyboard behavior, accessible names, and actual document structure rather than by the visual editor alone.
Webflow
Webflow exposes designers to HTML and CSS concepts more directly than many visual builders, but that flexibility places greater semantic responsibility on the person constructing the page. A designer can create an exceptionally clean document—or assemble a visually impressive interface from generic containers and custom interactions. Again, the tool does not determine the outcome; implementation discipline does.
Shopify, Wix, & HubSpot
- Shopify: Native Online Store 2.0 themes can be engineered with strong semantics, while third-party page-builder applications may add additional wrapper hierarchies and scripts. The resulting product information and structured data should be evaluated in the rendered output.
- Wix: Automated document generation can introduce substantial structural abstraction. Accessibility and machine readability therefore depend on how the resulting page exposes its content, controls, headings, relationships, and metadata.
- HubSpot: Drag-and-drop templates can simplify content management while introducing additional layout layers. Custom modules and templates should still be tested for semantic structure, keyboard behavior, accessible names, and content relationships.
The New Pitfall: AI Code Generation & “Instruction Decay”
Ironically, using AI development tools to build web interfaces can create a new version of the same problem: code that looks correct on screen while gradually losing the structural discipline required underneath.
Prompt-based coding assistants and rapid prototyping environments such as Claude, ChatGPT, Cursor, and v0 are powerful accelerators. But when a model is repeatedly asked to modify an existing interface, its attention is necessarily divided between visual requirements, functional changes, existing code, and the latest instruction. Unless semantic and accessibility requirements remain part of the active specification, important details can be simplified or lost during iteration.
The practical danger is not that AI-generated code is inherently inaccessible. It is that accessibility and semantic quality can decay silently during rapid iteration:
-
Silent Semantic Stripping
You may successfully prompt an AI to generate a component with strict semantic markup and accessibility requirements in step one. During later styling or layout revisions, however, semantic elements, accessible names, keyboard behavior, or relationships can be unintentionally simplified. The code can still look correct while the underlying implementation has degraded. -
Continuous Re-Anchoring Required
If semantic HTML, keyboard interaction, accessible names, and WCAG requirements matter to the finished product, they should remain explicit acceptance criteria throughout the development process—not merely instructions given once at the beginning. -
The Inline Styling Trap
AI coding assistants frequently optimize for immediately visible results. That can lead to unnecessary inline CSS, duplicated declarations, and increasingly difficult-to-maintain markup. Inline styling is not automatically inaccessible, but uncontrolled proliferation can increase payload complexity and make systematic maintenance harder.
Relying on code-generators or drag-and-drop abstractions without continuous structural oversight creates an illusion of velocity while potentially eroding accessibility, maintainability, and machine readability.
Caption: Visual abstraction is not inherently bad. The important question is whether the final rendered document preserves a clear, semantic, accessible architecture.
Citing Lawrence Shaw: The Threat of “Digital Suicide”
There is another side to the AI-readiness problem: restricting access to authoritative information. In his analysis Digital Suicide opens in a new window, Lawrence Shaw examines the strategic consequences of organisations limiting AI-related access routes to their own digital estates.
“Restricting an access route does not prevent AI discussing the organisation. It can reduce the opportunity for the organisation’s current, controlled information to shape the answer.”
That observation exposes an important vulnerability. When an organization’s authoritative website becomes difficult for a particular machine-access route to reach—whether because of server restrictions, crawler controls, technical failures, or structural problems—the AI system does not necessarily stop discussing the organisation. It may instead rely more heavily on other accessible sources.
Shaw’s analysis cites research suggesting that third-party sources can account for a substantial proportion of brand mentions in AI-generated answers. That does not mean an organisation loses control of its narrative the moment an AI crawler encounters a technical obstacle. It does mean that restricting or degrading access to authoritative first-party information can create an information gap that other sources may fill.
When generative systems encounter a website whose information is difficult to retrieve or interpret, they may draw on other accessible sources—including reviews, publications, older documents, forums, or third-party commentary. The result can be a widening gap between the information an organisation currently publishes and the information available to systems attempting to describe it.
The Compounding Danger: From Inaccessibility to Misinformation
This convergence of poor technical structure and fragmented information creates two distinct risks:
-
The Extraction Barrier
Complex or poorly structured documents can make reliable extraction harder for both assistive technologies and automated systems. The issue is not simply the number of HTML elements. It is whether the underlying document exposes meaningful relationships, hierarchy, labels, and content in a predictable way. -
Structural Misinterpretation & Regulatory Exposure
Accessibility failures can extend beyond missing visual text. When tables, pricing information, forms, or compliance documents lack clear semantic relationships—such as explicit<th>headers and appropriate data-cell associations—software can have greater difficulty interpreting the information correctly. For an AI system that subsequently summarizes or transforms that information, poor source structure can become one contributor to inaccurate output. The risk is therefore not that HTML semantics magically determine an AI’s answer, but that poor source structure removes useful context that machines rely on.
The Strategic Imperative
You cannot solve an AI visibility problem with a surface-level plugin, just as you cannot solve an accessibility problem by assuming an automated overlay has addressed the underlying implementation.
As Shaw emphasizes, AI readiness requires establishing foundational control, governance, and visibility over your digital doorway. For web developers and digital accessibility consultants, that means moving beyond the path of least resistance and taking responsibility for the actual document that reaches the browser—and the machines that process it.
True optimization requires semantic discipline, native HTML5 architecture where appropriate, structured data, accessible interaction patterns, and ongoing code-level verification. By building a website that assistive technologies can navigate effectively, you also create a clearer, more structured information source for automated systems. You reduce accessibility risk on one front while improving your ability to present authoritative information to the increasingly complex systems shaping digital discovery on the other.
The Rule: Test the Rendered Document
The most important lesson is that you should never assume a website is machine-readable simply because the authoring environment claims to be accessible, semantic, AI-ready, or SEO-friendly. The source of truth is the rendered document.
Inspect the Structure
- Heading Hierarchy: Confirm that headings communicate a logical information hierarchy rather than merely providing visual styling.
- Native Semantics: Use native elements such as
<button>,<nav>,<main>,<article>, lists, and properly associated table headers where they accurately describe the content. - Accessible Names: Verify that controls, links, images, and form fields expose meaningful names and relationships programmatically.
- Structured Data: Validate Schema.org and other machine-readable metadata rather than assuming it has been generated correctly.
Verify the Experience
- Keyboard Interaction: Test whether interactive functionality remains usable without a mouse.
- Assistive Technology: Test the actual interface with appropriate accessibility tools rather than relying exclusively on automated scans.
- Machine Accessibility: Review robots directives, crawl controls, server responses, rendered content, and the availability of authoritative information to legitimate automated systems.
- Regression Testing: Recheck the rendered output after significant content, plugin, template, or AI-assisted code changes. A page that was accessible yesterday can become inaccessible tomorrow.
The tool used to create a website is not the guarantee. The rendered document, tested against real requirements, is the evidence.
The Unified Epicpaths Strategy: Offense & Defense
Many agencies treat SEO, accessibility, cybersecurity, and AI readiness as entirely separate disciplines. But they overlap at the code, infrastructure, and governance levels. You do not need entirely isolated strategies when the same underlying engineering discipline can improve multiple systemic conditions. Here is how Epicpaths unifies offense and defense:
Offense: Structuring for AI
Semantic HTML and structured data can act like an interface between your authoritative information and the software attempting to interpret it. When Epicpaths manually engineers clean, native HTML where appropriate, we expose the content hierarchy, relationships, and metadata that machines can use to understand the source more reliably.
- Programmatic Structure: We utilize appropriate HTML5 landmarks such as
<main>and<article>, along with programmatic table associations such as<th scope="col">. Clear relationships reduce ambiguity for assistive technologies and automated systems alike. - Structured Data Integration: We embed appropriate Schema.org structured data to describe organizations, services, products, and other entities where the vocabulary accurately represents the underlying content.
- Assistive Technology Harmony: We use semantic HTML first and ARIA where appropriate to expose meaningful names, states, and relationships for users of assistive technologies, supporting robust WCAG conformance.
Defense: Mitigating the Risk
The web is dynamic, and there is no such thing as a “bulletproof” website. Instead of selling false guarantees, we build robust code-level foundations and equip you with defensible documentation and verification practices to reduce exposure.
- Eradicating Technical Failures: We engineer semantic, accessible interfaces to remediate underlying implementation defects and reduce the straightforward failures that automated scanners and accessibility evaluations can expose.
- Defensible Documentation: A responsible accessibility program requires evidence. Where appropriate, we help teams maintain formal Accessibility Conformance Reports (ACRs), VPAT-related documentation, testing records, and remediation evidence to demonstrate ongoing due diligence.
- IT Advisory & Verification: We provide internal DevOps teams with guidance on crawler controls, robots.txt architecture, and recurring verification so that legitimate automated access is governed deliberately rather than accidentally blocked.
Accessibility is Brand Survival
By intentionally building a natively accessible website for humans using assistive technology, you create a clearer, more structured information source for Artificial Intelligence as well. Manual, deep-code engineering is not merely a liability shield—it is part of the technical foundation for trustworthy digital communication in an increasingly machine-mediated web.