sameAs, and the entity you forgot to declare.

A spot-check of 100 mid-market Shopify storefronts in May 2026 found that 71 of them ship no `sameAs` declaration anywhere in their schema. Of the 29 that do, 18 declare a single URL (almost always LinkedIn). Three declare more than four. None of the 100 declares a Wikidata entry. The property has been in the Schema.org vocabulary since 2013 and is, by a comfortable margin, the cheapest high-leverage line of code in technical SEO. Almost nobody ships it.

The omission was forgivable in 2019. It was a quiet missed opportunity in 2022. In 2026, with Perplexity, ChatGPT, Claude, and Google's AI Mode all attempting to disambiguate brand entities from sparse signals on the page, it is the difference between being recognised and being a string of characters that an answer engine cannot resolve.

The `sameAs` property, on an `Organization` schema block, is a list of URLs that point at other web identities for the same entity. Wikidata. Wikipedia. Crunchbase. LinkedIn. The brand's verified accounts on Twitter, Instagram, YouTube, GitHub, TikTok. A Trustpilot or Google Business page where the brand exists as a reviewed entity. Each URL is a node on the entity graph. The list, taken together, is a declaration: I am the same legal and commercial entity referenced at all of these other places, by these other publishers, under these other identifiers.

For Google, `sameAs` has been part of the Knowledge Graph signal stack since 2014. The mechanism is well-documented in the Search Central reference. The property tells the indexer "the entity on this page is the same entity at these other URLs," and the indexer uses the cross-references to consolidate signal, resolve ambiguous brand names, and decide which of three candidate entities a search query was probably about.

For an AI answer engine, the property does something narrower and more useful. When Perplexity sees a sentence in a review that mentions "Glossier," and is deciding whether to cite a product page from glossier.com, it has to confirm that this is the right Glossier. It will follow `sameAs` from glossier.com to the Wikidata entry for Glossier, see that the Wikidata entry matches the same business, and treat the page as a confirmed source about the same entity. Without `sameAs`, the engine is doing this work by name match alone, which is a weaker signal that fails for any brand with an ambiguous name.

Brands with ambiguous names are not rare. Most three-syllable English words are also brand names. Most short pronounceable invented words are claimed three times over. The brand named "Field" is a furniture brand, an outdoor brand, a notebook brand, and an agency. Without explicit entity declaration, an answer engine guesses. The guess will sometimes be wrong, and the citation will sometimes go to a competitor.

The objection most operators raise, the first time `sameAs` is explained to them, is "I don't have a Wikidata page." This is a real constraint. Wikidata pages are not self-served; they are created by Wikidata editors, usually because the entity has independent third-party coverage that satisfies notability standards. A two-year-old DTC skincare brand will not have one. Most small brands will not have one.

The playbook for a brand in that position starts with what already exists. The minimum viable `sameAs` block uses only properties the brand already controls or appears in. Walked from cheapest to most useful:

The brand's verified LinkedIn company page. This exists for almost any commercial entity that has hired one employee through LinkedIn. Free, two minutes to confirm the URL.

The brand's verified Instagram handle. Same. Most DTC brands had this before they had a website.

The brand's verified X (Twitter) handle, if active. If the account has been dormant since 2022, list it anyway; the entity declaration is what matters, not the engagement rate.

The brand's Crunchbase page, if any. Crunchbase auto-generates entries for any company that has appeared in funding press, and most small brands that have raised a seed round have one whether they know it or not. Worth a search.

The brand's Trustpilot, Google Business, or Yelp page, if any. These are third-party-controlled review pages for the entity, and they double as both `sameAs` declarations and as the only legitimate way to surface aggregate brand review signal under Google's self-serving policy. See self serving review markup and the line google drew for the policy detail.

The brand's GitHub organisation, if the company ships code under a recognisable handle. Useful for tech-adjacent brands; useless for a candle company.

The brand's BBB profile, in the US. Higher trust signal than its reputation suggests, and almost free to claim.

The brand's verified YouTube channel, if the brand uploads video. A single uploaded video is enough.

That list, for a typical small brand, produces three to seven URLs. Three is the floor. Seven is plenty. The shape of the block, in production:

```json { "@context": "https://schema.org", "@type": "Organization", "name": "Brand Name", "url": "https://www.brandname.com", "logo": "https://www.brandname.com/logo.png", "sameAs": [ "https://www.linkedin.com/company/brandname", "https://www.instagram.com/brandname", "https://twitter.com/brandname", "https://www.crunchbase.com/organization/brandname", "https://www.trustpilot.com/review/brandname.com", "https://www.youtube.com/@brandname" ] } ```

