How Brave Search finds pages, and why chasing every engine is a trap

Most SEO advice treats search-engine discovery as one mechanism with cosmetic differences between engines: submit a sitemap, keep robots.txt clean, wait to get crawled. Brave Search breaks that model. It has no sitemap ingestion, no Search Console equivalent, and no IndexNow support. It will not crawl a page that Googlebot cannot crawl.¹ And it fills the gaps in its own crawl with opt-in browser telemetry that most publishers have never enabled. That would stay a niche curiosity except for one fact: Claude’s web search runs on Brave’s index, confirmed by Anthropic’s own subprocessor disclosure.³ If you care about being cited by Claude, you are already optimizing for Brave, whether you knew it or not.

Claude’s web search runs on Brave’s index, not Bing’s. A page’s Brave ranking is its Claude citation pool.

Does Claude’s web search run on Google’s index or Bing’s?

Neither. Claude’s web search runs on Brave. This is the assumption most SEOs get wrong, because the reflex is “AI answer engines run on Bing” (true for ChatGPT’s search for much of its history), and Brave rarely enters the conversation at all.

The evidence is disclosure-based and strong. Anthropic added “Brave Search” to its official subprocessor list on March 19, 2025, one day before it announced Claude’s web search feature on March 20.³⁴ A subprocessor list is a compliance document, not marketing, which makes it a more reliable signal than a press release would be. On top of that, the independent researcher Simon Willison inspected the web search tool’s function schema and found its parameter object literally titled BraveSearchParams, then ran a matched query (“pelican facts”) through both Claude’s web search and Brave Search and found the ten cited results were an exact match for the live Brave results.⁴ TechCrunch reported the same connection the same day.⁵

Two caveats keep this honest. First, Anthropic has never issued a press release or joint announcement confirming a Brave partnership, so this is confirmation by disclosure and technical fingerprint, not by announced deal. Anthropic’s current public web search docs do not name a provider at all.⁶ Second, this describes the default web_search tool used across Claude.ai, the API, and Claude Code. It is a separate thing from the optional “Claude Cowork on Amazon Bedrock with Brave Search MCP Server” enterprise integration Brave blogged about in June 2026, which a customer has to wire up manually.⁸ Do not conflate the two. And when Claude runs on Google Cloud’s Vertex platform, Google’s own docs describe web search as using “a third-party search service provider selected by Anthropic” without naming Brave, so I would not state “Google Cloud names Brave” the way some coverage has.⁹

How does Brave Search actually find a new page?

Brave has two discovery inputs, and neither one is a channel a publisher can submit to: a crawl gated on Googlebot-crawlability, and an opt-in browser-telemetry system that surfaces URLs nothing links to yet.

The first is crawling, gated on Google. Brave’s crawler documentation states it plainly: “if a domain or page is not crawlable by Googlebot, then Brave Search’s bot will not crawl it either.”¹ Brave’s crawler also refuses to advertise a distinctive user agent, and it says why: “The Brave Search crawler does not advertise a differentiated user agent because we must avoid discrimination from websites that allow only Google to crawl them.”¹ So Googlebot-crawlability is not one ranking factor among many for Brave. It is the entry condition for existing in Brave’s index at all.

The second input is the Web Discovery Project (WDP), which Brave’s own page describes as “an off-by-default (aka opt-in), privacy-preserving system” that partially powers the crawler using data from users who enable it in Brave browser’s settings.¹ This is how Brave learns about URLs that nothing links to yet. The catch for publishers is that WDP is a user-side setting you cannot influence. There is no submit form that feeds it.

On the submission question specifically: Brave’s crawler page documents only a submit-url form for requesting a re-fetch of a page Brave already knows, or for delisting a page that no longer exists.¹ It describes no sitemap ingestion and no Search Console equivalent anywhere on the page. MERJ’s teardown of Brave’s discovery reaches the same conclusion and adds that the submit form only re-fetches already-known pages rather than discovering new ones, which matches what Brave documents.⁷

One deindexing nuance worth internalizing, because it inverts the Google habit: on Brave, robots.txt does not keep a page out of the index. Brave’s page says “robots.txt is not used to prevent a page from being indexed,” and the only reliable removal lever is an on-page noindex directive, after which Brave has to re-fetch the page to see it.¹ One more claim travels with Brave’s model: that its crawler does not execute JavaScript and works from raw HTML only. Brave’s help page does not actually say this, so I am attributing it to MERJ’s analysis rather than treating it as house-verified.⁷ It is consistent with everything Brave does document, but it is MERJ’s finding, not Brave’s statement.

How is Brave’s model different from Bing’s?

Bing gives publishers the push-based channel Brave lacks entirely. Microsoft, with Yandex, created IndexNow, a protocol that lets a publisher notify participating engines the instant a URL is added, changed, or removed, and submitting to one participating engine propagates to all of them, a list Google has never joined.¹¹ Bing also runs Bing Webmaster Tools, an actual publisher-facing console with submission, coverage, and query data. Brave has no equivalent of either the push protocol or the console.

