Markup validation and debugging
Find the mismatch before treating the markup as ready.
A parser can accept a graph that describes the wrong facts. Diagnose format, vocabulary, evidence and live output separately so the repair addresses the real failure.
Start with the visible answer and a reproducible record.
Record the page URL, response status, content version, observation time, relevant visible passage and every structured-data block. Include JSON-LD, Microdata and RDFa where present. A test against an isolated snippet cannot show what a theme or plugin adds later. Keep a recoverable copy of the last accepted output before changing a shared generator.
State the intended entity and page job before choosing a rich-result target. Evidence, page identity and URLs should already be settled. When a claim is unresolved, hold that claim instead of inventing a property entry to silence a tool. Record the finding, affected node/property, evidence, severity, repair owner and test that must repeat.
Fix parser failures before interpreting the graph.
A parser failure prevents the format from being read reliably. In JSON-LD, inspect brackets, commas, quotation marks, escape characters and valid JSON values. Start at the reported location, but also inspect the preceding token because the first visible error may be caused earlier. Retest the entire block after a small repair.
A date like “2026-02-30” can be a valid JSON string while being an impossible calendar date. Parsing JSON successfully does not establish that a typed property entry is suitable. Separate format failure from a vocabulary or factual failure. Do not change a factual entry merely to make a parser stop complaining.
Check types, properties and values against the vocabulary.
Confirm that the type describes the subject and that the property has an appropriate meaning and expected entry form. A node about an article is different from the organization that publishes it. Check date representation, URLs, enumerated values and references to other IDs. A misspelling can create an unintended term rather than the property you meant.
Schema.org vocabulary checks and Google feature checks answer different questions. A vocabulary term can exist without belonging to a currently supported search feature. Likewise, a tool’s warning about a recommended field does not establish that the missing information exists. Supply a supported entry or keep the omission and its consequence visible.
Review search-feature requirements separately.
If a Google feature is the goal, read its current documentation through the structured-data gallery, then check the relevant required properties and content rules. Use the Rich Results Test for supported Google features and a vocabulary validator for broader Schema.org inspection. Record the tested input and tool output rather than only a green screenshot.
Google requires structured data to represent the page’s content. Passing an automated test does not establish every content-policy condition or guarantee display. If the page has no applicable supported feature, a feature test’s lack of a detected result is not by itself proof that all vocabulary use is wrong.
Worked repair: an impossible date and a missing claim.
This fictional example is an editorial release record, not a test performed on a client site. A visible article states “Published 28 February 2026”. Its JSON-LD candidate contains "datePublished":"2026-02-30". The same candidate also adds "award":"Regional Editorial Prize 2026", although neither the page nor the supplied evidence supports any award.
The publication record confirms 28 February; the impossible day is a transcription error. Repair it to "datePublished":"2026-02-28", then verify that the visible date still matches. Remove the award property because it is unsupported. Do not add an invented award sentence to the page or substitute another prize. If the correct date were unknown, hold the date rather than guess.
An illustrative repaired fragment is {"@context":"https://schema.org","@type":"Article","datePublished":"2026-02-28"}. It shows only the changed field, not a complete release graph or a claim of feature eligibility. The complete candidate still needs its identity, page/content match and relevant feature checks.
| Finding | Evidence and repair | Required repeat check |
|---|---|---|
| Impossible date | Visible publication statement and source record agree on 28 February; correct machine date to 2026-02-28 | Parse full block; inspect date entry and visible match |
| Unsupported award | No supplied award evidence or visible support; remove property | Confirm all emitted blocks omit the unsupported claim |
| Possible template duplication | Theme and plugin can both add Article nodes; inspect final assembled page | Compare final source and rendered graph after deployment |
Inspect rendering and the final release output.
After a proposed repair, inspect the normal response and rendered DOM in the intended environment. Confirm that the same candidate was deployed, that it appears on the correct canonical page and that another generator has not reintroduced the old property. Check resource failures and any script that inserts or replaces structured data.
A local file check is useful evidence about that file. It is not a rendered-page test, a crawler fetch or a search-index observation. Record which of those was inspected. A stale cache can explain a difference between a new source record and an old page response; identify the cache and recheck instead of reporting success from the editor alone.
Prioritize by consequence and affected scope.
Treat unreadable markup, false identity, unsupported commercial claims or a broken required feature field as distinct findings with a reasoned release effect. A recommended-field omission may deserve improvement without blocking an otherwise truthful page. An optional warning should not outweigh a factual contradiction. Use plain severity definitions agreed for the project.
For example, hold a false current price or invented award; repair a parser failure before relying on the graph; schedule a supported optional enhancement separately. Check the number and types of affected pages before changing a common template. Do not claim that every warning is a ranking penalty or that removing it promises a rich result.
Monitor changes with an owner and a regression case.
Keep the prior and repaired captures, tool versions or observation dates, the responsible generator and the repeat test. Reopen review after content, identity, offer, template, plugin or feature-policy changes. Search Console reports can provide further observations, but their coverage and timing differ from a single live test.
Close the finding only when the required evidence exists. If deployment checks fail, pause the wider change and use the recorded rollback route when it restores an accurate accepted state. A successful rollback still needs rechecking. Maintain the smallest useful issue record rather than rerunning unrelated work for a minor change.
Sources and related learning
Google structured data policies. Google supported structured data features. Schema.org data model.
The worked scenarios are fictional teaching records. They do not report live tests, client work or measured search outcomes.
Continue with semantic SEO learning and schema and entity identity. Recheck the evidence behind a claim. Inspect rendered page output.