CafeOrCoffeeShop or LocalBusiness: Which Schema Type to Use
Somewhere along the way you found two type names in a plugin dropdown or a code snippet, LocalBusiness and CafeOrCoffeeShop, and nothing told you which one your cafe should actually use. One plugin picks one. A tutorial picks the other. Neither explains why.
Short answer: use the most specific valid type that describes the business, and only combine two types when the business genuinely is two things, such as a roaster that also runs a retail counter. For almost every independent cafe, that means CafeOrCoffeeShop alone. This post walks the hierarchy those two types sit inside, when a broader type is the safer choice, a decision table you can match your own shop against, and the errors that show up most often when this gets picked wrong.
None of this requires hiring anyone or learning a programming language. It requires about ten minutes reading the actual definitions, matching your own shop against the five common shapes below, and then checking the result in a free validator. That is the whole job. What follows is written so you can do exactly that in one sitting, starting from the hierarchy itself and ending with the errors most owners never notice until something breaks.
Types
Schema.org organizes business types as a tree, not a flat list. LocalBusiness sits near the top as a broad category for any business with a physical location customers visit. Under it sit narrower branches, and FoodEstablishment is one of them, covering any place that serves food or drink to people on site. CafeOrCoffeeShop is a child of FoodEstablishment, meaning it inherits everything FoodEstablishment and LocalBusiness can describe, and adds nothing extra of its own beyond the name itself.
That inheritance matters more than the label. A page marked up as CafeOrCoffeeShop can still carry every property LocalBusiness supports: name, address, telephone, opening hours, geo coordinates, price range, and a URL. Choosing the more specific type does not cost you any properties. It only adds a clearer signal about what kind of place this is, which is the entire point of picking a type in the first place.
Store is a separate branch under LocalBusiness, built for retail businesses that sell goods rather than serve food and drink on site. A roaster that sells bags of beans through an online store, with no seating and no drinks served, sits closer to Store than to CafeOrCoffeeShop. A roaster that also runs a cafe counter is genuinely both things, and that is the one case where combining types earns its place rather than adding noise.
None of this hierarchy is a ranking system. Schema.org built it to describe what a business is, not to reward businesses for describing themselves precisely. The value of choosing correctly is that search engines and AI tools parsing your page get an accurate, unambiguous read on what they are looking at, which is a foundation, not a lever.
It helps to see the actual chain written out once, top to bottom. Thing sits at the very top of schema.org as the most general category that exists. Organization and Place both descend from Thing, and LocalBusiness descends from both, since a local business is simultaneously an organization and a physical place. FoodEstablishment descends from LocalBusiness. CafeOrCoffeeShop descends from FoodEstablishment. Every property available higher in that chain remains available at the bottom, which is why a CafeOrCoffeeShop block can still hold a plain LocalBusiness property like priceRange without any conflict.
Two sibling types under FoodEstablishment are worth knowing even if your shop does not use them: Restaurant and Bakery. A cafe that serves a full food menu alongside coffee is sometimes better described as a Restaurant with coffee mentioned in the content, and a cafe built primarily around baked goods with coffee as a companion product sometimes fits Bakery more honestly than CafeOrCoffeeShop. None of these siblings are wrong choices in the abstract. The only wrong choice is one that does not match what the business does.
Specific vs general
The instinct to play it safe with a broad type, LocalBusiness alone, is understandable but usually backwards. A generic type is not a hedge against getting it wrong. It is simply a less useful description, since it tells a reader of the markup that this is some kind of local business without saying what kind. If your shop serves coffee to people who sit down or walk up to a counter, CafeOrCoffeeShop says that plainly, and there is no real downside to using it.
There is one place where a broader type is the safer, more accurate choice: when the business does not cleanly fit the narrower type. A coffee cart with no fixed address that moves between events is not well described by CafeOrCoffeeShop, since that type assumes a stable place. A shop that is mostly a bakery with a small coffee counter might be more accurately described as a Bakery, another FoodEstablishment child, with coffee mentioned in the page content rather than the schema type itself.
The general rule holds across all of this: pick the type whose plain English definition matches what a customer would say the business is. If you would describe your own shop to a stranger as a coffee shop, CafeOrCoffeeShop is correct. If you would call it a roastery with a retail shop, Store or a combination is more honest. The type should describe the business, not aspire to describe it.
Owners sometimes worry that a narrower type will somehow limit what a search engine or AI tool can say about the business, as though a broader type opens more doors. It does not work that way. A search engine reading your page is not choosing between types the way a customer chooses between menu items. It is reading whichever type you provided and using it, correctly or not, as a description of what it found. A precise, accurate type gives it less to guess at, not less to work with.
It is also worth saying plainly what this choice will not do. Picking the correct schema type will not move a shop up a search results page on its own, and it will not make an AI answer choose to mention your shop over another. What it does is remove one small source of confusion from a system that is already trying to make sense of a page built for humans, not machines. That is a real, worthwhile improvement, and it is also a modest one, which is exactly why it should not take more than a sitting to fix.
Examples
A decision table is the fastest way to settle this for most owners, sorted by the kind of business rather than by platform or plugin. Five common shapes cover nearly every independent cafe.
A cafe with no roasting operation and no separate retail arm: use CafeOrCoffeeShop alone, with full LocalBusiness properties filled in underneath it. This covers the large majority of independent shops and is the simplest, most defensible choice available.
A roaster that also runs a cafe counter on the same site: use two type blocks, one CafeOrCoffeeShop for the cafe and one Store or a more specific product oriented type for the retail or wholesale side, each with its own accurate properties. Do not force one block to carry both jobs, since that is where errors creep in.
A roaster with no cafe seating, selling only bags of beans through an online store: use Store, not CafeOrCoffeeShop, since there is no on site food and drink service to describe. A coffee cart or mobile vendor without a fixed address: LocalBusiness alone is often the more honest choice, since CafeOrCoffeeShop implies a stable place a customer can visit. A multi location cafe brand: each location gets its own CafeOrCoffeeShop block with that location's own address and hours, not one shared block for the whole brand.
Walk through the first shape once in full, since it covers the largest number of shops. A single location cafe with a counter, seating and a straightforward menu names CafeOrCoffeeShop as its type, then fills in name, address, telephone, opening hours specification, geo coordinates and a URL pointing back to the homepage. Price range is optional but useful when it is honest and simple, expressed as a general band rather than an exact menu figure. None of these properties are exotic. They are the same facts already printed on a door sign and a Google Business Profile, restated in a form a machine can read directly from the page.
Errors
The most common mistake is not a wrong type at all, it is a type with no schema present, or schema that never loads on the page a crawler reads. Across the six region census Hillcane ran on more than 1,000 independent specialty shops, snapshot dated September 15, 2026, 337 shops had schema present, 367 had it only partially filled in, and 368 had none detected. Put plainly, choosing between CafeOrCoffeeShop and LocalBusiness only matters once markup exists on the page, and for a large share of shops in that snapshot it did not yet.
The second most common error is a wrong type paired with properties that do not belong to it, such as a Store block carrying opening hours meant for walk in dining, or a CafeOrCoffeeShop block missing the address entirely. A validator will often flag this as a warning rather than a hard error, which is exactly why it goes unnoticed for months. Run the block through Google's Rich Results Test or the Schema Markup Validator after any change, not just once at launch.
A third error is a misspelled type name. CafeOrCoffeeShop is one word with specific capitalization, and a typo turns the whole block into an unrecognized type that validators either ignore or flag outright. This is a simple, easy to miss mistake, and it is worth a direct copy and paste from a working example rather than retyping the name from memory.
The fourth error is two schema blocks on the same page that disagree with each other, commonly one generated automatically by a plugin and a second added by hand, each naming the business slightly differently or listing different hours. A crawler encountering conflicting structured data on one page has no clean way to decide which block is correct, so the safest fix is to pick one source of truth for your schema and remove or disable the other.
A fifth, smaller error worth naming: applying CafeOrCoffeeShop to a page that is not your business location at all, such as a general blog post or an about page with no address of its own. Structured data describing a place belongs on the page that represents that place, usually the homepage or a dedicated location page, not scattered across every page on the site. Putting the same business block on ten different pages does not multiply its value. It just adds ten more places a future edit has to be kept consistent.
Related Reading
More from Hillcane on this topic, plus the pages on the site that sit next to the work.
Frequently Asked Questions
Should I use CafeOrCoffeeShop for my cafe?
For most independent coffee shops, yes. CafeOrCoffeeShop is a child type of FoodEstablishment, which is itself a child of LocalBusiness, so it inherits every property a broad LocalBusiness block supports while naming your business more precisely. If your shop serves coffee to people who sit down or walk up to a counter, this is the correct, most specific valid type to use.
What is the difference between LocalBusiness and CafeOrCoffeeShop?
LocalBusiness is a broad parent type covering any business with a physical location customers visit. CafeOrCoffeeShop is a specific child type nested underneath it through FoodEstablishment, built to describe a place that serves coffee and food on site. Using the child type does not remove any LocalBusiness properties, it simply adds a more accurate label on top of them.
When should a cafe use LocalBusiness instead of CafeOrCoffeeShop?
Mainly when the business does not cleanly fit the narrower definition, such as a coffee cart or mobile vendor with no fixed address that customers can visit, since CafeOrCoffeeShop assumes a stable place. In that case a plain LocalBusiness type, described accurately in the page content, is the more honest choice than forcing a type that implies a storefront that does not exist.
Can a coffee shop use two schema types at once?
Yes, when the business is two things, such as a roaster that also runs a cafe counter. In that case use one CafeOrCoffeeShop block for the cafe side and a separate Store or product oriented block for the retail or wholesale side, each with its own accurate properties, rather than combining both jobs into a single block.
Does choosing CafeOrCoffeeShop over LocalBusiness help my cafe rank higher?
There is no basis for that claim, and this post does not make it. Choosing the correct type is about accuracy, giving search engines and AI tools an unambiguous read on what your business is. Across the six region census Hillcane ran, snapshot dated September 15, 2026, 735 shops still had partial or absent markup, which is the more foundational gap to close first.
What type should a roaster with no cafe seating use?
Store is the more accurate type for a roaster that sells bags of beans through an online store with no seating and no on site drink service. CafeOrCoffeeShop implies food and drink served on site, so applying it to a pure retail or wholesale roaster misdescribes the business, even though the coffee itself is the same product.
What is the most common schema type error on cafe websites?
Beyond schema simply being missing, the most common error is a type paired with properties that do not belong to it, such as dining hours attached to a retail only Store block, or an address left blank on a CafeOrCoffeeShop block. Validators often flag this as a warning rather than a hard error, so it can sit unnoticed on a live page for months.
How do I check if my schema type is set up correctly?
Run your page through Google's Rich Results Test or the Schema Markup Validator, both free tools that read your page's structured data and report errors and warnings. Do this after any change to your site or plugin settings, not only once at launch, since plugin updates and theme changes can quietly alter or duplicate the schema block on a page.
Should a multi location cafe use one schema block for all locations?
No. Each location should carry its own CafeOrCoffeeShop block with that location's own address, telephone, opening hours and geo coordinates, placed on the page that represents that location, rather than one shared block describing the brand as a whole. A shared block blurs which address and hours belong to which storefront, and copying the same business block onto ten pages only adds ten more places for a future mismatch.
Can Hillcane help pick and set up the right schema type for my cafe?
Yes. Hillcane works through exactly this decision with cafe owners, matching the business to the most accurate schema.org type, whether CafeOrCoffeeShop, Store, Bakery or LocalBusiness alone, and checking the result in Google's Rich Results Test and the Schema Markup Validator. In the census snapshot of September 15, 2026, 368 shops had no schema detected at all, so the work often starts there. Reach out at hillcane.co/contact or call (256) 384-2449.
Work with Hillcane
Two schema types show up in every plugin dropdown, LocalBusiness and CafeOrCoffeeShop, and almost nothing explains which one your cafe should actually use.
If you want a second set of eyes on your cafe's schema type and properties, reach Hillcane at hillcane.co/contact or call (256) 384-2449.
Comments