Common JSON-LD mistakes crawlers find

Most structured data problems are not dramatic.

They are not advanced technical puzzles. They are not clever edge cases. They are usually boring mistakes created by plugins, theme templates, migrations, old content, and people trying to do too much.

That is why crawlers are useful.

A crawler does not get impressed by a giant @graph. It does not care that a plugin says “AI ready.” It simply sees what is on the page: the schema types, URLs, entities, images, scripts, visible content, and conflicts.

Here are the JSON-LD mistakes worth fixing first.

1. The wrong type on the wrong URL

This is the most common problem.

A homepage gets Article schema.

A blog post gets Product schema.

A category archive gets marked as a single Article.

A service page gets FAQPage markup even though the only FAQ is a generic footer block.

A product listing page gets one Product entity even though it represents a collection.

Wrong type problems happen because templates are reused. A blog template becomes a landing page. A product plugin injects markup globally. A theme assumes every page with a title and body is an article.

The fix is to map schema to page purpose.

The main structured data type should reflect the main content of the page. Google’s structured data guidelines say structured data should be representative of the main content and not misleading.

Before debugging fields, ask the basic question: what is this URL?

If the schema answers a different question than the page, remove or replace it.

2. JSON-LD that does not match visible content

This one is more serious.

Examples:

FAQ markup for questions users cannot see.
Review markup for reviews that are not visible.
Product availability that differs from the page.
Author data that is hidden or invented.
Business address markup that is not supported anywhere on the site.
Event dates in JSON-LD that are different from the visible event page.

Google’s guidelines are clear: do not mark up content that is not visible to readers of the page, and do not mark up irrelevant or misleading content.

This does not mean every JSON-LD field must be repeated in the exact same visual layout. But the core facts should be supported by the page.

If the markup says “4.9 stars from 278 reviews,” users should be able to see where that comes from.

If the markup says the article was written by a named expert, the article should show that authorship clearly.

If the markup describes an FAQ, the page should show the questions and answers.

Callout: Fix visible content first. JSON-LD should describe the page you have, not the page you wish Google would see.

3. Broken URLs inside schema

JSON-LD often contains URLs:

url
logo
image
sameAs
author.url
mainEntityOfPage
publisher
@id

When those URLs break, move, redirect badly, or point to non-HTTPS versions, the structured data becomes less reliable.

Common examples include:

Logo URL returns 404 after a theme rebuild.
Article images point to old staging domains.
sameAs includes dead social profiles.
mainEntityOfPage points to the wrong canonical URL.
Author URLs redirect to the homepage.
Image files are blocked or not indexable.
Mixed http and https across different schema blocks.

Google’s structured data image guidance says image URLs should be crawlable and indexable. That same basic discipline applies to the other URLs too.

A crawler can catch many of these quickly by extracting schema URLs and checking status codes.

The fix is not glamorous: update the URLs, remove dead references, and keep canonical IDs consistent.

4. Duplicate and conflicting entities

Multiple structured data blocks are not automatically bad.

Google can understand multiple items on a page, and sometimes a page really does contain multiple things: an article, breadcrumbs, a video, and a publisher entity.

The problem is duplicate or conflicting entities.

Examples:

Two Organization blocks with different names.
One WebSite block from the theme and another from an SEO plugin.
Article publisher logo differs from homepage Organization logo.
Multiple Article blocks with different dates.
FAQ markup from two plugins with overlapping questions.
A LocalBusiness block and an Organization block that describe the same business but use different URLs and phone numbers.

This often happens after installing more than one SEO plugin, changing themes, adding a schema plugin, or migrating from one site builder to another.

The fix is consolidation.

Choose one source of truth. Use stable @id values. Reference the same Organization entity from related schema blocks. Disable duplicate schema output where possible.

More schema is not better when the graph contradicts itself.

5. Invalid JSON

Sometimes the entire JSON-LD block is broken.

A missing comma. A trailing comma. Bad escaping. Smart quotes. A plugin injecting unescaped user content. HTML inside a JSON string without proper encoding.

Invalid JSON-LD is easy to miss because the visible page may look fine.

Search engines and validators are less forgiving.

Common causes include:

Custom fields with quotes inside names or descriptions.
Manual edits to schema snippets.
CMS shortcodes inside JSON-LD.
JavaScript minification or optimization corrupting scripts.
Multiple plugins trying to alter the same output.

The fix is to validate the page, not just the template. A template can be valid with normal content and break when a specific post has unusual characters.

Use the Rich Results Test for Google-supported features and Schema Markup Validator for broader schema.org syntax checks.

6. Kitchen-sink `@graph` output

A large @graph is not automatically wrong.

Some sites need a graph with Organization, WebSite, WebPage, BreadcrumbList, Article, Person, ImageObject, and VideoObject nodes.

But some graphs are bloated because plugins add every possible entity whether the page needs it or not.

This creates two problems.

First, it becomes harder to see the primary purpose of the page.

Second, it becomes harder to maintain accuracy. Every extra node is another chance for stale URLs, mismatched names, duplicate IDs, and weak claims.

A practical crawl should not merely ask, “Is JSON-LD present?”

It should ask:

Which types are present?
Which type appears to be the main entity?
Are there duplicate Organizations?
Are key URLs valid?
Is the markup consistent with the visible page?
Are important fields missing from otherwise useful schema?

That is where structured data auditing becomes useful.

The fix order

Do not start by tweaking JSON fields.

Start here:

1. Visible content

Make sure the page actually says what the markup claims.

If there is no visible author, fix the byline. If there is no visible FAQ, add one or remove FAQ schema. If product information is stale, update the page first.

2. Page purpose

Choose the schema type that matches the URL.

Homepage: Organization and WebSite may make sense.

Article: Article or BlogPosting may make sense.

Visible FAQ section: FAQPage may make sense.

Product page: Product may make sense.

Do not let a global template decide blindly.

3. Entity consistency

Use one Organization. Use one WebSite. Use stable IDs. Make author and publisher references consistent.

4. URLs and assets

Fix broken logo, image, profile, canonical, and author URLs.

5. Validation

Use Google’s Rich Results Test for supported rich result eligibility. Use Schema Markup Validator for broader syntax and vocabulary checks.

6. Monitoring

Watch Search Console for structured data issues, rich result reports where available, and changes in page performance.

How SEO Perception should talk about this

The useful product angle is not “we found schema errors, buy now.”

The useful angle is crawl visibility.

SEO Perception can store detected JSON-LD types, notice missing schema where it makes sense, flag overlapping entities, and suggest Organization completeness without pretending every page needs markup.

The best recommendation is specific:

“Homepage has no Organization schema, but brand settings are available.”

“Article page has BlogPosting schema but no author URL.”

“Two Organization entities found with different names.”

“FAQPage markup found, but no visible FAQ headings were detected.”

That kind of recommendation is actionable.

Generic “add schema” advice is not.

Frequently asked questions

Can invalid JSON-LD hurt rankings?

A structured data manual action can remove rich result eligibility, but Google says it does not affect ordinary web search ranking directly. Bad or misleading markup can still waste effort and create trust problems.

Is duplicate schema always bad?

No. Multiple entities can be valid when they describe real visible content. Duplicate or conflicting entities are the problem.

Should I remove plugin-generated schema?

Only when it is wrong, duplicated, or conflicting. If plugin output is accurate and maintained, it may be fine.

Which tool should I use to test JSON-LD?

Use Google’s Rich Results Test for Google-supported rich result features and Schema Markup Validator for broader schema.org validation.

See how crawls surface these issues in structured data and viewport signals, how we find possibilities, and JSON-LD basics.