JSON-LD Validation: Separate Syntax, Visible Content and Search Features

“The validator is green” is not a complete acceptance criterion. A validator may accept the JSON while the page describes the wrong organization, an old price or a question readers cannot see. A tool may also omit a vocabulary type because it tests a particular search feature, not all of Schema.org.

This guide is for validating an existing implementation. Google’s AI optimization guide does not require special GEO markup. The task is to represent the page accurately and know what each check establishes, rather than accumulate validation badges or promise citations.

1. Parse the data and check the embedding boundary

First confirm that the intended object is valid JSON. Prefer a JSON serializer over string concatenation. Parsing catches malformed commas or quotation marks; it does not establish that the claims are true.

Then inspect the way that serialized JSON enters HTML. Text supplied by an editor or user can contain characters that affect a script element’s boundary. Use the framework’s documented safe embedding approach and handle less-than characters appropriately; do not treat JSON serialization alone as an HTML safety guarantee. Check the actual output, including a representative boundary case, when this code changes.

The following is a teaching example, not additional live page markup. Its visible question and answer are:

What does a JSON syntax check establish? It establishes that the data can be parsed as JSON, not that the statements are true.

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "What does a JSON syntax check establish?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "It establishes that the data can be parsed as JSON, not that the statements are true."
      }
    }
  ]
}

2. Check the vocabulary you actually use

Use the Schema.org validator for general vocabulary checks. Read the relevant type definitions, including DefinedTerm, FAQPage and HowTo, before interpreting properties or warnings.

A field being syntactically accepted does not make its meaning appropriate. A named definition is not a product credential. An FAQ page is not a reader-submitted discussion. A marketing timeline is not necessarily an executable procedure. Resolve the semantic mismatch rather than add fields to silence a tool.

3. Inspect the rendered content and identity

Test the intended route and authored language. Confirm the page title, description, canonical URL and entity relationships describe the same page. For article markup, preserve the original publication date and use a real editorial modification date only when a substantial edit happened.

Compare every marked question, answer, definition and step with text readers can access. The visible content need not duplicate the JSON byte for byte, but it must support the same meaning and qualifications. Google’s structured-data policies require accurate representation of visible content.

Inspect the returned HTML for the expected application/ld+json element. Teaching snippets should remain displayed code; they should not accidentally become extra active script elements. If one shared template generates many pages, check representative variants and the data contract rather than manually rechecking every unchanged page.

4. Verify current search-feature eligibility separately

Google’s testing-tool guidance distinguishes the Rich Results Test for Google-supported features from general Schema.org validation. A type not producing a supported result is not, by itself, proof that its vocabulary is invalid. Even valid eligible markup does not guarantee a search presentation.

Check current documentation at the time of implementation. Google’s update record says FAQ rich results stopped appearing on May 7, 2026 and its documentation was removed on June 15. The FAQPage example above explains vocabulary; it does not offer access to that feature. Do not infer every other product’s behavior from this Google change.

Finish with an explicit acceptance record

Record the affected routes, data version, checks run and remaining limitations. “JSON parses, type semantics fit, rendered content agrees and dates are truthful” is a concrete implementation result. “AI citations will increase” is a different claim that requires separate observations and cannot be inferred from validation.

For a small factual correction, one affected source-and-output check may be enough. Changes to a shared serializer, locale routing or external-data boundary warrant broader representative coverage. Repeat checks after relevant changes or failures, not as an endless polish loop. The goal is a trustworthy existing page and a reviewable change.