Organization Schema: There Are No Required Properties (and What to Add Instead)

What is Organization schema?

Organization schema is structured data describing the entity behind a website — its name, its real-world presence, its online presence, and the identifiers that distinguish it from every other business with a similar name. Google’s stated purpose for it is to disambiguate your organization in search results. And unlike most schema types, Google defines no required properties for it — the guidance is to add whichever properties actually apply to you. That is a rule about what makes the markup valid, not about what makes it useful: a node still has to carry enough applicable information to identify the organisation.

That last point is worth stopping on, because almost every Organization schema guide published leads with a table of required fields. Google’s documentation says the opposite in plain language. If you have been working from a required-properties checklist, you have been working from something that was never true.

This article is the build guide for one type. Which schema types are worth deploying at all — and which of them AI assistants appear to lean on — is a separate question, answered in structured data for AI search. What follows assumes you have already decided you want an Organization entity and want to construct it correctly.

TL;DR — Key takeaways

• Nothing is required. Google says so directly, for its own Organization implementation. Add what applies — an empty node is valid and useless.
• Properties split into two jobs: disambiguation (iso6523Code, naics) and display influence (logo, knowledge-panel elements).
• Use the most specific subtype that is genuinely true of you — OnlineStore, a LocalBusiness subtype — rather than bare Organization. Choosing a subtype can add obligations, and some subtypes are deprecated.
• One page, not every page. Home page or a single about page. Google says the rest of your site does not need it; sitewide injection is a maintenance liability rather than a violation.
• Logo rules are stricter than most people assume: 112×112px minimum, crawlable, indexable, and legible on white.
• iso6523Code with an ICD prefix is now Google’s preferred identifier over separate duns and leiCode fields.
• Google does not guarantee anything visible comes of it, and a manual action makes the markup be ignored entirely.
• There is a complete template below — copy it and delete every line that is not true of you.

There are no required properties

Google’s Organization documentation states it twice — once in the introduction and again above the property table: there are no required properties, and instead you should add as many recommended properties as apply to your page.

This is genuinely unusual. Most Google structured-data types have a required set, and violating it makes the page ineligible for a rich result. Organization does not work that way, because it is not primarily a rich-result type. Google explains the split: some properties are used behind the scenes to disambiguate the organisation — it names iso6523 and naics — while others influence visual elements, such as which logo appears in Search and in the knowledge panel.

One qualification, because “nothing is required” travels badly once it leaves the page. This is Google’s rule for Google’s Organization implementation. It is not a statement that any node validates everywhere — schema.org’s own vocabulary and third-party validators apply their own expectations — and under no reading does it mean an empty node does any work. “No required properties” answers what makes this invalid? Nothing does. It does not answer what makes this useful?, which is the question the rest of this article is about.

So the question is not “which fields must I fill in to be valid?” It is “which facts about this business are worth stating in a machine-readable way?” Those are different questions and they produce different markup.

Google’s own steer is useful here. It recommends focusing on properties that are useful to your users: the name and any alternate name, an indication of real-world presence such as an address or telephone number, and an indication of online presence such as the URL or logo.

That is a good default set, and it is short. Name, URL, logo, description, an address or phone if you have one, and sameAs links. Everything beyond that should earn its place — numberOfEmployees on a consultancy’s about page is noise; vatID on a B2B site in the EU is not.

Pick the most specific subtype, not bare Organization

Most implementations use "@type": "Organization" and stop. Google recommends against that: use the most specific schema.org subtype that matches your organisation, with OnlineStore given as the example for an ecommerce site rather than the broader OnlineBusiness.

There is an asymmetry here worth knowing before you choose. Organization itself has no required properties — but if your site is about a local business with physical premises, Google recommends the most specific LocalBusiness subtypes, which carry their own required fields on top of the Organization ones. Picking a more specific type is the right call for accuracy, and it can hand you obligations the generic type never had. That is a feature, not a trap: a more specific type is a stronger claim, and a stronger claim requires more evidence.

Bare Organization remains correct when none of the subtypes genuinely fit — a consultancy, an agency, a software company with no storefront and no physical premises open to the public. Do not reach for LocalBusiness because it sounds like it produces more results. Claiming to be a local business when you are not is inaccurate markup, and Google’s guidelines are enforceable.

There is one trap inside “most specific”: a subtype can be both more specific and deprecated. ProfessionalService is the one consultancies and agencies reach for by name, and it is a LocalBusiness subtype that schema.org deprecated because it was persistently confused with Service. It looks like the precise choice and it is two mistakes at once — an implied claim of premises open to the public, made with a type the vocabulary itself no longer recommends. Read the schema.org page for any subtype before committing to it. Deprecation is stated there, and nowhere in Google’s documentation.

