Organization vs LocalBusiness Schema: Which to Use

Ask which schema type your business needs and you will get one of two answers. Either "use LocalBusiness, you're a local business," or "use Organization for your brand and LocalBusiness for your location." The first is often right by accident. The second creates a problem on a large number of the sites that follow it.

The question is almost always asked as a choice between two types. It isn't one, and there is a single fact in the schema.org vocabulary that explains why. Once you know it, the decision takes about thirty seconds, the "use both" advice stops making sense for most sites, and you also discover that plenty of businesses need neither type.

The fact that answers the question

Nearly every schema.org type has one parent. Article sits under CreativeWork. Product sits under Thing. You can trace a single line upward and that is the whole story.

LocalBusiness has two parents.

Open schema.org's LocalBusiness page and you will see two separate chains at the top:

A LocalBusiness is an Organization and it is a Place. Not one or the other, not a cousin of either. Both, at the same time. Schema.org defines it as "a particular physical business or branch of an organization," and that phrasing carries the same double meaning: a business (the company) that is physical (the place).

This is why the "Organization vs LocalBusiness" framing falls apart. The two are not alternatives sitting side by side. One contains the other. Asking whether to use Organization or LocalBusiness is a bit like asking whether to describe something as a vehicle or as a car. Every car is already a vehicle. Saying "car" does not mean you have given up on "vehicle," it means you have said something more specific.

The practical version: anything you can say with Organization, you can say with LocalBusiness. A LocalBusiness node accepts founder, legalName, sameAs, contactPoint, vatID, parentOrganization, and every other Organization property, because it is an Organization. It just also accepts the properties that only make sense for somewhere on a map.

It goes deeper than two paths

The specific business types go further still. Dentist is a subtype of LocalBusiness, and schema.org lists five separate chains reaching it:

Thing > Organization > LocalBusiness > Dentist
Thing > Organization > LocalBusiness > MedicalBusiness > Dentist
Thing > Organization > MedicalOrganization > Dentist
Thing > Place > LocalBusiness > Dentist
Thing > Place > LocalBusiness > MedicalBusiness > Dentist

A dental practice marked up as Dentist is simultaneously an Organization, a Place, a LocalBusiness, a MedicalBusiness and a MedicalOrganization. You get all five sets of properties from one @type. This is worth knowing because it kills a common worry: people pick generic LocalBusiness over Dentist because they are afraid the specific type will "lose" the general properties. It cannot. Specific types only ever add.

Where each property actually comes from

The dual parentage is not trivia. It explains which properties are available and, more usefully, which ones are quietly wrong for your business.

Here is where the common properties are actually defined:

Two things fall out of this table.

First, the Place side is the part you can get wrong. geo and openingHoursSpecification are defined on Place, full stop. They are not Organization properties. If your business has no premises a customer can walk into, there is no place to put coordinates on and no door to state opening hours for. Reaching for LocalBusiness so you can use those properties, then filling them with your registered office or your home address, is how markup ends up describing something that does not exist.

Second, LocalBusiness adds surprisingly little of its own. Strip out what it inherits and the type contributes openingHours, priceRange, paymentAccepted, currenciesAccepted and floorLevel. Everything else you think of as "local business markup," including the address and the phone number, comes from one of the two parents. The type is mostly a junction where two existing sets of properties meet.

So should you use both? Usually not

Here is where the popular advice does real damage. A lot of guides tell you to publish an Organization block for your brand and a LocalBusiness block for your location, on the same single-location site. Follow that and you now have two entities on the web where your business is one.

Google's own documentation points the other way, in both directions. From the LocalBusiness guide:

since LocalBusiness is a subtype of Organization, we recommend following the fields for Organization in addition to the fields required and recommended below

And from the Organization guide, pointing back:

if your site is about a local business, for example a restaurant or a physical store, then we recommend providing your administrative details using the most specific subtype(s) of LocalBusiness ... in addition to the fields recommended in this guide

Read those together and the instruction is the same from both pages: one node, carrying both sets of properties. Not two nodes describing the same business twice. Google is telling you to take the Organization fields and put them on your LocalBusiness, because your LocalBusiness is an Organization.

