I Wrapped Firecrawl in Nine Apify Actors. The Runs Lied. The Users Didn't.

I did not plan nine Firecrawl actors either

Firecrawl does one thing I kept needing: hand it a URL and get back clean markdown, even when the site is a pile of JavaScript. So every time a client question ended in "can we pull that off their website," I wrapped another Firecrawl endpoint in an Apify actor and published it. Between December 2025 and January 2026 that happened nine times. A crawler, a site mapper, a search actor, a second search actor (do not ask), a change monitor, a competitive intel actor, a lead enricher, an autonomous agent, and a Pro actor that exposes every knob Firecrawl has.

Last week I wrote up what people run across all 283 of my actors. This is the zoomed-in version, one tool, nine wrappers, pulled from Apify's API this morning. The headline number is flattering. The real number is more useful.

6,307 runs. Then I counted the people.

All nine together have 6,307 runs. Nice number. I almost put it in the title. Then I pulled the user counts, and the run count started looking like a vanity metric with a crawler attached.

The website crawler: 1,589 runs, 66 users. The lead enricher, fire-enrich: 1,471 runs, 5 users. The agent: 878 runs, 117 users. Competitive intel: 749 runs, 2 users. The change monitor: 446 runs, 11 users. The Pro actor: 348 runs, 31 users. The site mapper: 297 runs, 6 users. The two search actors: 277 runs with 9 users and 252 runs with 6.

Add up the per-actor user counts and you get 253, which double counts anyone who tried more than one. In the last 90 days, 39. In the last 30 days, 13. In the last seven, 5.

And here is the tell that a run is not a person. fire-enrich ran yesterday. Apify says it has had zero users in the last 90 days. Something ran it. Maybe my own pipeline, maybe a schedule somebody forgot. Not a new customer. Runs count every click of the Run button, from anyone and anything. Users do not. If you publish actors, judge them by users. Runs will flatter you to death.

The agent got the crowd. The crawler got the job.

The actor with the most users is the agent: 117 people, 878 runs. It is the exciting one. Describe what you want in plain English and it goes and gets it. Twelve people tried it in the last 90 days. Zero in the last 30. That is a demo curve. People show up, ask it something clever, and leave.

The actor with the most runs is the plain website crawler: 1,589 runs from 66 users. Give it a domain, get every page back as markdown. No personality, no plain-English goals. Three people used it in the last 30 days, which is more than the agent, the enricher, and both search actors combined. Same lesson as the big fleet. The flashy one gets tried. The boring one gets wired into something.

The Pro actor quietly makes the same point. 31 users, and four of them in the last 30 days, the best recent number of the nine. It is the one that exposes Firecrawl's actual options: actions like click and scroll, screenshots, stealth mode, caching. The people who come back are the people who already know what they want from a page.

The heaviest Firecrawl user I have is my own app

The actors are the public face. The private one is the Local Howl app, where 45 files in the codebase reference Firecrawl. It is not a feature. It is plumbing, and here is where the pipes go.

Onboarding. When a new client signs on, Firecrawl's branding format reads their website and comes back with the color scheme, primary and accent colors, heading and body fonts, and the logo. That pre-fills the brand kit, which then feeds landing pages and every Google Business Profile post we generate. Same pass, a separate route harvests the photos off their site so the post generator has real images to work with instead of stock.

AI readiness. Our check for whether a site is readable by ChatGPT and Perplexity fetches pages through Firecrawl first and only falls back to a plain fetch if it has to. That order matters. A JavaScript-heavy site can look empty to a plain fetch, and an empty page is not a ranking problem, it is a reading problem.

Monitoring. On the 1st of every month a scheduled job snapshots competitor homepages through Firecrawl and diffs them against last month, so a new service or a new offer shows up as an alert instead of a surprise. A separate check watches the citation listings we build for content changes.

Design. Our page builder crawls a client's existing site to pull design tokens and the literal navigation markup, so a new landing page looks like it belongs to the business. And when a client's logo URL 404s, a rescrape route goes back for it, with an optional vision fallback that costs about a cent a call.

None of that is glamorous. All of it runs every week. Which is exactly the pattern the public numbers showed.

If you are about to build on Firecrawl

One. Start with scrape and crawl, not the agent. Markdown out of a single URL, then a whole domain, solves more real problems than the clever stuff. Add map when you need the URL list first, and save the agent for questions where you genuinely do not know which page has the answer.

Two. Always keep a fallback. Every Firecrawl call in my app has a plan B, a plain fetch, a cached copy, or a polite error. Any web data source gets rate limited eventually. Design for the day it does.

Three. Ask for the format you will actually store. The branding format saved me from writing a CSS parser. Structured JSON saves you from parsing markdown with regex at 2 AM. Pick the output shape before you pick the endpoint.

Four. Measure users, not runs. I said it above and I will say it again because it took me nine actors to learn it.

Try it before you wire it in

Firecrawl has a free tier of 1,000 credits a month with no card, which is roughly a thousand pages, and it now does keyless access to the same free monthly credits, so you can kick the tires before you even create a key. If you sign up through my link, new users get 10 percent off their first purchase. The company also just raised a $75M Series B and launched Alexandria, so it is not going anywhere, which is the first thing I check before I build anything on top of somebody else's API.

If you would rather not write the wrapper yourself, the boring one is on the Store: Firecrawl Website Crawler, and the rest of the fleet is on my Apify profile.

Nobody wants an AI agent. They want the page as text.

Nine actors taught me the same thing 283 did, faster. The agent is how people find you. The crawler is what they keep. And the most honest number on any dashboard is how many humans came back this month.

Mine is 13. I will take it. It is 13 more than the robot running fire-enrich every day.