sameAs schema: which URLs belong there and how to check them against Wikidata

As of November 12, 2026 · examples from podrez.pl and the Wikidata record Q133444548

sameAs is the schema.org property that tells search engines and AI systems: this person or company is the same one that’s described over there. “Over there” means Wikidata, Wikipedia, the profiles you run and records in catalogs. Most guides stop at “add your social profiles.” I’ll show you what belongs in the list, what doesn’t, and how to check it against Wikidata, using my own About page, where 15 of the 18 addresses Wikidata lists are already in my schema.

What is sameAs in schema markup?

Schema.org defines sameAs as the “URL of a reference Web page that unambiguously indicates the item’s identity” and gives three examples: the item’s Wikipedia page, its Wikidata entry and its official website. The property belongs to Thing, so you can use it on any type: Person, Organization, LocalBusiness, Book, Event. The value is a URL, and you can list as many as you need.

In practice, sameAs says: this node and the thing on that page are the same entity. It doesn’t copy any data from there and it doesn’t prove anything by itself. It’s a pointer. The proof is on the other side: a Wikidata record with sources, a profile confirmed as yours, an authority record in a national library.

What does Google say about sameAs?

For people and companies, Google’s structured data documentation mentions sameAs in three places (Organization, ProfilePage and Article markup) and gives it a slightly different job in each:

Google Search Central documentation, checked on November 12, 2026. None of the three pages promises a visual feature or a ranking boost for sameAs.

Google also recommends putting Organization markup on your home page or on a single page about the organization, such as About us, and says you don’t need it on every page. I use the same logic for a person: one About page that is the home of the entity.

Which URLs should go in sameAs?

• Wikidata and Wikipedia

  Two of the three examples schema.org itself gives. If you have a Wikidata record, it goes first on the list.

• Profiles you run

  LinkedIn, Instagram, YouTube, GitHub, your page on a podcast platform. Only the ones that are yours and still active.

• Authority records in catalogs

  ORCID, VIAF, the Library of Congress, your national library, WorldCat Entities. For authors and researchers these are the strongest identifiers, because someone else maintains them.

• Business registries and review sites

  For a company: an entry in a business registry, a Crunchbase profile, a profile on a review site. Google gives review sites as an example.

And what doesn’t belong there:

• Articles, interviews and podcasts about you

  They’re about you. They don’t identify you. They go in subjectOf, the property schema.org defines as a creative work or event about the thing.

• Your own website

  That goes in url. Google describes sameAs for organizations as a page on another website.

• Your employer’s home page

  A company is a different entity. Use worksFor and give the company its own node with its own sameAs.

• Search results for your name, tag pages, listings

  They change and don’t identify anyone.

One address on my list looks like a search page: google.com/search?kgmid=… It’s the address Wikidata builds from my Google Knowledge Graph ID (P2671), so it points to an entity, not to a query. You can look up your own kgmid in my Knowledge Graph checker.

sameAs, url, @id and subjectOf: which one when?

Values from the Person node on podrez.pl/en/about-me/ on November 12, 2026.

One more habit worth copying: sameAs isn’t only for you. In my graph, the university I graduated from and my country also point to their Wikidata records. That way there’s no doubt which university in Wrocław I mean.

Where should sameAs go?

On the node that describes the entity: Person, Organization or a more specific type such as LocalBusiness. Not on WebPage or WebSite. Your LinkedIn profile isn’t the same thing as your About page.

Keep one node per entity, with a stable @id, and refer to it from everywhere else, including the author property of your articles. If your SEO plugin builds one Person, your theme another and an author box a third, each with its own sameAs list, you’re describing three people with the same name. On the map in Entity Observatory, such duplicates are easy to spot.

In WordPress, SEO plugins have a field for profiles. In Rank Math it’s Titles & Meta → Social Meta → Additional Profiles (see Rank Math’s guide to sameAs). Whatever tool you use, check which node the profiles end up on.

sameAs schema example in JSON-LD

A trimmed version of my own Person node:

{
  "@context": "https://schema.org",
  "@type": "Person",
  "@id": "https://podrez.pl/#person",
  "name": "Ewelina Podrez-Siama",
  "url": "https://podrez.pl/",
  "sameAs": [
    "https://www.wikidata.org/wiki/Q133444548",
    "https://pl.wikipedia.org/wiki/Ewelina_Podrez-Siama",
    "https://orcid.org/0009-0005-5245-6258",
    "https://www.linkedin.com/in/podrez/",
    "https://www.youtube.com/@EwelinaPodrezSiama"
  ],
  "alumniOf": {
    "@type": "CollegeOrUniversity",
    "name": "Wrocław University of Science and Technology",
    "sameAs": "https://www.wikidata.org/wiki/Q522109"
  },
  "mainEntityOfPage": { "@id": "https://podrez.pl/en/about-me/#webpage" }
}

And a company, with the same split between sameAs and subjectOf (example addresses):

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://www.example.com/#organization",
  "name": "Example Bakery",
  "url": "https://www.example.com/",
  "sameAs": [
    "https://www.linkedin.com/company/example-bakery/",
    "https://www.instagram.com/examplebakery/",
    "https://reviews.example.org/business/example-bakery"
  ],
  "subjectOf": {
    "@type": "NewsArticle",
    "headline": "The bakery that wakes the street at 4 a.m.",
    "url": "https://news.example.org/bakery-at-4am"
  }
}

