sameAs Schema: Connecting Your Entity to Wikidata, Wikipedia & Social Profiles

sameAs is a schema.org property whose value is the URL of a reference page that unambiguously identifies the thing being described. It is an identity statement, not a relatedness statement: putting a URL in sameAs says the entity on this page and the entity that URL identifies are one and the same thing. That makes it the single most useful property for connecting a site’s own markup to entities that already exist in public knowledge bases.

What sameAs asserts

The schema.org definition is intentionally narrow. A sameAs value is a reference web page that indicates the item’s identity, such as its Wikipedia article, its Wikidata item, or its official website. The property is defined on Thing, so it is available on every schema.org type: Organization, Person, Place, Product, Event, CreativeWork.

What it does not mean matters just as much. sameAs does not mean “see also”, “the entity is mentioned here”, or “this page is relevant”. schema.org has other properties for those readings: relatedLink and significantLink on WebPage, mainEntityOfPage for the page that is primarily about an entity, and subjectOf for works about it. Using sameAs where one of those is meant publishes a false statement about identity.

The OWL lineage

The name comes from RDF. In OWL, owl:sameAs links two IRIs that denote the same individual, and a reasoner treats it as a strict entailment: everything asserted about one identifier is thereafter true of the other, in both directions. That is a strong claim, and it is why identity errors propagate so far in a reasoning system. See OWL for how that entailment behaves.

schema.org’s sameAs is deliberately weaker. Its range is URL, and the value is understood as a page that identifies the entity rather than an IRI that denotes it, which keeps it usable by publishers who are not modeling ontologies. Consumers still read it as an identity signal, so the practical discipline is the same as the OWL rule: only assert it when the two things really are one thing.

Which URLs to reference, in priority order

Not every identifier carries the same weight. The order below reflects how much disambiguating work each target does.

The Wikidata item. A Q-ID is a stable, language-independent identifier that already links out to dozens of other authority files. If the entity has an item, this is the highest-value value in the array. Use the canonical concept URI form https://www.wikidata.org/wiki/Q7186 (or the http://www.wikidata.org/entity/Q7186 entity URI, which is what other RDF datasets use).
The Wikipedia article, in the primary language of the entity. Wikipedia articles are already linked to Wikidata items, so this is partly redundant, but it is the reference page most consumers recognize.
Official social and professional profiles. LinkedIn company or member pages, X, Facebook, Instagram, YouTube, GitHub. Only profiles the entity actually controls.
Authority files, where they exist. VIAF and ISNI for people and organizations in library catalogs, ORCID for researchers, ROR for research institutions, LEI for legal entities. These are the identifiers libraries, publishers, and registries already agree on.
Industry and regulatory registries, where the listing is about the entity rather than a category: a licensing record, a company registration page, a professional body’s member page.

Two things do not belong in the list. The entity’s own canonical URL belongs in url, since a page saying it is the same as itself adds nothing. Any URL that resolves to a page about a category, a location, or a product line is different and must stay out.

Organization example

The block below describes a fictional company. Replace the identifiers with real ones and delete any line without a real value; an empty or placeholder sameAs is worse than no sameAs at all.

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://example.com/#organization",
  "name": "Northgate Analytics",
  "url": "https://example.com/",
  "logo": "https://example.com/assets/logo.png",
  "description": "Northgate Analytics builds data quality tooling for public-sector reporting.",
  "sameAs": [
    "https://www.wikidata.org/wiki/Q00000",
    "https://en.wikipedia.org/wiki/Northgate_Analytics",
    "https://www.linkedin.com/company/northgate-analytics/",
    "https://github.com/northgate-analytics",
    "https://www.crunchbase.com/organization/northgate-analytics"
  ]
}

Person example

For a person, the useful identifiers skew toward publishing and research systems rather than company registries.

{
  "@context": "https://schema.org",
  "@type": "Person",
  "@id": "https://example.com/authors/jane-doe/#person",
  "name": "Jane Doe",
  "url": "https://example.com/authors/jane-doe/",
  "jobTitle": "Principal Data Engineer",
  "worksFor": { "@id": "https://example.com/#organization" },
  "sameAs": [
    "https://www.wikidata.org/wiki/Q00000",
    "https://orcid.org/0000-0000-0000-0000",
    "https://viaf.org/viaf/000000000/",
    "https://www.linkedin.com/in/janedoe/",
    "https://github.com/janedoe"
  ]
}

Identifiers for public figures are already published and can be looked up rather than guessed. Marie Curie is Wikidata item Q7186, and that item lists her Wikipedia articles alongside her library authority records, which is the fastest way to assemble a correct set for anyone who already has an item.

Where to put it

sameAs belongs on the entity’s home, the one page on the site that is primarily about that entity. For a company, that is normally the home page or an “about” page; for an author, it is the author profile; for a physical location, it is the location page. Everything else on the site should reference that node rather than restate it.

The mechanism is @id. Declare the entity once with a stable identifier, usually the canonical URL plus a fragment, then point at it from other markup:

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://example.com/#organization",
      "name": "Northgate Analytics",
      "url": "https://example.com/",
      "sameAs": [
        "https://www.wikidata.org/wiki/Q00000",
        "https://www.linkedin.com/company/northgate-analytics/"
      ]
    },
    {
      "@type": "Article",
      "@id": "https://example.com/blog/data-contracts/#article",
      "headline": "Writing data contracts that hold up",
      "publisher": { "@id": "https://example.com/#organization" },
      "author": { "@id": "https://example.com/authors/jane-doe/#person" }
    }
  ]
}

