Organization vs LocalBusiness Schema: What's the Difference?

If you've spent any time reading about schema markup, you've probably come across both Organization and LocalBusiness as schema types. They sound similar. They share many of the same properties. And it's genuinely easy to pick the wrong one, or to assume they're interchangeable when they're not.

The distinction matters more than most people realise, especially as AI search engines like ChatGPT, Perplexity, and Gemini increasingly use structured data to understand what a business is, where it operates, and whether it's worth recommending. Getting this wrong won't break your site, but getting it right gives you a real edge.

How Schema.org Structures Business Types

Schema.org uses a hierarchy. Organization is the parent type. It covers any kind of organised entity: a company, a charity, a government body, a sports team, a brand with no physical presence. It's intentionally broad.

LocalBusiness is a child type of Organization. That means it inherits every property that Organization has, and then adds more on top. Specifically, it adds properties that are relevant to businesses with a physical location: opening hours, service area, map coordinates, price range, and so on.

Think of it this way. All LocalBusiness entities are also Organization entities, but not all Organization entities are LocalBusiness entities. A SaaS company with no physical office is an Organization. A dental practice with a reception desk in Manchester is a LocalBusiness.

Further down the hierarchy, LocalBusiness itself has subtypes. Things like Restaurant, MedicalClinic, LegalService, AutoRepair, and dozens more. These are even more specific, and when one applies to your business, you should use it. More on that shortly.

When to Use Organization Schema

Organization schema is the right choice when your business:

• Operates entirely online with no physical premises customers visit
• Is a holding company, parent brand, or corporate entity
• Has multiple locations but you're marking up the top-level brand rather than any individual site
• Is a non-profit, charity, or other entity that doesn't fit the "local" model

E-commerce brands often fall here. If you sell products through a website and your customers never visit a physical shop, Organization is your type. That said, if you also have a warehouse customers can collect from, or a showroom, the situation changes.

The key properties to include in Organization schema are:

• name: Your exact legal or trading name
• url: Your canonical homepage URL
• logo: A URL pointing to your logo image (at least 112x112px, ideally larger)
• description: A clear, factual description of what you do, written for machines as much as humans
• sameAs: An array of your verified profiles elsewhere, such as LinkedIn, Companies House, Wikipedia, Wikidata, and social media accounts
• contactPoint: How people can reach you, including contact type and available languages
• foundingDate: When the business was established

The sameAs property deserves special attention. AI systems use it to cross-reference information about you across the web. The more authoritative the sources you link to, the more confident an AI becomes that you're a real, established entity. A Companies House URL, a Wikidata entry, and a verified LinkedIn company page are far more valuable than just linking to your Twitter profile.

When to Use LocalBusiness Schema

Use LocalBusiness when customers physically visit your premises, or when your business serves a defined geographic area. This includes:

• Shops, restaurants, cafes, and retail outlets
• Service businesses like plumbers, electricians, or cleaners who work in a specific area
• Professional practices: solicitors, dentists, accountants, physiotherapists
• Gyms, salons, studios, and any venue with a physical address

The additional properties that make LocalBusiness worth using over plain Organization include:

• address: A structured PostalAddress object with street, city, postal code, and country
• geo: A GeoCoordinates object with precise latitude and longitude
• openingHoursSpecification: Structured opening hours by day of the week
• priceRange: A rough guide using pound signs (£, ££, £££)
• hasMap: A link to your Google Maps listing
• areaServed: The geographic area you serve, if you travel to customers
• telephone and email: Direct contact details

When an AI is asked "find me a good accountant in Bristol" or "which plumbers are near me and open on Saturdays", it needs this structured information to give a useful answer. A site with LocalBusiness schema that includes accurate opening hours and a verified address is far more likely to be cited than one with generic Organization markup or no markup at all.

Using a Subtype Instead of LocalBusiness Directly

Here's where many implementations miss a trick. If your business fits a specific LocalBusiness subtype, use that subtype rather than the generic parent.

Schema.org has over 150 specific local business types. Some commonly used ones include:

• Restaurant (with subtypes like FastFoodRestaurant, CafeOrCoffeeShop)
• MedicalClinic and Dentist and Physician
• LegalService and Attorney
• AutoRepair and AutoDealer
• HairSalon, BeautySalon, NailSalon
• GroceryStore, ClothingStore, ElectronicsStore
• Gym and SportsActivityLocation
• Hotel and LodgingBusiness

Using a more specific type gives search engines and AI systems more precise context about your business. A Dentist type tells an AI exactly what you do without needing to parse your page copy. It's a stronger signal than LocalBusiness with a text description saying "we are a dental practice".

You can also declare multiple types in a single JSON-LD block using an array: "@type": ["LocalBusiness", "Dentist"]. This is valid and often sensible when you want to be explicit at both the general and specific level.

Can You Use Both Organization and LocalBusiness on the Same Site?

Yes, and for many businesses this is exactly the right approach. The two types serve different purposes and can sit in different places on your site.

A common pattern for a multi-location retail brand might look like this:

