SUMMARY

  • Entity schema and content schema are different things that work differently – conflating them is one of the biggest mistakes in current SEO practice (only 2% of sites surveyed have sufficient entity data)
  • Corroboration audit – systematically checking entity consistency across Wikidata, LinkedIn, Crunchbase, Knowledge Panels and sameAs links – should be a named, packaged service
  • An entity brief should be produced before every new website build, because the thinking it forces changes site structure decisions, not just markup
  • Actionable HTML is an agentic concern, not a search one – but a SEO who understands it ultimately achieves better results for a client

There’s a whole new world of what a client actually needs from an SEO engagement, and I don’t think the scope of most retainer work has caught up with it yet. The keyword tracking, the content audits, the monthly reports – they’re all great, but a lot of the work that’s going to determine whether your clients show up in AI-generated answers, get cited with confidence, and have their sites navigated successfully by AI agents acting on behalf of users is done a different way. And it’s quite “upstream” from a lot of traditional SEO work.

I’ve been doing and teaching SEO for twenty years. I speak about it, write about it, make videos about it – and I’ve watched it change more in the last 18 months than in the decade before that. But at 18a we’re primarily a web development agency; we build and fix websites (usually websites where SEO is critical, but still – web dev rather than SEO retainers). And it’s that combination that gives me a particular view of where the gap is between what AI systems need and what most SEO work is currently delivering.

Are we still thinking about structured data as a post-build task?

Just a little shout out – I read a brilliant article by Lisa Marie that was cited in the Women In Tech SEO newsletter that delves into the research on the importance of entity data.

For most of SEO’s history, structured data has been something that gets added after a site is built – a technical audit finding, a box to check before launch, an afterthought on a retainer. And for content schema types like Article, FAQ, or HowTo, that approach is probably fine. Those are page-level signals. You can add them post-build without fundamentally changing anything.

Entity schema is different. Organization, Person, sameAs – these aren’t page-level signals. They’re identity infrastructure. They determine whether AI systems and search engines treat your client as a recognised, resolvable, trustworthy entity, or as an ambiguous website that might be anyone. And yes, you can add entity schema after a site is built – we do it every week on existing sites and it’s absolutely worth doing. But retrofitting it is slower and messier than designing it in, because the questions it forces you to answer (what are this client’s primary entities, what claims are we making, where’s the corroboration coming from?) are questions that should shape content decisions, external profile setup, and site architecture – not just get added via some code at the end.

Our own research, under the flag of our SiteVitals tool, found that just 2% of sites are doing what they could for entity schema (you can run the same report the research used on your site for free here). This distinction between entity schema as infrastructure and content schema as labelling is, I’d argue, one of the most important conceptual shifts in our discipline right now. And most people’s processes don’t reflect it yet.

Should “corroboration audit” be a service we’re all offering?

I think yes, and I think most of us aren’t doing it systematically enough.

The principle is straightforward: AI systems build confidence in an entity by finding consistent, cross-referenced information about it across multiple authoritative sources. Every time a machine sees your client described consistently – same trading name, same address, same description of what they do – across their own site AND an external source it already trusts, that’s a background check passing. Do it enough times, across enough places, and your client stops being a maybe and becomes a known quantity.

Which means our job now includes auditing entity consistency across the web, not just on the site. And that’s a bigger scope than most clients – and really most SEOs – have been thinking about.

A proper corroboration audit looks something like this: Does a Wikidata entry exist, and if so, is it accurate? (Wikidata feeds directly into Google’s Knowledge Graph so it’s the strongest external corroboration signal there is, and a surprising number of established businesses either don’t have an entry or have one that’s out of date.) Does a Knowledge Panel exist in Google, and what does it say? If it says something wrong, how are we correcting it? Is the NAP data (name, address, phone) consistent not just across local directories but across LinkedIn, Crunchbase, Companies House, and any industry body listings? Are the sameAs links in the existing schema actually pointing to live, accurate profiles?

This isn’t glamorous work and it doesn’t produce a beautiful deliverable. But it is apparently the foundation on which AI visibility is built, and right now it’s either not being done at all or being done inconsistently as part of a broader audit rather than treated as its own discipline.

I think there’s a real case for packaging this as a named, scoped piece of work with a clear output, rather than leaving it buried in a technical audit spreadsheet that nobody acts on.

Should SEOs be producing an entity brief before every new build?

This is the one I think will feel the most unfamiliar.

The entity brief isn’t really about the schema fields specifically… it’s about the thinking that schema forces you to do, done early enough to actually change decisions.

Before a new website build starts, someone should be answering the following questions:

What are the primary entities on this site – the business itself, key people, products, services, locations? What claims is the site going to make, and how are each of those claims going to be corroborated – in the markup, on the page, and across the web? What external profiles need to exist or be updated BEFORE launch – Wikidata, LinkedIn, Crunchbase, industry bodies – so that the corroboration network is in place when the site goes live, rather than being scrambled together three months after? And what are the persistent entity identifiers (@id values in JSON-LD) that will be used consistently across every page that references each entity?

Doing this thinking before the build changes what content gets created, what external profile work gets done before launch day, and what the developer gets briefed on. The schema itself can be added whenever – but the decisions it reflects are easier (and therefore cheaper) to make before anyone’s written a line of code.

Our own site is a good example of this, and it’s something we’re actually working through right now. We’ve been implementing Person schema on the people who’ve left us testimonials, tagging them as verifiable entities with sameAs links to their LinkedIn profiles, and associating each testimonial explicitly with the specific service it relates to using the itemReviewed property. Good so far. But doing that work has made us realise that our services pages need restructuring, because some of our testimonials are currently for services that don’t have their own dedicated page. The entity data is pointing at something that doesn’t properly exist yet in our site architecture.

