摘要： Firecrawl 的 crawl 端點會沿連結走訪網站，回傳每頁 Markdown 與 metadata；小型任務可同步等待，大任務可用輪詢、串流或 webhook。每頁 crawl 計 1 credit，JSON 抽取每頁加 4 credits，PDF 解析每頁再加 1 credit。文章建議先用 limit 與路徑篩選縮小範圍，確認品質後再放寬。
有些任務打從一開始要的就不只一頁：整套文件站、完整產品目錄、累積多年的部落格歸檔都算在內。當目標是把手上的數千頁整理成乾淨 Markdown、餵進訓練集或知識庫時，/v2/crawl 正是為此而存在的端點：丟給它一個起始 URL，每一個值得留住的頁面都會以 Markdown 回到你手上。官方教學對整條流程有完整說明，這篇文章把它收斂成三條實戰主軸：參數怎麼下、結果怎麼交付、費用怎麼算。
動手之前，先把兩個常被當成同義詞的術語分清楚。Web scraping 指的是針對已知 URL 的單一頁面取出內容；web crawling 則是跟著連結在站內移動、一面走一面找出新頁面，重心擺在導覽與 URL 發現。想像你在做一支能回答 Stripe 文件問題的 chatbot，這兩種能力缺一不可：靠 crawling 找出並走完文件站裡的每一頁，再靠 scraping 把各頁內容取出來。Firecrawl 的 crawl 把這兩件事包進同一個 job：先做 URL 分析（走 sitemap 或逐頁遍歷），接著遞迴走訪、逐頁抽取，最後以結構化形式回傳。呼叫管道有 REST API、Python/Node（另外還有 Go、Rust）SDK、MCP server，以及 CLI。
從同步開始：一行呼叫掃過一個站
拿練習站 books.toscrape.com 搭 Python SDK，總共兩行程式就能跑：crawl(url=base_url, limit=20)。回傳的 result 裡有 status、total、credits_used、completed，以及一份 data 清單；清單中每個項目對應一個頁面，裝著該頁的 Markdown 和 metadata（title、description、url、language、robots 等欄位）。同一件事若交給 beautifulsoup4 或 lxml，解析加上分頁的程式碼動輒數十行；這裡一行搞定，官方實測抓 3 頁費時約 8 秒（實際數字隨網路與目標站台浮動）。規模不大的工作，用同步 crawl() 現場等結果就好。
關鍵參數：limit、路徑篩選與 sitemap 模式
limit：替這次任務設下抓取頁數的上限。少了這道閘，crawler 會順著接不完的連結鏈一直走下去，credits 也跟著一路燒；站體越大、或外部連結被打開時，風險越是明顯。帳單金額同樣由它直接決定。include_paths/exclude_paths：用路徑模式替爬取畫出邊界——例如只要/docs/底下、或剔除/blog/——比起抓完再篩，credits 和時間都省下來。crawl_entire_domain：讓爬取橫跨子網域、覆蓋整個 domain，結構攤得很開的大型網站正需要它。sitemap：把 URL 發現切換到 sitemap 模式，速度與完整度都勝過沿連結遍歷，文件站尤其受惠。scrape_options：把給每頁 scrape 用的選項（格式、等待條件等）一路往下帶，讓整個 crawl 對每頁的處理行為在單一 job 裡保持一致。
這些參數該怎麼配？原則是「先窄後寬」：一開始用 limit 加 include_paths 只圈一小區，把輸出檢查一輪，等格式與品質都過關再放寬範圍；別在大站上第一輪就開全網域，讓 credits 直接見底。
大任務上場：三種非同步交付方式
job 一大，同步傻等就行不通。用 start_crawl() 把非同步 job 掛上去之後，結果有三種拿法，各對應一種場景：以 get_crawl_status() 輪詢，寫起來最單純，腳本批次跑很合適；用 watcher() 走 WebSocket 串流，每頁爬完立刻送到手上，適合一邊爬一邊處理的管線；或者讓 Firecrawl 把 webhook 事件推送過來，結果直接併進既有的事件架構。怎麼挑，看你的下游吃什麼：資料要批次入庫，輪詢就夠；要即時索引或回報進度，走串流；企業級 pipeline 交給 webhook。還有一個操作細節值得記住：status、total、completed、credits_used 這幾個欄位在同步與非同步兩邊都存在，成本遙測因此不受模式影響——大 job 跑串流時，credits_used 是當場一路看著它累加的，不必等到跑完才發現預算見底。
計費規則：把成本考量寫進參數
收費方式一目瞭然：每爬一頁計 1 credit；每頁做 JSON 抽取加收 4 credits；PDF 解析每個 PDF 頁再加 1 credit。白話說，總成本 ≈ 頁數 ×（1 + 選配加價）。也因為這樣，limit 不該被當成防呆開關，而是成本控管的核心工具：先抓出目標站的頁數量級（map 端點能只列 URL、完全不抓內容），接著才決定 limit 設多少、JSON 抽取開不開。幾千頁規模的站若把 JSON 抽取打開，帳單會是純 Markdown 模式的五倍——按下執行前，這筆帳得先算。
通往 RAG：直接對接 LangChain
教學收尾示範了一條完整管道：crawl 的產出直接交給 LangChain 的文件載入器——Markdown 進來、切塊、嵌入、存入向量庫，一路到底。給 builder 的實務建議：用 include_paths 讓爬取範圍貼著知識庫的主題邊界走（整站亂爬，常會帶進大量跟問答無關的頁面）；靠 metadata（url、language）把出處留住，檢索結果才連得回原文；做增量更新時，用 sitemap 模式比對新舊兩份 URL 清單，只重爬有變動的頁面，讓週期性更新的成本跟著變動量走，而不是全站規模。