We get asked about structured data (code that describes your website to machines) more than almost anything else at the moment. And the question is nearly always the same: “does it make a difference?”

SUMMARY

Entity data tells machines who you are, what you know about, and which other sites confirm it – and it matters more than the fancier schema types. It’s about trust. AI tools increasingly decide who to cite based on how confident they are you’re a real, recognised thing, and entity data removes the doubt. The sameAs property is the one to never skip: it links you to verifiable profiles like LinkedIn, Crunchbase, Companies House and Wikidata. You can usually add it to WordPress yourself with an SEO plugin or a code-snippet plugin. It’s invisible. It sits in your page’s code for the machines, not on the page for your visitors.

And it’s an understandable question as there have been various reports lately claiming it perhaps doesn’t… but then you dig deeper and find that it depends on the circumstances. And it depends on the schema you use. This is a bit backwards, but I’ve actually updated this post with a chunk on all the research that’s been happening lately in this world – and it’s at the END of this article. Which is odd, as it’s the reason for the rest of it, but it’s so that if you’ve landed here from my newsletter you don’t need to read loads of theory if it doesn’t interest you!

But basically, there are different types of schema. There’s schema for articles, products, recipes, events, reviews, opening hours, FAQs – on and on. You could spend a month tagging up your whole site and still not be finished. So if you’ve only got an afternoon, or a small budget, or one job you can hand to a developer, we’d point you at one thing before any of the others.

Entity data is the stuff that tells search engines and AI tools who you actually are, what you know about, and which other places online back that up. Below is why it matters more than the rest, what good entity data looks like, and how to get it onto a WordPress site (amongst others) without it ever showing up on the page.

What do we actually mean by “entity data”?

An entity is just a thing the web recognises as a distinct thing – your company, a person, a product, a place. Entity data is the structured information that pins down which entity you are and connects you to the version of you that already exists out there in Google’s Knowledge Graph (the big database of people, places and organisations that sits behind search) and on sites like Wikidata, LinkedIn and Companies House.

So instead of a machine reading your homepage and going “right, there’s a company called something here, probably based somewhere, possibly the same one I’ve seen on LinkedIn… maybe?”, you hand it the answer directly. This is us. Here’s our legal name, our logo, what we’re known for, and here are five other places online that confirm it’s really us.

That last part is the bit that does the heavy lifting – I’ll come back to it later.

Why does AI care who you are?

There’s a lot of hype flying about but it’s more nuanced than “AI reads your schema”.

Most AI tools don’t sit there reading your JSON-LD (a tidy block of code that holds your structured data) the moment someone asks ChatGPT a question about you. What they mostly lean on is the entity understanding that search engines and knowledge graphs have already built up over time. Your structured data feeds that understanding. So you’re not really talking to the AI directly – you’re making sure the picture it’s trained on, and the sources it pulls from, have you down correctly.

When an AI search tool like Perplexity does fetch your page live, some of them do parse your structured data alongside the visible text, and they use it to confirm facts with a bit more confidence. But – and this matters – if your schema says one thing and your actual page says another, they trust what’s on the page and mark you down as less reliable. So your entity data has to match reality. No inventing credentials you don’t have.

The reason entity data wins over the content schema types is trust. AI systems are increasingly choosing who to cite based on how confident they are that you are a real, recognised thing – not a vague website that might be a one-person reseller in a back bedroom. Clear entity data, backed by external sources, removes the ambiguity. And when the machine is deciding whether to mention you or a competitor, removing that ambiguity is often what tips it your way.

Like this explainer?

Join 1,100+ other organisations who receive Lisa’s newsletter for a weekly email on timely tips for your website.

Get newsletter

What does good entity data look like?

Here’s a stripped-back Organization block you can copy and fill in. Swap the placeholders for your real details and bin the bits that don’t apply:

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "Your Company Ltd",
  "legalName": "Your Company Limited",
  "url": "https://www.yourcompany.co.uk/",
  "logo": "https://www.yourcompany.co.uk/logo.png",
  "description": "A plain sentence or two on what you do and who you do it for.",
  "foundingDate": "2014",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "1 Example Street",
    "addressLocality": "Bristol",
    "postalCode": "BS1 1XX",
    "addressCountry": "GB"
  },
  "areaServed": "United Kingdom",
  "knowsAbout": [
    "Something you're genuinely known for",
    "Another core service",
    "A third thing you do well"
  ],
  "hasCredential": [
    {
      "@type": "EducationalOccupationalCredential",
      "name": "An accreditation you actually hold"
    }
  ],
  "contactPoint": {
    "@type": "ContactPoint",
    "url": "https://www.yourcompany.co.uk/contact/",
    "contactType": "customer service",
    "availableLanguage": "English"
  },
  "sameAs": [
    "https://www.linkedin.com/company/your-company",
    "https://www.crunchbase.com/organization/your-company",
    "https://find-and-update.company-information.service.gov.uk/company/00000000"
  ]
}

