Schema Markup Validator

What this checks, and what it does not

It reads every application/ld+json block on the page, confirms the JSON parses, and lists the types declared — including types nested inside an @graph.

It does not decide whether Google will award a rich result. That is Google's judgement, made by its own Rich Results Test and by policy that changes without notice. Valid markup is a requirement, not a promise, and any tool claiming otherwise is guessing.

Why markup fails to parse

Almost always because something rewrote it. A minifier that strips whitespace inside a JSON block, a plugin injecting a second block with a stray comma, or a template inserting an unescaped quote from a post title. The markup was correct when the plugin wrote it and broken by the time it reached the page — which is exactly why reading the served page beats reading the settings screen.

Types worth having, and types worth skipping

An ordinary article needs very little: Article or BlogPosting, BreadcrumbList, and the site-level WebSite and Organization nodes. FAQPage is worth adding only where a real question and answer exist on the page.

What does not help is stacking types onto a page that does not represent them. Marking a guide as a Product because product results look attractive is a manual-action risk, not a shortcut. The rule is simple: the markup describes what the page already is.

Where the markup comes from

On most WordPress sites it is generated by the SEO plugin, sometimes with a second helping from the theme. Two plugins each emitting their own Organization node is the usual cause of duplicate types in the list — see the best WordPress SEO plugins for how they overlap, and the SEO checklist for where structured data sits among things that matter more.