Structured Data Testing and Debugging: Rich Results Test and Error Triage
1. How the Two Testing Tools Split the Work
Many teams think they are done once Schema is on the page, then find GSC lit up red. Structured data debugging takes two tools, each covering its own part.
Use the Rich Results Test for a single page: paste a URL or a code snippet and see whether that page can generate rich results. Use the Schema Markup Validator to check whether the JSON-LD itself is valid.
| Tools | What it tests | When to use it | Limitation |
|---|---|---|---|
| Rich Results Test | Rich result eligibility for a single page | Test page by page before launch | Only tests the page you paste |
| Schema Validator | JSON-LD syntax validity | Check locally while writing code | Does not mean Google will actually show it |
| GSC rich results report | Validated pages across the whole site | Check weekly after launch | Data lags by 2 to 3 days |
For how to choose a Schema type and which fields it has, see Structured data (Schema) and The Complete Structured Data Schema Checklist. This article covers how to test once it is written and how to troubleshoot when something is wrong.
It is normal for the three tools to report differently: a local test may pass, but GSC can take 2 to 3 days to reflect it. Do not jump to conclusions just because it passed locally.
2. Errors vs. Warnings: Which to Fix First
Every notice in a debugging report needs to be graded. Treating warnings as errors and fixing them one by one will waste days.
| Tier | Meaning | Affects rich results? | Fix priority |
|---|---|---|---|
| Error | Required field missing or wrong type | Yes, rich results are dropped outright | Fix immediately |
| Warning | Recommended field missing | No, can still be shown | Schedule it |
| Info | Suggestion for an optional field | No | Add when you have time |
Counterintuitive but true: about 80% of the notices in the report are warnings. Google flags recommended fields like a missing author or date in yellow, but the page is still eligible for rich results.
What actually makes rich results disappear are errors: for example, using the Article type without a headline, or writing a date as a string instead of ISO format. These two must be fixed first.
Example: a blog site showed 120 pages with issues in GSC, and at first glance it looked like a total loss. After grading, 110 pages were warnings for a missing image, and only 10 pages had a datePublished format error. Fix the 10 hard errors first, and a week later rich results recovered to 80%, while the warning batch kept showing results as usual.
If your team uses CMS templates, some errors show up in bulk. Fix a field in one template and the whole batch of pages recovers after the next crawl, no page-by-page edits needed. That is why you should fix errors first: one template change does the work of manually fixing dozens of pages.
Warnings, by contrast, are usually tied to individual pages. A missing author or missing featured image is a per-page issue, so you can only schedule them and fill them in over time.
How to troubleshoot the four most common error types
The structured data errors B2B sites hit most often fall into four categories, ranked below by how frequently they occur.
| Error type | What it looks like | How to troubleshoot | Fix |
|---|---|---|---|
| Wrong field type | Date written as 2026/10/08 | Check whether it is ISO 8601 | Change it to 2026-10-08 |
| Wrong nesting level | Review sits outside Product | Check the @graph structure | Nest Review inside Product |
| Missing required field | Article has no headline | Compare against the official field list | Add the required field |
| Duplicate across multiple URLs | Every paginated page is marked Article | Check where canonical points | Mark only the main article |
Date format is the most common error. Google requires ISO 8601, meaning 2026-10-08, not 10/08/2026 and not Oct 8, 2026. One slash can strip rich results from an entire batch of pages.
Pagination is another easy-to-miss error. If page 2 and page 3 of a series are also marked Article, Google treats them as duplicates and keeps only the canonical one. Either remove the markup from the other pages or switch them to CollectionPage.
For how to earn and maintain rich results, see Rich result optimization; for entity markup, see Knowledge graph entity markup.
4. How to verify it actually took effect after launch
Passing a local test does not mean it works live. Structured data has a verification cycle, so you need the right method and some patience.
| Stage | Time | What you see | Action |
|---|---|---|---|
| Submit the fix | Day 0 | Click Request Validation in GSC | Do not keep editing |
| Request re-crawl | Days 1 to 7 | Report still shows Fixing | Wait |
| Review complete | Weeks 1 to 4 | Error count drops | Check the SERP for rich results |
| Ongoing monitoring | Monthly | Whether new pages are picked up automatically | Add to your technical audit |
Once you have clicked Request Validation, stop editing the code. Every edit resets Google’s review window, turning a two-week verification into six weeks.
After verification completes, search your target keyword on Google and check with your own eyes whether stars, FAQ accordions, and breadcrumbs actually appear in the SERP. GSC saying it is valid does not mean users can see it; some types only show for certain queries.
If GSC shows valid but you see no rich results in the SERP, first confirm whether that query triggers rich results at all. Some types only appear for navigational or informational queries, and may not show for transactional ones. Try a few related keywords and search again.
Ongoing monitoring matters too. Every time you publish a new page, check GSC a week later to see whether it was picked up automatically. If it was not, request a crawl once with the URL Inspection tool.
If you’re using a template-based site builder, add one check to your publishing workflow: run every new page through the Rich Results Test before it goes live, and only publish if it passes. It takes a minute and saves you from fixing pages in bulk after launch.
Rich results aren’t the goal. They just make your page stand out more in the SERP. Rankings still come down to content and backlinks. Structured data only amplifies a page that’s already good, lifting CTR by 10% to 20%.
So don’t get the order backwards: get your content ranking in the top 20 first, then add structured data to compete for rich results. If the content itself can’t rank, no amount of clean markup will earn you a single impression.
For the full technical SEO audit checklist, see Technical SEO audit checklist. Structured data is one item on it. For pre-launch checks, see Independent Site Launch Checklist.
5. Pitfalls: the three most common mistakes during debugging
There are three traps in structured data debugging. Step in one and you won’t just lose results, you may earn a manual penalty.
| Mistake | Consequence | The right way |
|---|---|---|
| Faking reviews to get star ratings | Violates structured data policies | Mark up only real reviews |
| Treating warnings as errors and fixing them all | Wastes days with no ranking gain | Fix errors first, schedule warnings |
| Passing locally, then editing every day | Resets the validation window | After submitting, wait 1 to 4 weeks |
The worst is faking star ratings. Google issues manual penalties for self-serving ratings and fake reviews. Get hit once and rich results are stripped sitewide, taking months to recover. Mark up only reviews that are actually visible on the page.
Structured data also helps AI crawlers. See GEO Technical Optimization. It isn’t about those stars. It’s about making your page entities readable to both search engines and AI.
FAQ
The Rich Results Test passed, so why are there still no rich results in search?
What’s the difference between errors and warnings in the GSC Rich Results report?
What’s the most common hard error in structured data?
After fixing structured data errors, how long until I see results?
Can I write a few positive reviews myself to get star ratings?
Does it matter whether JSON-LD goes in the head or the body?
Final thoughts
Debugging structured data isn’t about your ability to write Schema, it’s about patience. When the report is all red, triage first, 80% are warnings you don’t need to rush. After submitting fixes, wait 1 to 4 weeks, don’t change the code every day.
Three steps to implement: run a single page through the Rich Results Test; for the whole site, only fix the errors in the GSC rich results report first; after fixing, click Request Validation, then wait for Google to reassess, don’t redo work in the middle.
One line worth remembering: passing the structured data test is just your ticket in. Clicking validate in GSC, waiting the full four weeks, and seeing rich results with your own eyes in the SERP, only after these three steps is it truly live.