One page, not every page

Google’s technical guidance is direct: put this information on your home page, or a single page that describes your organization, such as an about page — and it explicitly says you do not need to include it on every page of your site.

Read that as permission withheld, not prohibition issued. Google says you do not need to repeat it. It does not say repetition is an error, and it is worth being precise about why not: an identical node carrying the same @id on eighty pages describes one entity eighty times, not eighty entities. Nothing is duplicated in the graph.

The argument against sitewide injection — the common CMS-plugin default — is therefore architectural rather than a rule you are breaking. Eighty copies is eighty things to keep in sync, and what happens in practice is that the address changes in one place, the sameAs list grows in another, and the plugin’s default quietly disagrees with the about page. One record cannot drift from itself.

The pattern that works: one full Organization entity on one canonical page, and everywhere else that needs to reference the publisher, reference it by @id rather than restating it. Where a reference needs a label — so that a publisher or about resolves to something with a name — a stub carrying the @id, name, url and logo does that job without restating the administrative record. That keeps a single source of truth and makes the entity graph explicit instead of duplicated — which is the same discipline that makes the author side of the graph work in E-E-A-T and author entity signals.

The logo rules are stricter than people assume

logo is one of the few Organization properties with hard constraints, and each of them fails quietly. Google publishes the logo constraints:

• The image must be at least 112×112px.
• The image URL must be crawlable and indexable.
• The file format must be supported by Google Images.
• It must look how you intend on a purely white background — Google specifically warns that a mostly-white or grey logo may not.

The second one catches people most often. A logo served from an asset host that is blocked in robots.txt, or sitting behind a noindex, cannot be used no matter how correct the markup is — the same class of problem as anything else that is served but never indexed. Check the image URL the way you would check a page.

The fourth is the one nobody tests. If your brand mark is white with a transparent background, it renders as nothing on the white surfaces Google puts it on. That is not a markup error and no validator will flag it.

If you use the ImageObject type rather than a plain URL, the ImageObject alternative must carry a valid contentUrl or url following the same rules.

The identifiers that do disambiguation work

This is the part almost no guide covers, and it is where the disambiguation actually happens.

iso6523Code is now the preferred identifier. Google encourages iso6523Code over the separate duns and leiCode fields. The format is an ICD prefix, a colon, then the identifier. The common ICD values Google lists are 0060 for a Dun & Bradstreet DUNS number, 0088 for a GS1 Global Location Number, and 0199 for a Legal Entity Identifier. So an LEI becomes "iso6523Code": "0199:724500PMK2A2M1SQQ228".

If you already emit duns or leiCode, this is a small, high-value change — you are moving from a field Google says it would rather you replaced to the one it prefers.

vatID is a user-facing trust signal. Google describes it as an important trust signal for users on the grounds that people can look the business up in public VAT registries. For a European B2B company this is one of the cheapest credibility signals available, and virtually nobody emits it.

name and alternateName should match your site name. Google says to use the same name and alternateName that you’re using for your site name.

That does not strand your registered company name. Google lists legalName for precisely this case — the registered, legal name of the organisation where it differs from the name it trades under — so a business that calls itself Acme states both, on one entity:

{
  "@type": "Organization",
  "name": "Acme",
  "legalName": "Acme Software Ltd"
}

Two names, one organisation, and the relationship between them stated rather than left to be inferred. The failure mode is not having a registered name. It is putting the registered name in name while the site title, the logo and every inbound link call the business something else, with nothing in the markup reconciling the two.

sameAs is external corroboration. It takes URLs of pages on other websites carrying additional information about the organisation, and you can provide several. This is the property that connects your assertion to independently verifiable profiles, which is the same mechanism that underpins entity confidence in topical authority. Point it at profiles that genuinely describe the same entity and that you control or are named on — not at every social account that exists.

The complete template

