How to Test Schema Markup and Fix Structured Data Errors

Why should you test Schema markup?

Structured data is code, and small defects can change or destroy its meaning. A missing comma can prevent a JSON-LD block from being parsed. A correctly formatted value can still fail Google's rules if a required property is absent. Valid markup can also describe information that does not agree with the visible page.

Testing helps answer several different questions:

1. Can the markup be parsed?
2. Does it use recognised Schema.org types and properties?
3. Does each property contain the expected kind of value?
4. Does it satisfy the rules for a supported Google search feature?
5. Is it present in the rendered live page?
6. Does it describe the same information visitors can see?
7. Has it been published consistently across the intended template?

No single result answers all seven. A useful process combines validation tools, live-page checks, Search Console and a complete site crawl.

Testing before publication prevents obvious defects from spreading. Testing after publication catches problems introduced by rendering, caching, plugins, optional fields and deployment. Ongoing monitoring finds failures caused by later template or content changes.

Which Schema markup validator should you use?

The main tools serve different purposes:

Use the Rich Results Test for Google search features

Choose Google's Rich Results Test when the goal is Product, Article, Breadcrumb, LocalBusiness or another feature in Google's supported structured-data gallery.

The tool can test a public URL or a code sample. It reports detected items, critical errors and non-critical issues, and can preview some result types.

Use the Schema Markup Validator for the full vocabulary

Choose the Schema Markup Validator when you need to check Schema.org markup generally, including types that do not produce a supported Google rich result.

The validator can confirm that a property belongs to a type and that nested objects are expressed correctly. It does not apply all of Google's feature-specific requirements.

Use both when the distinction matters

A page can pass the Schema Markup Validator but fail the Rich Results Test because a Google-required field is missing. It can also contain valid Schema.org markup that the Rich Results Test does not report because Google has no supported feature for that type.

The tools are complementary rather than interchangeable.

How to use the Rich Results Test

1. 01
   Choose URL or code testing

   Use Code while developing a new JSON-LD block. Use URL once the page is publicly available. Google recommends URL testing for a deployed implementation, particularly when JavaScript generates the markup.

2. 02
   Select the relevant crawler

   The test normally uses the smartphone crawler by default. If the page serves different HTML to desktop and mobile visitors, compare both deliberately rather than assuming the output is identical.

3. 03
   Review page access

   Confirm that the page was fetched successfully and crawling was allowed. A valid block on a page the tool cannot access does not establish that Google can use it.

4. 04
   Open every detected item

   Do not stop at the overall green or red status. Expand the detected objects and inspect their properties. Check that the tool found the intended main entity and did not detect a stale duplicate.

5. 05
   Separate critical and non-critical issues

   Correct all critical errors. Review each warning against the source data and user value. Add a recommended property when it is accurate and available; do not invent a value to make the report look complete.

6. 06
   Inspect the rendered code

   The Rich Results Test code explorer uses rendered output. Confirm that the JSON-LD contains the final values produced by the live page and that scripts did not truncate, escape or overwrite them.

7. 07
   Save a repeatable test case

   Record the URL, page type, detected objects and expected result. Test the same representative cases after template, CMS or plugin changes.

How to use the Schema Markup Validator

Test the whole page when possible

A complete page can contain several related objects. Testing the page preserves connections through @id, nested objects and shared entities that may be lost when one block is copied in isolation.

Review types and properties

Check that the validator detects the intended type and assigns each property to the correct object. A property with the right spelling can still sit under the wrong parent.

For example, an Offer should be connected to the Product it describes. A loose price value without that relationship may be valid JSON but an incomplete model of the page.

Look for unrecognised terms

Typos, outdated vocabulary and custom properties can trigger messages. Compare the property with the current Schema.org definition and the type-specific search documentation.

Follow identifiers through the graph

If the markup uses @id, confirm that references resolve to the intended object. Reusing one identifier for two different entities can merge information that should remain separate.

Do not mistake vocabulary validity for search eligibility

The Schema Markup Validator checks the broader standard. Pass its output through the Rich Results Test as well when the implementation targets a Google feature.

Should you test code or a live URL?

Both have a place in the workflow.

Code testing is useful during development

Paste a draft block into a validator to catch syntax and property errors before deployment. You can change the code and rerun the test quickly.

This does not verify:

• Whether the code reaches the production page.
• Whether template variables contain the correct values.
• Whether JavaScript creates the object successfully.
• Whether another plugin adds conflicting markup.
• Whether Google can access the URL.
• Whether the page is indexable or canonical.

