How to Fix Broken JSON-LD Schema Markup

This guide covers three distinct problems that our audit groups under one heading because they share a root cause: schema markup that exists but doesn't do its job. invalid_schema_json means the JSON-LD in a <script type="application/ld+json"> block fails to parse as valid JSON: a syntax error, not a content problem. missing_required_schema_field means the JSON parses fine and the @type is a real schema.org type, but it's missing a property Google's documentation lists as required for that type to qualify for a rich result. duplicate_schema_type means the same @type (commonly Organization, Product, or FAQPage) is declared more than once on the page, usually with different values in each copy.

Invalid JSON is almost always mechanical. The most common causes are single quotes instead of double quotes around keys and string values, a trailing comma after the last property or array item, an unescaped quote or newline inside a string value, or an HTML comment left inside the script block. All four are valid in a JavaScript object literal, which is why they slip through when someone copies a JS snippet into a JSON-LD block, but none of them are valid JSON. When a parser hits one, it doesn't salvage part of the block; it discards the entire script tag's worth of structured data and moves on.

Required fields differ by type, and the differences are specific enough that guessing is a bad strategy. Product has a real, documented required set: name, plus at least one of offers, review, or aggregateRating fully filled in. LocalBusiness needs name and a complete address. Event needs name, startDate, and location. Article is the one that surprises people: Google doesn't list any properties as strictly required for Article, NewsArticle, or BlogPosting. headline, image, author, and datePublished are recommended, not required, so a missing one is a quality gap, not the same kind of hard failure as a Product with no offers, review, or aggregateRating at all. If our audit flags a missing field on an article-type page, it's worth closing but isn't proof the page is broken. Google's own Search Central documentation for each type is the actual source of truth, since the required-versus-recommended split is type-specific and does change.

Duplicate types usually come from stacking. An SEO plugin auto-generates Organization or WebSite schema, and a theme, a page builder, or a manually pasted snippet from an old tutorial adds a second, separate declaration of the same type with different name, logo, or URL values. A common variant is several FAQPage blocks on one page, each covering a different subset of the visible questions, where a parser has no way to know they should be merged rather than treated as competing answers to the same question.

The direct cost is rich-result eligibility, not rankings. Google has been explicit that invalid or unused structured data doesn't cause a ranking penalty; it simply means the page doesn't qualify for whatever visual enhancement that type earns: a Product's price and availability, a Review's star rating, a Recipe's cook time, and so on. Search Console's Enhancements reports list affected pages under invalid or non-critical items, and that list is worth checking periodically since these errors are otherwise invisible on the page itself.

Whether broken schema is actually worse than no schema depends on which of the three problems you have. A pure syntax error is functionally the same as having none: the block is silently discarded, full stop. Duplicate or conflicting type declarations are the case where it turns into an active liability rather than a neutral one. When two Organization or Product blocks disagree, Google, or any other consumer of the markup, has to pick one or attempt to merge them, and there's no guarantee it picks the current, correct one. Showing a stale price, an old rating count, or the wrong organization name with the implied authority of structured data is worse for a user than showing no rich result at all.

The AI-answer-engine angle is where accuracy matters most, because these systems increasingly treat JSON-LD as a higher-trust source than prose. A well-formed schema block hands a model an explicit, unambiguous fact: this is the name, this is the price, this is the author, this is the organization. When the JSON fails to parse, the model gets nothing from that block and falls back to inferring facts from body text, a weaker source but at least a single one. When two conflicting blocks both parse successfully, the model has two candidate facts and no signal for which is authoritative; it may pick either, or blend them into something that matches neither. That's a genuinely worse outcome than having no structured data, because it manufactures a wrong answer with the appearance of machine-verified precision.

The fix that prevents most of this from recurring is structural: consolidate your page's structured data into one @graph with @id references between entities, instead of letting multiple plugins, templates, or snippets each declare their own copy of the same thing. It's a one-time change in how you generate schema, and it makes duplicate_schema_type largely impossible going forward.