Entities and structured data: how search engines and assistants recognise a business, person or product

Search engines stopped matching words and started recognising things a long time ago. When someone searches for a company, a person or a product, the system tries to work out which real-world thing they mean, what it knows about that thing, and which sources it trusts for each fact. AI assistants do something similar every time they answer a question about a business: they retrieve several sources, compare them and write an answer from whatever agrees. This guide is about how that recognition works and what you can do to make it accurate.

It covers what an entity is, how Google's Knowledge Graph and knowledge panels get their facts, what Wikidata and Wikipedia are for and when a business qualifies, how assistants reconcile what they read, how to keep records consistent, and then structured data in detail: JSON-LD, @id graphs, the core schema.org types, which markup still earns rich results, the policies, validation, and the specific cases of people and products. It builds on the local SEO guide and the AI search guide, and the practical setup for a single business is in the entity record stage of the exact match domain tutorial. Platform documentation changes often, so read every dated statement as true in October 2026.

An entity is a single, distinct thing that can be described with facts: a company, a shop, a person, a product, a place, a book, an event. The word in a query is only a pointer to it. “Mercury” can mean a planet, a chemical element, a record label or a singer, and the job of the search system is to work out which one is meant and then return facts about that thing.

Google described this shift in 2012 when it launched the Knowledge Graph under the line “things, not strings”. At launch the graph held more than 500 million objects and more than 3.5 billion facts about and relationships between them, drawn from sources including Freebase, Wikipedia and the CIA World Factbook.¹ The idea was older than Google's version of it. In the research literature a knowledge graph is a graph of data in which nodes represent entities and edges represent relationships between them, and the field covers how such graphs are built, how identity is handled and how their quality is assessed.²

Entity linking: how a mention becomes an entity

The step that connects a page to a graph is called entity linking: finding the mentions of things in text and resolving each to an entry in a knowledge base. A 2020 paper from Google researchers, for example, built one model that links mentions in 104 languages to 20 million entities in Wikidata, chosen because it is language-agnostic, broadly accessible and actively maintained.³ The paper also made a point that matters for smaller businesses: rare entities, the ones with few mentions, are the hardest to link correctly.³ A national brand is mentioned thousands of times in consistent ways. A joinery firm in one town might be mentioned a dozen times, and if three of those mentions use a different name, the signal is weak.

That is the practical reason this topic matters. The search system is trying to be sure that the page, the profile, the review and the news story all refer to the same thing. Everything in this guide is about making that easy to be sure of.

The kinds of entity this guide covers

Checking whether Google already has an entity for you

Google's Knowledge Graph Search API lets anyone look up entities in the graph. It returns results using schema.org types in JSON-LD, including an entity ID such as kg:/m/0dl567.⁴ It is useful for one thing in this context: checking whether Google has an entity for your business or a person, what type it thinks it is, and what description it holds. It has limits worth knowing. It is read-only, returns single matching entities and not the graph around them, is not meant for production-critical use, and Google is moving users towards a newer Cloud Enterprise Knowledge Graph product.⁴ An empty result does not prove there is no entity, and a result does not tell you what any assistant knows.

A knowledge panel is the box that appears for an entity in Google's results, and it is the most visible output of the Knowledge Graph. The help pages describe the sources only broadly. Facts come from a variety of sources that compile factual information, from licensed data for things like sports scores, stock prices and weather, and directly from content owners.⁵ Improvements are mostly made through the automated systems, with manual removal of information that breaks policy, and Google may remove information that is demonstrably false or outdated, as evidenced by legal documents, expert consensus or reputable primary sources.⁵

There is no list of which websites feed which facts, and there is no form to request a panel. Panels are generated automatically. In my experience they follow from consistent facts across many independent sources, but Google does not publish a threshold, and nobody outside Google can promise one.

Claiming a knowledge panel

If a panel already exists for you or the organisation you represent, it can be claimed. The process is to search for the entity while signed in to a Google account, click “Claim this knowledge panel” at the bottom of the panel, and verify by signing in to one of the listed official profiles: YouTube, Search Console, Twitter or Facebook.⁶ Once verified you can suggest changes and add other people as owners, managers or contributors. Not every panel can be claimed yet, so check back periodically for the button. A local business serving customers at a location should use a Google Business Profile instead.⁶

Suggesting edits, and what evidence carries weight

