Validate JSON-LD on a live page

Intended result

Use this tutorial after JSON-LD is deployed to a publicly reachable page. You will save the exact markup found on that page, determine whether it parses and uses the intended vocabulary, check one relevant consumer’s documented feature rules, compare material values with the visible page, and leave a result another person can repeat.

You need the canonical live URL, access to the page in a browser, the source record for changing facts such as price or hours, and the name of any consumer feature you actually intend to support. This procedure does not test a fictional result, guarantee an indexed page, or establish that an AI product uses the markup.

For type choice, begin with the structured data type-selection reference. For a response-versus-rendering discrepancy, use the original-versus-rendered HTML playbook.

1. Define the object and facts you will test

Write one line before opening a validator: “This URL describes this subject for this purpose.” Then name the facts that could cause harm if wrong. For a Product that usually includes selected variant, price, currency, availability, seller, and identifiers. For an Article, it includes headline, author, publisher, images, and meaningful dates. For an Organization, it includes the public name, URL, logo, and identity links.

This boundary prevents a generic passing result from becoming approval for an unrelated object on the same page.

2. Capture the deployed markup

Open the canonical URL in a normal browser session. Record the final URL after redirects, then save the page source or response body. Search that capture for application/ld+json. Also inspect the Elements panel after the page has settled; JavaScript can add, remove, or change a JSON-LD script after the initial response.

In the browser console, run this read-only snippet to inspect an inventory of script contents. It returns a parsing error beside any block that is not valid JSON.

[...document.querySelectorAll('script[type="application/ld+json"]')].map((node, index) => {
  try {
    return { index, raw: node.textContent, json: JSON.parse(node.textContent) };
  } catch (error) {
    return { index, parseError: error.message, raw: node.textContent };
  }
});

Copy the returned value using your browser developer tools’ copy-value control and save it with the URL and test conditions. Preserve raw exactly, including in valid blocks; it retains the original text that parsing can normalize or discard. If markup appears only in the rendered DOM, record that fact and compare the original and rendered versions with the rendering playbook. A browser observation is not proof that every crawler uses the same rendering path.

3. Check JSON and Schema.org vocabulary

First fix any parseError from the browser inventory. Common causes are an unescaped quote inside a string, a trailing comma, or server output that inserted HTML into the script. A JSON parser only tells you that the text is valid JSON; it does not tell you that Product, Offer, or an @id relationship means what you intend.

Paste each block’s raw JSON text, or enter the public URL when appropriate, into Schema.org Validator. Review the reported types, properties, value shapes, and graph connections. An unknown property, an invalid value type, or a reference that identifies the wrong entity is a modeling issue. Correct the source or template, deploy it, and capture the live page again before moving on.

4. Test the intended Google Search feature, if there is one

Use Google’s Rich Results Test with the public URL. The URL test matters because it checks the deployed page through Google’s test environment. Use code input only as a development aid; it cannot prove that the live page delivers that code.

Choose the relevant result type in the report and read its documentation. Google documents required and recommended fields by feature, while Schema.org describes a broader vocabulary. A type can be valid Schema.org and still have no Google rich-result feature, so “no items detected” is not automatically a vocabulary failure. (Google’s structured data introduction)

5. Compare the result with the page and its source facts

Use a short comparison for every material value. This hypothetical product page demonstrates why a green validator result is insufficient:

The example object can parse and remain eligible for a consumer test while still describing a wrong price. Fix the authoritative field or the transformation that emits it. Do not change the visible price just to make an incorrect block agree.

For editorial markup, make the same comparison with the actual headline, accountable author, publisher, representative image, and meaningful dates. For a business location, compare public name, address, telephone number, hours, and the exact location identity.

6. Interpret the result before closing the work

Google says its Rich Results Test validates structured data and can preview some features. It does not guarantee a search appearance. The test also cannot decide whether a price, author, or claimed relationship is true. (Google’s structured data introduction)

7. Leave a recheckable validation record

Record the canonical URL, final URL, template or component version, captured JSON-LD, visible facts checked, authoritative sources, validator and feature-test results, unresolved warnings, owner, correction made, and next trigger. Recheck after a template release, CMS or feed change, commerce change, migration, or an update to the intended consumer’s requirements.

Use the relevant template as the implementation starting point: organization, local business, website, article, product, or review and aggregate rating. The Structured Data guide explains the ownership and modeling decisions that come before validation.

The work is complete when the captured live markup parses, accurately models the intended subject, meets any relevant consumer rules, matches the visible page and maintained facts, and has a recorded recheck condition.