Canonical Identity Beats More Content

A reconciliation checklist for profiles, stale PDFs, sameAs links, and public proof pages.

Memo Details

Category: ENTITY CONSISTENCY. Published: 2026.06.19. Read time: 07 MIN.

Article Metrics

Scope

PERSON GRAPH

Priority

CANONICALS

Maintenance

ONGOING

Research Thesis

The fastest way to weaken a personal SEO graph is to publish more disconnected versions of the same person. A portfolio homepage says one thing, an old resume PDF says another, GitHub says nothing, LinkedIn uses a different line, and a hackathon profile still points at an abandoned project. None of those pieces is necessarily wrong on its own. The problem is that crawlers and human reviewers have to decide which one is current.

Canonical identity starts with one preferred host and one preferred profile thesis. Google describes redirects as one of the strongest canonicalization signals and recommends consistent canonical URLs across a site. For a personal site, that means the apex domain should resolve clearly, the www host should redirect, internal links should point at the same canonical pages, and stale URLs should be retired through redirects rather than left as dead ends.

The HTML resume should be the durable source of truth because it can carry visible text, internal links, schema, and a current update path. A downloadable PDF can still be useful, but it should not become the canonical identity page unless there is a reason for that tradeoff. When an old resume PDF is already in search results, the clean repair is either to restore the exact file with current content or redirect it to the canonical resume page so the old surface stops returning a dead 404.

Structured data should be conservative. Schema.org defines sameAs as a URL that unambiguously identifies the same item, not a bucket for every social link ever created. For a person, GitHub and LinkedIn can be strong sameAs links when they visibly describe the same person and current role. A dead, private, or weakly matching profile should stay out of sameAs even if it once existed. It can still appear as historical context on a source page if that context is useful.

ProfilePage markup works best when the visible page is clearly about one person or one organization. Google guidance describes mainEntity as the person or organization the profile page is about. That makes /about, /resume, and /ai-information useful profile surfaces if they share the same Person @id, current description, and source links. The markup should not invent claims that the page text does not support.

The reconciliation process is practical: pick the canonical domain, redirect duplicate hosts, redirect stale PDFs, keep /about and /resume aligned, publish an /ai-information page with source roles and caveats, and push the same one-line current identity to external bios. The output is not a bigger personal brand. It is a smaller, cleaner set of records that makes the current public identity easier to verify.

Model Frame

Personal Entity Reconciliation Pattern: one person graph = canonical URL + profile pages + sameAs discipline + redirected stale artifacts

Key Risk Vector

External profiles can drift, block unauthenticated crawlers, or expose old positioning. The site should distinguish verified profile links from weak or dead references.