Testing Your Cafe Schema in the Rich Results Test
You wrote schema markup for your cafe, or someone handed you a block of code and told you to paste it in, and now you have no real way to know whether it actually works. Two free tools exist for exactly this, and the confusing part is that people talk about them as if they are interchangeable when they answer two quite different questions.
Short answer: the Rich Results Test, run at search.google.com (Rich Results Test) as of September 21, 2026, tells you clearly whether Google can read your markup for a specific, supported rich result feature. The Schema Markup Validator, at validator.schema.org, separately tells you whether your markup is valid schema.org, independent of whether Google supports a visual feature for that type at all. Run the Rich Results Test first, since it is the one tied to what Google does with the markup, then run the Validator to catch anything structurally wrong that the first tool might not flag.
This post walks through both tools, a step by step run using a fictional cafe page, how to read what comes back, and the fixes worth trying first. It does not repeat what specific warnings are safe to ignore or the most common mistakes on cafe sites, since those live in their own posts and are linked from here. It also does not cover Search Console's own structured data reports, which track markup over time across a whole site rather than testing one page at a time, and which have their own separate coverage.
Tools
Two different tools, two different jobs. The Rich Results Test, documented on Search Console Help and reachable directly at search.google.com (Rich Results Test), checks a URL or a pasted code snippet against the specific structured data types Google currently supports for a visual search feature, and reports whether the page is eligible, per the page's own results screen as read on September 21, 2026.
The Schema Markup Validator, run at validator.schema.org, checks structured data against the schema.org vocabulary itself, regardless of whether Google, or any other consumer of schema, currently builds a visible feature from that particular type. It is the more general of the two tools, useful for confirming your JSON is well formed and uses schema.org properties correctly even for types the Rich Results Test does not evaluate.
Here is why using only one tool leaves a gap. A block of markup can be perfectly valid schema.org, passing the Validator cleanly, while still showing no eligible items in the Rich Results Test, because Google simply has not built a rich result feature for that particular combination of type and properties. The reverse is also true: a page can show up as eligible in the Rich Results Test for a supported type while the Validator flags a technically incorrect property elsewhere in the same block that has nothing to do with that specific feature.
Running both, in the order Rich Results Test first, then Validator, gives you the fuller picture: what Google can currently do with this markup, and whether the markup itself is technically sound. Treat the first as the practical, Google specific check and the second as the technical, standards level check.
It helps to think of the Rich Results Test as answering a narrower, more urgent question and the Validator as answering a broader, more thorough one. If your only goal is knowing whether a specific feature you care about, such as your cafe showing up with structured hours or a FAQ style result, is currently possible with your markup, the Rich Results Test alone gets you most of the way. If you want confidence that the underlying code is genuinely correct, not just correct enough for one feature Google currently supports, the Validator is the one that catches issues the first tool has no reason to flag.
Steps
Using a fictional page, call it a sample cafe's home page carrying a CafeOrCoffeeShop block with name, address, hours and a menu link, here is the sequence. Open the Rich Results Test and choose the URL option if the page is live and public, or the Code option if you want to paste the raw JSON LD directly. As read on the tool's own interface September 21, 2026, the entry screen shows a single field labeled to enter a URL, with a toggle to switch to Code.
Submit the URL or code and wait for the result screen. For a live URL, the tool needs the page to be publicly reachable, not blocked by a login wall or a robots rule; if it is blocked, the tool reports that plainly rather than silently failing, and that message should be read carefully since it points to a crawling problem, not a markup problem.
Once the test completes, the result screen shows a summary at the top, either listing detected structured data items by type or stating that no items were detected, followed by a details section for each detected item showing whether it is valid, has warnings, or has errors. Click into an item to see the individual properties Google parsed from your markup.
Repeat the same block through validator.schema.org by pasting the code directly. The Validator's output is organized differently, listing the schema.org types found and flagging any property that does not match the schema.org vocabulary for that type, again split into errors and warnings. Compare the two sets of results side by side rather than trusting either one alone.
For a cafe just starting this process, it is worth running the test on more than one page before assuming the site is done. A homepage carrying a CafeOrCoffeeShop block might pass cleanly while a separate menu page, an about page, or a location page for a second address carries no markup at all, or carries a different, less complete version of it. Testing each page individually, rather than assuming what passed once applies everywhere, catches this kind of unevenness early, and it is a five minute check per page once you have the workflow down.
Reading
Both tools separate findings into different severities, and the language matters. The Rich Results Test distinguishes items that are valid and eligible for a rich result, items with warnings, meaning the item is still eligible but a recommended property is missing, and errors, meaning a required property is missing or malformed and the item is not eligible for that feature.
The Schema Markup Validator uses a similar split between errors, meaning something in the code does not conform to the schema.org vocabulary for that type, such as a property that does not exist for that type, and warnings, meaning the markup is technically valid but missing a recommended property. An error in the Validator is a schema.org level problem; an error in the Rich Results Test is specifically about eligibility for a Google feature.
A clean result in either tool is not a guarantee of anything visual appearing in search results. Google's own documentation on the Rich Results Test states that passing the test means the markup is eligible, not that a rich result feature will definitely display, since Google makes its own separate determination about whether and when to show a given feature. Treat a pass as removing a blocker, not as a promise of display.
Watch for one more distinction: testing a live URL versus testing pasted code can produce different results if your page builds or injects the schema markup with a script after the initial page load. Both tools can fetch and render a URL, but if a script only adds the markup after user interaction or a delayed load, the tool may not see it the same way, or at all, depending on how the render step behaves. If you are unsure whether your platform outputs schema directly in the page source or through a script, testing both a URL and the raw code snippet is worth doing to see if the results differ.
This script rendered case matters more than it sounds like it should for a small cafe site, because some website builders and plugins that add schema markup do so through a script rather than writing it directly into the page's source code. If a tool cannot see markup added that way, the fix is usually not the markup itself but how and when it gets added to the page, which is worth flagging to whoever built or maintains the site if the results look inconsistent between the URL and code tests, rather than assuming the markup itself is wrong and rewriting something that was already correct.
Fixes
When a test comes back with problems, three fixes cover most cases before anything more complicated. First, check for a missing required property. A CafeOrCoffeeShop or LocalBusiness type commonly needs a name, an address in the correct nested format, and often a way to identify the specific location; a missing required field shows up as an error in the Rich Results Test, not just a warning, and blocks eligibility entirely.
Second, check for invalid JSON syntax, a stray comma, a missing closing bracket, or quotation marks that do not match. This is a purely mechanical error and both tools will usually flag it immediately and clearly, often before evaluating anything about the schema.org vocabulary at all, since the code has to parse as valid JSON before either tool can assess its structured data content.
Third, check for a property assigned the wrong type of value, such as a phone number formatted as a nested object when the schema expects a plain text string, or a URL field pointing to something that is not a valid, reachable link. These wrong type errors are common when markup is copied from a template built for a different kind of business and adapted without fully checking every field against the correct format for a cafe.
After making a fix, retest rather than assuming the change worked. Both tools update instantly on a new run, and rechecking the exact same page or code block after each change is the only reliable way to confirm an error cleared rather than simply changed form. Keep a simple before and after note of what you fixed and what the result showed, since tool interfaces change over time and reviewing your own history is more useful than remembering the exact screen from months earlier.
One habit worth building alongside these three fixes is testing again after any larger site change, not just when you first add markup. A platform update, a template swap, or a redesign can quietly change how schema gets output on a page even when nobody intended to touch it, and the only way to catch that kind of drift is to run the same test again periodically rather than assuming a pass from months ago still holds today.
Related Reading
More from Hillcane on this topic, plus the pages on the site that sit next to the work.
Frequently Asked Questions
How do I test my cafe's schema markup?
Run the page's URL or the raw code through the Rich Results Test at search.google.com (Rich Results Test) first, since it checks whether Google can read the markup for a supported feature. Then run the same code through the Schema Markup Validator at validator.schema.org to confirm it is technically valid schema.org, independent of any Google feature.
What is the difference between the Rich Results Test and the Schema Markup Validator?
The Rich Results Test, at search.google.com, checks whether your markup is eligible for a specific visual feature Google currently supports. The Schema Markup Validator, at validator.schema.org, checks whether the markup conforms to the schema.org vocabulary in general, whether or not Google builds any feature from that type. A CafeOrCoffeeShop block can pass one and still show issues in the other, so run the Rich Results Test first, then the Validator.
Does passing the Rich Results Test guarantee my cafe will show a rich result?
No. Google's own documentation on the Rich Results Test, read September 21, 2026, says a pass means the markup is eligible, not that a rich result will definitely display, since Google decides separately when and whether to show a feature. Treat a clean result as removing a blocker. Then run the same block through validator.schema.org as well, because eligibility for one feature says nothing about errors elsewhere in the markup.
Why does my markup pass one tool but show issues in the other?
Because the two tools check different things. The Validator can flag a technically incorrect schema.org property that has nothing to do with the specific feature the Rich Results Test evaluates, and the Rich Results Test can show no eligible items simply because Google has not built a visual feature for that combination of type and properties, even if the markup is otherwise valid.
What is the difference between an error and a warning in these tools?
An error means a required property is missing or malformed, and the item is not eligible in the Rich Results Test, or does not conform to schema.org in the Validator. A warning means the item is still valid or eligible, but a recommended, non required property is missing. Fix errors first; treat warnings as optional improvements.
Can I test a page before it goes live?
Yes, by pasting the raw code snippet into either tool's Code option rather than entering a live URL. This lets you check markup before publishing, though you should also retest the live URL once the page is published, since rendering and script behavior can sometimes differ between a code snippet and the actual live page.
Why does the Rich Results Test say it could not access my page?
This usually means the page is blocked by a robots rule, sits behind a login, or the tool could not reach it for another crawling related reason. Read the exact message the tool gives, since it points to a crawling or access problem rather than a markup problem, and the fix is different for each cause.
Will these tools see schema added by a script after the page loads?
It depends on how and when the script adds the markup. Both tools attempt to render the page, but markup added late, after user interaction or a delayed script, may not always be captured the same way as markup present directly in the page source. If your platform generates schema through a script, test both a live URL and the raw code to compare results.
Do these tool interfaces change over time?
Yes. Both interfaces can change, so note the date whenever you record what a screen or label says. The labels in this post reflect what each tool showed on September 21, 2026: the Rich Results Test entry screen had a single URL field with a toggle to switch to Code. Keep a simple before and after note of each fix and its result rather than relying on memory.
How can Hillcane help with cafe schema testing?
Hillcane can build and test structured data for your cafe site, running each page, not just the homepage, through the Rich Results Test and validator.schema.org, then fixing the usual causes: a missing required property such as the nested address, invalid JSON syntax, or a value of the wrong type. It also checks whether script injected markup shows up in both tools. Reach out at hillcane.co/contact or call (256) 384-2449.
Work with Hillcane
You pasted schema into your cafe's site and have no idea if it actually works. Two free tools answer two different questions, and most owners only ever run one.
If a schema test is coming back confusing or you are not sure which errors actually matter, Hillcane can walk through it with you. Reach out at hillcane.co/contact or call (256) 384-2449.
Comments