What is Organization schema used for?

Organization schema is structured data that describes your company as a machine-readable entity: its name, URL, logo, contact details, profiles, and people. It gives search engines and AI systems a clean fact sheet to anchor everything else on your site to.

What properties does Organization schema need?

At minimum name, url, and logo. Google also documents administrative details it can use, including address, contactPoint, and identifiers such as a company registration number. Beyond that, sameAs is the property that does the most work for entity recognition.

Why does the @id matter so much?

The @id is a stable identifier that lets every other node on your site point to the same Organization entity instead of redefining it. That turns separate snippets of markup into one connected graph an engine can traverse, rather than several loosely related things.

Should Organization schema go on every page?

Reference the Organization by its @id on every page, but define it fully once, usually on the homepage. Other pages link to that definition through properties such as publisher or provider rather than repeating all the details.

What is sameAs in Organization schema?

sameAs lists authoritative external URLs describing the same entity, such as your LinkedIn, Wikidata, or Crunchbase pages. These verified references help systems confirm your identity and merge what they know about you into one node.

How do I validate Organization schema?

Use the Schema Markup Validator at validator.schema.org for correctness of any schema.org type, and Google's Rich Results Test for types that can produce a rich result. Always validate the rendered live URL, not just your template, since plugins and JavaScript can alter the output.

Organization Schema: Example, Template, Guide

The strongest Organization schema is not a block of markup on one page. It is a single, well-defined Organization entity with a stable @id that every other node on your site references. Done that way, your pages stop being isolated documents and become a connected graph an AI system can traverse.

Most guides give you a snippet. This one gives you the pattern, the properties that matter, a full template, and the mistakes that quietly fragment an entity.

Why one connected entity beats scattered snippets

Most sites bolt on structured data page by page: a little Article markup here, a Service block there, an Organization snippet in the footer that redefines the company from scratch each time. To a machine that looks like several loosely related things rather than one coherent brand.

AI search systems reward coherence. When your WebSite, WebPage, Service, BlogPosting, and Person nodes all point back to the same Organization entity by its identifier, the engine can follow those references and assemble a complete picture: this company publishes this content, offers these services, and employs these people. That connected picture is what makes your brand entity legible and easy to cite.

The anchor: a stable @id

The mechanism is the @id. Pick one canonical identifier for your organization, such as https://example.com/#organization, and use it everywhere. Define the Organization fully once; every other node references it by that identifier instead of describing the company again.

This does two things: it stops duplicate, slightly different definitions from fragmenting your identity, and it lets systems merge everything they learn about you into a single node.

Treat the @id as permanent. If it changes, every reference breaks and you fragment the entity you spent months building. That is also why a domain migration needs a deliberate plan, covered in the website migration SEO checklist.

The properties worth including

Property	What it holds	Priority
`@id`	Stable identifier, usually `/#organization`	Essential
`name`	Your exact, consistent brand name	Essential
`url`	Canonical homepage	Essential
`logo`	A resolvable, high-quality image URL	Essential
`sameAs`	Authoritative external profiles	High
`description`	One or two plain factual sentences	High
`foundingDate`	A specific year, as a hard fact	High
`address`	`PostalAddress`, if you have a real one	Medium
`contactPoint`	Support or sales contact details	Medium
`founder` / `employee`	References to `Person` nodes by `@id`	Medium
`identifier`	A company registration number	Optional but strong

Two notes. logo should point at an image a crawler can actually fetch, not one behind a script or a hotlink guard. And identifier is undervalued: a registration number ties you to an authoritative public record that is unambiguous by construction, which is unusually useful if your brand name is shared, as covered in entity disambiguation.

Resist stuffing the node. A lean, accurate entity beats a bloated one full of properties you cannot keep consistent, because inconsistency is what lowers confidence.

A complete connected example

