Building Websites for AI: Why Accessibility, Structure and Clarity Matter

9 min read

Building Websites for AI: Why Accessibility, Structure and Clarity Matter

As AI becomes another front door for discovering information, a fairly predictable question is starting to crop up in marketing meetings:

“Do we need to redesign our website so AI can understand it?”

The reassuring answer is: probably not.

You certainly don’t need to rip everything up and rebuild your website around the latest three-letter acronym being sold as the future of search.

In fact, much of what makes a website easier for AI systems to understand is already familiar territory: good accessibility, sound technical SEO, semantic HTML and clear content structure.

There is, however, one important misconception worth clearing up first.

1. Can AI Actually “Read” Your Website?

The confusion usually starts with a demo.

Someone uploads a complicated chart, a screenshot of some software or a photograph of a whiteboard into ChatGPT or Claude. The AI interprets it, summarises it and explains what is going on remarkably well.

The obvious conclusion is:

“If AI can understand that image, surely it can understand all the graphics, icons and animations on our website?”

Hm, not necessarily.

There is an important difference between what an AI model can understand when you deliberately give it something to analyse and how search, crawling and retrieval systems discover information across billions of web pages.

When you upload an image directly to mainstream AI model, that image is explicitly being presented for analysis.

Web discovery is different; depending on the platform, systems may work with combinations of:

HTML
Extracted text
Headings and document structure
Links
Metadata
Structured data
Rendered page content
Search indexes
Cached or previously processed information

Some systems may also use visual or multimodal processing as part of that process. The important point is that we shouldn’t assume every graphic, animation or icon on every page is being interpreted visually in the same way as an image uploaded directly into an AI conversation.

Put simply: Just because AI can understand something doesn’t mean every AI retrieval system is looking at it.

2. AI Capability & AI Web Discovery Are Different

This distinction matters.

AI interpretation:

You give a model an image, screenshot, chart or PDF and explicitly ask it to analyse it.

AI web discovery:

A crawler or retrieval system has to process huge volumes of online information efficiently, work out what matters and make that information available later when somebody asks a relevant question. Those are very different jobs.

An AI model might be perfectly capable of understanding your beautifully animated customer journey. That does not necessarily mean the system discovering your website has analysed that animation frame by frame and understood the story you intended it to tell.

So, a useful rule for web teams is:

Don’t make important business information dependent on a machine successfully interpreting the visual design.

If something matters or it’s worth saying, say it with words!

3. The “As Things Stand Today” caveat

There is an important caveat we should include here, which is that AI technology is moving ridiculously quickly.

Multimodal systems are improving, processing costs will change and search systems are likely to become increasingly capable of understanding complete rendered pages, not just their underlying text and markup.

So this is not an argument that:

“AI can’t understand website visuals.”

It is an argument that:

As things stand today, important commercial information should also exist in explicit, accessible and machine-readable form.

Tomorrow’s crawlers may be considerably better at understanding an infographic, interactive demo or animation.

Fine. But clear HTML underneath it still won’t have done you any harm.

4. Accessibility, SEO and AI-Readability Intersection

This is where things get interesting.

If you want to make a website easier for AI systems to interpret, accessibility is a surprisingly good place to start.

The three disciplines overlap considerably.

Accessibility: Makes information understandable and usable across different devices, abilities and assistive technologies.

SEO: Makes information easier for search engines to discover, crawl, interpret and index.

AI-readability: Makes information easier for retrieval & generative systems to extract, contextualise and reuse accurately.

And many of the things that help one also help the others, such as:

Sensible heading hierarchies
Descriptive links
Semantic HTML
Logical page structure
Useful alt text
Clearly labelled forms and controls
Accessible navigation
Text explanations of important visual information

That gives us a useful principle:

A page that explains itself clearly to a screen reader will often also explain itself more clearly to a machine.

Not because AI engines follow accessibility standards in exactly the same way, but because both benefit when meaning is explicit rather than implied.

5. What Makes Pages Easier for Machines to Understand?

There isn’t a secret “AI HTML” specification, a lot of it is simply disciplined web publishing.

Use a clear H1

The main heading should make the subject of the page blindingly obvious.

Build a logical H2/H3 hierarchy

Headings should describe the structure of the information, rather than being chosen because someone likes the font size.

Use descriptive page titles

“Services” tells a machine (or a human) very little.

“Commercial HVAC Maintenance and Repair Services” tells both groups considerably more.

Write meaningful links

