今年受到關注的大多數爬取工具都想啟動瀏覽器，trafilatura 卻不是。它是一個純 Python 函式庫，專門讀取靜態 HTML，判斷哪些區塊才是真正的文章內容，然後把其餘部分全部丟掉。這個看似狹窄的任務——主內容擷取——正是它的核心，而且在「LLM-ready markdown」還沒成為流行語之前，它就已經在做這件事了。
我把 2.1.0 版放到 Python 3.14 的一組固定測試樣本中跑，最讓我印象深刻的就是文章測試。我把一段真實文章內容外面包上常見的頁面雜訊——登入提示、「訂閱」提醒、導覽連結、版權頁尾——而 trafilatura 回傳了標題、三段正文、作者與日期，所有這些制式標記都被清得一乾二淨。不用瀏覽器、不用逐站規則，只要一個函式呼叫。當然，它有一個限制，而且很快就會顯現：只要你要求的是結構化資料，它就做不到。這一點我會在下面再說明（這是設計取捨，不是缺陷）。
trafilatura 是什麼，以及你應該先放下的假設
官方的簡介把它稱作「用於從網路蒐集文字與中繼資料的 Python 與命令列工具：包含爬行、擷取、抽取」，輸出格式可為 CSV、JSON、HTML、Markdown、TXT 或 XML。這個描述範圍很大，但其實低估了它真正的差異化能力。它的價值不在爬行輔助功能，也不在那六種輸出格式，而在於內容擷取：輸入 HTML 文件，輸出主要文章文字，並把頁面外框雜訊去除。
先用一個思維模型來理解，這能同時解釋它的優勢與邊界。大多數你拿去對著頁面跑的爬蟲都是「選擇器驅動」的。你告訴它：「抓 class 是 product-price 的元素」，它就回傳那個位置上的資料。trafilatura 則是反過來。它會讀完整份文件，靠內容判斷哪些區塊是文章、哪些只是頁面雜訊，而不是依賴你手寫的 selector。也因為如此，它不需要每個網站都先做設定，就能清理你從沒看過的頁面。可也正因如此，它無法回傳結構化目錄：它沒有 schema，沒有欄位對照表，只有對「哪些算內容」的判斷。它是擷取器，不是你指定位置的 parser。
它的重量也真的很輕。純 Python、沒有無頭瀏覽器、沒有被你快取裡的 chromium 二進位檔、也沒有第一次執行時突然跳出來的 Playwright 安裝流程。這種特性單看好像不算什麼，直到你要對成千上萬個 URL 做擷取時，每一點依賴體積、每一個子程序，最後都變成你得維運的成本。到 2026-07-09 為止，這個專案大約有 6.26k 顆星（adbar/trafilatura）——和它常被放在一起比較的瀏覽器與爬行框架相比，這其實是個小得多的 repo；這只是說明它的定位，不是在貶低它的品質。
安裝篇幅很短，而這本身就是評價
安裝只要一行，而且沒什麼需要提醒你的地方；光是這點就值得寫進評測。pip install trafilatura 在一個全新的 virtualenv 中、Python 3.14 上，只拉下單一且乾淨的套件樹——不用下載瀏覽器，不用安裝後額外步驟，也沒有什麼層層相依的套件牆要跨。我看過夠多這類工具，知道往往要等第二隻鞋掉下來：第一次執行才發現的 150MB 瀏覽器套件、無法編譯的原生擴充、沒人提過的額外 [fetchers] 群組。到了 trafilatura，這些都沒有出現。
我透過 pip 拿到的版本是 2.1.0，也就是目前最新正式版，發佈於 2026-06-07，因此下面的數字不會有「你測的是過時版本」這種註解。這在這類工具裡並不常見——不少我看過的重量級工具，等我實測時都已經落後一個大版本。這次測試版本和實際發佈版本是一致的。
實測：擷取器到底回傳了什麼
我拿 trafilatura 去跑一組刻意設計過的 fixtures，測它擅長的地方，也測它的邊界。最後真正影響我整體判斷的，是文章測試。
我把一個本機文章樣本塞進去，然後在真實內容外面堆滿雜訊——登入提示、「訂閱」行動呼籲、導覽連結、版權頁尾，這些都是天真的爬蟲常常會連正文一起抓進來的制式內容。trafilatura 回傳了標題與三段正文，三段全都完整保留，而且所有獨特的雜訊標記——Login、Subscribe、Copyright——都不見了。除了文字之外，它也正確從頁面中繼資料抓出了作者與日期。一次呼叫就能輸出 .txt、.md、.json 三種結果。
這個多格式能力很值得多講一句。一次擷取能同時輸出純文字、Markdown 與 JSON。Markdown 這條路，正是大家現在追求的「LLM-ready text」步驟：把混亂的頁面丟進去，拿回結構保留、可直接餵給模型的乾淨文字。trafilatura 完成這件事時，整個流程不需要任何瀏覽器參與；相較之下，許多依賴瀏覽器的工具只是多了一整套渲染堆疊來產出同樣的結果。
接著看公開頁面測試。我把它指向一個真實商品頁——Books to Scrape 的產品頁——它回傳了 1,324 個字元的乾淨文字與 Markdown，也就是可閱讀的描述區塊，頁面雜訊完全沒跟著出來。然後我再丟一個回應 HTTP 500 的頁面給它，fetch_url 回傳的是 None，而不是直接拋錯。沒有當機，沒有堆疊追蹤要處理。這種看似平凡但正確的失敗方式，正是排程式、無人值守環境最需要的行為。
需要注意的限制
有三點，而且每一點都會界定這個工具的適用範圍。
第一，也是最重要的一點：trafilatura 是內容擷取器，不是結構化爬蟲。我拿它跑了一個 12 個商品的型錄樣本，它回傳了全部 12 個商品名稱——以文字形式——但結構化列數是 0（只有 478 個字元的平面文字）。名稱和價格確實都在輸出裡，只是它們不是欄位。如果你要的是 [{name, price, rating}, …] 這種結果，這就是錯的工具，而且沒有任何設定可以改變這件事。這是工具用途的設計選擇，不是要提報的 bug。
第二：它不會渲染 JavaScript。它只處理靜態 HTML。如果你把它丟給一個前端渲染的單頁應用，得到的只會是伺服器在 JS 執行前送出的內容，而那通常沒什麼用。若你的目標站點大量依賴 JS，就需要搭配另一個渲染器；trafilatura 不會替你補上這一段，而且它也沒有宣稱自己會做。
第三，這是我對自己證據的保留。前面那個公開擷取測試依賴的是產品描述區塊，而不是真正的新聞文章，因為我使用的公開沙盒（toscrape 系列）只有型錄，沒有新聞頁。至於文章清理效果乾不乾淨，則是來自我控制的本機樣本。這個結果我信得過——因為去除雜訊的結果很明確，也可重現——但產品頁不等於新聞編輯部等級的文章擷取，所以我不會把它說成那樣。
為了部分彌補這個落差，我另外做了一個刻意不納入評分的示範，使用兩個真實文章頁面，並讀取已儲存的 fixtures，讓結果可重現。在 Wikipedia 的「Web scraping」條目中，trafilatura 把原始 HTML 從 230,049 位元組縮到 26,673 位元組的擷取內容（正文與原始內容比為 0.116），而我檢查的四個頁面外框標記——「Jump to content」、「Privacy policy」、「Powered by MediaWiki」、「This page was last edited」——全都不見了。在一篇存檔的 Wikinews 文章中，它把內容從 79,716 位元組縮到 2,200 位元組（比率 0.028），五個檢查標記也全部被移除。這兩個頁面的標題、日期與主機名稱都有正確回傳；作者與網站名稱則都回傳 null，我也如實記錄這些缺漏，而不是刻意略過。這裡有兩件事要分清楚：這個位元組比率是在衡量有多少標記與頁面雜訊被去掉，不是 擷取準確率；而且這兩個頁面都屬於同一個 MediaWiki 家族，所以這只能算是真實文章的示範，不能當作具代表性的語料庫。
至於準確度本身，我會引用外部證據，而不假裝是我自己量出來的。trafilatura 有自己的評估頁面，而且它在 ScrapingHub article-extraction benchmark 裡，與 readability-lxml（約 0.887）相比，拿下了開源工具中的最高 F1（約 0.945）。這個數字有兩個誠實的註解：它來自那份 benchmark，不是我自己的測試；而且文中提到的 ~0.945 是對應較舊的 0.5.1 版本線，而不是我實測的 2.1.0。請把它當成外部基準證據，用來說明這個工具為何有擷取口碑，而不是把它當成我這篇評測直接測出來的數值。
優缺點
優點：
- 我這組測試裡最乾淨的文章擷取結果——標題加上 3 段正文全保留，所有雜訊標記（Login/Subscribe/Copyright）都被去掉。
- 能連正文一起正確抓到作者與日期中繼資料。
- 一次呼叫就能輸出多種格式：txt、Markdown、JSON——其中 Markdown 是很實用的 LLM-ready text 步驟。
- 輕量、純 Python 安裝——沒有瀏覽器、沒有二進位下載、沒有沉重依賴牆。
- 失敗時表現穩定：
fetch_url在 HTTP 500 時回傳None，不會直接丟例外。 - 實測版本與目前正式版一致（2.1.0）——沒有版本落差。
- 採用 Apache-2.0 授權——寬鬆而且適合商業使用。
缺點：
- 不是結構化爬蟲：型錄測試回傳 12 個名稱文字，但沒有任何 typed rows。沒有 schema，也沒有欄位。
- 不支援 JavaScript 渲染——只處理靜態 HTML；如果是前端渲染頁面，需要另外搭配渲染器。
- 某些網站的中繼資料不完整：在我檢查的兩個真實文章樣本中，作者與網站名稱都回傳 null。
- 我的公開文字測試用的是產品描述區塊，不是真正的新聞文章。
- 內建爬行／sitemap spider 與 CSV/XML 輸出格式，這次都沒有測到，所以我不對它們做任何結論。
適合誰——以及誰應該跳過
trafilatura 非常適合那種問題是「我有一堆 URL，我只想要乾淨的文章文字，不要導覽列、Cookie 橫幅、電子報提醒」的人。建立文字語料、把頁面餵給模型、封存可讀內容、對網頁文章做 NLP——這就是它的主場，而且它做得很好。如果你要的是一個輕量、免瀏覽器的步驟，把雜亂 HTML 轉成乾淨 Markdown 或 JSON，那就直接安裝它、繼續做你的事。
如果你真正需要的是結構化擷取：有價格的商品列、型別化紀錄、key: value 欄位，那就跳過它。它給你的是文字，不是表格——型錄測試只拿回名稱，沒有資料列，這不會改變。若你的目標站點內容是瀏覽器渲染，而且你不想再額外接一個渲染器，也請跳過它，因為 trafilatura 只讀靜態 HTML，到此為止。它的失敗模式不會很戲劇化；你只會拿到空結果或很薄的結果，然後疑惑為什麼。工具要對應工作：文章文字可以，結構化 JSON 或 JS 渲染頁面就該找別的方案。
替代方案，以及 Thunderbit 在哪裡派上用場
先講公平的定位。trafilatura 是免費、Apache-2.0、可自行部署的函式庫，由你自己執行。程式碼在你手上、每頁成本是零，而且輕到可以直接塞進任何流程而不增加維運負擔。就「把文章剝成乾淨文字」這件事來說，這樣的組合很難被取代，付費服務也不會改變這個結論。
真正有比較意義的，是 trafilatura 刻意畫出的邊界：結構化資料與 JavaScript。這兩件事它都不做，而這剛好也是受管控抽取 API 最擅長處理的部分。這就是 Thunderbit 的開發者產品線所在位置——站在那條線的另一側，和 trafilatura 互補，而不是在靜態 HTML 文章文字這一點上和它正面競爭。/distill 端點做的事情，和 trafilatura 的工作型態很像：把頁面轉成乾淨、可給 LLM 使用的 Markdown；差別在於 JavaScript 渲染由伺服器端處理，正好補上 trafilatura 跳過的那一半。而 /extract 則是依照你定義的 schema 回傳結構化 JSON，這正是 trafilatura 設計上不會做的那一半：那個回來只有 478 個字元平面文字的型錄案例，換成 /extract 才是該出手的時候。對 AI agents 和 coding assistants 來說，還有一個 MCP server，裡面的欄位建議工具可以免費試用；也有 npx @thunderbit/thunderbit-cli 這種 CLI，可用在終端機、CI 與 cron。它與超過 100,000 名使用者在用的 Thunderbit Chrome Extension 採用同一套引擎，所以不懂技術的人也有路可走；但就這類讀者而言，API、MCP 與 CLI 才是最相關的介面。
所以真正的取捨從來不是文字擷取品質——trafilatura 在它擅長的頁面上確實贏，而且我願意直接這麼說。重點在於範圍，以及誰來跑瀏覽器。你需要的是從靜態 HTML 抽出乾淨文章文字、自行部署、每次呼叫成本為零？trafilatura 就是更輕、更銳利的工具，沒有任何疑問。你需要的是符合 schema 的結構化 JSON，或者頁面得等 JavaScript 跑完才會顯示內容？那是受管控方案的主場，trafilatura 從來也不是要去打那場仗。若你想比較受管控方案的每頁成本與自己維運渲染器的成本，可以看 Thunderbit pricing page。
如果你是在整個類別中做方案比較，我也持續整理一份我實際在用的網頁爬取工具比較，把這類函式庫和瀏覽器驅動、代管方案放在一起看。
結論
該不該用 trafilatura？要——如果你的工作是把雜亂 HTML 變成乾淨文章文字，而且你也清楚它刻意不做的兩件事。它能一次把一個頁面上的所有制式雜訊清掉，並回傳標題、三段正文、作者與日期，而且只需要一個很輕量的安裝，整個過程完全不用開瀏覽器。它同時輸出 txt、Markdown 和 JSON，這讓它成為真正可用的 LLM-ready text 步驟。在一個大家都以為你非得用無頭瀏覽器和 AI 爬蟲才能做事的領域裡，這個不開瀏覽器的工具，反而把我在乎的清理工作做得很好。
但要正確理解它的範圍。它是擷取器，不是結構化爬蟲——型錄測試只回來 12 個名稱文字，沒有任何資料列。它只讀靜態 HTML，不執行 JavaScript。它的中繼資料擷取在某些頁面很強，但在另一些頁面只是部分成功（我檢查的兩個真實文章樣本中，作者與網站名稱都回傳 null）。而且我那個公開文字測試依賴的是產品描述區塊，不是真正的新聞文章，所以新聞級擷取的說法目前只能算是前景可期，還不能下定論。只要在這些界線內，trafilatura 做它該做的那一件事，確實比我比較過的重量級工具更乾淨，而且幾乎不用安裝什麼額外東西。
試試 Thunderbit 的網頁資料擷取 Get Started Free
常見問題
trafilatura 實際會從頁面擷取什麼？ 主要內容——文章正文、標題，以及作者、日期等中繼資料——並移除制式雜訊。在我的測試裡，它從一個包著導覽、登入、訂閱與版權雜訊的頁面，回傳了標題與 3 段中的 3 段正文，而且這些標記全部都沒出現在輸出中。它透過 heuristics 判斷哪些算內容，因此不需要每個網站都先寫 selector，也能清理從沒看過的頁面。
trafilatura 可以把商品型錄抓成結構化資料列嗎？ 不行。它是內容擷取器，不是結構化爬蟲。在一個 12 商品的型錄樣本上，它只回傳 12 個商品名稱的平面文字（478 個字元），以及 0 筆結構化資料列——名稱有在輸出裡，但不是欄位。如果你需要像名稱／價格／評分這種型別化紀錄，請改用基於 selector 的 parser 或 schema 驅動的擷取 API。
trafilatura 會渲染 JavaScript 嗎？ 不會。它只處理靜態 HTML。如果你把它丟給前端渲染的頁面，拿到的只會是 JavaScript 執行前伺服器回傳的內容，而那通常不是你要的結果。如果你的目標站點大量依賴 JS，就要搭配另一個渲染器；trafilatura 只讀靜態文件，然後就停在那裡。
trafilatura 安裝起來會很麻煩嗎？
不會——這正是它真正的賣點之一。pip install trafilatura 在 Python 3.14 的全新 virtualenv 中，只拉下單一乾淨的套件樹，沒有瀏覽器下載、沒有安裝後步驟，也沒有藏起來的額外套件群組。pip 安裝的版本（2.1.0）就是目前正式版，發佈於 2026-06-07。
trafilatura 跟其他擷取器相比準確度如何？ 這篇評測沒有做獨立的準確度 benchmark，所以我直接引用外部證據。trafilatura 有自己的評估頁面，而且它在 ScrapingHub article-extraction benchmark 中，與 readability-lxml（約 0.887）相比，報告了開源工具中最高的 F1（約 0.945）。注意，這個數字來自那份 benchmark，而且對應的是較舊的 0.5.1 版本線，不是我實測的 2.1.0——所以請把它看作是工具口碑的外部證據，而不是這篇文章直接量出的結果。
