Organization schema and sameAs: making your entity legible

Organization schema is a block of JSON-LD that states, in machine-readable form, which organization a website belongs to: its name, its home URL, its logo, its contact details, and, through sameAs, the other places on the web that describe the same organization. It does not make anything cite you. What it does is remove a guess. A crawler that reads “Acme” on your pricing page, “Acme Robotics Inc.” in your footer, and “acme_robotics” on a social profile has to decide whether those are one entity or three. Organization markup with sameAs answers that question on your terms.

This post covers what the markup is, what Google documents about it, what belongs in sameAs and what doesn’t, why the whole site should describe one entity with one identifier, and how to audit it by hand and at scale. It sits under Citability and entity signals: a GEO guide, which covers the wider set of signals entity markup belongs to.

What is Organization schema?

Organization schema is the schema.org Organization type, or one of its subtypes, expressed as structured data on your site. In practice that means a <script type="application/ld+json"> block in the HTML of your home page or about page that names the organization and lists its identifying properties.

The properties that carry the most weight for entity clarity are few:

What does Google say Organization markup does?

Google describes Organization markup as a way to help it understand an organization’s administrative details and tell it apart from others in search results. Some properties influence visible elements such as the logo shown in results and the knowledge panel; others, such as iso6523Code and naics, are used behind the scenes.

Four details from Google’s documentation shape how you write it:

• There are no required properties. Google’s page says so directly and recommends adding every property that applies.
• One page is enough. Google says to put it on the home page or on a single page that describes the organization, such as an about page. It is not needed on every page.
• The logo has rules. The image must be at least 112×112 px, the URL must be crawlable and indexable, the format must be one Google Images supports, and Google suggests checking that it looks right on a white background.
• Use the most specific subtype. An online store should use OnlineStore rather than the generic type; a restaurant or physical shop should use the most specific LocalBusiness subtype and follow Google’s local business guidance as well.

None of that is a statement about AI answers. Google’s own guidance on AI features says no special schema is needed to appear in AI Overviews or AI Mode, and that structured data should match the visible text on the page. Organization markup belongs in a GEO audit because it states identity unambiguously, not because any vendor documents it as a ranking or citation input.

What belongs in sameAs?

sameAs belongs to pages that are unambiguously about your organization and nobody else. schema.org defines it as the “URL of a reference Web page that unambiguously indicates the item’s identity,” and gives a Wikipedia page, a Wikidata entry, or an official website as examples. Google describes it as a URL of another website’s page with more information about the organization, such as a social media or review profile.

That definition gives you a three-question test for each candidate URL:

1. Is the page about this entity, and only this entity? Your company page on a professional network passes. A directory listing that bundles you with competitors does not.
2. Is it official or authoritative? An account you control, or a reference entry such as Wikidata, passes. A fan page, an unclaimed scraped profile, or a review aggregator listing you have never seen is weaker evidence.
3. Does it resolve, and does it agree? The URL should return a 200, not a login wall or a 404, and the name, URL, and logo on it should match what your markup states. A profile that links back to your domain closes the loop.

A short list of correct URLs is better than a long list of approximate ones. Five accounts you control and keep current say more than twenty that include a dormant profile with an old name and a dead link.

Two common mistakes. First, putting your own site’s pages in sameAs: your about page is not another web page describing you, and the url property already covers your site. Second, listing a person’s profile in the organization’s sameAs. The founder’s account describes the founder; it belongs in that person’s Person markup, which Author bylines and Person schema covers.

Why one entity, with one @id?

Because a site that describes its own organization three different ways gives a parser three candidates and no way to choose. This happens more often than it should: a CMS theme emits one Organization block, an SEO plugin emits another, and a hand-written Article block names a publisher with a third spelling.

