What structured data validation means

Structured data gives machines an explicit description of entities, attributes, and relationships found on a webpage. It is often added with JSON-LD, although other supported formats include Microdata and RDFa.

Validation asks several related questions:

• Can the markup be parsed?
• Does it use recognized types and properties?
• Are property values expressed in an expected form?
• Does it include fields required for a particular search feature?
• Does the markup accurately describe the page people can see?
• Can search systems retrieve and process the markup after publication?

These questions belong to different validation layers. A page may pass one layer and fail another. For example, a JSON-LD block can be valid JSON while using an inappropriate Schema.org property. It can also be valid Schema.org markup while lacking a field required for a Google rich result.

The layers of structured data validation

1. Syntax validity

Syntax validation determines whether the markup follows the grammatical rules of its format. In JSON-LD, common syntax problems include:

• missing or extra commas;
• unmatched braces or brackets;
• property names or text values without quotation marks;
• invalid escape characters;
• multiple top-level objects arranged incorrectly; and
• comments inserted into strict JSON.

A syntax error can prevent a parser from reading part or all of the structured data. Syntax should therefore be checked before deeper questions about meaning.

2. Vocabulary validity

Vocabulary validation checks whether the markup uses recognized Schema.org types and properties in a meaningful relationship. It may reveal:

• a misspelled type or property;
• a property attached to an unsuitable type;
• a text value where a URL, date, number, or nested entity is expected;
• an unrecognized enumeration value; or
• a relationship expressed at the wrong level of the entity graph.

For example, a property can be spelled correctly but still be placed on an entity that does not support it. That is not a JSON syntax problem. It is a vocabulary or modeling problem.

3. Search feature eligibility

Search engines may apply their own requirements to supported structured data features. These requirements are narrower than the full Schema.org vocabulary.

A type may be valid according to Schema.org without being supported as a rich result. A supported type may also require particular properties before it becomes eligible. Additional properties may be recommended because they help search systems understand the item more completely.

Eligibility does not guarantee display. Search engines decide whether to show rich results based on the query, page quality, technical accessibility, policies, device, location, and other contextual factors.

4. Factual and editorial accuracy

Automated tools cannot reliably determine whether a price is current, an author attribution is accurate, an event date is correct, or a review score reflects real reviews. Those questions require editorial knowledge and access to the underlying facts.

Structured data can be technically perfect while communicating incorrect information. Validation must therefore include a human comparison between the markup and the page.

5. Retrieval and rendering validity

Markup that works in a code editor may not appear in the version retrieved by a search system. Templates, plugins, JavaScript rendering, caching, content delivery systems, and deployment changes can alter or remove structured data.

Published validation should confirm that the final URL returns the intended markup and remains accessible for crawling and rendering. This connects structured data QA with the broader process of crawling, rendering, indexing, and ranking.

Structured data validation tools and what they test

No single validation tool answers every question. Each tool examines a different part of the markup and retrieval process.

The Schema.org Markup Validator and Google Rich Results Test are complementary rather than interchangeable. One is primarily vocabulary-oriented; the other evaluates supported Google search experiences.

A practical structured data validation workflow

Step 1: Identify the entity being described

Begin with the page rather than the markup. Determine the primary entity or subject the structured data is intended to describe. Depending on the page, that may be an article, product, organization, person, event, recipe, local business, job posting, or another entity.

Also identify any connected entities. An article may have an author and publisher. A product may have an offer and brand. A job posting may have a hiring organization and job location.

This prevents validation from becoming a search for green checkmarks without a clear model of meaning.

Step 2: Compare the proposed markup with the visible page

Before running a validator, confirm that important structured data claims have support on the page. Check names, dates, descriptions, availability, prices, ratings, addresses, images, authorship, and other relevant details.

Structured data should clarify the content people receive, not introduce a separate version of the page for machines.

Step 3: Inspect the actual implementation