Verified users suggest edits from the top of the panel, describing what is wrong, what to remove and any publicly accessible URLs that support the change. Google reviews feedback from verified users within a few days, can make some corrections directly (links to social profiles, for example), and checks feedback for accuracy by comparing it with other public information on the web.⁷ That last part is the important one. A correction that contradicts what the rest of the web says is unlikely to stick, so if a panel shows the wrong founding date, the wrong logo or an old address, fix the sources first: the website, the company register, Wikidata, the major profiles. Then submit the edit with links to those sources.

Wikidata and Wikipedia sit underneath a great deal of entity understanding. Wikipedia was one of the named sources of the original Knowledge Graph,¹ Wikidata is the knowledge base that research systems link to,³ and schema.org's own definition of sameAs gives a Wikipedia page or a Wikidata entry as the first examples of a page that unambiguously identifies an item.⁹ Both are open, both are editable by anyone, and both have rules that exist to stop exactly the kind of self-promotion businesses are tempted to try.

Wikidata notability

Wikidata is a structured database of items, each with a Q-number identifier and statements such as “instance of: business”, “official website” and “headquarters location”. An item is acceptable if it meets at least one of three criteria: it has a valid sitelink to a page on a Wikimedia project such as Wikipedia; it refers to a clearly identifiable conceptual or material entity that can be described using serious and publicly available references; or it fulfils a structural need, for example to make statements in other items more useful.¹⁰

The second criterion is the one a business without a Wikipedia article relies on, and the key words are “serious and publicly available references”. A company register entry, a regulator's register, coverage in a newspaper or a trade journal can serve. A company's own website on its own is weak evidence. In my view a Wikidata item is worth creating for an organisation that has real independent references, written neutrally, with every statement referenced. It is not worth creating for a business whose only sources are its own pages and directory listings, because items that do not meet the policy can be deleted and the effort is wasted.

Wikipedia notability and conflict of interest

Wikipedia's bar is much higher. A company is presumed notable if it has received significant coverage in multiple reliable secondary sources that are independent of the subject. Press releases and other public relations material do not count, nor does routine coverage of funding rounds, expansions, acquisitions or hiring, nor a passing mention in an article about something else, and only unpaid sources count.¹¹ The guideline for people is similar: significant coverage in multiple published secondary sources that are reliable, intellectually independent of each other and independent of the subject.¹²

Then there are the conflict of interest rules. Editors with a conflict of interest are strongly discouraged from editing affected articles directly and may propose changes on the article's talk page using the edit COI template so others can review them. Paid editors must disclose who is paying them, on whose behalf the edits are made and any other relevant affiliation, a requirement that comes from the Wikimedia Foundation's terms of use.¹³ That rules out the common shortcut of hiring someone to write a company article and post it quietly. If an article about your organisation exists and contains errors, the route is the talk page, with sources.

Very few sites do this. The structured data chapter of HTTP Archive's 2024 Web Almanac, which analysed pages from a crawl of several million websites, found sameAs links to Wikidata on 0.17% of mobile pages and to Wikipedia on 0.13%, against 4.53% to Facebook and 3.67% to Instagram.¹⁴ Most organisations that have a Wikidata item never point to it from their own markup, which is a small, cheap fix.

An assistant answering “who makes the quietest heat pump” or “which solicitors in Leeds handle probate” is doing the same job as the Knowledge Graph in a hurry. It runs searches, fetches a handful of pages, and writes an answer from the facts that appear across them. The AI search guide covers retrieval, crawlers and citations in depth. What matters here is that the answer about your business is assembled from several sources, read at answer time, and the assistant has no way of knowing which of two conflicting addresses is right except by which appears more often and in more trusted places.

What the platforms say about structured data and AI answers

The platforms do not agree, and the disagreement is worth reading closely. Google's guide to its generative AI features is direct: structured data is not required for generative AI search, there is no special schema.org markup to add, and machine-readable files such as llms.txt neither help nor harm because Google Search ignores them.¹⁵ The same guide points local and ecommerce businesses towards Business Profile and Merchant Center feeds as the way to supply accurate business and product information.¹⁵

Microsoft's position leans the other way. In a May 2025 post on the Bing Webmaster Blog, Fabrice Canel and Krishna Madhavan wrote that IndexNow tells search engines that something has changed while structured data tells them what has changed, and that schema.org markup makes it easier to surface content accurately in search results, shopping experiences and AI-driven assistants.¹⁶ Bing's February 2026 post introducing the AI Performance report in Bing Webmaster Tools, which shows citations in AI answers and the grounding queries behind them, also advises aligning text, images and video so they consistently represent the same entities, products or concepts.¹⁷