So we’re adding pages. Perfectly doable on an existing site – but it’s the kind of structural decision that’s cleaner to make before a build than after it. Before you’ve got URLs indexed and you’re 301’ing this, that and the other. If we’d done the entity thinking first, the sitemap would have included those pages from day one. The testimonials would have had the right target. The internal linking would have been set up correctly.

Instead we’re retrofitting the architecture to match the entity structure, which works but is slower. And the underlying principle – that deciding what your testimonials relate to is effectively deciding what your service pages should be, which is deciding what your navigation looks like – is a conversation that absolutely belongs at the brief stage.

Now this is a pretty geeky thing to get excited about, but I am genuinely excited about the work we’re doing on our testimonials! (And that’s not ChatGPT or Claude saying “genuinely” – it’s actually me!) So I’ve written all about it here – you can literally copy and paste the mark up we’re using. I think testimonials can do so much more heavy lifting than most people are asking of them. So I’m breaking the rules and saying that the testimonial and entity schema examples article will open in a new tab so you can click this link now and know you’re not going to lose where you’re at in this article.

I think clients can find the brief-stage entity conversation genuinely useful – once you get past the initial “I don’t know what an entity is” bit. The questions aren’t really technical, they’re things like: “What do you want to be known for? Who are the people whose credibility you’re trading on? What external sources would a sceptical machine find if it went looking for evidence that you are who you say you are?” Those are good strategic questions regardless of SEO, and they have direct consequences for site structure that most builds never surface at all.

Where can SEOs add the most value in the agentic conversation?

Google’s recent documentation about what AI agents want from websites talks about “actionable HTML” – markup that communicates not just what an element IS but what it DOES. Buttons that are actually buttons, coded as such. ARIA labels that describe a real function. Navigation that a system can traverse without seeing the design.

The implication is clear: AI agents – systems that navigate websites on behalf of users to complete tasks, not just retrieve information – need to understand what they can DO on a site, not just what it’s about.

This is different from AI search. AI search reads your pages. AI agents USE your pages. An AI agent acting on behalf of a user who wants to book a call, request a quote, or make a purchase needs to navigate your client’s site successfully. If the markup is ambiguous or the buttons aren’t properly labelled, the agent fails. The user (or their agent) was there. The intent was there. The site let them down.

Now: is this SEO’s job? I think that depends entirely on how you define your job. If your job is getting pages found, probably not. But if your job is generating enquiries and conversions for clients – which is what most of our clients think they’re paying for, even when they use the term “SEO” – then yes, absolutely. A missed agentic conversion is a missed conversion, full stop.

This is also where being involved early – or being the person who asks the right questions even if you come in on an existing site – really matters. Particularly if your client is working with a development team or agency that isn’t thinking about this yet. (And soooo many aren’t.)

And it’s not on most designers’ radar at all. Which means there’s a real role for someone who understands both the visibility implications and the technical reality to be the person who raises it. A developer can add an ARIA tag after the fact fairly easily. But button SIZE, button PLACEMENT, and button LABELS are decided in design. Google’s documentation specifically calls out that AI agents screenshot pages and assess button sizes. A designer who specifies elegant, small ghost buttons for aesthetic reasons – a perfectly reasonable visual decision – is also making a decision that affects agentic navigability, almost certainly without realising it.

Or consider a designer who uses a hover state to reveal a “Book” or “Buy” button on a product card. Clean, works beautifully for humans. What if the AI agent can’t hover? That action is completely invisible to it, and no ARIA tag fixes a design decision that hides the action until hover. If nobody’s asked the agentic question at brief stage, and helped brief the designer, it’ll be more long winded to get sign off for later.

What do these conversations actually look like with clients?

The entity conversation is easier to have than it sounds, because you can frame it without using the word “schema” once.

Ask: “If an AI system was trying to verify that your business is who it says it is – checking your name, your claims, your credentials across the web – what would it find? And would everything it found be consistent and point back to you?” That question tends to land immediately. Especially for clients who’ve ever been confused with another entity, or who’ve seen an AI tool produce inaccurate information about them. The business case is obvious once it’s framed as reputation and verification rather than technical markup.

The agentic conversation can be framed differently: “Which actions on your website are commercially critical – the things a customer needs to be able to complete for the site to do its job? And how do we make sure those actions are as clear and navigable as possible, not just for humans but for the automated systems that are increasingly acting on their behalf?” Most clients already know which pages matter, they just haven’t thought about making those pages navigable for anything other than a human.

With developers, raising this at the brief stage tends to get a much better response than dropping a spreadsheet of “errors” during UAT. (Top tip for talking to developers – don’t call something a “bug” or “error” if it’s actually an unrequested emission!)

So is SEO a bigger job than it was? Yes. Is it a better one? Also yes!

The scope of what’s useful has expanded, and the skill set required has broadened. And there are conversations happening – or not happening – in client relationships and build projects that someone with a strong technical SEO background is genuinely well placed to lead. The entity work, the corroboration audit, the entity brief, the agentic question: these sit right at the intersection of SEO expertise and web development knowledge. For clients working with agencies or developers who aren’t across this stuff yet, it’s exactly the kind of involvement that makes a real difference.

If you found this article useful…

…grab a seat at the next talk in Lisa’s Agentic Web series. A recording will be sent for anyone who can’t make it live.

Grab your seat