What is Organization schema?

Organization schema is the JSON-LD entity definition for a company, institution, group, or any structured collective. It sits at the root of schema.org's hierarchy of organizational types and serves as the canonical way to declare who you are to search engines and AI systems. A correctly implemented Organization schema feeds Google's Knowledge Graph, powers logo and sitelink features on branded searches, and gives retrieval systems a verifiable identity to attach citations to.

Organization is the parent type for more specific subtypes including Corporation, LocalBusiness, NGO, EducationalOrganization, GovernmentOrganization, MedicalOrganization, NewsMediaOrganization, OnlineBusiness, and PerformingGroup. The choice between Organization and a subtype affects which rich result features the schema is eligible for.

Why this matters for AEO

Answer engines and retrieval-augmented generation systems use Organization schema to verify that a domain belongs to a known entity before citing it. When ChatGPT, Perplexity, or Google AI Overviews evaluate whether to cite a page, they check whether the publisher resolves to a recognized organization with consistent identity signals across the web. Organization schema, combined with sameAs references to LinkedIn, Crunchbase, Wikipedia, and Wikidata, gives those systems the cross-reference points they need to treat the source as authoritative rather than anonymous. Without it, a high-quality page is a string of text without a verifiable publisher behind it.

For deeper context on why structured data underpins AI search visibility, see why schema is the foundation of AEO.

Who created and maintains Organization schema

The Organization type is defined by schema.org, the joint vocabulary maintained by Google, Microsoft, Yahoo, and Yandex. Google publishes its own implementation guidance through Google Search Central documentation, which specifies how its crawler interprets Organization properties and which fields drive specific search features.

Several adjacent standards govern values used inside Organization schema:

Google's spec is more permissive than schema.org's. A valid Organization schema can pass Google's Rich Results Test while still flagging warnings on the broader Schema.org Validator. Both checks should be run before publishing.

Choosing your @type

Schema.org defines Organization as the parent class. In practice, most B2B SaaS, agencies, consulting firms, and remote-first companies use Organization directly. Use a subtype only when the more specific type accurately describes the entity.

LocalBusiness triggers a different set of expected fields (opening hours, geo coordinates, price range) and surfaces in Google's local pack. Using it incorrectly for a SaaS company tells Google to look for signals it will never find.

Field hierarchy

Schema.org documents over 150 properties on the Organization type. They fall into clear priority tiers based on impact and Google support.

Essential fields

Required for any meaningful Organization schema. Without these, the entity definition is incomplete.

Recommended fields

Add these immediately after the essential set. They strengthen entity disambiguation and rich result eligibility.

Address vs location

address accepts a single PostalAddress and describes one primary location. location accepts an array of Place objects, each with its own nested PostalAddress and name, and is the correct choice for organizations with multiple offices.

The pattern looks like this:

"location": [
  {
    "@type": "Place",
    "name": "Office A",
    "address": {
      "@type": "PostalAddress",
      "streetAddress": "...",
      "addressLocality": "...",
      "addressCountry": "..."
    }
  },
  {
    "@type": "Place",
    "name": "Office B",
    "address": { ... }
  }
]

For a company with one office, use address. For two or more, use location array. Mixing both is valid but redundant.

Disambiguation fields

Use these to give Google and AI systems unambiguous identity anchors, particularly important for B2B companies with common names or operating across jurisdictions.

Operational fields

Useful for B2B companies that want to surface service scope and team context in AI-generated answers.

Structural fields

For groups, conglomerates, and parent-child entity relationships.

Credentials and recognition

Format requirements

Organization schema is published as JSON-LD inside a <script type="application/ld+json"> block. The recommended placement is the <head> of the homepage. Google also accepts it on dedicated "about" pages, and JSON-LD anywhere in the document body is technically valid, though head placement is the most reliable for first-crawl parsing.

The @context must be https://schema.org. Mixing http:// and https:// versions of the context across pages creates inconsistency in how Google interprets the graph.

