Schema for a Cafe Local Page: Copy Ready Fields and Tests

Thomas Garner

Oct 7

11 min read

Short answer: a cafe local page needs a small, accurate schema block, name, address, phone, hours, url, image, menu link and the correct business type, and it needs the data in that block to match the text visible on the page. That is the whole job. A long, inflated block full of fields the page never actually states does more harm than a short, correct one.

You built a local page for your shop, maybe for a neighborhood or a second location, and someone told you schema markup will help. You found an article, copied a block of code, pasted it in, and now have no idea what any of it actually does or whether it is even right. That is a common, understandable position, and it is fixable in one sitting.

This piece gives you a copy ready block with placeholders, explains each field and where its value comes from on the visible page, and walks through the two free tools that tell you whether the block works before you trust it.

The Fields That Actually Matter

For a cafe local page, the useful fields are few: the business name, the street address, the phone number, the hours, the page's own url, an image, a link to the menu, and the correct schema.org type describing what kind of business this is. That is eight things, not the forty or fifty properties some articles list as though every one of them is required.

Schema.org's CafeOrCoffeeShop type, sitting under the broader LocalBusiness and Restaurant family of types, is generally the closest match for an independent coffee shop, and it inherits the standard LocalBusiness properties like address, telephone, and openingHoursSpecification rather than needing entirely separate ones. The address itself uses schema.org's PostalAddress structure, broken into streetAddress, addressLocality, addressRegion and postalCode rather than one long string, and the hours use OpeningHoursSpecification, which separates the day of week from the opening and closing time rather than writing them as a single sentence.

The test for whether a field belongs in your block is simple: is it true, is it something you can verify by looking at the page itself, and does the page already say it in plain text somewhere a visitor would read. A field that exists only in the schema block and nowhere on the visible page is a mismatch waiting to be flagged, and it is also simply less useful, since the whole point of structured data is to describe content that is already there, not to invent content that only a machine will ever see.

A Copy Ready Block, Explained Field by Field

Here is a placeholder block built from exactly those eight fields, meant to be copied and then have every bracketed placeholder replaced with your shop's real, current information before it goes anywhere near a live page.

The @context and @type lines come first: @context is always https://schema.org, and @type is CafeOrCoffeeShop for a coffee focused business. The name field holds your shop's exact name, spelled and capitalized the same way it appears on the visible page, not a shortened or stylized version used only in a logo. The address field is a nested PostalAddress object, broken into streetAddress, addressLocality (the city), addressRegion (the state, as an abbreviation), and postalCode, each one matched exactly to what is printed on the page's contact section.

The telephone field holds the phone number in a consistent format, matching what is printed on the page rather than a different number used only on a business card. The url field points to this exact page, not the homepage, since this block is describing this specific local page. The image field holds a link to one representative photo of the shop, ideally the same photo already displayed on the page. The openingHoursSpecification field is an array, one entry per group of days sharing the same hours, each with dayOfWeek, opens and closes values written in the standard 24 hour time format. Finally, a hasMenu field can hold a direct link to your menu page if one exists separately, giving both a visitor and a machine one more accurate, verifiable fact about the business.

Every one of those eight fields should already have a home somewhere on the visible page before the schema block repeats it. If a field in the block does not have a matching, visible counterpart on the page, that is the signal to either add the information to the page itself first, or drop the field from the block entirely rather than leaving an orphaned, unverifiable claim sitting in code nobody but a machine will read.

Where Values Come From on the Page

Treat the visible page as the source of truth and the schema block as its translation, not the other way around. Before filling in the placeholder block, walk the actual local page top to bottom and note exactly where each of the eight fields is stated in plain text: the name in the page header, the address likely in a footer or a dedicated contact section, the phone number wherever it is printed or linked as a tap to call button, the hours in whatever format the page already displays them, whether that is a table or a simple list.