“Click here” and “Read more” throw away useful context.

“Explore our kitchen management systems” tells the reader what lies at the other end of the link. Yes, this can make button design, especially for mobile devices… challenging.

Use proper lists and tables

If something is a list, mark it up as a list.

If you’re comparing genuine tabular information, use a table rather than creating something that merely looks like one.

Use semantic HTML

Use meaningful structural elements such as "main", "navigation", "articles" and "sections", alongside proper headings and correctly marked-up controls, to help describe how a page is organised.

The wider principle is straightforward:

Don’t make the machine infer something you can state clearly.

6. Structured Data: Giving Machines Explicit Clues

Structured data takes that idea one stage further. A page may contain enough information for a person (or a search system) to infer that it is an article written by a particular person about a particular product.

Schema markup allows some of those relationships to be described explicitly in a standard machine-readable format.

Using JSON-LD, for example, you may be able to identify:

An Organization
An Article
A Person
A Product
A BreadcrumbList
Other entities appropriate to the page

Google itself describes structured data as providing explicit clues about the meaning of a page. That is actually a very useful way to think about it as it reduces ambiguity. It doesn’t eliminate it entirely and it certainly isn’t some sort of magic dust that suddenly makes a page rank in ChatGPT, Gemini or Google.

Similarly, using Schema to describe things that aren’t genuinely represented on the page, definitely a bad idea, but used properly schemat simply gives automated systems another clear source of context.

7. Why Structure Matters When Content’s Retrieved in Pieces

There is another reason to structure content well, which is becuase many modern retrieval systems work with sections or passages of information rather than necessarily handing an entire 2,000-word webpage to an AI model every time somebody asks a question.

Think about this sentence:

“It integrates automatically and removes the need for manual data entry.”

Perfectly understandable when you’ve just read the preceding five paragraphs. Taken out of context? Not so much. What is “it”?

Now compare it with:

How the CRM Integrates with Your Accounting Software

“Our CRM integrates with compatible accounting platforms, reducing duplicate data entry and helping sales and finance teams work from the same customer information.”

That passage retains much more of its meaning if it is retrieved independently, although we’re not advocating for every paragraph becoming a robotic mini-essay designed for AI.

It simply suggests another sensible content principle:

Important sections should make reasonable sense when encountered on their own.

Good headings help. Clear nouns help. Constantly referring to “it”, “this” and “the solution above” does not.

8. Good Content Provides Information, Structure Provides Context.

Raw copy still matters enormously becuase no amount of clever markup can rescue a page that doesn’t actually answer the user’s question.

But structure helps automated systems understand relationships within that content:

What the page is primarily about
Which information belongs together
What constitutes a definition
Which steps form a process
Which items are being compared
What belongs to a particular product or service
What is navigation and what is the main content

So the hierarchy is not: Structure instead of content.

It’s: Good content first. Good structure around it.

9. Lottie, SVGs, Infographics and Problems with Visual Meaning

This is where things become very tangible.

Modern websites communicate a lot through:

Lottie animations
SVG illustrations
Diagrams
Icons
Infographics
Animated workflows
Interactive product demos

Check the hero image for this article. It’s a fairly clear and simple way of communicting the article’s content quickly and succinctly, so for humans at least it sets the scene rather nicely. Another, very vogue example is Lottie animations. Imagine an animation showing an order placement system for a hospitality firm:

Order placed → Sent to kitchen → Meal prepared → Ready for collection

A human understands the process in seconds and yes, if you handed screenshots of that animation to a capable multimodal AI model, there is a reasonable to good chance the Ai model would understand it too.

But that does not mean every crawler visiting the page will interpret the visual narrative. It may instead encounter a player, SVG paths, animation data, scripts and whatever supporting markup surrounds them. So don’t make the animation do all the work!

Keep the lovely animation.

But put the process in HTML too:

Customer places the order
The order is sent to the kitchen
Kitchen staff update the preparation status
The customer is notified when the order is ready

That is a good example of a tension that exists between making a web page visually pleasing and engaging to people and readable for digital systems. The visual communicates beautifully to the human, but the HTML makes the underlying meaning explicit to everybody else.

10. Try the “What If the Images Disappeared?” Test

Here’s a useful test for any commercially important page:

If every image, diagram, icon and animation vanished, would the important message still make sense?

If not, the page may be relying too heavily on visual implication. That doesn’t mean describing every decorative flourish in painstaking detail, instead it means making sure important information isn’t trapped inside a graphic.

