Firecrawl 完整教學：把任何網站變成 LLM 讀得懂的 Markdown

做過 RAG 的人都懂那種挫折：你花兩小時挑好模型、設好向量資料庫，結果卡在一個蠢問題上——抓回來的網頁裡有導覽列、有廣告、有 Cookie 同意橫幅，而且有半數頁面用 requests 抓回來只有一個空殼，因為內容是 JavaScript 渲染出來的。

Firecrawl 就是專門解決這一段的工具。

Firecrawl 是什麼

Firecrawl 是一個網頁資料擷取 API，Y Combinator 出身，官方定位是「從網路取得脈絡最簡單的方式」。你丟一個網址進去，它回傳一份乾淨的 Markdown——廣告、導覽、腳本全部清掉，只留下有意義的內容。

它跟自己寫爬蟲最大的差別有兩個。第一，它會處理 JavaScript 渲染，也就是先把頁面跑完再抓內容，這解決了現代網站最常見的抓取失敗原因。第二，它的輸出格式就是給大型語言模型吃的，你不必再寫一堆清理邏輯。

它能做什麼

官方目前提供七種端點，每一種對應不同的使用場景：

端點	用途	點數計費
Scrape	抓取單一頁面	每頁 1 點
Crawl	遞迴爬取整個網站	每頁 1 點
Map	快速取得網站的頁面結構	每頁 1 點
Search	網路搜尋並取回內容	每 10 筆結果 2 點
Interact	瀏覽器自動化，處理登入與互動	每分鐘 2 點
Monitor	追蹤頁面變化	每次檢查 1 點
Agent（預覽中）	AI 代理人整合	動態計價，每日 5 次免費

方案分成 Free、Hobby、Standard、Growth、Scale 與 Enterprise 六階。免費方案每月一千點、兩個並行請求；以年繳計費折算，Hobby 約每月 16 美元含五千點、Standard 約 83 美元含十萬點、Growth 約 333 美元含五十萬點、Scale 約 599 美元含一百萬點。所有自助方案都支援點數用完時以五美元為單位自動加值。

怎麼用：從註冊到第一次抓取

第一步：註冊拿 API 金鑰

到 firecrawl.dev 註冊，免費方案不需要信用卡。登入後在儀表板可以取得 API 金鑰，記得存到環境變數裡，不要寫死在程式碼中。

第二步：抓第一個頁面

最簡單的用法是 Scrape 端點，丟一個網址、指定要 Markdown 格式，回來就是清乾淨的內容。實務上你會拿到兩個東西：markdown 欄位是正文，metadata 欄位包含標題、描述、語言等資訊。後者在建索引時很有用，別忽略它。

第三步：爬整個網站

Crawl 端點會從你給的起始網址開始，遞迴跟隨連結。這裡有幾個一定要設的參數：

• 頁數上限：不設的話，一個大型網站可以輕鬆吃掉你整個月的點數
• 路徑限制：只爬 /docs/ 底下的內容，不要跑去爬部落格與公司介紹
• 排除規則：把登入頁、搜尋結果頁這類沒有價值的頁面排除掉

我的習慣是先用 Map 端點看一次網站結構，確認總頁數在合理範圍，再決定要不要跑 Crawl。這一步能避免大部分的點數意外。

第四步：接進你的 RAG 流程

拿到 Markdown 之後的標準流程是：切塊（chunking）、向量化、存進向量資料庫。Firecrawl 的 Markdown 保留了標題階層，這對用標題做切塊邊界的策略特別友善——比起 HTML 轉純文字後的一團泥巴，品質差很多。

進階技巧

先 Map 再 Crawl，永遠。 這是我最想強調的一點。Map 只需要很少的點數就能告訴你這個網站有幾頁、結構長什麼樣。跳過這一步直接 Crawl，是最常見的燒點數方式。

用結構化擷取取代自己寫解析。 Scrape 支援指定 schema，讓模型直接把頁面內容抽成你要的欄位（例如商品名稱、價格、庫存狀態）。這比抓回 Markdown 再自己寫正則表達式穩定得多，尤其是頁面改版時。

並行數是實際瓶頸。 免費版只有兩個並行請求，抓一千頁會非常慢。如果你在做原型驗證，先抓五十頁確認流程可行就好，不要一開始就跑全站。

Monitor 適合做競品追蹤。 如果你要監控競爭對手的定價頁或產品頁變化，Monitor 端點比自己排程跑 Scrape 省事，而且每次檢查只算一點。

搭配可觀測性工具。 如果你的 RAG 流程接了 Helicone 或 Langfuse，記得把抓取的來源網址一併記錄。日後排查「為什麼模型回答錯了」時，八成問題出在來源資料，不是模型。

注意事項

法律界線一定要先想清楚。 這是我認為最重要的一段。Firecrawl 這個工具本身是中性的，但抓取行為的法律責任在使用者身上。務必遵守目標網站的 robots.txt 與服務條款；商業用途尤其要注意著作權與資料庫權利。台灣的著作權法對重製有明確規範，把別人的內容整批抓下來放進自家產品，風險並不低。有疑慮時請尋求法律意見，不要抱著「反正大家都在抓」的心態。

點數消耗很難事先估算。 一個看起來只有三十頁的文件網站，可能因為分頁與參數組合展開成三百頁。設頁數上限是必要的自保。

不是所有網站都抓得到。 需要登入、有嚴格反爬蟲機制、或明確禁止自動存取的網站，Interact 端點可以處理一部分互動情境，但不是萬能。遇到抓不到的網站，先確認是不是對方刻意擋的——如果是，那就是在告訴你不要抓。

輸出品質仍需抽查。 Markdown 轉換在多數網站上表現很好，但排版特殊的頁面（大量表格、複雜的巢狀結構）可能會失真。建立索引前先隨機抽查十頁，確認內容完整。

TheAI學院 評語

Firecrawl 的定位非常清楚，清楚到有點無聊——它就是把「網頁轉乾淨文字」這件苦差事包成 API，沒有別的野心。

但這正是它好用的原因。做 RAG 的人都知道，最花時間的從來不是選模型或調參數，而是資料前處理。把這一段外包出去，你的時間可以花在真正有差異化的地方。

評語：它賣的不是技術，是你不必再維護爬蟲的那些週末。

給台灣開發者的具體建議有三點。第一，先用免費的一千點跑通整條流程再考慮付費，這個額度足夠驗證原型。第二，養成「先 Map 再 Crawl」的習慣，這一個動作可以省下大半的點數浪費。第三，也是最重要的——在按下 Crawl 之前，先花五分鐘看一下對方網站的 robots.txt 與服務條款。技術上做得到，不代表法律上可以做。

更多開發者工具可以在 AI 開發者工具目錄 找到，也可以參考 提示詞範本 設計你的資料擷取提示。