One entity, or five
Publishing structured data is easy and mostly pointless on its own. You add a Person block, a validator says it is valid, and nothing happens. The reason is that validity is not the thing being assessed. A search engine reading your site is trying to decide whether the various mentions of a name across your pages, and across the other sites that mention you, refer to one real entity it can be confident about. Valid markup that describes five subtly different people answers that question in the negative, politely, forever.
I have been doing this work on my own site, so I can be concrete about what actually needed fixing rather than theoretical about best practice.
Give the entity an identifier and use it everywhere
The single most useful piece of discipline is also the least glamorous: pick one canonical identifier for the entity and reference it by that identifier from every other node, rather than describing the entity again each time.
In schema.org terms this means one node carrying an @id, and every article,
page and organisation that needs to point at that entity using {"@id": "..."}
instead of repeating a name and a job title. On my site the identifier is the site URL with a
fragment: one Person node owns it, and every article's author,
creator and publisher is that reference and nothing else.
The failure mode this prevents is subtle. If each article embeds a full author object with a name and a description, you have not published one author with twelve articles. You have published twelve author-shaped objects that a consumer must decide are the same person, using string similarity, on every crawl. Referencing an identifier removes the guess. It is the difference between twelve rows with a foreign key and twelve rows with a name typed into them, and it fails for the same reason denormalised data always fails.
The identifier is also how the graph extends off your own domain. My organisations declare a founder by the same identifier my site uses for me, so a crawler reading the company site and the personal site is reading two statements about one node rather than two similar strangers. That reciprocation is the part that does work; a Person node that only my own homepage references is a claim with no second source.
The strings have to be byte-identical, and they will not be
Here is the part that sounds trivial and is where the actual bugs live. The name, the job title and the description have to be the same strings everywhere they appear. Not equivalent. Not obviously about the same person. The same.
I audited my own site expecting this to be clean, because I had deliberately centralised the identity graph in a single function months ago. Name: one value across every page. Job title: one value. Description: two values. Thirteen pages carried the canonical description. Seven carried a shortened variant — same person, same facts, fewer clauses, a different list of companies. Both accurate. Both published. And that is exactly the ambiguity that stops consolidation, produced not by carelessness but by a subtree of the site that had been generated at a different time and had never been brought back in line.
It is worth being clear about why this matters more than it seems. A consumer comparing two
descriptions cannot tell the difference between the same entity, described twice
and
two entities that resemble each other
. Given the second possibility, the safe action is
to merge nothing. Every additional variant lowers confidence, so a site that describes its
author five slightly different ways is not five times as informative. It is less informative
than one that says it once.
Only list profiles that exist, and verify them properly
The sameAs array is where a personal entity connects to records the search
engine already trusts, and it is where people quietly do damage. The rule is that it should list
profiles genuinely owned and publicly live, and nothing else. An aspirational profile, a link to
a page that 404s, or a profile belonging to somebody with the same name are all worse than a
shorter list, because they either point at nothing or point at a different entity, and both
outcomes reduce confidence in the node making the claim.
Verifying that list turns out to be less mechanical than it sounds. I checked each of mine with a browser user agent and got a useful lesson in what a status code proves. Six returned 200 and are settled. One returned 403, and one returned 999, which is a status code a particular professional network invented for automated traffic.
The temptation is to treat those two as dead and remove them. That would have been wrong. When I requested a deliberately non-existent profile on the same network, I received a byte-identical response to the real one — same status, same length, same hash. The response carries no information about existence at all, so it can neither confirm nor refute the link, and removing a genuine profile on that evidence would have deleted one of the strongest signals on the page. I confirmed those two a different way instead, through a third-party record that independently lists the same account identifiers.
Which produced the one real inconsistency worth acting on: that third-party record lists my profile slug on the professional network with a different spelling of the surname than my own site uses. Same numeric suffix, so almost certainly the same profile under an older or newer public URL. I cannot resolve which is canonical from the outside, because both requests return the same uninformative response, and guessing would mean publishing a link I have not verified. So it stays as it is and gets settled by opening the profile while signed in, which is a thirty-second job for the account holder and impossible for anybody else.
What actually causes recognition
Volume does not. Publishing a great deal of content under a personal name is not a mechanism for entity recognition and, done deliberately for that purpose, tends to read as manufactured. What appears to matter is consistency across sources that are already trusted, which is why the work divides roughly in half: writing things worth reading, and making sure every place the entity is described says the same thing.
The engineering version of that is boring and mechanical. One identifier. One set of strings,
generated from one place so a second variant is not expressible. References by identifier rather
than repeated descriptions. Reciprocal statements from the organisation sites. A
sameAs list containing only what is real and verified — and an honest account
of what verified
means when the platform you are checking refuses to tell you
anything.
Written by Liana Grigory, also written Liana Grigoryan — entrepreneur, software engineer and U.S. Army veteran in Los Angeles. More at Writing.