Most structured data earns you something visible on a specific page, stars on a product, a recipe card, a breadcrumb trail. Organization schema mostly doesn't. It has exactly one direct visual output, and the rest of its value is invisible: it tells search engines who you are as an entity, so that everything else they know about you attaches to the right thing.
That makes it easy to skip and easy to implement badly. It's also the layer everything else rests on, particularly as search systems increasingly reason about entities rather than pages.
What Google actually says
Worth starting here, because it contradicts a lot of published advice.
Google's Organization documentation states that there are no required properties. Instead, Google recommends adding as many properties as are relevant to your organization. Some of those properties influence visual elements, which logo appears in Search and your knowledge panel. Others work behind the scenes purely to disambiguate you from other organizations.
You'll see guides asserting that name is required and that logo or image is required. That reflects what validators flag when checking eligibility for the logo rich result specifically, not a general requirement of the type. The distinction matters: Organization markup isn't a pass/fail checklist, it's a description that gets more useful the more complete and accurate it is.
Google also expanded its support for Organization properties in late 2023. Before that, Logo was effectively the only Organization rich result; since then, more properties feed knowledge panels and other visual elements.
The foundation
Three properties everything else builds on:
{
"@context": "https://schema.org",
"@type": "Organization",
"@id": "https://example.com/#organization",
"name": "Example Corporation",
"url": "https://example.com"
}The @id is the important one and the most commonly omitted. It's an internal node identifier that lets every other schema block on your site reference this same organization without duplicating it. The convention is your homepage URL plus a fragment.
Without it, an article's publisher, a product's brand, and a location's parentOrganization each describe a separate organization that happens to share a name. With it, they're all pointing at one entity. That's the difference between a graph and a pile of disconnected assertions.
Logo: the one visual output
logo is what influences which image appears in Search results and your knowledge panel. Practical requirements:
- Hosted on your own domain, not a CDN you don't control or a third-party host
- Crawlable and indexable, check it isn't blocked in robots.txt, which is a surprisingly common own-goal
- A standard format (JPG, PNG, SVG)
- At least 112×112 pixels, and larger is better for high-resolution displays
The robots.txt point deserves emphasis. Sites that block their /assets/ or /images/ directory sometimes block the logo they're asking Google to display. If Google can't fetch it, the property does nothing.
sameAs: the property doing the real work
If @id connects your schema internally, sameAs connects you to the rest of the web. It's an array of URLs pointing at other authoritative representations of the same entity:
"sameAs": [ "https://www.linkedin.com/company/example", "https://github.com/example", "https://www.crunchbase.com/organization/example", "https://en.wikipedia.org/wiki/Example_Corporation", "https://www.wikidata.org/wiki/Q12345678" ]
Why this matters: search engines need to resolve "Example Corporation," the string on your site, to a specific entity, distinguishing you from every other business with a similar name. sameAs is you explicitly stating which profiles across the web are also you.
A few practical rules:
Link profiles you actually control and that actually exist. Fabricated or dead links are worse than fewer links.
Prioritize authoritative and structured sources. Wikidata and Wikipedia entries, if you have them, carry disproportionate weight because they're machine-readable entity databases in their own right. LinkedIn, Crunchbase, and industry-specific directories follow.
Make the profiles consistent. If your sameAs points at a LinkedIn page with a different company name, different logo, and different description, you've connected two things that don't obviously match. Consistency across your name, logo, and description on every linked profile is what makes the connection convincing rather than confusing.
It's not a link-building tactic. sameAs links don't pass authority in the way backlinks do. The value is disambiguation, not ranking.
The identifiers most sites skip
Google's documentation notes that some properties exist specifically to disambiguate your organization behind the scenes rather than to display anything. These are the ones almost nobody implements:
"iso6523Code": "0199:724500PMK2A2M1SQQ228", "naics": "541511", "duns": "150483782", "leiCode": "724500PMK2A2M1SQQ228", "taxID": "12-3456789", "vatID": "GB123456789"
You won't have all of these and you shouldn't invent any. But if your organization has a DUNS number, an LEI, a VAT registration, or a NAICS classification, including them gives search engines externally verifiable identifiers rather than relying on name matching. For businesses with common or generic names, this is genuinely useful.
legalName is worth adding too when your trading name differs from your registered one, it's a fact about you that prose rarely states unambiguously.
Relationships build the graph
Entities gain meaning from their connections. Organization schema supports several:
"founder": {
"@type": "Person",
"@id": "https://example.com/about/jane-doe#person",
"name": "Jane Doe",
"sameAs": ["https://www.linkedin.com/in/janedoe"]
},
"foundingDate": "2015-03-01",
"parentOrganization": { "@id": "https://parent-co.com/#organization" },
"subOrganization": [
{ "@id": "https://example.com/locations/austin#business" }
],
"numberOfEmployees": {
"@type": "QuantitativeValue",
"value": 45
}founder and employee linking to Person entities with their own sameAs links is how you build author and executive authority alongside brand authority. parentOrganization and subOrganization express corporate structure, essential for multi-location businesses and franchises, which we cover in the multi-location schema guide.
Each of these adds an edge to the graph. Collectively they make your organization harder to confuse with anything else.
Contact points
contactPoint makes your support channels machine-readable, and it supports more nuance than a single phone number:
"contactPoint": [
{
"@type": "ContactPoint",
"telephone": "+1-512-555-0142",
"contactType": "customer support",
"areaServed": "US",
"availableLanguage": ["English", "Spanish"]
},
{
"@type": "ContactPoint",
"email": "press@example.com",
"contactType": "press"
}
]Separating support, sales, press, and technical contacts is more accurate than collapsing them, and areaServed plus availableLanguage are genuinely useful for international organizations.
Merchant properties
If you sell online, Organization markup does more than identity work. Google notes that merchants can influence details in their merchant knowledge panel and brand profile, including return policy, address, and contact information.
This connects to a change worth knowing about: Google now supports organization-level shipping and return policy structured data, so a store with one consistent policy can state it once at the organization level rather than repeating it on every product page. We covered the implementation detail in the Product schema guide.
For a store, that makes Organization markup part of your commerce setup rather than just branding.
The publisher pattern
The most practically useful thing about a stable @id is that it turns your Organization into something referenceable.
Define the organization once, typically in your site's root layout or homepage. Then every article references it:
{
"@type": "BlogPosting",
"headline": "...",
"publisher": { "@id": "https://example.com/#organization" }
}Not a duplicated organization object on every post, a reference. Fifty articles then reinforce one entity instead of describing fifty near-identical ones. The same pattern applies to brand on products and parentOrganization on location pages.
This is the single highest-leverage structural decision in the whole type, and it costs nothing beyond deciding on the identifier. Our docs walk through wiring up this reference pattern site-wide.
A complete example
Putting the pieces together, a realistic Organization block for a mid-sized company:
{
"@context": "https://schema.org",
"@type": "Organization",
"@id": "https://example.com/#organization",
"name": "Example Corporation",
"legalName": "Example Corporation Ltd",
"url": "https://example.com",
"logo": {
"@type": "ImageObject",
"url": "https://example.com/logo.png",
"width": 512,
"height": 512
},
"description": "Example Corporation builds inventory software for independent retailers.",
"foundingDate": "2015-03-01",
"founder": {
"@type": "Person",
"@id": "https://example.com/about/jane-doe#person",
"name": "Jane Doe",
"sameAs": ["https://www.linkedin.com/in/janedoe"]
},
"address": {
"@type": "PostalAddress",
"streetAddress": "40 Bridge Street",
"addressLocality": "Manchester",
"postalCode": "M3 3BT",
"addressCountry": "GB"
},
"contactPoint": [
{
"@type": "ContactPoint",
"telephone": "+44-161-555-0142",
"contactType": "customer support",
"areaServed": "GB",
"availableLanguage": ["English"]
}
],
"vatID": "GB123456789",
"sameAs": [
"https://www.linkedin.com/company/example",
"https://github.com/example",
"https://www.crunchbase.com/organization/example"
]
}Note logo as a full ImageObject with dimensions rather than a bare URL, both are valid, but the object form lets you state the dimensions explicitly. Everything here is a fact that could be verified independently, which is the standard to hold yourself to.
WebSite schema: the natural companion
Organization describes the company. WebSite describes the site, and the two are commonly implemented together:
{
"@context": "https://schema.org",
"@type": "WebSite",
"@id": "https://example.com/#website",
"url": "https://example.com",
"name": "Example Corporation",
"publisher": { "@id": "https://example.com/#organization" }
}Again, publisher is a reference rather than a duplicate. One thing worth knowing: the potentialAction / SearchAction property associated with WebSite was used for the Sitelinks Search Box, which Google retired. The markup remains valid and harmless, but it no longer produces the search field it was designed for, another case where a feature ended while the vocabulary stayed put.
Knowledge Panels: honest expectations
Organization markup is frequently sold as the route to a Knowledge Panel. Some realism is warranted.
Markup doesn't generate a panel. Google builds knowledge panels from many sources, Wikipedia, Wikidata, trusted third-party references, and its own entity understanding. Your structured data contributes and can influence what's shown, but publishing Organization schema doesn't produce a panel on its own.
It isn't fast. Entity recognition develops over months, not days. Published timelines vary widely and none are authoritative, but nobody credible suggests this is a same-week change. Treat it as infrastructure, not a campaign.
Notability still matters. Entities with substantial independent coverage get panels more readily. Structured data helps Google understand an entity it already has reason to recognize; it doesn't manufacture recognition from nothing.
What you can influence is accuracy. If a panel exists or emerges, complete and consistent Organization markup shapes which logo appears, which profiles are associated, and how your details are represented. That's a real benefit, and it's the honest version of the pitch.
Be sceptical of anyone quoting precise panel timelines or success rates, the numbers in circulation vary wildly and none trace to a verifiable methodology.
Where to put it
Homepage or About page, defined once. These are the pages that describe the organization, and Google's documentation points at the home page specifically.
Referenced everywhere else by @id rather than repeated. A full Organization object on every page describes many organizations; a reference describes one.
For a business with a physical location customers visit, note that LocalBusiness is a subtype of Organization, you generally want the location-level markup on location pages and the brand-level Organization at the top, related through parentOrganization and subOrganization.
Auditing what's already there
Most established sites already have some Organization markup, often from a plugin or a theme, and often incomplete. Before adding anything, find out what you have.
Check for multiple conflicting blocks. A theme, an SEO plugin, and a hand-added script can each emit their own Organization object. Three blocks describing your company with slightly different names, logos, or URLs is worse than one complete block. View source on your homepage and search for "@type": "Organization", more than one occurrence needs resolving.
Verify the logo actually loads. Open the URL in the markup directly. Broken logo URLs survive for years because nothing visibly breaks on the page.
Test every sameAs link. Profiles get deleted, companies rename their handles, and platforms change URL structures. A sameAs array assembled three years ago typically has at least one dead entry.
Compare against the profiles you link to. Does the name in your markup match the name on your LinkedIn page? Is the logo the same one? Small inconsistencies accumulated through a rebrand are common and quietly undermine the connection you're trying to assert.
Check who's listed. Founders who left, addresses you've moved out of, and phone numbers that no longer route anywhere are the most common stale facts.
This audit takes under an hour on most sites and typically surfaces at least one real problem. It's also worth repeating after any rebrand, office move, or leadership change, the moments when Organization markup reliably goes out of date and nobody thinks to update it.
Common mistakes
No @id, so nothing on the site can reference the organization cleanly.
Duplicating the full object on every page instead of referencing it.
Logo blocked in robots.txt or hosted off-domain.
sameAs pointing at dead, wrong, or fabricated profiles.
Inconsistent branding between your markup and the profiles it links to, different name, logo, or description.
Using Organization where LocalBusiness fits, or vice versa. If customers visit a physical location, use the LocalBusiness subtype.
Inventing identifiers. Don't put a DUNS number or LEI you don't have.
Stale data. Organization markup written at launch and never revisited, old address, former CEO as founder, discontinued phone number.
Treating it as a Knowledge Panel button. It's entity infrastructure; panels depend on much more.
Why this matters more than it used to
Organization schema has always been reasonable practice. The reason it's worth prioritizing now is that search systems increasingly reason about entities rather than keyword-matching strings.
When a system tries to answer a question involving your company, what you do, whether you're credible, how you compare, it needs to resolve you to a specific entity and attach what it knows to that entity. Every sameAs link, every stable identifier, every relationship you declare makes that resolution more reliable.
The honest limit, as always: Google states no special structured data is required for its AI features, and no markup guarantees you'll be represented accurately or cited. What clean Organization markup does is remove ambiguity about who you are. That's a prerequisite for being understood correctly, not a guarantee of being chosen. Our post on schema and AI Overviews sets out where that line sits.
If you do one thing with this post: define your Organization once with a stable @id, add honest sameAs links to profiles you actually control, and reference it from everything else. That's most of the value for a fraction of the effort, and it's the same entity-graph wiring built into every pricing tier here.
Frequently Asked Questions
AI Schema Gen generates Organization markup with proper entity identifiers and relationship references, across 530+ schema types. Start free or browse the schema types directory.
Generate perfect schema in 30 seconds
AI Schema Gen handles everything automatically, free to start.
Get Started Free