Anne Bovelett homepage, logo

Your website is now an API for AI agents, and you’re NOT ready

By Anne-Mieke Bovelett on May 27, 2026
Status: up to date

Why your Google ranking is tanking since the May 2026 core update

So, why on earth would an accessibility strategist write about AI agents and tanked rankings? Because it actually has a LOT to do with accessibility.

Inside that bubble of web agencies I live in, I learned that many assume that AI agents see websites the way humans do. They picture an agent loading a page, reading the text, maybe clicking a button or two. The main assumption is that as long as the website looks fine in a browser, an agent will have no trouble using it.

If you think that as well, this is your wake-up call. It’s wrong, and the consequences are detrimental to both your Google ranking and discoverability by AI.

The Google update everyone is panicking about

People “suddenly” see their site’s ranking tanking like crazy, and they wonder why that is happening. The answer is basic. If you have done everything else right and did not try to rig SEO with all kinds of pony tricks, probably your site’s semantic structure, under the hood, has accessibility issues. The accessibility tree is broken. The structure may be so bad that AI bots run into gaps that they then try to fill with training data. Or to say it even more precisely: if an AI agent runs into an unstructured mess, the model struggles to extract and interpret meaningful content chunks. It may misinterpret the context, leading to poor summaries or outright nonsense.

That broken output creates a lousy human experience. Someone clicks a link from an AI summary, lands on a page that does not deliver what the summary promised, and immediately hits back. That is a pogo-stick signal. Navboost logs it, and that’s how rankings drop.

Google has not officially confirmed a direct link between this update and semantic structure or accessibility. The connection I am drawing is an inference, grounded in how these systems work and what the research shows. It is a well-evidenced one, but you should know it is mine to make, not Google’s.

Google enforces building for all users

No, Google is not forcing us to build for agents only. On the contrary. They force us to build for all users, human and non-human.

That means building accessible websites. Because these can be used by all users, both with and without assistive technology like screen readers and voice control. And all users also means all AI agents. Because what a screen reader can’t do, an AI agent can’t do. They depend on the same things.

Google’s entire business model depends on advertisers buying ad slots (including the conversational ones in AI results). However, advertisers will only pay for them if real humans keep using Google. If Google’s AI interface returns lower-confidence, broken information because websites have messy structural HTML code, users will abandon the engine.

Google’s massive push into conversational advertising is the exact commercial reason why their core ecosystem is so ruthlessly enforcing user experience. They are attacking the problem from both ends to protect their real asset: human attention.

Through core updates and advanced AI parsers, they are scanning under the hood to ensure your site has a flawless semantic structure they can confidently feed into AI overviews. Simultaneously, through algorithms like Navboost, which relies heavily on user interaction data, they are tracking whether real humans find your site easy to navigate. If a broken accessibility tree frustrates human users into bouncing, Navboost flags it; if it breaks the AI’s ability to read the page, the Core Update drops it. Either way, you lose.

What AI agents actually do when they visit your site

Agents don’t browse the way we humans do. They parse. And how successfully they parse your site depends entirely on how your site is built.

There are three main ways agents read web content. The first is the accessibility tree, a structured representation of the page that the browser generates automatically from your HTML. The second is raw HTML or DOM parsing, where the agent reads the source code of the page directly. The third is screenshots, where the agent takes a visual snapshot and uses a vision model to interpret what it sees.

Each of these methods has very different costs and reliability levels. Screenshots consume enormous amounts of processing resources. According to research from both Nielsen Norman Group and accessibility analyst Matthew Stephens, a single screenshot can cost a frontier model roughly 50,000 tokens to process. The accessibility tree, by contrast, costs around 4,000 tokens for the same page. At scale, across hundreds of pages or thousands of users, it compounds into a serious operational cost.

In plain English: a screenshot-based agent is like hiring someone to photograph every page of a book, then asking another person to read all the photographs. It works, but it is expensive and slow, and it misses things.

The accessibility tree is the opposite. According to Nielsen Norman Group’s research on AI agents as users, reading the accessibility tree “costs a few thousand tokens to process (a fraction of what a screenshot requires)” and provides more reliable information. It is faster, cheaper, and more accurate than any screenshot approach.

The catch is that the accessibility tree is only useful if your HTML is built correctly. If your pages are built with a tangle of generic div elements and no semantic structure, the accessibility tree will be sparse and misleading. Agents using it will either fail to find what they need or extract incorrect information.

What the accessibility tree is, and why your HTML determines its quality

The accessibility tree is built automatically by the browser from your HTML. It strips the page down to the elements that actually matter for interaction: headings, buttons, links, form fields, and landmarks. It provides labels, roles, states, and relationships between elements.

Screen readers have used this same tree for decades. Now AI agents are using it too.

When you use semantic HTML, meaning proper heading elements, labeled form inputs, button elements instead of clickable divs, nav and main and footer landmarks, the browser generates a rich and usable accessibility tree automatically. When you use non-semantic markup, the browser has nothing meaningful to work with, and neither do the agents relying on that tree.

