Entity SEO learning
Resolve conflicting entity types
Entity type conflict resolution checks if competing descriptions identify the same thing, compatible views of that thing, or separate related entities. Compare identifiers, source claims, attributes, relationships, dates and scope before changing a record. More than one type can be valid. The aim is to preserve supported meaning, then carry that meaning into page text, links and schema.
Compare the three outcomes
Choose the supported outcome
One entity with different types, or separate records?
Compare the identifiers and subjects named by the sources. A shared name does not prove a shared identity. Choose the outcome that fits the evidence.
Keep compatible types
Keep each type when its definition, attributes and scope fit. A broad type and a supported subtype can coexist.
Split related entities
Give the company, brand or product separate identifiers. Connect them through sourced relationships with the correct direction.
Hold the unresolved claim
Retain the competing sources and dates. Name the missing evidence and delay the disputed type and dependent schema.

Fictional illustration
A company, a brand and a product
Cedar Works Ltd makes desk lamps under the Cedar brand. One lamp is sold as Cedar Arc. A merged record labelled Cedar contains a company registration number, a brand logo, a model number and a power rating. Those properties describe three related entities, rather than three interchangeable types for one entity.
Keep the registration number on Cedar Works Ltd, the brand identity on Cedar, and the model number and power rating on Cedar Arc. Record that the company manufactures the product and that the product carries the brand, using evidence for each relationship. A product does not manufacture its company; reversing that statement changes the meaning.
The company can still have compatible broad and specific organization types if the definitions and evidence support them. Splitting the brand and product does not require stripping valid types from the company.
Four checks before changing a type
- IdentityCompare stable IDs, canonical URLs, names and aliases. Check the subject identified by each source. A matching label is a clue, not proof that a company, brand and product are one entity.
- Source and dateRetain the source URL, its exact claim, the observation date and any stated effective date. Distinguish an old classification from a current one. A changed company name alone does not establish a new entity.
- Scope and attributesCompare market, version, location and period. Check attributes against the proposed type: a product model number and a company registration number identify different kinds of things. Keep genuine uncertainty visible.
- Relationships and lifecycleCheck who owns, makes, supplies or replaces what. Compare formation, launch, retirement and replacement events. Different lifecycles can reveal separate entities hidden behind a shared label.


Carry the decision into the website
- Write the resolved identityState the entity, its supported types and the reason for keeping, splitting or holding the claims. Preserve the source and scope so another reader can trace the decision.
- Correct connected recordsUpdate labels, aliases, attributes and relationships that depend on the disputed identity. Keep separate identifiers for separate entities. Check references that previously pointed to the merged record.
- Make pages and links consistentMake visible descriptions distinguish the entities and explain their relationship. Review internal links and external identity links against that distinction. A related company profile is not automatically an identity match for its product.
- Add schema after identity is settledChoose schema types and properties that express the resolved model and visible content. Check relationship direction again. Revisit the decision when a source, ownership relationship, product version or other relevant condition changes.
Related reading
Continue with a specific question
Entity Identity Evidence Register
Record the identifiers and sources supporting an identity claim.
sameAs Candidate Review
Check an external URL before treating it as the same entity.
Relationship Direction Audit
Check the subject, relationship and object of a statement.
Entity Predicate Library
Choose relationship wording with explicit direction and type constraints.
References: RDF 1.1 Concepts · Entity Identity Evidence Register.
These modeling methods do not verify unsupported facts or promise search visibility.
