Fix The Common Schema Errors in Google’s Rich Results Test

Schema markup gives Google a precise, machine-readable description of your content, and the Rich Results Test is the fastest way to confirm whether Google can read that description properly. Most of the time, the tool shows errors in ways that are not always self-explanatory, and a valid test result does not always translate into rich results appearing in search.

Below you will find the most common errors we see when implementing schema markup and how to fix each one. If you know what you are doing, you can skip the bottom where we have a Quick Reference Table for the Errors.

Error 1: Missing Required Properties

Common tool messages: Missing field "name" (required) / The property "author" is required / Either "offers", "review", or "aggregateRating" should be specified

The Rich Results Test categorizes issues as either errors or warnings. Missing a required property is always an error and will block the schema item from qualifying for rich results. Google’s required properties vary by schema type, and it is a short list relative to what schema.org documents as available. For a Product, Google requires name and at least one of: review, aggregateRating, or offers. For an Article, Google requires headline, image, datePublished, and author.

Why does this happen?

• Schema.org and Google use different required property lists: Schema.org documents dozens of properties per type and developers frequently treat it as the authority. Google’s implementation uses a narrower subset with its own required fields. A property that looks optional in schema.org documentation may be required by Google for rich result eligibility.
• WordPress schema plugins output empty strings for unfilled fields: These plugins build schema templates that dynamically pull values from post meta, custom fields, or the post editor. When those source fields are left blank, the plugin either omits the property entirely or outputs it with an empty string. Google treats an empty string the same as a missing property.

How to fix it:

• Cross-reference Google’s documentation, not schema.org alone: Go to Google’s Supported Structured Data Types page and find the exact required properties for your schema type. Schema.org is the full specification; Google uses a subset.
• Check what your CMS is actually outputting: Use the “Code” tab in the Rich Results Test to see the rendered markup. A property may exist in your template but be outputting an empty string, which Google treats the same as absent.
• Do not rely on plugin defaults: Many WordPress schema plugins populate required properties only when you fill in corresponding fields in the post editor. If those fields are blank, the property either outputs empty or is omitted entirely.

Error 2: JSON-LD Syntax Errors

Common tool messages: Syntax error: Unknown: Unexpected token / Syntax errors in items of unknown type / Unparsable structured data

JSON-LD must be valid JSON. A trailing comma after the last property in an object, a missing closing bracket, an unescaped quotation mark inside a string value, or a property name that is missing its quotes will break the entire block. When the parser cannot read the structure, Google reports a syntax error, and the entire schema block is treated as unparseable, not just the line with the problem.

Why does this happen?

• WordPress content filters interfere with JSON strings: WordPress’s wpautop filter converts straight quotes to curly quotes, and certain content sanitization hooks convert characters to HTML entities inside <script> blocks. A double quote inside a JSON string value becomes", which is valid HTML but breaks the JSON parser entirely.
• Trailing commas from copied snippets: Schema code is frequently copied from documentation, generators, or other sites. Many of those sources include a trailing comma after the last property in an object — syntax that is valid in JavaScript but not in JSON. The parser will reject the entire block over a single extra comma.
• Escaped slashes added by server-side implementations: Some PHP configurations add a backslash before every forward slash in a string by default. URLs within JSON-LD values become malformed, and the parser cannot read the property correctly.

How to fix it:

• Paste the block into a JSON validator before publishing: JSONLint.com will tell you the exact line and character position of any syntax issue. This takes thirty seconds and eliminates guesswork.
• Watch for HTML entities in JSON strings: If your CMS auto-converts double quotes to " or apostrophes to ' inside a JSON-LD block, the JSON will break. This is common in WordPress when schema is stored in post meta and rendered through the_content filters.
• Check for escaped slashes causing problems: URLs with forward slashes in JSON strings do not need escaping, but some server-side implementations add a backslash before every slash by default. Use the JSON_UNESCAPED_SLASHES flag in PHP if you are generating the schema programmatically.

