How to Test Schema Markup With Google Rich Results Test
The most useful thing to understand about testing is what a pass does not mean. A green result tells you the markup is well formed. It tells you nothing about whether what it says is true. Those are different questions.
Valid Is Not The Same As Correct
A test checks whether markup is well formed and whether a page qualifies for a particular appearance. It does not check whether the statements are true, which means you can assert something entirely untrue, perfectly formatted, then pass.
What the tools are checking. Form rather than truth.
Whether the description is structured properly, uses recognised terms and includes what a given appearance requires. All questions about shape, none about accuracy.
Why they cannot check truth. Nothing to compare against.
A tool reading a claim that a business opens at nine has no independent record of when it opens. Verification would require knowing the answer already, which would remove the need for the markup.
What that permits. Identical results for opposite situations.
A genuine rating from real customers and a fabricated one validate the same way. Correct hours and hours from two years ago produce the same green result. The tool cannot tell them apart and does not try.
Why the green result misleads. It feels conclusive.
A pass reads as completion. A business sees it, closes the tab and considers the work finished, having confirmed only that the false statement was well constructed.
What still has to happen. Somebody reads it.
The check that matters is a person confirming the markup is true of the page. Block eight covers it, because that is where this page ends up.
What The Tools Actually Check
Three questions, which between them describe everything the standard tools establish. Knowing the questions is more durable than knowing the interface, since interfaces change and the questions do not.
Does it parse. The basic one.
Whether the description is readable at all. Something malformed fails here. This is the only genuine break the tools detect, since everything beyond it is a matter of completeness.
Are the required properties present. Completeness.
Each appearance needs certain information before it can be produced. A description missing something essential is well formed and insufficient, which is reported as an error rather than a warning.
Is the page eligible for a particular appearance. The one people care about.
Whether the combination of type and properties qualifies the page for a specific enhanced result. This is the most useful answer available and block three explains its limit.
What none of them answers. Whether it is true.
No tool checks a value against the world. That absence is structural rather than an oversight. It is why accuracy remains a human responsibility.
Eligible Is Not The Same As Shown
Eligibility is the most a test can tell you. Whether the appearance actually happens is decided separately, at the moment somebody searches, which is why a passing test does not produce a result.
What eligibility means. Qualifying, no more.
The page has what is needed and is in the set that could be shown that way. That is a statement about the page rather than a prediction about any search.
What happens afterwards. A separate decision.
The query, the device and the competing results all bear on whether an enhancement is used. None of that is visible to a testing tool, which examined your page in isolation.
Why this generates so much confusion. The wording invites it.
A result saying a page is eligible for something reads as a promise. It is closer to confirming you have filled in the form correctly than to being told the answer is yes.
What a business should conclude from a pass. One thing.
That nothing on your side is preventing the appearance. That is genuinely worth confirming and it is the whole of what has been confirmed.
Where the rest of the answer sits. The troubleshooting page.
Valid markup with no visible result is the commonest situation in this subject. Why is my schema markup not working opens on it.
Test A Live Page And A Draft Differently
Checking a piece of code and checking a published page are different exercises. Markup added by a platform only appears in the second, which catches people out regularly.
What checking code establishes. That your own addition is sound.
Useful before publishing, when you want to know whether what you wrote is well formed. It examines only what you supplied.
What checking a published page establishes. Everything present.
The full picture, including whatever the platform, the theme and any extension contributed. That is the only view that shows what the site is genuinely asserting.
Why the difference matters. Generated markup is invisible beforehand.
A platform building descriptions from fields produces them when the page is served. Nothing about that appears in a draft, so a clean code check can precede a page carrying three conflicting descriptions.
Which to use when. Both, in order.
Check what you wrote before publishing, then check the published page afterwards. The second is the one that matters and the first prevents obvious errors going live.
Where this connects. The platform page.
What each platform contributes without being asked is covered in schema markup by platform.
Checking Across A Whole Site
A single test examines one page. The reporting available in a search console covers every page it has seen, which is where site-wide problems surface.
What the wider view adds. Pattern rather than instance.
One page failing is a page problem. Two hundred pages failing identically is a template problem. Only the aggregate view distinguishes them.
Why that distinction saves time. The fix differs entirely.
An individual page gets corrected. A template producing the same fault everywhere gets corrected once. Finding that out first prevents a great deal of page-by-page work.
What it does not do. Check accuracy.
The same limit applies. A site-wide report confirms that many pages are well formed. A wrong value repeated everywhere passes everywhere.
Where the mechanism sits. The other cluster.
How the reports work and how to operate them belongs in our Google Search Console material rather than here.
Warnings Are Not Errors
An error means something is wrong. A warning usually means a recommended property is absent. Chasing every warning to zero is rarely worth the effort and is regularly sold as though it were.
What an error indicates. Something required is missing.
The description cannot support the appearance it is aiming at. That is worth fixing, because until it is, the eligibility the markup exists for does not apply.
What a warning indicates. Something optional is absent.
A property that would add detail if you had it. The description works without it and the appearance remains available, so the warning is a suggestion rather than a fault.
Why warnings get treated as tasks. They come in a list.
Anything presented as a list of items reads as work to be completed. That is how a clean report becomes a project. It is also how suppliers generate billable work with no outcome attached.
When a warning is worth acting on. Two cases.
Where you genuinely hold the information and simply had not supplied it. And where the missing property is one that visibly affects how a result is presented.
When to leave it. Everything else.
A warning about something you do not have, else would have to invent, should stay a warning. Filling it with something approximate is exactly the false assertion this section refuses.
Test After Every Change
A redesign, a platform update or an extension change can alter markup silently. Nothing announces it, which makes a check after any change the only way to know.
What alters markup without warning. Four things.
A visual redesign, a platform or theme update, adding or removing an extension, then editing a template. None of them looks like a markup change and each can be one.
Why nothing tells you. No failure occurs.
Markup disappearing produces no error, no broken page and no complaint. The site continues working perfectly while asserting less than it did, else asserting something different.
The worst version. A rebuild.
Where descriptions were woven into the page rather than separated, replacing the page removes them. Our site migrations material covers what else goes missing during a rebuild.
What a check after a change costs. Very little.
Examining a handful of representative pages after any change is minutes of work. Discovering the loss a year later is considerably more expensive.
The Check A Tool Cannot Do
Somebody has to read what the markup asserts and confirm it is true of the page and of the business. No tool does this. It is the only check that addresses the thing that actually matters.
What the check involves. Reading the claims.
Going through each statement the description makes and asking whether it is currently true. Not whether it is well formed, which the tools settled. Whether it is accurate.
What to compare against. Two things.
The page itself, since everything asserted should be visible to a reader. And reality, since the page can be wrong too. A wrong phone number on both is consistent and still wrong.
Who should do it. Somebody who knows the business.
A developer can confirm the markup is sound and cannot know whether the hours are current. This check needs somebody who would notice a wrong address, which is rarely the person who implemented it.
How often. Periodically, plus after changes.
Values go stale on their own, so a check that only happens after edits misses everything that changed in the business rather than on the site.
Why it belongs to somebody. Otherwise nobody does it.
An unassigned check does not happen. Naming an owner is the difference between a policy and an intention. The full series is on the schema and structured data guide.
A pass checks
the form, not
the claim.
A fabricated rating and a genuine one validate identically, because nothing has anything to compare either against. Somebody who knows the business still has to read what the markup asserts and confirm it is true. That check needs an owner rather than good intentions.
On every page we build:
We will not bill you for driving a warning list to zero. Most of it changes nothing.
Every guide.
One practice.
What structured data is, which types apply to your business, how to test it, where the results features come from and what to do when nothing appears.
