Need deeper analysis? See the related editorial article for background and trade-offs. Use this guide for the practical steps.
A repair is only trustworthy when you can inspect what changed. This article shows how to use side-by-side comparison to distinguish harmless normalization from changes to meaningful product or business facts.
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: Save a baseline before editing
Keep the source file with its meaningful name, then export the repaired variant as a distinct corrected file rather than overwriting it.
Look for: Without the original text, a corrected file is hard to audit and hard to roll back. Small syntax changes may disguise larger content changes.
Example: For product.jsonld, produce product.corrected.jsonld and compare both copies before publishing anything.
Keep in mind: Avoid automatic overwrite of site files without a backup.
Step 2: Look beyond the green status
Compare the changed lines and inspect affected entities, especially identifiers, prices, dates, author details and opening hours.
Look for: A checker can report zero parse errors even if the repair altered a business name, price or URL. Syntax alone does not protect meaning.
Example: If the only change is a trailing comma removal, the review is simple; if a value changed, check the underlying source.
Keep in mind: Do not merge a repair based only on a headline score.
Step 3: Compare HTML without losing its page structure
Focus the diff on the application/ld+json blocks and make sure unrelated HTML remains byte-for-byte equivalent where practical.
Look for: Structured data is usually embedded in pages that also contain content, scripts, styles and navigation. A fix tool should not reformat everything indiscriminately.
Example: A large visual diff caused solely by whitespace makes genuine value changes harder to find.
Keep in mind: HTML normalization by a parser may reorder attributes; that is not always desirable.
Step 4: Spot the first changed line
Open the before and after panels side by side and move to the earliest changed region, then read a few surrounding lines.
Look for: Long markup documents are difficult to scan. A simple line-range summary helps reviewers find where a repair begins.
Example: An incorrect priceCurrency field near the bottom can be easy to miss without a focused comparison.
Keep in mind: The first-changed-line metric does not replace a full semantic review.
Step 5: Keep @id identifiers stable
Check that every renamed @id still matches references in related objects and across documents when those relationships matter.
Look for: An entity graph uses @id values to connect objects. Changing an identifier may break relationships without causing a syntax error.
Example: A WebSite node and an Organization node can refer to the same publisher; mismatched identifiers can produce disconnected metadata.
Keep in mind: Do not rewrite IDs merely because they look unusual.
Step 6: Use comparison when updating Google rules
Keep a fixture representing real schema and rerun both versions so you can see exactly which rules were modified.
Look for: A support data revision can legitimately alter which fields get flagged. The markup may stay identical while report output changes.
Example: A retired status should appear as an informational feature note, not as an unexpected parsing failure.
Keep in mind: Do not conceal changes in validation policy when shipping new versions.
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.
Why keep the original JSON-LD?
A before/after record helps explain what changed and supports review or rollback.
Does a cleaner after version guarantee eligibility?
No. It must still match the real page and applicable feature requirements.