How to check your sameAs against Wikidata

Wikidata is the best checklist for sameAs I know, because it stores the same things you’d put there: the official website (P856), links to Wikipedia and Commons, and dozens of external identifiers, from Instagram usernames to library catalog numbers. The catch: identifiers are stored as IDs, not as URLs. If you’re new to Wikidata, start with my Wikidata guide.

1. 1Find the record

   In your schema, find the node whose sameAs points to wikidata.org/wiki/Q… No such link? Look the entity up on Wikidata first.

2. 2Collect the addresses

   The official website (P856), the Wikipedia and Commons links, and every external identifier in the record.

3. 3Turn IDs into URLs

   Almost every identifier property has a formatter URL (P1630): a pattern in which $1 is replaced with the ID. The Instagram username ewela_pe and the pattern https://www.instagram.com/$1/ give https://www.instagram.com/ewela_pe/.

4. 4Mind the ranks

   A property can have several formats. On November 12, 2026, the Facebook username property had two formats: facebook.com/$1 with the preferred rank and messenger.com/t/$1 with the normal one. VIAF had three, two of them deprecated. Statements with the deprecated rank are ones Wikidata considers wrong or outdated (in its words, “known to include errors”), so skip them. History is marked differently, with end dates (P582): a profile with an end date is history, not a gap.

5. 5Normalize

   Before comparing, ignore http vs. https, www, trailing slashes, tracking parameters and letter case in the domain (and, on most social platforms, in usernames). pl.linkedin.com/in/x is linkedin.com/in/x, and twitter.com/x is x.com/x.

6. 6Compare both ways

   What Wikidata has and your schema doesn’t, and what your schema has and Wikidata doesn’t. The second list is not an error.

For one record that’s 20 to 40 lookups. That’s why I built it into Entity Observatory as the ≈ sameAs view. You load the page, fetch the Wikidata record it points to, and the tool does the rest in your browser. Only identifiers go to Wikimedia: the record number, property numbers and, if you leave name fetching on, the numbers of linked records. Wikimedia also sees your IP address.

What the check found on my own About page

On November 12, 2026, I ran it on podrez.pl/en/about-me/ against my record, Q133444548. Result: 15 of 18 addresses from Wikidata are in my schema.

• ≈ Another address format (4)

  VIAF in my schema uses viaf.org/viaf/…, a format Wikidata now marks as deprecated. The preferred one is viaf.org/en/viaf/…. The Library of Congress record has /authorities/names/ in my list and /authorities/ in Wikidata, Flickr has /photos/ instead of /people/, and Goodreads has the ID followed by my name. The identifiers are the same, so the tool counts them as matches.

• ○ Missing from the schema (1)

  My WorldCat Entities record, which I simply never added.

• ↪ In the schema on another node (2)

  Wikidata lists the Instagram and Facebook accounts of Ms. Fox, my keto blog, under my record. My schema puts them on Ms. Fox as a brand (an Organization), not on me. That’s deliberate: the accounts belong to the blog. The tool flags them so you can make that call for your own data.

• + Only in the schema (9)

  Author and expert profiles: at publishers, on event and mentoring platforms, on blogs I write for. Wikidata doesn’t have to know every profile. It does know two of them, but as “described at URL” (P973), not as identifiers.

Two more lines in the result. The English version, podrez.pl/en/, shows up as “◌ Another language version” of my official website. My NUKAT record (NUKAT is a Polish union catalog) shows up as “◌ Through a Wikidata redirect,” because that property’s format points to a tool on Toolforge rather than to NUKAT itself.

None of this is an emergency. It’s a to-do list for the next time I edit my schema.

Common sameAs mistakes

• 1

  Articles in sameAs

  An interview about you is evidence, not identity. It goes in subjectOf.

• 2

  sameAs on the wrong node

  On WebPage, on WebSite or on a second copy of the person created by a plugin.

• 3

  Dead profiles

  An account you abandoned three years ago still says “this is me.” Remove it, and check whether Wikidata marks it with an end date.

• 4

  One profile, three spellings

  With and without www, with tracking parameters, a mobile m. version. Not wrong, just noise. Pick one form, ideally the one Wikidata’s format produces.

• 5

  Schema and Wikidata telling different stories

  Your site lists one Instagram account, Wikidata another. Fix the side that’s wrong, and add a source in Wikidata.

• 6

  Expecting a visible effect

  sameAs doesn’t produce a rich result. Its job is identification. Google says it can understand sameAs and url when disambiguating authors.

Should you copy everything from Wikidata into sameAs?

No. The ≈ sameAs view is a diagnostic tool, not a generator. Pick the addresses that really confirm identity: profiles you run and records in catalogs. It also works the other way around. If your schema has an important profile that Wikidata doesn’t know, consider adding it there, with a source and within Wikidata’s rules.

Want me to go through your result with you? Send me a short brief. If the entity is you, take a look at personal brand SEO.

sameAs schema: frequently asked questions