In plain English: semantic HTML is the instruction manual the browser writes for anyone who needs to understand your page without seeing it. If the instruction manual is missing or badly written, agents, screen readers, and search engines all struggle.

As the No Hacks guide on how AI agents see websites puts it, “use semantic elements, and the browser generates a useful accessibility tree automatically.” Skip them, and the tree is sparse or misleading.

And nope, this is not new advice. Web standards and accessibility advocates have been making this argument for twenty years. What is new is that the audience has expanded well beyond assistive technology users.

The cost problem nobody is talking about

Most conversations about AI and websites focus on whether agents can access content at all. The more important question, and the one that will shape which sites agents prefer over time, is what it costs an agent to use your site.

Sites built with poor semantic structure force agents to work harder. The accessibility tree is larger, noisier, and less useful. Agents that rely on screenshots instead of the tree consume far more processing resources per page. JavaScript-heavy sites that require full browser rendering just to display their content add another layer of cost, because the agent needs to execute JavaScript, wait for the DOM to settle, and then parse what it gets. That requires browser automation tools like Playwright or Puppeteer, which are slower and more resource-intensive than reading static HTML directly.

As Matthew Stephens wrote in a March 2026 analysis of AI agents and accessibility, “agents optimized for token efficiency will perform better on well-structured interfaces.” Over time, that performance difference compounds. Agents will increasingly favour sites that are cheaper to parse.

In plain English: imagine two shops on the same street selling identical products. One has a clear layout, logical signage, and a well-organized catalogue. The other is a maze. If you send a delivery agent to collect an order from one of those shops every day, the agent will develop a preference quickly.

Your website is becoming the same kind of choice.

The Cloudflare markdown fix is not a fix

A service that has been getting attention recently is Cloudflare’s AI Gateway feature that converts web pages to markdown, making them theoretically easier for agents to read.

The problem is that markdown conversion only works on the content that is actually in the HTML to begin with. If your site renders its content through JavaScript after the page loads, that content is often not in the initial HTML at all. The markdown conversion captures the shell, not the substance.

More importantly, if your HTML is poorly structured, the markdown output will be poorly structured too. You cannot convert disorganized content into organized content by changing the format. Structure is the source. The conversion tool is just the medium.

In plain English: translating a confusing sentence from English into French does not make it less confusing. You still have the same confusion, now in a different language.

The fix happens at the source, in how the page is built, not in a layer applied on top of it.

What this means if you are not a developer

You do not need to understand the technical details to act on this. You do need to be able to ask the right questions.

Here are the questions worth bringing to your developer or development team:

  • Is our site content available in the initial HTML, or does it load after the page through JavaScript? If the answer is the latter, ask what the plan is for server-side rendering or static generation of that content.

  • Are we using semantic HTML elements throughout the site? This includes proper heading levels, labeled form fields, button elements for interactive controls, and landmark elements like nav, main, and footer.

  • Ask your developer to show you the accessibility tree of your homepage. Have we tested what an AI agent actually sees when it visits our site? Tools exist to inspect the accessibility tree and the raw HTML. Ask your team to do that check before the next major release.

  • Does our site rely heavily on JavaScript frameworks that render content client-side? If so, ask what fallback exists for agents and search engines that do not execute JavaScript.

Built your own site with a page building tool? Question them, hard!

If your page builder tool does not output accessibility-ready code under the hood (that part, that you as a user can’t touch), it doesn’t matter how well you do your things in accessible graphic design, including great color contrast, and correct heading order, etcetera. Your site is toast in agentic search. Period. So ask the team behind your page builder of choice about their code being accessibility-ready.

The systemic view

Jono Alderson put the longer-term implication plainly: your site “isn’t just a visual experience anymore. It’s an interface. An API. A dataset.”

That shift is already happening. AI-powered search like Perplexity, shopping agents, browser automation tools, voice assistants completing tasks on your behalf. All of them rely on some form of structured, machine-readable content. The sites that provide that clearly and efficiently will be easier to work with, cheaper to process, and more likely to be used.

The sites that do not will not disappear overnight. But they will slowly become less accessible to a growing class of users that does not browse the way humans do.

The good news is that fixing this does not require a full rebuild. Semantic HTML, server-side rendering, properly labeled interactive elements, and well-structured content are all established practices. They benefit screen reader users, search engines, and AI agents for exactly the same reasons. The structure that makes a site usable for a person using a screen reader is the same structure that makes it readable to an agent.

Accessibility was never just about compliance, and it was never just about human users. It is about building sites that communicate clearly to every system that needs to understand them.

That circle just got significantly larger.

My talk at WordCamp Europe 2026 covers this and more

If you’re attending WCEU, I’ll be speaking about this on June 5, 15:15 in Track one! Here’s the announcement of my talk, The clarity Dividend, accessibility as an SEO strategy. If you can’t attend, all talk recordings are published online after the event.

Sources

Latest articles

Topics