What independent tests found

Three pieces of independent work point in different directions, and none settles it.

• searchVIU, an SEO software company, published a test in December 2025 using a fictional product page with prices placed in different places: visible HTML, JavaScript-rendered content, JSON-LD, Microdata and RDFa. Across eight scenarios, none of the five systems it tested (ChatGPT, Claude, Perplexity, Gemini and Google AI Mode) returned a price that existed only in JSON-LD. The authors note that markup could still be used at earlier stages such as indexing or training, which their test did not measure.¹⁸
• Mark Williams-Cook ran a smaller test, reported by Search Engine Roundtable in February 2026, with a made-up company whose address appeared only inside invalid JSON-LD. ChatGPT and Perplexity both returned the address. His reading was that the systems pick up whatever text is in the HTML, valid schema or not, so the markup is being read as text and not used in the structured way it was designed for.¹⁹
• Ahrefs, which sells an AI visibility tool, tracked 1,885 pages that added JSON-LD between August 2025 and March 2026 against 4,000 pages that never did, and compared citations for 30 days either side. It found no major uplift on any platform: a 4.6% fall in Google AI Overviews citations relative to controls, and changes of 2.4% in AI Mode and 2.2% in ChatGPT that were statistically indistinguishable from zero. The study only covered pages already cited more than 100 times a month, so it says nothing about whether markup helps an unknown page get discovered.²⁰

The two small tests disagree on whether JSON-LD content reaches the answer at all, and they tested different things (a price on a product page, an address for a company). They agree on something more useful: when an assistant fetches a page live, markup is not a privileged channel. The Ahrefs data suggests that adding markup to pages that are already cited does not move citations much. None of this says markup is useless. Bing says its systems use it, it can feed the index and the knowledge graph, and it still drives rich results. It does say that a fact which exists only in JSON-LD is at risk. Put the facts that matter in visible text, and use the markup to describe them.

If one thing in this guide is worth doing before anything else, it is this. Every record about a business should give the same name, the same address, the same phone number, the same website and broadly the same description. Records drift for ordinary reasons: a move, a rebrand, a new phone system, an old directory listing nobody remembers creating, a founder's LinkedIn page that still says the old company name. Each drift is a small contradiction, and contradictions are what make a system unsure whether two records describe the same thing.

The platforms say this in their own rules. Google Business Profile requires the name to reflect the business's real-world name as used consistently on the storefront, website and stationery and as known to customers, and bans keywords, locations, taglines and phone numbers in the name field.²¹ Apple Business, launched in April 2026, is described by Apple as a way to manage brand name, logo and key details consistently across Apple Maps, Wallet and other apps.²² Bing's advice for appearing in AI answers includes keeping text, images and video consistent about the same entities.¹⁷ For people, the same applies to name, job title, employer and credentials across the author page, LinkedIn and any professional register.

Start from a master record

Write down the canonical version of every fact once, in one document, and copy from it everywhere else. For a UK business the root of the record is usually the legal one: the registered name and number at Companies House for a limited company, or the owner's name plus any trading name for a sole trader. The trading name customers know can differ from the legal name, and both can be described honestly. Schema.org has separate properties for this: legalName is “the official name of the organization, e.g. the registered company name”, and alternateName holds an alias.²³ The exact match domain tutorial works through this record for a new business, from the Companies House name to the Business Profile and the signage.

Some practitioners give the website page that carries this record a name. Jason Barnard of Kalicube calls it the “Entity Home”: in his framework, the single authoritative page that acts as the primary source of truth about an entity, usually the About page.²⁴ It is a practitioner's model, not something Google documents, but it describes a sensible habit: have one page on your own site that states the facts plainly and that every other profile can point back to. Organization markup belongs on the same kind of page: the home page or a single page that describes the organisation, such as an About page.²⁵

Identifiers do the disambiguation that names cannot

Names collide. There are many businesses called something like “Northfield Joinery”, but only one company number, one VAT registration and one Legal Entity Identifier for each. Schema.org defines properties for these: vatID for a value-added tax ID with its national prefix, taxID, leiCode for an LEI as defined in ISO 17442, iso6523Code for an organisation identifier under ISO 6523, plus the general identifier property.²³ The Organization markup documentation for Google Search covers the same set, calls the VAT number an important trust signal for users, and prefers iso6523Code over the separate duns and leiCode properties, using prefixes such as 0060 for DUNS, 0088 for GLN and 0199 for LEI.²⁵ Use the identifiers you have and show them on the page too, typically in the footer or on the About page.

