How to Rank in Brave Search (and Get Cited by Claude)

Brave Search doesn't crawl and rank pages the way Google does. It leans on real people using the Brave browser to vouch for a page before that page even enters the index - and that same index supplies most of what Claude cites when it answers with a web search. Here's how the mechanism actually works, and what to do instead of hitting "Submit URL" and hoping.

Why "just submit the URL" is bad advice

A tip that keeps circulating: Brave is Claude's primary search backend, Brave has a "Submit URL" tool at search.brave.com, so if you want your content to show up faster in Claude, submit your important pages there. It's a tidy story, and it's misleading in a way that can cost you more than it saves.

The tool's only documented function is forcing Brave to re-fetch a URL it already knows about. It is not a submission into the index and it does not guarantee indexing of new content. It's built for "I fixed something, please look again," not "please discover this page." Treated as the first, it's harmless. Treated as a discovery strategy, it's a lever that isn't connected to anything.

The bigger issue is what actually gates a new page into Brave's index in the first place, and it has nothing to do with a form.

How Brave actually finds new pages: two doors, not one

Brave has no search console, no sitemap submission, and no IndexNow equivalent. Discovery runs through the Web Discovery Project (WDP), an opt-in feature in the Brave browser that anonymously reports what pages opted-in users land on - Brave's own Help Center article confirms it's strictly opt-in and that contributed data "cannot be linked back to whoever contributed it." Around 120 million people are estimated to be in that pool. If none of them ever reach your page, nothing else you do matters. There are two routes in, with very different thresholds.

Page Channel - the hard door

Requires roughly 20 different opted-in WDP users, from different networks, to independently land on the page. Signals are protected with Brave's own STAR cryptographic protocol, which uses k-anonymity so a value only becomes readable once enough independent users submitted it. Brave's design writeup describes the mechanism but doesn't publish the specific quorum; the ~20-share figure for the Web Discovery Project itself comes from MERJ's independent testing below. Either way, below threshold, Brave's servers literally cannot decrypt or reconstruct what the page contains - a privacy mechanism, not an arbitrary spam filter, but the practical effect is the same: a brand-new page with no real traffic can sit invisible to Brave indefinitely.

Query Channel - the easy door

Requires only one opted-in user searching Google, Bing, Yahoo, or DuckDuckGo where your page already ranks. Brave's client recognizes the results page, anonymously re-fetches a cleaned version of it after a random 1-20 minute delay, and lifts the URLs out of it - no 20-person quorum required.

The practical takeaway: the fastest way into Brave's index is usually to already rank somewhere else. A page with zero visibility on Google, Bing, or DuckDuckGo has to clear the harder 20-person bar, which depends specifically on organic traffic from people running the Brave browser - a smaller slice of your total audience than "any visitor."

The technical checklist: make sure Brave can even see the page

Even once a page qualifies for discovery, it has to survive Brave's "double-fetch" verification - an anonymous, logged-out re-fetch that confirms the page looks the same to everyone. That check has stricter rules than Googlebot:

No JavaScript is executed. Content that only appears after a client-side render is invisible to this check. If a page depends on JS for its primary content, server-render or pre-render it.
Redirects disqualify a page. Any redirect in the chain marks it private, even redirect patterns Google tolerates fine.
Strict performance limits. The fetch aborts after 10 seconds and refuses responses over 2MB. Slow time-to-first-byte or bloated pages fail silently, with no report telling you why.
Only HTML signals count. A noindex sent via the X-Robots-Tag HTTP header is not read - only a <meta name="robots" content="noindex"> in the HTML <head>. Canonicals are only read from a <link rel="canonical"> element, never a header. If your CMS sets these via headers, Brave's verification may be looking at a page that doesn't reflect your intent at all.
Query strings are risky without a canonical. A second query parameter, or a query string over roughly 22 characters, marks the page private if there's no explicit canonical tag pointing somewhere clean.
Certain path words look risky. Paths containing words like login, token, checkout, account, admin, or wp-admin get treated with more suspicion. Keep those out of canonical marketing URLs.

