Fix JSON-LD Errors in WordPress Without Breaking the Page

Before fixing a JSON-LD error, decide which kind it is. A syntax error means the block is not valid JSON, so nothing in it can be read. A vocabulary error means the JSON parses but uses a schema.org type, property or value incorrectly. A feature error means the markup is valid schema.org but lacks something a specific Google feature requires. The tools report them differently, and each kind is fixed in a different way. In every case, fix the setting, field or code that prints the block, not the rendered HTML.

Locate the failing script and its source

Start with the public URL. The schema_inventory.py script in Audit the structured data your WordPress site publishes numbers each JSON-LD block on a page and reports blocks that fail to parse, with a line and column. The exact message wording depends on your Python version. The Rich Results Test and the Schema Markup Validator report errors against the same page.

Then find what printed the block: an SEO plugin setting, a theme option, a page builder widget, a header-scripts plugin, a custom field, or code in the theme. The audit guide covers how to trace the source. You need the source before you edit anything, because a fix made anywhere else can be overwritten or duplicated on the next page load.

Classify the error

Google’s Rich Results Test help, checked September 27, 2026, lists results such as “N valid item(s) with warnings detected”, so an item with warnings still counts as valid. Treat warnings as optional improvements, not as a broken page.

Fix syntax errors

JSON is stricter than JavaScript. MDN’s JSON reference, checked September 27, 2026, lists the differences: property names and strings must use double quotes, trailing commas are not allowed, and comments are not supported. In WordPress, look first at hand-edited markup and at text pasted from a word processor.

This illustrative block has four common mistakes:

{
  "@context": "https://schema.org",
  "@type": "Event",
  'name': "Spring pruning class",
  "description": "Bring gloves and "sharp" secateurs",
  // added by Sam
  "startDate": "2026-04-18T10:00:00-04:00",
}

The single quotes around name, the unescaped double quotes inside the description, the comment line, and the comma after the last property each break parsing. Curly quotes (“ and ”) pasted from a document around names or values cause the same failure, and they are hard to see. The corrected block:

{
  "@context": "https://schema.org",
  "@type": "Event",
  "name": "Spring pruning class",
  "description": "Bring gloves and \"sharp\" secateurs",
  "startDate": "2026-04-18T10:00:00-04:00"
}

Wrap the corrected text in <script type="application/ld+json"> and </script>, then paste it into the Rich Results Test’s code input to confirm it parses before you save it anywhere. Keep a copy of the working version.

Fix vocabulary and value errors

Once the JSON parses, the Schema Markup Validator checks it against schema.org; schema.org’s description of the tool, checked September 27, 2026, says it will “validate Schema.org-based structured data”. Common problems:

• Misspelled or invented properties, such as datepublished or authorName. Check the spelling and capitalization against the type’s page on schema.org, for example datePublished on schema.org/Article.
• A property on the wrong type, such as recipeIngredient on a BlogPosting. Use the type that describes the content, or drop the property.
• Text where an object is expected. Schema.org’s data model, checked September 27, 2026, says that “in the spirit of ‘some data is better than none’, search engines will often accept” text in place of an expected type. Accepted is not the same as preferred. Google’s Article documentation, checked the same day, shows author as a Person or Organization with a name, so an object is the better value:

{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "When to prune tomatoes",
  "author": { "@type": "Person", "name": "Sam Rivera", "url": "https://garden.example/author/sam/" },
  "datePublished": "2026-03-02T09:00:00-05:00"
}

• Dates in local formats, such as 03/02/2026. Google’s Article documentation asks for ISO 8601, and recommends including the timezone.

Fix missing feature requirements

The Rich Results Test reports what a Google feature needs. Google’s introduction to structured data, checked September 27, 2026, says you must include all required properties for an object to be eligible for enhanced display. For example, each item in a BreadcrumbList needs a position and a name, and every item except the last needs an item URL, per Google’s breadcrumb documentation, checked the same day.

Only add what is true and visible on the page. If a required property describes something the page does not have, the right fix is to drop that markup rather than invent a value. Whether a valid page then shows a rich result is a separate question, covered in Your schema validates but no rich result appears.

Edit the source, then validate the public page

Make the fix where the block is stored:

• Plugin or theme settings. Change the field, save, and let the component print the corrected output.
• Custom code. Build the data as a PHP array and encode it with wp_json_encode(), rather than writing JSON by hand inside a template string. Hand-written strings break as soon as a title contains a quote.
• Do not patch the output. Filtering the whole page’s HTML to rewrite a broken script hides the problem and breaks again when the source changes.

If the block comes from WP Visibility’s per-post custom schema, it lives in the editor’s WP Visibility sidebar, under Structured data, in the Advanced field. Three details from the released 2.10.3 code matter there:

1. The field takes JSON only: one object with an @type, or an array of such objects. Do not paste <script> tags. An object wrapped in @graph with no top-level @type is not added to the page, and neither is an array item without an @type.
2. The field shows “Valid JSON.” or a warning as you type. “Valid JSON.” means only that the text parses as an object or array; it does not check for @type. If you save while a warning shows, the stored value is empty, so any earlier working version in that field is gone. Keep a copy before editing.
3. On output, < and > in values are escaped as \u003C and \u003E. That is valid JSON, and it stops a value from closing the script element. You can check it with harmless text such as a headline in the Advanced field containing Tomatoes <early>. Do not test with the post title: the automatic headline has its tags stripped.

After saving, clear any page cache, then run the public URL through the Rich Results Test (URL input) and the Schema Markup Validator. Rerun the inventory script on one URL from every template the component affects.

JSON-LD repair checklist

• The failing block and its source identified.
• Error classified as syntax, vocabulary or feature requirement.
• Syntax fixed and tested in the code input before saving.
• Properties checked against schema.org; objects used where they are expected.
• Required feature properties added only when true and visible.
• Fix made at the source; public URLs revalidated across templates.