Your website can contain structured data that looks convincing in an editor but says something different from the page a visitor reads. It might name the wrong author, use an old image, or label an ordinary service page as a product with invented reviews.
Structured data is a machine-readable description of a page. JSON-LD is one way to write it, and schema.org supplies names such as BlogPosting, Person and Product for the things being described.
Checking it means asking three different questions: can the data be read, does it describe the page accurately, and does it meet the rules for a supported Google feature? No single green badge answers all three.
Decide what this page actually is
Start with the visible page, not a list of schema types you hope will attract more clicks.
A blog article may fit BlogPosting. A genuine product detail page may fit Product. A category listing, service page and article are different things; do not give them identical markup simply because your platform has a convenient switch.
Write down the facts a visitor can verify: the article title, author, publication date, image and preferred address, for example. You will compare the markup against those facts.
Structured data should not introduce claims the page never makes. Google's structured-data guidelines explain why misleading or hidden information can invalidate otherwise readable markup.
Run the focused check on a live URL
Open SEO Dispatcher's structured data checker and paste the public page address. You do not need to sign in or connect Search Console or Analytics to start.
The checker reads JSON-LD in the HTML the server sends. It checks JSON syntax, the declared schema context and types, and common properties for recognized types. It inspects up to 30 JSON-LD blocks and discloses that limit when more are present.
It does not render JavaScript or validate every schema.org property. It also does not check Microdata or RDFa, which are other ways to embed structured data. If another tool sees markup that this check cannot find, compare the formats and rendered page before concluding it is missing.
Open a checklist row to see the block and property involved. “Present” with “Needs review” may mean a property exists but its value is empty or unusable. “Missing” means the checked property was not detected; it does not mean every Google feature requires it.
Fix unreadable JSON before adding more properties
JSON syntax errors prevent a block from being reliably parsed. Common causes include a missing quote, a missing comma, or a comma after the last item.
For a simple example, this is not valid JSON because the final property has a trailing comma:
{
"@type": "BlogPosting",
"headline": "How to Choose a Wedding Photographer",
}
The readable version is:
{
"@context": "https://schema.org",
"@type": "BlogPosting",
"headline": "How to Choose a Wedding Photographer"
}
That small example demonstrates syntax and a declared type. It is not a complete article implementation or evidence of Google eligibility.
If a website plugin or template generates the block, correct that source. Do not paste another block over the broken one and assume the extra markup will cancel it out. If you cannot edit the template, send the maintainer the page URL, block number and reported error.
Separate useful properties from eligibility requirements
A recommendation to add an author is not the same as a syntax error. Nor should a checker call every recommended property a universal requirement.
For articles, Google currently describes properties such as author, headline, image and dates as recommended, rather than providing a single mandatory-property checklist. Other supported types have their own requirements. Use Google's Article documentation for an article, not a recipe or product checklist.
Review actual values before adding fields:
| Article fact | What to compare |
|---|---|
| Headline | Does it identify this article rather than another post or the site homepage? |
| Author | Is the named person or organization really responsible for the piece? Does the profile link identify them? |
| Publication and modification dates | Do they reflect publication and a real revision, not a fresh date on every deployment? |
| Image | Does it belong to the article, and can its public address be fetched? |
| Page URL | Does it identify the intended published article? |
This is a factual review. A validator cannot establish that someone really wrote an article or that a review came from a real customer. Do not invent those facts to fill a warning.
Check whether multiple blocks agree
Several JSON-LD blocks are not automatically a mistake. A page might describe an article, its author and breadcrumb navigation separately, or connect them in one graph.
What deserves investigation is disagreement: two article blocks with different authors, a plugin carrying last month's headline, or product markup referring to an unrelated page.
Inspect the observed values and, if necessary, the rendered source. Check your theme and SEO plugin settings before adding a second generator. A site-wide setting may be responsible for the same wrong value on every article.
SEO Dispatcher's free report helps locate blocks and common problems. It does not fully validate relationships across a graph or decide which plugin is responsible. Those questions may need your website maintainer and a wider validator.
Use the next test for the next question
After correcting the source and publishing the change, choose a check that matches your question:
- Can the JSON-LD be read, and are common values usable? Review the focused SEO Dispatcher report and the live output.
- Does the vocabulary and property usage make sense? Use the Schema.org validator for a broader vocabulary check. It does not decide Google feature eligibility.
- Is a Google-supported type technically eligible? Use Google's Rich Results Test and the documentation for that type.
- What can Google access on the deployed page? The verified website owner can use URL Inspection, including its live test and rendered-page information where available.
A type not supported by Google's rich-result features can still be legitimate schema.org markup. And passing a supported type's test does not guarantee that Google will show a special result.
Do not add FAQ markup to a normal business blog expecting extra search-result space or guaranteed AI citations. Questions and answers can help the reader without that promise. Google's FAQ rich-result changes explain the restricted treatment; markup is not a distribution shortcut.
Keep publishing and validation separate
In SEO Dispatcher's paid workspace, an approved article can become a Markdown or MDX file in your GitHub repository. Your website's renderer still determines what structured data appears at its public URL.
Check that final page. Correct frontmatter in a draft is not proof that a template published the same author, image or date. Keep one clear source of truth for article facts rather than manually maintaining conflicting copies.
The free tools share three accepted runs total per user and domain, with no reset. Signing in opens fuller evidence from the same saved report; it does not add runs. Accepted failed checks count, and saved reports can be reopened for 24 hours without another attempt. Anonymous users on a shared network may share the visitor allowance. Plan a follow-up after the change is actually deployed.
You have finished when the data is readable, the claims match the page, and any relevant feature requirements have been checked with the right tool. “More schema” is not the goal. A more accurate description is.