The markup on your page may not be about you

By Matt Kerr·Published 18 September 2026

An audit reports that your address, telephone number, opening hours and price range are missing from your structured data — and that two of them are present in the markup but carry no value. You check the page. None of those facts was ever about you. They were about a takeaway in another city that your page happens to list.

Why a reader of your markup loses track of whose it is

Structured data is nested, and a tool that only looks at the top level finds almost nothing — most real markup is a single graph with everything inside it. So a JSON-LD reader descends through every value at any depth. That is the right decision and it is why these tools work at all.

But a walk like that has no idea whose business it just found. It sees a node with a type it recognises and treats it as yours.

There is exactly one property that settles the question, and it is in the vocabulary already: itemListElement. Its entries are, by schema.org's own definition, the things a page lists — not the thing the page is. Anything reached through it belongs to somebody else.

What that produced

On a national food-delivery marketplace, the only structured data on the page was a list of restaurant nodes — other people's takeaways, each carrying an empty address string and an empty price range. The check judged the first node it reached and reported that the marketplace's address, telephone, opening hours, geolocation and price range were missing, and that two fields were present but blank.

Every one of those statements was about a shop the marketplace does not own, in a town it does not operate from. There was nothing for the reader to fix, and no way to tell that from the finding.

True, and still misleading

The same site produced a second sentence worth studying separately, because it was not wrong.

Deciding whether the local-business checks apply at all, the tool said it had found restaurant markup on this URL. That is literally correct — the markup is there, and it is restaurant markup. It reads to the owner as "this tool thinks we are a restaurant", which is not what was meant and not true.

The lane genuinely does apply: a site that lists local businesses has local-schema work to do. But the reason given for applying it has to be the reason that is actually true. A correct sentence that invites a wrong inference costs the same as a wrong one.

The repair kept the finding and changed its subject

The obvious fix — ignore anything inside a list — would have been wrong, and this is the part worth copying.

Thin listing markup is a real finding. Complete entries are what make a listing page eligible for rich results, so a list of businesses with empty addresses is a genuine missed opportunity. It is simply not a statement about the publisher. So the finding stayed and its subject changed: it now describes the businesses the page lists, rather than the page's own premises.

And dropping it outright would have silenced a real case — a chain that publishes its own branches inside a list on its store locator.

The sentence about evidence

Six chain store locators were checked for exactly that shape, and none of them nests business-type nodes inside a list. That is a useful result and it is not a licence: "none of six" is a reason to keep a finding cheap, not a reason to delete it.

It is worth saying because the opposite reasoning is everywhere in tooling — a small sample that finds nothing gets treated as proof that nothing exists, and a rule is removed on the strength of not having seen the case yet.

Reading this on your own report

• Ask whose data is missing. If the finding names fields you would never publish about yourself — a price range for a company that is not a venue, opening hours for a marketplace — the node is probably not yours.
• Look for a list in your markup. Search the page source for itemListElement. Anything under it describes something you are listing.
• Check whether the empty strings are yours. A node with empty values is usually a template that ran with no data for one entry, which is a different job from missing markup.
• Ask whether the page is one business or many. Directories, locators, marketplaces and category pages are the shapes where this goes wrong.

When it matters, and to whom

Two readers should act on a listing-markup finding, and they should do different things:

• A publisher of a directory or marketplace. Complete entries are the point — empty address and price fields on listed businesses cost the listing page its eligibility, and the data usually exists in the database behind the page.
• A chain publishing its own branches in a list. Here the nodes really are yours, and incomplete ones are a genuine local-SEO defect on premises you operate.

Everyone else can read it as information about their listings rather than a defect in their own entity.

The fixes that make it worse

• Adding your own address to a node that describes someone else. You have now published a false claim about a third party's premises in machine-readable form.
• Deleting the list markup to clear the finding. The list is the thing that makes the page eligible for anything. Complete it instead.
• Adding a local-business node for your company to a page that is not premises. A marketplace is not a shopfront, and claiming to be one is the misrepresentation that structured data is policed for.

How to clear this without improving anything

Remove itemListElement and leave the entries loose in the graph. The nodes are still there, the tool can no longer tell they are listings, and it will go back to treating them as yours — the finding changes shape rather than disappearing, and you have thrown away the one signal that made the page legible.

The property that got you a confusing finding is the property that makes the page readable at all.

Where this sits in an audit

The registered checks are local.schema, which covers local-business structured data, and local.applicable, which decides whether the local lane applies to your site at all. For the other ways structured data misleads, see how to fix structured data errors →; for the related case of a node that is a pointer rather than a definition, see an @id is a pointer, not a definition →.

Common questions

Why does my audit say my address is missing when I have no premises?

Because it probably read a node describing a business your page lists. Anything reached through itemListElement is something you are listing rather than something you are.

What is itemListElement?

The schema.org property whose entries are the things a page lists. It is the one signal that separates markup about you from markup about everybody else on the page.

Should I remove structured data that describes other businesses?

No. Complete entries are what make a listing page eligible for rich results. Fill the empty fields rather than deleting the list.

My store locator lists my own branches. Does this apply to me?

The nodes really are yours, so incomplete ones are a genuine defect on premises you operate. That case is exactly why listing markup is still reported rather than ignored.

Is it safe to add my company as a local business on a listings page?

Not unless the page describes premises the public visits. Claiming to be a shopfront you do not have is the kind of misrepresentation structured data is policed for.