Start with relationships, not markup volume
Structured data is useful when it expresses relationships already established on the page: an organization has a founder, offers a service, publishes an article and uses a preferred website identity. Adding more types does not compensate for missing or contradictory visible information.
A small service-business graph
Organization → founder → Person
Organization → makesOffer / provider → Service
Article → author → Person
WebSite → publisher → Organization
Choose the page's main entity
The home page normally anchors the organization and website. A service page should describe a real service available from that provider. An article should identify its headline, author, publication dates and publisher. A profile page can connect a real person to credentials and areas of work that are also visible.
Values that require restraint
| Property | Safe rule | Common failure |
|---|---|---|
| name / alternateName | Use the public names consistently used on the site. | Adding keyword-rich aliases nobody uses. |
| sameAs | Link profiles that represent the same entity. | Linking clients, partners or unrelated directories. |
| areaServed | Reflect a real service boundary. | Listing every country to imply global presence. |
| review / rating | Use only eligible, visible and genuine review information. | Inventing an aggregate or marking up third-party ratings incorrectly. |
| founder / employee | Name real people whose relationship is public. | Creating people or credentials only inside JSON-LD. |
Implementation order
- Write the visible identity and service facts first.
- Assign stable
@idvalues to the organization, website and public people. - Reference those identifiers instead of creating duplicate disconnected objects.
- Add only properties the team can maintain.
- Validate syntax with Schema Markup Validator and feature eligibility with Google's Rich Results Test.
- Compare the rendered page and markup after every template change.
Schema is not a private fact channel
Do not hide legal names, service claims, prices, reviews or FAQs only in markup. Google states that structured data should describe the page and should not refer to content hidden from users. A smaller graph that matches the page is more trustworthy than a large graph full of unsupported values.
Maintenance test
Quarterly, crawl the site's JSON-LD and compare organization names, URLs, dates and profile links. Re-test representative templates after redesigns. Record warnings separately from errors: not every optional recommendation justifies a site change.
An approval checklist for entity changes
Before publishing a new organization, person or service value, identify its visible source, factual owner and update path. Confirm that the canonical page uses the same name, that the relationship is current and that no existing node creates a contradiction. Legal names, addresses, credentials and commercial availability should be reviewed by the person responsible for those facts—not inferred from an old directory or inserted only because a property exists in Schema.org.
Primary references
Where to go next
Use the Nexus AI Visibility Framework to place this topic inside a complete measurement system, or review the AI Visibility Audit scope.
13 Jul 2026 — Expanded with an independent structure, examples, implementation guidance and primary references.