Locate the JSON-LD, Microdata, or RDFa in the page output. When JSON-LD is used, verify that the complete script block is present and has the appropriate type:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Example Article"
}
</script>

If a plugin or template generates the markup, review the final output rather than relying only on configuration fields in the content management system.

Step 4: Check syntax

Run JSON-LD through a parser or a validator capable of reporting syntax errors. Correct parsing problems first because they can obscure later errors.

When a syntax error is reported near a particular line, also inspect the preceding line. A missing comma or quotation mark often causes the parser to fail only after it reaches the next property.

Step 5: Validate Schema.org vocabulary

Use the Schema.org Markup Validator to inspect recognized entities, properties, nesting, and value types. Review the extracted entity graph rather than looking only for a pass or fail label.

Ask whether the graph expresses the intended relationships. An entity appearing in the validator does not necessarily mean it has been modeled clearly.

Step 6: Test applicable rich result requirements

If the markup corresponds to a Google-supported search feature, test it with the Rich Results Test. Review required fields, recommended fields, detected items, and any feature-specific guidance.

If no eligible items are detected, possible explanations include:

• the markup contains a type that Google does not support as a rich result;
• the intended type is missing or malformed;
• required properties are absent;
• the markup is not present in the rendered output; or
• the tested code or URL differs from the final implementation.

Step 7: Resolve errors before evaluating warnings

Errors generally deserve priority because they may prevent parsing or feature eligibility. After correcting them, rerun the test. One syntax or nesting correction can remove several downstream messages.

Warnings require more interpretation. Some identify recommended information that the page genuinely does not provide. Others reveal an omission worth correcting. Do not add unsupported values merely to silence a warning.

Step 8: Conduct a human meaning review

Read each important property as a factual statement. For example:

• datePublished says the work was published on a particular date.
• author attributes the work to a person or organization.
• offers.price states a particular price.
• jobLocation describes where a position is located.
• aggregateRating summarizes a body of ratings.

Confirm that each statement is accurate, current, and supported. This is the point where validation moves from technical acceptance to verified meaning.

Step 9: Test the published URL

After publication, validate the live URL rather than only the copied code. Confirm that the canonical page is indexable when indexing is intended, resources can be retrieved, and the rendered output contains the expected structured data.

This final check can catch deployment, caching, template, and environment differences that were not visible during drafting.

How to interpret structured data errors and warnings

Validation messages are diagnostic signals. Their meaning depends on the tool, the schema type, and the page.

An error is not always the root cause

Several errors may descend from one structural problem. If a nested object is closed too early, properties that follow may appear to belong to the wrong entity. Correcting the nesting can resolve multiple messages at once.

A warning is not permission to invent information

A warning often indicates that a recommended property is missing. If the information is unavailable, uncertain, or not present on the page, leaving the warning unresolved may be more accurate than inserting a placeholder or unsupported claim.

A green result is not final proof

A successful result means the markup passed the checks performed by that tool at that time. It does not establish that:

• the page will receive a rich result;
• the claims are factually correct;
• the marked-up content follows every applicable policy;
• search systems have crawled the latest version;
• the page is canonical or indexable; or
• future template changes will preserve the markup.

Structured data must correspond with visible page content

One of the most important validation checks cannot be reduced to syntax: the markup should represent the content and entities users can reasonably understand from the page.

Problematic mismatches include:

• a structured data title that materially differs from the page heading;
• a price or availability status that is no longer shown or no longer current;
• an aggregate rating without visible supporting rating information;
• an event date that conflicts with the event details;
• a job location that differs from the visible listing;
• an author entity that does not match the stated byline; or
• markup describing a product, recipe, or event that is only mentioned incidentally.

Exact wording does not always need to be identical. A concise structured description can differ from a longer visible passage while preserving the same meaning. The essential requirement is factual and semantic correspondence.

This is also why structured data and semantic HTML serve different but related roles. Structured data provides explicit machine-readable relationships, while semantic HTML organizes the visible document. Neither should be used to conceal weaknesses in the other.

Structured data validation after publication