A few of those properties earn their place more than others. knowsAbout tells machines the topics you’re an authority on, which helps connect you to the right questions. sameAs is the one we’d never skip – more on that next. And if you’re a bigger outfit, you can add a brand for a named product and a subOrganization for separate trading entities or regional offices. Most small businesses won’t need those, so don’t feel you have to pad it out.

Why is “sameAs” the bit that matters most?

Think of sameAs as the connective tissue between your website and the wider web. Each link is an external, authoritative source that Google and the AI tools can cross-reference to confirm you’re really you. Your LinkedIn company page. Your Crunchbase profile. Your Companies House listing. And if you’ve got one, your Wikidata entry – that’s the strongest of the lot, because it feeds straight into Google’s Knowledge Graph.

This is exactly the idea I talked through in my recent Masterclass on AI retrieval as continued due diligence. Every time a machine sees you described consistently across your own site and a handful of verifiable sources, that’s a little background check passing. Do it enough times, across enough places, and you stop being a maybe and become a known quantity. sameAs is how you hand the machine the references to check.

Going all in on testimonial schema

Testimonials are a really good example of where entity schema can do genuinely meaningful work – and where most implementations are leaving a lot on the table. The standard approach is a Review type with an author name, a rating, and a reviewBody. It validates. It’s not wrong. But it’s a content signal, not an entity signal, and if we’re thinking about corroboration and entity establishment, we can do significantly more.

We’ve started tagging up the people who leave testimonials on our site, so the praise comes from a verifiable human rather than an anonymous quote that could be anyone (or made up). Here’s the shape of it:

{
  "@context": "https://schema.org",
  "@type": "Person",
  "name": "Jane Smith",
  "jobTitle": "Marketing Director",
  "worksFor": {
    "@type": "Organization",
    "name": "Another Company Ltd"
  },
  "knowsAbout": [
    "B2B marketing",
    "Brand strategy"
  ],
  "sameAs": [
    "https://www.linkedin.com/in/jane-smith-example"
  ]
}

So now a glowing testimonial isn’t just words on your page – it’s tied to a real person with a real LinkedIn profile and a real job, who happens to know about the thing they’re praising you for. Obviously you ask permission first, and obviously you only link people who are happy to be linked. But done properly, it’s genuinely good evidence, and it’s the kind of corroboration that machines like to see.

But there’s more you can do too…

  1. Tie each testimonial to a specific service or product using itemReviewed. Rather than a generic Review floating on the page, associate it explicitly with the Service or Product it’s about. This tells AI systems “this testimonial is specifically about THIS capability” – not just “this company is generally well regarded.” A testimonial about your client’s SEO audit work shouldn’t be semantically identical to one about their content strategy. Give them different targets.
  2. Mark up the reviewer as a Person entity, not just a name string – and use sameAs to link to their LinkedIn profile. A name in a quote is just a name. A Person entity with a sameAs pointing to a real, verifiable LinkedIn profile – where that person exists, works where they say they work, has the job title you’ve attributed to them – is a claim that can be checked and corroborated. We’re implementing this on our own site specifically to tie well-known publishers to quotes they’ve left us. The connection is currently just text. It should be a machine-readable relationship.
  3. Use Organization schema on the reviewer’s employer, with sameAs pointing to Wikidata, Crunchbase, their LinkedIn company page, or Wikipedia where they exist. The more recognisable the organisation leaving the testimonial, the more important this becomes. Don’t waste that credibility by leaving it as a string. An AI system doing due diligence on your client’s claims will find corroboration, rather than nothing to go on.
  4. Use ItemList to group and categorise testimonials by use case. Rather than all testimonials living in one undifferentiated blob, structure them into lists that correspond to service areas or product categories. An ItemList containing Reviews for one service and a separate ItemList for another gives AI systems a much cleaner signal about what evidence exists for which capability.

None of this is experimental, all of it is valid schema, and most of it isn’t being done. And all of it is operating at the entity layer – the part the research suggests actually matters for AI visibility – rather than the content layer that most short-term studies are measuring.

How do you get this onto a WordPress site?

Good news first: a lot of the basics are probably half-built already. If you use an SEO plugin like Yoast, dig into its settings – there’s usually an Organization section where you fill in your name, logo and social profiles. Those social links are your sameAs, basically, so turn that on before anything else.

For the richer stuff – knowsAbout, credentials, tagging individual people – you’ll usually need to add custom JSON-LD. The easiest no-developer route is a code-snippet plugin like WPCode (or “Insert Headers and Footers”). You paste your JSON-LD block in, tell it to load across the whole site or on specific pages, and that’s it.

When would you ask a developer? If you want a Person block generated automatically for every testimonial, or the markup applied cleverly across loads of different page types, or you’re just not comfortable pasting code – hand it over. It needn’t be a big project so don’t let it become one – use the code above to copy and paste and enter your details so you can hand your developer exactly what you need added.