Use of the @graph wrapper is recommended when publishing multiple connected entities (Organization plus WebSite is the standard pairing). The @graph array lets entities reference each other via @id, which is how the resulting nodes get linked in Google's internal knowledge graph rather than treated as disconnected fragments. The full referencing pattern is covered in the @id referencing technique for AEO.

JSON-LD example using @graph

The recommended pattern is a single JSON-LD block combining Organization and WebSite, with the WebSite's publisher pointing to the Organization's @id. This declares the two entities as connected nodes rather than independent definitions.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://example.com/#organization",
      "name": "Example Co",
      "legalName": "Example Co, Inc.",
      "url": "https://example.com",
      "description": "Example Co builds workflow automation for revenue teams.",
      "foundingDate": "2021-03-15",
      "logo": {
        "@type": "ImageObject",
        "@id": "https://example.com/#logo",
        "url": "https://example.com/logo.png",
        "contentUrl": "https://example.com/logo.png",
        "width": 600,
        "height": 60,
        "caption": "Example Co"
      },
      "image": { "@id": "https://example.com/#logo" },
      "sameAs": [
        "https://www.linkedin.com/company/example-co",
        "https://www.crunchbase.com/organization/example-co",
        "https://x.com/exampleco",
        "https://github.com/example-co",
        "https://www.youtube.com/@exampleco"
      ],
      "contactPoint": [
        {
          "@type": "ContactPoint",
          "telephone": "+1-415-555-0100",
          "email": "sales@example.com",
          "contactType": "sales",
          "areaServed": ["US", "EU"],
          "availableLanguage": ["English"]
        },
        {
          "@type": "ContactPoint",
          "email": "support@example.com",
          "contactType": "customer support",
          "availableLanguage": ["English"]
        }
      ],
      "address": {
        "@type": "PostalAddress",
        "streetAddress": "123 Market Street, Suite 400",
        "addressLocality": "San Francisco",
        "addressRegion": "CA",
        "postalCode": "94103",
        "addressCountry": "US"
      },
      "founder": {
        "@type": "Person",
        "@id": "https://example.com/#founder",
        "name": "Jane Doe",
        "jobTitle": "CEO",
        "sameAs": [
          "https://www.linkedin.com/in/janedoe",
          "https://x.com/janedoe"
        ]
      },
      "knowsAbout": [
        "B2B SaaS",
        "Workflow automation",
        "Revenue operations"
      ]
    },
    {
      "@type": "WebSite",
      "@id": "https://example.com/#website",
      "url": "https://example.com",
      "name": "Example Co",
      "description": "Official website of Example Co.",
      "publisher": { "@id": "https://example.com/#organization" },
      "inLanguage": "en-US",
      "potentialAction": {
        "@type": "SearchAction",
        "target": {
          "@type": "EntryPoint",
          "urlTemplate": "https://example.com/search?q={search_term_string}"
        },
        "query-input": "required name=search_term_string"
      }
    }
  ]
}
</script>