Everything above is a rule. This is the shape those rules produce — a full Organization node for a SaaS company or a consultancy, on the one page that carries it.

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://example.com/#organization",
  "name": "Acme",
  "legalName": "Acme Software Ltd",
  "alternateName": "Acme Software",
  "url": "https://example.com/",
  "description": "Acme builds deployment tooling for engineering teams.",
  "logo": {
    "@type": "ImageObject",
    "@id": "https://example.com/#logo",
    "url": "https://example.com/assets/logo.png",
    "contentUrl": "https://example.com/assets/logo.png",
    "width": 512,
    "height": 512
  },
  "email": "hello@example.com",
  "telephone": "+44-20-7946-0000",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "12 Example Street",
    "addressLocality": "London",
    "postalCode": "EC1A 1BB",
    "addressCountry": "GB"
  },
  "vatID": "GB123456789",
  "iso6523Code": "0199:724500PMK2A2M1SQQ228",
  "foundingDate": "2016-03-01",
  "numberOfEmployees": {
    "@type": "QuantitativeValue",
    "value": 24
  },
  "sameAs": [
    "https://www.linkedin.com/company/acme",
    "https://github.com/acme",
    "https://www.crunchbase.com/organization/acme"
  ]
}

Use it by deleting, not by filling in. Every line that is not true of your organisation comes out — no telephone number you do not answer, no address that is a registered-agent mailbox, no LEI you do not hold. That is the entire method, and it is why the “no required properties” rule is a gift rather than a gap: nothing here obliges you to invent a fact to satisfy a validator.

Three substitutions to make as you go. Ecommerce sites change "@type" to "OnlineStore", which is the subtype Google names for them. Businesses with premises open to the public use the appropriate LocalBusiness subtype instead and take on its required fields. And @id should be a URL fragment on your own canonical home page — the value itself is arbitrary, but it must be stable, because every other node on the site refers to the organisation by it.

Property priority: what to add first

If the template is more than you want to deploy at once, the properties sort into three tiers by what each one buys.

Tier	Properties	What it does
Core — do these first	name, url, logo, description	States who the entity is and gives Google the logo it may use in Search and the knowledge panel. This is Google’s own “useful to your users” set.
Identity — the disambiguation layer	alternateName, legalName, sameAs, address, telephone, email	Separates you from every similarly named business: the names you are known by, external profiles that corroborate the claim, and evidence of real-world presence.
Situational — only if they apply	iso6523Code, vatID, taxID, naics, foundingDate, numberOfEmployees, contactPoint, parentOrganization / subOrganization	Registry-grade identifiers and structural facts. High value where they are true — iso6523Code and vatID especially for B2B — and noise where they are approximated.

The tiers are a deployment order, not a quality ranking. A three-person consultancy that ships the core tier honestly has better markup than a company that pads all three with guesses.

Before and after

The realistic starting point is not an empty page. It is markup that a plugin generated years ago and nobody has read since:

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "Acme Software Ltd",
  "url": "https://example.com",
  "logo": "https://example.com/logo.png",
  "duns": "150483782",
  "leiCode": "724500PMK2A2M1SQQ228"
}

Nothing there is invalid. Every line is also doing less than it could:

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://example.com/#organization",
  "name": "Acme",
  "legalName": "Acme Software Ltd",
  "url": "https://example.com/",
  "logo": {
    "@type": "ImageObject",
    "url": "https://example.com/assets/logo.png",
    "contentUrl": "https://example.com/assets/logo.png",
    "width": 512,
    "height": 512
  },
  "iso6523Code": "0199:724500PMK2A2M1SQQ228",
  "vatID": "GB123456789",
  "sameAs": [
    "https://www.linkedin.com/company/acme",
    "https://github.com/acme"
  ]
}

Five changes, each with a reason:

• name split into name + legalName. The site, the logo and the inbound links all say Acme. The registered name is still stated, in the property built for it.
• duns and leiCode replaced by iso6523Code. Google encourages the combined form over the separate fields. The LEI keeps its value, prefixed with the 0199 ICD.
• A plain logo URL became an ImageObject. Same image, but the node now carries contentUrl and dimensions, which is what makes the 112×112 minimum checkable rather than assumed.
• sameAs added. The first property in the node that points at something Google can verify independently of the site making the claim.
• vatID added, @id added. One is a public-registry trust signal on a B2B entity; the other is what lets every other page reference this organisation instead of restating it.

What did not change: no address was invented, no employee count estimated, no social profile added that does not describe this company. The improvement came from stating known facts more precisely, which is the only kind of improvement this markup type offers.

Validating what you shipped

Organization markup fails quietly, so validation is not optional and the usual tool does not tell you what people assume it does.

