How to validate structured data without Google tools

Structured data validation has become oddly dependent on Google-facing tools. That is understandable: many teams add JSON-LD because they want rich results, and Google’s testing tools are familiar. But structured data is not a Google format. It is usually JSON-LD using Schema.org vocabulary, embedded in HTML, interpreted by many consumers, and maintained by your own publishing workflow.

If you only validate through a search-engine lens, you can miss basic problems: invalid JSON, data that disappears after rendering, stale product prices, conflicting canonical URLs, or markup that is technically valid but semantically silly.

A better workflow is standards-first. Validate the data as data, then validate the vocabulary, then validate the page as it exists in production.

What are you actually validating?

“Structured data” is not one thing. On most websites it has four layers:

1. JSON syntax — is the code parseable?
2. JSON-LD model — does it expand into meaningful linked data?
3. Schema.org vocabulary — are the types and properties plausible?
4. Page-level truth — does the markup match what users and crawlers can see?

Google tools mostly focus on the fourth layer plus Google-specific rich-result eligibility. Useful, yes. Complete, no.

For example, this can be valid JSON-LD and still be poor structured data:

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Best winter jackets",
  "datePublished": "2026-01-12",
  "author": {
    "@type": "Organization",
    "name": "Editorial Team"
  }
}

There is nothing broken here. But if the visible page has a different headline, no author attribution, and a last-modified date that contradicts the markup, you have a quality problem rather than a syntax problem.

Step 1: Parse the JSON before thinking about SEO

Start with the boring check: can the JSON be parsed?

JSON-LD embedded in HTML often breaks because of small template mistakes:

• trailing commas
• unescaped quotes in product names
• invalid line breaks inside strings
• missing braces after conditional fields
• duplicate script blocks from layout inheritance
• CMS plugins outputting partial objects

For local checks, you do not need an SEO platform. Use the tools already in your development stack.

In JavaScript:

const blocks = [...document.querySelectorAll('script[type="application/ld+json"]')];

for (const block of blocks) {
  try {
    JSON.parse(block.textContent);
  } catch (error) {
    console.error('Invalid JSON-LD:', error.message, block);
  }
}

In CI, extract the script contents from rendered HTML and parse them as JSON. This catches many problems before they reach production.

The important point: do this before any Schema.org validation. A vocabulary validator cannot help if the data is not valid JSON.

Step 2: Check JSON-LD behaviour, not just JSON syntax

Valid JSON is not automatically valid JSON-LD. JSON-LD uses concepts such as @context, @type, @id, and graph relationships. If those are malformed, parsers may interpret your data differently from what you intended.

At minimum, confirm:

• every block has an appropriate @context
• primary entities have clear @type values
• repeated entities use stable @id values where useful
• nested entities are connected logically
• arrays are used when multiple values are possible

For larger sites, stable identifiers are especially helpful. If your organization appears in Article, Product, BreadcrumbList, and FAQPage data, using the same @id helps consumers understand that these are references to the same entity, not four unrelated organizations with the same name.

A typical pattern looks like this:

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://example.com/#organization",
  "name": "Example Ltd",
  "url": "https://example.com/"
}

You are not trying to impress a validator here. You are making your data less ambiguous.

Step 3: Validate against Schema.org vocabulary

Once the JSON and JSON-LD structure are sound, check the vocabulary.

The Schema.org validator is useful because it tests against Schema.org terms rather than one search engine’s rich-result rules. It can show whether properties are recognized, whether types are being interpreted as expected, and whether your nested structures make sense.

This is where you catch mistakes like:

• publishingDate instead of datePublished
• imageUrl where image is expected
• Product markup on a category listing that is not a product
• AggregateRating without a meaningful reviewed item
• Person used for a brand account

Be careful with warnings. Schema.org is intentionally flexible. A validator may allow a property that is not useful for your use case, or warn about something that is optional. Treat validation as evidence, not a verdict.

A practical rule: if a property helps a machine understand the page more accurately, keep it. If it exists only because someone copied it from a snippet generator, question it.

Step 4: Compare markup with visible content