Don't let robots.txt silently block Bravebot

Brave's own Search Crawler help page confirms it directly: "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," and "if a domain or page is not crawlable by Googlebot, then Brave Search's bot will not crawl it either." In practice that means a common security pattern - "block any bot we don't explicitly recognize" in robots.txt, or a WAF/CDN rule that only allowlists named crawlers - can silently exclude Brave along with every scraper it was meant to stop. There's no error message; the page simply never gets fetched. Check your robots.txt for a catch-all Disallow and check server or CDN-level bot rules (Cloudflare and similar WAFs are common culprits) before assuming a discovery or ranking problem is about content quality.

Expect volatility, not stability

Brave's index is dramatically smaller than Google's and appears to weight recent signals heavily - Brave itself describes the underlying data as unlinkable to any user, device, or session, which is a different design goal from stability. In practice, several SEOs who track Brave closely report a recognizable pattern: a page gets picked up, ranks well for a few weeks, then drops off just as fast, sometimes cycling back later. Brave hasn't published the exact mechanics of this, so treat it as an observed pattern rather than a documented one - but it's consistent with how a smaller, freshness-weighted index tends to behave. Don't react to a Brave ranking swing the way you'd react to a Google core update. Treat gains there as a bonus on top of real traffic, not a metric to defend week to week.

Should you use the Brave browser yourself?

It's a modest, genuinely low-cost tactic worth considering, just not a full-time strategy. Downloading Brave and opting into the Web Discovery Project sends anonymous browsing and search signals that help build the index - and visiting your own published pages while opted in can be one of the up-to-20 signals a new page needs, or the single signal that triggers the Query Channel if you search a query the page already ranks for elsewhere. It won't move the needle on its own, and it's not a substitute for real visitors, but there's no real downside to running it either.

Why this also decides whether Claude cites you

Anthropic hasn't confirmed the relationship in a product announcement, but its own Trust Center subprocessor disclosures name Brave Search, and two independent studies back it up. Profound's original analysis (March 2025) found an 86.7% overlap between Claude's citations and Brave's top results, statistically far beyond coincidence (p < 0.0001). A larger follow-up MERJ study covering roughly 35,000 Claude citations across 400 queries (July 2026) landed on a near-identical 79.2% of the URLs Claude cites sitting in Brave's top 10 for the matching query, versus just 34% for Google's top 10. Coverage from Search Engine Land adds that Claude doesn't appear to re-rank Brave's results - it uses them close to as-is.

Practically, that means everything above - crawlable by Brave, eligible for double-fetch, actually indexed, and ranking - is a more direct lever for Claude visibility than anything aimed at Google alone. Optimize only for Google and you're optimizing for the smaller of the two overlaps.

The checklist

Audit robots.txt and any WAF/bot rules for a catch-all block that could be silently excluding Bravebot.
Confirm core content is server-rendered (not JS-only), avoid redirect chains, and keep pages well under the 10-second / 2MB double-fetch limits.
Use a real <link rel="canonical"> tag, not just a header, and keep canonical URLs free of unnecessary query parameters.
Build or confirm real ranking visibility on Google, Bing, or DuckDuckGo. That's the fast Query Channel door into Brave.
If there's no existing ranking to lean on, focus on genuine promotion that could reach Brave-browser users - real audience-building, not submission forms.
Use Submit URL only after a real fix, to force a fresh look. Not as a discovery mechanism.
Don't panic over short-term Brave ranking swings. Treat sustained visibility as the signal, not week-to-week noise.
Optionally, run Brave with Web Discovery Project enabled yourself. Low cost, and it makes you one of your own signals.

Next playbook

GSC Wizard doesn't track Brave - no third-party console does yet - but the crawlability issues that silently block Bravebot usually affect real users and other bots too. Start with diagnosing technical indexing issues → on your own site, which covers the robots.txt and canonical problems that matter for every engine, not just Google.

How to rank in Brave Search (and get cited by Claude)