1. Run the Schema Markup Validator first. It answers the question you actually have at this stage — does the JSON-LD parse, are the types and properties real — without reference to any one search engine’s features.
2. Then the Rich Results Test, on the live URL rather than pasted code. URL mode tests what Google actually fetches and renders, which is the only version that matters if your markup is injected client-side. Because Organization is largely not a rich-result type, do not read a short list of detected features there as a failure.
3. Check the logo URL like a page. Request it directly: does robots.txt allow it, does it return an X-Robots-Tag: noindex, is it at least 112×112, and does it read correctly on a white background? Four separate failure modes, none of which any validator reports.
4. Confirm the node exists once, on the page you intended. View the rendered HTML of your home page and of a random article. One should carry the full entity; the other should carry a reference to it, or nothing.
5. Watch the Unparsable structured data report in Search Console. It is the only place a syntax regression introduced by a later deploy will surface on its own, and it surfaces late.

Then re-check on a cadence rather than at launch, because none of what breaks here produces an error.

What it will not do

Two limits, both stated by Google, and both worth setting expectations against before anyone asks why the knowledge panel has not changed.

Nothing is guaranteed. Google does not guarantee that features that consume structured data will show up in search results. Correct markup makes you eligible for a set of behaviours. It does not purchase them. This is the same expectation-setting that applies across rich results generally, and it is the honest framing to give a stakeholder.

Inaccurate markup can be worse than none. Google warns that violating the structured-data guidelines may trigger a manual action, and that when a structured-data manual action is applied, the structured data on the page is ignored — the page can still rank, but the markup stops doing anything. So an Organization block claiming a physical address the business does not have, or a LocalBusiness type it does not qualify for, is not a harmless exaggeration. It is a route to having all your markup discounted.

Markup describes reality. It does not create it. The other types in this cluster follow the same rule — breadcrumb and FAQ schema both fail in exactly this way when they describe something the page does not contain — and the construction detail for the types that do produce visible results is in creating rich snippets with JSON-LD.

Whatever you deploy, re-check it on a cadence rather than at launch. Entities drift: sameAs URLs move, addresses change, legal names change at incorporation events. A quarterly sweep inside the recurring technical SEO audit catches that; nothing else will, because none of it produces an error.

Frequently asked questions

Which Organization schema properties are required?

None. Google’s documentation states there are no required properties for its Organization implementation and recommends adding whichever recommended properties apply to your organisation. Guides that publish a required-fields table for this type are wrong. That is a rule about validity, not usefulness — an empty node passes and does nothing. A sensible default set is name, URL, logo, description, sameAs, and an address or telephone number if you have one.

Where should Organization schema go?

On your home page, or on a single page that describes the organisation such as an about page. Google explicitly says it does not need to be on every page. Reference it by @id from elsewhere instead of repeating it sitewide.

Should I use Organization or LocalBusiness?

Use the most specific subtype that genuinely matches. LocalBusiness subtypes are for businesses with physical premises, and they bring their own required and recommended fields in addition to the Organization ones. If you have no premises open to the public, bare Organization — or a subtype like OnlineStore for ecommerce — is the accurate choice.

Does Organization schema produce a rich result?

Not in the way Product or Review markup does. Google frames it as helping disambiguate your organisation, with some properties influencing visual elements such as which logo is shown in Search and in the knowledge panel. Treat it as entity clarification, not as a SERP feature you are buying.

What size does the logo need to be?

At least 112×112px. The URL must also be crawlable and indexable, the format must be one Google Images supports, and the image must look as intended on a purely white background — which is the constraint that quietly breaks white or very light logos.

How many sameAs links should I include?

As many as genuinely describe the same entity. There is no stated limit. The value is corroboration, so a handful of authoritative profiles that clearly refer to your organisation is worth more than an exhaustive list of every account anyone ever registered.

Can name and legalName be different?

Yes, and they often should be. Google lists legalName for the registered, legal name of the organisation where it differs from the name it trades under, while name should match the site name you use everywhere else. A company trading as Acme with Acme Software Ltd on the register states "name": "Acme" and "legalName": "Acme Software Ltd" on the same node — one entity, two names, the relationship made explicit.

How do I validate Organization schema?

Start with the Schema Markup Validator to confirm the JSON-LD parses and the properties are real, then run the Rich Results Test against the live URL rather than pasted code so you are testing what Google fetches and renders. Neither checks the logo, so request that URL yourself: crawlable, indexable, at least 112×112, legible on white. Search Console’s Unparsable structured data report catches regressions introduced by later deploys.

Does Organization schema help with AI search visibility?

It contributes to a clear, machine-readable entity, which is the same thing publisher identity depends on. But no assistant documents how it consumes Organization markup, and there is no measurement to point at, so anyone promising a citation uplift from it is guessing. What can be said about schema and AI citations is in the structured data for AI search guide linked above.