One graph, one Organization definition, and other nodes referencing it by @id.

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://example.com/#organization",
      "name": "Example Agency",
      "url": "https://example.com/",
      "logo": {
        "@type": "ImageObject",
        "@id": "https://example.com/#logo",
        "url": "https://example.com/logo.png",
        "width": 512,
        "height": 512
      },
      "description": "Example Agency is a web studio in Austin, Texas, founded in 2019, specializing in technical SEO and generative engine optimization.",
      "foundingDate": "2019",
      "founder": { "@id": "https://example.com/team/jane-doe/#person" },
      "contactPoint": {
        "@type": "ContactPoint",
        "contactType": "sales",
        "email": "hello@example.com"
      },
      "sameAs": [
        "https://www.linkedin.com/company/example-agency",
        "https://www.wikidata.org/wiki/Q000000"
      ]
    },
    {
      "@type": "WebSite",
      "@id": "https://example.com/#website",
      "url": "https://example.com/",
      "name": "Example Agency",
      "publisher": { "@id": "https://example.com/#organization" }
    },
    {
      "@type": "WebPage",
      "@id": "https://example.com/services/#webpage",
      "url": "https://example.com/services/",
      "isPartOf": { "@id": "https://example.com/#website" },
      "about": { "@id": "https://example.com/#organization" }
    },
    {
      "@type": "Service",
      "@id": "https://example.com/services/geo/#service",
      "serviceType": "Generative Engine Optimization",
      "provider": { "@id": "https://example.com/#organization" }
    },
    {
      "@type": "Person",
      "@id": "https://example.com/team/jane-doe/#person",
      "name": "Jane Doe",
      "jobTitle": "Founder",
      "worksFor": { "@id": "https://example.com/#organization" },
      "sameAs": ["https://www.linkedin.com/in/janedoe/"]
    },
    {
      "@type": "BlogPosting",
      "@id": "https://example.com/blog/post/#article",
      "headline": "Organization Schema for AI Search",
      "publisher": { "@id": "https://example.com/#organization" },
      "author": { "@id": "https://example.com/team/jane-doe/#person" }
    }
  ]
}

Nothing redefines the Organization. WebSite points to it as publisher, WebPage via about, Service as provider, Person via worksFor, and BlogPosting references both by @id. That is the connected graph, and it is exactly the pattern this site uses.

Connecting people to the graph

Your authors and founders should be Person nodes with their own @id, referenced from BlogPosting.author and from the Organization’s founder. That ties expertise to content and content to the brand, which matters more as engines weigh who is behind a claim. See Person schema and author entities.

Common mistakes

Redefining the Organization on every page with slightly different values, which fragments the entity.
Changing the @id during a redesign or migration.
A sameAs list of everything. Speculative or unofficial links weaken it; see the sameAs guide.
A logo URL that does not resolve for a crawler.
Markup that contradicts the visible page, which violates Google’s structured data policies.
Using Organization where a more specific subtype fits, such as LocalBusiness for a business with a real storefront and service area.
Validating the template but never the live URL.

How to validate and maintain it

Structured data drifts as sites change. Two habits keep the graph healthy.

Validate rendered output, not your template. Check the JSON-LD that actually ships, since plugins and client-side JavaScript can alter or drop it. The Schema Markup Validator checks any schema.org type; Google’s Rich Results Test only reports on types that produce rich results, so an empty result there is not necessarily an error.

Re-check after every release. Add it to the deploy checklist in the technical SEO checklist for AI search.

The authoritative property reference is schema.org/Organization, and Google documents the administrative details it uses in its Organization structured data guide.

The Service node above is deliberately minimal. For the properties worth adding, such as areaServed, audience, and pricing, see Service schema.

Where Organization schema fits in your GEO strategy

Organization schema is plumbing for visibility. It will not write your content or earn your mentions, but without it AI systems work harder to understand you and get you wrong more often. It is the backbone that our schema markup service builds and that our GEO service relies on.

If you are not sure whether your current markup forms a connected graph or a pile of disconnected snippets, request an AI visibility audit and we will show you exactly how machines read your site today.

Organization Schema for AI Search: The Connected Graph