How to Use OpenClaw Firecrawl

Firecrawl gives OpenClaw a stronger extraction path for pages that plain HTTP fetches struggle with. The docs describe three roles: Firecrawl can power generic web_search, expose explicit plugin tools called firecrawl_search and firecrawl_scrape, and act as a fallback extractor for web_fetch. That makes it useful for JS-heavy pages, blocked pages, and research flows that need cleaner page content.

30-second answer

Create a Firecrawl API key, store it as FIRECRAWL_API_KEY or in plugin config, then choose Firecrawl as the web search provider or enable it for web_fetch fallback. Use generic web_search for simple queries, firecrawl_search for Firecrawl-specific controls, and firecrawl_scrape for difficult URLs.

Search configuration

Firecrawl search config lives under plugins.entries.firecrawl.config.webSearch. The docs show baseUrl as https://api.firecrawl.dev and note that base URL overrides must stay on that host. Choosing Firecrawl during onboarding or openclaw configure --section web enables the bundled plugin automatically. Generic web_search supports query and count through this provider.

Scrape and fallback

For extraction, configure plugins.entries.firecrawl.config.webFetch with apiKey, baseUrl, onlyMainContent, maxAgeMs, and timeoutSeconds. Firecrawl fallback attempts run only when a key is available. web_fetch tries local Readability first, Firecrawl if selected or auto-detected, then basic HTML cleanup as a final fallback.

Tool choice

Use firecrawl_search when you need options like sources, categories, scraping results, or timeout control. Use firecrawl_scrape for a specific URL with extractMode, maxChars, onlyMainContent, maxAgeMs, proxy, storeInCache, and timeoutSeconds. The docs say OpenClaw uses proxy auto and storeInCache true for Firecrawl requests.

Cost and reliability

Firecrawl’s proxy auto mode can retry with stealth proxies if a basic attempt fails, which may use more credits. Use it where content quality matters. For normal pages, local Readability or a cheaper search provider may be enough.

Playbook angle

The Playbook pattern is to keep Firecrawl as the heavy extractor, not the default hammer for every page. Save it for pages where better extraction changes the answer.

Runbook checklist

Before you automate this, run one small acceptance test with harmless input. Confirm the tool is available to the right agent, the credential is loaded from config or environment, the output shape matches the workflow, and the failure message is understandable to a tired operator. If the feature touches money, public channels, logged-in browsers, host commands, or customer data, put a review step before the side effect. If it only reads data, still record the source and timestamp so future sessions do not treat stale context as fresh truth. Keep the first version narrow, then expand once the logs show the agent is choosing the right tool for the right reason. When the docs are incomplete, prefer a conservative sentence over a clever invented shortcut that future agents cannot reliably verify. Add one monitoring habit as well: after the first real run, check the transcript or logs for missing prerequisites, broad prompts, stale assumptions, and accidental side effects. Tighten the instruction while the failure is fresh. The best OpenClaw workflows improve in small, documented passes instead of one giant rewrite after something breaks in public. For SEO pages, that same discipline matters: do not promise hidden capabilities, paid-provider limits, or setup shortcuts unless the current docs say so. Trust compounds when the guide is accurate even in the boring operational edge cases that matter during real maintenance windows.

Operator note

How to Use OpenClaw Firecrawl works best when it is written into a small runbook instead of treated as a magic switch. Record who owns the workflow, which config keys are allowed, which credentials are required, what the agent may do without approval, and what counts as a failure. OpenClaw gives agents broad tools, but the reliable version is boring: one source of truth, one verification step, and one rollback path when a provider or channel behaves differently than expected.