What Belongs in sameAs Schema, and What Google Ignores

sameAs is the schema property people add last and think about least. It is a list of URLs. There is no syntax to get wrong, no nesting to reason about, and no validator warning if you fill it with garbage. Which is exactly why most of the sameAs blocks on the web are doing no work at all.

The property has one job, and understanding that job tells you immediately which links belong in it. This article covers what sameAs is actually for, which links carry weight, which ones Google discards without comment, and where the property belongs in a site that already has the rest of its schema types in place.

The schema.org definition is one sentence: a URL of a reference web page that unambiguously indicates the item identity. The load-bearing word is unambiguously. Everything useful about the property follows from it.

Search engines do not just index pages. They maintain a model of entities, distinct things in the world, and the relationships between them. Your business is an entity. The pages on your site are documents that describe it. Those are separate objects in the index, and connecting them correctly is not automatic.

When a crawler encounters a page for a company called Meridian Consulting, it faces a resolution problem. There are hundreds of businesses called Meridian something. Is this the one in Ohio, the one in Manchester, or a new one nobody has seen? The page itself cannot settle that, because every one of those companies has a page that looks structurally identical.

sameAs settles it. It says: this specific entity is also the one represented at these specific external addresses. If those addresses are places where identity is verified, the ambiguity collapses.

Once you accept that the property exists to resolve ambiguity, a useful test falls out of it. For every URL you are considering, ask: does this link reduce the number of things I could be?

A LinkedIn company page with your address, employee count, and an actual posting history reduces it dramatically. A Facebook page created in 2014, never posted to, with no address and a stock cover photo reduces it slightly. A link to your own contact page reduces it not at all, because every one of those hundreds of Meridians has a contact page too.

This is also why sameAs matters more the more generic your name is. A company called Hyperlocal Fabrication Systems has almost no disambiguation problem. A company called Coastal Dental has a severe one, and every link that resolves it is worth adding.

The same logic applies to people. If you publish under a byline and want that byline associated with a real professional identity rather than treated as an unverifiable name on a page, sameAs on a Person entity is the mechanism. This is a meaningful piece of the experience and expertise signals search engines look for, which we cover in more depth in the SEO checklist.

Ranked roughly by how much resolution they provide, these are the categories worth including.

Structured knowledge bases. Wikidata and Wikipedia sit at the top because they are editorially reviewed, carry stable identifiers, and are already used as canonical entity references. If you have an entry, it is the single strongest link you can list. Most small businesses will not qualify, and that is fine.

Verified professional and business profiles. LinkedIn company pages, Crunchbase entries, and industry registries or licensing bodies. These involve some level of account ownership or third-party listing, which is what makes them evidence rather than assertion.

Actively maintained social profiles. The platform accounts you genuinely run and that genuinely link back to your site. Facebook, Instagram, X, YouTube, TikTok. The value is in the reciprocal link and the ongoing activity, not in the platform name.

Authoritative directory listings. For a local business, well-established directories carrying consistent name, address, and phone data. These overlap with citation building, and consistency across them is the thing that matters, which is why we treat it as part of local SEO rather than a schema task.

Here is what a clean Organization block looks like once you have picked the right links. Note that the @id gives the entity a permanent internal handle, and url stays separate from sameAs.

Five links. Every one of them controlled by the business, every one of them pointing back. That is a complete sameAs block for the overwhelming majority of companies, and adding another ten would not improve it.

Nothing in the validators will flag any of the following. They pass, they render, and they accomplish nothing.

• Your own pages. A sameAs entry pointing at your about page, your homepage, or a subdomain you own. Self-reference is not corroboration. Use url and @id for this.
• Profiles that do not link back. A one-way claim cannot be verified. Worse, if the profile belongs to a different company with a similar name, you have actively told a search engine you are them.
• Dead and abandoned accounts. A profile with no posts since 2019, no bio, and a placeholder avatar corroborates almost nothing. It is not harmful, it is just filler.
• Aggregator pages you never claimed. Scraped listing sites that auto-generate a page for every business in a zip code. Anyone can appear there, so appearing there proves nothing about identity.
• Your Google Business Profile share link. This one surprises people. Google already knows the relationship between your site and your profile through the profile itself, and the shortened share URLs are not stable references. Verify the website field inside the profile instead.
• URLs that redirect or 404. Platforms rename, businesses rebrand, handles get released. A sameAs array is one of the least-audited parts of a site, so broken entries sit there for years.
• Personal profiles under an Organization entity. The founder personal LinkedIn is not the company. That link belongs on a Person entity, and the two can be connected properly with founder or employee.