Whichever route you take, test it. Pop your URL or your code into Google’s Rich Results Test or the Schema.org validator and check it parses cleanly with no errors. A broken block can do more harm than no block at all.

Will this change how my website looks?

No. Your entity data lives inside a <script type="application/ld+json"> tag in the page’s source code. Your visitors never see it. It doesn’t add a box to your homepage or change your design one bit. It sits in the background, purely for the machines reading your code. You can have the most thorough entity data on your block and your customers would never know it was there.

So there’s no design cost to weigh up. It’s a back-end job that pays off in how confidently search engines and AI tools can talk about you.

Where to start this week

If you do one structured data thing in the next fortnight, set up your Organization block with proper sameAs links to every verifiable profile you’ve got. Turn on whatever your SEO plugin already offers, then add the rest with a snippet plugin or a quick developer job.

And if you’ve got testimonials on your site, have a think about tagging the people behind them too. It’s a small bit of work that turns nice words into checkable evidence – which is the whole game when machines are deciding whether to trust you.

The background to all this – do we need structured data anymore?

A May 2026 study by Louise Linehan and Xibeijia Guan at Ahrefs tracked 1,885 pages that added JSON-LD schema over seven months, measured against 4,000 control pages. Their finding: adding schema produced no meaningful uplift in AI citations on Google AI Overviews, AI Mode, or ChatGPT. Which sounds alarming, until you read the methodology – every page in the dataset already had 100+ AI Overview citations before the study began. These were pages already inside the AI consideration set. The study was essentially asking whether adding a label to a bottle already on the shelf makes customers pick it up more. That’s a different question from how the bottle got on the shelf in the first place.

Pedro Dias, in a May 2026 piece in The Inference, explains the architecture: large language models don’t have a schema parser. They process text as sequences of tokens. There is no mechanism at query time by which an LLM reads your JSON-LD. A separate study tracked five major AI systems – ChatGPT, Claude, Perplexity, Gemini, and Google AI Mode – fetching pages in real time. Every single one extracted visible HTML only. Not schema. Not structured data. (A shout out to Lisa Marie for laying a lot of this out.)

So does schema matter? Yes, absolutely – but it does its work UPSTREAM, at indexing and entity resolution, not at the moment an AI retrieves your page to answer a query. Gianluca Fiorelli put it well in his response to the Ahrefs study: schema is less like placing an ad and more like registering a company. You don’t register a company expecting the act of registration to immediately drive revenue. You register it because without that registration, the company doesn’t exist as a verifiable entity in any official system. The downstream benefits depend on the registration being complete and accurate – but you can’t measure them by asking whether citations went up in 30 days.

This is why the distinction between entity schema and content schema matters so much – and is one I think lots of people aren’t really aware of yet. Organisation, Person, and sameAs are entity identity signals. Article, FAQ, and HowTo are content signals. They operate on completely different timelines and serve completely different purposes. A study that pools them all together, as the Ahrefs research did, simply cannot detect entity-level effects. That doesn’t mean those effects aren’t happening. Meanwhile SiteVitals’ research has found that only 2% of sites surveyed had complete Entity data.

The sameAs property is one of the most underused tools we have, and the research is increasingly pointing to entity consistency and corroboration as the foundation on which everything else is built.

The principle is straightforward: AI systems build confidence in an entity by finding consistent, cross-referenced information about it across multiple authoritative sources. Your client’s Organization schema saying they’re called X and based in Y is a start. That same information appearing on their Wikidata entry, their Crunchbase profile, their LinkedIn company page, their Google Business Profile – all linked back via sameAs – is a corroboration network. Each consistent data point adds weight. Each inconsistency erodes it.

Martha van Berkel, CEO of Schema App, has published some compelling enterprise case study data on this. Following entity linking implementation, Schema App clients have seen significant uplift specifically on non-branded entity queries – InSinkErator observed a 69% increase in clicks and 116% increase in impressions for non-branded product queries; Henry Ford Health saw a 113% increase in clicks year-over-year on optimised pages. But the example I think is most instructive is Wells Fargo, where connected schema markup was used to correct AI hallucinations about branch closures. AI systems were serving inaccurate third-party information, and structured entity data was the mechanism that corrected it. That’s not a visibility story. That’s a brand protection story. And as AI-generated answers become a primary touchpoint for consumers, the cost of inaccurate entity representation is only going to grow.

This means our job now includes auditing entity consistency across the web, not just on the client’s own site. Wikidata entries are publicly editable and more achievable than most clients assume. NAP consistency matters not just because of Google’s local algorithm but because AI systems doing due diligence on entity identity will find and weight inconsistencies.

So that’s the science bit – if you’ve read this far, give yourself a pat on the back! If you want to check your Entity data, you can carry out a free audit on SiteVitals. Or if you’d like a hands on helping hand, get in touch.