The Text Only Version of Your Website Strips Out the Wrong Layer
/ 7 min read
Summary
Heavy JavaScript is absolutely unnecessary for a website that is not some kind of web app, and the visual layer is not essential. The practical question is what this changes for SEO, content quality, and AI search visibility.
There is a growing trend of serving text only or markdown versions of websites to AI agents. The logic is that it makes the content easier for a Large Language Model to digest. But there is a fundamental flaw in this approach: it solves the reading problem while completely ignoring the doing problem. This connects with AI Agents Read Your Site & It’s Breaking when the same signal needs a clearer operating decision. The same pattern also shows up in Clicks Are Down 42%, where the practical question is how the signal becomes visible.
When you strip a website down to a markdown mirror, you aren't just removing the visual clutter. You are removing the mechanism of action. By the time a machine receives a text only version of your page, everything a visitor could have actually pressed or triggered is gone. You've turned a functional tool into a piece of prose.
The Myth of the Essential Visual Layer
If you imagine a website that no human will ever open, you quickly realize how much baggage we carry. For a machine, heavy JavaScript is almost entirely unnecessary unless the site is a complex web application. The visual layer is equally irrelevant.
As an exercise, imagine stripping away the layout, the navigation menus, the design system, and the visual hierarchy that guides a human eye. If the structural layer of the site is healthy, nothing of value is actually lost. The machine doesn't need to see where the "Buy Now" button is positioned on the screen; it just needs to know that the button exists and what it does.
The tradeoff here is between aesthetics and utility. We spend massive amounts of time optimizing the visual experience for humans, which is necessary, but we often mistake the visual layer for the functional layer. The decision to inspect here is whether your site's functionality is tied to its presentation or if it exists independently in the code.
Structured Data as a Machine Only Interface
We already have a way of talking to machines without involving humans: structured data. JSON LD is a prime example, appearing on over half of the websites measured by W3Techs as of late 2026. This data is invisible to people because it was never meant for them. A useful companion note is We Earned 1, because it looks at a nearby part of the same system.
The recent surge in markdown mirrors and "AI readiness" scores belongs to this same family. They answer the question, "What is this page?" However, they fail to answer, "What can be done with this page?" A readiness scanner might tell you if certain tools are registered, but it won't tell you if those tools actually function when called.
This matters because there is a difference between being "discoverable" and being "usable." You can have perfect structured data that tells an AI you sell blue suede shoes, but if the AI cannot actually trigger the purchase process, the structured data is just a brochure.
The Floor and the Ceiling of Machine Action
There are two primary ways to expose actions to a machine: semantic HTML (the floor) and a declared tool surface (the ceiling).
The floor is built on semantic HTML and accessibility features. Native elements are designed to be self describing. A button is a button; a label names a field; a form has a specific target and method. This isn't new technology; it is the foundation of the web that predates AI agents by decades. If you have a working form, you should already have this floor in place.
The ceiling is a declared tool surface, such as the WebMCP proposal. In this model, a page explicitly registers the functions an agent can call. The agent doesn't have to guess or infer anything from the markup; it simply calls the function. While the ceiling is the ideal, it is still a proposed standard.
The practical reality is that most websites have a broken floor. If the basic HTML is invalid or non semantic, the agent cannot navigate the site, regardless of how fancy the "ceiling" is. The decision for developers is to stop treating accessibility as a "nice to have" and start seeing it as the primary API for AI agents.
The High Cost of a Broken Floor
The data on this is sobering. WebAIM's 2026 evaluation of the top million home pages showed that nearly 96% failed WCAG 2 standards, a decline from the previous year. On average, pages had over 56 errors. Interestingly, pages that tried to use ARIA (accessible rich internet applications) attributes often had more errors than those that didn't, likely because those pages were more complex.
The most critical failures are the ones where actions simply vanish. Over half of home pages had form inputs with no labels, and about 30% had empty buttons. To a human, a button's purpose is often clear from its position or an accompanying icon. To an agent, a button without a name is indistinguishable from the one next to it.
When you provide a text only version of a page with broken HTML, you aren't fixing the problem; you are just adding a new file on top of a broken foundation. If a screen reader cannot find the button, an AI agent using the accessibility tree cannot find it either.
The Feedback Loop Problem
Even if the HTML is valid, there is a second hurdle: programmatic feedback. I've seen AI agents fail not because the form was broken, but because the site didn't tell the agent that the submission worked.
A human sees a "Thank You" page or a green checkmark and stops. An agent, however, needs a programmatic confirmation. Without it, the agent assumes the action failed and tries again. This leads to duplicate orders, duplicate tickets, and duplicate signups. These aren't "AI hallucinations" or agent mistakes; they are failures of the website to communicate success in a machine readable format.
A text only version of a site does nothing to solve this. Neither does a readiness score. The real work is ensuring that every action has a clear, readable result. The tradeoff here is between a "pretty" confirmation page and a "functional" one. You must ensure the success state is as accessible as the input state.
Platform Level Implementation of Tool Surfaces
While individual site owners struggle with the floor, platforms are starting to build the ceiling. Shopify is a notable example. In August 2026, they enabled WebMCP tools by default for all storefronts built on Liquid. This included catalog search, cart management, and checkout.
The merchants didn't have to build these tools; Shopify wrote a single adapter script and served it via CDN to every store. This is the most efficient way to scale agentic capabilities because the tools read the same data as the human storefront, meaning there is no "drift" between what a human sees and what a machine can do.
This highlights a shift in power. The ability for a machine to "do" something on your site will likely be determined by your platform provider rather than your individual SEO efforts. If you are on a platform, you should be auditing which "tool surfaces" are actually active and whether they are functioning as intended.
The Gap Between GEO and Action
There is a lot of talk about GEO (Generative Engine Optimization). GEO is essentially the practice of getting your brand cited or recommended in an LLM's answer. This is valuable because citations drive traffic, but it is important to recognize that GEO is about visibility, not utility.
GEO is effectively SEO for more powerful systems, but it ignores the very thing that makes those systems powerful: the ability to act. Optimizing for a citation is optimizing for the half of the process that cannot act. It's the difference between being mentioned in a travel guide and having a "Book Now" button that actually works.
The danger here is that businesses may spend their entire budget on GEO, believing they are "AI ready," while their actual checkout process is a black box that no agent can navigate. The decision to make here is to balance the desire for citations with the necessity of functional infrastructure.
Prioritizing Structure Over Visuals
To simplify this, think of your website in three layers: the visual layer, the structure, and the content.
The actions live in the structure. If you remove the visual layer but keep the structure and content, a machine can still use your site. But if you remove the structure and keep only the content (which is what a text only/markdown version does), the machine can only read about your site. It becomes a spectator rather than a user.
A machine first architecture means ensuring that the structure and the actions work independently of the visual layer. The visuals are for the people; they are the final polish. The structure is the engine.
If you want to know where you stand, sort your site's capabilities into two piles: "describable" and "doable." You will likely find a full pile of things the AI can talk about and an empty pile of things it can actually do. Once you identify that gap, you can stop worrying about the visual layer and start fixing the floor.
Comments
Comments are reviewed before they are published. Links are not allowed inside comments.