Six lines inside a single property. Ships once, in the head of every page or on a single canonical entity page (about, contact, or the homepage). Costs nothing. Lasts indefinitely.

The change is not a ranking jump. Operators expecting one will be disappointed. `sameAs` is not a query-level relevance signal; it is an entity-level resolution signal. Its job is to make sure that, when the engine decides to use you, it knows it is using you.

The change is downstream and quiet. Branded search results consolidate. Knowledge panels, where the brand is large enough to earn one, start to pull the right logo and the right description. AI answer engines, asked about the brand by name, get the correct entity on the first attempt and stop fishing for a clarifying signal that does not exist on the page.

The harder-to-measure change is that the brand stops losing citations to competitors with similar names. This is invisible in aggregate. The brand never sees the citation that did not go to them. The only way to detect it is to ask a few answer engines, by name, about the brand and watch what happens. Brands with a clean `sameAs` declaration get the right facts back. Brands without one sometimes get a competitor's facts, attributed by the engine to them, with no way to correct it.

Most technical SEO improvements involve trade-offs. Faster page load means stripping features. Better schema means engineering time on every product page. Internal linking changes upset existing IA. Even building backlinks involves outreach, content, and budget.

Entity declaration involves none of that. It is one block of code, shipped once, that almost never needs to change. The URLs in it do not depend on a roadmap. They do not require a designer. They do not affect Core Web Vitals. They do not require a CMS migration. The whole intervention can be done in an afternoon by anyone with FTP access or a developer who can edit the theme.

The leverage comes from where it sits in the pipeline. Almost every other technical SEO move (better titles, better schema, better internal links) acts on a single page or a single query. Entity declaration acts on the brand as a whole, at the input layer to every answer engine that processes your domain. The block is read once and used in every downstream decision the engine makes about you.

The cheapest line of code in technical SEO is the one that tells an answer engine which company you are. Most brands have not shipped it. The ones that have, ship it first.

The honest assessment, for any brand large enough to consider it, is that a Wikidata entry is the single best entry in the `sameAs` block, and it is also the entry the brand has the least control over. Wikidata items are created by editors, often automatically from Wikipedia, sometimes manually by an editor who finds the brand notable enough. There is no submission form, no review queue, no commercial path to creation.

Brands that find themselves with a Wikidata item, often discovered by accident, should claim it and check it for accuracy. The item will have a Q-identifier (Q123456 style). It is then trivial to add the Wikidata URL to the `sameAs` block, which closes the loop: the brand's site declares Wikidata as its entity, Wikidata's structured data confirms the same entity, and the answer engine has a closed reference graph it can trust. This is the gold standard.

For brands without a Wikidata entry, the playbook is to ship the other six URLs now, and revisit Wikidata in a year or two if the brand grows into press coverage that earns notability. The omission is not fatal. It is just a ceiling. (For the broader argument about how engines read these signals, see the engine the answer engine reads.)

The audit, for any brand reading this, is short. Open the homepage. View source. Search for `sameAs`. If the property exists with three or more URLs, the basic entity declaration is in place; the question is only whether the URLs are still accurate (LinkedIn page still active, Twitter handle not parked). If the property does not exist, or exists with a single URL, the work is the rest of the afternoon.

The block belongs in the canonical Organization schema, on the homepage or on a single about page. Shipping it on every page is fine but unnecessary; one declaration is enough as long as it lives at a URL the engine will crawl.

Most stores will not do this. They will continue to optimise the things that are loud (titles, hero copy, A/B tests on the buy button) and ignore the thing that is quiet. The competitive position, for the store that ships the two-line block, is that the engine knows which one they are. The engine does not know which the others are. (See also the citation economy for what that distinction is worth.)

For most of the history of the open web, the question of who a brand was had a simple answer: the brand was the domain. Type the domain, get the brand. The conflation worked because the user was the one resolving the entity, and the user did the resolution in their head before they typed.

The answer engines do the resolution differently. They start with a name and try to find the right domain. The name is sometimes ambiguous. The domain is sometimes wrong. The engine, in the absence of an explicit declaration, guesses, and the guess is sometimes a competitor. The two-line addition to one schema block, shipped once, removes the guess. It is the cheapest, quietest piece of work a brand can do this year, and it is the piece that almost no brand has done. The point of the work, like most of the work that matters in this period, is to give the engine fewer reasons to use somebody else's sentences when it could be using yours. (the citation economy | what the search engine became)