Error 3: Incorrect Date and Time Formats

Common tool messages: Invalid datetime value for "datePublished" / Datetime property "datePublished" is missing a timezone / Invalid value in property "startDate"

Google requires dates in ISO 8601 format. For schema types like Event, BlogPosting, and VideoObject, the startDate, datePublished, and uploadDate properties must follow this standard. A date formatted as “January 15, 2025” or “01/15/2025” will trigger a validation error. The accepted format is 2025-01-15 for date-only values, or 2025-01-15T09:00:00-05:00 when including time and timezone offset.

Why does this happen?

• Schema plugins read dates from WordPress template functions without converting them: Functions like get_the_date() return human-readable strings by default. When a schema plugin reads from those same sources without explicitly converting the value to ISO 8601, the date passes into the schema block in whatever format WordPress is configured to display, which is almost never the format Google requires.
• Event plugins omit timezone offsets as a separate issue: Event management plugins often have their own date fields with custom formatting logic that outputs the date correctly but drops the timezone offset entirely. Google flags a missing timezone offset as a distinct warning from the date format error itself, so a date that is partially correct can generate two separate messages simultaneously.

How to fix it:

• For WordPress sites using custom fields: Confirm the date format your schema plugin reads when pulling from post meta. If the plugin reads a human-readable date, it may not convert it to ISO 8601 before outputting it in the schema block.
• For events with no set end time: Google still requires an endDate for Event schema. If the event duration is unknown, use a logical estimate rather than omitting the property entirely, which triggers a warning that can reduce display quality.
• Test a date-only vs. date-time value: Some schema types are flexible about whether you include time. Others expect a full datetime. Check the Google documentation for the specific property before deciding which format to use.

Error 4: Schema Content Does Not Match Visible Page Content

Common tool messages: The value of "ratingValue" must be between 1 and 5 / The value in field "price" does not match what is shown to users — Note: the Rich Results Test does not catch content mismatch automatically. This category of violation is flagged in Google Search Console’s Manual Actions report or through manual review, not via structural validation.

Google’s spam policies explicitly prohibit structured data that does not reflect the actual content a user sees on the page. If your AggregateRating schema declares a 4.8-star average but no reviews are visible on the page, or if your Product schema lists a price that does not appear in the page copy, Google can apply a manual action that removes all rich result eligibility for that URL. The Rich Results Test does not catch this automatically. It validates structure, not accuracy.

Why does this happen?

• Schema is implemented once and never maintained: A product goes on sale, an address changes, or a phone number is updated — the page reflects the new information, but the schema block still holds the original values. A schema implemented when the website is built, with no update process attached to it, will drift from page content over time.
• Plugins auto-generate schema from SEO fields that do not match page copy: Many schema plugins pull values from the SEO meta description or a dedicated schema field written for keyword targeting rather than accuracy. The values in those fields do not appear in the actual page body, so to Google sees the markup describes something different from what the user sees.
• JavaScript-loaded reviews create invisible rating data: Aggregated review scores are pulled from a third-party platform via API and placed in AggregateRating schema, but the individual reviews load on the page via JavaScript. Google’s manual reviewers see a rating in the markup and no visible reviews on the page, which qualifies as a mismatch even if the technical implementation is otherwise correct.

How to fix it:

• Audit every schema property that makes a claim: Rating values, review counts, prices, availability status, and event dates all need to be reflected somewhere on the visible page. If the data lives only in the schema block, it is a policy violation.
• Check dynamically priced pages: eCommerce product pages with frequently changing prices are a common source of this mismatch. The schema may cache a price while the page itself shows an updated value.
• Review auto-generated schema from plugins: Some plugins pull data from post meta and output it in schema without confirming that the same data appears in the post body. A manual check is the only reliable way to catch this.

Error 5: Page Is Blocked from Crawling

Common tool messages: Couldn't fetch the page / Blocked by robots.txt / Server connection error: server was unreachable / Page fetch failed