The same guide is also clear that Organization has no required fields at all: "There are no required properties; instead, we recommend adding as many properties that are relevant to your organization." So there is nothing you are obliged to publish separately. There is no minimum Organization block you have to add on the side.

What a split entity looks like

When a single business gets described twice, this is the shape:

{
  "@type": "Organization",
  "@id": "https://example.com/#organization",
  "name": "Bright Smile Dental",
  "url": "https://example.com",
  "logo": "https://example.com/logo.png",
  "sameAs": ["https://www.linkedin.com/company/brightsmile"]
}

{
  "@type": "Dentist",
  "@id": "https://example.com/#localbusiness",
  "name": "Bright Smile Dental",
  "address": { "...": "..." },
  "telephone": "+1-512-555-0142",
  "openingHoursSpecification": [ "..." ]
}

Two identifiers. Two names that happen to match. No relationship stated between them. Nothing in the markup says these are the same company, so anything reading it has to guess, and the identity signals split across two half-descriptions instead of accumulating on one complete one. The social profiles attach to a node with no address. The address attaches to a node with no social profiles.

For a single-location business, the fix is to delete one of them and merge the properties:

{
  "@context": "https://schema.org",
  "@type": "Dentist",
  "@id": "https://example.com/#business",
  "name": "Bright Smile Dental",
  "legalName": "Bright Smile Dental LLC",
  "url": "https://example.com",
  "logo": "https://example.com/logo.png",
  "telephone": "+1-512-555-0142",
  "priceRange": "$$",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "1200 South Lamar Blvd",
    "addressLocality": "Austin",
    "addressRegion": "TX",
    "postalCode": "78704",
    "addressCountry": "US"
  },
  "geo": {
    "@type": "GeoCoordinates",
    "latitude": 30.2545,
    "longitude": -97.7688
  },
  "openingHoursSpecification": [
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"],
      "opens": "08:00",
      "closes": "17:00"
    }
  ],
  "founder": {
    "@type": "Person",
    "name": "Dr. Elena Reyes"
  },
  "sameAs": ["https://www.linkedin.com/company/brightsmile"]
}

One identifier, one entity, Organization properties and Place properties living together on the node that is entitled to both. This is what Google's two guides are jointly describing.

Where the split usually comes from

Almost nobody sets out to publish two competing descriptions of their own company. On WordPress it typically arrives on its own: a general SEO plugin emits an Organization block from its brand or "knowledge graph" settings, a local SEO plugin or a theme emits a LocalBusiness block from a different settings screen, and neither knows the other exists. Both are doing exactly what they were configured to do.

The symptom is easy to check and covered in more detail in our guide to common schema errors: view source on your homepage, search for "@type", and count how many blocks describe your company. More than one, with different identifiers and no relationship between them, is the problem in this section.

The choice was never between two types

The other thing the hierarchy reveals: LocalBusiness is one of twenty direct subtypes of Organization. The other nineteen are Airline, Consortium, Cooperative, Corporation, EducationalOrganization, FundingScheme, GovernmentOrganization, LibrarySystem, MedicalOrganization, NGO, NewsMediaOrganization, OnlineBusiness, PerformingGroup, PoliticalParty, Project, ResearchOrganization, SearchRescueOrganization, SportsOrganization and WorkersUnion.

If you have been choosing between exactly two options, you have been picking from a list of twenty while looking at two of them. Several of the others describe real businesses far better than either.

Online-only businesses have their own branch. Schema.org defines OnlineBusiness as "a particular online business, either standalone or the online part of a broader organization," with examples including an eCommerce site, an online travel booking site and an online learning site. Underneath it sits OnlineStore, defined simply as "an eCommerce site." For a shop with no premises, OnlineStore says what you are far more precisely than generic Organization, and far more honestly than LocalBusiness.

One caveat worth stating plainly: both terms carry schema.org's note that they are "in the 'new' area," meaning the definitions are still settling, and Google does not document a rich result tied to either. Use them because they describe you accurately, which is what helps machines place you correctly. Do not use them expecting a visual change in search results.

