Blog · Machine readability

Organization schema done properly, with a complete example

Published 1 October 2026 · Updated 8 October 2026 · 9 min read

Organization schema done properly, with a complete example
Photograph: Nina Mercado / unsplash

The short answer: Organization schema done properly is one block, on one canonical page, with a stable @id that every other node on the site points back to, a name that matches the name you use everywhere else, a url, a crawlable logo, and a sameAs array of profiles you actually control. A complete example you can copy is below. Google lists no required properties for it. That is exactly why most implementations are decorative rather than useful.

A decorative block validates and resolves nothing. A useful block gives a machine a single place to decide that the company in the footer, the company in the press release and the company in the directory listing are one entity. The gap between those two outcomes is small in bytes and large in effect.

A complete Organization example you can copy

Replace the values and keep the shape. Every property below is one Google lists as recommended on its Organization page, and none of them is required, so delete any row you cannot state truthfully about your own company.

``html <script type="application/ld+json"> { "@context": "https://schema.org", "@type": "Organization", "@id": "https://example.com/#organization", "name": "Example Ltd", "legalName": "Example Limited", "alternateName": "Example", "url": "https://example.com/", "logo": "https://example.com/assets/logo-512.png", "description": "Example Ltd builds scheduling software for independent clinics.", "foundingDate": "2016-04-11", "email": "press@example.com", "telephone": "+44-20-7946-0000", "address": { "@type": "PostalAddress", "streetAddress": "12 Example Street", "addressLocality": "Bristol", "addressRegion": "England", "postalCode": "BS1 4ST", "addressCountry": "GB" }, "contactPoint": { "@type": "ContactPoint", "contactType": "customer support", "email": "support@example.com", "telephone": "+44-20-7946-0001" }, "sameAs": [ "https://www.linkedin.com/company/example", "https://github.com/example", "https://www.youtube.com/@example" ] } </script> ``

Three notes on the values. The @id is the anchor every other node on the site points at, so it has to survive redesigns and deploys unchanged. The logo has to be a file a fetcher can actually retrieve, at 112 by 112 pixels or larger. And the sameAs entries are profiles the company can log into and correct, which is the test that keeps the array honest.

In a real page this node sits inside one @graph, in one script tag, alongside the Article or Product nodes that reference it by @id. The next three sections are about why that shape matters more than the field list does.

What the specification actually asks for

Google's Organization documentation, updated 8 September 2026, carries no required properties at all. It lists 23 top-level recommended ones, or 30 rows if you count the nested address.* and contactPoint.* entries: address, alternateName, contactPoint, description, duns, email, foundingDate, globalLocationNumber, hasMerchantReturnPolicy, hasMemberProgram, hasShippingService, iso6523Code, legalName, leiCode, logo, naics, name, numberOfEmployees, sameAs, taxID, telephone, url and vatID. Schema.org itself, at version 30.1 released 16 September 2026, defines far more.

Zero required properties is not permission to ship three fields. It is a statement that the specification cannot know which facts identify your company, so you have to decide. The honest test is not "does it validate". It is "could a stranger, holding only this block, tell my company apart from a similarly named one in another country".

Two small specifics that get missed. The logo has to be crawlable and indexable at a minimum of 112 by 112 pixels, which means a logo served from a blocked CDN path is a logo the engine never sees. And Google's own placement advice is to put the block on the home page or on a single page that describes the organisation, not on all 4,000 of them.

One block, one @id, everything else pointing at it

Here is the mechanism that separates a working implementation from a validating one. Two blocks both claiming to be the Organization, with different name values or different logos, do not announce which of them is authoritative. We have not found published documentation that says how a consumer resolves that conflict, which is the point: you are leaving the choice to a process you cannot inspect. Google's own instruction is to avoid the situation, by putting the information on the home page or on a single page that describes the organisation.

So the shape that works is a single <script type="application/ld+json"> holding one @graph. Every node inside gets an explicit @id that resolves to a fragment on your own domain, for example https://example.com/#organization. Then the Article node's publisher is not a second copy of the organisation, it is {"@id": "https://example.com/#organization"}. Same for provider on a Service node and isPartOf on a page node. One definition, many references. Google's general structured data guidelines, updated 10 July 2026, give the same instruction for separate items on one page: use @id in both so the consumer knows they are linked.

That reciprocity is the part people skip. If your product page describes a SoftwareApplication and the organisation block never claims it, you have two unconnected facts rather than one company with a product. For how the outward half of that graph works, the companion piece on sameAs and the identity links engines check covers which external profiles are worth claiming and which are noise.

The failure modes that quietly break it

These are the ones we check for first in an audit. We have not counted how often each one occurs across a sample, so read the order as the order we look, not a frequency ranking.

