Choose pages and types
Inventory page templates, genuinely useful schema types and language variants. Reject types unrelated to the content.
GUIDE / PROTOCOL
Audit structured data
Valid markup cannot repair an ambiguous page, missing information or an unverified identity.
Direct answer
How do you audit structured data beyond syntax?
Start with the rendered page and its canonical URL. List declared entities and properties, match each claim to visible content, then check syntax and the rules for the intended search feature.
01 / Review method
Review method
Compare HTML and markup
Check names, authors, dates, images, links and relationships in visible HTML and JSON-LD. Make important information visible or remove it from markup.
Validate at two levels
Use a Schema.org validator for structure and the rich results test for relevant Google features. Record errors separately from warnings.
Repeat after changes
Test templates and real pages after release, then monitor available reports. Check other languages and canonical URLs too.
IN PRACTICE
A correction is complete when its consequences have been reviewed
A page belongs to a system: summary, title, tables, links, language versions and structured data. Correcting a sentence requires finding where it is reused and checking that each version still tells the same story.
Which check comes first?
Choose the situation you observed. Each path gives a first check, useful evidence and the limit of that check.
Two pages give incompatible information
- First check
- Isolate the same claim on both pages and compare source, effective date and scope. Name the reference page and decision owner before propagating a correction.
- Evidence to retain
- Both URLs, exact wording, references, effective date, decision and pages or snippets repeating the information.
- Limit to remember
- The newest page is not necessarily correct. Changing a publication date does not resolve different definitions or missing evidence.
Language versions no longer say the same thing
- First check
- Compare a sensitive claim in every language: number, date, condition, exclusion and source link. Identify the approved version and translations actually synchronised.
- Evidence to retain
- Each language URL, content ID, passage, source version, approval date and unresolved difference.
- Limit to remember
- Translated navigation and correct language links do not establish content equivalence. Publishing staff must be able to see partial updates.
Structured data contradicts the visible page
- First check
- Match important properties to displayed passages: identity, date, offer or question and answer. Check content and correspondence before markup syntax.
- Evidence to retain
- URL, markup type, property, declared value, visible passage and verification after correction.
- Limit to remember
- A syntax validator confirms neither truth nor rich-result eligibility. Do not mark up absent or misleading content to improve visibility.
Further reading
| Situation | Avoid | Useful correction |
|---|---|---|
| Corrected number | Changing only the paragraph. | Review the associated table, caption, summary and structured value. |
| Moved page | Updating only the visible link. | Check destination, fragment and return path. |
| Translated version | Copying words while retaining an obsolete example. | Also review unit, date, source, links and interpretive scope. |
Identify
Which claims depend on the change?
Propagate
Which pages and languages reuse them?
Review
Do numbers, links and limits agree everywhere?
Final check
An update date marks a real edit. It does not redefine source or observation dates. Keep those roles separate in prose and references.
Documentary references
Consulted on .
Reading workshop
Readable JSON assigning the wrong author
The DEMO page is a French article signed by Lina DEMO. The DEMO laboratory is separately described as an organization; neither is real.
Fictional data and records for learning: none of these results comes from a live service query.
Four checks beyond syntax
The fictional markup mixes identity, attribution and language. No external validator is run here: the table separates issues a rendered-page review should examine.
If the table exceeds the screen, scroll horizontally; arrow keys work when the region is focused.
| Check | DEMO state | What it establishes | Correction to examine |
|---|---|---|---|
| JSON syntax | Well-formed braces, strings and arrays | The text can be parsed as JSON | Continue semantic checks. |
| @id identity | Same #entity for Lina and the laboratory | Two distinct objects are conflated in this case | Assign consistent identifiers to the objects actually described. |
| Article author | Lina visible; laboratory in author | Attribution differs from the page | Use the supported author without turning an organization into a person. |
| Declared language | French article; inLanguage=en | The declaration identifies another language | Check the article entity and this page variant. |
What does a successful syntax check permit?
Open each proposition to compare its diagnosis. More checks may still be needed.
Certifying authorship and entity identity
No. Values can be grammatically valid while identifying the wrong object.
Promising a rich search result
No. Eligibility and display are not guaranteed consequences of syntax.
Continuing with identity, visible content and type rules
Yes. Record syntax, editorial consistency and applicable criteria separately.
Fictional markup audit record
Page: DEMO article in French Visible author: Lina DEMO Issue: #entity shared by person and organization Issue: author points to laboratory Issue: inLanguage=en for this French article Decision: correct markup; no rich result certified
Fragments #entity and inLanguage are example clues, not findings about this site’s code or a complete schema to copy.
Documentation of the rules, separate from fictional examples
02 / Evidence to keep
Evidence to keep
Template inventory
URL, page type, expected schema, editorial owner and review date.
Field comparison
Marked-up value, visible evidence, field source and any discrepancy.
Validation report
Tool, tested URL, date, errors, warnings and result capture.
Correction decision
Field fixed or removed, owner and post-publication verification.
Compare other situations and exercises
PRACTICAL CHECK
Before reaching a conclusion
A frequent misreading and the check that helps avoid it.
Premature conclusion
Valid JSON-LD syntax is insufficient if markup describes information that is absent, outdated or contradicted by visible content.
Decisive check
Compare each important property with visible text, canonical URL and expected type. Validate syntax and relevant search-engine policies separately, then inspect deployed output.
AFTER THE REVIEW
Decide from the evidence
JSON-LD validates but states a fact absent from the page
Fix the markup or make the fact visible and verifiable. Syntax alone does not establish consistency with the page.
Two pages describe one entity with conflicting attributes
Choose an editorial source of truth, align the fields and check translations before validating again.
Decision and review trail
Decision and review trail
What the check must help decide and what to retain so the choice can be reviewed.
Sufficient evidence
Compare rendered JSON-LD with visible text, canonical URL and properties required for the selected type. Check several templates and languages.
Next decision
Remove unsupported properties, fix conflicting fields and validate rendered HTML. Document the types in use and their editorial upkeep.
Detailed inspection cases
Typical situations for preparing a check. They do not describe completed assignments or actual observations.
Markup promises more than the text
What to inspect
Match each structured property to visible information and supporting evidence.
Decision and action
Remove unsupported values; syntactically valid markup does not validate a rating, price or relationship.
Record to retain
Property, visible text, evidence and chosen correction.
One identifier names two objects
What to inspect
Compare occurrences of the same @id across pages and their identity attributes.
Decision and action
Reserve the identifier for one coherent object; distinguish person, organisation and page without duplicating one object’s identity.
Record to retain
Occurrences, affected objects and corrected identification rule.
Markup goes beyond visible content
What to inspect
Compare JSON-LD claims with displayed text and supporting sources.
Decision and action
Remove or correct properties the page does not substantiate.
Record to retain
Property, visible value, source and check outcome.
DOCUMENTED REFERENCE
Canonical JSON: a precise contract beyond sorted keys
JCS, described in Informational RFC 8785, defines a deterministic representation for cryptographic operations. It is stricter than arbitrary JSON and more complete than removing spaces.
| Reference | Value or form | What it identifies |
|---|---|---|
| INPUT | I-JSON · unique names | Property names must be unique and data compatible with I-JSON. A parser that already overwrote a duplicate can hide invalid input: check before information is lost. |
| WHITESPACE | no inter-token whitespace | No whitespace between tokens is emitted. Spaces within strings remain; stripping every blank from raw text would change data. |
| NUMBERS | ECMAScript · IEEE 754 binary64 | Numbers follow ECMAScript serialization of binary64 values. NaN and Infinity are rejected; greater precision needs an appropriate representation contract, often an explicit string. |
| PROPERTY ORDER | recursive · UTF-16 units | Sorting recursively compares decoded names as unsigned UTF-16 units without locale collation. Sorting UTF-8 bytes or code points can produce another order. |
| ARRAY ORDER | preserved | Array element order remains unchanged, though contained objects must be processed. Sorting every list changes meaning rather than presentation. |
| UNICODE | preserved · UTF-8 output | Unicode strings remain unchanged: JCS applies neither NFC nor NFKC. Final output is UTF-8. JSON canonicalization and linguistic normalization are different transformations. |
Published reference order for seven JSON names
RFC 8785 § 3.2.3. English labels retain their source form. UTF-16 units make the sort verifiable, particularly for the character outside the Basic Multilingual Plane.
| Name as code points | UTF-16 units | Source label (English) |
|---|---|---|
| U+000D | 000D | Carriage Return |
| U+0031 | 0031 | One |
| U+0080 | 0080 | Control |
| U+00F6 | 00F6 | Latin Small Letter O With Diaeresis |
| U+20AC | 20AC | Euro Sign |
| U+1F600 | D83D DE00 | Emoji: Grinning Face |
| U+FB33 | FB33 | Hebrew Letter Dalet With Dagesh |
RFC 8785 § 3.2.3. Copyright © 2020 IETF Trust and the persons identified as document authors. UTF-16 units added for explanation.
Implication for the record
Label a JCS output digest and its profile explicitly. It does not replace a digest of original received bytes; retain both objects when traceability needs them.
Is JSON.stringify sufficient for JCS?
Not alone. It does not check every input constraint or the required recursive sort. The RFC sorting example below helps reveal an unsuitable Unicode sort.
Primary documentation
Documentation consulted on .
DOCUMENTED REFERENCE
JSON Merge Patch: delete, retain or replace a value
A partial update must identify its format. JSON Merge Patch describes values to merge into a target; JSON Patch describes operations. Their media types and treatment of null differ. The simulator lets you inspect a merge without calling an API.
| Reference | Value or form | What it identifies |
|---|---|---|
| member absent | keep | An omitted patch member stays unchanged when the target is an object. A member set to null requests deletion; deleting an already absent member adds nothing. Empty strings, false and zero are values, not deletion instructions. |
| member: null | delete | An object patch merges recursively. A corresponding array, scalar or null target first becomes an empty object. Applying {} to the number 7 therefore produces {}, rather than 7. |
| {} | object target | A non-object patch replaces the entire target at that level. An array is replaced as a whole: it is neither concatenated nor matched by index or identifier. |
| null / [] / scalar | replace | At the root, a null patch replaces the whole target with null. As an object patch member, null deletes that member. A JSON Patch operation may be a better fit for explicitly assigning null to a property. |
| JSON values | ≠ text diff | The calculation operates on JSON values. Whitespace, indentation and property presentation order are not preserved. A valid merge result may still violate the API schema or business rules. |
Simulate JSON Merge Patch
Original teaching examples; no real document is modified.
Two JSON values, at most 4,000 UTF-16 units each, depth of 20 containers and 500 values per input. Numeric profile: integers written without fraction or exponent, from −9,007,199,254,740,991 to +9,007,199,254,740,991. Unique member names; Unicode strings without lone surrogates. These are tool limits.
Calculated locally; input is neither sent nor stored. The result remains on this page.
Simulation updated.
Resulting value
{
"title": "B",
"keep": true
}Ten merges: target, patch and result
| Step | Initial target | Patch to apply | Resulting value |
|---|---|---|---|
| 1 | {
"title": "A",
"note": "old",
"keep": true
} | {
"note": null,
"title": "B"
} | {
"title": "B",
"keep": true
} |
| 2 | {
"items": [
"A",
"B",
"C"
]
} | {
"items": [
"B"
]
} | {
"items": [
"B"
]
} |
| 3 | [
1,
2
] | {
"x": 1
} | {
"x": 1
} |
| 4 | {
"x": 1
} | null | null |
| 5 | [] | {
"missing": null
} | [] |
| 6 | 7 | [] | [] |
| 7 | {
"a": {
"x": 1,
"y": 2
},
"z": 3
} | {
"a": {
"x": null
}
} | {
"a": {
"y": 2
},
"z": 3
} |
| 8 | {
"a": null,
"b": 5
} | {
"b": 0,
"c": false,
"d": ""
} | {
"a": null,
"b": 0,
"c": false,
"d": ""
} |
| 9 | {
"items": [
"A",
"B"
]
} | {
"items": [
"X"
]
} | {
"items": [
"X"
]
} |
| 10 | {
"__proto__": {
"x": 1
},
"constructor": 2
} | {
"__proto__": {
"y": 3
}
} | {
"__proto__": {
"x": 1,
"y": 3
},
"constructor": 2
} |
Implication for the record
The simulation changes no resource and checks no permissions, API contract or concurrent update. Numeric and input limits protect browser interpretation; they do not define all JSON. Record the identifier and version of the resource actually updated separately.
Does an empty object always mean “change nothing”?
No. In Merge Patch, {} preserves an object target but replaces a non-object target with an empty object. Meaning depends on the target type at that level. Schema validation after merging is a separate check.
Primary documentation
Documentation consulted on .
Review before deciding
These questions complement the method. They help establish what is actually supported while retaining qualifications in the record.
Visible facts
Does every marked-up date, price, role, review or availability have a justified visible equivalent? Remove inferred or outdated properties rather than filling fields artificially.
View a worked decision
Fictional example: the state applies only to the criterion and scope described.
- Fictional observation
- JSON-LD shows a price of 100; the page shows 120 for the same offer and period.
- Declared state
- Observed discrepancy
- Decision and next check
- Restore one visible, supported value. Check variants and the data generating the markup.
Syntax and scope
Do type, properties and relationships pass the appropriate validator? Separate markup validity, search-feature rules and actually observed display.
View a worked decision
Fictional example: the state applies only to the criterion and scope described.
- Fictional observation
- The validator reports no error; no search-result observation is available.
- Declared state
- Not checked
- Decision and next check
- Retain syntax validation and leave actual display unverified. Do not promise a rich result.
Example or current offer
Does markup distinguish fictional data, old values and the visible offer? An educational example must not become a structured commercial promise.
Documentation consulted : Google Search Central · Structured data policies ·
View a worked decision
Fictional example: the state applies only to the criterion and scope described.
- Fictional observation
- An exercise declares fictional data; its markup describes a learning resource without a sale offer.
- Declared state
- Verified within this scope
- Decision and next check
- Content type is consistent within this scope. Recheck if it becomes a real offer.
TOOLS / REGISTERS
Information to record
Compare declared properties with visible content and source records. Valid JSON can still be false; technical validation does not replace editorial verification.
- Access date and time zone
- Exact URL
- Document type
- Claim to verify
- Observed result
- Acceptance criterion
- Decision / next action
- Review owner
- Next review
03 / FAQ
Frequently asked questions
Does JSON-LD guarantee a rich result?
No. The type must fit the page, applicable rules must be met and display remains at the search engine’s discretion.
Should every FAQ have markup?
No. A useful FAQ can remain plain HTML; do not invent questions to seek a feature.
What if titles differ by language?
Each version should describe its own visible content and use consistent URLs, names and language codes.
Can markup describe a service absent from the page?
No. It should represent the page without adding a claim readers cannot verify.
How to control the repeated values on multiple pages?
Identifiers and common properties. Compare their values with the site references, and then check the models that produce them to correct the cause and occurrences dependent.
04 / Official references
Official references
Describe a context
DOCUMENTED REFERENCE
JSON Schema: present, non-null and allowed are separate checks
This reference targets dialect 2020-12, which the validator must support. Fragments are pedagogical. Object rules also assume type: object; required alone does not make arbitrary values objects.
| Reference | Value or form | What it identifies |
|---|---|---|
| $schema | https://json-schema.org/draft/2020-12/schema | The URI declares dialect. Keep it and validator version because keyword support can differ. |
| properties | Property present | properties validates named properties when present; it does not require presence. |
| required: ["id"] | Presence ≠ non-null | required ["id"] demands the key; null still counts as present and is checked separately. |
| type: ["string", "null"] | String or JSON null | Union string/null explicitly permits either; required can demand the key while allowing null. |
| additionalProperties: false | Sibling declaration scope | additionalProperties uses sibling properties and patternProperties. It does not automatically discover declarations in another allOf subschema. |
| unevaluatedProperties: false | Evaluated properties across subschemas | unevaluatedProperties considers properties evaluated by applicable successful subschemas, including composition. Verify support; it is not interchangeable with additionalProperties. |
Implication for the record
Structural conformity does not prove registry existence or relational truth. Separate JSON syntax, schema errors and domain checks. Unknown dialects undermine a bare valid message.
Does properties id:string make id mandatory?
No. Declare an object, require presence separately, and decide whether null is allowed.
Primary documentation
- JSON Schema · Object validation guide
- JSON Schema 2020-12 · Validation vocabulary
- JSON Schema 2020-12 · Core and unevaluated properties
Documentation consulted on .
DEEPER READING / PRACTICE
Check consistency beyond syntax
A validator accepts the labelling when a name, date or URL no longer corresponds to the page. The control must bring the declared data closer to the information displayed.
Updated on .
Priority checks
Examine the objects, their identifiers and their relationships. Check the final URLs, dates, and properties repeated on several pages, and then raise the contradictions.
Interpretation pitfalls
A validation warning does not always have the same impact as a false data. Priority depends on the property, its use and the information it seeks to represent.
Working record to retain
The register distinguishes syntax errors, missing properties and substantive inconsistencies. Each correction includes a check of the markup and the visible page.