Other useful forks. A school or training provider is an EducationalOrganization. A charity is an NGO. A council or agency is a GovernmentOrganization. A publisher is a NewsMediaOrganization. A hospital group or health system is a MedicalOrganization, which is a sibling of LocalBusiness rather than a child of it, and the reason Dentist reaches the vocabulary through both.

None of these carry a dedicated rich result either. They do the same job the identifiers and sameAs links do: they tell a machine what kind of thing you are, so that everything else it learns about you attaches to the right kind of entity. Our post on Organization schema goes through that identity layer property by property.

Three questions that settle it

1. Can a customer physically come to you?

Not "do you have an address." Every business has an address somewhere. The question is whether there is a place a customer visits: a shop floor, a waiting room, a reception desk, a table.

Yes, that is the Place half earning its keep. You want LocalBusiness or one of its subtypes.

No, and you should be on the Organization side of the tree. Pick the subtype that fits: OnlineStore for a shop, EducationalOrganization for a training company, NGO for a charity, plain Organization when nothing specific applies.

2. If yes, how many places?

One place is one node, the merged shape shown earlier, usually on the homepage.

More than one place is genuinely two kinds of entity: a brand-level Organization, and a LocalBusiness per location, each on its own page with its own identifier, connected upward. This is the one case where "use both" is correct advice, and it is correct because you really do have a company and separately several places, not because a single business needs two descriptions. The architecture, including identifiers, franchises and store locators, is covered in our multi-location schema guide.

3. Is there a more specific subtype?

Google recommends "using the most specific schema.org subtype of Organization that matches your organization," and on the local side, "use the most specific LocalBusiness sub-type possible; for example, Restaurant, DaySpa, HealthClub, and so on."

There is no downside. As the Dentist example showed, a specific type inherits everything the general one had. The only reason to stop at generic LocalBusiness is that nothing more specific genuinely describes you. Our schema types directory lists what is available.

The awkward middle: businesses that travel to you

Trades and mobile services are where this decision gets genuinely uncomfortable. A plumber has a van, a yard, maybe a home office. There is an address. No customer ever visits it.

By the hierarchy, the honest reading is that the Place half does not apply, so an Organization-side type with areaServed describes the business better than a LocalBusiness with an address nobody visits. The stricter version of the same rule: if the address is not displayed on your website, it should not be asserted in your markup either. Structured data describes what is on the page.

In practice this is the case where the vocabulary and the search results pull in different directions, because Google's local features lean on your Google Business Profile rather than on your markup, and a Business Profile handles service areas directly. The markup's job here is to be accurate and consistent with the profile, not to substitute for it. If your work is the offering rather than the place, Service markup carries more of the weight than the business type does, and our service schema guide covers how to structure that.

The third architecture almost nobody covers

There is a case that is neither "one business" nor "several locations": one location containing several distinct operations. A hotel with a restaurant and a spa. A garden centre with a cafe. A department store with a pharmacy counter.

Schema.org has a property for exactly this. department describes "a relationship between an organization and a department of that organization, also described as an organization (allowing different urls, logos, opening hours)." It is defined on Organization and expects an Organization, which in practice means a nested LocalBusiness.

The point of the parenthesis in that definition is that a department can carry its own opening hours, which is usually the real reason you need it. The restaurant inside the hotel closes at 22:00 while the hotel itself never closes.

{
  "@context": "https://schema.org",
  "@type": "Hotel",
  "@id": "https://example.com/#hotel",
  "name": "The Lamar",
  "department": {
    "@type": "Restaurant",
    "name": "The Lamar Grill Room",
    "servesCuisine": "Modern British",
    "openingHours": "Tu-Su 17:00-22:00"
  }
}

Google asks for a specific naming format here: "Include the store name with the department name in the following format: {store name} {department name}." So "The Lamar Grill Room," not "Grill Room" on its own. That convention exists so the department is still identifiable as part of the parent when it appears without surrounding context.

