How to Test Schema Markup and Check for Rich Results
Adding schema markup is only half the job. Until you test it, you do not know whether Google can parse it, whether it meets the rules for a rich result, or whether a plugin quietly broke it last week. There are two free tools that matter, Google's Rich Results Test and the Schema Markup Validator, and they answer different questions. Many people run one, see a green tick or an empty result, and draw the wrong conclusion. This guide shows you how to test schema markup properly: which tool to use for what, how to test code before it goes live and live URLs after, how to read errors and warnings, and how to confirm in Search Console that Google sees the same thing you tested.
- The two testing tools and what each one answers
- Testing a live URL or a code snippet
- Reading errors and warnings
- When the test finds nothing
- Confirming in Search Console
- Testing on WordPress, Shopify and headless sites
- The fix, step by step
- Edge cases worth knowing
- Keeping your schema tested
- Questions and answers
The two testing tools and what each one answers
Google's old Structured Data Testing Tool was retired, and its job was split in two. The general checker moved to Schema.org as the Schema Markup Validator, and Google kept the Rich Results Test for its own search features. Knowing which question each tool answers saves a lot of confusion.
| Question | Rich Results Test | Schema Markup Validator |
|---|---|---|
| Address | search.google.com/test/rich-results | validator.schema.org |
| Can Google parse my markup? | Yes | Yes |
| Is my page eligible for a Google rich result? | Yes, this is its main job | No |
| Does it check every Schema.org type? | No, only types tied to Google features | Yes |
| Does it flag misspelt or unknown properties? | Usually not | Yes |
| Does it render JavaScript? | Yes, as Google does | For URLs it fetches the page; test the rendered code if markup is injected late |
| Formats | JSON-LD, Microdata, RDFa | JSON-LD, Microdata, RDFa |
Use the Rich Results Test to answer will Google use this for a rich result? Use the Schema Markup Validator to answer is this correct Schema.org? A page can pass one and not the other, and both results can be right.
@context, @type and @id.Testing a live URL or a code snippet
Both tools offer two modes. Pick the one that matches where you are in the job.
Code mode: before you publish
Paste a JSON-LD block, or the full HTML of a page, and run the test. Use this while you are writing markup, on a staging site behind a password, or on a page running on your own computer, because neither tool can reach localhost or a login page. You can edit the code in the tool and run it again until it passes.
URL mode: after you publish
Enter the public address. The Rich Results Test fetches the page using the Google-InspectionTool crawler, renders it with the smartphone agent by default and tests what it finds. This catches problems that code mode cannot: a caching plugin that strips the block, a robots.txt rule that blocks the page, a theme that only prints schema on desktop, or JavaScript that fails to run.
- If the URL test shows no items but the code test passes, the markup is not reaching the rendered page. Open View tested page and search the HTML tab for
ld+json. - If the URL test reports the page could not be fetched, check robots.txt, firewall or bot protection rules, and the HTTP status. A page Google cannot fetch cannot be tested.
- If you have just changed the page, a cached copy may still be served. Purge your cache or CDN first.
To confirm what any crawler receives before JavaScript runs, check the raw response:
curl -sI https://example.com/products/rye-loaf/
curl -s https://example.com/products/rye-loaf/ | grep -c 'application/ld+json'The first line shows the status code; you want 200. The second counts the JSON-LD blocks in the raw HTML. Zero means the markup only exists after rendering, or not at all.
Reading errors and warnings
The Rich Results Test lists each rich result type it found, such as Product snippets, Breadcrumbs or Local business, and how many items of each. Open an item to see its properties and any issues against it.
| Result | Meaning | What to do |
|---|---|---|
| Valid item | Meets the required properties; eligible for that rich result | Nothing urgent. Consider recommended properties. |
| Valid with warnings (non-critical issues) | Eligible, but recommended properties are missing or malformed | Add the properties if you have the real data |
| Invalid item (critical issues) | A required property is missing or has the wrong kind of value | Fix before anything else; this item cannot produce a rich result |
| Unparsable structured data | The JSON or markup itself is broken | Fix the syntax; nothing in that block is read |
| No items detected | No markup found for a Google feature | Check the block exists, then check whether the type has a Google feature at all |
Each issue names the property, for example Missing field "offers" or Invalid value in field "priceCurrency". Click it and the tool highlights the line in the code. Fix one issue at a time and re-run, because one structural mistake can produce several messages.
The Schema Markup Validator shows errors and warnings in a similar way, but against the whole vocabulary. Its most useful finding is a property it does not recognise for that type, which usually means a typo such as adress or a property used on the wrong type.
For detail on specific messages, see fixing schema errors, fixing schema warnings and structured data syntax errors.
When the test finds nothing
An empty Rich Results Test is the most common surprise. Work through the causes in this order:
- The block is broken. Paste it into the Schema Markup Validator or a JSON validator. One trailing comma hides the whole block.
- The block is not on the tested page. Check the HTML tab under View tested page. Plugins sometimes only output schema on certain templates.
- The type has no Google rich result. Types such as
WebSite,WebPage,PersonorServiceare valid but have no rich result card, so the Rich Results Test does not list them. The Schema Markup Validator will. - The feature is restricted. Some features are limited to certain sites. FAQ rich results, for example, stopped appearing in Google Search on 7 May 2026, so a valid FAQPage block no longer leads to a visible result. See whether FAQ schema is still worth it.
The no rich results detected guide covers each of these with fixes.
Confirming in Search Console
The testing tools show what Google could see at that moment. Search Console shows what Google actually recorded when it crawled your site, across every page.
URL Inspection
Inspect a page and look under Enhancements or Enhancements & Experience for the structured data Google detected on the indexed version. Click Test live URL to run the same checks as the Rich Results Test against the current page. If the indexed version and the live test differ, Google has not recrawled since your change.
Enhancement reports
Search Console shows a report for each rich result type found on your site, such as Breadcrumbs, Product snippets, Merchant listings or Videos. Each lists invalid and valid items, groups them by issue and shows example URLs. A report only appears once Google has found that type on your site, so a missing report usually means no pages carry it.
After you fix an issue across a template, open it in the report and click Validate fix. Google recrawls the affected pages over the following days and updates the status. Validation can take up to about two weeks on a small site, longer on large ones.
Testing on WordPress, Shopify and headless sites
- WordPress: test one URL from each template: home, a post, a page, a category and, on WooCommerce, a product. SEO plugins often output different types per template, and a second plugin may duplicate them. See debugging schema on WordPress.
- Shopify: test a product with variants, a product that is sold out and a collection page. The theme and any reviews or SEO apps may each print a Product block. See debugging schema on Shopify.
- Next.js, React and other headless builds: test the live URL, not only code, because the problem is often that markup is added on the client and missing from the server response. See debugging schema on headless sites.
Whatever the platform, a single URL proves little. Templates are what break, so test one page per template and record the result.
The fix, step by step
Step 1
List one URL per template
Write down one representative public URL for each page template on your site: the home page, a blog post, a standard page, a category or collection, a product, a contact or location page. Templates share markup, so testing one of each covers the site far better than testing ten blog posts. Note which schema types you expect on each. You know this step is done when every template has a URL and an expected type, such as Product or BreadcrumbList.
Step 2
Run the Rich Results Test by URL
Open the Rich Results Test at search.google.com/test/rich-results, choose URL, paste the first address and run it with the default smartphone crawler. Wait for the result, then note each detected rich result type and whether its items are valid, valid with non-critical issues or invalid. Repeat for each template URL. If the test says the page could not be fetched, check robots.txt, bot protection and the HTTP status before going further.
Step 3
Check the rendered HTML
On any URL that shows no items or fewer than expected, click View tested page and open the HTML tab. Search for ld+json to see whether the markup is in the rendered page. Then run curl -s against the URL and count the blocks in the raw response. If the block appears only after rendering, or not at all, the cause is your theme, plugin or caching, not the markup itself. Fix delivery first.
Step 4
Fix critical issues first
Open each invalid item and read the critical issues. Each names a property, such as a missing offers or an invalid priceCurrency. Click the issue to highlight the line, correct it in your template, plugin settings or theme file, and clear your cache. Fix one issue at a time and re-run the test after each, because a single structural error often produces several messages. Carry on until every expected item for that template shows as valid.
Step 5
Review non-critical issues
Read the warnings on valid items. These are recommended properties that are missing or malformed. Add a property only when the real value already appears on the page, for example an image or a brand. Leave a warning in place rather than inventing data. Re-run the test after changes. The aim is valid items carrying every recommended property you can honestly supply, not a result with zero warnings at any cost.
Step 6
Validate with Schema.org
Paste each template URL, or its code, into the Schema Markup Validator at validator.schema.org. Look for unknown properties, properties placed on the wrong type and types that the Rich Results Test did not list, such as WebSite, WebPage or Service. Correct any typos or misplaced properties in the source. When the validator shows every object with the expected type and no errors, the markup is correct as Schema.org as well as for Google.
Step 7
Test in code mode before deploying
When you write a new template or change existing markup, paste the full HTML or the JSON-LD block into the code tab of the Rich Results Test before it goes live. This works for staging sites, password-protected previews and pages on your own computer, which the URL mode cannot reach. Fix any issue in the tool, copy the corrected code back to your template, and only deploy once the code test shows valid items.
Step 8
Confirm in Search Console
After deploying, open URL Inspection in Search Console for one page per template and click Test live URL to confirm Google sees the same items. Then open the matching enhancement report, such as Product snippets or Breadcrumbs, select any issue you have fixed and click Validate fix. Google recrawls the affected pages over the following days. The fix is confirmed when validation passes and the invalid item count falls.
Edge cases worth knowing
- Smartphone and desktop results differ. If your theme serves different HTML by device, switch the crawler in the Rich Results Test settings and test both. Google indexes the mobile version.
- Testing too soon after a change. Server caches, CDNs and optimisation plugins can serve an old page for hours. Purge first, then test.
- Bot protection. Security plugins and firewall rules that challenge unknown visitors can block the testing tool. If the screenshot shows a challenge page, allow Google's crawlers through.
- Duplicate items. Two Product items for one product usually mean the theme and an app both add markup. The test passes, but the data may conflict. See multiple schema blocks.
- Valid is not the same as shown. Passing makes a page eligible. Google still decides per search whether to show a rich result.
Keeping your schema tested
Schema breaks quietly. A theme update, a new app or a change to how prices are stored can remove or damage markup with no visible sign on the page. Build testing into routine work:
- Keep a list of one test URL per template and run it through the Rich Results Test after every theme, plugin or app update.
- Check the enhancement reports in Search Console once a month for new invalid items.
- Test code in code mode before deploying a new template, then test the live URL straight after.
- Use a crawl-based checker to test every page, not a sample. The schema debugger guide shows how to scan a whole site in one run.
1. How do I test schema markup?
Test schema markup by running the page URL, or the code itself, through Google's Rich Results Test and the Schema Markup Validator. The Rich Results Test shows whether Google can use the markup for a rich result and lists any critical or non-critical issues. The Schema Markup Validator checks the markup against the whole Schema.org vocabulary and catches misspelt properties. Test one page per template, then confirm in Search Console with URL Inspection and the enhancement reports once Google has recrawled the pages.
2. What is the best schema markup testing tool?
There is no single best tool; you need two, because they answer different questions. Google's Rich Results Test is the authority on whether markup is eligible for Google rich results, and it renders JavaScript the way Google does. The Schema Markup Validator, run by Schema.org, checks every type and property, including types that Google has no rich result for. Use both on every template, and use a crawl-based checker when you need to test every page on a site rather than a handful.
3. What happened to Google's Structured Data Testing Tool?
Google retired the Structured Data Testing Tool and moved its general validation to Schema.org, where it became the Schema Markup Validator at validator.schema.org. Google kept the Rich Results Test for checking its own search features. The validator looks and behaves much like the old tool, accepting a URL or pasted code and listing every type found. If an old guide tells you to use the Structured Data Testing Tool, use the Schema Markup Validator instead, alongside the Rich Results Test.
4. Why does the Rich Results Test show no items when my schema is valid?
Most often the schema type you used has no Google rich result, so the Rich Results Test has nothing to list. Types such as WebSite, WebPage, Person and Service are valid and useful, but they do not produce a rich result card. Check the same URL in the Schema Markup Validator; if your items appear there, the markup is fine. If they do not appear in either tool, the block is broken or missing from the page Google fetched.
5. Can I test schema on a staging or local site?
Yes, but only in code mode. Neither the Rich Results Test nor the Schema Markup Validator can reach localhost, a password-protected staging site or a page that needs a login, so paste the page HTML or the JSON-LD block into the code tab instead. This tests the markup itself. Once the page is live, test the public URL as well, because caching, robots.txt rules or JavaScript problems on the real server can stop markup that passed in code mode from reaching Google.
6. Do warnings in the Rich Results Test matter?
Warnings do not stop a rich result; they mean recommended properties are missing or malformed, and the item is still eligible. Adding the missing properties can make a rich result more complete, so fill them when the real information is on the page. Do not add made-up values to clear a warning, because markup must match visible content under Google's guidelines. Critical issues are different: they make an item invalid, so fix those first and treat warnings as improvements.
7. How long does Search Console take to show schema fixes?
Search Console updates after Google recrawls the affected pages, which usually takes from a few days to around two weeks on a small site. Use URL Inspection with Test live URL to check a page straight away, then click Validate fix in the enhancement report so Google prioritises rechecking the affected URLs. The report shows validation as started, then passed or failed. Large sites, or pages Google visits rarely, can take longer to clear from the report.
The schema debugger on aiwebpageseo.com crawls your pages, extracts every structured data block and reports parse failures, missing required properties and duplicate items template by template, so you see what one-URL tests miss.
Open Schema Debugger Fixes →