docs
Suspicious JSON-LD Type Patterns from Themes and Plugins
Structured data generated by themes and plugins often produces type combinations that are technically valid but semantically nonsensical. A page describing a single blog post should not also declare itself an Organization, WebSite, BreadcrumbList, and WebPage in the same graph. These patterns pass Google's Rich Results Test but do not produce rich results, and at scale they indicate to search engines that the structured data is machine-generated boilerplate rather than intentional markup.
What's wrong
The page contains JSON-LD type combinations that do not reflect the actual content. This is distinct from an invalid @type. Each type may be individually valid in the schema.org vocabulary, but the combination on a single page is implausible. Common patterns include every page on a site emitting identical Organization + WebSite + WebPage + BreadcrumbList blocks regardless of content, product pages that also declare LocalBusiness entities with no local business information, and blog posts wrapped in multiple redundant type declarations. These patterns originate from theme or plugin defaults that inject the same structured data template site-wide without evaluating page content.
Why it matters
Search engines evaluate structured data for intent and specificity. When every page on a site emits the same broad type combination, the signal carries no information. Google has explicitly stated that structured data should describe the primary entity on a page. Redundant or conflicting types dilute that signal. A product page declaring Organization, WebSite, WebPage, BreadcrumbList, and Product gives the parser five entities to reconcile when only one or two are meaningful. The result is that none of the types receive the focused property set needed to qualify for rich results. At scale, this pattern correlates with lower rich result eligibility across the entire domain.
The correct change
Audit the JSON-LD output per page type, not per site. Each page template should emit only the structured data types that describe its primary content. A product page needs Product. An article needs Article or BlogPosting. Organization and WebSite belong on the homepage or a dedicated about page, not on every page. BreadcrumbList should reflect actual navigation hierarchy, not a static template. Remove type declarations that do not correspond to content present on that specific page. If a theme or plugin forces identical structured data across all pages, override or disable its output and replace it with template-specific markup.
Scope
This condition applies at the page level. Each page is evaluated independently for suspicious type combinations. The violation considers the full set of JSON-LD blocks present in the page source, including those injected by multiple plugins that may not be aware of each other's output.
How to verify
- · Confirm the structured data reflects actual page content:
- · • Each JSON-LD type on the page corresponds to content visible on that page
- · • No type declarations are identical across unrelated page templates
- · • Organization and WebSite types appear only where contextually appropriate
- · • BreadcrumbList reflects the real navigation path, not a static default
- · • Google Rich Results Test shows eligible rich result types for the page's primary content
Takeaway
- · Suspicious type patterns are a quality signal, not a syntax error
- · Theme and plugin defaults inject identical structured data across every page regardless of content
- · Passing validation does not mean the markup is useful — search engines evaluate semantic fit
- · Structured data should describe the specific entity on each page, not repeat a site-wide template
FAQ
Is it wrong to have multiple JSON-LD types on one page?
Not inherently. A product page with Product and BreadcrumbList is reasonable. The issue is when the combination is implausible or when every page emits the same set of types regardless of content. Multiple types should each correspond to something the page actually describes.
How do themes and plugins cause this problem?
Most WordPress themes and SEO plugins inject structured data from a single template applied site-wide. The template typically includes Organization, WebSite, WebPage, and BreadcrumbList as defaults. The plugin has no awareness of page-specific content, so it emits the same block on a blog post, a product page, a contact form, and a 404 page.
Will Google penalize suspicious type patterns?
Google does not apply a manual penalty for nonsensical structured data. However, search engines may ignore the structured data entirely if the type combinations do not match the page content. The practical effect is the same — the markup produces no rich results and provides no ranking benefit.
What is the difference between this and an incorrect @type?
An incorrect @type means the declared type does not exist in schema.org or does not match the entity at all. Suspicious type patterns involve valid types that are semantically inappropriate in combination or context. A blog post with @type Product is an incorrect type. A blog post with Organization + WebSite + WebPage + BlogPosting is a suspicious pattern — each type is valid, but the combination is boilerplate.
Should I remove all structured data except the primary entity?
Not necessarily. Supporting types like BreadcrumbList add navigation context. The goal is relevance: each type should describe something present on the page. Remove types that describe site-level concepts from individual content pages, and ensure supporting types contain real data rather than static defaults.
How do I fix this if my theme controls the JSON-LD output?
Disable the theme or plugin's structured data output and implement your own per-template markup. Most SEO plugins provide an option to disable JSON-LD output. Replace it with structured data specific to each page template — Article for blog posts, Product for product pages, and Organization only on the homepage or about page.
The fix
Intent: Replace theme/plugin boilerplate structured data with page-specific type declarations that match the actual content
End state: Each page emits only the JSON-LD types that describe entities present in its content, with no site-wide template producing identical type combinations across unrelated pages
- ✕ Do not remove all structured data — keep types that genuinely describe the page content
- ✕ Do not add more types to compensate for missing rich results
- ✕ Do not rely on a single site-wide structured data template for all page types
- ✕ Do not assume passing Rich Results Test means the markup is effective