The Schema You Did Not Know Was Missing
01Twelve pages had it
The structured data audit on one of my sites came back looking healthy. Twelve key pages carried full markup: organisation, services, breadcrumbs, frequently asked questions, the lot. By the usual measure, the share of pages with valid markup, it was well above average. Then I read the list instead of the percentage, and the one page with nothing on it was the pricing page. The only page on the site where money changes hands was the only page a machine could not read a price from.
How an average hides the gap
Coverage figures reward the pages that are easy to mark up, and those are usually the pages that matter least. Service pages share a template, so markup added once appears everywhere. Pricing pages, checkout pages and data pages tend to be built by hand, later, by someone in a hurry, and they are exactly the pages that never get the template. Schema coverage is not a percentage. It is a list of the pages that matter.
02Complete where nobody reads
Markup on the wrong pages
The same site had question and answer markup on 19 of its 19 service pages and on only 4 of its 17 articles. When I checked which pages one assistant actually fetched, 68% of its reads in the audit window went to just two addresses, an article and the homepage. The markup was complete on the pages machines rarely read and missing on the pages they read most. Nobody chose that. It is simply what happens when markup follows templates instead of traffic.
Markup that can disagree with the page
The fix was a shared component that renders the visible questions and the structured version from one list, so they cannot drift. Four older articles were left out of it, with their markup written by hand inside the page. Those four still work today. The problem is tomorrow: the first time someone edits a visible answer and forgets the hidden copy, the page will tell people one thing and machines another, which is the inconsistency problem in its purest form. Two copies of the same answer are one edit away from being two different answers.
Markup of the wrong type
The most expensive version I found was on a different product, where 37 pricing pages were marked up as a physical product. The validator did what validators do and graded them as shop listings, then failed every one for having no product photo, no shipping details and no returns policy, for software that is never posted to anyone. The tempting fix was to add a zero day shipping policy and a returns address. That would have silenced the warnings by writing markup that lies. The real fix was the type: software with offers attached, which asks for none of those fields. Markup that lies to pass a validator teaches every machine reading it the wrong thing about what you sell.
Audit the pages that matter by name. The average will always look fine.
03Write the list before you run the tool
The method that would have caught all four problems is almost embarrassingly simple. Before running any validator, write down the ten pages that matter most: the ones that earn money, the ones machines fetch most often, the ones that state your prices and facts. Then check each by name for three things. Does it carry markup, is the markup the right type for what the page is, and is it generated from the same source as the visible text. A validator gives you a percentage. A list of the pages that matter gives you the answer.
The order of the fixes matters as much as the list. Wrong types come first, because they are actively teaching machines something false. Missing markup on the pages that earn money or state your facts comes second. Drift risks come third, by moving every hand written block into the shared source. Template pages in the long tail come last, if at all, because that is where the percentage goes up and nothing else changes.
Keep the claim in proportion
Schema introduces you; it does not make you chosen, as the clean audit showed at length. A priced offer in markup will not win a citation for a site nobody trusts. What it does is remove a reason to guess. When an assistant is asked what something costs and your pricing page states the number in the text and in the markup, in agreement, you have given it the least ambiguous answer available.
Tomorrow: a character you cannot see, pasted from a terminal, that took down two providers at once.
>Should a pricing page have structured data?+
>What schema type should a SaaS pricing page use?+
>How do I audit structured data coverage properly?+
Abd Shanti. "The Schema You Did Not Know Was Missing" CITED, Entry 060, Sep 22 2026. unknown.ps/blog/the-schema-you-did-not-know/
