What Google documents first
DOCUMENTED Before any markup advice, the platform position. Google’s documentation for AI Overviews and AI Mode says there is “no special schema.org structured data that you need to add” to appear in AI features, and that site owners “don’t need to create new machine readable files, AI text files, or markup”. What it does say is: “Making sure your structured data matches the visible text on the page”, and, in its May 2025 guidance, “be sure to follow our guidelines, such as making sure that all the content in your markup is also visible on your web page and that you validate the structured data markup.”
INFERRED So the job of entity markup is not to switch on a feature. It is to restate, in a machine-readable form, facts the page already states visibly, so that an organisation, its people and its services are unambiguous to anything parsing the page. The value is removed ambiguity, and no number can honestly be attached to it.
Which schema types carry entity meaning
Four elements do the work; most other types are result decoration.
- Organization. The business itself:
name,legalName,url,logo,address,foundingDate, contact details,areaServed. The primary node. - Person. The people:
name,jobTitle,worksFor, credentials where they are real,sameAslinks to professional profiles. - Service. What the business provides:
name,description,provider,areaServed,serviceType. - sameAs. The property that points from an entity to its other authoritative representations, so several records can be confirmed as one thing.
Structuring JSON-LD for a service business
Give the organisation one stable @id and reference it from everywhere else rather than repeating it.
{
"@context": "https://schema.org",
"@graph": [
{
"@type": "ProfessionalService",
"@id": "https://example.com.au/#organization",
"name": "Example Advisory",
"legalName": "Example Advisory Group Pty Ltd",
"url": "https://example.com.au/",
"email": "[email protected]",
"foundingDate": "2019",
"address": {
"@type": "PostalAddress",
"addressLocality": "Perth",
"addressRegion": "WA",
"addressCountry": "AU"
},
"areaServed": ["Perth", "Western Australia"],
"sameAs": [
"https://www.linkedin.com/company/example-advisory",
"https://abr.business.gov.au/ABN/View?abn=00000000000"
],
"founder": { "@id": "https://example.com.au/about/#jane-doe" }
},
{
"@type": "Person",
"@id": "https://example.com.au/about/#jane-doe",
"name": "Jane Doe",
"jobTitle": "Founder and Principal Adviser",
"worksFor": { "@id": "https://example.com.au/#organization" },
"sameAs": ["https://www.linkedin.com/in/jane-doe-example"]
},
{
"@type": "Service",
"@id": "https://example.com.au/advisory/#service",
"name": "Strategic Advisory",
"provider": { "@id": "https://example.com.au/#organization" },
"areaServed": ["Perth", "Western Australia"]
}
]
}
Three things make this work. The @graph array holds related nodes in one block. Each node has a stable @id built from a real URL plus a fragment. References use { "@id": "..." } rather than repeating the object, so there is one authoritative definition of each entity. Australian sites copying overseas templates should check currency (AUD, not USD) and time zone in any hours or price markup.
The five errors that break entity markup
- Orphaned nodes. A Person with no
worksFor, a Service with noprovider. The node exists and connects to nothing. - Missing or unstable
@id. Repeating the full organisation object on every page, or changing the identifier between pages, forces a parser to guess whether these are the same organisation. - Mismatched names. Schema says “Example Advisory Group Pty Ltd”, the heading says “Example Advisory”, the footer says “Example”. Pick one for
name, put the registered form inlegalName, stop there. - Invalid
sameAstargets. Profiles that 404, redirect elsewhere, or belong to a similarly named business. A brokensameAsasserts a false equivalence, which is worse than none. - Markup that contradicts the page. An address the page does not show, a service the page does not mention, a credential stated nowhere visible. DOCUMENTED This is the error Google’s guidance addresses directly, and the most damaging, because it introduces a conflict where there was only an absence.
Where to put it, and platform realities
Place the graph in one server-rendered JSON-LD block in the document head, so a fetcher that does not execute JavaScript still receives it. Platforms vary:
- WordPress. SEO plugins emit their own graph. A second hand-written block creates two competing definitions of the same entity. Configure the plugin’s entity settings first and replace its output only if it cannot express the relationships needed.
- Shopify. Themes inject partial markup, often with the store title where the legal entity name belongs. Read the rendered source before assuming nothing is there, and re-check after theme updates.
- Client-rendered sites. Markup injected after hydration is invisible to a non-rendering fetcher, which removes the benefit for the surfaces this work targets.
The check is the same everywhere: view the raw source and confirm the block is in the delivered document.
Person schema and expertise
A named Person node with a jobTitle, a worksFor reference, sameAs links to a professional profile and, where real, hasCredential entries gives a system something to attach expertise to. Two rules: assert only credentials that exist and can be checked, and make sure the person is named and described on the page the node points at. A Person node referencing a URL with no visible bio contradicts the page.
Validating, and what validation does not tell you
Google’s Rich Results Test and the Schema Markup Validator check syntax and eligibility. Neither checks truth. Valid markup describing the wrong entity, referencing a dead profile or asserting a service no longer offered passes every automated test. The manual checks that matter: fetch the raw page and confirm the JSON-LD is present in what a crawler receives; open every sameAs target; and read the schema against the visible text asking whether someone reading only the markup would form an accurate impression of the business.
What is documented and what is inferred
- Documented: Google’s statements that no special markup is needed for AI features and that markup must match visible content; the schema.org types and properties.
- Inferred: that removing ambiguity in markup helps parsing; the platform-specific traps.
- Not established: any measured effect of entity markup on AI citation. This publication does not assert one, and the SOP it follows forbids asserting that structured data causes citation.