根據 Ahrefs 對超過 100 萬個網域做的分析，66.2% 的網站裡都至少有一個重要頁面，內部連結只靠一條在撐，說白了，就是已經一腳踏進「孤兒頁」名單，搜尋引擎的爬蟲幾乎找不到路走到那一頁。這種問題不會跳出來提醒你，不會讓網站當機，也不會讓畫面跑版，它只是安安靜靜讓一篇文章從來沒有機會被人看見，直到某天回頭盤點流量，才發現少掉的那一塊，早就不知道少了多久。
Screaming Frog SEO Spider 就是用來揪出這類看不見的問題的桌面版爬蟲工具。它會像搜尋引擎的爬蟲一樣，從你給的一個網址出發，沿著內部連結把整個網站爬過一遍，再把每一頁的狀態碼、標題、描述、標籤整理成一份可以篩選、可以匯出的清單。官方稱這套工具能揪出超過三百種 SEO 問題，涵蓋斷連結、重複標題、孤兒頁、重定向鏈到爬取深度，幾乎是把網站體質整份攤開來給你看。
這篇不重複「輸入網址、按下 Start」這種畫面操作示範，改成照 Screaming Frog 怎麼用的實際邏輯，從它的定位一路講到能揪出的技術問題，以及最新加進去的 AI 功能。先從它到底是什麼、能取代掉哪些人工作業講起。
Screaming Frog 是什麼？跟人工排查網站有什麼不同？
把 Screaming Frog 想成一台會自己去爬全站的檢查員最貼切。你只要給它一個起始網址，它就會用爬蟲的邏輯，一路沿著內部連結把整個網站掃過一遍，這套機制跟搜尋引擎的爬蟲基本上是同一套邏輯，都是靠超連結去發現新的頁面，不會憑空知道網站上有哪些網址。
跟人工檢查最大的差別在規模。一個網站如果有幾百頁，靠人工一頁一頁點開看標題對不對、連結通不通，光想就讓人卻步；Screaming Frog 通常能在幾分鐘內把整站掃完，並把每一頁的狀態碼、標題、描述、標籤、爬取深度全部整理成一張可以篩選、可以排序、可以匯出成試算表的清單。預設情況下它抓的是網頁的原始 HTML；如果網站大量依賴 JavaScript 才會把內容渲染出來，這種情況可以切換成用內建的瀏覽器引擎，把畫面實際跑一次再抓。
這也是為什麼多數技術 SEO 稽核，第一步都是先把網站丟進 Screaming Frog 跑一輪，先有一份完整清單，才知道問題出在哪一層。至於要用到什麼程度、要不要付費，得先搞懂免費版能查到多少。
免費版能查到什麼？500 網址上限與付費版有什麼差異？
Screaming Frog 提供一個免費版本，不用註冊、不用留信箱就能直接下載使用。免費版的限制很單純，單次爬取最多抓 500 個網址。這裡要注意的是，「網址」算的不只是頁面本身，還包含圖片、CSS、JavaScript 等所有被爬蟲讀到的檔案，並不是單純算 500 篇文章或商品頁。對個人網站、部落格或中小型官網來說，這個額度通常已經夠用；如果經營的是內容量大的網站或電商平台，很快就會撞到上限。
付費版解鎖的東西不是模糊的「功能變多」，而是幾項具體能力：拿掉 500 個網址的上限、可以把每次爬取的結果儲存下來日後重新開啟、能設定排程讓它自動定期爬、開啟 JavaScript 渲染去看懂大量依賴前端框架的網站、用 Custom Extraction 抓取自訂資料，還有串接 Google Analytics、Search Console、PageSpeed Insights 等 API 的整合功能，這幾項後面章節會分別展開。官方目前公告的年費授權價格是以英鎊計價，實際金額請以官方網站當下公布的為準，畢竟匯率跟方案內容都可能隨時間調整。
開始爬站，Spider 全站模式與 List 名單比對怎麼選？
Screaming Frog 有兩種爬取模式，功能取向不同，選錯模式很容易查不到你真正要看的資料。
Spider 模式，從首頁出發把全站爬一遍
這是預設模式，也是做整站技術健檢時要用的模式。貼上網站首頁的網址、執行爬取，它就會沿著內部連結一路把整站掃過一輪，直到再也找不到新的內部連結為止。後面每一節談到的斷連結、重複標題、孤兒頁等檢查，指的都是在這個模式下跑出來的結果。
List 模式，比對你手上已有的一份網址清單
List 模式剛好相反，它不會自己往外爬，只針對你上傳或貼上的那份網址清單逐一檢查。適合的情境包括網站搬家後要驗證一批舊網址現在導向哪裡、把 Sitemap 或 Google Analytics 匯出的網址整理成一份清單來比對，或是要專門追蹤某一批頁面的重定向狀態，這個模式在後面重定向鏈那一節會再用到。
Response Codes 頁籤，抓出斷連結與伺服器錯誤
斷連結是最基本、也最容易被低估的問題，它不見得會拖累 SEO 分數，卻直接傷害使用者體驗。有人從舊文章點進去，看到一片錯誤畫面就轉身離開，而你完全不知道這件事正在發生。
爬完之後，切到 Response Codes 頁籤，這裡列出每個網址回傳的狀態碼。幾個常見的先認得：200 是正常、301 是永久轉址、302 是暫時轉址、404 是找不到頁面、500 是伺服器錯誤。把篩選器切到 4xx，畫面就只剩下所有回傳錯誤的網址，其中 404 就是斷掉的連結。
多數人容易漏掉的一步，是只看到哪個網址壞了還不夠，真正要修的不是那個壞掉的網址本身，而是哪一頁連到了這個死巷子。點開任一個 404 網址，看下方的入站連結資訊，就能找到是哪些頁面正連向這裡，把來源頁的連結改成正確網址或直接移除，這個 404 才算真的處理掉。外部連結適用同一套邏輯，連到站外的過期新聞、失效的社群連結，一樣會拖累使用者體驗，檢查方式跟站內斷連結一樣，都是看回傳碼再往回追來源頁。
Page Titles、Meta Description 與 H 標籤，兩種最容易被忽略的重複問題
把斷連結清乾淨之後，下一個該看的是頁面的標題與描述。這裡的問題比想像中普遍，Ahrefs 對超過 100 萬個網域做的分析發現，68.5% 的網站有頁面標題跟搜尋結果實際顯示的不一致，59.5% 的網站至少有一頁的 H1 標籤是缺漏或空白的。換句話說，這不是少數網站才會犯的錯，是絕大多數網站或多或少都在犯的問題。
標題重複與過長，稀釋掉的不只是排名
切到 Page Titles 頁籤，篩選器裡有三個狀態值得留意：
- 缺少標題（Missing）：頁面根本沒有 Title，搜尋引擎和使用者都難以判斷這頁在講什麼。
- 重複標題（Duplicate）：多個頁面共用同一個 Title，是稀釋排名的主因，因為搜尋引擎很難分辨這些頁面到底有什麼不同，流量容易被拆散、誰也排不上去。
- 標題過長（Over 60 Characters）：超過約 60 個字元的標題，在搜尋結果裡有機會被截斷，重點塞不進去就可惜了。
Meta Description 也是同一套邏輯，本身不直接影響排名，卻是搜尋結果裡那段吸引人點擊的文案。一堆頁面沒寫描述、或每頁都套同一段，Google 往往會自己從內文抓一段來填，抓出來的內容通常不夠精準、不夠吸引人。
H1 標籤的缺漏與重複，也逃不過同一套邏輯
H1 頁籤可以查出缺 H1、重複 H1，還有一頁出現多個 H1 的情況。邏輯跟 Title 完全一樣，一個頁面留一個清楚的 H1 就好，缺漏會讓人搞不清這頁在講什麼，多個 H1 則會讓搜尋引擎分不出主題重點在哪。
Orphan 篩選條件，找出沒有內部連結指向的孤兒頁
孤兒頁是那種存在、卻沒有任何內部連結指向它的頁面。可能是一篇舊活動頁、一個已下架的商品頁，也可能只是某次測試留下忘記清掉的頁面。因為站內沒有任何路徑通往它，搜尋引擎的爬蟲跟一般訪客一樣，幾乎不可能自然走到這一頁，收錄和排名的機會自然低到接近零。前面提到的那份 Ahrefs 研究已經點出這個風險有多普遍，66.2% 的網站，至少有一個重要頁面只靠單一內部連結撐著，離變成孤兒頁只差一步。
有個關鍵容易被忽略，孤兒頁沒辦法只靠爬站找到，因為 Screaming Frog 預設是沿著內部連結去發現新頁面，但孤兒頁的定義正是沒有內部連結指向它，爬蟲自然連不過去，也就爬不到。
正確做法，是把外部來源的網址餵給它去比對。常見的外部來源有三個：XML Sitemap、串接 Google Analytics（GA4）、串接 Search Console。這些來源裡記錄著一些實際存在、但爬蟲沒爬到的網址，把它們跟爬站結果交叉比對，差集就是孤兒頁。找到之後，該留的重要頁面就從相關的現有內容補上內部連結接回站內；早就該下架的舊頁，直接刪除或做轉址處理。
Redirects 報表，揪出重定向鏈與迴圈
重定向本身不是問題，問題出在鏈。當 A 網址轉到 B、B 又轉到 C，使用者要連跳好幾關才到得了最終頁面，這就是重定向鏈；如果不小心轉成一個圈子，A 轉到 B、B 又轉回 A，就變成永遠到不了終點的重定向迴圈。每多跳一關，都會多一點載入延遲，也會稀釋原本要傳遞過去的連結權重。這類問題在網站搬家、改網址結構之後特別常見。
檢查重定向鏈，要用前面提過的 List 模式，搭配一個進階設定。把要檢查的舊網址清單準備好，切到 List 模式上傳，實務上最好把搬家前爬下來的網址，跟 Sitemap、Search Console 的熱門頁面合併去重，來源越完整、漏掉的越少；進到爬取設定的進階頁籤，勾選一律跟隨轉址，讓它無視原本 List 模式只看第一層的限制，一路跟著轉址跳到最終頁面為止；執行爬取，跑到完成後，到報表選單匯出重定向相關的報表。
這份報表最好用的地方，是把每條鏈的細節攤平成欄位讓你一眼看懂：這條鏈跳了幾關、有沒有形成迴圈、起始網址與最終網址各是什麼、最後落地的頁面能不能被索引。跳兩關以上的，就把來源直接指向最終網址，把中間那幾關砍掉；形成迴圈的優先處理，因為那是個跳不出去的迴圈，使用者永遠也到不了終點。
Crawl Depth 欄位，找出埋得太深的頁面
爬取深度講的是從首頁出發，要點幾下才能走到某一頁。首頁本身是 0，首頁直接連到的頁面是 1，再往下一層是 2，以此類推。這個數字之所以重要，是因為點擊路徑越深，代表這頁離首頁越遠，不只訪客難找到，搜尋引擎爬蟲也越不容易爬到、收錄和給好排名。
一般的原則是，重要頁面的爬取深度最好控制在比較淺的層級；如果一頁要點超過三、四次才到得了，就值得回頭看看是不是網站結構層層疊疊，或這頁的內部連結太少。
爬完之後，到 Internal 頁籤，找到 Crawl Depth 這個欄位，點欄位標題就能從高到低排序，深度最深的頁面會排到最上面，路徑中若經過轉址，會多算一層深度，這個小細節容易被忽略。找到埋太深的重要頁面之後，把它拉上來的方法有兩種：真的很關鍵的頁面，考慮放進主選單；其他的，就從現有的相關文章補內部連結指過去。
進階整合：串接 Google Analytics、Search Console 與 PageSpeed Insights
單靠爬站，Screaming Frog 看得到的只有網站內部的結構，哪些頁面存在、標題寫了什麼、連結通不通，這些資訊都有；但流量高不高、Google 眼裡的索引狀態如何、頁面速度快不快，這些資料都在別的系統裡，這也是為什麼它可以串接三個 API。Google Analytics（GA4）能看到每個網址的流量與轉換數字；Search Console 能看到索引狀態與搜尋端的實際表現；PageSpeed Insights 則能拉出 Core Web Vitals 等速度診斷資料。串起來之後，這些指標會直接掛在爬取結果的每一列旁邊，不必切換好幾個工具來回對照，就能同時看到某個頁面速度很慢、流量卻也很低這種交叉線索，判斷優先順序時更有依據。
除了串接外部資料，它還有一個叫 Custom Extraction 的進階功能，能用 XPath、CSS 選擇器或正規表示式，批次抓取頁面裡任意指定的自訂資料，例如結構化資料裡的特定欄位、商品價格、SKU 編號等等，把爬蟲變成一支可以客製化的資料擷取工具。搭配內建的結構化資料驗證功能，還能一次檢查全站的 Schema 標記有沒有寫對，是不是符合搜尋引擎能讀懂的格式。
AI 時代的新功能：模擬 AI 爬蟲、串接 AI 模型做內容分析
最新版本的 Screaming Frog，把好幾個跟 AI 有關的功能加了進來，剛好對應到現在網站不只要被 Google 看懂，也要被 AI 搜尋看懂的趨勢。
先是 User-Agent 這個設定。爬蟲預設模擬的是一般瀏覽器或 Googlebot，但你也可以把身份切換成 GPTBot、ClaudeBot 這類 AI 訓練與搜尋用的爬蟲，實際跑一次爬取，檢查 robots.txt 有沒有不小心把這些 AI 爬蟲擋在外面，或是頁面回應是否正常。換句話說，這是在確認你的內容進不進得了 AI 的訓練資料與搜尋範圍，而不是只顧著 Google 一家。
再來是 AI Integration。爬取過程可以串接 OpenAI、Gemini、Anthropic、Ollama 等模型，設定一段自訂提示詞，讓它在爬每一頁的同時自動跑一輪分析，像是判斷頁面的搜尋意圖、產生內容摘要、或抓出文案的語氣傾向，等於把爬蟲跟一顆會讀內容的大腦接在一起。
最值得留意的，是新加入的 MCP（Model Context Protocol）整合。有了這個，你可以直接在 Claude 這類 AI 助手裡，用自然語言下指令操作爬蟲，請它跑一次爬取、整理某項資料、產出一份分析報表，都不必自己點開介面一項一項設定。這是 Screaming Frog 近期更新裡動作最大的一塊，顯示這套工具不只在追傳統 SEO 問題，也在跟進 AI 搜尋時代的稽核需求。
Screaming Frog 和 Google Search Console 怎麼分工？
很多人會問，已經有免費的 Google Search Console，還需要 Screaming Frog 嗎。這兩者其實是不同角色，最好搭配著用，不是二選一。
Screaming Frog 比較像自己派出去的檢查員，主動把整站爬一遍，即時告訴你哪裡壞了；Search Console 則是 Google 那一端回傳給你的資料，告訴你 Google 實際怎麼看待、怎麼收錄你的網站。一個是主動爬取的現場勘查，一個是搜尋引擎端的官方回報，角色本來就不一樣。
實務上的順序，通常是先用 Screaming Frog 把技術問題抓出來、修掉，再用 Search Console 驗證 Google 端的索引和搜尋表現有沒有跟著改善。前面提到的孤兒頁檢查，更是直接需要把 Search Console 的資料餵進 Screaming Frog 才做得到，兩者搭起來用，稽核才算真正完整。
整套流程走完，你會發現這些問題有一個共同點，都不會自己跳出來提醒你。連結會壞、頁面會被改掉、結構會隨著時間慢慢長歪，Screaming Frog 負責的，是把這些看不見的變化變成一份看得見的清單；清單看完之後要不要動手、要先修哪一項，還是得靠你自己判斷，工具是健檢儀器，不是特效藥，真正決定排名的還是內容、架構跟連結這些更全面的東西。把它變成一個固定會拿出來跑的習慣，每隔一段時間爬一次、對著清單走一遍，才能在流量真的掉下去之前，先一步把問題擋住。