Validation is not limited to the moment markup is created. Published pages change through editorial updates, plugin releases, theme changes, product feeds, expired events, removed jobs, and revised business information.

Use Search Console as an observation layer

Where relevant reports are available, Google Search Console can show detected items, invalid items, changes over time, and affected URLs. It may also help reveal differences between an isolated test and Google’s processing of indexed pages.

Search Console reports should be interpreted with care:

• reports may not update immediately after a page changes;
• not every Schema.org type has a dedicated report;
• a reported sample may not represent every affected URL;
• validation requests do not guarantee immediate recrawling; and
• an item can be valid without appearing as a rich result.

Revalidate when the page’s facts change

Structured data should be reviewed when information such as the following changes:

• publication or modification dates;
• prices and availability;
• event schedules;
• job status or application deadlines;
• business names, addresses, or telephone numbers;
• authors and publishers;
• ratings or review counts; and
• canonical URLs or primary images.

Include structured data in regression testing

Sites using shared templates can introduce the same error across many pages. A small group of representative URLs can be retested after changes to themes, plugins, rendering logic, content models, or deployment systems.

This turns validation into part of a durable validation workflow rather than a one-time publishing task.

Common structured data validation mistakes

Testing only copied code

A code snippet may pass while the published page contains an older version, duplicate markup, or no markup at all. Test both the code during development and the final URL after publication.

Using only one validator

A JSON parser, Schema.org validator, rich result test, and published-page inspection answer different questions. Treating one tool as universal leaves important gaps.

Adding fields solely to remove warnings

Completeness is useful only when the added information is accurate and supported. A truthful incomplete model is preferable to a complete-looking model built from assumptions.

Confusing Schema.org validity with rich result eligibility

Schema.org supports a broad vocabulary for describing entities. Search engines support selected subsets for particular features. Valid vocabulary does not automatically create search feature eligibility.

Ignoring duplicate or conflicting markup

Plugins, themes, and custom code can each generate structured data. Multiple blocks are not inherently wrong, but conflicting names, URLs, dates, organization details, or entity identifiers can create ambiguity.

When reviewing existing implementations, follow a deliberate process for reviewing and adding structured data to existing pages rather than layering new markup over an unknown system.

Removing markup that does not produce a rich result

Structured data can still provide explicit machine-readable context even when it does not correspond to a visible search enhancement. Whether to retain it depends on its accuracy, maintenance cost, clarity, and role within the site’s information architecture.

Forgetting that guidance evolves

Schema.org vocabulary and search engine feature documentation can change. When a previously valid implementation begins producing a new message, compare it with current documentation before assuming that the validator or the page is wrong.

A concise validation checklist

• Identify the primary entity and intended relationships.
• Confirm that the visible page supports the structured claims.
• Inspect the markup in the final page output.
• Correct syntax and parsing errors.
• Validate types, properties, values, and nesting.
• Check applicable search feature requirements.
• Resolve errors before interpreting secondary warnings.
• Do not invent information to satisfy a validator.
• Review factual accuracy with a person who understands the content.
• Test the published canonical URL.
• Monitor relevant Search Console reports.
• Revalidate after material content or template changes.

Frequently asked questions

Can structured data be valid without producing a rich result?

Yes. The markup may be valid according to Schema.org while using a type that is not supported for a rich result. Even eligible markup does not guarantee display because search engines make that decision contextually.

Should every structured data warning be fixed?

No. A warning should be investigated, but a recommended field should be added only when the information is accurate, relevant, and supported by the page. Do not create values merely to remove warnings.

Why does one validator pass markup that another validator flags?

Different validators apply different rules. A syntax checker evaluates JSON grammar, the Schema.org validator examines vocabulary, and a rich result test applies search feature requirements. Their results can differ without being contradictory.

When should structured data be validated?

Validate during implementation, after publication, after relevant template or plugin changes, and whenever important facts in the markup change. Periodic checks are especially useful for pages containing time-sensitive information.