@id URIs do not need to resolve to real URLs. They function as stable internal identifiers so other entities can reference them. The fragment pattern (#organization, #website, #logo) is the established convention.

Real brand example: Stripe

The schema below is Stripe's actual production Organization markup as published on stripe.com. It demonstrates several patterns worth studying for any B2B SaaS at scale.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "WebSite",
      "url": "https://stripe.com/",
      "name": "Stripe"
    },
    {
      "@type": "Organization",
      "@id": "https://stripe.com/#organization",
      "url": "https://stripe.com/",
      "name": "Stripe",
      "legalName": "Stripe, LLC",
      "founders": [
        { "@type": "Person", "name": "Patrick Collison" },
        { "@type": "Person", "name": "John Collison" }
      ],
      "description": "Stripe powers online and in-person payment processing and financial solutions for businesses of all sizes.",
      "logo": {
        "@type": "ImageObject",
        "url": "https://images.stripeassets.com/fzn2n1nzq965/1hgcBNd12BfT9VLgbId7By/01d91920114b124fb4cf6d448f9f06eb/favicon.svg"
      },
      "contactPoint": {
        "@type": "ContactPoint",
        "contactType": "customer support",
        "url": "https://support.stripe.com/",
        "availableLanguage": ["en", "es", "fr", "ja", "de"]
      },
      "sameAs": [
        "https://twitter.com/stripe",
        "https://youtube.com/@stripe",
        "https://www.linkedin.com/company/stripe/",
        "https://www.facebook.com/StripeHQ",
        "https://en.wikipedia.org/wiki/Stripe,_Inc.",
        "https://www.crunchbase.com/organization/stripe",
        "https://github.com/stripe",
        "https://www.instagram.com/stripehq/",
        "https://www.bloomberg.com/profile/company/0170016D:US",
        "https://www.wikidata.org/wiki/Q7624104"
      ],
      "location": [
        {
          "@type": "Place",
          "name": "Stripe South San Francisco",
          "address": {
            "@type": "PostalAddress",
            "streetAddress": "354 Oyster Point Blvd",
            "addressLocality": "South San Francisco",
            "addressRegion": "CA",
            "postalCode": "94080",
            "addressCountry": "US"
          }
        },
        {
          "@type": "Place",
          "name": "Stripe Dublin",
          "address": {
            "@type": "PostalAddress",
            "streetAddress": "1 Wilton Park, Wilton Place, Grand Canal Street Lower",
            "addressLocality": "Dublin 2",
            "postalCode": "D02 FX04",
            "addressCountry": "IE"
          }
        }
      ]
    }
  ]
}
</script>

Stripe's live schema includes 24 office locations in the full location array (truncated above to two). Several patterns are worth noting.

The strong patterns:

The patterns to learn from but not copy:

The takeaway: even at Stripe's scale, production schema has trade-offs and historical decisions. The patterns to copy are the comprehensive sameAs, the location array for multi-office, and the legalName precision. The patterns to improve on are the @id referencing and the current property names.

Minimal pattern for a B2B SaaS

For a single-office Series A B2B SaaS, the minimum viable Organization schema looks like this:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://yoursaas.com/#organization",
  "name": "YourSaaS",
  "legalName": "YourSaaS, Inc.",
  "url": "https://yoursaas.com",
  "description": "One-sentence positioning statement.",
  "foundingDate": "2022-01-15",
  "logo": {
    "@type": "ImageObject",
    "url": "https://yoursaas.com/logo.png",
    "width": 600,
    "height": 60
  },
  "sameAs": [
    "https://www.linkedin.com/company/yoursaas",
    "https://x.com/yoursaas",
    "https://github.com/yoursaas",
    "https://www.crunchbase.com/organization/yoursaas"
  ],
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "...",
    "addressLocality": "...",
    "addressRegion": "...",
    "postalCode": "...",
    "addressCountry": "US"
  },
  "founder": {
    "@type": "Person",
    "name": "Founder Name",
    "jobTitle": "CEO",
    "sameAs": "https://www.linkedin.com/in/foundername"
  }
}
</script>

This is the minimum recommended set: essential fields plus sameAs, legalName, foundingDate, address, and founder. Pair it with a separate WebSite schema (or wrap both in @graph) on the homepage.

How to implement in Webflow

Organization and WebSite schema describe the entity behind the entire domain. They are published site-wide.

Site-wide placement

The schema is injected into the <head> of every page on the site. Per-page schema (Article, Product, Service, BreadcrumbList, FAQPage) is added separately via page-level Custom Code or CMS Embed elements, with publisher or provider references pointing back to the site-wide Organization @id. The full pattern for connecting per-page schemas to the site-wide entity is covered in advanced Webflow AEO: mastering schema and CMS structure.

With Schema HQ

Schema HQ manages the full Organization schema across a Webflow site. The Organization values are defined once in the Schema HQ dashboard and injected into every page with correct @id referencing and the WebSite pairing handled automatically. No manual editing of JSON-LD blocks across Project Settings or per-page custom code.

Webflow-specific gotchas

