Your scraper is becoming a data broker: reading Firecrawl's Alexandria as a buyer

Firecrawl Alexandria is Firecrawl's new single-interface layer that puts official licensed data providers, Firecrawl's own pre-built indexes, and the live web behind one query. It launched on 22 September 2026 alongside a $75M Series B led by Smash Capital, a round reported the same day by SiliconANGLE. The money is the headline. The shift underneath it is the part that should change how you evaluate the vendor.

For most of the last two years, buying a scraping or extraction API meant buying a fetcher: you handed it a URL or a query, it went to the live web, and it returned the page. Alexandria is a different product wearing the same brand. It is a web data index for AI agents that Firecrawl has already crawled, partly licensed, and now sells access to. The vendor is moving from "we go get the page you asked for" to "we already hold the corpus, ask us what is in it." That is a data-broker posture, and it carries buying questions a fetcher never raised.

What Alexandria actually is

In Firecrawl's own words, Alexandria unifies "official data providers, custom connectors and Firecrawl's own indexes together with the live web, so your AI agent has one way to find a source, see what it holds and pull from it." An agent reaches it through the Firecrawl API, an MCP server, or the CLI.

Three of Firecrawl's own indexes ship at launch: a Research Index of tens of millions of scientific paper abstracts, a Developer Index of tens of millions of primary sources across documentation, READMEs, issues, and merged pull requests, and a Government Index of laws, regulations, and ordinances. Alongside those, Firecrawl says it already pays official providers under individual agreements, "most notably Wikimedia Enterprise," with millions of requests for Wikipedia data flowing through it each month. So the library is part first-party crawl, part licensed feed, behind one interface.

From point-it-at-a-URL to query-a-corpus

The distinction that matters is not new endpoints. It is a change in what you are actually buying.

A fetcher answers a request: get this page, run this search, extract these fields. An index answers a different question: what do you already hold about this topic, and how do I pull it. The first is a live operation against the open web. The second is a query against a corpus the vendor assembled ahead of time and chose the boundaries of. Once the vendor holds the corpus, the freshness, the coverage, and the license terms are decisions it made before you showed up, not properties of a page you pointed at.

This is a different move from the one we described when the web data API became a platform, not a product. That shift was about endpoints merging onto one credit meter: search, scrape, crawl, extract, and a browser sold as a bundle. Alexandria adds a layer beneath the endpoints. Finding and fetching already lived in one product. What is new is that some of what you fetch never touches the live web at request time, because Firecrawl indexed it in advance. The guide to search, crawl and extract APIs still describes the live primitives. Alexandria sits behind them, as a store the primitives can read from instead of the open web.

What changes for the buyer

An index you query is not a page you fetched, and the difference shows up in four places.

Freshness: snapshot versus live fetch

A live fetch is current by definition; it reflects the page at the moment of the request. An index reflects the last time the vendor crawled it. That gap is fine, or even preferable, for slow-moving material, and Firecrawl chose its launch verticals accordingly. Scientific abstracts, documentation, and statutes do not change hourly, so a periodically refreshed index of them is close enough for most uses and cheaper than re-fetching. The live web is still available through the same interface when you need it.

The risk is that the snapshot boundary is invisible at call time. If your agent queries the Government Index for a regulation amended last week, you need to know whether you are reading the current text or a stale copy, and nothing in a returned passage tells you that on its own. The practical question to put to any indexed source is simple: when was this last crawled, and is that timestamp exposed to my agent. If the answer is no, treat the index as reference-grade, not current-state.

Provenance and license posture

Alexandria mixes three kinds of data with three different legal footings: content Firecrawl crawled itself, content it licenses from providers like Wikimedia Enterprise, and, eventually, content that individuals and organizations contribute. From inside a single query response, those look identical. They are not.

For a production system, the license under which a passage arrived affects what you can do with it downstream, and a blended library makes that harder to reason about than a fetch you initiated against a known source. This is the same concern behind field-level provenance: if you cannot trace a value back to where it came from, you cannot defend it. Ask whether Alexandria labels each result with its source and license, or whether provenance collapses into a generic "from Alexandria." The licensed portion is the reassuring part. The self-crawled portion inherits whatever access rules the origin site set, which is the whole reason pay per crawl and access licensing became live issues this year.

Reading the 21% claim

Firecrawl reports that "across the verticals we tested, AI agents using Alexandria scored 21% higher on answer quality than those using built-in web tools," holding models and prompts constant across 845 tasks with a blind AI judge. That is a first-party benchmark from the vendor selling the product, and it should be read as a claim, not a measurement you can bank.

The number is plausible and the method is more disclosed than most vendor benchmarks, which is worth crediting. But "answer quality," the identity of the "built-in web tools" it beat, and the vertical mix behind the average are all unspecified, and a 21% lift concentrated in the verticals Firecrawl indexed says little about your workload if your workload looks different. The only benchmark that settles a buying decision is the one you run. Take a sample of your real queries, score Alexandria against your current retrieval path with your own judge, and read the delta on your traffic. Our guide to evaluate a search API on your own data lays out the harness. A vendor's 21% is a reason to test, not a result to adopt.

Index-curation lock-in

When you fetch the live web, coverage is the web. When you query an index, coverage is whatever the vendor decided to crawl, license, and keep. What is in and out of Alexandria is now an editorial decision made by Firecrawl, and your agent's answers inherit it. A topic the Research Index skipped is not thin in your results; it is absent, and absence is harder to notice than a bad answer.

That is a real dependency, distinct from the API lock-in of endpoints and schemas. You are binding your product's knowledge coverage to one vendor's curation roadmap. It is a defensible trade for the convenience, but it belongs in the build versus buy column explicitly, not by default. Keep a way to ask the live web directly for the coverage the index does not carry.

The licensing marketplace is the more interesting half

The indexes are the launch. The plan underneath them is the part worth watching. Firecrawl says it intends to pay individuals, publishers, and organizations when agents use their knowledge, through a self-service system that extends the direct deals it already runs with providers like Wikimedia Enterprise.

If that ships and works, it puts Firecrawl in the position of a clearing house between people who hold data and agents that want it, which is a more durable business than crawling alone. It also lines up with the direction access has been moving all year, toward metered, paid, and consented data rather than open scraping.

The caution is that none of the terms exist yet. No payout rates, no revenue split, no contributor volume have been disclosed. A marketplace is only as real as its economics, and until a contributor can see what a unit of demand pays, this is a stated intention, not a working system. Watch for the rate card. That is when the marketplace becomes something you can evaluate rather than a slide.

What this means if you build on web data

The unit of sale is shifting from a fetch to a corpus. When your vendor holds a pre-built, partly-licensed index, you are buying its coverage and freshness decisions, not just its ability to retrieve a page. Evaluate the library, not only the fetcher.

Provenance stops being automatic. A blended index of self-crawled, licensed, and contributed data returns results that look uniform and are not. Require per-result source and license labels before you route indexed answers into production.

Freshness is now a property you have to ask about. A live fetch is current; an indexed passage is as old as the last crawl. Make the crawl timestamp visible to your agent, or scope indexed sources to material that changes slowly.

Test the lift on your own traffic. A 21% first-party benchmark is a reason to run your own evaluation, not a result to inherit. Score the index against your current retrieval path on your real queries before you commit, and keep a direct line to the live web for the coverage curation leaves out.