Keep Entity Identity Consistent Across the Proof Layer

Identity work should connect a person, organization, product, and publication through accurate visible copy and structured references—not manufacture relationships.

Use one canonical identity source and describe every relationship in the same way across visible copy, links, and structured data. This page treats that goal as a documentation and implementation problem: identify the exact product or content behavior, collect route-specific evidence, make the narrowest justified change, and preserve the conditions that limit the conclusion.

The term “entity identity” can invite claims that exceed what a robots rule, content pattern, schema block, or audit record proves. The workflow below keeps access, discovery, interpretation, source quality, eligibility, selection, citation, ranking, and traffic as distinct states.

Readers should be able to use the guidance without accepting a hidden score or vendor label. Each recommendation therefore names the evidence to inspect, the owner to change, the deployment state to validate, and the outcome that remains unmeasured.

Start the entity identity review at the canonical production URL and record the date, response status, effective directives, visible content, and relevant source version. When logs or provider rows are used, retain the attribution method and sampling limits.

A screenshot or search result can motivate investigation but cannot replace page and protocol evidence. Collect the underlying HTML, headers, robots file, structured data, links, or source records required for the specific question.

Inventory names, URLs, authors, publishers, logos, and sameAs references. Store the result beside the URL and expected state so another reviewer can reproduce the conclusion without relying on the original operator's memory.

Compare visible ownership claims with JSON-LD and external canonical profiles. Store the result beside the URL and expected state so another reviewer can reproduce the conclusion without relying on the original operator's memory.

Flag obsolete profiles, self-referential sameAs entries, and unsupported affiliations. Store the result beside the URL and expected state so another reviewer can reproduce the conclusion without relying on the original operator's memory.

• Inventory names, URLs, authors, publishers, logos, and sameAs references.
• Compare visible ownership claims with JSON-LD and external canonical profiles.
• Flag obsolete profiles, self-referential sameAs entries, and unsupported affiliations.

Resolve entity identity at the layer that owns the behavior. Content belongs with the page record, crawler policy with the deployed robots configuration, identity with canonical visible profiles, and structured data with the component that renders the corresponding facts.

Write the intended state before editing. That simple contract prevents an optimization request from silently overriding privacy, licensing, access, evidence, or product requirements and gives the validation pass an explicit target.

Choose the authoritative profile and use stable identifiers for its entity nodes. Keep the patch narrow, note the affected routes, and avoid unrelated metadata or navigation changes that make the result harder to attribute.

Link project and article pages back to that identity without replacing page-specific subjects. Keep the patch narrow, note the affected routes, and avoid unrelated metadata or navigation changes that make the result harder to attribute.

Remove relationships that cannot be supported by visible content or primary profiles. Keep the patch narrow, note the affected routes, and avoid unrelated metadata or navigation changes that make the result harder to attribute.

• Choose the authoritative profile and use stable identifiers for its entity nodes.
• Link project and article pages back to that identity without replacing page-specific subjects.
• Remove relationships that cannot be supported by visible content or primary profiles.

{ "@type": "Person", "@id": "https://example.com/about#person", "name": "Name", "url": "https://example.com/about" }

Validate entity identity against the deployed canonical route, not only a local component or text fragment. Repeat the original collection method, exercise important variants, and preserve both successful and failed checks.

A technical pass means the intended content, directive, link, identifier, or markup is available under the named conditions. Discovery, selection, citation, ranking, and traffic require separate evidence collected after systems have had time to crawl and process the change.

Resolve every identifier and external reference. Record the observed value, timestamp, and any measurement gap rather than reducing the result to an unlabeled green check.

Compare Person, Organization, WebSite, WebPage, and Article relationships as one graph. Record the observed value, timestamp, and any measurement gap rather than reducing the result to an unlabeled green check.

Confirm that structured data remains a faithful description of the visible page. Record the observed value, timestamp, and any measurement gap rather than reducing the result to an unlabeled green check.

• Resolve every identifier and external reference.
• Compare Person, Organization, WebSite, WebPage, and Article relationships as one graph.
• Confirm that structured data remains a faithful description of the visible page.

Context can make an apparently restrictive, incomplete, or unusual entity identity state intentional. Review the page purpose, audience, policy owner, and evidence freshness before treating it as a defect.

Minor naming variations are not always separate entities. Preserve that possibility in the audit record until route-level evidence resolves it.

Structured references cannot establish ownership that the visible site and external profiles do not support. Preserve that possibility in the audit record until route-level evidence resolves it.

Claim boundary: Consistent identity reduces ambiguity for readers and machines; it does not guarantee a knowledge panel, entity merge, ranking, or answer attribution.

This boundary is part of the implementation contract. It must remain visible near the recommendation and in any downstream summary so a machine-readable extract cannot turn technical eligibility into an outcome promise.

This guide was reviewed on 2026-07-20 against the primary references linked below. Product roles and documentation can change, so crawler strings, directives, feature status, and policy language should be refreshed before acting on a later release.

The source list supports the factual product or protocol description. Atlas workflow language supplies the evidence boundary; it does not claim private provider access, client outcomes, rankings, citations, or traffic.

1. General Structured Data GuidelinesGoogle Search Central / checked 2026-06-18

   Official Google structured-data policy and eligibility guidance.

2. Schema.org DocumentationSchema.org / checked 2026-06-18

   Official Schema.org vocabulary documentation for type and property vocabulary context.