URL testing verifies the published output

Test the final public URL after deployment. This includes the page response, rendered markup and access conditions available to the testing service.

Use examples representing real variations, such as:

• An ordinary product and an out-of-stock product.
• A full-price product and a sale item.
• A single-author and multi-author article.
• A standard location and one with exceptional opening hours.
• A page with and without optional images.
• A canonical page and an alternate URL.

The best-looking example is rarely enough to verify the template.

What is the difference between errors and warnings?

Critical errors can prevent eligibility

Google labels a structured-data item invalid when it has a critical issue. A required property may be missing, a value may use the wrong data type, or the JSON may not parse.

The page itself can still appear in ordinary search results. The error normally affects the structured-data item or associated search feature rather than indexing the whole page.

Warnings identify opportunities or risks

A non-critical issue often concerns a recommended property. The item may remain valid and eligible, but supplying accurate additional information could improve its completeness or presentation.

Treat warnings as decisions, not a score to drive to zero. Ask:

1. Is the property relevant to this page?
2. Is the value available from a reliable source?
3. Is it shown or supported by the visible content?
4. Can the site keep it current?

Leave the property out if an honest, maintainable value does not exist.

Tool wording can differ

The Schema Markup Validator and Rich Results Test apply different rules and may describe the same implementation differently. Record which tool produced each message before assigning the fix. Validation is easier when you know the intended vocabulary; review Schema Markup fundamentals and the Product Schema requirements.

Common structured-data errors and how to fix them

Invalid JSON

JSON-LD requires exact punctuation. This example is missing a comma after the name:

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "Example Company"
  "url": "https://example.com/"
}

The corrected version is:

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "Example Company",
  "url": "https://example.com/"
}

Other parsing problems include missing closing braces, stray trailing commas, unescaped quotation marks and invalid escape characters. Fix the generator rather than editing the final HTML manually.

Missing required property

A supported rich-result type may require properties that Schema.org itself considers optional. Follow the Google documentation for the intended feature and add the missing value from a reliable source.

An empty string is not a meaningful substitute. If the data is genuinely unavailable, decide whether the page should produce that object at all.

Incorrect value type

A property may expect a URL, number, date, object or array. Supplying plain text in the wrong shape can invalidate the item. For example, an author may need a nested Person or Organization object rather than one long string containing a name and job title.

Invalid date or missing timezone

Use recognised ISO 8601 date and time formats. When a value includes a time, supply the relevant timezone where required so the moment is unambiguous. Do not update dateModified every time a page is rendered; it should describe a meaningful content change.

Invalid or inaccessible image

Check image URLs for successful responses, supported formats, minimum dimensions and crawlability. A correct URL string can still point to a blocked, expired or missing image.

Markup conflicts with visible content

The code may say a product is in stock while the page says it is unavailable. A rating may be included in the JSON-LD but never shown to visitors. Repair the data source and use the same source for visible content and Schema output.

Duplicate or conflicting objects

A theme and SEO plugin may both publish Product or Organization markup. Identify which system owns the object, consolidate the implementation and remove stale output.

Markup missing after JavaScript rendering

A code snippet may work in isolation while the live page never adds it, adds it too late or generates incomplete values. Test the URL and inspect rendered output. Fast-changing product prices and availability deserve particular care.

Unsupported or retired search feature

Valid Schema.org markup may no longer produce a Google rich result. Check the current supported-feature gallery and documentation updates before spending time removing every validator message. The markup may still have uses outside that feature, but the expected Search outcome needs to be revised.

How to use Search Console for Schema errors

Search Console rich-result reports show supported structured data that Google has found and processed for the verified property.

Review the report for each feature

Each supported feature has its own report when Google detects relevant items. The landing view separates invalid items with critical issues from valid items, which may still have non-critical improvements.

Remember that the figures count items, not necessarily pages. One URL can contain several items and one item can have several issues.

Open the issue group

Review when the issue was first detected, the latest crawl date and the example URLs. Search Console supplies samples rather than a complete export of every affected page. Use those examples to identify the shared template or data pattern, then find the full affected set with a crawl.

Inspect an example URL

URL Inspection can show the indexed status, detected enhancements and details of Google's crawled page. Compare the indexed information with a live test when the site has changed since Google's last crawl.

Validate the fix after deployment

Once the underlying issue is corrected on all affected pages, use Search Console's validation process where available. Google must recrawl the examples, so the status will not update immediately.

