Free Semantic SEO learning
Keep entity identity consistent across pages and updates
A person or organization can appear on different pages without becoming distinct entities. Maintain accountable facts, then describe the relationship relevant to each page.
Created by Kevin Maguire.
Separate the entity from the page.
An about page, an author biography and an article are different documents. They may all describe the same person. Give each document a clear purpose, and keep the person’s identity separate from the URL of a particular document. A page migration should not silently create a different person in your records.
The Schema.org data model organizes types and properties for describing things. It does not determine which of your conflicting biographies is correct. Resolve the underlying fact before encoding it. A repeated identifier connects descriptions; it is not independent evidence that those descriptions are accurate.
The entity analysis overview introduces the subjects and relationships being described. This page deals with maintaining those facts across documents; it does not make the biography URL the person’s identity.
Assign an accountable source for each fact.
Keep a small identity record with the preferred name, approved alternatives, current role, organization relationship, source, responsible owner and review date. Record uncertainty instead of filling a gap from an old snippet. Distinguish a legal name from a trading name and a former role from a current appointment.
Reuse stable facts from that record. Write local context for the stated page: an article may need the author’s relevant experience, while a contact page needs the organization’s contact route. Consistency means compatible facts, not identical paragraphs everywhere. Avoid inserting the same promotional biography into unrelated content.
Add an effective period and unresolved status to the fact record. Check names and aliases when labels change, and resolve conflicting facts before distributing a proposed answer. One record can own a fact without prescribing one identical promotional paragraph for every page.
Write compatible facts for each page purpose
A short article author box can identify Alex and the experience relevant to that article. A biography can give a fuller account of roles and dates. A service page needs to explain the organization’s present delivery arrangements. Those descriptions can differ in wording while agreeing on the same facts.
Check the claim a reader could draw from each local passage. “Alex founded the agency” does not also say that Alex personally delivers every current service. Do not turn a stable founder relationship into an unsupported current staffing promise.
Worked example: a founder changes operating role.
This is a hypothetical editorial example, not a claim about a named founder. Alex founded a specialist agency and previously managed every project. Alex now oversees subject analysis, while a separate team handles delivery. The historical founder relationship remains; the current delivery claim needs revision.
First confirm the new role with an accountable person and record its effective date. Update the central biography, team page, relevant service descriptions and any current author boxes. Preserve accurate dated case histories instead of rewriting the past as if the new role always applied.
Inspect templates as well as page bodies. A shared author component can repeat the old claim on many articles. Review visible text and published structured data together, then check the public output. A successful edit to one biography does not prove every dependent page changed.
Fictional role change: preserve the past, revise the present
F1: founder relationship
- Subject
- Alex, the fictional person in this exercise.
- Fact
- Founded the fictional agency.
- Effective period
- Historical relationship retained unless its evidence is corrected.
- Current action
- Keep the accurate founder description.
F2: operating responsibility
- Previous role
- Managed every project in the earlier period.
- Current role
- Oversees subject analysis; a separate team handles delivery.
- Effective period
- From the confirmed change date, which a real record must supply.
- Current action
- Update current delivery descriptions and retain accurate dated project histories.
Use identifiers with a clear meaning.
An identifier chosen for the person should continue to denote that person. An identifier for a web page should denote that document. Reuse a stable identity reference where the same entity is described, and keep separate entities separate even when their names match.
Do not use an unrelated external profile as a shortcut for identity. Confirm that a reference belongs to the same person or organization. Distinct branches, products and legal organizations may need their own records rather than one convenient global identity.
Illustrative references with different meanings
Identity reference
- Local reference
- P1 denotes the fictional person Alex.
- Persistence
- The reference continues to denote Alex when a document moves.
Document references
- BIO1
- The current biography document about P1.
- ARTICLE1
- A separate article authored by P1.
- SERVICE1
- A service document describing the organization’s current delivery arrangements.
- Boundary
- These teaching references illustrate meaning; they are not prescribed URL or fragment syntax.
The stable ID and page node method covers the markup decisions. An external profile is another reference to check, not automatic identity evidence.
Inspect shared components as well as page bodies
A stale author component can repeat the old operating role even after the biography has changed. Check shared author boxes, team cards, service summaries, cached public output and all active structured data sources. A saved change in an editor does not establish what visitors now encounter.
Fictional placement register
BIO1: biography
- Fact owner
- Assigned biography editor.
- Source
- Confirmed role change with effective date.
- Local change
- Describe the current subject analysis role; retain the founder relationship.
- Public check
- Pending until the published biography is inspected.
ARTICLE1: shared author box
- Fact owner
- Owner of the shared author component.
- Source
- The same confirmed fact record.
- Local change
- Retire a current claim that Alex manages every project.
- Public check
- Inspect the articles using the component, including any local exception.
SERVICE1: service description
- Fact owner
- Assigned service editor.
- Source
- Confirmed current delivery responsibilities.
- Local change
- Describe the separate delivery team only within the verified scope.
- Public check
- Check visible copy and corresponding emitted data.
HISTORY1: dated project account
- Fact owner
- History editor.
- Source
- Evidence for the earlier project period.
- Local change
- Retain accurate earlier project management wording with its date.
- Public check
- Ensure the historical context remains visible.
Review the change where readers encounter it.
Create a change list containing the affected fact, all known placements, responsible editor and verification result. Search rendered text, author components and metadata for the retired wording. Check pages with local exceptions separately; a global replacement can damage a historically accurate statement.
Google’s structured data guidelines require relevant markup that represents visible content. Correct syntax does not settle factual conflicts or guarantee a search feature.
Return to the entity analysis hub for identifying subjects and relationships, or the structured data hub for markup boundaries. The learning overview connects the wider process.
A page can emit data through a plugin, a theme component or another active publisher. Inventory those output owners before changing the data. The schema output ownership explanation covers competing descriptions; do not insert another emitter merely to hide a conflict.
Identity change record
Copy these fields into your own notes or spreadsheet. This is a static worksheet.
Fields for checking an identity update
Identity
- Field
- Identity
- Record
- Preferred name and stable reference
Fact
- Field
- Fact
- Record
- Current fact, effective date and reliable source
Ownership
- Field
- Ownership
- Record
- Person responsible for confirming and updating it
Placements
- Field
- Placements
- Record
- Profiles, author components, relevant pages and metadata
Verification
- Field
- Verification
- Record
- Public output reviewed and unresolved differences
Maintain identity through the next update
A correction is complete only for the placements that were checked. Record the exact URL, component, previous wording, replacement, supporting source, owner and public verification result. Leave an unresolved placement visible in the change list instead of extending one successful check to the whole site.
When a document moves, review its redirects and incoming references while preserving the meaning of the entity reference. When a name changes, use the rebrand change method for release sequencing. Preserve accurate dated history and retire inaccurate current descriptions with the reason recorded. No real Semantec SEO staffing claim is introduced by the Alex example.
Choose the next question
Return to the Semantic SEO learning library to choose another explanation. If you want help applying this work to a website, send Kevin the site and the task you need to address.