Kagi Search API Adds Related Searches and Link-Preserving Extraction
Kagi’s July API update adds related searches and preserves original links in extracted documents. Update schemas, fixtures, and evidence exports carefully.
Confirmed in Kagi’s July 30, 2026 changelog: Search API responses added related searches, and extraction was updated to retain original document links. Kagi also described per-key cost tracking and personalization validation changes.
These additions can improve research interfaces, but they can also break strict decoders, snapshot tests, exports, and downstream evidence models. Treat the release as a response-contract migration. The changelog confirms the features; it does not define how every client library or existing stored response will behave.
Inventory the response contract
| Change | Potential dependency | Required check |
|---|---|---|
| Related searches | Strict response schema | Accept the new field without reordering core results |
| Preserved links | Extractor output and sanitization | Retain safe targets and provenance |
| Per-key cost data | Usage reporting | Map key labels without exposing credentials |
| Personalization validation | Controlled tests | Snapshot the account configuration |
Store the raw response before transforming it. If the current decoder rejects unknown fields, change it deliberately and add a compatibility fixture. A parser that silently drops new evidence can appear healthy while losing exactly the information the release was designed to expose.
Model related searches as suggestions
A related-search string is not an organic result, a query-volume estimate, or proof of user demand. Keep it in a separate typed collection with its source, position, request ID, locale, account profile, and retrieval time.
Do not automatically send every suggestion back to the API. That can create uncontrolled query expansion, unexpected cost, and a biased research corpus. Require an explicit expansion rule, depth limit, duplicate check, and stopping condition.
If suggestions become inputs to editorial research, record which ones were accepted and why. A useful workflow distinguishes product-generated leads from independently verified reader questions.
Preserve links as evidence
When extraction keeps original document links, store the target URL, visible anchor text, source document, source position, resolved URL, HTTP result, and whether the link is internal or external. Do not reduce the link to untraceable plain text.
- Test relative, absolute, fragment, redirected, and malformed targets.
- Resolve links against the canonical source URL.
- Apply a safe protocol allowlist before rendering.
- Keep the original target beside the resolved target.
- Record links removed by sanitization and the reason.
Preserved links improve provenance only when the application carries them through context assembly and export. The Kagi API reproducibility guide explains how to preserve the account and request context around the response.
Run a migration test
Create fixtures from pre-change responses, current responses with related searches, extracted pages with several link types, empty results, errors, and rate-limit responses. Compare the old and new normalized outputs field by field.
Check UI overflow, CSV and JSON exports, storage size, cache keys, cost aggregation, and any prompt template that serializes the response. Unknown fields should not appear in a model prompt merely because the API added them.
SearchEngineAnswer has not benchmarked the relevance of Kagi’s related searches or the completeness of its link preservation. Those require a declared sample. This migration guide is limited to the documented response additions and the checks they make necessary.
Ask a question or join the discussion