Summary: Cloudflare shipped AI Search improvements on August 6, 2026 so agents can query a managed index over a file or website without assembling separate crawling, embedding, storage, and reranking primitives. The update adds namespace-wide /search and /mcp endpoints, custom domains, Cloudflare Access support, EmDash integration, hybrid search, and a pricing preview with free embedding and reranking for select models. Site indexing currently requires the site to be a zone on the customer’s Cloudflare account.
The Update: AI Search Just Got Easier
On August 6, 2026, Cloudflare shipped a batch of developer experience improvements to AI Search. What the work is after is simple enough: hand your agents a search engine of their own, one that finds the data it needs without effort, so the answers an agent produces — for itself and for its humans — come out better. Leaning on out-of-date training data or dragging an awkward web-scraping pipeline along is what it replaces.
Getting to the same place used to mean assembling the Cloudflare primitives by hand — Workers AI, AI Gateway, Vectorize, R2, Browser Run. AI Search now does that work automatically, and does it better, which leaves you with the data and the queries.
The release brings a set of features worth knowing:
- Build an index over a collection of data: Whatever the shape of the data, structured or not, it can become a search index your agent builds against, from a single file up to a whole website. As things stand the site has to be a zone on your Cloudflare account; Cloudflare says further ways to prove ownership are on the way.
- Sites can come without a sitemap: The website integration used to demand one. Choose the “Discover” parsing option and a sitemap-less site can be brought in anyway.
- One public endpoint can search a whole namespace: Switch public URLs on for a namespace and a
/searchand/mcpendpoint appear, covering several instances or websites in one request with no authentication involved — handy when customers need to be handed a link. - Your own domain, your own access rules: Domains you own can sit in front of your public URLs, so the
/searchand/mcpendpoints carry your branding (e.g.,search.example.com/mcp). Layering Cloudflare Access on top turns a search instance private instead. - Semantic search for EmDash sites, plugin included: Where a site is built on EmDash — Cloudflare’s open-source CMS — semantic search over your content arrives with the AI Search plugin.
- Preview the new pricing model: The pricing is meant to stay predictable and grow alongside you: pick select models from the Workers AI catalog and embedding and reranking cost nothing.
/crawl from Browser Run is what runs underneath, yet AI Search does not blend into the background: it announces itself under a bot identity of its own, Cloudflare-AI-Search. As with Browser Run, robots.txt gets honored, the user agent is immutable and public, and whatever bot controls a site sets are respected.
Under the Hood: From Index to Public Endpoint
Crawling, ingestion, embedding, retrieval — that is the load AI Search carries. Hand it one site or a group of them and the rest becomes its problem. An instance comes up with a single command, and where no sitemap exists you add --parse-type discover so pages get found by link-following, with /crawl from Browser Run doing the work:
npx wrangler ai-search create cloudflare-community \
--namespace dev-stack \
--source https://community.cloudflare.com \
--type web-crawler \
--parse-type discoverWith instances in hand, the next move is folding them into one search that spans several surfaces. That can go two ways:
Option A: inside a Worker (the route Cloudflare took for Cloudflare Dev Stack MCP)
Bind the namespace to a Worker and a remote MCP server is the result; one multi-instance call then covers every instance. Take this path when search has to live inside an app or MCP server you already run. The binding lives in wrangler.jsonc:
{
"ai_search_namespaces": [
{ "binding": "AI_SEARCH", "namespace": "cloudflare-stack" }
]
}From there one tool issues a single call that fans out over whichever instances you list:
// One tool, one call that searches every surface in the namespace at once.
context.registerTool(
'search_dev_stack',
{
description: 'Search current docs across the Cloudflare stack.',
inputSchema: z.object({ query: z.string() }),
},
async ({ query }) => {
const res = await context.env.AI_SEARCH.search({
query,
ai_search_options: {
instance_ids: ['developers-cloudflare-com', 'astro', /* ...every surface */],
retrieval: { max_num_results: 10 },
reranking: { enabled: true },
},
})
// res.chunks come back cited and tagged with the instance they came from.
return { content: [{ type: 'text', text: format(res.chunks) }] }
}
)Option B: switch on public endpoints (no code)
Should writing a Worker not appeal, switch public URLs on for the namespace instead. /search and /mcp are there at once, querying every instance, with no auth to arrange and nothing to deploy. Which one fits where? The Worker suits folding search into an app or MCP server you already have; the public endpoint suits wanting a shareable search endpoint in one click.
In Practice: The Cloudflare Dev Stack MCP
Cloudflare puts AI Search to work in several places, and one of them is the new Cloudflare Dev Stack MCP, ready to try today in the AI Playground. Through it, coding agents get docs that are current and cited from across the Cloudflare developer ecosystem, so what they build on is the latest features and fixes rather than stale training data.
The build went like this:
- One index per surface: Every Cloudflare-owned surface got an AI Search instance of its own: Docs, Blog, API Docs, Community, Astro, Vite, Vitest, Hono, Replicate, OpenNext. Different domains, one owner — and since the website data belongs to Cloudflare, the whole lot can be treated as a single set and ingested in the same fashion.
- Fold them into a single search: Option A (a Worker) produced a remote MCP server, and one multi-instance call spans all 10 instances. It ships as a tool beside the other Cloudflare tools agents already hook up.
- Give it a brand and a lock: Public endpoints arrive with a default public URL, though a domain you own can sit over it so the endpoint carries your brand (e.g.,
search.example.com/mcp). Where the search should stay private, Cloudflare Access goes in front of the domain. A login is then required, so only people (or agents) holding permission can query it.
Dropping the MCP URL into your MCP configuration is all it takes to point your agent of choice at the Dev Stack MCP:
{
"mcpServers": {
"dev-stack": { "url": "https://stack.mcp.cloudflare.com/mcp" }
}
}The habit it replaces — searching the web, then fetching whole pages — is slow, heavy on tokens, and all too often ends up on a stale or wrong source.
Search on Cloudflare’s own Blog, Developer Docs, and Cloudflare.com runs on AI Search too. Hybrid search is what all of them use, semantic and keyword combined in a single query, which answers open-ended “what does this do” questions and literal name-or-keyword lookups alike. EmDash is where the Blog now lives, rebuilt on it recently, and that search runs on the EmDash AI Search integration today. Your own EmDash site can take the same integration and get the identical search over your content, with nothing extra to build.
Pricing Preview: Predictable Bills, Free Embedding and Reranking
Nothing is charged while AI Search stays in beta and billing has not been switched on; when it is, Cloudflare will email well ahead of time. Ahead of general availability, here is what pricing looks like, covering ingestion, storage, and queries, and separately embedding and reranking — with the caveat that preview prices may change before billing starts:
| Preview usage price | Free monthly allotment (all Workers plans) | |
|---|---|---|
| Ingestion | ||
| Base Ingestion | $0.75 / 1M tokens | 5M tokens † |
| Image processing (add-on) | +$0.50 / 1M tokens | 5M tokens † |
| Storage | ||
| Stored data | $2.00 / GB-month | 10 GB |
| Query | ||
| Semantic (hybrid and vector search) | $0.75 / 1k queries | 2,000 queries ‡ |
| Full-text | $0.10 / 1k queries | 2,000 queries ‡ |
| Embedding and Reranking | ||
| Ingestion and query | Free with select Workers AI models; third-party billed separately | N/A |
† A single pool of 5M ingestion tokens per month, covering any file type currently supported (e.g., text, images). ‡ A single pool of 2,000 queries per month, shared across both query types.
Text into the vectors that search matches against: that is embedding. Most relevant first: that is reranking, which reorders the results. Neither costs anything under AI Search defaults, or with select models from the Workers AI catalog — which means the models doing the indexing, and every search after it, never turn into a cost line. Two optional steps, answer generation and query rewriting, run on whichever model you pick, billed as Workers AI usage, or covered by AI Gateway credits with any model/provider.
Sample bill time, on the Workers Paid plan: an instance over a 20,000-document data source (about 20M tokens of text) with 1,000 images (call each one about 1,000 tokens), serving 30,000 semantic queries in a month, with AI Search’s default embedding and reranking model doing the work. Chunking during ingestion carries roughly 10% overlap, which is the source of the × 1.1 below:
| Line item | Usage | Price | This month |
|---|---|---|---|
| Base ingestion | (20M tokens of text + 1M tokens of images) × 1.1 - 5M free = 18.1M tokens | $0.75 / 1M tokens | $13.58 |
| Image add-on | 1M tokens of images × 1.1 = 1.1M tokens | $0.50 / 1M tokens | $0.55 |
| Storage | ~1.2 GB (within 10 GB free) | $2 / GB-mo | $0 |
| Queries (semantic) | 30,000 - 2,000 free = 28K | $0.75 / 1k | $21.00 |
| Embedding (Workers AI) | Usage included with selected Workers AI model | $0 | $0 |
| Reranking (Workers AI) | Usage included with selected Workers AI model | $0 | $0 |
| Total | ~$35 |
Each image lands in base ingestion and triggers the image add-on as well. The storage estimate rests on about 10 KB per document and 1 MB per image. Indexing being mostly a one-time expense, later months are query-dominated and settle closer to $21.
Limits Worth Knowing
Capable as it is, AI Search comes with limits worth weighing:
- Website ownership: Indexing currently requires the website to be a zone on your Cloudflare account. Further ways to verify ownership are coming soon; until then, non-Cloudflare users are boxed out.
- Pricing subject to change: Preview pricing is not final and may shift before billing begins. Cloudflare will give notice before billing starts.
- Bot policy compliance: Identification comes via
Cloudflare-AI-Search, with robots.txt and bot controls respected — good news for content owners, but it also means your site has to permit crawling. - Beta status: Beta is where AI Search still sits, so features and pricing may yet move.
The Takeaway: A Managed Search Engine for Your Agents
The pitch is a managed service that hands your agents a search engine over your own data, minus the job of stitching primitives together. For product builders, the benefits that matter:
- Lower integration cost: Crawling, embedding, vector storage, and reranking are handled for you. An index comes from one command, fit for prototyping or production alike.
- Native MCP support: Agents query over the standard protocol through the
/mcpendpoint, which sits well with today’s coding agent ecosystem. - Predictable pricing: Default models make embedding and reranking free, which simplifies budget planning, all the more so when usage swings.
Start by pointing AI Search at your site and switching hybrid search on so semantic and keyword matching both apply; what you end up with is a search engine over your own data, ready for your agents. One command spins it up:
npx wrangler ai-search create my-search \
--namespace my-namespace \
--source https://my-website.com \
--type web-crawler \
--hybrid-searchQuery it from there, hang it off an agent through /mcp, or give a public /search endpoint a custom domain of your own and pass it to your users. The AI Search docs have more.