Need deeper analysis? See the related editorial article for background and trade-offs. Use this guide for the practical steps.
Good validation explains the problem, the likely impact and the safest next action. Learn how to repair JSON-LD without silently inventing facts or weakening Google structured-data quality.
Use this checklist alongside the local checker. Every step is free and can be repeated without an account or daily quota. Only approve corrections that reflect the real page. Where Google eligibility matters, follow the linked official documentation rather than treating a local result as certification.
Step 1: Read the first parsing error before anything else
Fix the earliest syntax problem, rerun the checker, and only then decide whether remaining messages represent separate schema issues.
Look for: One unclosed quote can cause several downstream errors. When JSON cannot be parsed, later rules cannot reliably inspect the intended schema entities.
Example: A trailing comma may invalidate an entire Product example even though all the property names are otherwise correct.
Keep in mind: A syntax repair does not prove that the facts or feature requirements are correct.
Step 2: Handle smart quotes carefully
Preview any replacement, especially when pasted descriptions legitimately contain quotation marks inside string values.
Look for: Text copied from editors can contain curly quotation marks that look normal to people but are not recognized as JSON string delimiters.
Example: A safe correction changes only JSON punctuation and preserves the actual product name, description and numeric values.
Keep in mind: Global replacements can alter content unexpectedly, so reparse the repaired output.
Step 3: Remove trailing commas only where safe
Use a scanner that respects quoted strings, so text inside a product description cannot be accidentally rewritten.
Look for: Strict JSON disallows commas immediately before a closing brace or bracket, although some JavaScript object notations tolerate them.
Example: Repair an object like {"name":"Item",} by removing the final comma and verifying that its object structure is preserved.
Keep in mind: Do not run blind regular expressions across arbitrary complex source without a validation pass.
Step 4: Distinguish missing facts from fixable syntax
Offer a sample structure and explain the required field, but ask the user to provide true values from the page or product database.
Look for: A missing factual price, brand or rating cannot be produced honestly from nothing. Automatic filling may create misleading markup.
Example: A checker can point out that offers.price is needed for a target Google feature; it should never invent a discounted price.
Keep in mind: Fake or mismatched data can violate Google structured-data policies even if it parses.
Step 5: Treat optional guidance differently from errors
Categorize critical syntax failures, documented Google required properties, recommended enhancements and information notices separately.
Look for: Some properties make entities more descriptive but are not always Google prerequisites. Calling every optional field an error wastes time.
Example: Brand and SKU often improve product data; whether they are mandatory depends on the specific feature and guidance.
Keep in mind: Do not present a generic best-practice preference as an official Google rule.
Step 6: Repair enumerations and dates with review
Normalize obvious string forms only when the original meaning is unambiguous, then show the exact before/after comparison.
Look for: Schema.org enumeration values often use full URLs, and dates are usually clearer in a standardized ISO notation.
Example: Changing http://schema.org/InStock to https://schema.org/InStock is different from changing an unknown delivery date.
Keep in mind: Never interpret ambiguous regional dates without asking what they mean.
Final review checklist
Recheck syntax and warnings after editing, compare the corrected file against the original, export a report, and validate applicable features using official tools. If a result is unclear, keep the original data instead of guessing business facts.
Official sources: Google documentation and additional reference. For more detail, read the complete article.
Frequently asked questions
Answers are educational. FAQ markup does not guarantee Google FAQ rich results.
Should I apply every suggested correction?
No. Review changes, especially factual fields and inferred values, before publishing.
Can safe fixes invent product ratings?
No. Ratings and reviews must come from genuine source information.