The Article block carries no sameAs of its own, because the article is not the same thing as any external page. It inherits nothing and claims nothing; it just references the organization node that holds the identity statements. The pattern is explained in more depth in JSON-LD and applied across property sets in organization schema and person schema.

Misuses that make sameAs harmful

A wrong sameAs is not a neutral omission. It is a published false claim about identity, and a consumer that acts on it will merge or confuse two entities.

Pointing at a related but different entity. A subsidiary linking to the parent company’s Wikidata item, a regional office linking to the global brand’s Wikipedia article, a product page linking to the manufacturer. These are real relationships, and schema.org has properties for them: parentOrganization, subOrganization, brand, manufacturer, isPartOf.

Pointing at a founder’s page from the company. A company is not its founder. If the founder has a Wikipedia article and the company does not, the temptation is obvious, and the statement is still false. Use founder with a Person node, and keep the founder’s identifiers on the Person.

Pointing at aggregator or directory listings that are about a category. A “best accounting software” roundup, a city directory page, a marketplace category, a review site’s genre hub. Those pages are about a set of things. A directory profile page dedicated solely to the entity is a defensible value; a listing page that happens to mention it is not.

Duplicating conflicting sameAs sets across pages. Two templates each emitting an Organization node, each with a slightly different array, produce contradictory identity claims and often two entities where one was intended. One node, one @id, one array, referenced everywhere else.

Padding the array. Every dormant account and every profile owned by someone else dilutes the set with noise. A short, accurate array is stronger than a long, partly wrong one.

Corroboration is what makes the claim credible

sameAs is an assertion the site makes about itself. Nothing in the property makes it true, and a search engine has no reason to accept an unsupported identity claim from an interested party. What makes the claim usable is agreement from sources the site does not control: the Wikidata item pointing back to the official website, the LinkedIn page naming the same organization, the authority record carrying the same identifiers. When the outbound claim and the inbound records agree, the entity resolves. When they disagree, the markup adds another conflicting signal.

This is the difference between publishing markup and building an identity. Entity linking, NER, and extraction describe the resolution problem from the consuming side, and linked data covers the convention that identifiers should be dereferenceable and shared rather than private.

For developers

Treat sameAs values as foreign keys into other graphs and validate them like foreign keys. A build-time check can fetch each referenced Wikidata item and confirm that its label and instance-of class match the local entity, catching transposed Q-IDs immediately. Wikidata’s own data is queryable, so the check is a SPARQL request rather than a scrape.

In a triple store, schema:sameAs will not trigger identity reasoning the way owl:sameAs does, because they are different properties. Pipelines that want reasoning usually map curated, high-confidence schema:sameAs statements to owl:sameAs and leave the rest as weaker evidence. Doing that mapping indiscriminately is how a graph ends up believing a company and its founder are the same individual.

For SEOs

sameAs produces no visual change in search results. It is not a rich result property, no report will confirm it, and it is not a ranking factor. Its value is upstream of results: it gives a consumer a documented route from the page to identifiers it already holds, which helps an entity get recognized rather than re-derived from text each time. Related work covers entity SEO and, for the panel case specifically, how to get a knowledge panel.

The sequence is short: fix the entity home so one page is clearly about the entity, declare one node with one @id, add only identifiers that exist and are correct, then work on the external side, since a corroborated claim is the only kind that does anything.

FAQ

What does sameAs mean in schema markup?

In schema.org, sameAs holds the URL of a reference page that unambiguously identifies the thing being described, such as its Wikidata item, its Wikipedia article, or an official profile it controls. It is an identity claim: the entity described in the markup and the entity that URL identifies are the same thing. It is not a way to link to related or merely relevant pages.

How many sameAs URLs should an entity have?

As many as are accurate, and no more. Three or four correct identifiers, led by a Wikidata item and an official profile, do more than a dozen loose links. Every value is a separate identity claim, so a wrong one is a published error rather than a missed opportunity. Remove dormant accounts, category pages, and profiles the entity does not control.

Does sameAs help get a knowledge panel?

Not on its own. sameAs is a claim the site makes about itself, and search engines weigh it against independent sources. Panels come from an entity being recognized and corroborated across sources Google trusts, so sameAs helps mainly by making the site’s own identity statements explicit and consistent with those sources. No markup guarantees a panel.

Where should sameAs go on a website?

On the entity’s home: the single page that is primarily about that entity, such as the home page or about page for an organization and the author profile for a person. Declare the entity once with a stable @id there, then reference that @id from markup on other pages instead of repeating the sameAs array, which prevents conflicting identity claims.

Sources and further reading

schema.org, sameAs: https://schema.org/sameAs
schema.org, Thing: https://schema.org/Thing
W3C, OWL 2 Web Ontology Language Primer: https://www.w3.org/TR/owl2-primer/
Google Search Central, Organization structured data: https://developers.google.com/search/docs/appearance/structured-data/organization
Wikidata, Introduction: https://www.wikidata.org/wiki/Wikidata:Introduction
ORCID: https://orcid.org/