Search engines and other data consumers tend to distrust markup that does not match the page. More importantly, users deserve consistency.

For each structured data type, compare the markup with the visible page:

Article and BlogPosting

Check that the headline, author, published date, modified date, image, and publisher are visible or reasonably inferable. If you publish AI-assisted content, your structured data should not be used to launder unclear authorship. We have written separately about honest AI disclosure on a small website, and the same principle applies here: metadata should clarify, not obscure.

Product

Check name, price, availability, currency, variants, ratings, and review counts. Product structured data is particularly prone to going stale because prices and stock status change outside the CMS.

LocalBusiness

Check name, address, phone number, opening hours, and service area. If your footer says one thing and your JSON-LD says another, the JSON-LD is not “better”. It is contradictory.

BreadcrumbList

Check that breadcrumb positions match the visible breadcrumb trail and that URLs are canonical, crawlable, and not redirected unnecessarily.

This is not glamorous work. It is also where many structured data problems are found.

Step 5: Validate the rendered page, not your template

Many sites generate JSON-LD through JavaScript, tag managers, personalization layers, or component hydration. That means the template file may not represent what a crawler or browser actually sees.

Validate the rendered HTML in at least three states:

• local development build
• staging or preview URL
• production URL

Use browser DevTools to inspect the final DOM. Search for application/ld+json and copy the exact script content that exists after rendering. If server-rendered markup differs from hydrated markup, decide which version you expect consumers to read.

Also check whether structured data is being duplicated. Duplicate Article or Product blocks are common when a CMS plugin and a custom component both emit schema. Duplication is not always fatal, but conflicting duplication is a problem: two prices, two authors, two publication dates, or two canonical URLs.

This is similar to reading performance and diagnostics reports: the first task is not to panic, but to separate signal from noise. The same habit helps when you read a Lighthouse report without panicking — although structured data itself should not be reduced to a single score.

Step 6: Check production transport details

Structured data can be perfect in your source and still fail in production because the page is not accessible in the way you assume.

Check:

• final status code is 200, not a soft 404
• canonical URL matches the page you are validating
• redirects are intentional and stable
• robots directives do not block indexing where indexing is expected
• HTML is not replaced by an error page for some user agents
• cached pages are not serving stale JSON-LD

This is where HTTP inspection matters. If a product page redirects through three URLs before reaching a canonical destination, validate the final page, not the first URL copied from the CMS. For the raw mechanics, our guide to debugging redirects and HTTP headers in production is a useful companion.

Structured data does not live in a vacuum. It travels with headers, redirects, caching, canonical tags, and robots directives.

Step 7: Add structured data tests to your release process

Manual validation is fine for one page. It does not scale across hundreds or thousands of URLs.

A simple automated test suite can catch the most expensive mistakes:

• fetch representative URLs from each template type
• extract all JSON-LD blocks
• parse them with JSON.parse
• assert required fields for each page type
• check that dates are valid ISO 8601 strings
• check that URLs are absolute and canonical
• check that prices and availability exist for product pages
• check that duplicate entities do not conflict

You can run this in CI for templates and on a schedule for production URLs. The goal is not to prove that every rich-result feature will appear. Nobody outside the search engine can promise that. The goal is to keep your own data accurate, parseable, and consistent.

<!-- tool-cta:start -->

💡 Try this: Before validating schema logic, run your JSON-LD through the JSON Formatter to catch syntax errors that would otherwise break every downstream check.

<!-- tool-cta:end -->

A standards-first validation checklist

Use this short checklist before asking whether a search engine likes the page:

• Is every JSON-LD block valid JSON?
• Does each block include the correct @context and @type?
• Are Schema.org properties spelled correctly?
• Does the markup match visible content?
• Are dates, prices, ratings, and availability current?
• Are URLs absolute, canonical, and reachable?
• Is the rendered production page the same page you tested?
• Are duplicate entities intentional and non-conflicting?

If you can answer yes to those questions, you have done the durable part of structured data work. Search-specific testing can still be useful later, but it should be the final compatibility check, not the foundation of your validation process.