Improving web search quality by switching to Brave or Perplexity
21 min read
Key Takeaways
Deadline: Google shuts down the Custom Search JSON API on 1 January 2027, so every deployment still using it needs a replacement before then.
Recommendation: Switch to the Brave or Perplexity Search API. Both beat Google Custom Search in every configuration tested, at effectively the same cost; the choice between them rests on compliance, vendor preference and contract terms rather than performance.
Snippet quality: On snippets alone, Perplexity reached 94.3% and Brave 88.0% against Google's 59.3% — a 35-point spread on identical questions. Google's snippets average 157 characters and usually identify the page without containing the answer.
End-to-end accuracy: Inside a full assistant that can rewrite queries and open pages, Google recovers most of that ground but does not close it: 94.3% (Brave) and 93.3% (Perplexity) against 88.0% (Google), falling to 82.0% when the decision to crawl is left to the assistant.
Agentic search is not a shortcut: Grounding with Google Vertex AI (92.6%, but 70 s per answer) and Bing Grounding (89.0% at best) add no accuracy, are slower than the search APIs that beat them, and cost three to seven times more.
Cost: $5.27 (Perplexity) and $5.28 (Brave) per 1,000 questions, against $6.41 for Google Custom Search, $19.66 for Grounding with Google Vertex AI and $36.00 for Bing Grounding.
Grounding curbs hallucination: With no search the model guessed, answering 187 of 300 questions wrongly; with snippets in front of it, it declined instead of inventing, giving only 12–24 wrong answers.
Executive summary
Google is shutting down the Custom Search JSON API on , so deployments using it need a replacement. We compared the three search APIs that could take its place — Google Custom Search, Brave Search and Perplexity Search — using the SimpleQA dataset, both with the search engine isolated and through a Unique AI assistant. Two agentic search services offered in the Unique platform, Grounding with Google Vertex AI and Grounding with Microsoft Bing, are included in the assistant benchmark for comparison.
Brave and Perplexity scored higher than Google Custom Search in both benchmarks, at broadly the same cost. On snippets alone, Perplexity reached 94.3% and Brave 88.0% against Google's 59.3%; once the assistant can rewrite queries and open pages the gap narrows, with Brave at 94.3% and Perplexity at 93.3% against Google's 88.0%. Neither agentic search service scored above them, and both are slower than the search APIs that beat them on accuracy as well as three to seven times more expensive. On these results either Brave or Perplexity is a suitable replacement, and the choice between them rests more on compliance aspects and provider preference.
Why web search matters
An agent has two sources of knowledge before it searches anything: what the underlying model absorbed during training, and what the client has put into its knowledge base. Neither is complete. Training data has a cut-off date and was never exhaustive to begin with, least of all on narrow or recent subjects. A knowledge base holds what an organisation has deliberately curated, which will never cover everything an assistant may be asked.
Web search fills this gap by allowing an agent to independently look up information it could not otherwise access. As we will see in this report, this improves question-answering accuracy and, when the retrieved text is informative, substantially reduces hallucination.
How the Web Search tool works
The Web Search tool in Unique AI is assembled from separately provided services, and each of those services can be swapped for another. It is worth looking at the components before the whole, because the choice this report is about is a choice between building blocks.
Finding sources
The first component finds candidate sources, and it comes in two kinds, search engines and agentic search services.
A search engine takes a query string and returns a ranked list of results: page titles, source URLs, and a short extract of text from each page known as a snippet. It does not read the pages and it does not attempt to answer the question. Google Custom Search, Brave Search and Perplexity Search all work this way (Diagram 1). Different engines return different URLs for the same query, and different snippets even when they return the same URL.
Diagram 1. Search engine data flow.
An agentic search service takes an instruction rather than a query, and runs its own retrieval loop behind a single call: it searches, reads sources, summarises what it found, and repeats as needed. What comes back is not a list of raw results but grounded findings — a summary of the relevant information together with the sources it rests on. Grounding with Microsoft Bing and Grounding with Google Vertex AI work this way (Diagram 2).
Diagram 2. Agentic search service data flow.
Reading pages
The second component is a crawl service, which takes a URL and returns the full text of that page. Snippets are short by design and sometimes do not contain the answer; crawling is how an agent gets the rest. It is not free: crawling costs time and money, and some websites block it outright. Whether it happens at all depends on the search strategy configured for the Unique space the assistant runs in.
The full Web Search tool
Putting them together, a typical question-and-answer flow runs as follows.
A question arrives.
The agent prepares a query or an instruction which is passed in the web search tool call.
The search component runs — either a search engine returning URLs and snippets, or an agentic search service returning grounded findings.
The agent assesses whether it has enough evidence. If a promising source has not been read in full, it can pass selected URLs to the crawl service and get the complete page text back.
The agent answers, with sources. If the evidence is still not good enough, it refines the query and searches again instead.
Diagram 3. Full Web Search tool data flow. A question arrives (1), the agent formulates a query (2), and the query is sent to the configured search component (3). This component is an either/or choice: a Search Engine, which returns URLs and snippets, or Agentic Search, which returns grounded findings. The administrator selects one of the two during setup and it applies to every request — the agent cannot switch between them. The agent then assesses whether the evidence is sufficient (4). If yes, it answers with sources (5); if not, it may perform an optional crawl of selected URLs to retrieve full page text (4a), or refine the query and search again.
Two things follow from this structure, and both shape the benchmarks below. The search component is interchangeable, so it can be tested by swapping it while everything around it is held fixed. And because page reading is optional, the quality of the snippets matters twice over: they are evidence in their own right, and they are also what the agent uses to decide whether a page is worth opening at all. The optional crawl shown in Diagram 3 is the normal behaviour; the forced-crawl arms of the second benchmark below override it deliberately as an experimental configuration.
What is changing
Google is shutting down the Custom Search JSON API on , so any deployment using it has to select a new search service. Microsoft closed the equivalent Bing Search API in August 2025, which removes the obvious like-for-like substitute and leaves two kinds of replacement: an independent search API, or one of the bundled agentic search services both vendors are now steering customers towards.
The agentic search services — Grounding with Google Vertex AI and Grounding with Microsoft Bing — collapse search, crawl and answer generation into a single call. They are a different kind of product: retrieval happens inside the vendor's own loop, and the steps we would otherwise configure are not exposed. Both are included in the end-to-end benchmark below, so the comparison covers both kinds of replacement.
The three search APIs compared here are Google Custom Search, the Brave Search API and the Perplexity Search API. In the end-to-end benchmark, pages returned by all three were read using Tavily Extract; keeping this fourth service fixed lets us compare the search APIs without also changing the page-reading provider. The two agentic search services appear in the end-to-end benchmark only. Putting them in the snippet-only benchmark would not be a fair comparison, since each is in a sense an encapsulated end-to-end assistant of its own and neither exposes a comparable list of snippets to test; in the end-to-end benchmark they are included for completeness.
What we wanted to know was narrow. Holding everything else constant, how much does an agent's ability to answer questions change when the search engine is swapped for another?
What we measured
A question-answering benchmark is a fixed list of questions, each stored with its correct answer. The questions are put to the system under test, each reply is compared against the recorded answer, and the matches are counted. Because the answers are fixed in advance, every system is scored against the same standard, and a run can be repeated later and compared with an earlier one.
The set used here is the SimpleQA dataset, published by OpenAI. Each of its 4,326 items is a short question about a single obscure fact with one verifiable answer — Q: Who received the IEEE Frank Rosenblatt Award in 2010? A: Michio Sugeno. The questions were written to be hard to answer from memory, which makes them a reasonably clean test of retrieval rather than of what the model already knows.
Deployed Unique AI assistants generally handle questions that are more complex and more specialised to financial services than SimpleQA. We nevertheless use SimpleQA because its short questions and unambiguous answers allow reliable automatic grading. Results should therefore be read as a controlled test of factual retrieval, not as a complete measure of production performance.
Grading is done by a language model. That is workable here because of how the questions were built: each has one unambiguous answer, so the judge is checking whether a name or a date matches rather than weighing how good a piece of writing is. It sees the question, the official answer and the agent's reply, and returns correct, incorrect, or not attempted. It does not see the search results, or which configuration produced the answer. Accuracy is the share of questions graded correct.
We ran two benchmarks on the same 300 questions. The first is deliberately naive: each question is used unchanged as a single search query, with no agent to extract keywords, reformulate it, issue follow-up searches or choose pages to open. A model then answers using only the titles and snippets returned by the engine. This artificial setup isolates how much usable evidence each engine supplies for exactly the same query. The second measures the assembled product as a client would configure it: a real assistant can write its own queries, search more than once and choose whether to open pages. It covers five providers — the three search APIs and the two agentic search services — under two page-reading policies. In both benchmarks, the answering model, the judge model and the question set were held fixed; only the components under test varied.
Isolating the engine
The first benchmark strips the setup back to the engine: the question goes to the engine unchanged, and the answering model sees only the page titles and snippets that come back. If those extracts do not contain the answer, it is instructed to reply "I don't know" rather than guess. The setup is not meant to reproduce normal assistant behaviour; it is designed to compare the evidence each engine returns under identical conditions.
Figure 1. Snippet-only accuracy by search engine, with the closed-book control for comparison.
The results in Figure 1 are striking in two respects. The first is the spread between engines: 35 points separate Perplexity from Google Custom Search on identical questions, with the same answering model, the same prompt and the same judge on either side of the swap. This shows that choosing a search provider is not a minor configuration detail.
The second is the distance from the closed-book control, which is the same model with no search at all. That it reaches only 31.3% is partly by construction, since SimpleQA was built to defeat recall, but the control still provides a useful baseline: depending on the engine, adding search raises accuracy by 28 to 63 percentage points. In other words, the model can answer about one-third of these questions from memory, while search supplies enough evidence to answer many more.
Examining the answers in more detail reveals an important lesson about grounding and hallucination. The three-way grading in Figure 2 matters here, because it separates being wrong from declining to answer.
Figure 2. Correct answers, wrong answers and refusals for each snippet-only arm. Google mainly loses coverage through refusals, while the closed-book control mainly answers incorrectly.
Google's shortfall is mostly the second kind. It gave 24 wrong answers and replied "I don't know" 98 times. Of the questions it actually attempted it was right 88.1% of the time — 7 points behind Brave, not 30. The headline figure is therefore largely a measure of how often the snippets ran out, not of how often the agent was led astray.
The closed-book control does the opposite, under an identical instruction. With nothing retrieved it declined 19 times and answered wrongly 187 times, guessing on almost everything it could not recall. Retrieved text seems to be doing something beyond supplying facts: it also gives the model a concrete thing to check itself against. A model looking at snippets that do not contain the answer will say so; a model looking at nothing at all does not appear to register that anything is missing. The full grades are in Table 1.
Table 1. Snippet-only grades and accuracy for each arm.
Search engine | Correct | Wrong | "I don't know" | Accuracy |
|---|---|---|---|---|
Perplexity | 283 | 12 | 5 | 94.3% ±2.6 |
Brave | 263 | 14 | 22 | 88.0% ±3.7 |
Google Custom Search | 178 | 24 | 98 | 59.3% ±5.6 |
Closed book (no search) | 94 | 187 | 19 | 31.3% ±5.2 |
What the snippets look like
The poor performance of Google Custom Search in this experiment is perhaps surprising, but it is largely explained by the snippets each engine returns: those from Google are generally less informative than those from Brave or Perplexity.
Examining a question where all three engines returned the same page makes this concrete. As a response to the query "In which city was John Gilbert Layton raised?", all three search engines returned en.wikipedia.org/wiki/Jack_Layton. The snippets each engine returned are shown in Table 2.
Table 2. Text returned with the same result by each engine.
Engine | Text returned with the result |
|---|---|
Google Custom Search | "John Gilbert Layton (July 18, 1950 – August 22, 2011) was a Canadian politician and academic who served as the leader of the New Democratic Party (NDP) from …" |
Brave | "John Gilbert Layton was born on July 18, 1950 in Montreal, Quebec, to parents Doris Elizabeth (née Steeves), and Progressive Conservative MP Robert Layton. He was the maternal great-grandnephew of William Steeves, a Father of Confederation, and his grandfather, Gilbert Layton, had served as a minister without portfolio to the government of Quebec's Union Nationale under Premier Maurice Duplessis. Layton was raised … John Gilbert Layton was born on July 18, 1950 in Montreal, Quebec… Layton was raised in Hudson, a largely Anglophone suburb of Montreal, where he served as the student council president of Hudson High School." |
Perplexity | "The son of Robert Layton, a Progressive Conservative cabinet minister, Layton was raised in Hudson, Quebec. … Layton was raised in Hudson, a largely Anglophone suburb of Montreal, where he served as the student council president of Hudson High School." |
Notice that the Google snippet does not contain the answer (Hudson), whereas both the Brave and Perplexity snippets do. The example is a single case, but the pattern holds across the set: Google's snippets average 157 characters, Brave's 1,175 and Perplexity's 235. Perplexity's are nearly as short as Google's, but qualitative inspection suggests they are usually more relevant to the query, which is consistent with their benchmark performance. Longer is not automatically better, since flooding an agent's context with irrelevant information can degrade performance.
It would be unfair to call Google Custom Search defective. It descends from a product built to help a person choose which link to click, and for that job an opening line that identifies the page is a sensible thing to show. The Brave and Perplexity search APIs are newer, and were perhaps designed with something closer to our use case in mind.
The isolated view presented above is deliberately artificial. The next benchmark measures the same engines inside an assembled Unique AI assistant.
The end-to-end benchmark
The second benchmark measures the product as it is actually assembled, and this is where an agent enters. It writes its own queries, decides how many to issue, and can open pages. We tested two page-reading policies:
Forced crawl. Pages selected from the search results are fetched before the assistant answers. This provides more complete evidence but adds time.
Voluntary crawl. The assistant can answer from snippets when they are sufficient, or fetch full pages when it needs more evidence. This is how the we generally recommend running the product.
Running both is more informative than running either alone because they test different demands on the engine. Forced crawling measures primarily whether the engine returns useful URLs. Voluntary crawling also depends on snippet quality, because the assistant uses each snippet to decide whether a page is worth opening. Together, the configurations test the two jobs an engine does: finding the page and describing it.
Alongside the three search APIs we ran the two agentic search services under the same two policies. The comparison is less clean for them because an agentic search service performs its own retrieval before our page-reading step sees anything.
Figure 4. Accuracy against median time to final answer for the ten configurations, coloured by provider and shaped by page-reading policy. Bars are 95% margins of error, and the time axis is logarithmic. The bars overlap widely across the upper half of the range, so small differences in accuracy should not be read as a ranking.
Five of the ten configurations in Figure 4 sit between 92% and 95%: both Perplexity arms, both Brave arms, and Grounding with Google Vertex AI under forced crawl. Margins of error are around three points, so the ordering within that group is not conclusive.
Below the leading group the field is flatter than it first appears. Vertex under voluntary crawl, Bing under either policy and Google Custom Search under forced crawl all land between 87.0% and 89.3%. Only Google Custom Search under voluntary crawl, at 82.0%, separates clearly from everything else. Left to its own judgement on Google's snippets, the agent underestimates how often it needs to crawl and answers instead. Any search strategy that leaves that decision to the assistant will have to account for it.
Page-reading policy has a strong impact on speed, but only where retrieval itself is cheap. For the three search APIs, forcing crawl multiplies the time to answer by 2.4× to 2.9×, the cost of the extra crawling. Again, this is the value of informative snippets: they let the agent skip crawling altogether.
The agentic search services do not behave that way. Their own retrieval dominates the answer, so switching policy changes the time by only about 1.4×. Vertex is slow in absolute terms: 46.9 s under voluntary crawl and 70.0 s under forced crawl, against 6.3 to 18.2 s for every search-API arm. Bing was quicker than Vertex, at 16.9 s under voluntary crawl and 23.8 s under forced crawl, but that puts it in the same time band as the forced-crawl search-API arms while scoring below them, and it reached only 89.0% at best. Neither agentic search service bought accuracy that a search API did not already provide, and neither matched the speed of the search-API arms that beat it on accuracy.
Google as page reading is added
Following Google Custom Search across the three configurations helps explain what is going on (Figure 5). Reading pages is what recovers the correct answers. When reading is optional, though, the refusals do not all become correct answers; they divide between correct and wrong. The agent is not unaware of the problem. Running with Google Custom Search it issues more queries and opens around five times as many pages as it does with Brave, which is consistent with it noticing that the snippets are thin. Yet it does not do so often enough, and answers on inadequate evidence instead.
Figure 5. Google Custom Search as page reading is added. The first column comes from the snippet-only benchmark, where the question is the query; the other two are product configurations with an agent writing the queries.
Cost
Google Custom Search, Brave Search and Perplexity Search each charge $5 per 1,000 search requests. Their total costs differ slightly because the assistant may choose to perform additional searches or use Tavily to read full pages. This is particularly relevant for Google Custom Search API where the crawling is essential to ensuring decent quality. Bing and Vertex also incur grounding and internal model-token charges. Table 3 gives the totals for the voluntary-crawl arms.
Table 3. Web Search cost per 1,000 questions, voluntary crawl.
Provider | Web Search cost per 1,000 questions |
|---|---|
Perplexity | $5.27 |
Brave | $5.28 |
Google Custom Search | $6.41 |
Grounding with Google Vertex AI | $19.66 |
Bing Grounding | $36.00 |
These figures include Tavily page extraction costs but exclude free allowances, volume discounts and the token cost for the answering model used equally across all arms. Because Tavily charges for each successfully extracted page, configurations that require less page reading also cost less.
Conclusion
Brave and Perplexity both came out ahead of Google Custom Search in every configuration we ran, so a switch is an upgrade rather than a like-for-like replacement. On snippets alone the gap is up to 35 points, because Google's extracts usually identify the page without containing the answer. Through the assistant, which can rewrite queries and open pages, Google recovers most of that ground but does not close it: 94.3% for Brave and 93.3% for Perplexity at their best, against 88.0% for Google.
The results also suggest that Perplexity may have a slight edge over Brave, but this is not conclusive: Brave produced the strongest arm in the end-to-end benchmark, and its longer snippets could be more useful when the agent is answering more complex or ambiguous questions than the ones posed by SimpleQA.
The agentic search services do not offer a shortcut. Grounding with Google Vertex AI under forced crawl reached 92.6%, inside the leading group, but took an unreasonable 70 seconds to answer; under voluntary crawl it fell to 89.3% and still took 46.9 s. Bing Grounding reached 89.0% at best. Neither improves on Brave or Perplexity for accuracy, neither is faster than the search APIs that beat it on accuracy, both cost three to seven times as much per thousand questions, and both give up the separation between searching and page reading that lets us tune the pipeline at all. On this evidence they are a fallback rather than a destination.
Based on these results we recommend switching to either the Brave Search API or the Perplexity Search API. They are essentially identical in terms of costs and in our benchmark the performance is comparable. Choosing between them will likely boil down to questions of compliance, vendor preference and contract terms, rather than raw performance metrics. As always, our Customer Success representatives are at the ready to help you find the right option for your needs.
Disclaimer
This report presents our current findings and recommendations regarding alternative web search providers to Google. It does not constitute legal, regulatory, or compliance advice. Clients should review these recommendations with their internal teams to ensure alignment with their own policies and procedures before making any decisions.