Short answer: structured data errors fall into three groups: syntax errors that make the JSON-LD unreadable, missing or invalid properties that make a page ineligible for rich results, and markup that does not match the visible content. Find them with the Rich Results Test, the Schema Markup Validator, Search Console’s enhancement reports and a site-wide crawl, then fix them at the template or plugin level so every page is corrected at once.
What structured data does and does not do
Structured data is machine-readable information about a page, usually written as JSON-LD using the Schema.org vocabulary. It tells search engines that a page is a product with a price and availability, an article with an author and publication date, a local business with an address, an event with a date, and so on.
Valid structured data can make pages eligible for rich results, such as review stars, product prices, breadcrumbs or event listings, depending on the search engine’s current features. It also helps search engines and other systems understand the page. It does not guarantee rich results, and it is not a direct ranking boost. Google lists which types it supports and the required properties for each in its structured data search gallery.
Error group 1: syntax errors
JSON is strict. A single mistake makes the whole block unreadable, and search engines simply ignore it. Typical causes:
- a trailing comma after the last property in an object or array;
- unescaped double quotes inside text, for example a product name like
27" monitor; - line breaks or control characters pasted into values;
- smart quotes (“ ”) instead of straight quotes, often from copying out of a word processor;
- HTML tags or entities inside values where plain text is expected;
- two JSON objects placed in one script tag without wrapping them in an array or
@graph.
When structured data is generated by code, syntax errors usually come from building JSON by concatenating strings. Generating it with a proper JSON encoder, such as wp_json_encode() in WordPress or JSON.stringify() in JavaScript, prevents most of them.
Error group 2: missing and invalid properties
Each rich result type has required and recommended properties. If a required property is missing, the page is not eligible for that rich result; missing recommended properties produce warnings. Common examples:
| Type | Frequent problem | Fix |
|---|---|---|
| Producto | No offers, review or aggregateRating |
Add offers with price, currency and availability |
| Offer | Price with currency symbol or comma decimals | Numeric price plus priceCurrency code |
| Article | Missing or invalid datePublished, author, image |
ISO 8601 dates, author as Person or Organization |
| BreadcrumbList | Items without position or item URL |
Number positions from 1, use absolute URLs |
| LocalBusiness | Incomplete address |
Use a full PostalAddress object |
| Event | Missing startDate or location |
Add date with timezone and a Place |
Invalid values are just as common as missing ones: dates in local formats, prices as text, URLs that are relative or point to redirects, images that return 404, or values from an enumeration misspelled, such as an availability value that is not one of the Schema.org options.
Error group 3: markup that does not match the page
This group is the most serious, because it can lead to manual actions for spammy structured data, not just lost eligibility. Search engines expect markup to describe content that visitors can see. Problems include:
- Review ratings that do not appear on the page, or ratings copied from another site.
- Self-serving reviews for your own business marked up on your own site in ways the guidelines exclude.
- Prices and availability that differ from what the page shows, often because a cache or feed is out of date.
- FAQ markup for questions not visible on the page.
- The wrong type, for example Product markup on a category page listing many products, or Article markup on a product page.
The rule is simple: mark up what is on the page, accurately, and nothing else.
Error group 4: duplicate and conflicting markup
On WordPress sites and shops, structured data often comes from several sources at once: the theme, the SEO plugin, the shop plugin, a reviews plugin and a schema plugin. The result can be two Product objects with different prices, or three Organization objects with different names and logos. Search engines may pick the wrong one or ignore both.
- Decide which plugin owns each type and disable the others’ output for it.
- Connect related entities with
@idreferences in one@graphrather than repeating them. - Check the page source after every plugin update; new versions sometimes switch output back on.
How to find structured data errors
- Rich Results Test checks a URL or code snippet for rich result eligibility and shows errors and warnings per item. It also renders the page, so JavaScript-injected markup is included.
- Schema Markup Validator at validator.schema.org checks general Schema.org validity, including types Google does not use for rich results.
- Search Console enhancement reports list pages with errors and warnings for each detected rich result type across your whole site, grouped by issue.
- A full crawl extracts structured data from every page, showing which templates are missing markup, which have invalid JSON and where types are duplicated.
Test at least one page of every template type: home, category, product, article, contact, and any landing page with special markup.
A minimal, valid example
It helps to see what clean markup looks like. This is a simplified Product block of the kind a shop template might output, with the values filled from the product’s own data:
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Product",
"name": "Trail Running Shoe X",
"image": "https://www.example.com/images/shoe-x.jpg",
"sku": "TRX-42",
"brand": {"@type": "Brand", "name": "ExampleBrand"},
"offers": {
"@type": "Offer",
"price": "89.00",
"priceCurrency": "EUR",
"availability": "https://schema.org/InStock",
"url": "https://www.example.com/shoes/trail-running-shoe-x/"
}
}
</script>
Notice the details that often go wrong: the price is a plain number without a currency symbol, the currency is a three-letter code, availability uses the full Schema.org value, and URLs are absolute and point to live pages. The price and availability must match what the visitor sees on the page at the same moment, which means the markup should be generated from the same data as the visible price, not from a separate feed that may lag behind.
A fixing workflow that scales
- Group errors by template. Almost every structured data error is repeated across all pages using the same template or plugin.
- Fix syntax first, because nothing else in a broken block is read.
- Fill required properties from real data in your CMS rather than hard-coding values.
- Remove markup that does not match visible content.
- Remove duplicates so each entity is described once.
- Retest a sample in the Rich Results Test, then use “Validate fix” in Search Console for the affected issue.
- Add a check to your release process, so theme or plugin updates do not silently break markup again.
Warnings: fix or ignore?
Warnings concern recommended properties. They do not block eligibility, but adding them can make rich results more complete, for example adding brand, sku or gtin to products. Prioritise warnings on templates that generate important rich results, such as products in a shop. For less important types, a warning can safely wait. Never add properties with invented values just to silence warnings.
It is also worth remembering that search engines change which rich results they show and which properties they require. A type that produced rich results last year may no longer do so, and new recommended fields appear from time to time. Review the official documentation for your main types once or twice a year, and treat Search Console’s enhancement reports as the current source of truth for what is checked.
How Site SEO AI Audit checks structured data
Structured data is one of the seven areas the audit scores. SEOAuditBot reads the Schema.org markup on each page, reports invalid JSON-LD and pages without markup, and checks Open Graph tags and share images. Because issues are weighted by the share of pages they affect, a broken product template ranks far above a single page with a warning. WordPress sites get the steps to fix the issue in the relevant plugin. You can run a free audit to check every page, not just the one you tested.
Related reading
- Does structured data help in AI search? An honest look
- What is technical SEO? A plain guide for site owners
- JavaScript SEO basics: how search engines render your pages
The bottom line
Structured data only helps when it is valid, complete and truthful. Fix syntax errors first, fill required properties with real data, remove markup that does not match what visitors see, and make sure only one source outputs each entity. Work at the template level and test after every update.
FAQ
Do structured data errors hurt rankings?
Errors usually just mean the markup is ignored and the page is not eligible for rich results. Misleading markup that does not match the page can lead to a manual action, which can remove rich results for the site.
What is the difference between an error and a warning?
An error means a required property is missing or invalid, so the item is not eligible for that rich result. A warning means a recommended property is missing; the item can still be eligible, but the result may be less complete.
Should I use JSON-LD, Microdata or RDFa?
Google supports all three, but recommends JSON-LD because it is easier to add and maintain separately from the HTML. Most plugins and frameworks output JSON-LD by default.
Why does my valid markup not show rich results?
Valid markup makes a page eligible, but search engines decide whether to show rich results based on quality, relevance and the query. Some rich result types are also limited to certain kinds of sites.
Can structured data be added with JavaScript?
Google can read JSON-LD injected by JavaScript after rendering, but server-side output is more reliable and is also visible to crawlers that do not run JavaScript.


