📘 This use case demonstrates reporting field-level structured data coverage across every page in a template, and confirming a sample against Google's indexed version.

Best for: Technical SEO and content operations teams · Uses: crawl data, structured data extraction, and URL Inspection, via your AI assistant

Overview

Structured data usually breaks on part of a template rather than all of it: one subset of product pages loses a price or a rating while the rest stay valid. Botify MCP can report field-level coverage across every page in a template from your own crawl, so you can see which field is missing, on how many pages, and whether those pages have anything in common.

Prerequisites

Botify MCP connected to your AI assistant, such as Claude or ChatGPT. See Connecting to the Botify MCP for setup steps.
A completed crawl covering the template you want to audit.
Google Search Console connected to the project, if you also want to confirm a page against Google's indexed version.

Description of the problem

A missing structured data field is not a crawl error, so nothing flags it. The page returns 200, the JSON-LD block is present, and one property inside it is absent. Checking by hand means opening pages one at a time, which does not scale to a template with six figures of URLs, and validating a handful of samples says nothing about how many pages are affected or where they sit.

Application

Ask for field-level coverage across the template, naming the URL pattern and the fields:
```
For acme-outdoors.com, check the Product structured data on every page matching /p/*. Which pages are missing offers.price or aggregateRating?
```
Why this prompt works:
- Naming the URL pattern rather than a single URL is what scopes the answer to the template. A prompt that names one page returns one page's structured data.
- Naming the specific fields returns a count per field. Asking whether the structured data is "valid" returns a pass or fail judgment instead, which hides how many pages are affected.
- Asking across the template means the answer is built from the crawl rather than a page-by-page fetch, so the counts cover every URL in the crawl rather than a sample.
Review the coverage and look for where the missing pages cluster. A field missing on a scattered 5% of the template is a different problem from one missing on an entire subdirectory.
Confirm one affected page against Google's indexed version before filing anything:
```
Check /p/clearance/summit-40l-pack against Google's URL Inspection. Does Google see the price?
```
Why this prompt works:
- The crawl shows what Botify's crawler rendered. URL Inspection shows what Google indexed. When the field is missing in both, the gap is in the page rather than in either crawler.

Follow-up prompts

"List 20 URLs missing offers.price so I can send them to engineering." — turns the count into something a ticket can reference.
"Do any other templates on this project have the same field missing?" — checks whether the fix is one template or several.
"Compare this against the crawl from before the last release." — separates a new regression from a long-standing gap.

Make it repeatable

Re-run after each crawl that follows a template change, rather than only when a rich result disappears. Coverage falling by a few percent is easier to act on than a ranking drop weeks later.
Keep the URL pattern and the field list identical between runs, so the counts stay comparable.
The same template-wide check applies to values you configured yourself. See Checking Whether a Custom Extract Is Reliable Before You Build On It.