📘 This use case demonstrates checking what a custom extract actually captured across the pages it covers, measured against a stated expectation rather than a glance.
Best for: Teams configuring custom extracts in SiteCrawler · Uses: crawl data and custom extracts, via your AI assistant
Overview
A custom extract captures a value from your pages during the crawl, and anything you build afterwards — a segmentation, a report, a PageWorkers dataset — inherits whatever it captured. Botify MCP can report what the extract actually returned across the pages it covers, so the rule is checked before the work that depends on it.
Prerequisites
Botify MCP connected to your AI assistant, such as Claude or ChatGPT. See Connecting to the Botify MCP for setup steps.
At least one custom extract configured on the project.
A completed crawl that ran after the extract was configured. Values are captured during the crawl, so a crawl that predates the rule does not contain them.
Description of the problem
An extract that returns a value on every page looks like it is working. It is not the same thing as being correct: a selector that matched a boilerplate element returns the same value everywhere, and the fill rate reports that as full coverage. A selector written against the standard page layout can also miss the variants of that layout entirely, so the gap follows a page type rather than scattering at random. Neither shows up in a count of how many pages have a value.
Application
Ask for coverage and variation together, not coverage alone:
For [project], check the "price" extract across the pages matching /p/*. How many pages have a value, and how many distinct values are there?
Why this prompt works:Asking for distinct values alongside the fill rate is what separates coverage from correctness. A fill rate on its own cannot distinguish a working extract from one that captured the same boilerplate value on every page.
Naming the URL pattern scopes the check to the pages the extract is meant to cover, so pages it was never expected to fire on do not count against it.
Naming the extract explicitly keeps the answer to your rule rather than to a field the crawl captures by default, such as the title or the H1.
Read the two numbers together. A high fill rate with very few distinct values points at a selector matching boilerplate. A fill rate well under 100% is worth locating before it is worth explaining.
Find where the empty pages sit, and check one against the live page:
Where do the pages with no value cluster? Show me a few, and tell me what is on one of them where the extract expected a price.
Why this prompt works:Asking where the gaps cluster distinguishes a rule that missed a layout variant from a value that is genuinely absent on those pages. The first is a rule to fix; the second is not a problem.
Checking a page rather than only the count is what tells you which of the two you have.
State what a correct result looks like, and check the extract against it:
Check the "price" extract on /p/* against these expectations: a value on every page, numeric, and more than 100 distinct values across the template.
Why this prompt works:Writing the expectation down is what makes the check repeatable. "Does this extract look right" produces a judgment; a stated expectation produces a pass or a list of failures.
An expectation about variation, not only presence, is what keeps the boilerplate case from passing.
Follow-up prompts
"Which page types does this extract fire on, and which does it miss?" — turns a fill rate into a list of layouts to fix the rule against.
"Run the same check on the other extracts configured for this project." — covers the rest of the set once the method is established.
"Compare this against the previous crawl." — separates a rule that never worked from one a site change broke.
Make it repeatable
Re-run after a template change on the pages the extract covers. A selector is tied to the markup it was written against, and a layout change can empty it without anything else failing.
Keep the expectations from step 4 written down alongside the extract. The next person to check it should not have to reconstruct what correct meant.
Check a new extract before building on it, rather than after a report looks wrong. A segmentation built on a bad extract is harder to unpick than the extract is to fix.
For the same kind of template-wide check on structured data rather than your own rules, see Auditing Structured Data Across a Page Template.
Result
What the extract actually captured, across the pages it covers, measured against a stated expectation rather than a glance — before a segmentation, a report, or a dataset is built on it.
Read next
Related topics