Use department when the operations share a single address, and separate location pages when they do not. A cafe inside your shop is a department. A second branch across town is not.

What each type actually gets you in search

Worth separating what is real from what gets promised.

Local business is a supported rich result in Google's structured data gallery, feeding knowledge panel details, hours, directions and booking actions. Organization is supported too, covering the logo, legal name, address, contact details and identifiers. So both types are live features rather than markup that goes nowhere.

What neither one does is produce a result on its own. Google's LocalBusiness guide asks for only two required properties, name and address, which tells you how little of this is a pass or fail test and how much of it is description. Eligibility is not the same as appearance, and the local panel in particular is driven far more by your Google Business Profile than by anything in your page source.

The Organization-side subtypes discussed earlier, OnlineStore and friends, have no rich result of their own. That is not a reason to avoid them. It is a reason to be clear with yourself about why you are adding them, which is identity rather than decoration.

How AI systems read the difference

The type you choose is a claim about what kind of thing you are, and that claim is doing more work now than it used to.

When an assistant answers a question about a business, it has to resolve a name on a page to a specific entity in the world, and separate you from every similarly named company. The type is the first fact that narrows the field. A Dentist in Austin with an address and coordinates is a different kind of answer to a Corporation with a national contact point, and a system building an answer treats them differently because they are different.

This is also why a split entity costs more than it used to. Two half-described nodes give a system two weak candidates instead of one strong one, and the choice between them is a guess.

The honest limit is the one that applies everywhere in this topic: Google states no special structured data is required for its AI features, and no markup guarantees a mention in any generated answer. Accurate typing makes you unambiguously identifiable, which is a prerequisite for being resolved correctly. It is not a lever that produces citations.

Common mistakes

Publishing Organization and LocalBusiness separately for one business. Two identifiers, one company, no relationship stated. The most common version of this problem and the one most likely to be arriving from a plugin you have not looked at recently.

Using LocalBusiness because you want the "business" properties. Almost all of them are Organization properties that any Organization subtype already has. The only ones exclusive to LocalBusiness are opening hours, price range, payment methods, currencies and floor level.

Asserting geo or opening hours for a business with nowhere to visit. These come from Place. If there is no place, they are describing something that is not there.

Stopping at generic LocalBusiness when a subtype exists. Specific types inherit everything. There is no cost to being precise.

Using branchOf to link a branch to its parent. Schema.org has superseded branchOf with parentOrganization. The old property still validates, but new markup should use the current one.

Treating department as a way to list separate locations. Departments share an address. Branches do not.

Letting the markup and the visible page disagree. An address in the markup that is nowhere on the page, or opening hours that contradict the ones displayed, is a mismatch a reviewer or a validator can catch.

How to check what your site emits right now

This is narrowly a check on how many entities you are publishing and whether the type fits, not a full audit of every Organization property, which our Organization schema post covers separately. Fifteen minutes, and most established sites turn up at least one of the problems above.

1. Count the blocks. View source on your homepage and search for "@type". List every block describing your company. If there is more than one, note the @id of each.

2. Check whether they are connected. Two blocks are fine when one is a brand and the other is a location, and they reference each other. Two blocks with unrelated identifiers and no link between them are a split entity.

3. Check the type against the three questions. Can customers visit? How many places? Is there a more specific subtype? If the answer to the first is no and you are publishing LocalBusiness, that is the thing to fix first.

4. Check the Place properties are earned. If geo, hasMap or openingHoursSpecification are present, confirm there is a real location they describe and that the hours match what the page displays.

5. Find where each block comes from. Usually a plugin settings screen. Turning off the duplicate at its source is the durable fix. Deleting the output while the setting that generates it stays on means it returns at the next update.

6. Validate. Run the page through the Rich Results Test for Google's view of eligibility, and validator.schema.org for plain vocabulary checking of properties that produce no rich result.

AI Schema Gen picks the type for you. Its site type system covers 28 business profiles and 80+ specific subtypes, so a dental practice gets Dentist and an online shop gets OnlineStore, on one connected entity rather than two competing blocks. Start free and see what your site is emitting today.