This matching exercise catches more problems than people expect. It is common for a page's visible hours to say one thing while an old schema block, pasted in months earlier from a different template, still lists a completely different set of hours from before a schedule change. The fix in that case is not a schema problem at all, it is an out of date content problem that happens to show up as a schema mismatch once you go looking for it.

Once every field has a confirmed, visible counterpart on the page, filling in the placeholder block becomes a straightforward copy exercise rather than a guessing game, and the block you end up with is one you can stand behind, because every value in it traces back to something a real visitor to the page can also see and verify for themselves.

Testing the Block Before You Trust It

Two free tools do this testing job well, and running a block through both, not just one, is worth the extra few minutes. Google's Rich Results Test checks whether a page's structured data is eligible for any of Google's enhanced search result features and flags errors or warnings specific to how Google parses the markup. The independent Schema Markup Validator at validator.schema.org checks the same block against the schema.org specification itself, which is a slightly different, broader check than Google's own tool runs, and it is useful for catching structural problems Google's tool might not flag directly.

Paste your finished block, or better yet the live page url once the block is pasted in, into each tool and read through what comes back. A clean result shows the type recognized correctly and every field parsed without error. Any warning or error message names a specific field, which makes fixing it a matter of returning to that one field rather than guessing at the whole block.

It is worth deliberately breaking a test block once, on a copy rather than the live page, just to see what each tool reports, since that familiarizes you with the difference between an error and a warning before you depend on either. Try three breaks, one at a time: remove the address, write the hours as a plain sentence instead of the structured openingHoursSpecification format, and change the phone number in the block so it no longer matches the one printed on the page. Note what each tool says for each break, and date the note, since both tools change over time. The third break is the instructive one. The tools check structure, not truthfulness, so a mismatched but well formatted phone number may sail through cleanly, which is exactly why the page to block matching exercise described above matters even when a tool reports no errors.

What Schema Does Not Do

A valid, error free schema block does not guarantee a rich result, meaning it does not guarantee your page shows up with any special visual treatment in search results, and it certainly does not guarantee any particular ranking position. What it does is give Google's systems, and any other tool parsing your page, a clean, structured, unambiguous version of information that is already sitting in your page's visible text. That is a real, worthwhile thing to provide. It is not the same thing as a promise of a specific outcome.

It is also worth being plain that review markup, meaning star ratings or review counts shown directly in a schema block, is left out of the copy ready template here entirely. That is deliberate. Review data the page owner controls or fabricates is not something to add through schema, and this template sticks to facts a cafe owner can state and verify directly about their own business: the name, the address, the hours, the phone number, the url, an image, and a menu link.

As background context only, a broader visibility census of more than 1,000 shops across six regions (snapshot September 15, 2026) tracks whether structured data is present, partial or absent across independent cafe sites: 337 present, 367 partial and 368 absent, with 37 left unclassified. Those figures describe the landscape, not any one page, and they say nothing about whether a given block is well built, only whether one exists at all. They are not a reason to rush a block onto a page without the matching and testing steps described above.

The Routine Worth Repeating

Once a local page's schema block passes both tools cleanly and every field has been matched against the visible page, the work is essentially done for that page, until something on the page itself changes, hours shift for a season, the phone number changes, a photo gets swapped. Any time the visible content changes, the schema block needs the same update, since a block that once matched the page and now does not is exactly the kind of mismatch this whole process exists to prevent.

For a cafe with more than one local page, whether that means multiple neighborhood pages or multiple physical locations, the same eight field template and two tool test routine applies to each page individually, since each page is describing a specific, distinct place, not a single business as a whole. A separate piece covers what changes once a shop specifically has more than one physical location, and this template is the right starting point for any single page within that larger structure.

The whole process, filling in eight fields from values already visible on the page, running the block through the Rich Results Test and the Schema Markup Validator, and confirming a clean result, is realistically an hour of focused work for a first page and considerably faster for every page after that, once the placeholder block and the habit of matching it to the visible page are already established.