The Rich Results Test accesses your page as Google-InspectionTool, which respects your robots.txt file. If the URL you are testing is blocked in robots.txt, or if the page requires a login to access, the tool will report a crawl error rather than a schema error. In these cases, the schema is not the problem. The problem is access. This error also appears when a staging environment is tested, while it blocks all crawlers.

Why does this happen?

• The tool runs as an anonymous external crawler, not an authenticated user: Any page requiring a login, sitting behind a membership paywall, or restricted to logged-in WordPress users returns a non-200 status code when accessed without credentials. The tool reads that response as a fetch failure rather than a schema error.
• Staging environments block all crawlers by default: Most staging setups apply a blanket Disallow: / rule in robots.txt or use HTTP authentication at the server level. Both block the tool the same way they block Googlebot, so no schema validation is possible via the URL input.
• Individual blocked resources prevent schema from executing: A JavaScript file that injects schema, a CSS file the page builder depends on, or an image asset can each be blocked independently in robots.txt. When a blocked resource is required for schema injection, the tool loads an incomplete version of the page where the schema block never runs.

How to fix it:

• Verify the URL is not blocked before debugging schema: Paste the URL into Google Search Console’s URL Inspection tool and check the “Crawl allowed” status before touching the schema code.
• Check whether the resources the page depends on are blocked: CSS files, JavaScript files, and image assets can all be individually blocked in robots.txt. If the schema is injected by a blocked JavaScript file, the tool will not see it even if the HTML loads correctly.
• Test staging URLs with the code input instead of the URL input: If you need to validate schema before a page goes live on a restricted staging server, paste the raw JSON-LD code directly into the “Code” tab of the Rich Results Test rather than entering the URL.

Error 6: Duplicate Schema Blocks Causing Conflicting Declarations

Common tool messages: The Rich Results Test typically surfaces only one block of each type, masking the conflict. In Google Search Console you may see Duplicate items detected or notice the same schema type appearing multiple times with inconsistent property values across the Enhancements report.

When two or more schema blocks on the same page declare the same type with different values, Google has to decide which one to trust, and in many cases, it ignores both. This happens most often when a site has multiple active schema sources: a theme that outputs schema, a dedicated schema plugin, and a page builder that adds its own markup. All three may output a LocalBusiness or WebPage block, each with slightly different property values. The Rich Results Test may only surface one of them, giving the false impression that the conflict does not exist.

Why does this happen?

• Multiple active plugins each output their own schema block for the same type: A theme like Astra, GeneratePress, or Kadence outputs a WebPage or Organization block by default. A plugin like Rank Math, Yoast SEO, or Schema Pro adds its own block for the same type. Neither checks whether the other is already active, so both run simultaneously with potentially different property values.
• Theme switches activate a second schema source without disabling the first: A new theme ships with schema enabled by default. The existing schema plugin is still active. Both output the same type, now with conflicting declarations. This is the most common trigger for the issue and the one most likely to go unnoticed because the Rich Results Test only surfaces the first block it finds.
• Custom functions added to functions.php: Over time, the schema output added directly to the theme’s functions file during a previous development sprint does not disappear when a new plugin is installed. It runs alongside whatever else is active, and no plugin UI surface makes it visible unless someone checks the raw page source.

How to fix it:

• View the full page source and search for application/ld+json: Count how many schema blocks exist. More than one block of the same type on a single page is a signal to investigate whether they are consolidating correctly or conflicting.
• Disable schema output from all but one source: Most WordPress schema plugins have settings to disable theme-level schema output. Use them. Running two separate Organization blocks with different name values are worse than running none.
• Use the Schema Markup Validator at validator.schema.org in addition to the Rich Results Test: The validator shows all parsed blocks, not just those eligible for rich results, giving a complete picture of what is on the page.

Error 7: Unsupported or Deprecated Schema Type

Common tool messages: No items detected / This page is not eligible for rich results / This rich result type is no longer supported

