sameAs and digital identity.
sameAs is the schema field that declares an entity’s official profiles on other platforms, letting machines merge the same entity across different places.
An organization or a person does not live in one place on the web. There is the site itself, a professional network profile, perhaps a code repository, an industry directory record, a portfolio account. To a human it is obvious these are the same entity — the name matches, the photo is familiar, the story lines up. To a machine it is not obvious at all: hundreds of accounts may carry the same name, and there is no way to know which ones really are the same entity. sameAs closes exactly that gap.
The field’s job is a list: it says “this entity is also me here, here and here.” Because the declaration is made from the site’s own schema, its authority is high — a site is the most authoritative source speaking about its own identity. Models and search engines use the declaration to gather the signals from different platforms into a single entity.
Why it matters
When answer engines evaluate a source, they look not at a single page but at the entity behind it. The more independent verification exists about that entity, the higher the trust. Someone whose own site says “I have done this work for twenty years” and someone who carries the same information on a professional profile, shows real contributions in a code repository and is recorded in an industry directory do not weigh the same to a machine.
Second, sameAs is a merging mechanism. When profiles are not declared, your presence on different platforms remains a set of disconnected fragments, none reinforcing the others. Once declared, the fragments gather into a single entity, and the total weight exceeds the sum of the parts.
- Professional network profile — verification of identity and experience.
- Code repository — proof of real contribution in technical fields.
- Industry directory record — third-party verification.
- Portfolio or award platform profile — an external record of work quality.
- Publication profiles — a history of articles and talks.
Fabrication is forbidden
The most important rule of this field is a prohibition: a profile that does not exist, or is not yours, must not be declared. The declaration is a claim, and a verifiable one — the machine opens the link and looks for a pointer back to your site. Without reciprocity the claim fails verification, and the credibility of the rest of the graph is damaged with it. One false declaration does more harm than ten correct ones do good.
For the same reason, leaving the field empty is always better than inventing. A site may have no sameAs field, and that is not a deficiency; an absent field claims nothing. On this site the field stands empty on purpose, because the owner has not yet shared profile addresses — and the verification suite checks on every run that no fabricated profile link has been added. The guard would even catch a well-meant “example” link added in the future.
One false profile declaration does more harm than ten correct ones do good.
Reciprocity: the two-way link
For sameAs to really work, the link must run both ways. Your site points to your profile; your profile must point back to your site. Most platforms offer a website field on the profile, and filling it is what lets the sameAs declaration be verified. A one-way link is technically valid but unverifiable — and an unverifiable claim carries no weight on the trust scale.
There is also a consistency dimension. Your name, description and contact information across platforms should agree. If one place says “Studio X,” another “X Digital,” and a third your personal name, the machine has a harder time deciding they are the same entity. The principle known for local businesses as name-address-phone consistency works exactly the same way for digital identity.
The practical start: list which profiles are genuinely active, make sure each carries the site link, bring the name and the description into line, then write the list into the schema. The order matters — fix the reality first, then declare it. The reverse would announce an unfixed reality to the machines.
Which profiles count
Not every account is identity verification, and padding the list gains nothing. The profiles that count are the ones with real activity that make the identity verifiable. An empty profile proves nothing even though it carries your name; a rarely updated account can even backfire by leaving an abandoned impression. The rule: a profile enters the list if it genuinely represents your presence on that platform.
The order of priority also depends on your field. In technical work the code repository weighs most; in design, the portfolio platform; in consulting, the professional network profile. Industry directories and professional body records carry special value because they provide third-party verification — a record you did not create yourself is a stronger signal than your own declaration.
And a maintenance rule: the list must be updated together with reality. If a closed account is not removed from the list, the declaration eventually points at a dead link and becomes unverifiable. This is the rarely considered but real maintenance cost of the sameAs field.
There is a timing dimension too. A newly founded entity having no external profiles is normal, and in that case leaving the field empty is the correct decision. As profiles form over time the list grows — but the growth should follow real activity, not the other way round. Creating profiles first and doing nothing on them fills the list without providing verification. Models do not count an empty account as evidence; what matters to them is the real footprint on that platform.
Name-address-phone for local businesses
For businesses with a physical location, the classic name of digital identity consistency is NAP consistency — name, address, phone — and its logic is identical to sameAs: the records of the same entity in different places must agree. If one directory says “Street No 5,” another “St. 5/A,” and a third carries an old phone number, the machine has a harder time deciding these are the same business, and each record stays weak on its own.
Inconsistency usually comes not from bad intent but from time: the business moves, the number changes, and old records go unupdated. Digital identity maintenance is therefore not a one-off job but a regular check — reviewing all records once a year is enough for most businesses, and something most businesses never do.
On this site no physical location is declared, because the service is delivered remotely and the owner has not shared an address. The schema states the service area, but no street address — not declaring what does not exist is the correct behavior, even at the cost of an empty field.