It is worth saving a short note alongside the page, even a single line in a document you already keep, recording the date you last checked the block against the visible page and confirmed it in both tools. That note turns a full hour of matching and testing into a five minute confirmation the next time hours change or a phone line gets updated, since you will already know exactly which fields to revisit rather than rechecking all eight from scratch every time.

Frequently Asked Questions

What schema type should a cafe local page use?

Schema.org's CafeOrCoffeeShop type, which sits under the broader LocalBusiness and Restaurant family and inherits standard properties like address, telephone and openingHoursSpecification rather than needing separate ones. It is generally the closest documented match for an independent coffee shop's local page. Set it in the @type line, directly under an @context of https://schema.org, and keep the business name spelled exactly as the page header shows it.

What are the eight fields a cafe local page schema block needs?

Name, address as a structured PostalAddress with streetAddress, addressLocality, addressRegion and postalCode, telephone, hours as OpeningHoursSpecification entries, the page's own url, one image, a hasMenu link, and the correct schema.org type. Every one of those should already appear in plain text somewhere on the visible page before it goes into the block. A field with no visible counterpart gets added to the page first or dropped.

Does a valid schema block guarantee a rich result in Google search?

No. A clean, error free block gives Google's systems a clear, structured version of information already on the page, but it does not guarantee any special visual treatment in results or any particular ranking position. Schema describes content that is already there. Passing the Rich Results Test and the Schema Markup Validator confirms the block is readable, which is worth having, but it is not a promise of an outcome.

What tools should I use to test a cafe schema block?

Two free tools. Google's Rich Results Test checks eligibility for Google's enhanced result features and flags errors or warnings in how Google parses the markup. The independent Schema Markup Validator at validator.schema.org checks the same block against the schema.org specification itself, a slightly broader check. Run the live page url through both after pasting the block in, and read every warning by the field it names.

Why does the schema block need to match the visible page exactly?

Because the schema block is meant to be a structured translation of what a visitor can already see and verify on the page, not a separate set of claims. A mismatch, like an old set of hours left in the block after the visible page's hours changed, is a real accuracy problem even if a testing tool reports no structural error.

Should review star ratings be included in a cafe's schema block?

No. Review data a page owner controls, curates or could fabricate is deliberately left out of this template. The block sticks to facts a cafe can state and verify directly about its own business: the name, the address, the hours, the phone number, the url, an image and a menu link. Leave star ratings on the Google Business Profile, where customers leave them, and link to it.

Should I deliberately break a test block to learn the tools?

Yes, once, on a copy rather than the live page. Remove the address, then write the hours as a sentence instead of OpeningHoursSpecification, then mismatch the phone number against the page, one break at a time, and note what the Rich Results Test and the Schema Markup Validator each report. Date that note, because tools change. It teaches you what a real error looks like before you depend on a clean result.

Can a testing tool catch a wrong phone number in my schema block?

Not necessarily. These tools check the structure of the data, not whether it is true. A schema block can list a phone number that does not match the one printed on the page and still pass structural testing cleanly, which is why manually matching every field against the visible page still matters even after a clean tool result.

Does the census say how many cafe sites have correct schema?

No. A broader visibility census of more than 1,000 shops across six regions, snapshot September 15, 2026, tracks only whether structured data is present, partial or absent: 337 present, 367 partial, 368 absent and 37 left unclassified. It does not say whether any given block is accurate or well built, only whether one exists. Treat it as background context, not a grade on anyone's markup.

How can Hillcane help with schema for a cafe local page?

Hillcane can help build a copy ready schema block matched field by field to your actual local page, run it through the Rich Results Test and the Schema Markup Validator before it goes live, and leave you a dated note of what was checked so the next hours change takes five minutes instead of an hour. Reach out at hillcane.co/contact or call (256) 384-2449.

Work with Hillcane

You pasted a schema block you found in an article and have no idea if it is right. Here is a short, correct one, explained field by field, plus the two tests that tell you.

Want your cafe local page's schema checked or built from scratch? Reach Hillcane at hillcane.co/contact or call (256) 384-2449.