Organization Schema Markup: The Fields Google Actually Uses

Open Google's Organization structured data page and you get a list of twenty-three properties, none of them required, all of them filed under "recommended." The documentation's advice is to add the ones that apply to you. That's honest and completely unhelpful when you're staring at iso6523Code at eleven at night wondering whether skipping it costs you anything.

The short answer: which Organization fields to add

Add name, url, logo, and sameAs. Add address, telephone, and email if you have real ones you monitor. Add description, legalName, and alternateName when they're true and differ from what you already gave. Skip the registry identifiers unless a bank or regulator has already issued you one, and skip the merchant properties unless you sell products. Then put the whole thing on one page and stop thinking about it.

The rest of this post is why.

Google's own split: visible fields versus background disambiguation

The documentation makes a distinction most guides skip past. Google says some properties "are used behind the scenes to disambiguate your organization from other organizations (like iso6523 and naics), while others can influence visual elements in Search results (such as which logo is shown in Search results and your knowledge panel)."

That split is the thing to hold onto. One group can change something a human might see. The other only helps Google's index decide that the Acme on your site is the same Acme it has records for elsewhere. Both are legitimate, and they pay off on completely different timescales.

One ceiling applies to all of it. Google's stock line is that it "does not guarantee that features that consume structured data will show up in search results." Structured data only makes you eligible for a feature. Google still decides.

What each Organization property does

Sorted by what the property does rather than by how prominently Google lists it. These are the twenty-three top-level properties on Google's Organization page.

name, url, logo, and sameAs: the four that carry the weight

For most small businesses the block that earns its keep has four properties in it:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "Ridgeline Plumbing",
  "url": "https://www.ridgelineplumbing.com",
  "logo": "https://www.ridgelineplumbing.com/assets/logo-512.png",
  "sameAs": [
    "https://www.linkedin.com/company/ridgeline-plumbing",
    "https://www.yelp.com/biz/ridgeline-plumbing"
  ]
}
</script>

name and url are the identity claim. Make url the canonical home page, the one your redirects settle on, not a stray variant with or without www depending on which template rendered it.

logo is the property most likely to change something you can point at, though "most likely" is doing real work in that sentence and it still isn't a promise. Google's requirements for the image are short: at least 112 by 112 pixels, a format Google Images supports, a URL that's crawlable and indexable, and an image that "looks how you intend it to look on a purely white background." There's a fifth condition if you pass an ImageObject instead of a plain URL, which needs a valid contentUrl or url of its own. That white-background rule catches people with a white-on-transparent logo, which vanishes on the white card Google may drop it onto. The logo schema post goes deeper on the image, including the failure where the markup is perfect and the image URL is quietly blocked by robots.txt.

sameAs is the one people fill in carelessly. It's a claim that the profile at the other end is you, so a dead Twitter account from 2019 and a Facebook page nobody has posted to since the pandemic are worse than nothing. List the profiles you run. The sameAs post covers exact-URL matching and which profiles earn the line.

Contact details and address

address, telephone, and email are the second tier, and the rule for all three is the same: include them when they're real, monitored, and already public on your contact page. Markup isn't the place to debut a phone number you don't want ringing.

contactPoint looks like the more sophisticated option and mostly isn't, at least not the way Google documents it. On the Organization page it carries only its own email and telephone, so for a business with one phone number and one inbox it's a wrapper around what telephone and email already say. Use it when the contact details you want Google to surface differ from the ones on the page. Otherwise use the flat properties.

Registry identifiers you can almost certainly skip

iso6523Code, naics, duns, leiCode, and globalLocationNumber are registry identifiers. Google's expansion of Organization markup support, announced on 29 November 2023, brought most of them in, and SEO blogs have been dutifully listing them ever since as if a bakery should have a Legal Entity Identifier.

