sameAs Schema: Connect Your Business Profiles for SEO

The sameAs property is a Schema attribute that links a page's entity to a canonical reference, such as a Wikidata entry or an official social profile, so search engines can confirm it is the same real-world thing described elsewhere. It helps search engines and knowledge graphs reconcile identity across sources, and JSON-LD is the recommended format for adding it to a page.

What sameAs accepts and where it's commonly used

The sameAs property takes a URL value, and schema.org's own documentation shows it working inside nested objects, meaning it applies to nearly any Thing type, not just top-level entities. Common acceptable values include canonical URLs for official profiles, Wikidata or Wikipedia entries, and Google Knowledge Graph IDs formatted as kg:/m/xxxxxx for entities that already have an established Knowledge Graph presence.

You will see sameAs most often on:

• Organization markup on a homepage, pointing to social profiles and a Wikidata entry
• Person markup on author or team bio pages, linking to a LinkedIn profile or personal site
• LocalBusiness markup on location pages, connecting each branch to its verified Google Business Profile

A dental practice might add sameAs to its homepage Organization schema with links to its Facebook page and Wikidata listing, while an individual dentist's author page carries a separate Person entry pointing to a professional bio elsewhere. Each use case ties back to the same underlying goal: telling machines "this page and that other page describe the same entity."

How to implement sameAs in JSON-LD with practical examples

JSON-LD is the format Google recommends for structured data, and sameAs fits into it as an array of URL strings attached to the entity being described. The script belongs on the page that actually represents the entity: an Organization block on the homepage, a LocalBusiness block on each location page, and a Person block on an author or staff bio.

A homepage Organization example looks like this:

{ "@context": "https://schema.org", "@type": "Organization", "name": "Example Dental Group", "url": "https://example.com", "sameAs": [ "https://www.facebook.com/exampledental", "https://www.linkedin.com/company/exampledental", "https://www.wikidata.org/wiki/Q123456" ] }

A location page uses LocalBusiness instead, with sameAs pointing to that specific branch's verified listings rather than the brand's main social accounts:

{ "@context": "https://schema.org", "@type": "LocalBusiness", "name": "Example Dental Group - Downtown", "sameAs": [ "https://www.google.com/maps/place/?q=place_id:ChIJ..." ] }

An author or staff page follows the same logic with a Person type, linking to that individual's own professional profiles rather than the company's. The placement rule stays constant across all three: the script tag sits on the page describing that specific entity, and the sameAs values describe that entity, never a different one borrowed from a template.

Google's guidance and technical constraints for sameAs

Google's Organization structured data documentation lists sameAs as a property to include when applicable, and shows it in example markup alongside other identity fields. A few constraints shape how much that recommendation can help:

• Structured data must pass Google's general quality and spam policies before it becomes eligible for any Search feature
• Syntactically valid sameAs markup that contains misleading or spammy links can still be ignored or trigger a manual action
• Following recommended properties, including sameAs, improves the odds of being used in features Google builds around structured entity data

Google documents sameAs as a recommended property for Organization markup, though it does not publish a figure for how much it influences ranking or knowledge panel eligibility (Google Search Central). Treat it as one signal among several that help an entity get recognized correctly, not a standalone ranking lever.

Best practices and implementation checks

Getting sameAs right is less about volume and more about picking the few links that actually prove identity. Practitioner guidance from Schema App lays out a workable process:

1. Start with authoritative, stable identifiers: a Wikidata entry, verified social profiles, or a Google Knowledge Graph ID where one already exists.
2. Skip pages that merely mention the entity in passing, such as a directory listing or a news article that references it without confirming identity.
3. Favor two or three correct links over a long list of weak ones; each incorrect link dilutes the signal rather than strengthening it.
4. Re-check sameAs values periodically, since social profiles get renamed, pages get redirected, and old links quietly go stale.
5. Run markup through a validator before and after deployment to catch syntax errors that would otherwise go unnoticed for months.

Scaling caveats and contextual accuracy for templates and multi-page sites

The mistake that shows up most on larger sites is copying homepage sameAs values into a sitewide template. A link that correctly identifies the parent Organization on the homepage is often wrong on a product page, a service page, or an individual location page describing a different entity.

A few controls prevent this:

• Use entity-level data items rather than fixed template properties, so each page pulls sameAs values tied to its own entity
• Build conditional logic into templates so a LocalBusiness page only receives that location's verified listings, never the brand's corporate social accounts
• Combine automated checks with periodic human spot review, since a script can confirm valid URL syntax but cannot confirm the link still points to the right entity

Schema App's guidance on Linked Data Items addresses exactly this problem: conditional, per-page deployment keeps identity claims accurate even when hundreds of pages share a template.

NSYGHT perspective: operationalizing sameAs in an entity-first SEO stack

We treat sameAs as connective tissue in a broader entity architecture rather than a markup checkbox. Combined with our Stack approach spanning technical SEO, GEO, and AEO, correctly scoped sameAs links help AI systems and knowledge graphs resolve which business, location, or person a page actually describes. For a franchise with dozens of locations, that means building per-location entity maps before writing a single line of JSON-LD, so each branch's markup references its own verified profiles instead of a shared template. The payoff is fewer identity mismatches feeding into knowledge panels and AI-generated answers, which matters more as those surfaces pull directly from structured entity data rather than ranked blue links.

How we help you implement sameAs at scale

Getting sameAs right across dozens of locations takes more than a template with a swapped-out URL. Our entity-driven approach starts with an audit of your existing structured data, builds an entity map for every location or profile that needs its own markup, then deploys and monitors sameAs alongside the rest of your schema as part of our SEO services, including GBP Management and our SEO Foundation plan.

A typical engagement moves from audit to entity map to deployment to ongoing monitoring, so links stay accurate as profiles change. If you manage multiple locations or a franchise and want entity architecture handled for you, check our SEO Foundation and GBP Management plans to see where your sites stand today.

Frequently Asked Questions

Sources

• Schema
• Organization Schema Markup | Google Search Central
• Best Practices for Using the sameAs Property | Schema App Support

Canonical docs and tools for validation

Start with schema.org's sameAs property page for the formal definition, then review Google's Organization structured data guidance for implementation examples. For applied, industry-specific examples of entity schema in action, see this entity SEO guide for self storage operators.