Staging subdomain leakage. Webflow's default *.webflow.io staging URL is indexable unless explicitly blocked. If indexed, Organization schema is crawled from two domains with mismatched URLs, fragmenting the entity. Block staging via robots.txt or password protection before publishing schema with production URLs.

CMS field auto-encoding. Webflow can encode special characters in CMS field values (& becomes &), which invalidates JSON-LD if those fields are bound into a schema template. Hardcode Organization schema in Custom Code rather than templating it with CMS fields.

Logo asset accessibility. Webflow assets are served from uploads-ssl.webflow.com. This subdomain must remain crawlable. Blocking it via robots.txt prevents Google from fetching the logo, which causes logo features to fail in search.

Canonical domain mismatch. If the production canonical is https://www.example.com but the schema @id uses https://example.com, the two URIs identify separate entities. Match the canonical exactly, including www and trailing slash conventions.

How to validate Organization schema

Three tools cover the validation surface. Each catches a different category of problem.

Schema.org Validator

validator.schema.org checks against the full schema.org specification. It catches:

Run on raw JSON before publishing. Run again on the live URL after publishing to confirm Google's crawler receives the same payload that was authored.

Google Rich Results Test

search.google.com/test/rich-results checks eligibility for Google's rich result features. It validates:

Narrower than the Schema.org Validator but it represents Google's actual interpretation, which is the relevant test for SERP feature eligibility.

Google Search Console URL Inspection

After both validators pass, fetch the homepage via URL Inspection in Search Console, click "View Crawled Page," and confirm the JSON-LD appears in the rendered HTML. This catches cases where schema is injected by JavaScript that fails to execute under Google's renderer.

What it takes to trigger a Knowledge Panel

Schema markup alone does not produce a Google Knowledge Panel. Schema establishes eligibility. Notability and external entity coverage drive the panel itself.

Knowledge Panels appear when Google's algorithm determines an entity is well-documented and widely referenced across authoritative sources. The signals in order of weight:

The realistic ceiling for most Series A B2B SaaS companies is a strong brand SERP (logo, sitelinks, social profile linking) rather than a full Knowledge Panel. Wikidata is the most accessible path into Google's entity graph for companies that do not yet meet Wikipedia's notability bar.

Common mistakes

@id references inside @graph

❌ Broken @id references

{
  "@type": "WebSite",
  "publisher": { "@id": "https://example.com/#org" }
},
{
  "@type": "Organization",
  "@id": "https://example.com/#organization"
}

✅ Matched @id references

{
  "@type": "WebSite",
  "publisher": { "@id": "https://example.com/#organization" }
},
{
  "@type": "Organization",
  "@id": "https://example.com/#organization"
}

The reference must match the @id exactly. A mismatch produces two disconnected entities instead of one linked graph.

Logo formatting

❌ Logo as bare string with no dimensions

"logo": "https://example.com/logo.png"

✅ Logo as ImageObject with dimensions

"logo": {
  "@type": "ImageObject",
  "url": "https://example.com/logo.png",
  "contentUrl": "https://example.com/logo.png",
  "width": 600,
  "height": 60,
  "caption": "Example Co"
}

A bare URL string is valid schema but provides Google no dimension hints, which can cause logo rendering to fail. The ImageObject form is required for reliable logo display.

@type selection for B2B SaaS

❌ Wrong @type for a B2B SaaS

{
  "@type": "LocalBusiness",
  "name": "Example SaaS"
}

✅ Correct @type for a B2B SaaS

{
  "@type": "Organization",
  "name": "Example SaaS"
}

LocalBusiness triggers expectations Google looks for (geo coordinates, opening hours, price range) and surfaces in local search results, neither of which apply to a SaaS company without a physical storefront.

Founder property naming

❌ Using deprecated founders (plural)

"founders": [
  { "@type": "Person", "name": "Founder A" },
  { "@type": "Person", "name": "Founder B" }
]

✅ Using current founder (singular name, accepts array)

"founder": [
  { "@type": "Person", "name": "Founder A" },
  { "@type": "Person", "name": "Founder B" }
]