Markup that contradicts the page. The schema says the company was founded in 2019 and the about page says 2021. Neither fact is now trustworthy, and an engine asked "when was this founded" has a reason to hedge or to prefer a third-party source. Schema is a claim about the visible page, not a parallel universe.

Multiple plugins injecting their own Organization. A theme adds one, an SEO plugin adds another, a consent tool adds a third. All three validate. In the duplicate cases we have taken apart by hand, the Rich Results Test showed one block per type, which hid the conflict neatly. The schema.org validator at validator.schema.org shows everything parsed on the page, which is why it is the better first stop when you suspect duplication.

sameAs pointing at pages you do not control. A link to a scraped aggregator profile with the wrong headquarters city is a link that imports an error into your identity. Claimed profiles only.

The block rendered client side. Google documents that it can read JSON-LD that is injected into a page's contents by JavaScript, so for Google this case is covered. What a publisher cannot see from outside is which other fetchers execute scripts before they read, and we have no measurement of our own on that. Server rendering removes the question, which is why we treat it as the conservative default rather than as a rule anyone has published.

A logo or page behind a bot rule. This is dull and it is easy to miss. A file the fetcher cannot retrieve makes every markup refinement moot, which is why structured data for AI search argues for fixing fetchability before anyone opens a schema generator.

What it will not do

Worth being blunt, because the category oversells this. Google's documentation on AI features, last updated 10 December 2025, states plainly that there is no special schema.org structured data needed to appear in AI Overviews or AI Mode, and no new machine-readable files to create. Read that as what it says. Organization markup is not a lever that pushes you into an AI answer.

What it does is cheaper and more durable. It removes ambiguity about who you are, in a format that costs a machine nothing to parse, so that systems building or consulting an entity graph have one unambiguous record to work from. Identity resolution is upstream of being cited correctly. It is not a substitute for being worth citing.

The term work in the AI search glossary goes into why entity and ranking are different problems.

Honest limits

We have not run a controlled test isolating Organization markup from every other change on a site, and we are suspicious of anyone who claims they have, because the engines shift underneath the measurement. What this post reports from our own work is case work rather than a counted sample: we have seen engines describe a company wrongly where the block was duplicated or contradicted the page, and we have not measured how often that happens, on how many sites, or how reliably the fix changes the answer, so no figure for it appears here. The documented claims are Google's, dated in the Sources below, and we do not hold equivalent documentation from the other assistants, so where this post states a behaviour without naming a source it is describing Google. We also cannot observe which fetchers run JavaScript before reading a page, which is why server rendering is offered as a precaution and not as a measured result. That identity resolution sits upstream of being cited correctly is our working model, not something we can put a number against.

Four checks you can run this afternoon

  1. curl -s yoursite.com | grep -c 'application/ld+json'. More than one script tag

    2. is not automatically wrong, but more than one Organization node is.

  2. Paste the home page into validator.schema.org and count Organization nodes. Then count

    3. how many distinct name strings appear across them.

  3. Grep your own site for the company name and compare it, character for character, against

    4. the name in the block. Legal suffixes, ampersands and spacing all matter here.

  4. Open every sameAs URL. Any that 404, redirect to a login wall, or show stale facts

    5. comes out of the array today.

Then ask the engines directly, because the markup is a means and the answer is the outcome. The method for that lives in how to check what engines say about you. If you would rather see the finished shape of this work before doing it, the sample audit report shows how an identity finding is written up with its evidence attached.

FAQ

What does a complete Organization schema example look like? It looks like the block above: one node, one stable @id, a name, a url, a crawlable logo, a description, an address, a contactPoint and a sameAs array of profiles you control. Google lists 23 top-level recommended properties and no required ones, so the complete version is the one that states every fact you can state truthfully.

Do I need Organization schema on every page? No. Define it once, on the home page or a single page about the company, then reference it by @id from the other nodes. Repeating the full definition on every template invites the duplication problem described above.

Is LocalBusiness better than Organization? If you serve customers at a physical place, a LocalBusiness subtype carries the address and hours properties that matter for that case. It is a subtype of Organization, not a rival to it, so the identity logic is unchanged.

How many sameAs links should I include? Fewer, verified, beats more. Each entry is a claim that you are the same entity as the thing at that URL, so a wrong entry is worse than a missing one. Profiles you can log into and correct are the ones worth listing.

Does valid markup mean Google will use it? No. Validation checks syntax and types. Whether a consumer uses the data depends on eligibility rules, on whether the markup agrees with the visible page, and on whether the page is trusted at all.

Sources

Related reading

Structured data for AI search: what to mark up firstsameAs and the identity links engines checkAn AI search glossary that defines the terms properlyHow to check what engines say about you, properlyProduct schema for AI shopping answers