How to Use Firecrawl to Get More Leads (GTM Playbook)

Use Firecrawl to get more leads by making the research step faster, not by pretending it is an email finder. Map a domain you already care about, scrape the pricing, about, customers, and contact URLs, and hand the people to an enrichment tool. I ran that pattern on 9 November 2026. The map and the scrapes worked. A loose web search did not produce accounts. A contact page produced CTAs, not inboxes.

Last updated - November 2026

I am Austin Heaton. Most of the pipeline work I touch is fintech and B2B SaaS. The leads that turn into calls come from a page that answers the buyer's question, or from a note that proves you read the account. Both of those start with the public web. This is the playbook I would rerun, with the outputs from the session, including the miss.

Credit rates used in the budgets below are from Firecrawl's pricing page, read on 9 November 2026, as listed on the Firecrawl pricing page, November 2026. The full plan grid, rollover rules, and what I will not claim is the Firecrawl review. The enrichment handoff is Loopster or Loopster vs Clay. Where this research should end up if the goal is an assistant citation, not only an outbound email, is answer engine optimization. Channel context for the rest of the stack is the B2B lead channel breakdown.

Key Takeaways

• Firecrawl pulls public pages. It is not a contact database. The Stripe contact-sales extract named the company and the CTAs and returned no email. Expect that.
• The first call on a known account is map, with a keyword hint. Ramp returned 4,088 URLs in about twelve seconds, including pricing and about. Then scrape ten pages, not four thousand.
• Pricing intel is the scrape that paid for itself. Stripe's pricing page was about two seconds and 1,532 lines, with the Standard versus Custom split intact. Ramp pricing was 688 lines. A homepage scrape (Rise, 626 lines) was enough for positioning language, not for a contact.
• Search is a topic tool until the query is tight. "B2B SaaS fintech pricing page contact sales", limited to five results, returned how-to articles. It did not return a vendor list.
• A small weekly budget, using only the published rates, is on the order of a few dozen credits: one map, ten scrapes, one search, and a handful of monitor checks. The batch I actually ran moved the balance by about eleven credits, from 81,541 remaining to 81,530.

What Firecrawl Can and Cannot Do for Leads

Can: turn a URL into markdown an agent can read, list the URLs on a domain, watch a page you name, and collect sources for a page you are about to publish. Cannot: look up a person by title, verify a work email, or tell you the phone number that was never on the site. If your definition of a lead is a name plus a way to reach them, Firecrawl is step one of three. Step two is enrichment. Step three is a human deciding the note is true.

I keep that order because the failure mode is confident nonsense. A model that "finds" an email inside a scrape that had no email is worse than a missing field. The Stripe extract is the example I want on the wall. Company, CTA, no inbox. Stop.

Setup: API Key, CLI, or MCP

You need a key. The pricing page points agents at an onboarding skill, and it says a free account is 1,000 credits a month with no card. I ran the official CLI, version 1.23.3, with a key that was already authenticated. Status at the start: 81,541 of 100,000 credits remaining, concurrency 0/50. I am not telling you to paste a key into a chat log or a commit. Put it in the environment the CLI expects, and treat every Bot that can see that environment as able to spend the balance.

Three ways to call the same API, and I would pick by who is driving:

• CLI, when you are at a terminal or a script and you want a file of markdown. This is what I used.
• MCP, when the caller is an agent that should ask for a scrape inside a larger job. Same credits. The win is that the page never has to be copy-pasted into the prompt.
• REST, when a workflow tool you already run should fetch the page on a schedule. Then you own retries and storage.

I did not compare latency across those three. The timings below are CLI timings on that day. Your network will differ. The shape of the output should not.

Workflow 1: Account Mapping for Outbound

Start with domains, not keywords. A list of fifty accounts from the CRM, from a conference, or from deals you lost is the input. For each domain:

1. Map the domain and pass a hint such as pricing, contact, about, team, careers, customers.
2. Keep the URLs that match those words. Drop the blog archive, the legal pages, and the localized duplicates unless the locale is the one you sell to.
3. Scrape the keepers with main content only. Save the markdown next to the account, with the date.
4. Write the outbound hook from a sentence that is actually in the file: a plan name, a customer logo section, a hiring page, a region you serve. If the sentence is not in the file, it does not go in the email.