Bing’s index also reaches further than Bing’s own results page. DuckDuckGo sources most of its links and images from Bing while running its own supplementary crawler, and several smaller engines syndicate Bing’s index rather than building their own.¹² I would treat the exact roster of Bing resellers as directionally well established rather than precisely fixed, since the arrangements shift, but the structural point holds: ranking in Bing has historically bought distribution across a family of downstream surfaces.

The reason this contrast matters is that Brave is not one of those Bing resellers. Brave says it reached 100% independence from Bing in April 2023, removing the last remnant of Microsoft’s index from its results after climbing from roughly 87% at its 2021 launch.² That independence figure is Brave’s own self-reported metric rather than a third-party audit, but the direction is not in dispute: Brave runs its own index, which is exactly what makes “Claude runs on Brave” a meaningful statement rather than a roundabout way of saying “Claude runs on Bing.” Ranking in Brave buys Brave, plus whatever consumes Brave’s index, which now includes Claude.

How is Brave’s model different from Google’s?

Google is the gold-standard publisher toolkit that Brave declines to replicate. Google discovers URLs from known pages, links between known pages, and submitted sitemaps; it crawls with a Chrome-based renderer that executes JavaScript through a rendering queue; and it exposes all of it through Search Console.¹⁰ A publisher working with Google has a submission path, a rendering pipeline that tolerates client-side content (with the caveats I have written about elsewhere for the Shopping crawler), and a diagnostic console.

Brave offers none of the three, by design. It rides on Google’s crawl decision, renders less, and gives you no console to check what it saw. The practical asymmetry is that the work you do to satisfy Google’s discovery is most of the work that makes you discoverable to Brave, because Brave’s crawl is downstream of Google’s crawlability verdict. The reverse is not true: nothing you do specifically “for Brave” moves the needle, because Brave gives you no lever to pull.

What does this mean for AI-citation visibility?

If Claude cites from Brave’s ranking, then your Brave position is your Claude citation candidacy. MERJ’s own analysis of roughly 35,000 Claude citations across about 400 queries found that 79.2% of Claude’s citations appeared in Brave’s own top-10 results, versus 34% overlap with Google’s top 10.⁷ That is MERJ’s proprietary methodology, so read it as “MERJ reports X,” not as a settled figure. The direction is the load-bearing part: Claude’s citations track Brave far more closely than they track Google.

I ran a small first-hand check to see whether that direction holds up. I put four e-commerce and SEO queries through the web search tool available in my Claude environment and compared each result set against Brave Search’s live top ten.

Query	Overlap with Brave top 10
Merchant Center price mismatch structured data	6 of 10
ProductGroup schema variant requirements	9 of 10
hreflang x-default best practices	7 of 10
Core Web Vitals INP threshold	5 of 10

Overlap ran from 50% to 90%, averaging about 68% by strict URL match, and higher once you account for result-type differences (Brave surfaced Reddit threads and YouTube videos that the tool’s link set omits). This is n=4 and illustrative, not a study, but it is consistent with the confirmed Brave backing and with the direction of MERJ’s numbers. One honest limitation shaped the method: I could not fetch Google’s live results page to reproduce the Brave-versus-Google contrast, because Google blocks automated fetches of its results page while Brave does not. So I corroborated the Brave side first-hand and left the Google differential as MERJ’s finding.

So how should you actually optimize for all of this?

Stop hand-tuning for each engine’s discovery quirks. Brave, Bing, and Google do not share a submission mechanism, a rendering budget, or a diagnostic surface, which means “optimize for AI crawlers generally” is advice with no object. The useful move is to separate what transfers everywhere from what does not.

Three fundamentals transfer to every engine in this piece, and they are what I call the crawlability floor: Googlebot-crawlable, server-rendered HTML; signals delivered on the page rather than in HTTP headers; and clean, self-consistent canonicals. Brave gates on Googlebot-crawlability, Google and Bing reward it, and Claude inherits it through Brave. Server-rendered HTML clears the widest set of crawlers, including the ones that render little or no JavaScript. On-page signals beat header-based ones because the low-rendering crawlers are the least likely to act on headers. These are not engine tactics. They are the price of admission to all of them at once.

Above the floor sit the engine-specific rabbit holes, and they earn far less than the effort they invite. WDP is opt-in telemetry you cannot influence, so there is nothing to optimize. IndexNow only reaches the Bing family and buys speed of inclusion, not ranking, so it is a nice-to-have for large or fast-changing sites and irrelevant for most. JavaScript-rendering quirks are worth fixing once, to clear the floor, and not worth re-solving per engine. My read: get the crawlability floor genuinely right, verify it the boring way by fetching your own pages without JavaScript and reading the raw HTML, and treat everything past that as marginal gain to price accordingly. The engine you most want to be cited by may be one you have never optimized for by name, and it is reading the same crawlable HTML as all the others.