JSON-LD Error Fixes: From Broken Syntax to Valid Structured Data

JSON-LD is the block of code, usually in the page head, that describes a page to search engines in a fixed vocabulary from schema.org. It has to be valid JSON before anything else can happen, and a single stray comma can make a parser discard the whole block without any visible sign on the page.

The JSON Checker parses every JSON-LD block, checks the syntax, checks each type against schema.org, looks for missing required fields and conflicting types, and tests the result against Google's rich result criteria. This page explains each finding and links the fix.

By John Carlsson · Updated 28 September 2026 · About 10 minutes to read

📋 Demo 📘 Tutorial 📖 Guide 📚 Book 🔧 Fix

On this page

Three layers of correctness
The JSON mistakes that break whole blocks
The fix guides
A valid block, piece by piece
Which findings to fix first
A sensible order of work
Questions and answers

Three layers of correctness

A JSON-LD block can be wrong in three different ways, and each layer only matters once the one beneath it is right. Reading findings with this in mind saves a lot of confusion.

Layer	The question	Typical failures	What happens
1. JSON	Can a parser read it at all?	Trailing commas, single quotes, curly quotes pasted from a word processor, a missing bracket, comments	The entire block is thrown away. Every type in it is lost, including ones that were written correctly.
2. Vocabulary	Do the types and properties exist in schema.org, and do they fit together?	Made-up types such as `BlogPost`, misspelt properties, a text value where an object is expected, references to entities that are never defined	The JSON is read, but the unknown parts are ignored or misunderstood.
3. Feature rules	Does it meet what a search feature requires?	A Product with nothing to show in a snippet, a date without a time zone, an image that cannot be crawled	The markup is understood but the page is not eligible for that rich result.

Google's Rich Results Test only reports the third layer for the types Google supports, and it tends to report a broken block as simply missing. The JSON Checker reports all three, so a block that "disappeared" shows up as the syntax error that caused it.

The JSON mistakes that break whole blocks

JSON is stricter than JavaScript and much stricter than HTML. Browsers forgive almost anything in HTML; a JSON parser forgives nothing. These are the mistakes that turn up most often in real pages:

{
  'name': 'Oak Bench',            <-- single quotes are not allowed
  "description": “Solid oak bench”, <-- curly quotes cannot wrap a value
  "sku": "OB-150",
  "brand": "Northwood",           <-- trailing comma before a closing brace
}

Quotes. Every key and every string value must use straight double quotes. Word processors and some CMS editors silently turn them into curly quotes, which a parser treats as ordinary characters.
Commas. Items are separated by commas, but there must be no comma after the last item in an object or list. Templates that loop over fields often leave one behind.
Quotes inside values. A double quote inside a string must be escaped as \". Product names such as 6" shelf brackets are a classic cause.
Comments. JSON has no comment syntax. // or /* */ left in a block breaks it.
HTML entities. Some templates encode the whole block, turning quotes into ". The browser does not decode entities inside a script element, so the parser sees them literally.

💡 When a parser reports a line and column, the real mistake is often just before that point, typically a missing comma or bracket on the previous line.

The fix guides

Each guide explains one type of finding, shows broken and corrected code, and covers how to confirm the fix.

Syntax and vocabulary

Fixing JSON syntax errors covers every parser error above and how to add a check to your build so broken blocks never reach the live site. Fixing invalid schema.org types covers invented and misspelt type names, and how to pick the most specific real type, for example BlogPosting rather than a non-existent BlogPost.

Required values and formats

Fixing missing required fields explains the difference between what schema.org allows and what Google requires for a rich result, with the fields that matter for common types. Fixing date format errors covers ISO 8601, time zones and CMS templates that output UK-style or empty dates. Fixing image schema problems covers relative image URLs, images blocked from crawling and images too small to be used.

How blocks relate to each other

Fixing duplicate or missing @id explains how identifiers link entities and why every page reusing one identifier for different things causes confusion. Fixing dangling references covers an author or publisher that is referred to but never described. Fixing multiple competing schemas covers pages where a theme, a plugin and hand-written code all describe the same thing differently.

By platform

WordPress covers SEO plugin output and how to change or extend it safely. Shopify covers theme markup, review apps and editing Liquid templates. Next.js covers rendering JSON-LD in server components and checking it in continuous integration.

A valid block, piece by piece

This Article block passes all three layers. It is worth reading the notes below it, because each keyword does a specific job that several findings refer to.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://www.example.co.uk/#organization",
      "name": "Northwood Furniture",
      "url": "https://www.example.co.uk/",
      "logo": "https://www.example.co.uk/images/logo-600.png"
    },
    {
      "@type": "Person",
      "@id": "https://www.example.co.uk/about/sam-price/#person",
      "name": "Sam Price",
      "url": "https://www.example.co.uk/about/sam-price/"
    },
    {
      "@type": "BlogPosting",
      "@id": "https://www.example.co.uk/blog/oiling-oak/#article",
      "headline": "How to Oil an Oak Garden Bench",
      "datePublished": "2026-04-02T09:00:00+01:00",
      "dateModified": "2026-09-10T14:15:00+01:00",
      "image": "https://www.example.co.uk/images/oiling-oak-1200.jpg",
      "author": { "@id": "https://www.example.co.uk/about/sam-price/#person" },
      "publisher": { "@id": "https://www.example.co.uk/#organization" }
    }
  ]
}
</script>