What happened when I did the middle of that on Ramp. The map call finished in about twelve seconds. The payload was 4,088 URLs. About 107 matched the hint. The ones I cared about were there immediately: the pricing URL and the about URL, plus regional pricing paths. That is the demo. A site with four thousand URLs is not a site you scrape end to end for a first-touch email. It is a site you index, then you pick.

Example of a keeper list I would hand a rep, built only from what that map made obvious:

• Pricing, because the package names are the hook.
• About, because the one-sentence description should match the words the rep uses.
• Careers, if it appeared, because a relevant open role is a better trigger than a compliment about the homepage.
• Customers or stories, if the URL is obviously that, because a shared customer is a reason to write. I am not claiming the Ramp map's 107 hits were all of those types. I am claiming pricing and about were in the set, and that is enough to start.

Credit shape, from the published rates, not from a second test: one map is one credit. Ten scrapes are ten credits if you stay on the base rate and skip JSON. Fifty accounts, mapped and then scraped on five URLs each, is 50 plus 250, so 300 credits, before a single retry. That fits a free month only if you cut the URL list. It fits Hobby. It is a rounding error on Standard. Retries and 404s add credits when the error page is still returned. The pricing FAQ is explicit that a 403 or 404 which comes back to you costs one credit, and a scrape with no result does not.

Workflow 2: Pricing and Positioning Intel

This is the workflow I trust most, because I watched it work.

Stripe pricing, main content only, about two seconds, 1,532 lines. The markdown kept the split a seller needs: a Standard offer shown as 2.9% + 30¢, and a Custom offer that pushes contact sales. I would not paste the fee into a prospect email without opening the live page the same day. I would paste it into an internal battlecard with the URL and the date, and I would refresh it on a schedule. The scrape's job is to make that refresh boring.

Ramp pricing, 688 lines, same outcome: a page a human can skim and an agent can quote from. Rise's homepage, 626 lines, was the positioning version of the same test. You get the language the company uses about itself. You do not get a buying committee.

How I turn that into a lead, without inflating it. The outbound line is allowed to say what the page says. "You split Standard and Custom, and Custom is a sales conversation" is a Stripe-shaped observation from the scrape. It is a relevant opener only if you sell something to companies who live with that split. If you do not, the scrape still helped you disqualify the account in two seconds. Disqualification is a lead-gen result. It saves the call you should not have booked.

JSON extracts are optional here. I used a query extract on Stripe's contact-sales URL because I wanted fields: company, emails if any, and the CTA. Fields came back. Emails did not. The extract cost more than a plain scrape. My rule after that test: scrape the pricing page and read it. Spend the JSON premium on a page where you have already named the fields, and only if you will store them. A one-off "any emails?" question is cheaper to answer by reading the markdown.

If the pricing page and the page you want an assistant to cite are the same URL, Book a Call and bring both. Pricing depends on scope. The scrape is the easy half.

Workflow 3: Trigger Monitoring

A trigger is a change you would mention in the first line. Pricing moved. A new product tier appeared. A role opened that matches what you sell. Firecrawl's pricing page describes Monitor as one credit per page per check. I did not create one. I am describing the setup I would use, and marking the untested part as untested.

1. Pick five URLs you already scraped and already use. Not the homepage of every target.
2. Check them weekly, not hourly. Five pages, four weeks, one credit each check: twenty credits a month. That is arithmetic on the published rate.
3. Diff the markdown against last week's file. A human, or a very constrained prompt, writes the sentence only if a heading or a number changed.
4. If nothing changed, send nothing. A "just circling back" email that cites a page which did not change is how this workflow gets a bad name.

Careers pages are the tempting over-monitor. They change for reasons that have nothing to do with you. I would monitor one role family, on accounts already in a live conversation, and I would ignore the rest. Interact, the browser-minute endpoint, is what I would reach for if a pricing page only renders inside a client-side app. I did not need it for Stripe or Ramp. I am not telling you those two sites prove every app will scrape clean.