Use:

Useful (and relevant) alt text where appropriate
Captions for charts and complex diagrams
Nearby explanatory copy
Visible labels next to meaningful icons
HTML lists or tables where the information naturally belongs there

If an icon means “24/7 Support”, there is very little downside in also writing 24/7 Support next to it.

11. Descriptive Links: Tiny Change, Useful Context

Consider: To see our software options, click here.

versus: Explore our kitchen management systems.

The second call to action is simply better, because a human understands the destination and a screen reader user gets useful context.

A crawler also has a much clearer description of the relationship between the current page and the destination page.

This is a nice example of an accessibility improvement, an SEO improvement and an AI-readability improvement all being essentially the same piece of sensible web design!

12. JavaScript: “Can Render” Isn’t the Same as “Make It Difficult”

The old claim that Google simply “can’t read JavaScript” is well past its sell-by date now. Googlebot can render JavaScript and Google indexes rendered HTML.

But there is still an important distinction between something being possible and making every crawler work unnecessarily hard to get to your important content.

Google itself notes that “server-side or pre-rendering remains a good approach because it can be faster for users and crawlers”; and not every bot runs JavaScript.

Potential trouble spots include:

Content only appearing after an unusual interaction
Important text being injected late
Broken client-side rendering
Widgets whose content doesn’t appear in the rendered HTML
Navigation that isn’t represented by crawlable links
JavaScript failures preventing important content from appearing

So the sensible rule isn’t: Never use JavaScript.Of course use JavaScript!

The more sensible “rule” is:

Don’t hide your pitch behind unnecessary technical gymnastics.

If a product benefit, specification, price or key proposition matters commercially, make sure automated systems can reliably reach it.

13. `robots.txt`: You Can Also Shut the Door Yourself!

There’s a final technicality that is easy to overlook which is that you can build an impeccably structured, accessible website and then prevent particular automated systems from crawling it. Oops.

AI platforms increasingly publish their own crawler controls, and importantly, not all of them serve the same purpose.

For example:

OpenAI uses OAI-SearchBot for web discovery associated with ChatGPT search.
Perplexity describes PerplexityBot as the crawler used to surface and link websites in Perplexity search results.
Google’s Google-Extended is different again: it is a robots.txt product token controlling certain uses of crawled content for Gemini models and grounding. It does not control inclusion in ordinary Google Search.

That distinction matters because Search/indexing controls and model-training controls are not necessarily the same thing.

So before adding blanket bans to robots.txt, understand exactly what each rule does and revisit it occasionally. This area is changing quickly; a robots policy written two years ago may no longer reflect what the business actually wants.

14. A Simple AI-Readiness Audit

Run an important page through these questions, it won’t take long:

Would the page still make sense if its images disappeared?

Would the key message survive if animations failed to load?

Is the main topic obvious from the H1 and opening copy?

Do H2s and H3s create a logical structure?

Can important sections make sense when read independently?

Do internal links describe where they lead?

Are important workflows also explained in text?

Is genuinely comparative data marked up appropriately?

Can important commercial content be accessed without unusual interaction?

Is useful information buried solely inside graphics?

Is appropriate structured data implemented accurately?

Can relevant search and AI crawlers access the content?

Would a screen-reader user understand the core proposition?

If most of those answers are yes, you’re probably in pretty decent shape, not just for AI but for the web generally.

15. Optimise for Understanding, Not for This Month’s New Bot

Trying to chase the exact quirks of ChatGPT, Perplexity, Gemini or whatever arrives next Wednesday is unlikely to be a winning long-term strategy.

So be aware that the better question isn’t:

“How do we trick an AI into citing our website?”

It’s:

“How do we make our website’s meaning so clear that people, assistive technologies, traditional search engines and AI systems can all understand it?”

The technology will change, think how Ai has changed in the last twelve months… the last three years even! AI systems will of course become more capable, visual “indexing” will improve and crawler behaviour will evolve.

But, clear writing, sensible structure, accessible media, semantic HTML and straightforward crawlability are unlikely to suddenly become bad ideas.

That is perhaps the best news of all as it means building a website for AI doesn’t necessarily mean learning an entirely new set of rules.

It may simply mean getting much better at the rules we should have been following all along anyway.

About the author

This article was written by Stuart Noton, a marketer working with growing businesses to bring more strategic direction to their digital marketing, based near to Stowmarket in Suffolk. View LinkedIn profile.