Organization schema: telling machines who publishes this site

sameAs is not a list of links. It is a claim that the thing at this URL and the thing described in this block are the same thing. That claim is worth something for exactly one reason: the pages at the other end are controlled by someone other than you, so they can be cross-checked, and a claim that survives a cross-check is evidence.

Which means the ordering of value is not the ordering people usually use. A Wikidata item or a Wikipedia article is the strongest thing you can put there, because both are structured, public and edited by third parties. A company profile on a professional network comes next, because it carries a registered name and a location. A dormant account you posted to twice in 2019 corroborates nothing, and nine of those do not add up to one Wikidata item.

Two things not to do with it. Do not list your own pages: your homepage belongs in url, and your about page is not a separate entity that happens to be you. And do not expect the property to produce anything on its own. Filling it in makes an identity claim machine-readable. It does not create a knowledge panel, does not add you to anyone's entity graph, and anyone promising otherwise is selling you the markup.

The mechanical part. Give the entity a stable @id, declare it once, and have every other block that needs to mention your company reference that identifier rather than restate a name. A @graph array is the tidiest way to ship it, because the site-level nodes that never change can sit together in one script tag.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://example.com/#organization",
      "name": "Northwind Analytics",
      "alternateName": "Northwind",
      "legalName": "Northwind Analytics Limited",
      "url": "https://example.com/",
      "logo": {
        "@type": "ImageObject",
        "@id": "https://example.com/#logo",
        "url": "https://example.com/img/logo-600.png",
        "width": 600,
        "height": 600,
        "caption": "Northwind Analytics"
      },
      "description": "Reporting tools for teams with too many dashboards.",
      "foundingDate": "2016-04-11",
      "sameAs": [
        "https://www.wikidata.org/wiki/Q00000000",
        "https://www.linkedin.com/company/northwind-analytics/",
        "https://github.com/northwind-analytics"
      ],
      "contactPoint": {
        "@type": "ContactPoint",
        "contactType": "customer support",
        "email": "support@example.com",
        "availableLanguage": ["en", "de"]
      }
    },
    {
      "@type": "WebSite",
      "@id": "https://example.com/#website",
      "url": "https://example.com/",
      "name": "Northwind Analytics",
      "inLanguage": "en",
      "publisher": { "@id": "https://example.com/#organization" }
    }
  ]
}
</script>

Replace that Wikidata URL or delete the line. A placeholder identifier that resolves to somebody else is worse than an absent one.

Where the block goes: on the homepage at minimum, and on every page if your layout emits it, which is fine. What matters is not how many pages carry it but that the identifier is the same string on all of them.

This is the mistake that justifies the whole page. In schema.org, LocalBusiness is a subtype of Organization, and every subtype below it, Store, Restaurant, Dentist and the rest, inherits from both. A restaurant already is an organisation as far as the vocabulary is concerned.

So shipping an Organization block and a Restaurant block for one company does not describe it twice as well. It asserts that two things exist, both named after your business, and leaves any consumer to guess which of them your articles mean when they name a publisher. The fix is to keep the specific type, move the identity properties onto it, sameAs and logo included, and delete the generic block.

The case that looks like an exception and is not: a brand with branches. One Organization for the brand, one LocalBusiness per branch, each branch pointing back at the brand through parentOrganization. That is several entities because there really are several, a company and its premises, which is a different situation from one company split across two competing blocks. Choosing the subtype and modelling the premises is a check of its own.

Indirectly, and the indirection is the point. A model answering a question about your company has to resolve the name first, and brand names collide heavily. Anything that helps the resolution land on you rather than on a homonym works in your favour, and a name with an identifier and third-party corroboration behind it is easier to resolve than a name in a footer.

Now the honest half. What does the resolving is overwhelmingly the corroboration, not the declaration. A Wikidata item, a Wikipedia article, and coverage that names you the same way twice are what a training corpus and a retrieval index actually contain. Your array of profile URLs is a pointer to that evidence, useful because it is unambiguous, and worth nothing when the evidence at the other end does not exist. Writing the markup first and the evidence never is the usual order and the wrong one.

So: ship the block, keep the identifier stable, and treat it as a description of an identity you established somewhere else. No assistant vendor documents what its retrieval stack does with an organisation block, and any figure quoted at you for it was made up.