Workflow 4: Research That Feeds Pages People Can Cite

Outbound is one output. The other is a page on your own site that answers the question a buyer asks an assistant. The scrape is the source note. The page is the asset. I do not let the same agent publish the page unattended. The sequence I want is:

1. Search only after you know the question. My broad search returned primers on how pricing pages work. That is a reading list for a writer. It is a bad outline for "tools like us." Tighten it to a named product plus the word pricing, or skip search and scrape the URLs you already trust.
2. Scrape the two or three vendor pages the comparison depends on. Keep the date in the draft.
3. Write the table from those files. If a cell is not in the file, the cell says you could not read it. That is the style that survives a reader who clicks.
4. Put a clear next step on the page. A sourced comparison that ends in a fog does not book a call. Neither does a sourced comparison that invents a price.

This is also why I do not use Firecrawl search as the prospecting engine. The five results I got were articles. Articles are inputs to your content. Accounts are inputs to your outbound. Mixing them up is how a content calendar gets filled with pages that never had a buyer, and how a sequence gets filled with URLs that are not vendors.

How to Combine Firecrawl with Enrichment

The handoff is a domain plus a reason, not a guessed email. After workflow 1 you have a short note: what the company says it sells, which pricing motion it uses, which URL proved it, and the date. Enrichment starts there. Loopster, in the test I ran separately, can take a domain and return a company record from its own data at no wallet cost. Clay can take a company and a persona and run a waterfall, on its own meters. I did not run those enrichments inside this Firecrawl session, and I did not paste scraped text into either tool and ask it to hallucinate an address.

A clean record to pass across looks like this, and every line is from the tests or from the absence the tests found:

If the enrichment tool's company record disagrees with the scrape, believe the scrape for what the website says today, and believe neither one for a number you did not check. A homepage and a firmographic database answer different questions. The lead note should say which is which.

Credit Budgeting for a Small GTM Team

Published base rates, applied to a week I would actually run. This is arithmetic, not a second measurement.

• Map 20 accounts: 20 credits.
• Scrape 5 pages on each, no JSON: 100 credits.
• One search while drafting a comparison: 2 credits for up to 10 results.
• Monitor 5 competitor URLs, weekly: about 20 credits in a month, about 5 in a week.

A heavy week of that shape is under 150 credits. The free plan's 1,000 credits cover several of those weeks if you never turn on JSON, never crawl, and never leave an agent in a loop. One JSON extract is 5 credits on the pricing table's scrape-plus-JSON line (1 plus 4). Twenty JSON extracts are 100 credits, still fine. Two hundred, on every page, "just in case," is how Hobby starts to feel small. Interact at 2 credits per browser minute is the other cliff. I did not spend those minutes. I would put a ceiling on them before an agent discovers it likes clicking.

The balance I watched moved by about eleven credits for a much smaller batch: two pricing scrapes, one homepage scrape, one map, one five-result search, one query extract. That lines up with "this is cheap when you stay on the base rate." It does not line up with "crawl the domain." A crawl of Ramp's 4,088 URLs, at one credit a page, is thousands of credits and a lot of pages you will never read. Map was the point.

Rollover, because it changes the plan and not the workflow: Hobby, Standard, and Growth do not keep unused credits. If you burst once a quarter, do not pre-buy a huge month you will not roll. Scale rolls one month. Pay-as-you-go on paid plans adds credits in $5 steps if you turn it on. I would turn it on with a cap, not as an unlimited hose behind an agent.

Mistakes That Waste Credits

• Crawling because map felt incomplete. Sort the map. Scrape twenty URLs. Then decide.
• JSON on every page. Five credits instead of one, and you still have to read it. Use JSON for a schema you named.
• Search with a slogan instead of a site. I did this. I got articles. The credits were small. The wasted afternoon is the real cost, if you then write from the wrong sources.
• Retrying 404s. They can still bill. Fix the URL list.
• Asking the extract for emails the page does not have, then letting a model fill the blank. The blank is the answer.
• Monitoring homepages. They change their marketing without changing the fact you sell against. Monitor the URL whose change would alter the first sentence.
• Leaving pay-as-you-go uncapped on an agent key. The $5 increment is small until a loop is not.

