Do Cafes Need Geo Coordinates in Schema? Service Area Rules
An owner working through schema markup for their cafe hits the geo property and stalls: is this required, is it worth the trouble, and what happens if it is wrong. Short answer: for most cafes with a single, fixed address, geo coordinates in schema are optional, genuinely useful when accurate, and worse than leaving them out entirely when wrong. The service area property is a different tool for a different kind of business, one that actually travels to customers rather than serving them from one fixed location, and most independent cafes should not reach for it at all.
This piece covers the properties involved, geo, GeoCoordinates, areaServed and the address itself, and then covers accuracy specifically, since that is where the real risk sits: decimal precision, the correct sign for a location in the western hemisphere, coordinates with latitude and longitude accidentally swapped, and a pin that lands somewhere the business is not. It includes a copy ready example using a fictional address, since real coordinates for a real cafe have to come from the owner's own verified location, never copied from an example in a blog post. By the end, an owner should be able to decide confidently whether to add geo at all, and if so, know exactly how to test the result before it ever goes live.
The Properties Involved
Schema.org's structured data vocabulary describes a physical location through a handful of related properties. The address property holds the street address, city, state and postal code as separate, structured fields, and for a cafe with a fixed storefront this is the property that matters most, since it is the plainest, most direct statement of where the business actually is. The geo property is where latitude and longitude values can be added, using a nested GeoCoordinates type that holds a latitude value and a longitude value as decimal numbers.
The areaServed property is a different tool entirely, meant to describe a geographic region a business serves, a city, a set of neighborhoods, a radius, rather than a single fixed point. This property exists for businesses that genuinely travel to or serve customers across an area rather than operating from one storefront a customer visits, a mobile coffee cart or a catering business being reasonable examples. A cafe with a single physical location that customers walk into generally has no real use for areaServed, since its actual business model is the opposite of an area served concept: customers come to one fixed point, rather than the business reaching out across a region.
It is worth being candid that documentation on how geo coordinates are classified for local business markup, whether they are described as required, recommended, or simply optional, should be checked directly and dated at the time an owner is implementing this, since documentation pages get updated and a claim made in one piece of writing can go stale. What can be said generally and safely is that an address property is the more fundamental, commonly expected piece of location markup for a fixed location business, and geo coordinates function as an additional, more precise layer on top of that address, useful when accurate rather than a required substitute for it.
Why Accuracy Matters More Than Presence
The reason this topic deserves real caution is not that geo coordinates are dangerous in general. It is that a wrong pair of coordinates is a specific, concrete false statement about where a business physically is, sitting in the page's own code, which is a different and arguably worse problem than simply not having coordinates at all. A missing geo property tells a search engine nothing extra. A wrong one tells it something false, stated with the same apparent confidence as if it were correct.
The most common, avoidable errors fall into a small number of categories. Swapped latitude and longitude values, where the two numbers are written in the wrong order, will place a pin somewhere entirely different from the intended location, often in a different part of the world depending on the specific values involved. A missing negative sign is a related, equally common error: for most locations in the United States, the longitude value should be negative, reflecting a position west of the prime meridian, and a coordinate pair that drops that negative sign by mistake will place a pin on the opposite side of the globe rather than merely nearby. Rounding coordinates to too few decimal places is a subtler error, one that does not send a pin to the wrong continent but can still place it a noticeable, wrong distance from the business's actual building, especially in a dense downtown area where a small error in decimal precision translates to a real, visible gap on a map.
Every one of these errors is easy to catch before publishing, which is exactly why there is no good excuse for leaving a wrong coordinate pair live on a site. The fix is simple and available to anyone: take the exact coordinate values from the schema markup and plot them directly on a public map tool, then look at where the pin lands and compare that to where the business is. If the pin is not sitting on the building, the coordinates are wrong, and they should be corrected or removed rather than left in place because the markup otherwise looks complete. A plugin, a template, or a developer copying an old example can all introduce these same errors just as easily as a manual mistake, so the check matters regardless of how the markup was originally produced.
Getting Accurate Coordinates and Writing Them Correctly
The most reliable way for an owner to get accurate coordinates for their own real cafe is to use a mapping tool directly: locate the business's own building precisely on a map, using the actual entrance or the building's center point as the reference point, and use the map tool's own method for copying the coordinates at that exact spot, generally through a right click or long press option that surfaces the latitude and longitude as text. This produces coordinates tied to the map tool's own current data for that specific building, rather than an estimate typed from memory or copied from an old listing that may not reflect the building's actual current position on the map.
Whatever number of decimal places the map tool provides when coordinates are copied this way is generally a reasonable amount of precision to use, since that reflects the tool's own working precision rather than an arbitrary choice, and there is no benefit to rounding a copied value down further once it has been copied directly from the source. Writing the values into schema follows a simple pattern: a geo property containing a GeoCoordinates type, with a latitude value and a longitude value written as plain decimal numbers, matching exactly what was copied from the map, not retyped from memory or transcribed from a different source that might introduce an error along the way.
A fictional, copy ready example makes this concrete without risking a real cafe's actual location: a business at a fictional 142 Willow Street in a fictional town, with a geo property set to a GeoCoordinates type holding a latitude of 35.12345 and a longitude of negative 86.54321. Note the negative sign on the longitude value, consistent with a location in the United States west of the prime meridian, and note the five decimal places, a reasonable level of precision for a specific building location. Before publishing any coordinate pair, real or fictional, it should be validated using a structured data testing tool to confirm the markup itself is well formed, and the actual coordinate values should always be plotted on a map separately to visually confirm the pin lands where it is supposed to.
When a Service Area Actually Applies
The areaServed property belongs to a different kind of business than the typical fixed location cafe this piece is mostly written for. A business that travels, a mobile coffee cart working a rotating set of events, a catering operation that delivers to a defined region rather than operating from a storefront customers visit, has a real use for describing the area it serves rather than a single fixed point, since a single address does not accurately describe how that business operates.
A cafe with one physical storefront that customers walk into should generally rely on its address and, where accurate, its geo coordinates, rather than adding an areaServed property that implies the business operates across a wider region than it does. Adding a service area to a business that does not serve one is not a helpful embellishment. It is an inaccurate statement about how the business works, the same underlying problem as a wrong coordinate, just expressed through a different property.
This piece deliberately does not cover the fuller structure of markup for a business with multiple locations, or the specific rules for a mobile vendor, since those are different enough questions that they deserve their own dedicated coverage rather than being folded into a general geo and service area explainer. For the large majority of independent cafes with one fixed address, the practical answer this piece supports is simple: add an accurate address always, add geo coordinates when you can get them accurately from a reliable source and verify the pin lands correctly, and leave areaServed alone unless your business operates across a region rather than from one storefront.
A Simple Way to Test Your Own Block Before Publishing
Before any schema change goes live on a real cafe's site, it is worth running through a short, repeatable check rather than trusting that the markup looks right at a glance. First, validate the block using a structured data testing tool to confirm it is well formed and free of syntax errors, since a small typo in the markup itself can cause the whole block to be ignored or misread even if the actual address and coordinate values are correct. Second, take the exact latitude and longitude values written in the block and paste them directly into a public map tool's search, then look at where the resulting pin lands and compare it, honestly, against where the business is.
Third, read through the address fields themselves, street, city, state and postal code, and confirm each one matches the business's actual current mailing address exactly, since a stale address left over from an old draft or a copied template is just as much a false statement as a wrong coordinate, even though it tends to draw less attention. Fourth, if the business does not operate across a service area, confirm that no areaServed property has been left in from a template or an earlier draft, since templates are a common, easy to miss source of exactly this kind of inaccurate leftover markup.
This four step check takes only a few minutes once a block is written, and it catches the overwhelming majority of the real, common errors this piece has described: a malformed block, a mismatched pin, a stale address, and an inaccurate service area claim left over from a template. Running it once before publishing, and again any time the business's address or coordinates are updated, is a small, cheap habit that keeps a cafe's structured location data honest and useful rather than technically present but quietly wrong.
Related Reading
More from Hillcane on this topic, plus the pages on the site that sit next to the work.
Frequently Asked Questions
Do I need geo coordinates in my cafe's schema markup?
For most cafes with a single fixed address, geo coordinates are optional rather than required. They are worth adding when you can get them accurately from a reliable source, since they add a useful, precise layer on top of your address, but an accurate address alone is the more fundamental piece of location markup for a fixed location business.
What happens if my geo coordinates are wrong?
A wrong coordinate pair is a specific false statement about your business's physical location, which can be worse than having no coordinates at all, since a missing property tells a search engine nothing extra while a wrong one states something false with apparent confidence. Common errors include swapped latitude and longitude, a missing negative sign on longitude, and coordinates rounded to too few decimal places.
How do I get accurate coordinates for my cafe?
Locate your building precisely on a mapping tool, using the entrance or the building's center as the reference point, and use the map tool's own method for copying coordinates at that exact spot, usually through a right click or long press. This ties your coordinates to the map's own current data for your specific building rather than an estimate or an old value copied from somewhere else.
What is the difference between geo coordinates and areaServed in schema?
Geo coordinates, through a GeoCoordinates type nested in the geo property, describe a single fixed point: your business's actual location, as a latitude and a longitude in decimal numbers. AreaServed describes a broader region a business serves, a city, a set of neighborhoods or a radius, meant for businesses that travel to customers, such as a mobile coffee cart or a catering operation.
Should a cafe with one storefront use the areaServed property?
Generally no. AreaServed implies the business operates across a region rather than from a single fixed location, which is not accurate for a typical storefront cafe that customers walk into. Using it anyway is an inaccurate statement about how the business works, similar in kind to a wrong coordinate. Templates often leave an areaServed block behind, so check for one before publishing.
How many decimal places should my geo coordinates have?
Whatever number of decimal places your map tool provides when you copy the coordinates directly from the source is generally a reasonable level of precision to use. There is no benefit to rounding a value down further once it has been captured accurately, and a fictional example in this piece uses five decimal places for illustration.
How do I check if my coordinates are correct?
Take the exact latitude and longitude values from your schema markup and plot them directly on a public map tool, then compare where the pin lands to where your business is. If the pin does not land on your building, correct or remove the coordinates. Validate the block itself with a structured data testing tool too, and recheck both whenever the address changes.
Why does the sign on the longitude value matter?
For most locations in the United States, the correct longitude value should be negative, reflecting a position west of the prime meridian. A coordinate pair that accidentally drops that negative sign places a pin on the opposite side of the globe rather than simply nearby, which is a serious, easily made error worth double checking.
Does adding accurate geo coordinates improve my cafe's Maps ranking?
This piece does not make that claim, since none of the documentation behind it supports one. Schema markup, including geo coordinates, is generally understood as helping search engines understand a page clearly rather than as a direct ranking lever. Accuracy is the priority regardless: a correct address always, and coordinates only when the pin lands on your building.
How can Hillcane help with schema and location markup for a cafe?
Hillcane can help write and validate accurate schema markup for your cafe, from the address fields to a GeoCoordinates block, checking that any coordinates plot to your real building and that no leftover areaServed property is sitting in a template before anything goes live. Reach out at hillcane.co/contact or call (256) 384-2449 to talk through your site's markup.
Work with Hillcane
A wrong pair of geo coordinates in your schema is worse than no coordinates at all. Here is how to add them correctly, and when to skip them entirely.
If you want your cafe's schema markup checked for accuracy, including geo coordinates and service area properties, reach Hillcane at hillcane.co/contact or call (256) 384-2449.
Comments