Do not start validation after fixing only one sample if the faulty template still affects the rest of the group.

Why valid markup may be missing from Search Console

The absence of a report or item does not always mean the live code is invalid. Possible causes include:

• Google has not recrawled the new implementation.
• The page is not indexed.
• robots.txt, login requirements or access problems prevent retrieval.
• A noindex directive prevents the page appearing in property reports.
• The markup has an unparsable syntax error.
• The type is not supported by a Search Console rich-result report.
• The report is showing a sample rather than every known item.
• Google has selected another URL as canonical.
• The implementation exists only after a rendering path Google did not complete.

Work through the evidence in order: fetch the live page successfully, confirm its response code, robots directives and canonical, run the live URL through the relevant validator, inspect the rendered output, check URL Inspection for Google's indexed view, and allow time for recrawling after a verified change.

Schema validation and AI visibility

Structured data can give AI-powered search and discovery systems explicit information about entities, products, authors and relationships. Validation matters because machine-readable information is only useful when it is accurate and internally consistent.

A malformed block may be ignored. A valid block with an incorrect price, business name or author can communicate the wrong fact more efficiently. Conflicting objects can create uncertainty about which value represents the entity.

When reviewing Schema for AI visibility, check more than syntax:

• Use stable names and identifiers for the same entity.
• Connect products with the correct brand and offer.
• Connect articles with a real author or publisher.
• Keep prices, availability and dates current.
• Ensure the visible page supports every important claim.
• Keep the page crawlable, indexable and canonical.
• Remove obsolete duplicate objects.

Google applies the usual crawlability, indexability and content-quality foundations to its AI search experiences. Bing has also described structured product data as useful for accurate search, shopping and AI-powered discovery.

Schema validation does not guarantee that an LLM will cite the page or that an AI assistant will recommend its product. It improves the quality and consistency of the machine-readable information available to systems that choose to use it.

How to audit Schema markup across a website

Define expected coverage

List the templates and the types they should contain:

This expectation makes missing and unexpected output measurable.

Crawl and segment the URLs

Group pages by template, directory or detected Schema type. Find pages missing an expected type, types appearing on the wrong template, invalid or empty objects, duplicate objects from several generators, inconsistent properties within one page group, and marked-up pages that redirect or cannot be indexed.

Prioritise by pattern and impact

A critical Product error on every product page usually deserves attention before one warning on an archived article. Consider the number of affected URLs, business value, whether the issue blocks feature eligibility, whether the data is inaccurate or merely incomplete, and whether one template fix resolves the whole set.

Validate representative samples

Use a specialist validator for a normal page and each important variation. The crawl provides breadth; individual tests provide detail.

Save a baseline

Record coverage and issue counts before the change. A new crawl can then demonstrate whether the fix reduced errors without removing valid objects elsewhere.

Test Schema patterns with Clearcrawl

A Schema markup checker can diagnose one URL. Clearcrawl helps reveal the scope: which templates are affected, where the same problem repeats and whether the marked-up pages are technically eligible to be found.

Use the crawl to choose representative URLs and verify the rollout. Use Google's tools and the Schema Markup Validator to inspect the exact properties and rules on those examples.

How to fix and verify structured-data errors

1. 01
   Reproduce the issue

   Test a reported URL with the tool that generated the message. Save the affected object, property and rendered code.

2. 02
   Identify the pattern

   Find every affected URL and determine what they share: template, content type, CMS field, plugin version or optional value.

3. 03
   Confirm the current requirement

   Read the documentation for the exact type and feature. Check whether the field is required, recommended, retired or expected to contain a different value type.

4. 04
   Fix the source

   Correct the CMS field, data feed, template or generator. Keep the visible page and structured data driven by the same reliable information.

5. 05
   Test the edge cases

   Validate a normal example plus pages with missing optional fields, unusual characters, several authors, price changes, out-of-stock states or other relevant variations.

6. 06
   Publish a controlled release

   Check the live response and rendered markup. Confirm that another script or cache has not preserved the old block.

7. 07
   Recrawl the affected section

   Compare type coverage, issue counts, page status, canonicals and indexability with the baseline.

8. 08
   Start Search Console validation

   When the complete issue group is fixed, use the relevant Search Console report to validate the correction. Allow time for Google to recrawl the examples.

9. 09
   Monitor future template changes

   Include representative Schema checks in release testing. A markup implementation can break months later when a field name, component or plugin changes.

Common testing mistakes

Frequently asked questions