For local businesses the listings side of this is covered in the local SEO guide, and the version aimed at being named by assistants is the stage on making your details the same everywhere in the AI recommendations tutorial.

Structured data is a standard way of describing what a page is about in a form a program can read without guessing. Search engines use it to understand the content of the page and to gather information about the web and the world in general, including people, books and companies.²⁶ The vocabulary almost everyone uses is schema.org, a collaborative project created by Google, Microsoft, Yahoo and Yandex and run since April 2015 through a W3C community group.²⁷ It defines types (Organization, Person, Product, Article) and properties (name, address, sameAs, gtin), arranged in a hierarchy where every type inherits the properties of its parents.

Formats: JSON-LD, Microdata and RDFa

Google Search supports three formats and treats them as equally good if the markup is valid, but recommends JSON-LD as the easiest to implement and maintain at scale and the least prone to user error.²⁶ Bing has supported JSON-LD since 2018 alongside Microdata, RDFa and others, and validates all of them in Bing Webmaster Tools.²⁸ JSON-LD sits in a script element, separate from the visible HTML, which is why it is easier to maintain and also why it is easy to let it drift away from what the page says.

Adoption keeps growing. The 2024 Web Almanac found JSON-LD on 41% of pages, up from 34% in 2022, with RDFa on 66% and Open Graph, the social sharing vocabulary that is often encoded as RDFa, on 64%. Among JSON-LD types, WebSite appeared on 12.73% of mobile pages, Organization on 7.16%, BreadcrumbList on 5.66%, LocalBusiness on 3.97% and Product on 0.77%.¹⁴

The four keywords that matter: @context, @type, @id and @graph

JSON-LD 1.1 is a W3C Recommendation, published on 16 July 2020.²⁹ For SEO purposes you need four of its keywords. @context maps the short terms you write (name, address) to full identifiers, which for schema.org markup is always https://schema.org. @type says what kind of thing a node is. @id gives a node an identifier, and @graph holds several nodes in one block.²⁹ A node without an @id is a blank node, one that cannot be referred to from outside because it has no identifier.²⁹ That is the detail most site markup misses: without @ids, the Organization on the home page, the publisher of each article and the seller on each product page are separate anonymous things that happen to share a name.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://www.example.com/#organization",
  "name": "Northfield Joinery",
  "legalName": "Northfield Joinery Ltd",
  "url": "https://www.example.com/",
  "logo": "https://www.example.com/images/logo.png",
  "sameAs": [
    "https://www.linkedin.com/company/example-northfield-joinery",
    "https://www.wikidata.org/wiki/Q00000000"
  ]
}
</script>

The @id is a URL with a fragment. It does not have to resolve to anything, but the convention of using the canonical URL of the page that describes the entity, plus a fragment such as #organization, keeps identifiers unique and readable. The sameAs URLs above are placeholders. sameAs should point to pages that unambiguously indicate the item's identity, such as its Wikipedia page, Wikidata entry or official website,⁹ and profile pages on social media or review sites can serve the same purpose.²⁵ Do not list pages that merely mention the business, and do not list profiles that belong to a different business with the same name.

Google's general guidelines ask that pages with several structured data items either nest them or link them by @id so the relationships are clear.³⁰ The practical pattern is to define each entity once, give it a stable @id, and refer to it by that @id everywhere else. The organisation is defined fully on the home page or About page. Every article then says its publisher is {"@id": "https://www.example.com/#organization"} instead of repeating the name and logo, and every author is a Person with their own @id on their profile page.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://www.example.com/#organization",
      "name": "Northfield Joinery",
      "legalName": "Northfield Joinery Ltd",
      "url": "https://www.example.com/",
      "logo": "https://www.example.com/images/logo.png",
      "vatID": "GB123456789",
      "founder": { "@id": "https://www.example.com/about/sam-taylor/#person" },
      "sameAs": [
        "https://www.linkedin.com/company/example-northfield-joinery"
      ]
    },
    {
      "@type": "WebSite",
      "@id": "https://www.example.com/#website",
      "url": "https://www.example.com/",
      "name": "Northfield Joinery",
      "publisher": { "@id": "https://www.example.com/#organization" }
    },
    {
      "@type": "Person",
      "@id": "https://www.example.com/about/sam-taylor/#person",
      "name": "Sam Taylor",
      "jobTitle": "Founder and lead joiner",
      "worksFor": { "@id": "https://www.example.com/#organization" },
      "url": "https://www.example.com/about/sam-taylor/"
    }
  ]
}
</script>