Verdict

Firecrawl gets you more leads when the bottleneck is reading the account, not finding a human's inbox. The workflow that matched the tests is short. Map. Filter. Scrape the money pages. Write only what the markdown supports. Enrich somewhere else. Monitor a few URLs once the first scrape was worth keeping. Search only with a query you have already seen succeed.

I would not roll this out as "the lead gen tool." I would roll it out as the source layer in front of the lead gen tool, and as the source layer in front of any page that quotes a competitor. The review page has the plan math. This page has the order of operations. Austin Heaton still wants a person to read the first ten notes before a sequence sends, because a fast scrape of the wrong URL is still the wrong URL.

What I Could Not Confirm

• Interact, Monitor, and Agent in production. The budgets that mention them are the pricing page plus arithmetic. I did not start those jobs.
• A per-call credit log. The account balance dropped by about eleven credits for the batch described.
• That every JavaScript pricing page will behave like Stripe and Ramp. Those two returned markdown quickly. I am not generalizing past them.
• Email coverage on the open web. One contact page had none. That is a sample of one, and it matches how most B2B sites I open are built. It is not a study.
• Any lift in reply rate. I did not send the outreach. A cleaner note is the claim I will make. A higher reply rate is a measurement I did not take.

Frequently Asked Questions

Can Firecrawl find emails?

Not as a product. It returns the public page. If the page prints an address, the text is in the markdown. On the Stripe contact page I tested, there was no public email, only registration and contact-sales CTAs. Do not invent an address from a scrape. Hand the domain to an enrichment tool when you need a person.

What is the first command for a new account list?

Map the domain, with a hint for pricing, contact, about, team, and careers. Then scrape only the URLs that match. On Ramp, that map returned thousands of URLs in about twelve seconds and still surfaced the pricing and about pages. Mapping first is what keeps you from crawling the whole site.

How do I avoid scraping the whole site?

Use map, filter to a short list, and scrape that list with main content only. Crawl is the call that walks pages and spends a credit each. A four-thousand-URL map is a menu. It is not an instruction to fetch every item.

Is map cheaper than crawl?

On the pricing page I read, map is one credit per call, and crawl is one credit per page at the base rate. One map of a large site is cheaper than crawling it. You still pay for every page you then scrape, and a page that returns an error status can still cost a credit.

How does this help AI search visibility?

Assistants cite pages that answer a specific question and that name a current fact. A scrape gives you the source, the URL, and the date you pulled it, which is the raw material for a comparison or a buyer page. Firecrawl does not get you cited. The page you publish, and whether other sources agree with it, does that. I would rather ship five sourced pages than fifty pages with a guessed fee.

What should I monitor?

A competitor pricing URL, a packaging or docs URL you cite, and a careers URL if hiring is a trigger you actually use. The pricing page lists monitor at one credit per page per check. I did not turn a monitor on in this test. I would not monitor an entire domain.

Do I need the Standard plan?

Not to start. The free monthly allowance is enough to map a handful of domains and scrape the money pages. Standard is the plan I would use once an agent runs this every week and JSON or browser minutes enter the workflow. Hobby sits between them. Read the rollover row. Unused credits on the lower paid plans do not carry.

How does Austin Heaton use this in a GTM stack?

As the research step in front of outreach and in front of pages that should be cited. Map, scrape the short list, write from the markdown, then enrich the people somewhere else. If you want that sequence scoped, pricing depends on scope.

Read next:

• Firecrawl Review: Honest Opinion from a GTM Marketer
• Loopster Review
• Loopster vs Clay
• Best B2B Lead Generation Channels for 2026
• Best Grok Bot Uses for AI Search Visibility

If you want this wired into the pages that should actually book the call, Book a Call and bring the account list or the URL. Pricing depends on scope.