None of these will get you penalized. The cost is opportunity cost: a property that could have resolved your identity is instead a list nobody can act on.

Declare the entity once. Reference it everywhere else. This is the pattern that trips up more sites than any syntax question.

Your canonical Organization or LocalBusiness block, carrying the full sameAs array, lives on your homepage with a stable @id. Every other page on the site that needs to refer to your organization, and that includes every BlogPosting publisher field and every WebPage, points at that id rather than restating the whole thing.

Two things are happening there. The publisher is a pointer, not a copy, so the sameAs array exists in exactly one place on the site. And the author carries its own separate sameAs, because a person is a different entity from a company and their verifying links are different.

The failure mode of ignoring this is not dramatic. It is drift. Six months later the company changes its X handle, someone updates the homepage block, and 140 blog posts still carry the old URL in a duplicated array nobody remembers exists.

sameAs is available on Thing, which means it is available on every type in the vocabulary. In practice three matter.

Organization gets the company-level links: the LinkedIn company page, the brand social accounts, the Crunchbase entry, the industry body. This is your primary block.

LocalBusiness inherits from Organization, so everything above applies, plus the directory listings that carry your address. For a business competing in a map pack, consistency between these links and the name, address, and phone data on your profile is doing real work. That relationship is the subject of our piece on why you rank at your office and nowhere else.

Person gets professional profiles, publication pages, speaker bios, and credentialing bodies. If you have named authors on your content, giving each one a Person entity with real sameAs links is one of the cheapest ways to make authorship checkable rather than claimed.

Beyond those three, sameAs shows up usefully on Product when the same product has a manufacturer page or a standard identifier elsewhere, and on Place for venues with an established external reference.

Here is the claim you will see repeated on a hundred blogs: add sameAs and you will get a knowledge panel. It is not true, and believing it leads people to stuff the array and then conclude schema does not work.

Knowledge panels are produced when Google is confident an entity exists, is distinct, and is notable enough that people search for it directly. That confidence is assembled from corroborating references across the whole open web: news coverage, third-party listings, official registries, consistent mentions. sameAs contributes by making your claimed identity explicit and machine-checkable. It is an input, not a trigger.

What sameAs realistically improves, once a panel already exists, is accuracy. The social profile links that appear in a panel, and the correctness of which entity the panel is attached to, are exactly the sort of thing an unambiguous identity claim helps with.

If you want a panel, the work is earning the corroboration, not editing JSON. Getting your markup right just makes sure that when the corroboration arrives, nothing on your side is muddying it.

Traditional search could get away with fuzzy entity resolution. A results page shows ten links and the human sorts it out. Generative systems cannot do that, because they have to commit to a single answer.

When an assistant is asked about a company by name, it has to decide which company. If your markup makes that decision easy and your competitor markup does not, you are the one that gets described. If the decision is hard, the safe behavior is to say less about you, or to conflate you with a better-defined entity that shares your name.

This is the practical reason to bother with a property that has no visible output and no rich result attached. The payoff is not a star rating in a listing. It is being resolvable at a moment when a system has to pick exactly one thing you could be. We go further into how this changes content and markup priorities in our AI SEO training.

• Writing sameAs as a string when it should be an array. A single URL as a bare string is technically valid, but the moment you add a second one without brackets the block breaks. Use an array from the start even for one link.
• Duplicating the array on every page. Covered above. One canonical block, referenced by @id.
• Mixing entity levels. Personal profiles inside the Organization array, or the company page inside a Person array. Each entity gets its own links.
• Listing a profile you do not control. Especially a fan page, an unclaimed aggregator listing, or a similarly named account. This is the one failure that actively misinforms rather than merely wasting space.
• Injecting it client-side and assuming it lands. Markup added by a tag manager requires the page to be rendered before it is seen. It usually works, but it is slower and harder to debug than putting it in the server-rendered source.
• Never auditing it again. sameAs arrays rot. Set a reminder to check the links resolve whenever you do a broader site audit.

Validation tools will confirm your syntax parses. They will not tell you whether your links mean anything, so the check has two halves.

The machine half. Run the page through the Schema Markup Validator to confirm the block parses and the property is attached to the entity you intended. Google Rich Results Test is the second pass, though be aware it only reports on features that produce a rich result, and sameAs does not, so a clean report there is not evidence your array is good.

The human half. Open every URL in the array. For each one, confirm three things: it loads without redirecting somewhere unexpected, it is unmistakably you, and it links back to your website. Any URL that fails one of those comes out. This takes about four minutes and is the only part of the process that actually improves anything.

If you want the full sequence for finding markup problems across a site rather than a single page, that lives in technical SEO, alongside the crawl and indexation work that has to be right first.