Which test answers your question?

Use Google’s Rich Results Test to review structured data against Google’s supported rich-result features. Use Schema Markup Validator to inspect Schema.org markup more generally. Run both when a page needs broad vocabulary checks and Google-specific feature checks; then inspect the published URL so that the result relates to the version readers can actually visit.

A valid JSON document, a recognized Schema.org type and eligibility for a Google feature are different findings. A fourth question remains after all three: will Google choose to show that feature for a particular search? A validation tool cannot promise that outcome.

Google’s structured-data testing guidance makes the same distinction between its rich-result checks and generic Schema.org validation. Neither tool is a universal SEO score. A page can communicate its content accurately without qualifying for every enhanced search appearance.

Compare what the tools inspect

Schema.org’s validator documentation describes extraction of JSON-LD, RDFa and Microdata, a summary of the resulting graph and detection of syntax mistakes. It accepts a URL or supplied markup. Its focus is Schema.org, rather than every possible external JSON-LD context or Google’s separate feature rules.

The Rich Results Test documentation explains URL and code testing, with smartphone or desktop user-agent selection. The report identifies detected rich-result types and their issues. A code test is useful before deployment, but it cannot establish that your live server serves that same code to a crawler.

Read a finding at the entity level. If a page contains a business, a product and a breadcrumb trail, record which entity produced each message. Fixing an issue in one object does not prove that another object’s content is accurate. Check names, URLs, dates, prices and relationships against the visible page rather than merely clearing warnings.

The FAQ example that catches outdated advice

FAQPage is a useful example because the Schema.org vocabulary and a Google search feature do not have the same lifecycle. Google’s May 2026 documentation changelog says FAQ rich results stopped appearing from 7 May 2026. The June update records removal of the feature’s documentation. Older tutorials describing how to qualify for Google’s FAQ rich result are therefore outdated.

The FAQPage type still exists at Schema.org. Its existence does not restore Google’s retired feature. For an invented camping shop, suppose the visible page contains this question and answer:

The matching illustrative JSON-LD could describe that content as follows. These are invented product details for an example, not care instructions for a real mug.

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "Can I wash the trail mug in a dishwasher?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "The demonstration mug should be washed by hand."
      }
    }
  ]
}

There are three useful review questions here. Does the JSON parse? Do the objects describe the visible question and answer using the intended vocabulary? Is there a currently supported Google search feature for this type? Answering the first two does not make the third true. This guide displays the example as code; it does not add the invented FAQ as live structured data.

For a real site’s historical FAQ markup, decide whether it still describes useful visible content and has a reason to be maintained. Do not convert it into an unrelated type just to make another test recognize it. Choose a type because it accurately represents the page and meets that type’s requirements.

A repeatable code-to-live review

1. Save the inputs. Record the page URL, code version, date and intended entity. Keep a copy before editing so that a later report can be compared with a known baseline.
2. Check syntax locally. Correct malformed JSON and inspect the graph using the JSON-LD review workflow. A parser result is a syntax finding, not a Google approval.
3. Check vocabulary and relationships. Run Schema Markup Validator with the supplied markup. Review each entity rather than counting the number of recognized items as a quality score.
4. Check the relevant Google feature. Read the current documentation for the feature you intend to support, then run Rich Results Test. Record the user agent and exact errors, including the entity they apply to.
5. Inspect the published URL. After deployment, test the URL and compare extracted values with the saved code. A successful staging snippet does not prove production has the same theme, app settings or cached output.
6. Review index information separately. In a verified property, use URL Inspection to distinguish the indexed version from a live test. Keep both dates in the review log.

For a shop with theme markup plus an SEO app, start by identifying which system owns each entity. If both output a product with conflicting availability, correcting just one source leaves the published page inconsistent. Make the smallest repair in the authoritative system, then repeat the live-URL check.

Turn a report into a specific repair

Google’s structured-data policies require markup to represent the page’s content and explain that a successful test does not guarantee display. Do not add invented reviews, prices or dates to remove a warning. Some policy and content-quality questions require human review even when the syntax is valid.

Use a compact handover note: “Entity; issue; source changed; code test; live test; remaining unknown.” That makes the review actionable for a developer or editor. For a product-page audit, the Shopify tools checklist places structured-data testing alongside content, discovery and redirect checks.