Structure Your Identity for Machines: Entity SEO for People

You can publish rigorously and earn real citations, and still lose, if the retrieval and knowledge graph systems underneath the engine cannot confirm that all of it belongs to one person. This is the least glamorous step in Person Engine Optimization and one of the most decisive, because every other layer depends on it.

The identity fragmentation problem

Most professionals accidentally exist as several different people online. A full name shows up on one platform, an abbreviated version on another. A different title appears here, a different company appears there. An old bio contradicts the new one on a page nobody has touched in two years. To a human reader these are obviously one person, since context fills the gaps automatically. To an engine trying to resolve those signals into a single entity, they can look like several weakly connected profiles, and every signal you have earned gets split across them instead of accumulating in one place.

Table 1: what changes when an identity moves from fragmented to consolidated.

Why this breaks retrieval, not just search

Classic search engines and the retrieval layer sitting underneath a modern AI assistant do not read the way people read. A person recognizes "J. Okafor" and "Jane Okafor, strategist" as the same author instantly, because they carry a mental model of who Jane is. A retrieval system works from strings, embeddings, and graph edges instead of a mental model, and Training Data vs Retrieval covers the difference between what a model learned during training and what it looks up live. When your name appears in five slightly different forms across the web, the system has to decide whether it is looking at one entity or several, and it frequently guesses wrong in the direction of splitting you into weaker fragments. Knowledge graphs such as Wikidata and Google's Knowledge Graph, covered in Knowledge Graphs for People, resolve entities partly through exactly this kind of corroborating detail: the same name, the same employer, the same domain, and the same collaborators appearing consistently across independent sources. Consistency is not a nicety here, it is the raw material the disambiguation step consumes. For a closer look at what actually gets written into a model's internal representation of you versus what it fetches on demand, see How LLMs Store Your Name.

Consistency first

Pick one canonical name and use it everywhere: the same spelling, the same form, across every profile and byline. Do not let a title appear on one page and disappear on another, and do not let a middle initial come and go depending on the platform. Standardize your title and your one-line description so it reads as one sentence repeated, not three related sentences competing for the same territory. Align your bios so they tell one coherent story rather than three contradictory ones, with the same career order, the same key dates, and the same framing of what you actually do. This sounds trivial, and that is exactly why professionals skip it. It is nonetheless the difference between one strong entity carrying every signal you have earned and three or four weak ones quietly splitting credit nobody notices is being split.

Connect your properties: building the sameAs graph

Consistency handles the name. Connection handles the graph. Link your properties to each other so an engine can trace them back to a single person: your personal site, your professional profiles, your author pages on any publication that has run your byline, and your published papers or talks. The schema.org sameAs property, covered in more depth in sameAs: The Most Underrated Markup, exists for exactly this purpose. It tells a machine reader that several distinct URLs describe the same real-world entity. The more clearly your properties reference each other, ideally in both directions, the more confidently an engine resolves them into one identity that owns every signal attached to any of them.

{
  "@context": "https://schema.org",
  "@type": "Person",
  "name": "Jane Okafor",
  "url": "https://yoursite.com",
  "jobTitle": "Fractional CFO",
  "sameAs": [
    "https://www.linkedin.com/in/janeokafor",
    "https://yoursite.com/about",
    "https://twitter.com/janeokafor",
    "https://www.wikidata.org/wiki/Q00000000"
  ]
}

A minimal Person object with a sameAs array pointing at the properties that all describe the same Jane Okafor.

Speak the machine's language: Person schema in practice

Structured data is where entity SEO turns from prose into something a machine reads directly rather than infers. A Person object, placed in JSON-LD in the head of your own site, names you explicitly, states your role, and lists the other profiles that are the same entity. It does not replace the consistency work above, it reinforces it: schema is a formal restatement of a story you have already made coherent everywhere else. The Person Schema JSON-LD Guide walks through the full property list, but the load-bearing fields for identity consolidation are name, url, sameAs, and, where it applies cleanly, worksFor or alumniOf. Keep the object honest and current. A sameAs array pointing at a profile you closed two years ago is itself a small contradiction, and contradictions are what the next section is about.

The name collision problem

Consolidation gets harder when your name is not unique. If you share a name with an unrelated professional, an entity resolution system faces a genuinely different problem than fragmentation: instead of merging your scattered signals, it may be merging you with someone else's, or hedging by treating both of you as one uncertain entity, or splitting a shared name into arbitrary buckets that neither of you controls. Name Collision in PEO covers the specific tactics for this case, but the short version fits here: a collision makes every consolidation habit in this article more urgent, not less, because your consistent name plus your consistent domain plus your consistent sameAs graph is the disambiguating evidence that tells the engine which Jane Okafor it is looking at.

Machine-readable about pages as your anchor document

Somewhere in your properties there should be one page that functions as the anchor: a machine-readable about page, ideally on a domain you control, that states your name, your role, your history, and your other properties in plain sentences plus matching schema. The Machine-Readable About Page covers how to structure that page so both a human visitor and a crawler can parse it cleanly. Treat it as the canonical source the rest of your identity work points back to. When a bio elsewhere drifts out of date, the anchor page is the version you correct first, and it is the one every sameAs link should ultimately resolve toward.

Clean up the contradictions

Audit the web for the old, inconsistent, or outdated versions of you: the stale conference bio, the abandoned profile with a five-year-old title, the guest post blurb that lists a job you left two roles ago. Correct what you can edit directly. Ask politely for updates where you cannot. Where a profile is genuinely dead, retire it rather than leaving it to keep contradicting the current story. Contradictions quietly erode an engine's confidence the same way inconsistent testimony erodes a jury's confidence, not through one dramatic failure but through the accumulated cost of details that do not line up. A clean, consistent entity is one an engine can trust enough to recommend without hedging.

A five-step consolidation audit

Run this once fully, then re-run step 1 whenever you add a new property.

Maintaining the identity over time

Consolidation is not a one-time project, it is a habit that has to survive every new platform, every rebrand, and every job change. Add a new profile only after deciding whether it will carry the canonical name and title, and update the anchor page's sameAs array the same day you create it, not months later when you have forgotten. When you change your title or your firm, treat it as a small migration: update the anchor page first, then every property downstream, then check that no old sameAs link still points at a version of you that no longer exists. Done consistently, this is a few minutes a month. Done sporadically, it is exactly how a clean identity drifts back into the fragmented mess this whole page exists to fix.

One detail people skip: transliteration and script variants. If your name has a common alternate spelling, a transliteration from another script, or a version with and without diacritics, decide on one primary form and note the alternates explicitly rather than letting them appear as silent variants scattered across different platforms. An engine that sees "Jose" on one profile and "Jos\u00e9" on another has no automatic way to know these are the same string unless something, a sameAs link, a matching bio, a shared domain, tells it so. The same logic applies to former names after a legal name change or a professional rebrand: state the transition plainly on your anchor page rather than hoping old references quietly fade, since a silent gap in the record reads to a resolution system as two different people rather than one person with a history.