Fetch measurement asks a narrow question: when an AI system is handed an exact URL, can it retrieve the page, read the important facts, and use them in an answer? It is the most operational GEO mode because the target is known. The page either returns useful evidence to the fetcher, or it does not.
1. What Fetch measurement is
Memory measurement tests what the model already knows. Search measurement tests which pages a vendor retrieval layer discovers. Fetch measurement tests exact-URL recall: the user or model provides the URL first, then the AI attempts to read that URL. The measurement unit is therefore not ranking position. It is the content the model could extract from the first fetch path.
This makes Fetch the right mode for product pages, pricing pages, support articles, policies, documentation, and comparison pages. If those URLs return an app shell, a consent wall, a soft error, or metadata without facts, the AI can only summarise the failure.
2. The probe pattern
The basic probe is simple: Read https://example.com/page and summarise it, focusing on installation time, eligibility, price and next action. The prompt names the exact URL and the facts that matter. The response is then checked against the expected page facts, not against a generic answer quality score.
Run the same probe through each vendor path. In Combot's worker, Anthropic receives web_fetch_20260209 with citations enabled. OpenAI has no dedicated URL-fetch tool in the current worker path, so URL fetch enables web_search. Gemini receives url_context, optionally alongside google_search.
3. Per-vendor success rates
Do not invent success-rate percentages. Measure them on a fixed URL set. For each URL, record whether the vendor returned the correct status, extracted the title, saw the H1, captured the target facts, preserved the canonical URL, and cited or referenced the source where the API exposes that metadata.
| Vendor path | Fetch surface | JS behaviour claim | Score method |
|---|---|---|---|
| Anthropic | web_fetch_20260209 |
Dynamic JavaScript sites are unsupported in the web fetch docs. | Compare extracted answer, citations, and web_fetch_requests. |
| OpenAI | ChatGPT-User / web_search path |
JS execution is not established by the checked docs. | Compare answer facts, annotations, logs, and raw HTML tests. |
| Perplexity | Perplexity-User |
JS execution is not established by the checked docs. | Compare user-fetch logs, answer facts, and source links. |
| Gemini | url_context |
Measure retrieved URL metadata and answer facts directly. | Compare url_context_metadata, status, and extracted facts. |
4. Common failure modes
Fetch failures are usually mundane. A CSR-only page returns <div id="root"></div>. A paywall hides all useful summary text. Open Graph metadata is missing or generic. Time to first byte is slow enough that the fetcher times out. A WAF returns 500 or 403 to AI user agents while humans and Googlebot see 200.
The checklist is equally mundane: status code, title, meta description, H1, canonical, OG tags, JSON-LD, body text length, key facts in the first thousand words, crawlable anchors, and no cookie banner dominating the raw HTML.
5. The fetch-audit method
Frame this as an audit you can run, not a fully productised button. Invoke an LLM with the target URL, use the vendor fetch tool where available, parse what it extracted, then compute a fetch-readiness score. For Anthropic, the deployed Combot worker uses web_fetch_20260209, max_uses: 5, citations enabled, and a large content token budget. The audit compares the model's extracted facts with the page's expected facts.
A reproducible audit stores three artefacts: raw HTTP response by user agent, rendered browser DOM, and model extraction result. The diff explains whether the problem is delivery, rendering, extraction, or synthesis.
Keep the scoring boring: pass, partial, or fail for each required fact. A page that exposes the title but hides price, availability, or next action is not ready for commercial Fetch prompts, even if the model produces a fluent summary.
6. Per-vendor fetch-readiness scorecard
| Check | Claude fetch | ChatGPT path | Perplexity user | Gemini URL context |
|---|---|---|---|---|
| Initial HTML has core facts | ✓ Required | ✓ Required | ✓ Required | ✓ Required |
| Depends on client JS | ✗ High risk | Measure | Measure | Measure |
| OG and title are specific | ✓ Useful | ✓ Useful | ✓ Useful | ✓ Useful |
| WAF allows user fetchers | ✓ Required | ✓ Required | ✓ Required | ✓ Required |
7. Anti-patterns
The biggest anti-pattern is optimising for the best-performing bot and declaring the page fetchable. The worst-performing important fetcher sets the ceiling. If Claude cannot read a JavaScript-rendered product page, that URL is not fetch-ready for Claude, even if a browser-rendered test passes.
The second anti-pattern is measuring only the HTTP status. A 200 response with no H1, no facts, no canonical, and no crawlable links is a failed fetch for AI purposes. Measure what the model can recall from the URL, then use Optimising Fetch to fix the delivery path. If the URL was discovered through Search, connect this back to Measuring Search so the cited URL becomes a monitored asset.
Paired post: Optimising Fetch
Series: Optimising Memory · Optimising Search · Optimising Fetch · Measuring Memory · Measuring Search · Measuring Fetch
Foundation: AI Knowledge Modes — Memory · Search · Fetch