Copy Ready Homepage Schema for a Cafe, Explained Line by Line


Short answer: paste the block below into your homepage's head section after replacing the placeholders in ALL CAPS with your own shop's real details, then run it through a validator before you publish. What goes in homepage schema, at minimum, is your name, address, hours, phone number and website, built as a single CafeOrCoffeeShop object so search engines can read your basic facts as structured data rather than guessing at them from your page's visible text.
Most schema examples an owner finds online are either stripped down to almost nothing or stuffed with properties a small shop cannot actually support, like review ratings nobody generated or a price range nobody wants published. This post gives you one complete, realistic block built specifically for a homepage, and it explains every line so that when you need to change a value, you know exactly what you are changing and why.
This is not a promise that adding this code changes your ranking or gets you cited by an AI tool. Schema is a translation layer, not a ranking lever. It tells machines clearly what your page already says in plain text. Getting that translation right is worth doing well, and worth understanding, rather than pasting blind.
The Properties, One at a Time
Google's own Local business structured data documentation and the schema.org CafeOrCoffeeShop type page, both read on September 21, 2026, describe a set of properties for a local business listing. Some are required for Google to consider the markup valid, some are recommended because they make the listing more useful, and some are optional extras. Here is what each one in the block below actually does.
The @context and @type lines are not content, they are labels telling a machine what vocabulary and what kind of thing this block describes, in this case a CafeOrCoffeeShop from the schema.org vocabulary. The name property is your shop's actual business name, exactly as it appears on your signage and your Business Profile, not a slogan or a tagline. The url property points back to your own homepage, confirming the page and the entity described in the schema are the same thing.
The description property is a short, plain sentence describing what your shop is, written for a machine reading it out of context, not for a customer reading your homepage copy. The address property is not a single line of text, it is its own nested object, using the PostalAddress type, broken into streetAddress, addressLocality, addressRegion, postalCode and addressCountry, each as its own separate value rather than one combined string.
The geo property is also a nested object, using the GeoCoordinates type, holding latitude and longitude as separate numeric values. The telephone property is your shop's phone number in a single, consistent format. The openingHoursSpecification property is a list, one entry per set of days and hours, using the OpeningHoursSpecification type, so a shop with different hours on different days needs multiple entries rather than one line trying to describe all of them. The priceRange property is optional and this example intentionally leaves it out, since the plan behind this post bans naming any price. The image and logo properties point to real image files already hosted on your own site, and sameAs is a list of your shop's other official profile URLs, such as your Business Profile or social accounts, confirming to a machine that those profiles and this website describe the same business.
The Complete Example Block
Here is the full block, built and validated on September 21, 2026 against the Schema Markup Validator and Google's Rich Results Test with no errors returned. Every value below is a placeholder in ALL CAPS. Replace each one with your shop's real information before publishing, and do not leave any placeholder text in the live version.
{ "@context": "https://schema.org", "@type": "CafeOrCoffeeShop", "name": "YOUR SHOP NAME", "url": "https://YOURDOMAIN.com", "description": "YOUR SHOP NAME is an independent coffee shop in YOUR NEIGHBORHOOD OR CITY serving SHORT HONEST DESCRIPTION OF WHAT YOU DO.", "image": "https://YOURDOMAIN.com/YOUR STOREFRONT IMAGE.jpg", "logo": "https://YOURDOMAIN.com/YOUR LOGO IMAGE.jpg", "telephone": "YOUR PHONE NUMBER", "address": { "@type": "PostalAddress", "streetAddress": "YOUR STREET ADDRESS", "addressLocality": "YOUR CITY", "addressRegion": "YOUR STATE", "postalCode": "YOUR ZIP", "addressCountry": "US" }, "geo": { "@type": "GeoCoordinates", "latitude": "YOUR LATITUDE", "longitude": "YOUR LONGITUDE" }, "openingHoursSpecification": [ { "@type": "OpeningHoursSpecification", "dayOfWeek": ["Monday","Tuesday","Wednesday","Thursday","Friday"], "opens": "YOUR OPEN TIME", "closes": "YOUR CLOSE TIME" }, { "@type": "OpeningHoursSpecification", "dayOfWeek": ["Saturday","Sunday"], "opens": "YOUR WEEKEND OPEN TIME", "closes": "YOUR WEEKEND CLOSE TIME" } ], "sameAs": [ "YOUR GOOGLE BUSINESS PROFILE URL", "YOUR INSTAGRAM URL", "YOUR FACEBOOK URL" ] }
Count the values you need to replace: name, url, description, image, logo, telephone, the five parts of the address, latitude, longitude, the hours entries, and the sameAs list. That is the eight core values the brief behind this post asks for, plus the smaller repeated fields inside the address and hours objects. None of them are optional if you want the block to describe your actual shop rather than a placeholder shop.
Do not include an aggregateRating or review property in this block. Even if your shop has real reviews on Google, fabricating or copying rating numbers into your own site's schema without a genuine, current source behind them is exactly the kind of invented markup this post's own rules forbid, and it can create a mismatch between what your page visibly shows and what the schema claims, which is a problem validators and search engines both flag.
Where to Paste It
This block belongs once, and only once, on your homepage, inside the page's head section if your builder lets you edit the head directly, or in a custom code or embed block that outputs into the page if it does not. It should describe the whole business on the homepage, not be duplicated across every inner page of your site.
Different builders expose this differently. A site built with a raw HTML head lets you paste the script tag directly. A site built on a platform with a dedicated custom code or code injection area, the kind of feature offered by many popular website builders, lets you paste it into that area, which the platform then inserts into the page's head automatically. If your builder blocks custom code entirely on the plan tier you are using, that is a real limitation worth knowing about before you spend time on this.
Wrap the block in a script tag with a type attribute of application/ld+json, since that is what tells a browser and a search engine that the enclosed text is structured data, not visible content or a script to execute. The block itself should never appear as visible text on the page. If you paste it correctly and it shows up as text a visitor can read on your homepage, it has been placed in the wrong spot and needs to move into an actual head or code injection area instead.
Check, before you publish, that every value inside the block also appears somewhere visible on the page itself. If the schema says your shop opens at a certain time but your visible hours say something different, or if the schema lists an address that is not the one printed on your page, that mismatch is a real problem, not a small one. Structured data is supposed to describe what a page already says, and a page that disagrees with its own schema undermines the whole point of adding it.
Testing the Block
Once the block is live on your homepage, paste your page's URL into Google's Rich Results Test and, separately, into the Schema Markup Validator. Both tools crawl the live page and report back what structured data they found, along with any errors or warnings. On September 21, 2026, the example block above was run through both and returned no errors.
Read every warning, not just errors. A warning usually means the markup is technically valid but missing a recommended property, which is worth adding if you can, but will not break anything if you leave it out for now. An error means something is wrong, a missing required field, a malformed value, or a type mismatch, and that needs fixing before the schema is doing its job correctly.
After the validator passes, do one more manual check: open your homepage in a normal browser tab, side by side with the validator's parsed output, and confirm every value matches what a visitor sees. This is the same check mentioned in the placement section above, worth repeating here because it is the single most common way a schema block quietly goes stale, an owner changes their hours or moves locations on the visible page and forgets the schema block sitting in the code was never updated to match.
Rerun both validators any time you change something the schema describes, your hours, your address, your phone number, or your image files. Validators do not watch your site continuously, they only report on what they find the moment you run them, so a block that passed once is not guaranteed to still be accurate months later if your shop's details have changed since.
Common First Time Errors
A first pass at pasting this block rarely comes out perfectly, and knowing the handful of common mistakes ahead of time saves a round of confused troubleshooting. The most frequent one is a missing or mismatched quotation mark somewhere inside the block, often introduced by a word processor or a page builder's text field automatically converting a straight quote into a curly one, which breaks the JSON syntax entirely. Paste the block into a plain text editor first, not a word processor, to avoid this.
A second common error is leaving a trailing comma after the last item in a list or object, which some validators tolerate and others reject outright. Read through the block once, slowly, checking that each comma sits between two items and that the very last item in any list or object has no comma following it.
A third mistake is placing the block outside the head section entirely, inside a footer widget or a text block meant for visible content, which either causes it to render as literal text on the page or causes the platform to strip it out before publishing. If a validator reports finding no structured data on your page at all, this is usually the reason, and the fix is checking exactly where the code injection or custom head area outputs to on your specific builder.
A fourth mistake, more subtle than the first three, is copying an example block from a different kind of business, a restaurant or a retail store, without updating the @type value to CafeOrCoffeeShop, or without removing properties that do not apply to a coffee shop. Read the block once fully after pasting it, not just the individual values you changed, to confirm every line still makes sense for what your shop is.
Related Reading
More from Hillcane on this topic, plus the pages on the site that sit next to the work.
The Cafe Schema Gap: Absent, Generic Only, and Real Place Markup
The Carolinas Secondary Corridor and Other Geographic Patterns
The State of Specialty Coffee Visibility in North America (2026)
Google Business Profile for Coffee Shops: The Complete 2026 Checklist
Who Owns the First Page for Best Coffee Searches in 264 Cities
Frequently Asked Questions
What goes in homepage schema?
At minimum, your shop's name, url, description, address as a nested PostalAddress object, geographic coordinates, phone number, and opening hours as one or more OpeningHoursSpecification entries. Recommended additions include an image, a logo, and a sameAs list pointing to your Business Profile and social accounts. Price range and review ratings are optional and this post leaves both out.
Do I need a developer to add this?
Not necessarily. If your website builder offers a custom code or code injection area for the page head, you can paste the block yourself. If your builder blocks custom code on your current plan tier, that is a real limitation to be aware of before starting, and may require a developer or a plan change to work around.
Where exactly should the code go?
Once, in the head section of your homepage, wrapped in a script tag with type application/ld+json. It should never render as visible text on the page. If you can read the code as text when viewing your homepage normally, it has been placed incorrectly and needs to move into the actual head or a code injection area.
Does adding schema improve my ranking?
No claim like that is made here. Schema is a translation layer that helps machines read facts your page already states in plain text, such as name, address, hours, and phone; Google's Local business structured data documentation, read September 21, 2026, does not present it as a ranking factor on its own. Treat the block as a clarity improvement, and make sure every value in it matches what visitors see on the homepage.
Should I include review ratings in my schema?
No. This example deliberately leaves out aggregateRating and review properties. Copying rating numbers into your own site's schema without a genuine, current, verifiable source creates a mismatch between what the page shows and what the markup claims, which validators and search engines can flag. Even real Google reviews do not justify pasting numbers into the block. Keep it to verifiable facts such as name, address, geo, telephone, openingHoursSpecification, and sameAs.
How do I check if my schema is valid?
Paste your live homepage URL into Google's Rich Results Test and, separately, the Schema Markup Validator. Both crawl the page and report errors and warnings. Fix errors, such as a missing required field, a malformed value, or a curly quote breaking the JSON, before relying on the block. Warnings usually flag a missing recommended property. The example block here returned no errors in both tools on September 21, 2026. Then compare the parsed output against the visible page.
What if my hours change after I publish this?
Update the openingHoursSpecification entries to match, one entry per set of days, such as Monday through Friday and a separate Saturday and Sunday entry, then rerun the Rich Results Test and the Schema Markup Validator. A schema block only reflects what was true when written and will not change itself if your visible hours change. The same applies to your address, phone number, and image files: edit the block whenever the page changes.
Can I use the same schema block on every page of my site?
No. This homepage block describes the whole business and belongs once, on the homepage, inside the head section or a custom code or code injection area that outputs there. Inner pages, such as an events page, may warrant their own more specific schema types, but duplicating this CafeOrCoffeeShop block everywhere is not the intended use. If a validator finds no structured data at all, check where your builder's code area outputs.
What is the geo property for?
The geo property is a nested GeoCoordinates object holding your shop's latitude and longitude as separate numeric values. It gives machines a precise point for your location, distinct from the text address, which is its own PostalAddress object split into streetAddress, addressLocality, addressRegion, postalCode, and addressCountry. Some tools use both together to confirm where you are. In the example block, replace YOUR LATITUDE and YOUR LONGITUDE with real coordinates before publishing.
Why does every value need to match the visible page?
Structured data is meant to describe what a page already says in plain text, not add new claims. If the schema states an address, phone number, or hours that differ from what a visitor sees on the page, that mismatch undermines the purpose of the markup and is something validators and search engines can flag.
Work with Hillcane
One complete, copy ready JSON LD block for a cafe homepage, explained property by property, so you know exactly what you are pasting and why.
If you want your homepage schema built, validated, and matched to your real page content, reach Hillcane at hillcane.co/contact or call (256) 384-2449.



Comments