Google supports a defined subset of schema.org types for rich results. If you implement a type that Google does not include in its supported list, the Rich Results Test will not flag it as an error in the traditional sense but will return “no items detected.” This is not the same as a validation failure. The schema may be perfectly valid JSON-LD and perfectly valid according to schema.org, but Google simply does not use it to generate rich results. The HowTo schema type is one example that Google has deprioritized for most sites after limiting eligibility to certain categories.

Why does this happen?

• Google changes its supported types without notifying sites already using them: The FAQPage type was broadly supported through mid-2023, then restricted to government and health-focused sites. HowTo was progressively deprioritized and is no longer reliably awarded rich results on most sites. Sites that implemented either type before those policy changes have no automatic signal that the type stopped working.
• The tool cannot distinguish between broken schema and deprecated schema: The Rich Results Test returns “no items detected” for both a type that is structurally invalid and a type that is valid but no longer on Google’s supported list. Both conditions appear identical in the tool output, making it easy to misdiagnose the problem as a code error when the actual issue is a policy change.

How to fix it:

• Check the current list of supported rich result types before implementing: Google’s supported types change. What qualified for rich results two years ago may no longer generate an enhanced listing today. The FAQ schema type, for instance, is now restricted to government and health-focused sites.
• Do not remove unsupported schema if it is otherwise valid: Non-Google-supported schema types still communicate useful information to other search engines and AI models that parse structured data. Removing them to clean up the Rich Results Test output is counterproductive.
• Map your content types to the current supported list: For most sites, the high-value types to prioritize are Article, Product, LocalBusiness, Event, Review, BreadcrumbList, VideoObject, and JobPosting.

Error 8: Relative URLs Where Absolute URLs Are Required

Common tool messages: The value of the "url" field must be a valid URL / Invalid URL in property "image" / The value in field "logo" must be a valid URL starting with "http://" or "https://"

Certain schema properties expect fully qualified URLs, meaning they must include the protocol and domain. The image, url, logo, and sameAs properties are the most common places where this error appears. Providing /images/product-photo.jpg instead of https://www.example.com/images/product-photo.jpg will trigger a validation error because a relative URL is not a valid URL type in the schema. The page might display correctly in a browser because browsers resolve relative paths automatically. The schema validator does not.

Why does this happen?

• Internal WordPress functions return root-relative paths in certain environments: Functions like get_the_post_thumbnail_url() or get_permalink() usually return absolute URLs, but in multisite environments, development environments with different base URLs, or when a page caching layer serves a version built under a different domain, they can return paths beginning with / instead of https://.
• JSON-LD parsers have no base URL context to resolve relative paths: A browser resolves a root-relative path automatically against the current domain, which is why the image loads correctly on the page. A JSON-LD parser receives the value as a string and has no domain context to complete it. A path starting with / is simply not a valid URL, and the property fails validation regardless of whether the referenced file actually exists and loads.

How to fix it:

• For WordPress sites: Use the home_url() function to prepend the domain to any image or URL value when building schema programmatically. If you use a plugin, confirm it is outputting absolute URLs by checking the rendered source code.
• Pay particular attention to image properties on Article and Product schema: Google requires the image URL to resolve to an actual, accessible image file. A broken image URL or a URL that returns a redirect chain will cause the property to fail even if the URL format is correct.
• Check image dimension requirements alongside the URL format: For Article schema, Google recommends images be at least 1200 pixels wide. Images that are too small do not cause a hard error but do generate a warning that limits display eligibility.

Error 9: JavaScript-Rendered Schema That Passes the Test but Fails During Actual Crawls

Common tool messages: None — the Rich Results Test renders JavaScript fully and will show the schema as valid. The signal surfaces elsewhere: Google Search Console’s Enhancements report shows zero valid items, or the URL Inspection tool’s “View Crawled Page” output contains no schema blocks despite the test passing.

