--- source_url: "https://docs.tavily.com/documentation/best-practices/best-practices-search" title: Best Practices for Search - Tavily Docs mirrored_at: 2026-08-30T13:01:41.478Z host: docs.tavily.com cited_in_42a: true mirror_canonical: "https://index.42a.ai/docs.tavily.com/documentation/best-practices/best-practices-search" --- > **Original source:** https://docs.tavily.com/documentation/best-practices/best-practices-search ## Query Optimization ### Keep your query under 1500 characters Keep queries concise—under **1500 characters**. Think of it as a query for an agent performing web search, not long-form prompts. ### Break complex queries into sub-queries For complex or multi-topic queries, send separate focused requests: ## Search Depth The `search_depth` parameter controls the tradeoff between latency and relevance: Show Latency vs relevance chart ![Latency vs Relevance by Search Depth](https://mintcdn.com/tavilyai/-85Rr9EfVqo8fXvO/images/search-depth.png?fit=max&auto=format&n=-85Rr9EfVqo8fXvO&q=85&s=c57f2074dda171a1e3e9f96afbec8f10)_This chart is a heuristic and is not to scale._ Depth Latency Relevance Content Type `ultra-fast` Lowest Lower Content `fast` Low Good Chunks `basic` Medium High Chunks `advanced` Higher Highest Chunks ### Content types Type Description **Content** NLP-based summary of the page, providing general context **Chunks** Short snippets reranked by relevance to your search query Use **chunks** when you need highly targeted information aligned with your query. Use **content** when a general page summary is sufficient. ### `basic` vs `advanced` `advanced` searches more broadly and reaches more sources per query, delivering the highest relevance at higher latency. Reach for it when coverage matters most: niche topics, very recently published pages, or questions with several distinct facets. Longer, more detailed queries also do better with `advanced` — the extra context gives it more to match against, whereas `basic` is tuned for short, focused lookups. `basic` covers less ground for a lower latency budget, making it the right default for general-purpose lookups where a fast, query-aligned answer is enough. Both depths return chunks, and `chunks_per_source` controls how many come back per source at either depth. ### Fast + Ultra-Fast Depth When to use `ultra-fast` When latency is absolutely crucial. Delivers near-instant results, prioritizing speed over relevance. Ideal for real-time applications where response time is critical. `fast` When latency is more important than relevance, but you want results in reranked chunks format. Good for applications that need quick, targeted snippets. `basic` A solid balance between relevance and latency. Returns reranked chunks. Best for general-purpose searches where you need quality results without the overhead of advanced processing. `advanced` When you need the highest relevance and are willing to trade off latency. Best for queries seeking specific, detailed information. ### Using `search_depth=advanced` Best for queries seeking specific information: ## Filtering Results ### By date Parameter Description `time_range` Filter by relative time: `day`, `week`, `month`, `year` `start_date` / `end_date` Filter by specific date range (format: `YYYY-MM-DD`) ### By topic Use `topic` to filter by content type. Set to `news` for news sources (includes `published_date` metadata): ### By domain Parameter Description `include_domains` Limit to specific domains `exclude_domains` Filter out specific domains `country` Boost results from a specific country ### By language Parameter Description `language` Boost results in a specific language. Accepts an ISO 639-1 code (`en`, `fr`, `zh-cn`) or an English language name (`english`, `french`). `filter_by_language` Strictly drop results that don’t match `language`, instead of only boosting them. Requires `language` to be set. ## Response Content ### `max_results` Limits results returned (default: `5`). Setting too high may return lower-quality results. ### `include_raw_content` Returns full extracted page content. For comprehensive extraction, consider a two-step process: 1. Search to retrieve relevant URLs 2. Use [Extract API](https://docs.tavily.com/documentation/best-practices/best-practices-extract#2-two-step-process-search-then-extract) to get content ### `auto_parameters` Tavily automatically configures parameters based on query intent. Your explicit values override automatic ones. ## Exact Match Use `exact_match` only when searching for a specific name or phrase that must appear verbatim in the source content. Wrap the phrase in quotes within your query: Because this narrows retrieval, it may return fewer results or empty result fields when no exact matches are found. Best suited for: - **Due diligence** — finding information on a specific person or entity - **Data enrichment** — retrieving details about a known company or individual - **Legal/compliance** — locating exact names or phrases in public records ## Async & Batch Search Use async calls for concurrent requests: ### Parallelize with bounded concurrency For larger batches, cap in-flight requests to stay under your [rate limit](https://docs.tavily.com/documentation/rate-limits), and tag each result so one failure (e.g. a `429`) doesn’t sink the whole batch. Size concurrency from your own [rate limit](https://docs.tavily.com/documentation/rate-limits): `concurrency ≈ (RPM / 60) × avg_latency_s`. For example, at 100 RPM and 3s avg latency that’s `(100 / 60) × 3 ≈ 5`. Start there and tune up while watching your `429` rate. ### Deduplication Dedupe the results to save tokens and avoid repetitive context — join unique `content` chunks with Tavily’s `[...]` separator. ### Operational checklist - **Run queries in parallel, but cap how many run at once** with a semaphore so you stay under your rate limit. - **Handle failures per query.** Tag each result `ok` / `error` and retry only the failed ones with backoff, so a single error never sinks the whole batch. - **Consolidate results.** Dedupe URLs and combine their unique content so you don’t pay to process the same page twice. - **Track credits.** Pass `include_usage=True` and sum the `usage` from each response to see total credits spent across the batch. - **Set a timeout.** Cap each search (e.g. `timeout=10`) so one slow query doesn’t stall the batch. ## Post-Processing ### Using metadata Leverage response metadata to refine results: Field Use case `score` Filter/rank by relevance score `title` Keyword filtering on headlines `content` Quick relevance check `raw_content` Deep analysis and regex extraction ### Score-based filtering The `score` indicates relevance between query and content. Higher is better, but the ideal threshold depends on your use case. Extract structured data from `raw_content`: ## Use Session Tracking for Multi-Step Workflows When an agent issues several Tavily calls to answer a single user task — for example, retrieving sources, then extracting full content from a subset, then running follow-up searches — pass a **consistent `session_id` across all related calls**. If your agent serves multiple end-users behind a single API key, also pass a stable `human_id` per user. For security, Tavily hashes human IDs before processing or storing them. See the [SDK references](https://docs.tavily.com/sdk/python/reference#session-tracking) or the [API HTTP headers](https://docs.tavily.com/documentation/api-reference/introduction#session--user-tracking) for how to set these.