The sameAs Property: How to Fill It In Properly and Why It Matters More Than You Think

The sameAs property in schema markup is an array of URLs pointing to other authoritative pages about the same entity, and its job is to let a machine confirm that the business on your website and the business in a directory, a profile or a knowledge base are one thing rather than several. It does more work for AI visibility than almost any other single property, and most implementations of it are either empty or padded with the wrong links.

If you fix one piece of structured data this month, fix this one.

The problem sameAs solves

A model trying to answer "who is the best orthodontist in Houston" has to do something harder than ranking. It has to decide which of the businesses it knows about are real, distinct, and verifiable.

Your business appears in a lot of places. Your website. Google Business Profile. Yelp. An industry directory. LinkedIn. A chamber of commerce listing. A trade association page. Each of those is a separate document with a separate description of you.

Without an explicit connection, a machine has to infer that they all refer to the same entity. It does that by comparing names, addresses and phone numbers, and inference is fragile. "Smith & Associates LLC" on your site and "Smith and Associates" on Yelp and "Smith Associates Law" on LinkedIn are three strings. If your address format differs too, the confidence drops further.

Low confidence has a specific consequence. Models are cautious about naming businesses they cannot verify, and caution shows up as omission. You do not get named as a maybe. You get left out.

sameAs replaces inference with a declaration. You are telling the machine directly: these URLs are me.

What it looks like

{
  "@context": "https://schema.org",
  "@type": "LocalBusiness",
  "name": "Riverside Dental Care",
  "url": "https://riversidedental.com",
  "telephone": "+1-713-555-0142",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "1420 Westheimer Rd",
    "addressLocality": "Houston",
    "addressRegion": "TX",
    "postalCode": "77006",
    "addressCountry": "US"
  },
  "sameAs": [
    "https://www.google.com/maps/place/?q=place_id:ChIJ...",
    "https://www.yelp.com/biz/riverside-dental-care-houston",
    "https://www.linkedin.com/company/riverside-dental-care",
    "https://www.facebook.com/riversidedentalhouston",
    "https://www.healthgrades.com/group/riverside-dental-care"
  ]
}

Five URLs. Every one verified, live, and describing the same business under the same name. That is a complete implementation for a local business, and it beats a list of twenty unverified links.

The full definition lives at schema.org/sameAs, and Google's structured data documentation covers how it fits into the wider markup.

Which URLs to include

Order matters less than quality, but there is a rough hierarchy of usefulness.

Highest value. Wikipedia and Wikidata entries if you have them. Wikipedia is disproportionately represented in AI citations, and a Wikidata entry is a machine readable identity record built for exactly this purpose. Most small businesses do not qualify for either, and you should not attempt to create a Wikipedia page you do not merit.

High value. Your Google Business Profile, your primary industry directory, and any regulator or licensing body listing you. For a healthcare practice that is an NPI record or a hospital affiliation page. For a law firm it is a state bar listing. For a home services business it is a licensing board. These carry weight because they represent verification by a third party with a reason to be accurate.

Solid value. LinkedIn company page, Crunchbase, Better Business Bureau, chamber of commerce, established review platforms in your category.

Useful for a personal brand. For a Person entity, LinkedIn is close to mandatory, plus any platform where you publish under your own name.

Include social profiles only if they are active. A dormant account with two posts from 2019 is a page describing a business that appears inactive. That is not a signal you want to strengthen.

What not to include

Anything you do not control or cannot verify. A scraped aggregator listing with wrong hours is a page you are now vouching for.

Pages that describe something else. A parent company page, a franchise network page, or a page covering multiple locations when your markup describes one. This actively creates the ambiguity sameAs exists to remove.

Broken or redirecting URLs. Check every entry. A 404 in your sameAs array is a failed verification attempt.

Your own pages. sameAs is for external references. Use url for your own site and internal linking for your own pages.

Volume for its own sake. Twenty links, half of them unverified, is worse than five that all check out. The array is a set of claims, and every claim that fails weakens the ones that hold.

The mistake that undoes all of it

sameAs only works if the pages it points at agree with each other.

If your schema says "Riverside Dental Care" and your Yelp page says "Riverside Dental" and your LinkedIn says "Riverside Dental Group," you have used sameAs to formally connect three inconsistent records. You have made the problem legible rather than solving it.

Before you build the array, run a consistency pass. Open every profile you intend to list and check four things against your markup:

1. Business name, character for character, including punctuation, & versus and, and legal suffixes like LLC or Inc.
2. Address format, including whether you write Suite, Ste or #.
3. Phone number, same digits, and ideally the same formatting.
4. Primary category, because a business listed as a dentist in one place and a cosmetic surgeon in another is genuinely harder to resolve.

Fix the profiles first. Then write the array. Doing it the other way around gets you a well formed piece of markup that confirms you are unreliable.

This is unglamorous work, and it is the highest return hour available to most businesses in this field.

sameAs for a Person

If you run a personal brand, a consultancy, or you work in a credential driven field, add a Person entity alongside your organization and give it its own sameAs array.

{
  "@context": "https://schema.org",
  "@type": "Person",
  "name": "Dr Elena Marsh",
  "jobTitle": "Orthodontist",
  "worksFor": {
    "@type": "LocalBusiness",
    "name": "Riverside Dental Care"
  },
  "sameAs": [
    "https://www.linkedin.com/in/elenamarsh",
    "https://www.healthgrades.com/dentist/dr-elena-marsh",
    "https://npiregistry.cms.hhs.gov/provider-view/..."
  ]
}

This matters more than it used to. Models asked for a recommendation in a professional services category increasingly name individuals rather than firms, because an individual with verifiable credentials is easier to stand behind than a company name. If the person behind your business is the reason clients choose it, make that person an entity a machine can resolve.

How to know whether it worked

sameAs is not a ranking factor with a dial you can watch. What you are looking for is a change in how confidently a model describes you.

Run the same prompt in a fresh session before you make the change and again four to six weeks after. Pay attention to the description rather than the position. Hedged language, a wrong category, a merged description that blends you with another business, or a flat omission are all signs of an unresolved entity. A clean, correct, specific description is the outcome.

Validate the markup itself with Google's Rich Results Test and the Schema.org validator before you ship it. Malformed JSON-LD is silently ignored, and a property that never parsed cannot have worked.

Then leave it alone and let the rest of the web catch up. Entity signals compound slowly, over months rather than weeks, because they depend on the pages you pointed at being re-crawled and the connections being reinforced elsewhere.