SUMMARY

Websites need to be designed so that a robot can understand what each button and feature does. Coding with accessibility in mind will suit a lot of what’s required by agentic users. Design with clarity in mind, and check with your developer that your pages aren’t going to jump around (cumulative layout shift) or have messy code generated by a page builder.

If you read my LinkedIn post about “do we need two websites now?” – this is the follow-up I promised. Less “here’s what’s coming” and more “here’s what to actually do about it.”

The question came up when I saw people debating on LinkedIn if you would need one website for people and one basic website for robots to use. And you don’t, but you do need to get your single website designed and built to suit both audiences.

I’m going to split this three ways: what designers and agencies need to start doing differently, what clients should be asking before they sign off on a new build, and the specific technical things that matter right now.

Are designers and agencies thinking about what their code SAYS?

The design process focuses – understandably – on how something looks to a human. Figma files get signed off, everyone loves the colours and the layout, the developer starts building. But nobody has a conversation about what the code underneath is actually going to SAY.

Because here’s the thing: a human looking at your homepage can see that the big orange rectangle is a button that books a call. An AI agent – or a search engine crawler, for that matter – can only know that if the code tells it so. If that button is actually a div styled to look like a button, the robot has no idea what it is. It could be a decoration. It could be anything. That’s essentially invisible functionality, and it matters more now than it ever has.

The shift I’d encourage every agency to make is to start treating the markup brief as seriously as the design brief. Before a developer touches the build, have a conversation about what each element IS and what it DOES – not just what it looks like. What are the calls to action? What’s a navigation element versus a decorative one? What content needs to be explicitly labelled for a system that can’t see the design at all? This doesn’t add weeks to a project. It adds a conversation.

What is ‘actionable HTML’ and why should developers be implementing it?

Actionable HTML – and this is a phrase that’s appeared in Google’s recent documentation that I think is going to become much more common – is basically the idea that your HTML markup should make clear not just what something IS but what it DOES. It’s the difference between a button labelled “button” and a button labelled “add to basket” or “book a discovery call.” The latter tells a robot (or an AI agent browsing on a user’s behalf) exactly what will happen if it interacts with that element.

In practice, this means things like:

  • Using proper semantic HTML elements throughout – so <nav>, <main>, <article>, <section>, <button> – rather than a sea of generic <div> tags that don’t communicate anything about what they contain
  • Making sure buttons are actually coded as buttons, not divs or spans styled to look like them
  • Writing descriptive, specific ARIA labels (ARIA – Accessible Rich Internet Applications – is basically a set of attributes you add to HTML to give extra meaning to elements that might not be self-explanatory) for interactive elements
  • Using clear, descriptive link text – so “book a call” rather than “click here”
  • Making sure form fields have proper labels attached to them in the code, not just floating nearby in the design

A lot of this overlaps with accessibility best practice, which is not a coincidence. The things that help a screen reader understand your website are very similar to the things that help an AI agent understand it. So if your site is already built accessibly, you’re in a good position. If it isn’t, that’s worth fixing for several reasons at once.

Is structured data still something only big websites need to worry about?

No. Structured data used to be something we’d implement as standard for bigger clients – ecommerce sites, publishers, anyone with a large content library where it made an obvious commercial difference. For smaller sites we’d do the basics and move on (just for the sake of their budget).

But we’re now treating structured data as a standard part of every build, regardless of size, because the landscape it operates in has changed. Structured data is basically a layer of explicit labelling you add to your pages that tells search engines and AI systems exactly what your content is – “this is a business,” “this is a product,” “this is a review,” “this is a FAQ.” It uses a shared vocabulary (Schema.org, if you want to look it up) so that the label means the same thing to every system reading it.

The reason it matters more now is that AI agents and AI-powered search features are using this information to understand and summarise web content. If your structured data is missing or out of date, you’re essentially leaving it up to the system to guess – and it might guess wrong, or not include you at all. The good news is that implementing it isn’t wildly complicated. Google’s Rich Results Test is a free tool you can use to check what structured data your site currently has and whether it’s reading correctly.

A big heads up here though, is that not all structured data is created equal – so do read my other post about entity data and understand the difference between that and content data.

What should clients ask before briefing a new website?

If you’re about to invest in a new site – or you’re mid-conversation with an agency about one – here are the questions worth raising before anything gets built. Most agencies won’t bring these up themselves, not because they’re hiding anything, but because clients haven’t historically asked about them.

Ask about structured data: “Will structured data be implemented as standard, and if so, what types will you include for our site?” An agency should have some immediate ideas (or questions for you) about this and be able to explain which schema types could be relevant to your business – whether that’s LocalBusiness, Product, Article, FAQPage, or others.

Ask about semantic HTML and actionable markup: “How do you approach HTML structure – are elements coded to reflect what they actually are and do?” This might sound technical, but it’s a reasonable question and actually quite a leading question. I can’t imagine someone answering “no, we don’t code to reflect what they do”! But it sets the scene that this is important to you.

Ask about CMS choice and code quality: “Does the CMS you’re recommending produce clean, semantic HTML output, or does it generate a lot of unnecessary code?” Some page builders and CMS platforms produce markup that’s technically functional but structurally messy – fine for humans, less good for robots. It’s worth understanding what you’re getting under the hood.

Ask about layout stability: “How can we avoid layout shift?” (Layout shift – CLS, Cumulative Layout Shift – is what happens when elements jump around as a page loads, because images or fonts haven’t loaded yet.) This affects both user experience and how AI agents screenshot and assess your pages. You don’t need to have the actual technicalities explained to you, but you need to flag that it’s important to you.

Ask how they’ll handle your calls to action in the code: “Will the primary actions on each page be explicitly marked up as such, rather than just styled to look like buttons?” It’s a small thing that could make a real difference.

You don’t need to understand the technical detail behind any of these questions. You just need to ask them and see what comes back. If you want a hand with any of this, book a consultancy session with me.

How do you check what your current site is actually doing?

If you’re not about to rebuild but you want to know where you stand, a few starting points:

Google’s Rich Results Test – free, paste in your URL and it’ll tell you what structured data it can find and whether there are any errors.

SiteVitals – free to run your initial report – check the AI readiness section and performance section, specifically the CLS (Cumulative Layout Shift) score.

View source – if you’re comfortable doing it, right-click on any page and hit “View Page Source.” Do a search for things like <div class="button". If your buttons are divs, that’s a flag. Do a search for schema.org – if nothing comes up, structured data probably isn’t implemented.

For anything beyond that, it’s worth asking whoever manages your site to run a proper audit. The specific question to ask them is: “Can you check our structured data implementation and our Core Web Vitals, and give me a plain English summary of where we stand?” If they can’t answer that, it’s worth getting a second opinion. Give us a shout if you’d like us to carry out an AI readiness audit for you.

The summary of all of this is that building a website in 2026 / heading into 2027 requires thinking about two audiences simultaneously – the humans who’ll visit it and the systems that’ll read it. Those two things aren’t in conflict. A well-structured, clearly coded website is usually also a faster, more accessible, better-converting one for human visitors. The work is the same. It’s just that the bar for what “done thoroughly” means has shifted, and it’s worth making sure whoever builds your next site knows that.

If you want to talk through any of this for your specific situation, please get in touch.