The Schema Mistakes That Pass Validation but Still Fail Rich Results

There is a frustrating moment every site owner who adds structured data eventually hits. The validator shows a green tick. The JSON parses. No errors are reported. And yet, weeks later, nothing has changed in search results. No richer display, no enhancement, no sign that the markup is doing anything at all.

The confusion comes from what validation actually checks: that your JSON-LD is well-formed JSON, and that the properties it knows to look for are present. It does not confirm eligibility for a rich result, a match with the visible page, or that a search engine will choose to show anything. The mistakes that break those are invisible to a pass-or-fail check.

This guide covers the four mistakes that most often explain a passing validator and a missing result, and how to fix each one using the Structured Data Generator, which checks required properties as you build each block. Work through them in order the next time your markup validates but nothing appears.

Mistake 1: Missing required fields that the validator does not demand

Not every property a schema type can carry is required, and not every validator demands the same set. A block can be perfectly valid JSON, with a correct type, and still be missing the one field that makes it eligible for a particular result. The classic example is an Article block with a headline and an author but no image, or a Product block with a name and description but no price or availability. The JSON is fine. The eligibility is not.

The fix is to check the requirements for the specific result you are aiming at, not just the general shape of the type. Google publishes per-type documentation listing which properties are required for eligibility, and those lists change over time. Treat the tool's required-property warnings as a floor, not a ceiling: fill in every field the form asks for, and if a field genuinely does not apply, reconsider whether that schema type is the right choice at all. Never invent a value to satisfy a form — a price of "0" or an author of "Admin" validates, but it describes nothing real, and a search engine that meets placeholder data learns to ignore the markup.

Mistake 2: The wrong type for the page

Schema types look similar, and picking a near-miss is easy. A blog post marked up as a generic WebPage instead of an Article loses the article-specific properties that matter. A services page marked up as a Product implies something is for sale when nothing is. A local business marked up as an Organization misses the address and hours fields that make local markup useful.

The rule is simple: the type must match what the page visibly is, not what you wish it were. Read the page as a stranger would. If the page is an article with a headline, an author, and a publication date, it is an Article. If it is a business listing with an address and hours, it is a LocalBusiness or one of its subtypes. If it is a list of questions and answers, it is an FAQPage. When two types could both fit, pick the more specific one that matches the page's main purpose, and use the other only if the page genuinely serves both purposes.

Marking up a page as a type it is not, in the hope of a richer display, is misrepresentation, and search engines treat it as such. The correct type for a page that does not qualify for any rich result is still worth adding — but it must be the honest type.

Mistake 3: Markup that does not match the visible page

This is the single most common reason valid markup fails, and it is entirely invisible to a JSON validator, because the validator only sees the block, not the page. If your markup says a product costs one amount and the page shows another, or your FAQ markup answers a question that appears nowhere on the page, or your Article markup names an author who is not credited on the article, the markup and the page disagree. Search engines compare the two, and when they disagree, the markup loses.

Mismatches usually creep in through editing drift rather than deliberate deception. A price is updated on the product page but not in the markup. A blog post is rewritten and its headline changes, but the old headline stays in the JSON-LD. A FAQ answer is shortened on the page while the markup keeps the longer version. Each drift is small, and each one erodes trust in the markup.

The fix is procedural, not technical. Whenever you edit a page, edit its markup in the same session. Regenerate the block in the Structured Data Generator with the new facts and replace the old block wholesale, rather than patching individual values by hand, where a typo can introduce a new mismatch. Then check the published page: read the visible facts and compare them against the markup, line by line, for the fields that matter — names, prices, dates, hours, and answers.

One special case: FAQ markup for questions answered only in the markup, hoping to win extra search space without cluttering the page. This is exactly the pattern search engines penalise. If the answer is worth marking up, it is worth showing to visitors — put it on the page first.

Mistake 4: Duplicate or conflicting markup

Many sites now carry markup from more than one source: a theme that injects its own JSON-LD, a plugin that adds another block, and a hand-written block added by the site owner. Individually, each block may validate. Together, they can contradict each other. Two Article blocks with different headlines, two Organization blocks with different names, or a Product block from a plugin and a hand-written one with a different price all create the same problem: the search engine cannot tell which version is true, so it trusts neither.

Duplicate markup is hard to spot because you only see the block you added; the theme's and the plugin's blocks are invisible in your editor. View the published page's source, search for every JSON-LD script block, and read each one. If you find duplicates, pick a single source of truth — usually the block you control directly — and disable the others. A related trap is pasting the same block onto every page: an Article block belongs on that article, not on the home page and every other article, and site-wide markup should be limited to things genuinely site-wide, such as Organization or WebSite.

A practical debugging sequence

When markup validates but nothing appears, work through this sequence before assuming the markup is broken. First, confirm the block is actually on the published page, not just in your editor or staging site: view the live page source and search for the script block. Content management systems and caching layers can swallow script tags silently.

Second, run the On-Page SEO and Redirect Checker against the live URL. It reports whether JSON-LD is present and flags other on-page problems, telling you whether the block shipped at all.

Third, check the page for the four mistakes above, in order: required fields, correct type, visible match, and duplicates. Fix what you find, regenerate the block with the Structured Data Generator, and republish.

Fourth, check the basics that have nothing to do with schema. Is the page indexed? Can search engines reach it at all? The Robots.txt and Sitemap Toolkit helps confirm that your robots rules and sitemap are not accidentally blocking the page. Markup on a page that is not indexed cannot produce any result, rich or otherwise.

Fifth, wait, then re-check. Search engines do not reprocess every page immediately, and any richer display depends on their timing and eligibility decisions. A week or two without change after a fix is normal, not evidence the fix failed.

An honest limitations note

Validation is not a guarantee of rich results, and fixing every mistake in this guide is not one either. Google chooses what to show, for which queries, and for which sites, and those choices change over time. Several schema types that once produced visible enhancements no longer do so for most sites, and no tool can promise a particular display. What correct markup does guarantee is narrower and still valuable: your pages are described accurately, in a format search engines can parse without guessing, and you have removed the preventable reasons a result might be withheld. Our guide to structured data with JSON-LD covers the format and its limits in more depth. Treat any guide that promises a specific search appearance as a warning sign, not a selling point — it is promising something outside its control.

FAQs

How long should I wait after fixing schema before expecting a change?

Allow at least a couple of weeks for the page to be recrawled and reprocessed, and longer for a large site. If nothing changes after a month and the block is confirmed on the live page, re-check the four mistakes above rather than adding more markup.

Can duplicate markup cause a penalty, or just a missed result?

Conflicting markup usually just means the markup is ignored, but markup that deliberately misrepresents the page — hidden content, false prices, fake reviews — can lead to a manual action for spammy structured data. Keep markup honest and the risk stays low.

Is it better to remove schema entirely if it is not producing rich results?

No. Accurate markup still helps search engines understand your pages, even when no richer display appears. Remove only markup that is wrong, duplicated, or mismatched, and keep the correct blocks in place.

Should I use a plugin or generate the markup by hand?

Either can work. A plugin is convenient but can create the duplicate-markup problem described above, since you may not see what it injects. A generated block from the Structured Data Generator gives you full control over exactly what ships. Whichever you choose, make it the single source of truth and check the live page source.

human review pending client designation