The fix is a single node with a stable @id, defined once and referenced everywhere else. The @id is conventionally your home URL plus a fragment. Here is a minimal example for the fictional Acme Robotics site used in our demo crawls; the profile URLs are illustrative.

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://acme-robotics.example/#organization",
  "name": "Acme Robotics",
  "alternateName": "Acme",
  "url": "https://acme-robotics.example/",
  "logo": {
    "@type": "ImageObject",
    "url": "https://acme-robotics.example/assets/acme-logo-512.png",
    "width": 512,
    "height": 512
  },
  "sameAs": [
    "https://www.wikidata.org/wiki/Q00000000",
    "https://www.linkedin.com/company/acme-robotics-example/",
    "https://github.com/acme-robotics-example",
    "https://www.youtube.com/@acmerobotics-example"
  ],
  "contactPoint": {
    "@type": "ContactPoint",
    "contactType": "sales",
    "email": "sales@acme-robotics.example"
  }
}

Every other block then points at that node instead of redefining it. An article’s publisher becomes "publisher": { "@id": "https://acme-robotics.example/#organization" }, and so does the publisher of a WebSite block. One definition, one name, and nothing for a parser to reconcile.

How consistent does the name have to be?

Exactly consistent, in the places that describe the site as a whole. Google’s site names documentation is the clearest statement of this: it reads WebSite structured data on the home page, but also considers og:site_name, the <title>, headings, and other home page text, and it recommends using the same name everywhere on the home page.

The same discipline applies to the organization. Pick the canonical form of the name, then check it in every place that states it:

Address consistency matters most for local businesses, where a different suite number or an old phone number on a directory is a second entity in waiting. Treat the contact page as part of this audit, not a separate one.

How do you check it on one page?

Open view-source: on your home page and search for application/ld+json. Count how many blocks declare "@type": "Organization" or a subtype. More than one is the first finding.

Then:

1. Validate it. Paste the URL into Google’s Rich Results Test or the Schema Markup Validator at validator.schema.org. A block that fails to parse states nothing.
2. Open the logo URL. Confirm it returns an image, not a redirect to a CDN error, and that it meets the 112×112 px minimum.
3. Open every sameAs URL. Note the status, the name shown on the profile, and whether the profile links back to your domain. Any profile that 404s, redirects to a login, or shows a former name gets fixed or removed.
4. Compare the name strings in the table above. Differences in capitalization or a dropped “Inc.” are worth one decision, written down, and applied everywhere.

This takes about twenty minutes and covers the one page where the markup matters most.

How do you check it across a site?

Across a site, the question changes from “is it correct?” to “how many versions of the organization does this site describe?” A crawler with custom extraction answers it without a terminal. Add rules that run against the page source:

• A regex count of "@type"\s*:\s*"Organization" per URL, to find templates that emit their own block.
• A regex extraction of the publisher name, for example "publisher"\s*:\s*\{[^}]*"name"\s*:\s*"([^"]+)", to find the spellings articles carry.
• An XPath extraction of //meta[@property='og:site_name']/@content.

Export to a spreadsheet. A pivot on the publisher-name column shows every variant the site uses, with a count. A =COUNTIF(B:B, ">1") on the Organization-count column finds pages where two blocks compete. If a plugin is the source, the fix is a template setting, not a page edit.

From a terminal, the same count for one URL:

curl -s "https://example.com/" | grep -o '"@type"[[:space:]]*:[[:space:]]*"Organization"' | wc -l

Run it over a URL list to produce the same column.

How GEOBee reads entity clarity

GEOBee scores Entity clarity as a GEO-lens signal worth 15 of 100: it checks for Organization or Person schema with sameAs links. A second GEO signal, Trust (10), includes valid schema alongside HTTPS and a visible way to make contact. Both are listed with every other weight in the three lenses, and the grid’s Schema column shows the detected type per URL, or None, Invalid, or Partial when the markup is missing or incomplete.

What GEOBee does not do is open your sameAs URLs and judge whether the profiles behind them agree with you. That part of the audit stays manual, which is why the twenty-minute check above is worth repeating whenever the company renames a product, changes an address, or retires an account. What makes a page citable covers the page-level signals that sit beside entity clarity, and Freshness signals and honest dateModified covers the other GEO signal most often broken by templates.

To see which of your templates carry Organization markup and which emit a second copy, download GEOBee and crawl the site during the 7-day trial.