What Is sameAs and Entity Linking and How Do You Implement It in 2026?

Why sameAs and Entity Linking matters for AI visibility

The failure mode is specific and easy to reproduce. Ask an assistant about a mid-sized company whose name collides with a bigger one, or about an author whose byline is shared by three other people, and the answer comes back stitched from the wrong record: the wrong founding year, a competitor's funding round, a headquarters in the wrong country, an article credited to someone else. Nothing on your site is factually wrong. The consumer simply never had a reason to believe that the string on your pages and the string in the record it already holds refer to one entity, so it merged or picked at random. sameAs is the explicit assertion that closes that gap, and @id is the mechanism that keeps every page on your own site pointing at one node rather than quietly declaring a slightly different organisation on each template.

Be precise about how that assertion travels, because two pipelines are involved and only one of them parses your JSON-LD. Google's Knowledge Graph does parse it, and Wikidata Q-IDs are among the identifiers it leans on, so a clean Organization node carrying a Wikidata sameAs is a genuine input to how Google resolves you, and to the AI Overviews and Gemini surfaces built on that graph. Language models reading a page directly do not parse it. A widely replicated February 2026 test placed a fabricated address inside deliberately invalid JSON-LD, with a made-up context and made-up types, and both ChatGPT and Perplexity repeated it back: they tokenise the script block as text, like any other text on the page. So do not promise anyone a ranking effect. Google lists sameAs as recommended rather than required and documents no ranking benefit for it, and the honest case for shipping it is narrower and more durable: it makes you a resolvable node instead of an ambiguous string, and it is about a dozen lines of JSON.

Where the spec lives

One vocabulary page defines the property, one W3C recommendation defines the identity plumbing around it, two vendor pages define what is consumed, and one policy page decides whether your Wikidata item survives. Read them in that order.

• schema.org/sameAs - the property definition, its expected type (URL), and the fact that it is defined on Thing so it applies to every type. The worked examples on this page link a Movie, a Book and a Person to Wikidata items.
• JSON-LD 1.1 (W3C Recommendation, 16 July 2020) - the normative source for @id and @graph. Read section 4 before you decide what your Organization node's @id should be, because node identifiers are IRIs and not slugs.
• Google Search Central: Organization structured data - the vendor list of what to put on the node. It states there are no required properties, recommends placing the markup on your home page or a single page describing the organisation, and documents the exact-match identifier fields leiCode, iso6523Code, duns, naics, globalLocationNumber, taxID and vatID.
• Google Search Central: author markup best practices - the rules for person entities: one author field per author, valid URLs in url and sameAs, Person for people and Organization for organisations, and nothing but the name inside author.name.
• Wikidata:Notability - the three criteria your item must meet one of. Check this before you create an item, because an entry sourced only to your own website fails the verifiability test and gets nominated for deletion.
• Schema Markup Validator - the tool that parses the whole graph rather than only the parts Google turns into rich results. Use it to confirm your @id references actually resolve to a node instead of dangling.

Implementation guidelines

These are the things that break entity linking in production, in the order they usually break.

1. Pick one Organization @id and never change it. An absolute URI with a fragment, such as https://example.com/#organization, is the convention. Changing it later orphans every reference that pointed at the old value, and there is no redirect mechanism for node identifiers.
2. Reference by @id, do not re-declare. On article and product pages, write "publisher": { "@id": "https://example.com/#organization" } rather than pasting a second copy of the node with a shortened name or an older logo. Two nodes that differ by one field are two entities.
3. Make the link reciprocal where the platform allows it. A one-way claim is unverifiable. Set the official website field on your Wikidata item (property P856) back to your home page, fill in the website field on your LinkedIn company page, and set the URL on your GitHub organisation. Consumers weight a mutual link far higher than a claim only you make.
4. Only list profiles you control and that are still live. An abandoned X account, a squatted handle, or a Crunchbase record for a company you acquired pulls the wrong facts into your cluster. Google's structured data guidelines are explicit that markup must not misrepresent ownership, and a dead profile is worse than no profile.
5. Prefer issued identifiers to marketing URLs. A Wikidata Q-ID, an ORCID iD, an LEI, a ROR ID or a national company register entry were assigned by someone other than you, which is exactly what makes them useful. Four to eight strong references beat twenty weak ones, and there is no benefit to padding the array.
6. Never put your own pages in sameAs. sameAs is for external references. Your home page belongs in url, your node identity belongs in @id, and a sameAs pointing at your own /about/ page tells a consumer nothing it did not already know.
7. Validate in CI, not in a browser tab. One trailing comma invalidates the entire script block and every node in it disappears at once, including the sameAs array. Parse each rendered template with JSON.parse in a test, then assert that every @id referenced somewhere in the graph is also defined somewhere in the graph.

Do this, not that

How Glippy checks this

Glippy splits this across two categories. Under Structured Data and Schema it flattens every JSON-LD block, expanding @graph and top-level arrays, then awards the full 10 points for the sameAs Links check as soon as any node carries a non-empty sameAs array, and it counts sameAs alongside url, logo and contactPoint as a recommended property when it scores Organization completeness. Under Entity and Authority, category 7, it scores five signals: author discovery worth 25 points, which looks for an author on a page-author schema type and deliberately ignores Review and Comment authors, then falls back to meta[name="author"] and byline selectors; author credibility worth 10, which wants both an author link and an author bio; publication date worth 20 and modification date worth 10, taken from datePublished and dateModified; and organisation signals worth 20, which needs three of four from an about or contact link, an Organization, LocalBusiness, NewsMediaOrganization or Corporation node or any publisher field, an og:site_name meta tag, and a copyright line in the footer. Marking up one canonical Organization node and one linked author entity moves both categories at once.

Reviewed against the primary sources on 27 August 2026. These standards move quickly, so check the linked specs before you ship.