Canonical identity beats more content.
Resolve conflicting biographies before publishing another version.
Sulayman Bowles · · Updated
How do I make my website, résumé, and public profiles describe the same person?
Inventory the profiles and documents people can actually find, then choose an authoritative homepage and current résumé. Reconcile names, roles, dates, and links against that record before adding more pages. Use sameAs for profiles representing the same identity, rather than every page that mentions you. Retain dated historical context where appropriate. Consistent publication signals help people and crawlers reconcile records; they do not give you control over a search engine’s identity presentation.
Evidence: Google canonical guidance · Google ProfilePage guidance · Schema.org sameAs
Read this alongside Build search systems you can verify.
Your portfolio, résumé PDF, university biography, GitHub, LinkedIn, competition account, old domain, and copied speaker bio can describe different versions of you. Conflicting roles, employers, dates, project ownership, and official websites leave the identity unclear.
Reconcile these records before expanding them. Choose which controlled profile owns the current biography, experience, and education; classify supporting and historical pages; then decide how to repair stale URLs. More copies cannot settle an unresolved source of truth.
Scope and assumptions
This playbook improves consistency among controlled and observable profiles. It cannot force third-party platforms to update, remain public, or be interpreted as identity evidence by a search system.
- Primary artifact
- RECONCILIATION LOG
- Decision layers
- 06
- Review cadence
- QUARTERLY
Inventory the identities already in public
Collect the preferred site, HTML résumé, public PDF, GitHub, LinkedIn, portfolio accounts, institutional biographies, programs, press, and abandoned domains. Compare name, headline, employer, education dates, project ownership, and preferred homepage.
Assign a role: canonical biography for the present, supporting profile for corroboration, historical page for a dated event, or stale controlled page needing repair. Private, deleted, and weakly matching profiles remain unresolved rather than assumed equivalent.
| Field | Decision it supports | Example state |
|---|---|---|
| URL and owner | Can this record be edited or redirected? | Controlled / third party |
| Profile role | What is the page allowed to establish? | Canonical / supporting / historical |
| Visible identity | Does the name and headline match the intended person? | Match / partial / conflict |
| Freshness | Is the content expected to describe the present? | Current / dated history / unknown |
| Action | What should happen next? | Keep / update / redirect / omit / monitor |
Align the host and the current facts
Resolve protocol and hostname variants consistently. Permanently redirect duplicate hosts and retired controlled routes with clear destinations. Align redirects, canonicals, sitemaps, and internal links so one signal is not asked to overcome contradictory routing.
Maintain an approved set of facts for home, About, résumé, and metadata: current work, relevant projects and institutions, and inspectable proof. Wording can vary; identity and factual meaning should agree.
| Observed state | Action | Expected result |
|---|---|---|
| Alternate host contains the same site | Permanently redirect to the preferred host | One hostname receives internal and external references |
| Old controlled route has a direct replacement | Permanently redirect to the closest current page | Existing links reach the maintained record |
| Duplicate page must remain available | Declare the preferred URL and link internally to it | Signals consistently favor one version |
| Historical page documents a real past event | Keep dated context; do not rewrite it as a current profile | History remains legible without competing with the present |
Check identity before adding sameAs
Use four core checks: the destination unambiguously represents this person, functions as their profile or homepage, is publicly inspectable, and contains no material contradiction. Apply this rubric before adding a URL to Person markup, then keep it maintained.
A mention is not a profile. Articles, programs, employer pages, repositories, and schedules can support visible citations, subjectOf relationships, project markup, or editorial context without asserting identity equivalence.
| Test | Include when | Exclude when |
|---|---|---|
| Identity | The destination unambiguously represents the same person | The name is shared or the connection is inferred |
| Access | A reviewer can inspect the profile without privileged access | The page is private, deleted, blocked, or empty |
| Agreement | Core current facts do not materially conflict | Employer, role, location, or ownership is misleading |
| Profile function | The destination is a profile or official homepage | The destination merely mentions the person |
| Maintenance | The link is reviewed and still expected to persist | The account was abandoned or transferred |
Maintain HTML and reconcile the portable PDF
Use the HTML résumé as the maintainable website record. Semantic headings, current project links, profile details, and a modification date make it easier to update and connect to the rest of the site.
Keep PDF for applications and offline sharing, with one stable public URL. Redirect obsolete controlled filenames and reconcile visible facts before leaving another dated copy publicly available.
- Treat the HTML route as the current, maintainable experience and education record.
- Publish one stable PDF URL rather than creating a new public filename for each revision.
- Check that the visible PDF facts match the HTML record before release.
- Redirect known retired filenames instead of allowing silent duplicate copies.
- Keep private application variants outside the public web surface.
Prioritize the records you can change
Start with likely reviewer touchpoints: preferred website, LinkedIn, GitHub, then major portfolio accounts. Institutional and event records may belong to another owner. Log correction requests and preserve accurate historical context.
Track uneditable discrepancies rather than pretending they are fixed. A stale third-party title is a dependency; the same stale title on your site is directly repairable. Ownership determines the next action.
- 1Preferred site and HTML resumeEdit immediately
- 2LinkedIn, GitHub, portfolio accountsUpdate controlled fields
- 3Employer or university biographiesRequest correction when appropriate
- 4Programs, press, and event archivesPreserve accurate history
- 5Private, deleted, or inaccessible profilesOmit from structured identity claims
| Priority | Profile class | Required check | Owner response |
|---|---|---|---|
| 1 | Preferred site and HTML resume | Name, headline, dates, links, canonical identifiers | Edit immediately |
| 2 | LinkedIn, GitHub, portfolio accounts | Current role, canonical website, project ownership | Update controlled fields |
| 3 | Employer or university biographies | Material current-fact conflicts | Request correction when appropriate |
| 4 | Programs, press, and event archives | Whether the page is accurate for its historical date | Preserve accurate history |
| 5 | Private, deleted, or inaccessible profiles | Whether identity can still be verified | Omit from structured identity claims |
Reconcile after changes and each quarter
Review after roles, graduation, launches, domain moves, and public résumé revisions. Quarterly checks catch expired links, copied biographies, renamed accounts, and newly indexed files. Record observations and actions instead of giving a profile permanent “done” status.
Measure the share of important controlled records that agree on current identity and reference the maintained source. Historical descriptions may differ because they document other times; accurate history is not an inconsistency to erase.
- Review controlled profile pages and the public PDF every quarter.
- Recheck redirects and canonical host behavior after deployments or domain changes.
- Validate sameAs destinations before adding them and after username changes.
- Record third-party correction requests separately from edits you directly control.
- Keep dated historical sources when they are accurate for their original context.
Maintain the facts, not more copies
Measure agreement across important, controllable records and their links to the maintained profile. Keep accurate history dated and third-party discrepancies visible. Consistency does not force another platform to update or a search system to accept an identity claim.
Sources
- Google canonical URL guidance
Verified Jul 16, 2026
- Google redirects guidance
Verified Jul 16, 2026
- Google ProfilePage structured data
Verified Jul 16, 2026
- Schema.org Person
Verified Jul 16, 2026
- Schema.org sameAs
Verified Jul 16, 2026
- Schema.org ProfilePage
Verified Jul 16, 2026