Can an engine tell who you are?
Enter a page. We read its structured data and report what it really says, including the references that point at entities the page never defines.
We do not store the pages people check.
Anyone an assistant describes incorrectly.
Structured data is how you tell an engine what your business is, in terms it does not have to guess at. When it is wrong, the failure is not an error message. It is an assistant confidently describing someone else.
That is not hypothetical for us. Our own company shares a near-identical name with a credit-repair firm, and the pages where our markup was weakest are exactly the pages where answers went to the other company.
Six things, and the first one is the point.
Dangling @id references
The check nobody else runs. A page that names its publisher, parent site or author by @id and never defines them tells an engine three things exist and then never says what they are.
JSON that does not parse
One trailing comma and an engine discards the whole block, not the broken part. A page can look fully marked up and be publishing nothing.
Missing required fields
A LocalBusiness with no address or telephone is the common one. Those are the fields an engine uses to identify and contact you.
Placeholder values
“Your Business Name” still in production. A placeholder asserts something false; an empty field would only say nothing.
FAQ markup with no answers
A Question without an acceptedAnswer is ignored entirely. The markup is there, the result is not.
Duplicate and untyped nodes
Two nodes sharing one @id means an engine picks one and you do not control which. A node with no @type cannot be used at all.
Naming something you never define.
Structured data lets a page refer to an entity by id rather than repeating it. A page can say “published by #org” and define #org once. It is the right way to write it.
A dangling reference is one where #org is never defined at all. The page tells an engine it has a publisher, a parent site and an author. And then never says what any of them are. It is valid JSON. It is valid schema.org. Every validator we ran passed it.
We found it on our own site. One page referenced an organisation, a website and a founder by id and defined none of the three, so that page resolved to no business at all. The repair, with the before and after, is on our methodology page.
That is the whole reason this tool exists, and it is the reason it checks something a rich-results test has no cause to look at.
The honest limits.
Whether you get a rich result
That is Google's Rich Results Test, and it is the right tool for that question. This one asks whether an engine can resolve who you are, which is not the same question and is the one that matters for being named.
Whether the facts are true
We check that your markup says something coherent. We cannot check that the phone number is yours or that the address is where you work. And an engine that finds those contradicted elsewhere will trust all of it less.
Pages that build their markup in the browser
If the JSON-LD is injected by JavaScript after load, we will not see it. Nor will some crawlers, which is itself worth knowing.
Whether an engine agrees with you
Markup is a claim. Whether it is believed depends on whether the rest of the internet says the same thing, which is the work, not the check.
Five moments worth the ten seconds.
After any template change
Structured data lives in the template. One edit changes it on every page at once, and nothing announces that.
When an engine names the wrong business
The commonest cause we see is a page that resolves to no organisation at all, so the engine picks whichever similarly-named company it can resolve.
Before paying for schema work
Run it first, keep the output, run it after. It is the cheapest before-and-after in this field.
After a site migration
Absolute @id values that still carry the old domain are a classic, and they parse perfectly.
On the competitor who keeps getting cited
Their markup is public. It is often the shortest explanation of why an assistant can describe them and not you.
Two different questions.
Google's Rich Results Test asks: will this draw a rich result? It is the right tool for that, it is free, and we would use it for that question.
This one asks: can an engine resolve who this business is? A dangling reference does not stop a rich result, so by the first standard it is not a defect at all. It does stop an engine resolving you as an entity, which is what decides whether an assistant names you when a customer asks.
Run both. They disagree more often than you would expect, and the disagreement is the interesting part.
Legible is not the same as credible.
Correct markup makes your business legible to an engine. Whether the engine believes it depends on whether your listings, your profile and other people’s pages say the same thing. And making those agree is the work.
We publish how we test it, including the answers where we are not named, on our methodology page, and our prices on the pricing page.
What owners ask about this.
What is a dangling @id reference?
Structured data lets a page refer to an entity by id instead of repeating it, 'this page is published by #org'. A dangling reference is one where #org is never defined anywhere on the page. The page makes a claim about an entity and then never says what the entity is, so an engine has nothing to resolve. It is valid JSON and valid schema.org, which is exactly why validators pass it.
Why does no other validator check for this?
Because most are built to answer 'will this produce a rich result in search?' A dangling reference does not stop a rich result, so by that standard it is not a defect. It does stop an engine resolving your business as an entity, which is the thing that decides whether you get named in an answer.
Did you find this on your own site?
Yes, and that is why the tool exists. One of our pages referenced an organisation, a parent website and an author by id and defined none of them. It had been live for some time and every validator we ran passed it. We publish the repair, with the before and after, on our methodology page.
Is JSON-LD better than microdata?
Engines read both, so neither is wrong. JSON-LD sits in one block in the head rather than being threaded through your markup, which makes it far easier to keep correct. And every current guide assumes it. If you have microdata and it is accurate, there is no urgency.
My markup is valid but I am still not named by AI. Why?
Valid markup is a claim an engine can read. Whether it is believed depends on whether the rest of the internet agrees. Your listings, your directory entries, your reviews, other people's pages. Structured data makes you legible, not credible.
Does this check every page on my site?
No, one page at a time. Structured data usually lives in a template, so checking your homepage, one service page and one article covers most sites. If those three agree, the rest almost certainly do too.
Do you store the pages you read?
No. The check runs, the result goes to your browser, and nothing is kept. There is no sign-up and no email field on this page.
What should a local business publish at minimum?
A LocalBusiness or a specific subtype, with name, address, telephone and url, every one of them matching what your Google Business Profile and your other listings say exactly. Consistency across sources does more than any additional markup type.
Related: Robots.txt checker · Sitemap validator · Which AI crawlers can see my site · How we test AI answers
By Steven Allbright, founder, Ultimate Elite Solutions · Last updated: 2026-10-08
The next checks worth running.
Each one takes seconds and needs no sign-up. They fail in order, so start at the top.
Canonical tag checker · llms.txt generator · Title tag checker · How we run a real test · Get the free report