Adding schema markup to a WordPress site feels like a finished task the moment the plugin saves your settings. It isn't. JSON-LD is just a block of text sitting in the page source, and nothing stops it from being malformed, incomplete, or pointing at the wrong schema type entirely. The only way to know it actually works is to test it against the tools that search engines use to read it.
This guide covers the practical side: how to find the raw JSON-LD on a page, which validators to trust in 2026, how to read the errors they return, and how often to recheck. If you haven't set up structured data yet, Rankwyn's schema and structured data guide covers the full type breakdown, from Article and Product to FAQPage and LocalBusiness, before you get here.
Why validating schema matters
Structured data has one job: give search engines a machine readable summary of what's on the page so they can decide whether to show a rich result, an FAQ dropdown, a review star rating, or a recipe card. That decision runs entirely on parsed data. If the parser can't read your JSON-LD, or reads it into the wrong shape, none of the visual upside shows up, and you won't get an error message telling you why.
Validation is the step that turns "I added schema" into "I confirmed search engines can read this schema." It takes a few minutes per page template and it's the only way to catch mistakes before they quietly cost you the rich results you were trying to earn in the first place.
Rankwyn's schema and structured data tools generate JSON-LD automatically for common WordPress content types, which removes most manual syntax errors up front. Validation still matters, since even generated markup can end up incomplete if a required field is left blank in the editor.
What breaks silently if you skip it
Broken schema doesn't throw a 404 or a visible error on the page. The HTML still renders fine, the page still loads, and nothing in your day to day WordPress workflow flags a problem. That's exactly what makes it dangerous: the failure is invisible until you go looking for it.
- A missing required property, like the `image` field on a Product schema, means the entire block can be silently ignored by the parser instead of partially used.
- A typo in a property name (`"pric"` instead of `"price"`) produces no error in the page itself, since JSON-LD with a stray key is still syntactically valid JSON.
- Using the wrong schema type for the content, such as tagging a blog post as a Product, can get the markup parsed correctly but rejected for rich result eligibility because it doesn't match the page's actual content.
- Duplicate schema blocks from a plugin conflict, where both your SEO plugin and a theme template inject overlapping JSON-LD, can confuse the parser about which values are authoritative.
- A stale schema block left over from a redesign can describe content that no longer exists on the page, which validators treat as a mismatch between the markup and the visible page.
None of these show up by scrolling the page in a browser. They only show up when you paste the raw markup into a validator and read what comes back.
How to find your page's raw JSON-LD
Before you can validate anything, you need the actual JSON-LD block, not a description of what your plugin says it added. The most reliable way to get it is straight from the rendered page source, since that's exactly what search engines see.
In any browser, right click the page and choose "View Page Source," or use the keyboard shortcut for it. Once the source is open, use the browser's find function (Ctrl+F or Cmd+F) and search for a term that identifies structured data:
application/ld+jsonThis is the MIME type WordPress and most SEO plugins use to embed JSON-LD inside a script tag. Searching for it will jump you straight to every schema block on the page. You may find more than one, which is normal for a page with, say, both Organization schema in the header and Article schema for the post itself.
If you want a cleaner view than raw page source, open your browser's developer tools (F12 or right click, Inspect), go to the Elements or Inspector tab, and search the DOM for the same `application/ld+json` string. This shows the script tag with syntax highlighting, which is easier to scan for obvious structural problems like a missing closing brace before you even run it through a validator.
Copy everything between the opening and closing `<script>` tags, not the tags themselves. That block of raw JSON is what you'll paste into the validators in the next section.
How to test it with the current validation tools
Two tools cover schema validation in 2026, and they check for different things. Using both gives you full coverage: one confirms your markup earns rich results in Google, the other confirms it's syntactically correct against the schema.org vocabulary itself.
1. Google's Rich Results Test
Go to search.google.com/test/rich-results. You can either enter your live page URL, which lets Google fetch and render the page the way it actually crawls it, or switch to the code tab and paste your raw JSON-LD directly. Testing the live URL is the better first check, since it also tells you whether the schema is reachable at all, not just whether it's well formed.
Run the test and Google returns a list of detected structured data types, whether each one is eligible for a rich result, and a breakdown of any errors or warnings. Errors block eligibility outright. Warnings mean the markup is valid but missing a recommended (not required) field, which usually means a weaker rich result rather than none at all.
2. The Schema Markup Validator
Go to validator.schema.org. This tool, maintained as part of the schema.org project, checks your markup against the schema.org vocabulary itself rather than against Google's rich result requirements. It's the one to use when you want to confirm your JSON-LD is structurally correct independent of any single search engine's eligibility rules, since your markup also gets read by other engines and AI crawlers that follow the same schema.org spec.
Paste your JSON-LD (or a page URL) in and it returns the parsed data graph plus any syntax errors it found. Use this alongside the Rich Results Test rather than instead of it: the Schema Markup Validator can tell you your syntax is valid schema.org markup even when Google's tool says it's not eligible for a specific rich result, because eligibility rules are stricter and Google-specific.
Test every distinct page template on your site (home page, a blog post, a product page, an FAQ page), not every individual URL. Pages built from the same template share the same schema logic, so one clean test per template is usually enough to confirm the pattern is sound.
The schema validation workflow
Locate the JSON-LD
View page source or dev tools, search for application/ld+json.
Paste into a validator
Run the URL or raw code through Rich Results Test and Schema Markup Validator.
Review the errors
Separate blocking errors from optional warnings.
Fix in the source
Correct the field in your plugin settings, template, or theme file.
Re-test
Confirm the fix resolved the error without introducing a new one.
Monitor Search Console
Watch the Enhancements reports for the same issue reappearing site-wide.
Common validation errors and what they mean
| Error type | What it means | How to fix it |
|---|---|---|
| Missing required field | A property the schema type requires (such as `image` on Product or `datePublished` on Article) is absent from the JSON-LD block. | Add the field with a real value. If your SEO plugin generates this automatically, check that the underlying content, like a featured image, is actually set on the page. |
| Wrong type used | The schema type doesn't match what the page actually contains, for example tagging a service page as a Product when it has no price or availability. | Switch to the schema type that matches the content. When in doubt, use the narrower, more specific type rather than a generic one. |
| Invalid date format | A date field like `datePublished` or `validThrough` isn't in ISO 8601 format, which is the only format schema.org parsers accept. | Reformat the date as `YYYY-MM-DDTHH:MM:SS+00:00`. Most WordPress plugins handle this automatically, so this usually points to a manually edited template. |
| Duplicate schema types | The same schema type (for example, two Organization blocks) appears more than once on the page, often from a plugin and a theme both injecting markup. | Identify the source of each block and remove the redundant one. Keep the version with the more complete, accurate data. |
Duplicate schema is the error most likely to go unnoticed, because each individual block can be perfectly valid on its own. It only shows up when you view the full page source and count how many times a given `@type` appears.
How often to re-validate
Re-validate any time you change your SEO plugin's schema settings, switch themes, update a page template, or install a new plugin that touches content types, reviews, or events. Any of these can silently add, remove, or overwrite JSON-LD without you noticing.
Beyond that, a quarterly spot check across your main templates is a reasonable baseline for most sites. If you're publishing schema-heavy content regularly, like recipes or products, check Google Search Console's Enhancements reports weekly instead, since they'll flag a spike in errors across many pages faster than manual spot checks will.
If you're auditing your broader WordPress setup at the same time, see Rankwyn's pricing for how automated schema generation fits into a full SEO toolkit, so validation becomes a final check rather than the only line of defense.