All names, numbers and URLs in these examples are placeholders: the VAT number is not a real registration and the business is invented. Replace them with your own values, and only include an identifier you can show on the page.

The WebSite node and your site name

The WebSite node does a specific job in Google: it is the strongest way to state your preferred site name, the name shown above the URL in results. The site name system is automated and also reads og:site_name, the title element, headings and other home page text, but WebSite structured data on the home page is the most important input if you want to state a preference. It must sit at the domain or subdomain root, alternateName can hold a recognised shorter name or acronym, and site names are not supported for subdirectories.³¹ Use the same name in the markup as you use everywhere else, which is the consistency point again.

Rules for a graph that stays correct

• Define each entity in full once, on the page that is about it, and refer to it by @id elsewhere. The organisation lives on the home or About page, each person on their profile page, each product on its product page.
• Keep @ids stable. Changing them on a redesign breaks the links between pages for no gain. If URLs change in a migration, update the @ids with them.
• Use the most specific type that is true:³⁰ a plumber is a Plumber, which is still a LocalBusiness and an Organization.
• Generate markup from the same data the page is built from. Markup typed by hand into a template field drifts from the page within months.
• Put the same markup on every duplicate version of a page, not only the canonical.³⁰

Most business sites need a handful of types. The table sets out what each is for and what it does in Google today. The chapters that follow cover rich result status, people and products in more detail.

Organization and LocalBusiness

Organization markup on the home page can help Google understand an organisation's administrative details and disambiguate it in results, and there are no required properties.²⁵ LocalBusiness requires a name and a physical address, recommends opening hours, phone, geo coordinates and more, and asks for the most specific subtype available, such as Restaurant or DaySpa.³² A single-location business can use one LocalBusiness subtype on the home page as its organisation node. A multi-location business should have one Organization for the brand and a LocalBusiness on each location page, linked with parentOrganization, which schema.org defines as the larger organisation that this one is a subOrganization of.²³

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Dentist",
  "@id": "https://www.example.com/locations/leeds/#location",
  "name": "Example Dental Leeds",
  "url": "https://www.example.com/locations/leeds/",
  "telephone": "+44 113 496 0000",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "12 Example Street",
    "addressLocality": "Leeds",
    "postalCode": "LS1 0AA",
    "addressCountry": "GB"
  },
  "openingHoursSpecification": [
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"],
      "opens": "08:30",
      "closes": "17:30"
    }
  ],
  "parentOrganization": { "@id": "https://www.example.com/#organization" }
}
</script>

Every value here should match the Business Profile for the same location exactly, including the phone number format and the opening hours. If the markup and the profile disagree, you have created the contradiction this guide is trying to remove.

Article

Article markup has no required properties and can help Google show better title text, images and dates for the article.³³ The author guidance is precise and often ignored: put only the author's name in author.name, with no job title or prefix; use Person for people and Organization for organisations; list multiple authors separately; and include a url or sameAs that points to a page about the author, both of which Google can use to understand who the author is.³³

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "How to choose a hardwood for a fitted wardrobe",
  "datePublished": "2026-09-14T09:00:00+01:00",
  "dateModified": "2026-10-02T11:30:00+01:00",
  "image": ["https://www.example.com/images/wardrobe-oak-1x1.jpg"],
  "author": {
    "@type": "Person",
    "@id": "https://www.example.com/about/sam-taylor/#person",
    "name": "Sam Taylor",
    "url": "https://www.example.com/about/sam-taylor/"
  },
  "publisher": { "@id": "https://www.example.com/#organization" }
}
</script>

BreadcrumbList

Breadcrumb markup needs an itemListElement with at least two ListItems, each with a position, a name and the URL of the page it represents (the last item can leave out the URL). Breadcrumbs should represent a typical user path to the page, not a copy of the URL structure, and a page can carry more than one trail.³⁴ Since January 2025 breadcrumbs only appear in desktop results, because they were truncated on smaller screens.³⁷ They remain cheap to add and worth having for desktop and for the clarity they give a site's hierarchy.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    {
      "@type": "ListItem",
      "position": 1,
      "name": "Wardrobes",
      "item": "https://www.example.com/wardrobes/"
    },
    {
      "@type": "ListItem",
      "position": 2,
      "name": "Fitted wardrobes in oak"
    }
  ]
}
</script>

