You.com Highlights vs Full-Page Extraction: A Reproducible Citation Test
You.com now lets Search API users request relevant highlights or full-page HTML and Markdown. Use this protocol to compare citation support, answer coverage, latency, and tokens without inventing a winner.
Direct answer: You.com added an extraction object to POST /v1/search on August 11, 2026. A client can request relevant highlights for token-sensitive workflows or retrieve a full_page representation as Markdown or HTML. The modes expose different amounts and shapes of evidence.
There is no honest universal winner without a task and test. Highlights can reduce context volume but may omit a passage needed for a complex claim. Full-page extraction can preserve more context while increasing tokens, latency and irrelevant material. This protocol compares both without presenting an unrun benchmark as a result.
Map the response contract before comparing quality
| Mode | Returned content | Primary risk |
|---|---|---|
| Highlights | contents.highlights with relevant passages; ordinary snippets omitted | Needed context falls outside selected passages |
| Full page: Markdown | contents.markdown plus default snippets | Navigation and repeated page material consume context |
| Full page: HTML | contents.html plus default snippets | Markup noise and larger payloads complicate parsing |
Save the raw Search API response before cleaning it. The source URL, title, retrieval time, extraction mode, returned order and errors are part of the evidence object.
Freeze a query-and-answer fixture
Use at least four task classes: a narrow fact, a multi-condition explanation, a comparison that needs evidence from more than one source, and a current product fact. Add one zero-result or inaccessible-page case. Freeze exact queries, domain filters, country and language settings, freshness controls, result count, model, answer instructions and acceptance rubric.
Run both extraction modes against the same query in close succession. If the result set changes, compare only overlapping URLs or record the retrieval difference as a separate variable. Otherwise the test confuses extraction with search ranking and index freshness.
The existing GET versus POST guide covers endpoint and cache semantics. The Answer API citation audit explains claim-to-source review.
Score evidence and efficiency separately
| Metric | Definition | Evidence to save |
|---|---|---|
| Claim support | Material answer claims directly supported by a retrieved passage | Claim, passage, URL and reviewer label |
| Coverage | Required task elements answered with evidence | Frozen rubric and missing elements |
| Source fidelity | Answer preserves conditions, uncertainty and attribution | Source snapshot and answer text |
| Input tokens | Tokens sent into the answer step | Tokenizer/version and per-source counts |
| Latency | Elapsed search, extraction and answer time | Start/end timestamps and retry state |
| Failure rate | Empty, inaccessible, truncated or malformed sources | Raw error and HTTP/extraction state |
Report medians and tail values for tokens and latency. For citation support, preserve reviewer disagreements instead of forcing a clean score.
Calculate citation value per 1,000 tokens carefully
A practical efficiency measure is supported material claims ÷ input tokens × 1,000. Publish the numerator and denominator, not only the ratio. A compact mode can score well while missing an essential claim; a full-page mode can support more claims but waste context.
Use a release gate: no extraction mode wins when it increases unsupported material claims, hides contradictory source language, or fails the task’s mandatory element—even if its token ratio improves. Choose a default by task class and keep a fallback when extraction returns insufficient evidence.
Status: this is a reproducible protocol, not a completed benchmark. Search Engine Answer has not run a production You.com key against this fixture, so no measured advantage is claimed.
Ask a question or join the discussion