Entity Clarity and Structured Data for AEO

Start with the fact system

Before writing JSON-LD, list the public facts a person or organization needs to keep consistent: canonical name, alternate name, current role, organization, role dates, location, credentials, contact identity, verified profiles, services, and representative work.

For each fact, store the supporting URL, owner, verification date, allowed wording, and prohibited extrapolation. Resolve conflicts in visible pages first. Markup cannot repair contradictory biographies.

Use stable identifiers

A small graph can reuse identifiers such as:

https://example.com/#person
https://example.com/#organization
https://example.com/#website
https://example.com/article/#webpage
https://example.com/article/#article

The webpage can reference the person as its subject, the article can reference the person as author, and the site can reference the person or organization as publisher. Reusing the identifier is clearer than emitting disconnected copies with slightly different properties.

Match the visible page

If JSON-LD says a person holds a credential, names an employer, offers a service, charges a price, or serves a location, a visitor should be able to find and verify that claim on the page or a clearly linked source. Do not mark up reviews, awards, offices, or outcomes merely because they might look persuasive to a machine.

Google’s structured-data policies describe feature eligibility, not guaranteed display or rank. Misleading markup can remove eligibility or create a manual-action risk.

Connect, then corroborate

sameAs can connect a person to a verified LinkedIn profile, GitHub account, scholarly profile, or company biography. That connection helps disambiguate the entity. It does not turn every statement on those profiles into an independently verified fact.

Stronger corroboration comes from public records and third parties with their own accountability: a university dissertation record, peer-reviewed article, client-domain case, reputable interview, conference program, or documented open-source contribution.

Choose types that match the page

Page	Useful vocabulary	Boundary
Biography	ProfilePage, Person	Credentials and roles must be visible and current
Article	Article, WebPage, Person author	Dates and author URL must match the page
Case study	Article, named subject, evidence links	Markup does not establish causal validity
Consulting page	Service, Organization, Offer when exact	Area served is not proof of a local office
Navigation	BreadcrumbList	Reflect the visible human hierarchy
Dataset	Dataset when a real data release exists	Do not mark up a prose summary as downloadable data

Use the most specific accurate type; do not build a vocabulary museum.

Validate three ways

1. Parse the JSON as code and resolve every referenced identifier.
2. Compare each material property with visible text and the fact register.
3. Use relevant platform validators for syntax and eligibility, recognizing that a passing result is not a ranking forecast.

Repeat these checks in the production build. Schema generated from typed editorial data is easier to keep consistent than markup copied manually into every page.