A rich result is a search result with something extra drawn from structured data: stars, a price, a recipe card, an event date, a breadcrumb trail. Markup that meets the requirements makes a page eligible, never guaranteed. Including the required properties is what makes an item eligible for enhanced display,²⁶ and the search gallery itself notes that the actual appearance in results might be different.³⁸ Since 2023 the list of features has been shrinking steadily, and much advice still in circulation describes rich results that no longer exist.

What is still supported

Google's search gallery, last updated in June 2026, lists these features: Article, Breadcrumb, Carousel, Course list, Dataset, Discussion forum, Education Q&A, Employer aggregate rating, Event, Image metadata, Job posting, Local business, Math solver, Movie, Organization, Product, Profile page, Q&A, Recipe, Review snippet, Software app, Speakable, Subscription and paywalled content, Vacation rental and Video.³⁸ Two caveats. Dataset markup is used by Dataset Search, not Google Search.³⁷ And several entries on the list, Organization and Profile page among them, rarely change how a result looks: they feed understanding, logos and panels.

What has gone, and when

• August 2023: FAQ rich results restricted to well-known, authoritative government and health websites, and HowTo limited to desktop. The same announcement said unused structured data does not cause problems for Search and there is no need to remove it proactively.³⁹
• September 2023: HowTo rich results stopped appearing on desktop too, making the feature deprecated, with its Search Console report and Rich Results Test support removed soon after.³⁹
• January 2025: breadcrumbs limited to desktop results.³⁷
• June 2025: Google announced it would phase out Book Actions, Course Info, ClaimReview, Estimated Salary, Learning Video, Special Announcement and Vehicle Listing, because they were not commonly used and no longer added significant value. The announcement said the change would not affect ranking and that use of these types outside Google Search was not affected.⁴⁰ Book Actions was later kept because one feature still uses it.³⁷
• January 2026: documentation for practice problem markup removed, after the type stopped appearing in results.³⁷
• May 2026: FAQ rich results stopped appearing in Google Search from 7 May, and the FAQ documentation was removed the following month.³⁷

FAQ and HowTo markup: keep, remove or ignore?

Neither produces a rich result in Google any more. FAQPage remains a valid schema.org type, defined as a web page presenting one or more frequently asked questions,⁴¹ and unused markup does not cause problems for Search.³⁹ Other systems may still read the content: Bing's 2026 advice on AI answers mentions FAQ sections, though it is talking about visible content and not markup.¹⁷ My view: leave existing FAQPage markup where it accurately describes a visible FAQ, do not add it to pages for search reasons, and do not spend development time on HowTo. The visible questions and answers are what help readers and what assistants can quote.

Rich results versus understanding

The structured data guidelines are short, and most of them reduce to one rule: markup must describe what a visitor can see on the page, accurately. The technical rules are to use a supported format and not block the page from Googlebot with robots.txt, noindex or access controls. The quality rules are where sites get into trouble.³⁰

• Do not mark up content that is not visible to readers of the page.³⁰
• Do not use markup to deceive or mislead users, or to impersonate an organisation.³⁰
• Markup must be relevant to the page: a page of instructions marked up as a recipe breaks the rule.³⁰
• Include every required property for a feature, and use the most specific applicable type.³⁰
• Put the markup on the page it describes, and keep the information current and original.³⁰
• Images referenced in markup must be crawlable and indexable.³⁰

The penalty is specific. A structured data manual action removes a page's eligibility for rich results and does not affect how the page ranks in web search.³⁰ It is triggered by markup of invisible content, irrelevant or misleading content, or other manipulative behaviour; the fix is to correct or remove the offending markup and request a review in the Manual Actions report in Search Console.⁴² Bing's warning is older and vaguer but points the same way: putting spam data in markup can hamper a site's presence in search.²⁸

Reviews about yourself

The most common breach on business sites is star ratings. If the entity being reviewed controls the reviews about itself, its pages with LocalBusiness or any other Organization markup are not eligible for review stars, whether the reviews are on its own site or in an embedded third-party widget. Review content that is marked up must also be readily available to users on the page.⁴³ A plumber can show testimonials on the home page, but should not add AggregateRating markup to its own LocalBusiness node in the hope of stars. Products are different: Product is one of the supported types for review snippets,⁴³ so genuine customer reviews shown on a product page can be marked up.

Fake authors and borrowed credentials

