Your structured data is in microdata only

The check reports a page that carries schema.org structured data written as microdata (itemscope/itemtype/itemprop attributes in the HTML itself) while having not a single <script type="application/ld+json"> block. It is a check of FORMAT, not of content: it says which notation your data lives in, not whether the data is right.

The page's template shell does not count as microdata here. The types SiteNavigationElement, WPHeader, WPFooter, WPSideBar, WPAdBlock and WebPageElement (the list lives in config/microdata.json under boilerplate_types) describe navigation, header, footer and sidebar, not the content of the page. A site whose only microdata is the navigation shell therefore gets SCH-01 (“we couldn't find structured data”), not this finding. The other way round we would be silencing a warning for a site that states nothing machine-readable about its content at all.

The finding is informational, which means it carries zero weight in the score. It is not a defect you have to fix, and in that it differs from every other SCH-* check.

What the check does not do:

• It does not judge what the microdata says. Whether the type matches what the page is, whether the substantive properties are filled in, and whether it contradicts the visible text are all outside this check.
• It cannot spot an error in the microdata markup. A typo in itemprop is not a syntax error: such a property simply does not exist, nothing breaks, and there is nothing to report. There is no microdata counterpart to SCH-04 (invalid JSON).
• SCH-05 does not apply to it. The three errors in existing schema (a home page typed as an article, an author named after an account, a product without a name) are still looked for in JSON-LD only, because that is what we calibrated them against. For microdata that is a deliberate gap, not an oversight.
• It cannot see RDFa. The third valid format for structured data is one we do not read at all yet, so a page carrying its data only in RDFa gets SCH-01 rather than this finding. That is an admitted limit, not a claim that the format is invalid.
• It does not tell you to move to JSON-LD. It names the situation, and the section below sets out when converting is worth it and when it is not.

First the one fact that keeps this finding informational rather than a warning: Google's own documentation states that JSON-LD, microdata and RDFa are all equally fine for it, as long as the markup is valid and properly implemented per the feature's documentation. It recommends JSON-LD for practical reasons, in its own words as “the easiest solution for website owners to implement and maintain at scale (in other words, less prone to user errors)”. So: equal for reading, JSON-LD easier to maintain. Verified on that page on 19 September 2026.

That is why this is information, not a defect. Keeping a page with valid microdata under a warning would dock its score for a format the search engine itself calls equivalent. It would be an untruth from the opposite side to the one this finding repairs: until 19 September 2026 the audit did not read microdata at all and told sites that carry it that they had no structured data.

The rest holds exactly as for every other check in the schema group, and it is honest to repeat it here too, where you have nothing to fix:

• The documented value of structured data is for classic search, where Google uses it to recognise content type and qualify pages for rich results. That is tangible; it is just not what this product is about.
• With AI assistants the measured effect is inconsistent. A controlled experiment (Otterly, March 2026) found a rise for Google AI Overviews but a decline for ChatGPT, Gemini, Perplexity and Copilot. The larger measurement (Ahrefs, 1,885 pages against 4,000 matched controls) landed within noise.
• Information placed ONLY in the schema was used by none of the platforms tested. From which follows a sentence that holds regardless of format: schema does not replace content, it only describes it. What is not in the visible text of the page will not be taken from the markup, whether that markup is JSON-LD or microdata.

The evidence class is therefore “not demonstrated”, the same as for the rest of the group. Read this finding as a note about maintaining your site, not as an item for the fix queue.

The commonest correct response is none. If your microdata describes the content truthfully and you maintain it without trouble, there is nothing to fix; tick the finding off as read.

Consider converting to JSON-LD when one of these holds:

• You maintain the markup by hand in a template. Microdata is interleaved with the visible HTML, so it is easy to break or forget with every change to the layout. JSON-LD sits in one block separate from the text, where a mistake shows at a glance.
• The markup drifts apart between page types. When an article has it, a product does not, and a category page uses a different type, that is a sign it is being maintained one place at a time. A single generated block unifies it.
• You are planning a bulk change, such as adding an author or a publisher across the site. In JSON-LD that is one template; in microdata it is an edit in dozens of places in the HTML.

Conversely, do not convert when:

• A template or plugin generates the markup for you and you never edit it. Converting then buys you work and risk, not a more accurate description.
• The microdata is tied to the visible text the way it should be. Markup where itemprop="name" wraps the name in the text itself has a safeguard built in: it cannot be changed without changing the text. JSON-LD has no such property, and that is precisely why it drifts away from the content.
• You expect better visibility in AI answers from the conversion: that we do not promise and cannot evidence, and the equivalence of the two formats is exactly what Google itself states.

If you do convert, three rules so the tidy-up does not become a regression:

1. Convert without changing the content. First state one to one what the markup already says; only then consider adding anything.
2. Keep both formats side by side only temporarily, during the rollout. Two descriptions that start to diverge are worse than one imperfect description.
3. Validate the result after deployment (the Schema Markup Validator at validator.schema.org) and check that the types match what the microdata had.

And the closing line, the same as for the rest of the group: check that the same information is also in the visible text of the page. That matters more than which of the two formats holds it.