• Homepage: Organization schema describing the parent brand, its logo, social profiles, founding date, and contact point
• Each location page: LocalBusiness (or a relevant subtype) schema with that specific location's address, hours, phone number, and geo coordinates

This structure tells AI systems both "here is the brand" and "here are the specific places you can find us". It's a far richer picture than either type on its own.

If you only have one location and one website, you can combine both types in a single JSON-LD block on your homepage. Use the array syntax for @type and include all the relevant properties from both.

At FlinnSchema, we often see clients who've implemented Organization across their entire site when several of their pages should actually be using LocalBusiness subtypes. It's one of the most common structured data mistakes for businesses with physical premises, and one of the easiest to fix once you know what to look for. If you're not sure how your current setup holds up, a free AI visibility audit is a good place to start.

A Practical JSON-LD Example

Here's how a physiotherapy clinic in Leeds might structure their schema, using the MedicalBusiness subtype:

{
  "@context": "https://schema.org",
  "@type": ["LocalBusiness", "MedicalBusiness"],
  "name": "Leeds City Physio",
  "url": "https://www.leedscityphysio.co.uk",
  "logo": "https://www.leedscityphysio.co.uk/logo.png",
  "description": "Specialist physiotherapy clinic in Leeds city centre offering sports injury treatment, post-operative rehabilitation, and chronic pain management.",
  "telephone": "+441132001234",
  "email": "hello@leedscityphysio.co.uk",
  "priceRange": "££",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "42 Park Row",
    "addressLocality": "Leeds",
    "postalCode": "LS1 5JB",
    "addressCountry": "GB"
  },
  "geo": {
    "@type": "GeoCoordinates",
    "latitude": 53.7996,
    "longitude": -1.5491
  },
  "openingHoursSpecification": [
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"],
      "opens": "08:00",
      "closes": "19:00"
    },
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": "Saturday",
      "opens": "09:00",
      "closes": "13:00"
    }
  ],
  "sameAs": [
    "https://www.linkedin.com/company/leeds-city-physio",
    "https://www.google.com/maps/place/..."
  ]
}

Notice that the @type array combines both LocalBusiness and the more specific MedicalBusiness. The address is a nested PostalAddress object, not just a plain text string. Geo coordinates are included. Opening hours are structured by day with specific times rather than a vague text value. This is the kind of implementation that AI systems can actually parse and use.

For a deeper look at which schema types e-commerce and service businesses should prioritise across their whole site, see our guide on which schema types every e-commerce site should have. And if you want to confirm your JSON-LD is valid before publishing, the schema validation guide walks through the tools and process step by step.

Common Mistakes to Avoid

A few patterns come up repeatedly in site audits:

Using Organization when LocalBusiness applies. If you have a physical address customers visit, using the generic Organization type leaves structured location data on the table. AI systems cannot infer your opening hours or location from text alone with the same confidence as structured data.

Ignoring the subtypes entirely. Using LocalBusiness when you could use Restaurant or Dentist or AutoRepair is a missed opportunity. The more specific you are, the more useful the signal.

Putting opening hours as plain text. A description property that says "open Monday to Friday 9am to 5pm" is not the same as a properly structured openingHoursSpecification array. Only the latter gets reliably parsed by machines.

Using the wrong address format. Address should always use the PostalAddress schema type as a nested object, not a single string. A string like "42 Park Row, Leeds, LS1 5JB" is harder for machines to parse accurately than the structured equivalent.

Forgetting sameAs links. This matters for both types. It's how AI systems verify that your schema claims match what they already know about you from external sources. Even three or four authoritative sameAs URLs make a meaningful difference to how confidently an AI can describe your business.

Frequently Asked Questions

Can I use LocalBusiness schema if my business also sells online?

Yes. If you have a physical location that customers can visit, use LocalBusiness for that location. You can also include Organization at the brand level. Having both an online shop and a physical presence doesn't prevent you from using LocalBusiness. In fact, it makes it more valuable, since AI can surface your physical location for relevant local queries while your e-commerce pages handle product-related queries separately.

Does LocalBusiness schema help with Google Maps rankings?

Schema markup is not a direct ranking factor for Google Maps or the Local Pack. Those are primarily driven by your Google Business Profile, citation consistency, and reviews. That said, LocalBusiness schema with accurate address and geo data reinforces the same signals and helps AI search engines (outside of Google) understand your location. It's part of a wider local visibility strategy, not a silver bullet on its own.

What is the difference between areaServed and address in LocalBusiness schema?

address describes where your business is physically located. areaServed describes the geographic area you serve, which may be different. A mobile dog groomer based in Brighton might have a Brighton address but an areaServed value covering the whole of East Sussex. Both properties can and should coexist for service-area businesses. Use areaServed with a City, State, or plain text string depending on how specific you want to be.

Do I need to add LocalBusiness schema to every page, or just the homepage?

For a single-location business, putting LocalBusiness schema on the homepage and contact page is usually sufficient. For multi-location businesses, each location should have its own dedicated page with its own LocalBusiness schema block containing that location's specific details. Duplicating identical location schema across dozens of pages adds noise without adding value. Keep it targeted and accurate rather than widespread and repetitive.