Fabricating creator profiles, for example with AI-generated headshots, made-up names or false credentials to make content look as if experts wrote it, is a form of deception under the guidance on helpful content.⁴⁴ Markup that names such an author compounds the problem: it is structured data used to mislead.

People are entities too, and for many businesses the people are part of the reason to trust them: the solicitor, the consultant, the clinician, the founder. Google's guidance on helpful content asks whether it is self-evident who wrote a piece, whether pages carry a byline where one is expected, and whether bylines lead to more information about the author and the areas they write about, and it strongly encourages accurate authorship information.⁴⁴ That is a description of a person entity: a name, a profile page, and evidence of what they know.

The author page is the person’s home

Give each author or expert a profile page on the site with their full name as they use it elsewhere, their role, a factual account of their experience and qualifications, and links to their other profiles. Mark it up as a ProfilePage whose mainEntity is a Person. The ProfilePage documentation describes the markup as a way to help Google understand creators, lists author pages on news sites, About Me pages and employee pages among the uses, and requires the page's main focus to be a single person or organisation affiliated with the site. mainEntity and name are required; sameAs, identifier, alternateName, description and image are recommended.⁴⁵

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "ProfilePage",
  "dateModified": "2026-10-01T10:00:00+01:00",
  "mainEntity": {
    "@type": "Person",
    "@id": "https://www.example.com/about/sam-taylor/#person",
    "name": "Sam Taylor",
    "jobTitle": "Founder and lead joiner",
    "worksFor": { "@id": "https://www.example.com/#organization" },
    "description": "Time-served joiner who founded Northfield Joinery and still leads every fitted furniture job.",
    "image": "https://www.example.com/images/sam-taylor.jpg",
    "knowsAbout": ["Fitted furniture", "Hardwood joinery"],
    "sameAs": [
      "https://www.linkedin.com/in/example-sam-taylor"
    ]
  }
}
</script>

Schema.org gives a person properties for the facts that establish expertise: jobTitle, worksFor, alumniOf for an organisation they studied at, affiliation, award, and hasCredential for a credential awarded to them. knowsAbout is deliberately weak: it suggests possible expertise without implying it.⁴⁶ Use them only for facts that are stated and checkable on the page. A hasCredential claiming a professional qualification should match a public register if one exists, because anyone, human or machine, can check it.

Linking articles to authors

Every article's author should be the same Person @id as on the profile page, with author.name holding only the name and author.url pointing to the profile.³³ Byline, profile page, markup and LinkedIn should all use the same form of the name. If an author writes for other publications, sameAs links to their author pages there help join the records, provided those pages are clearly the same person.

Knowledge panels and Wikipedia for people

A person can have a knowledge panel and can claim it in the same way as an organisation.⁶ Verified people can suggest corrections with supporting public URLs.⁷ Wikipedia's bar for people is significant coverage in multiple reliable, independent published sources,¹² which most practitioners and business owners will not meet, and writing your own article runs against the conflict of interest guideline.¹³ For most experts the realistic goal is a consistent, well-evidenced profile page and matching professional profiles. A panel may or may not follow.

Products are the entity type where identifiers matter most, because the same product is sold by many retailers under slightly different names. A Global Trade Item Number is what ties those listings together. Under GS1's rules the brand owner, meaning the organisation that owns the product's specification wherever it is made, is normally responsible for allocating the GTIN, using the GS1 Company Prefix it receives on joining a GS1 member organisation, and that prefix is for its sole use. There are exceptions, for example for items made exclusively for one customer.⁴⁷ A retailer reselling branded goods should use the manufacturer's GTIN and never create its own.

Schema.org's gtin property takes an 8, 12, 13 or 14 digit number with a valid GS1 check digit, and generalises the older gtin8, gtin12, gtin13 and gtin14 properties.⁴⁸ The merchant listing documentation asks for all applicable global identifiers, the most specific GTIN that applies, and identifiers given as numbers, not URLs. It also supports mpn and sku.³⁵ On the feed side, Merchant Center recommends submitting the GTIN for every product that has one assigned by the manufacturer, warns that products with missing or incorrect GTINs may have limited visibility, and says not to submit one for products that have none, such as store brands or custom items.⁴⁹

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Product",
  "@id": "https://www.example.com/boots/fellwalker-gtx/#product",
  "name": "Fellwalker GTX walking boot, men's, brown",
  "image": ["https://www.example.com/images/fellwalker-gtx-brown.jpg"],
  "brand": { "@type": "Brand", "name": "Example Outdoor" },
  "gtin": "5012345678900",
  "mpn": "FW-GTX-BRN",
  "sku": "FWGTX-BRN-09",
  "offers": {
    "@type": "Offer",
    "url": "https://www.example.com/boots/fellwalker-gtx/",
    "price": "149.00",
    "priceCurrency": "GBP",
    "availability": "https://schema.org/InStock",
    "itemCondition": "https://schema.org/NewCondition",
    "seller": { "@id": "https://www.example.com/#organization" }
  }
}
</script>