This is the most consequential mismatch between the Rich Results Test and real-world behavior. The Rich Results Test renders the page fully, including JavaScript, before checking for structured data. Googlebot’s crawling and indexing pipeline is more complex. If your schema is injected by a JavaScript file that loads asynchronously after the initial HTML response, there is a genuine risk that Googlebot indexes the page before the schema injection completes. The test shows the schema. The indexed version does not contain it.

Why does this happen?

• Page builders and schema plugins hook output into post-load JavaScript events: Events like DOMContentLoaded, window.onload, or custom builder-specific triggers fire after the initial HTML response is delivered. The schema block does not exist in the raw HTML — it only appears after JavaScript runs.
• The Rich Results Test renders JavaScript fully; Googlebot does not always wait: The tool uses a full headless browser that completes JavaScript execution before scanning for structured data. Googlebot’s rendering queue processes pages in two stages: a fast first pass over the raw HTML, and a slower deferred rendering pass for JavaScript. Pages are frequently indexed after the first pass, before the deferred render is queued. If the schema only exists after JavaScript runs, the indexed version of the page contains no schema at all — even though the live page and the test both show it correctly.

How to fix it:

• Move schema output to the server side: Schema delivered in the initial HTML response is always safer than schema injected by JavaScript after page load. If your current implementation relies on client-side injection, work with your developer to move it to the server-rendered HTML.
• Check the cached version Google has indexed: In Search Console, use the URL Inspection tool and click “View Crawled Page” to see what Google actually indexed. If the schema is missing from that view, server-side delivery is the fix.
• Use Google’s Search Console Enhancements report as the ground truth: A passing Rich Results Test result tells you the schema is structurally sound. The Enhancements report tells you what Google actually read during its crawl. Both need to show valid results before you can consider the implementation complete.

This distinction between test validation and crawl indexing is directly related to how you approach enterprise SEO at scale. The gap between what tools report and what Google actually processes is one of the most common sources of unexplained ranking issues we investigate in technical audits.

Error 10: Passing the Rich Results Test but Not Appearing in Search

Common tool messages: Page is eligible for rich results — the test passes, but no enhanced listing appears in search. In Search Console, the Enhancements report may show valid items with zero impressions in the Performance report, or the URL Inspection tool confirms indexing, but the Search Appearance filter shows no rich result activity.

A valid result in the Rich Results Test means Google’s tool found structurally sound schema on the page. It does not mean Google will display a rich result. Google’s decision to show a rich result depends on additional factors: whether the page meets content quality standards, whether the structured data has been indexed on the live crawled version (not just the test), whether the page has enough authority for certain schema types, and whether the query context is one where Google deems a rich result relevant to users. The test confirms eligibility, not appearance.

Why does this happen?

• The tool validates structure, not content quality or authority. The Rich Results Test checks whether the schema block is technically correct according to Google’s specification. It does not evaluate the page’s E-E-A-T signals, content depth, domain authority, or whether Google is currently awarding that schema type as a rich result for the query category and site type in question.
• Google treats rich results as a discretionary display feature: Meeting the technical requirements makes a page eligible, but Google still decides on a query-by-query and site-by-site basis whether to show the enhanced listing. Sites with thin content, low authority, or a history of structured data policy violations may be technically eligible but algorithmically suppressed.
• Newly indexed schema takes time to appear in the Performance report: Even when the Enhancements report shows valid items and the URL Inspection tool confirms the schema was indexed, rich result impressions can take several weeks to appear in the Performance report. A schema implementation that looks broken may simply be waiting in the queue.

How to fix it:

• Check Search Console’s Enhancements section: Open Search Console, navigate to Enhancements, and find the report for your schema type. Valid items here confirm that Google indexed the schema. Invalid items here are separate from the errors the Rich Results Test surfaces and require their own investigation.
• Filter the Performance report by Search Appearance: In Search Console’s Performance report, you can filter by Search Type and see whether your schema type is generating impressions at all. If it appears in the filter options with data, your schema is working. If it has zero impressions after several weeks, the issue is upstream of the schema itself.
• Review manual actions: A manual action for structured data misuse suppresses all rich results from the affected URLs even if the markup is technically valid. Check the Manual Actions report in Search Console and resolve any flagged issues before continuing to troubleshoot schema directly.