Schema.org's current property is founder. The plural founders still parses in many crawlers but is not in the current spec.

@id and canonical domain alignment

❌ Domain mismatch between @id and canonical

Canonical: https://www.example.com

{
  "@type": "Organization",
  "@id": "https://example.com/#organization",
  "url": "https://example.com"
}

✅ @id and canonical aligned

Canonical: https://www.example.com

{
  "@type": "Organization",
  "@id": "https://www.example.com/#organization",
  "url": "https://www.example.com"
}

Different domain forms create different URIs, which Google reads as different entities.

sameAs verification

❌ Inaccessible or wrong sameAs targets

"sameAs": [
  "https://twitter.com/wrong-account",
  "https://linkedin.com/in/some-random-person",
  "https://broken-url-that-404s.com"
]

✅ Verified sameAs targets

"sameAs": [
  "https://www.linkedin.com/company/example-co",
  "https://x.com/exampleco",
  "https://www.crunchbase.com/organization/example-co",
  "https://www.wikidata.org/wiki/Q12345678"
]

Every sameAs URL must resolve to a 200 status on a profile owned by the same entity. Broken or wrong-account links erode trust in the entire schema.

JSON encoding

❌ HTML entity encoding inside JSON

"name": "Example & Co"

✅ Plain text inside JSON

"name": "Example & Co"

JSON-LD does not use HTML entity escaping. Encoded characters break the JSON parser silently. Common cause: CMS auto-escaping or copy-paste from styled text editors.

Address vs location for multi-office orgs

❌ Single address for multi-office org

"address": {
  "@type": "PostalAddress",
  "streetAddress": "HQ only",
  "addressLocality": "San Francisco"
}

✅ Location array for multi-office org

"location": [
  {
    "@type": "Place",
    "name": "San Francisco HQ",
    "address": { "@type": "PostalAddress", "...": "..." }
  },
  {
    "@type": "Place",
    "name": "London Office",
    "address": { "@type": "PostalAddress", "...": "..." }
  }
]

address is for one primary location. For two or more offices, location array with Place objects is the correct pattern.

Related glossary entries

Schema HQ

Schema HQ manages Organization, WebSite, and the full graph of connected schemas across a Webflow site. Organization values are defined once in the dashboard and injected on every page with correct @id referencing, the WebSite pairing handled automatically, and no risk of drift between visible content and schema. Per-page schemas (Article, Product, FAQPage) auto-link back to the site-wide Organization entity.

FAQ

Does Organization schema need to be on every page or only the homepage?

Either is valid. Google recommends placing it on the homepage or a dedicated "about" page. Site-wide placement (via Webflow's Project Settings head code) is the most reliable pattern because it ensures the schema is parsed regardless of which page Google crawls first. Per-page schemas should reference the Organization via @id rather than duplicating the full block.

Should @id be a real URL or a fragment identifier?

A fragment identifier on the canonical domain (e.g., https://example.com/#organization) is the recommended convention. The URI must be unique and stable, but it does not need to resolve to a real page. The fragment pattern keeps the identifier scoped to the domain without requiring a dedicated URL.

Can a site have multiple Organization schemas?

A single primary Organization schema per site is standard. Multiple Organization schemas appear in valid cases like a parent company with subsidiaries (use parentOrganization and subOrganization to link them) or a publishing site with separate publisher and content-creator entities. Avoid duplicating the same Organization in multiple places on the same page.

When should I use address vs location?

Use address for organizations with a single primary location. Use location (an array of Place objects, each with its own nested PostalAddress) for organizations with multiple offices. Mixing both is valid but redundant. Stripe's production schema uses location array with 24 office Places, which is the pattern to follow for global organizations.

Does adding Organization schema improve search rankings?

No. Organization schema makes the site eligible for rich features (logo display, brand SERP, sitelinks) and strengthens entity recognition in AI search. None of these are ranking factors in the blue-link sense. The benefit is presentation quality and AEO citation reliability, not position change for unrelated queries.