They exist for organizations that already hold these numbers because a bank or a large customer required one. A DUNS number is a nine-digit business identifier issued by Dun and Bradstreet. An LEI is a twenty-character ISO 17442 code issued through GLEIF-accredited operators, originally for financial transaction reporting. If nobody has ever asked you for one, you don't have one, and inventing one is worse than leaving the field out. Google's own note is that it encourages iso6523Code over both duns and leiCode.

vatID and taxID follow a similar rule with one wrinkle. In much of Europe, publishing a VAT number is routine and sometimes required: German businesses have to show theirs in the site Impressum where one exists, and Google's documentation calls vatID a trust signal because users can look it up in public registries. In the US there's no equivalent norm around publishing an EIN, and I'd leave it out. That's a judgment call rather than a rule anyone has written down, but the field buys you nothing in Search either way.

Merchant fields only matter if you sell products

hasMerchantReturnPolicy, hasShippingService, and hasMemberProgram are for merchants. Google's framing: "if you're a merchant, you can influence more details in your merchant knowledge panel and brand profile, such as return policy, address, and contact information." If you sell products online, these can put a return window and shipping cost on surfaces shoppers see. Google also recommends the most specific Organization subtype that fits, which for an ecommerce site means OnlineStore.

If you sell services, or nothing at all from the site, these fields do nothing. Skip them.

If you do use them, treat a stated return policy in your markup as a public promise. The number in the markup and the number on your returns page have a way of drifting apart after somebody updates one of them, so pick a single source of truth first.

description, foundingDate, and the other descriptive fields

None of these will visibly change your result. They're cheap and true, which is the only reason to bother with them.

alternateName is the one worth a second look. If people search for you as "Ridgeline" and your name is "Ridgeline Plumbing and Heating LLC," the alternate name is a real signal, and legalName earns its place for the same reason when your trading name and registered name differ.

foundingDate and numberOfEmployees are filler unless they happen to be interesting. A founding date on a business that started last March adds nothing. On a business that started in 1974, it's part of what makes you a distinguishable entity. Put in what's true and leave out what you'd have to estimate.

Put Organization markup on one page, not every page

Google recommends this "on your home page, or a single page that describes your organization, for example the about us page," and adds that "you don't need to include it on every page of your site."

The trap is that plenty of themes and SEO plugins already inject Organization markup site-wide, so a hand-written block on top gives you two Organization definitions for one business, sometimes disagreeing about the logo or the name. View source on your home page and search for "@type": "Organization" before you add anything. If a plugin is already emitting it, change the plugin's settings instead of writing a second block. The logo schema post has the specific settings for Yoast, Shopify, Squarespace, and Wix.

The same "one of them" logic applies to the type itself. LocalBusiness is a subtype of Organization and the right pick for a walk-in business, and it adds opening hours and geo-coordinates on top of what you get here. OnlineStore is the ecommerce subtype. A site declaring itself an Organization in one block and a LocalBusiness in another is describing two businesses as far as a parser is concerned.

How to validate your Organization markup

The Schema Markup Validator tells you whether the JSON-LD is well formed and whether the values are what you think, which is where you catch the trailing comma and the typo'd URL. Google's Rich Results Test tells you what Google can parse from the live page, which is where you catch the block your plugin is overwriting. If you'd rather not hand-write the block at all, the Brandize schema markup generator will build one you can paste and then validate.

Then leave it alone. Organization markup isn't something you tune weekly. It changes when your logo changes or your address moves.

Where Organization schema fits with your other head tags

This is one of a handful of things worth getting right in a small site's head, alongside your meta tags, your favicon, and your OG image. They all point at the same handful of files. The schema logo, the favicon, and the OG image are three different files at three different sizes, and the markup only works if the file behind it is the right one, which is the argument for settling your exports before you start pasting anything. What logo files a small business needs covers that list, and a Brandize brand kit produces them in one download.

If a knowledge panel is what you're chasing, the markup only makes you legible. What gets a panel built happens mostly on other sites, and how to get a Google knowledge panel covers that part.