A completeness check assumes your type is right

By Matt Kerr·Published 18 September 2026

Every completeness check in every structured-data tool shares one assumption it never states: that the type you declared is the type you meant. When that assumption fails, the finding is still arithmetically correct — this type requires that property, you do not have it — and the work it asks for is worth nothing. Here are the two versions of that, both of which we shipped before we caught them.

Add an image to a product that is not a product

A property portal's homepage declared a Product node. It carried the company's name, its address on the web, its logo and links to its profiles elsewhere. It had no image, so the completeness check said so and advised adding one and re-testing.

The advice is correct for the type. The type is wrong.

logo is not a property of Product at all. There was no offer, no price and no review anywhere in the block. A product block with none of those was never going to produce a product rich result however many images it gained. Someone follows that advice, spends an afternoon wiring the logo into an image field, re-tests, and nothing has changed — because nothing could have.

The block was the company's own identity markup wearing the wrong type. The defect was one line above the one being reported.

Why a completeness finding cannot see this by itself

A completeness check works by lookup: what does this type require, what is present, print the difference. It is a good design, it is why these checks are reliable, and it means the type is an input rather than something being judged.

So the failure is structural, not a bug in the lookup. Every required property it names is a property you do not need, and each one looks like a small, reasonable task. That is what makes this expensive: nothing about the finding feels wrong while you are doing it.

Why the check now needs two tells before it says anything

Catching this required care, because the cost of being wrong runs the other way too. A genuine product missing only its image must not be told its type is wrong.

So the guard speaks only when both are true: an Organization-only property is present and every product signal is absent. One tell is not enough — a real product page trips neither, and that is the point. It is the same principle as being generous about applying a check and strict about what to recommend →, applied to the fields rather than to the type.

The same shape in a smaller font: one capital letter

A large public-sector site declares headLine in its Article blocks. The property is headline. JSON-LD keys are case-sensitive, so a search engine reads no headline at all and the rich result never appears.

The report said "missing headline". True — and it reads as false to anyone looking at a block that plainly contains the word. The typo survives review precisely because the eye reads headLine as headline. That site is built by people who know exactly what they are doing, which is the argument for catching it rather than against.

Told a property is missing, you go looking for something absent. Told you wrote it with a capital letter in the middle, you are done in a minute. Same finding, same severity, same remedy — a different sentence.

This is a near neighbour of a property that is present and empty, which is a different defect with a different fix: see when a field is there and still missing →. Present-but-empty means fill it in. Present-but-miscased means rename it.

What that check refuses to guess

It matches on case and never on spelling. headlin, head-line and title are all plausible things somebody meant by headline, and none of them can be asserted. A confident wrong guess about your markup is worse than a generic sentence, because you will act on the confident one.

Worth applying to any tool that offers to interpret your code: the useful ones tell you what they measured, and go quiet where they would have to guess.

Checking your own report

1. Read the type before you read the missing fields. Ask whether the thing on that page really is one of those. A homepage is almost never a product.
2. Search your block for the property without regard to case. If it is there in another capitalisation, that is your whole fix.
3. Ask whether the rich result is even reachable. A product result needs an offer, a price or reviews. If the block has none of those and you have no plans to add them, the missing image is not the reason you have no rich result.
4. Test the live URL, not the template. What the search engine's testing tool says about the page you actually serve is the only verdict that counts.

When the completeness finding is exactly right

Keep the severity where it belongs. A real product block on a real product page missing name or image is a rich result you were entitled to and did not get, on a page built to sell something. That is worth the afternoon. The point of this page is to tell that case apart from the one where the same sentence buys you nothing.

The fixes that make it worse

• Filling in the required fields of a type you should not have declared. The block now makes more claims, all of them about something the page is not.
• Adding a correctly typed block and leaving the wrong one in place. Two blocks describing the same thing as two different kinds of thing is worse than one wrong block.
• Declaring both spellings of a miscased property. One of them is ignored, you now maintain two copies of the value, and they will diverge.
• Trusting a validator's silence. Structured-data validators check shape. A block can be perfectly valid, perfectly complete and about the wrong kind of thing.

How to complete the markup and gain nothing

Put a value in every property the report names. The finding clears, because a completeness check counts properties and cannot ask whether anything you sell is for sale. Completeness is not eligibility. Whether you get a rich result is decided by whether the markup describes something the search engine shows results for — which is a question about the type, and about the page, and never about the length of the property list.

Where this sits in an audit

The registered check is schema.incomplete, which reads structured data for required properties. For what a type declaration claims about you, see a schema type is a claim about what you are →. For two findings from this check that counted the same pages twice, see when the numbers add up to more than your site →. For the rest of the lane, see how to fix structured data errors →.

Common questions

Why would adding the missing properties not fix my structured data?

Because a completeness check assumes the type you declared is correct. If the block is really your organisation's identity markup declared as a product, every property it asks for belongs to something the page is not.

How do I know the type on a block is wrong?

Look for properties that do not belong to it, and for the signals the type needs that are entirely absent. A product block carrying a logo, with no offer, price or review anywhere in it, is your organisation wearing the wrong label.

An audit says a property is missing but I can see it. Why?

Check its capitalisation first. JSON-LD keys are case-sensitive, so headLine and headline are different properties and only one of them is read. If the spelling and case are both right, the value is probably empty, which counts as missing.

Should I add a second block with the correct type?

Not while the wrong one is still there. Two blocks describing the same thing as two different kinds of thing is a worse claim than one wrong block. Correct the type in place.

Does complete markup mean I will get a rich result?

No. Completeness is not eligibility. Whether a result appears depends on what the markup describes and whether the search engine shows results for that kind of thing, and a validator checks neither.