The product, brand and codes above are invented, and the GTIN is an example number with a valid check digit. Use your own GTINs, or leave the property out if a product has none.

Product snippets, merchant listings and feeds

Google distinguishes two kinds of product result. Product snippets suit pages where people cannot buy directly, such as reviews. Merchant listings are for pages where customers can buy, and support details such as sizing, shipping and returns. Providing both structured data on the page and a Merchant Center feed maximises eligibility and help Google understand and verify the data, and some experiences combine the two.³⁶ Product variants (sizes, colours) need their own decisions about URLs, canonicals and ProductGroup markup, which I cover in the post on product variants, canonicals and Merchant Center.

Feeds for assistants

Shopping in assistants increasingly runs on feeds. OpenAI's product feed specification for ChatGPT requires a stable ID that is unique per item or variant and never reused, and a brand as shown on the product page. It treats GTIN as optional but, when given, it must be one assigned GTIN of 8, 12, 13 or 14 digits with a valid check digit, and an MPN should be submitted with the brand and never invented.⁵⁰ On Bing, the case for structured product data is made alongside IndexNow: notify the engine when a price or stock level changes, and let the markup say what changed.¹⁶ The fields that carry the weight, and how to make feed, markup and page agree, are in the post on product data for AI shopping.

There are two different questions to ask of markup, and they need different tools. Is it valid schema.org? And is it eligible for a specific Google feature? Google split the old Structured Data Testing Tool along exactly that line in 2020 and 2021. The Schema Markup Validator, now hosted by schema.org at validator.schema.org, checks syntax and compliance with schema.org for any type. The Rich Results Test checks eligibility for Google's rich result types, and Search Console reports on them across a site.⁵¹ Bing added JSON-LD to the Markup Validator in Bing Webmaster Tools in 2018;²⁸ Bing has not documented it recently, so check it is still offered in your account.

Check the rendered page, not the template

Markup that a plugin or tag manager injects with JavaScript exists only after rendering, so test the rendered page and also look at the raw HTML the server returns. Systems that fetch pages without running JavaScript will not see injected markup. In searchVIU's test, Gemini was the only one of the systems it tried that rendered JavaScript during a live fetch,¹⁸ which is one more reason to put structured data in the server-rendered HTML. The AI search guide covers which crawlers render JavaScript.

Checking that the entity work as a whole is having an effect is slower and less precise. Watch the knowledge panel and the result for a search on the business name, the site name shown in results, the logo, and the rich result counts in Search Console. For assistants, ask the same questions about the business every month and record whether the facts they give are right, which the tutorial on getting recommended by AI assistants sets out as a monthly routine. If you use an AI coding agent on the site, the structured data skill in this site's free skill pack adds JSON-LD for the entities a page is really about, checks it against the visible page and validates it on the rendered output.

Entity work used to be a niche corner of technical SEO: knowledge panels for famous brands, star ratings for shops. It now sits underneath almost every way a business is found. The map pack depends on a Business Profile whose facts match the website. Product results depend on GTINs and feeds that match the page. Knowledge panels depend on consistent facts across independent sources. And assistants that write answers about a business retrieve the same website, profiles, directories and press, and do their own reconciliation in seconds.

The common thread is that systems reward agreement between independent records. Structured data is one way to state your side of the record precisely, and it still earns rich results for a shrinking set of features. It cannot make an unknown entity known, and it cannot outvote ten other sources that say something different. Google says no special markup is needed for its AI features,¹⁵ Bing says markup helps its systems understand what changed,¹⁶ and the independent tests so far show that facts living only in JSON-LD are at risk.¹⁸ Those positions are compatible if you do the work in the right order.

Done in that order, the same work serves the classic results page, the map pack, the shopping results and the assistants. Done in reverse, with elaborate markup on a site whose listings disagree, it mostly produces valid JSON-LD that describes a business nobody's records can confirm.