Entity SEO learning
Choose sameAs URLs that identify the same entity
A sameAs candidate needs evidence that the destination identifies the same entity as your accepted record. A relevant article, similar name or related organization is not enough.
Use the review before adding identity URLs to an entity record or structured data. Preserve related sources as evidence even when they do not qualify as identity links.
Read the candidate review
Establish the entity before assessing its URLs
Start with a resolved identity record: a stable internal ID, preferred name, entity type and lifecycle state. Keep a person separate from their company, its brand, its product family and each product version. A shared name or close relationship does not make those records interchangeable.
Then inspect the candidate destination itself. A URL that describes the entity is different from a URL whose main purpose is to identify it. Check the page title, named subject, identifiers, ownership and scope together. A search result snippet or a matching domain name alone does not establish that match.
A registry entry, professional profile or official identity page can be a candidate. An interview, news report or general article can supply evidence about the person while remaining a poor identity destination. Keep those evidence links available without adding them automatically to sameAs.
One founder with different candidate destinations
This hypothetical example concerns a founder with an accepted Person record, P1. The company record is O1 and its product record is R1. These labels and candidate descriptions are invented teaching data; no destination has been checked here. The decisions show what the stated evidence would justify.
| Candidate and evidence | Decision for P1 | Reason and next action |
|---|---|---|
| Official founder profile. The page identifies P1, names O1 as the company and agrees with the accepted identity record. | Accept, after confirming the destination and current evidence. | The page identifies the person. Store the exact URL, identity evidence and observation date with the decision. |
| Professional profile. The name matches P1, but employment dates and another distinguishing identifier are unresolved. | Hold. | A plausible name match is incomplete evidence. Resolve the conflict before adding this URL. |
| Interview about the founder. It discusses P1 but functions as an article about their work. | Reject as an identity URL; retain as supporting evidence. | Being about the person is insufficient for this identity use. The article can still support a specific sourced claim. |
| Company profile. The page clearly identifies O1 and mentions P1 as its founder. | Reject for P1. | The destination identifies the organization. Review it separately against O1 rather than moving its identity to the founder. |
| Former profile URL. Its replacement is confirmed to identify P1; the old route no longer serves the accepted identity page. | Replace after reviewing the new URL. | Keep the former URL and reason in the decision history. A redirect or new address needs an identity check, not an automatic carryover. |
The accepted example is conditional on evidence confirming its description. None of these invented candidates is a verified recommendation. Rejecting an identity use does not mean the source is false or useless; it means the URL does not fit this particular relationship.
Keep the evidence beside the decision
- Accepted entity and candidate URL Record the internal identity ID, type, preferred name and lifecycle state, followed by the exact destination under review. Avoid a bare display name that could refer to different people or organizations.
- Identity match Explain which identifiers, ownership details and contextual facts establish the same subject. Record contradictory details too. Do not turn a shared employer, brand or topic into proof of identity.
- Evidence and scope Keep the source URL, observation date, applicable market or version and unresolved uncertainty. Check that the evidence covers the entity now being represented rather than a related family, predecessor or subsidiary.
- Decision and maintenance Choose accept, reject, hold or replace and give the reason. Add the next review date and the event that should reopen the decision, such as a rename, acquisition, closure or changed destination.
- Owner and review state Name the person responsible for the decision, any unresolved dependency and the next action. An internal approval label without evidence cannot make an ambiguous destination acceptable.
One decision record can contain observations from different sources. Keep their roles clear: the candidate is the URL proposed for identity use; supporting sources are evidence used to assess that proposal. They need not be the same URL.
Review, publish and revisit the identity link
- Resolve missing identity details first. If the internal record is ambiguous, return to identity research. Adding more sameAs candidates cannot repair a person and organization merged into one record.
- Read the complete candidate page. Confirm its subject, type and scope. Compare distinguishing evidence rather than accepting a familiar name, account label or related domain.
- Choose a reasoned decision. Accept only when the evidence supports the same entity. Hold incomplete or conflicting cases. Reject a related destination that identifies something else. Review a replacement as a new candidate.
- Check the visible description and emitted data. Keep the identity expressed in visible copy and structured data consistent. A supported relationship in prose does not automatically justify sameAs. Do not emit links whose identity evidence remains unresolved.
- Retain the reviewed record. Store the exact accepted URL, supporting evidence, reviewer, observation and review dates, scope and unresolved items. Keep rejected candidates with their rationale so the same mistake is not repeatedly proposed.
Reopen identity decisions when the subject or destination changes
A rename can preserve identity while changing its preferred label. An acquisition can change ownership without turning the acquired organization into its parent. A closure can leave a historical identity record useful while making a current operating description inaccurate. Recheck the exact claim instead of applying one automatic remove or retain rule to every lifecycle event.
When a destination changes, inspect the new subject and scope. A redirect to a company homepage is not evidence that the original person profile remains an appropriate identity link. Hold or remove an unsupported emitted link while the identity question is unresolved; retain its history and supporting sources.
After a correction, review dependent entity records, visible descriptions and structured data that used the former URL. Repair the affected assertions and recheck their meaning. Keep unrelated links intact. The responsible owner should record the next review date and any event that requires an earlier check.
Questions about sameAs candidate decisions
Can every URL that mentions the entity be added?
No. A mention, interview or topical article can support a claim without serving as an identity destination. The candidate must identify the same resolved subject.
Does an official company domain prove a founder match?
No. Read the destination. A company page identifies the company unless its content clearly functions as the founder’s identity page; the domain alone cannot settle the subject.
What happens when two profiles conflict?
Keep the conflict visible and hold the candidate. Compare identifiers, dates, scope and ownership, then seek evidence that resolves the disputed identity. Do not choose the more convenient page by name alone.
What does an accepted record establish?
It records a justified identity URL decision within its documented scope and review period. It does not guarantee indexing, rankings, traffic, rich results or external platform behavior.
Related decisions and source reading
Entity Identity Evidence Register
Resolve identifiers, source conflicts and the accepted subject before assessing identity URLs.
Entity Evidence Hierarchy
Compare source authority, directness, age and fit for the particular identity claim.
Entity Type Conflict Resolution
Investigate incompatible classifications before attaching more URLs to one record.
Entity Predicate Library
Choose a different supported relationship when the destination is related but does not identify the same entity.
RDF 1.1 Concepts
Read the subject, predicate and object model. This reference does not verify a candidate URL or certify the use of sameAs.
Entity SEO library
Continue into related identity, attribute and relationship decisions.
This is an editorial method for identity URL review. The linked identity and predicate articles are first party methods; RDF 1.1 Concepts supplies general graph context. A specific vocabulary or consuming system can impose its own semantics. Check that vocabulary before emitting data; no current standards compliance or search outcome is asserted here.