Quick Reference: Schema Error Lookup Table

Error	Tool Message	What It Means	How to Fix It
Missing required properties	Missing field "name" (required) / The property "author" is required	A property Google needs to generate a rich result is absent, or outputs an empty string	Cross-reference Google’s required properties list (not schema.org) and confirm your CMS is outputting a non-empty value for each
JSON-LD syntax errors	Syntax error: Unknown: Unexpected token / Unparsable structured data	The JSON block cannot be parsed; the entire block is ignored, not just the line with the error	Validate the raw JSON block at JSONLint.com; check for trailing commas, HTML entities inside strings, and escaped slashes
Incorrect date/time format	Invalid datetime value for "datePublished" / Datetime property "datePublished" is missing a timezone	The date value is not in ISO 8601 format, or the timezone offset is absent	Use YYYY-MM-DD for dates or YYYY-MM-DDTHH:MM:SS±HH:MM for datetime; confirm your schema plugin converts dates before output
Content-to-markup mismatch	No tool error — flagged via Search Console Manual Actions report or a Google manual review	Schema declares values (prices, ratings, dates) that are not visible to users on the page; it qualifies as a spam policy violation	Audit every claim-making property and confirm a matching visible value exists on the page; check dynamically priced pages for caching lag
Page blocked from crawling	Couldn't fetch the page / Blocked by robots.txt / Server connection error	The tool cannot access the page as an anonymous crawler; the schema is not the problem — access is	Check robots.txt and login requirements; test staging URLs using the Code tab instead of the URL tab
Duplicate schema blocks	The tool shows only one block, masking the conflict; Search Console may show Duplicate items detected	Multiple schema sources (theme, plugin, page builder) are outputting the same type with different values; Google may ignore all of them	Search the page source for application/ld+json; disable schema output from all but one source; validate with validator.schema.org to see all blocks
Unsupported or deprecated schema type	No items detected / This page is not eligible for rich results	The schema type is valid JSON-LD, but is not on Google’s current supported rich result types list	Check Google’s supported rich result types page; do not delete valid schema — keep it for other search engines and AI parsers
Relative URLs where absolute URLs are required	The value of the "url" field must be a valid URL / Invalid URL in property "image"	A URL property contains a root-relative path (/image.jpg) rather than a fully qualified URL; JSON-LD parsers do not resolve relative paths	Prepend the full domain to all URL values; in WordPress, use home_url(); confirm image URLs resolve to accessible files and are not redirect chains
JavaScript-rendered schema	No tool error — test passes; signal appears in Search Console Enhancements (zero valid items) or URL Inspection “View Crawled Page” output	Schema is injected by JavaScript after page load; the test renders JS fully, but Googlebot may index the page before the JS render completes	Move schema output to the server-rendered HTML; use URL Inspection to view the crawled page version and confirm schema is present
Passes the test, but no rich results in search	Page is eligible for rich results — tool passes; Search Console Enhancements shows valid items, but the Performance report shows zero rich result impressions	Technical eligibility is confirmed, but Google is not displaying the rich result; content quality, authority, or algorithmic suppression is the likely cause	Filter Search Console Performance report by Search Appearance; check Manual Actions report; review content quality and E-E-A-T signals for the affected pages

Conclusion

Schema errors rarely exist in isolation. The Rich Results Test is the right starting point, but cross-referencing its output with Search Console’s Enhancements report and the URL Inspection tool is what separates a genuine fix from a surface-level patch.

The Emulent team works through exactly this kind of layered technical SEO diagnosis as part of our broader enterprise SEO engagements. If your schema markup is generating errors you cannot trace, or if your structured data is passing the test but not producing rich results in search, we can help identify where the breakdown is happening. See how we have helped brands resolve technical SEO issues, or reach out to the Emulent team directly to discuss your structured data strategy.