用 API 與 Screaming Frog 做資料驅動的大規模內容修剪
來源聲明：本文根據〈Data-Driven Content Pruning at Scale Using APIs and the Screaming Frog SEO Spider〉（Liam Lesani，Welltopia，刊登於 Screaming Frog，2026-01-12）編譯整理，不是逐句翻譯。原文連結：https://screamingfrog.co.uk/blog/data-driven-content-pruning。頁面未見開放授權。文中「編輯解讀」為本站觀點。
內容修剪（content pruning）指移除、合併或更新低價值頁，以減少低品質量並改善爬取與主題權威。挑戰包含：找出可刪頁、判斷要更新還是做站外動作、怕掉流量、以及說服利害關係人。
三種評估取向
手工：逐 URL 看流量、日期、品質——中型站上萬頁就不可行，且主觀。 LLM＋Python：語意理解強，但要 NLP／向量／管線能力，成本與模型偏差、閾值難定；作者建議與資料方法並用在更新／合併。 資料驅動：用 GSC、GA 等指標打分排序，降低誤刪有流量頁的機率，並能按主題控制刪除量，較利對主管簡報。
四階段流程
- 評估：匯入點擊、曝光等，定義分數。
- 策略：行動計畫（keep／prune／update／check／improve）與照顧計畫（估計損失、主題權威、補內容）。
- 實作：完整文件與技術工單。
- 監測：保留頁若掉量，要能快速反應。
後續原文展開如何用 API 拉資料、與 Screaming Frog 爬取結果接合、以及具體欄位與閾值示例；實作細節以原文與你的資料保護政策為準，此處不複製操作逐步清單。
常見問題
- 什麼是內容修剪？移除、合併或更新低價值／低流量內容，以降低低品質頁量，並常與爬取預算與主題權威有關。
- 為什麼作者偏向資料驅動，而不是純手工或純 LLM？手工無法規模化且主觀；純 LLM／Python 門檻高、成本與偏差風險大。資料驅動能估計刪頁流量影響與主題覆蓋，也較利說服利害關係人。
- 流程四大階段是什麼？內容評估（收集 GSC／GA 等並打分）、執行策略（行動計畫與照顧計畫）、實作（與技術團隊工單）、監測（保留頁若掉量要能反應）。
- 行動計畫裡常見動作有哪些？原文提到 keep、prune、update、check、improve 等標籤，依分數與情境指定。
- 照顧計畫在防什麼？估計刪除仍有流量之頁的損失、檢視主題覆蓋，避免主題權威被挖空，並設計降低風險的內容策略。
編輯解讀
一句話重點：修剪是風險專案——先用數據估損失與主題空洞，再分批刪，而不是開爬蟲後一次砍。
這對你的網站意味著什麼：
- 刪前先標「有流量／有反向連結／是樞紐頁」保護清單。
- 與 Gary Illyes 舊 AMA 一致的直覺：大量刪頁會帶走內部連結，宜分批。
- 閾值按你的產業季節性調整，勿直接複製他人點擊切線。
適用與不適用的情境：適用頁數膨脹的出版商與大型內容站。新品目錄剛起步時，亂刪會毀覆蓋。
需要注意的限制：客座文章刊登於 Screaming Frog，工具流程自然偏向該爬蟲與 API 串接；廠商有商業利益。作者任職 Welltopia，方法來其專案經驗，樣本與閾值未必可移植。
延伸閱讀：
名詞與資料來源
- Search Console — Google：〈About Google Search Console〉 https://search.google.com/search-console/about（檢索日期：2026-09-30）
- 有幫助的內容 — Google Search Central：〈Creating helpful, reliable, people-first content〉 https://developers.google.com/search/docs/fundamentals/creating-helpful-content（檢索日期：2026-09-30）
- Screaming Frog SEO Spider — Screaming Frog：〈SEO Spider〉 https://www.screamingfrog.co.uk/seo-spider/（檢索日期：2026-09-30）