@context tells the parser the terms come from schema.org. Without it, the names mean nothing.
@graph holds several entities in one block, so a page does not need three separate scripts.
@id gives each entity a stable identifier. It is conventionally a URL plus a fragment; it does not need to be a page that loads, but it must be unique to that entity and the same everywhere you mean the same thing.
References such as "author": {"@id": ...} point at an entity defined elsewhere in the graph. Every reference needs a matching definition, which is the closed-graph rule the checker enforces.

Which findings to fix first

Syntax errors. These wipe out entire blocks, so one fix can restore several types at once. Nothing else in a broken block is even checked until the JSON parses.
Invalid types. An unknown type means the entity is not recognised at all, and every property under it is wasted.
Missing required fields on types that earn rich results. Product, Recipe, Event, JobPosting, LocalBusiness and similar types lose eligibility when a required field is absent.
Competing blocks. Two different descriptions of the same product or article make it unclear which to believe. Choose one source.
Dangling references and @id problems. These rarely block a rich result on their own but weaken how entities connect across your site.
Date and image formats. Usually warnings rather than errors, but cheap to fix and they affect how results display.

⚠️ Fix the markup at its source, not in the page. If a template or plugin produces the error, editing one page's output will be overwritten on the next update and leaves every other page broken.

A sensible order of work

Run the JSON Checker on one page of each template: home, article, product, category, contact.
For each block, fix any syntax error first and re-run until every block parses.
Work out where each block comes from: theme, SEO plugin, app, tag manager or hand-written code. Note any type that more than one source produces.
Remove or switch off duplicate sources so each entity is described once.
Correct invalid type names and fill in required fields from the visible page content.
Give shared entities such as your organisation and authors one stable @id each and reference them rather than repeating them.
Normalise dates to ISO 8601 with a time zone and make every URL absolute.
Add a JSON parse check to your deployment or build so syntax errors are caught before they go live.
Confirm the changes in Google Search Console's structured data reports once Google has recrawled the pages.

The JSON-LD Schema Guide explains the checker's output in detail and the example report shows it on a real page. For choosing and designing markup rather than repairing it, see the Schema Builder Guide; for page-by-page debugging with severity levels, see the Schema Debugger Guide; and for what earns a rich result, the Rich Snippets Guide.

Questions and answers

1. Why does Google say my page has no structured data when I can see the code?

The most common reason is a syntax error. If the JSON inside a script block cannot be parsed, Google discards the whole block, so tools report it as missing rather than broken. Other causes are markup added by JavaScript that has not been rendered yet, a script tag with the wrong type attribute, or markup served only to logged-in users. Run the page through a JSON parser first; that usually reveals the problem within seconds.

2. Is JSON-LD better than Microdata or RDFa?

Google supports all three formats and has said it prefers JSON-LD where a site can use it, mainly because it sits in one block separate from the visible HTML and is easier to maintain. Microdata and RDFa are spread across the page's tags, so a design change can break them without anyone noticing. If your site already uses Microdata that validates, there is no urgent need to convert, but new markup is simpler to manage as JSON-LD.

3. Can I have more than one JSON-LD block on a page?

Yes. Several blocks are perfectly valid, and many sites have one from the theme, one from an SEO plugin and one from an app. The problems start when two blocks describe the same thing differently, such as two Product entities with different prices, or when an entity is defined in one block and referenced by an @id that does not match. Combining everything into one @graph makes these problems much easier to spot.

4. Does JSON-LD have to be in the head?

No. JSON-LD works in the head or the body, and Google reads it in either place. Putting it in the head is a common convention and keeps it away from content editors, but body placement is fine and is often easier on platforms that do not let you edit the head. What matters more is that it is present in the HTML the server sends, rather than injected later by script where some crawlers will miss it.

5. What does a dangling reference mean?

It means one part of your markup points to an entity by its @id, but nothing on the page defines an entity with that @id. A typical case is an Article whose author refers to a Person identifier, while the Person block was removed or given a slightly different address. The reference then leads nowhere. Either add the missing entity to the graph with the same @id, or replace the reference with the full details.

6. Why does the checker flag my dates when they look correct?

Structured data dates should follow ISO 8601, which means year, month and day in that order, such as 2026-09-28, and ideally a time and time zone offset as well. Dates written as 28/09/2026 or September 28, 2026 are easy for people to read but ambiguous for machines. A date with a time but no zone can also be read as the wrong day. Fix the template that outputs the date so every page is corrected together.

7. Will valid JSON-LD improve my rankings?

Google has said structured data is not a general ranking factor. What it does is make pages eligible for rich results, such as product prices and review stars in search, and help search engines and other systems understand what a page describes. Valid markup is a prerequisite for those benefits, not a guarantee of them. The page still has to be useful and relevant, and Google decides case by case whether to show an enhanced result.

Check the JSON-LD on your page

The JSON Checker parses every JSON-LD block on your page, validates the syntax, checks each type against schema.org, verifies required fields, detects conflicting types and runs the result against Google rich result criteria.

Run the JSON Checker →