· 4 min read
How to Audit Schema Coverage by Template
Heshan Fernando
Co-founder & COO
Someone checks a product page, finds Product markup, and reports that the site has structured data. Nine other page types have none, and nobody has looked at them because there was no list.
Structured data coverage is a template question. Auditing it page by page produces a sample; auditing it by template produces an answer.
Templates, not pages
Structured data is generated by the template, so every page using that template has the same markup or the same gap.
That means the unit of work is the template. Fix one and thousands of pages are fixed; check one and you know about all of them.
Auditing page by page is both slower and misleading — checking three product pages tells you about the product template three times, and nothing about the category, article, author or location templates.
The audit is therefore: list every template, name a representative URL for each, and check what type it carries.
| Template | Expected type | Present? |
|---|---|---|
| Product detail | Product, Offer | Product only — Offer missing |
| Article | Article | None |
| FAQ page | FAQPage | None |
| Category listing | ItemList (optional) | None — acceptable |
| Home | Organization, WebSite | Present |
More markup is not better
The instinct after an audit is to add structured data everywhere. That is the wrong conclusion, and in one case actively harmful.
Where a rich result exists for the content, markup is worth adding — products, recipes, events, articles, FAQs, local businesses, job postings.
Where no rich result exists, markup is valid and does nothing. Adding Thing markup to a generic page is effort with no outcome.
Where the markup does not describe the page, it is a policy violation. FAQ markup on a page with no visible questions, Product markup on a category listing, review markup with no reviews on the page — these can trigger a manual action against the whole site.
So the audit’s output is not “add markup to every template”. It is “add the right type to templates where a rich result is possible, and leave the rest”.
The properties gap is as common as the type gap
A template can have the right type and still be ineligible.
Product markup without an Offer has no price, so the rich result cannot show one. Article markup without a headline or a date is missing what the result would display. Event markup without a start date cannot be shown at all.
Checking presence of the type is the first pass. Checking the required properties within it is the second, and it is where most of the actual fixes are — the type is usually there and incomplete rather than absent.
Validate after every template change
Structured data breaks silently, and template changes are when it happens.
A redesign that moves a price into a component, a CMS upgrade that changes how fields render, or a caching layer that strips inline scripts can all remove markup without any visible change to the page.
Nothing reports it. The page looks correct, the rich result quietly stops appearing, and the connection between the two is discovered months later if at all.
Adding a structured data check to the deployment process — validating one representative URL per template — catches it at the point the change was made. Search console reports it eventually, and eventually is a long time to lose a rich result.
Common mistakes to avoid
- Auditing pages rather than templates.
- Concluding that every template needs markup.
- Adding markup that describes content not visible on the page.
- Checking the type is present and not checking its required properties.
- Fixing markup on individual pages rather than in the template, so it regenerates without it.
How to do it with Schema Type Coverage Checker
The Schema Type Coverage Checker audits by template.
- List each page template with a representative URL.
- Compare against the types that page type could support.
- Check required properties on the types that are present.
- Fix in the template, and only where a rich result is actually available.
Google’s structured data documentation lists the supported types and their requirements. Other SEO tools are in the tools directory.
Frequently asked questions
Which page types need structured data?
Those where a corresponding rich result exists — products, recipes, events, articles, FAQs, local business pages. Adding markup where no rich result is available produces valid markup and no benefit.
Should I mark up every page?
No. Markup must describe what is genuinely on the page. Adding Product markup to a category listing or FAQ markup to a page with no questions is a policy violation rather than thorough coverage.
Why audit by template rather than page?
Because the template generates the markup. One gap affects every page using it, and one fix resolves them all.
Final thought
List the templates first. An audit that checks pages is sampling; an audit that checks templates is complete.