Screaming Frog 實戰：從流量下滑到工程師工單

想像一個場景：週一早上，電商公司的行銷負責人打開後台，自然搜尋帶來的進站人次連續第三週往下掉。會議上老闆問了一句「網站是不是壞了」，她手上只有一份排名報表，答得出哪些關鍵字退了幾名，答不出網站哪裡出了狀況。有人建議她裝一套爬蟲軟體自己量，於是她下載了 Screaming Frog，把公司網址貼進輸入欄，按下開始。

接下來發生的三件事，比流量下滑本身更讓人慌。軟體量出來的頁面數，跟內容後台登記的數字對不起來；量到一半，免費版的五百筆上限把工作停在半路；換個方式跑完，Issues 面板一整排警示，紅的黃的擠在一起，沒有人告訴她該先處理哪一個。多數人在這裡關掉軟體，回頭繼續盯排名報表，問題原封不動。

慌的根源並非工具難用，真正的問題是對報表的期待錯了。爬蟲給你的從來不是網站的全部真相，而是一份量測結果：從特定起點出發、沿著特定連結路徑、在特定設定之下，伺服器此刻實際回應了什麼。起點換一個、範圍框小一點、渲染模式開或不開，數字就跟著變。把報表當判決書讀的人會被紅字淹沒；把報表當量測紀錄讀的人，才有辦法從數字裡找出下一步。這兩種讀法的差別，決定診斷是往前推進，還是在原地打轉。

快速重點：整站性症狀先用爬蟲量測網站此刻的實際回應；報表是量測結果，不是網站真相，也不是判決。與 Google 後台資料交叉對帳，差異先分類、再決定查證方向；判讀看分布型態，不看單一狀態碼。交付以可驗收工單為單位，修完同設定重查才結案；免費版上限以網址總數計，不是頁面數。

症狀對了，工具才有用。往下走之前，先過一道閘門：手上這個問題，究竟是不是爬蟲能回答的。

哪些狀況才需要出動爬蟲

先回答一個比「怎麼用」更省時間的問題：這個症狀需不需要出動爬蟲。判斷標準不是職稱或年資，而是症狀的特徵。流量連幾週走低、收錄數量縮水、改版之後成效變調、同一個頁面樣板大規模出錯，這類整站性的技術狀態，值得把整個網站量一遍。反過來，某一頁的標題怎麼寫、某個關鍵字排第幾、對手有哪些連結，點對點查就有答案，開爬蟲只是把等待時間拉長，還會得到一堆用不上的數字。

單頁的問題，開發者工具夠用。檢視原始碼、看單一請求的回應、確認頁面標記，幾分鐘內結案，操作方法可參考瀏覽器開發者工具的檢查技巧。整站的問題不同，你面對的是幾百幾千個頁面的共同行為，逐一點開等於把同一個動作重複幾千次，這時才輪到爬蟲上場：它把重複的量測交給機器，你把時間留給判讀。剛起步、連檢索與收錄的關係都還不熟的讀者，先回SEO 基礎觀念把底子補齊再碰工具，判讀品質會差一大截。

有三種情況可以直接排除，不必猶豫：

• 內容品質的問題。文章深度不足、議題過時、排版難讀，爬蟲量得出頁面存在，量不出內容好不好，這要靠編輯判斷與讀者行為資料回答。
• 外部連結的問題。爬蟲看得到自己站內連出去的方向，別人願不願意連回來、連結品質好不好，它管不到。
• 關鍵字規劃的問題。需求規模、競爭強度、該不該投入，是搜尋資料與商業判斷的事，跟網站技術狀態無關。

這三種問題硬拿爬蟲解，報表只會製造新的困惑。把症狀對應到第一個該看的證據，順序比記住任何面板名稱都重要：懷疑網站壞了，先看整批回應狀態的分布；懷疑頁面不被看見，先查指令與連結路徑；懷疑網站太胖，先量深度與重複版本的數量。起點走對，後面每一步都是推進；起點走錯，後面每一步都在補救。

閘門也擋掉另一種浪費：在錯的時間量測。網站本週才剛上線新模板，工程還在收尾，此刻量到的問題裡會混著半成品，這份報表缺的是穩定的比較基準，差異反映的多半是工程進度。這跟改版上線後立刻量一次驗證並不衝突：變動還在進行中量，任何差異都無法歸因；上線前後兩個定點各量一次，比的就是工程交付的結果。時間點本身只是表象，判斷的關鍵在於這次量測要拿來跟什麼比。這個紀律看似瑣碎，卻決定報表在團隊裡的信用：一份基準混亂的報告，會讓之後每一份正確報告都跟著被打折。

對帳之前，先把網址與資料時間對齊

回到開場的第一個慌：頁數對不起來。要讀懂落差，先換一種問法：挑一個有疑問的網址，它手上能拿到幾種紀錄？自己發起請求，看到的是爬取期間這個網址被訪問時的實際回應，這是Screaming Frog SEO Spider 這類本機爬蟲量到的東西；Google Search Console 給的是 Google 端回報的檢索與索引狀態；Ahrefs、Semrush 的競品與反向連結報表，則是第三方資料庫上次拜訪留下的快照，兩家雖然也各賣站點稽核模組，那部分的性質就回到主動爬取這一側。三份紀錄各有延遲與偏差，沒有任何一張名單是網站的標準答案。

三份紀錄的時鐘不同步，這是對帳的第一個障礙。爬蟲的數字是爬取期間逐網址取得的回應，一個大站跑下來，起頭量到的網址與收尾量到的網址，中間可能隔了好幾個小時；後台資料是累積與延遲後的回報；快照停留在對方上次拜訪的時間。涵蓋範圍也不同：爬蟲只看本次設定下可及的部分，後台只記 Google 實際處理過的部分，快照只有對方資料庫裡的紀錄。對帳之前先把這兩件事寫在報告開頭，跨清單的差異先不定性好壞，那是接下來分類的事。

差異怎麼讀，按「多出來的是誰」分類最快。爬蟲清單多、後台少的網址，往指令與價值面查：是否 noindex、標準網址是否指向別處、內容是否值得收錄。後台多、爬蟲少的，往量測條件查：範圍框太窄、渲染沒開、robots 擋路，或清單本身的統計口徑不同。快照登記、現在回應轉址的，往頁面現況查：下架、搬家、整併。分好類，每一筆差異都對到一個查證方向，報告就從兩串對不上的網址，變成一張標好去向的清單。

有一個事實要先記住：從 Google 後台匯出的資料，本來就不是完整的已索引清冊，它是特定條件下的回報。拿它當分母、當全集去計算，算出來的結論站不住。全站對帳用清單比對，單頁確認換一種粒度，用收錄狀態的查詢方法交叉驗證，兩種做法不要混進同一個結論裡，報告的效力才清楚。

對帳的實際操作不複雜：把三張清單都匯出來，以網址當對齊的鍵，兩兩比對。哪一邊多、多出來的是什麼類型的頁面，把差異分類標注，問題的輪廓就會自己浮出來。多數時候你會發現，差異集中在某一種頁面類型上，例如全部是篩選頁、全部是舊目錄、全部是剛上線的區塊，這種集中本身就是診斷結論的一半。

第三方工具的正確用法也是對照，不是替代。Ahrefs 的基本操作與資料分析視角、Semrush 的站內稽核與競品觀察，適合印證爬蟲的發現，或補上站外面向；目光放在對手身上時，再搭配Similarweb 這類流量估計工具。手上的證據來源越多種，差集能告訴你的事就越多，單一來源的結論永遠值得再查一次。

症狀一：流量無預警下滑，先確認網站能被正常讀取

流量下滑的原因百百種，技術面先排查的是可存取性：網站此刻回應是否正常。做法不是逐頁檢查狀態碼，而是先看整批回應的分布型態，型態決定處置層級。一頁回報 404，先分清是預期中的下架還是意外失蹤：前者確認替代去處與來源連結就收工，後者要恢復內容，修來源連結救不回消失的頁面；同一個樣板的幾百頁全部回報錯誤，系統性問題，找工程看樣板與部署；整站連首頁都回不了正常回應，這種等級當天就要通報處理，其他 SEO 排程全部讓位。單點看狀況，樣板找工程，全站當急件，三級先分清楚，力氣才不會放錯地方。

狀態碼的讀法也要更新幾個觀念。200 只代表這一次請求成功回應，不代表頁面可被索引，後面還有指令與內容的條件要過。404 可以合理存在，下架的商品、移除的舊文回報 404 是正常行為，只有當它有明確替代內容時才值得轉址。301、308 與 302、307 的差別在宣告的永久性，這層宣告會影響搜尋端處理標準網址與訊號整併的方式，但整併的幅度與時程由搜尋端依個案判斷，不是強弱兩檔能概括；轉址鏈每多一跳就多一次往返與失敗的機會，該拍平就拍平，但沒有公式能推算每一跳固定折損多少。狀態碼是伺服器的回答，把它當訊號讀，不要當判決讀；各代碼的完整行為，可對照官方的回應碼判讀教學。

5xx 要單獨拉出來講。搜尋引擎的爬蟲遇到持續的伺服器錯誤，可能降低之後拜訪的頻率；什麼時候回升，取決於搜尋端對網站健康狀況與需求的評估，不一定立刻回到原本的水準。所以整批 503 不該排進下週待辦，它屬於當天就要找工程確認的事件，這是它的風險等級，不必再往上加更多推論。

另一個高風險情境是改版與搬家。這類工程動到的網址動輒數百條，上線前先量一次、上線後再量一次，兩份報表一比，轉址漏了幾條、標題掉了幾頁、指令是不是被模板更新覆蓋，一眼就看見。這是網站搬遷工程裡最便宜的保險，也是預防性量測最標準的用法：問題在差異裡現形，不必等流量掉下來才回頭找原因。

讀分布的時候，把頁面價值放進來加權。同樣是十頁出錯，落在主力商品頁與落在三年前的活動存檔頁，嚴重度完全不同。量測報表本身不知道哪些頁面扛著流量與轉換，這個權重要你自己帶進去：把出錯清單與後台的到達頁資料對在一起，先看有流量的那幾頁，再看其他。這個對照不花多少時間，卻決定了後續工單的排序方向。

症狀二：頁面明明在，搜尋引擎卻像看不見

第二組症狀是看不見：頁面上線了、內容也寫了，搜尋側卻像從沒發現過它。取證有三個機制要依序排除，順序本身就是效率，跳著查容易把三個原因的證據混在一起。

第一個機制是指令擋了自己。先交叉看 canonical 與 noindex，再查 robots 規則，三件事經常被混成一件事，修錯方向比不修還糟。canonical 指到別的網址、頁面被套上 noindex、目錄被 robots 擋下，三種狀況的修法完全不同；標準網址的設定原則與robots 跟 noindex 的分界先讀熟再動手，判斷會快很多。這一面有個常見來源：範本沿用。測試環境的 noindex 忘了移除，跟著版型上了正式站，整批頁面一起消失；找出這種問題的切入點，就是把指令欄位跟範本版本對著看：同一批同一天上線的頁面一起出狀況，可以優先檢查共用的範本與部署變更，再往上游確認指令是誰帶進來的。

孤立頁的問題在於：頁面確實存在，卻缺任何站內連結路徑可以抵達，這是第二個機制。收錄與否是另一件事，這種頁面可能已經被索引，也可能還沒。確認用途之後，該保留的頁面就從相關主題頁接回站內連結網絡，沒有保留價值的照正常下架流程處理。接回去改善的是發現路徑與導航，訪客與爬蟲都更容易到達；至於排名會怎麼回應，取決於內容本身的條件，不必預期立竿見影的變化。

排查孤立頁，官方教學的做法是一場對照：把獨立取得的網址清單，跟爬取到的連結網絡放在一起比。清單來源不只有 Google 後台一種，內容系統的全站頁面、Sitemap、分析工具的到達頁都是可用來源，成效資料只是其中之一。清單上有、連結網絡裡沒有的網址，先別急著認定，依序排除四種常見的漏抓原因：量測範圍框得太小、robots 擋了、內容要渲染才看得到、頁面需要登入。這份清單並不窮舉，爬取中途中斷、連結被標記為不跟隨，同樣可能讓頁面漏網；排除得差不多之後，再核對該網址實際的連入連結紀錄，剩下的才適合判定為缺路徑。

第三個機制是內容靠瀏覽器端的 JavaScript 才出現。這種網站量完會有一種特徵：頁數異常少、標題整批空白。遇到這種報表，先懷疑渲染設定，再懷疑封鎖，剩下的才輪到網站本身的問題。多語系網站順手檢查 hreflang 是否成對：缺少互返標記的配對可能被搜尋端忽略，但其他完整配對仍可能照常處理，細節在多語系標記設定另有完整說明。

指令、路徑、渲染三個機制都排除之後，頁面如果仍然不被看見，先補兩個技術面查證：用後台的網址層級檢查，看 Google 實際檢索到什麼、收錄判定為何；比對檢索時間點，確認不是間歇性錯誤或特定爬蟲被擋。這些也沒有發現，重心才移到內容價值與競爭環境，換搜尋資料與需求分析接手，這時候爬蟲就該收起來，不必再跑十遍。

症狀三：頁面越多，重要內容越難被爬到

第三組症狀最隱晦：網站沒壞，但內容持續增加之後，重要頁面反而更難被看到。原因出在檢索資源。篩選器的組合、分頁的序列、帶參數的網址，每一種都會衍生出大量版本；分頁與篩選本身可能是訪客找商品的重要路徑，真正的問題是其中重複與不需要被檢索的部分，爬蟲的時間與頻寬有限，花在這些版本上，留給真正要排名的頁面就變少。背後的運作邏輯，檢索預算一篇有完整說明，這裡專注在量測能做的事：把網站的胖，變成可比較的數字。

盤點三個指標：目錄深度多深、從首頁出發要點幾下才到達、同一頁有幾種參數版本。量完之後，「網站太大了」從一種感覺變成數據，收斂才有依據。處置選項四種，各對應不同的頁面類型：不需要檢索的網址（例如無意義的參數組合），用 robots 規則限制檢索，但要記得這只擋爬取，不等於讓頁面消失或退出索引；內容高度重複、該併成同一個標準版本的，用 canonical 指向代表網址；要留而且該被找到的，收進導航與分類；確定整批無用的舊內容，走下架流程移除。順序上，先把孤立頁與重複版本的盤點做完再動刀：收斂與封存都會改變報表的長相，改完才量，差異就分不清是網站真的變了，還是量測口徑變了；重複版本的判斷原則，參考重複內容的處理方針。

想像一個場景：上萬商品頁的購物網站，把三十幾個重疊的分類整併成八個。整併後先量一次，確認轉址到位、殘留版本收乾淨，再把主力商品的量測結果接上商品頁的優化清單（示意）。這時分類頁的角色也被重新定義：網站資訊架構決定入口的位子，內部連結的位子有限，入口留給要排名的頁面，站內資源的流向就交給結構決定，無須聽天由命。

點擊深度的判讀也一樣要接上價值判斷。從首頁出發要點五下才到的頁面，不是自動有罪，深入的長尾內容本來就離首頁遠；該緊張的是那些扛著商業目標的頁面，卻埋得比一堆篩選頁還深。把深度資料跟頁面價值對在一起看，你會發現要修的往往不是幾百個深層頁面，而是十幾條關鍵路徑上的入口安排。

稽核爬蟲也是流量，量測前先想清楚這件事

多數教學把爬蟲講成純粹的觀察行為，好像量測不佔資源。物理事實相反：稽核爬蟲本身就是一股流量，會增加網站服務的負載；快取與 CDN 擋在前面的架構，壓力落在邊緣層，動態內容多的架構，壓力會一路到應用與資料層。量測幾十頁的小站感覺不到；量測流量大的站，負載規劃就是事前功課，不是出狀況後再補救的事。

所以量測大站，事前把準備做足：跟負責主機的窗口確認承載餘裕，挑對方業務的離峰時段跑；同時連線數與每秒請求量從預設值往下調，用較長的量測時間換餘裕；量測用的識別字串取一個認得出的名字，知會對方的工程窗口，真出狀況時雙方對得上來源。

觀測基準與停止條件也屬於事前：先記下平常的回應時間當基準，量測中一旦比基準明顯拉長就先暫停，回頭交叉查主機、CDN 與網路指標，延遲的成因不一定在後端；收到 403 或 429 是同一類停止條件，那是對方的閘門在拒絕或限速，暫停後向站方確認原因再談下一步，這些請求多半也留有紀錄可以對照。量測不屬於自己的網站，先取得授權，這是底線，不是禮貌。同一套物理限制，也正是檢索預算觀念存在的原因，搜尋引擎同樣要在有限時間內決定拜訪誰、拜訪多深。量測姿勢最終也會回到訪客身上：回應時間拖長，訪客經歷的就是變慢的頁面，這跟體驗指標的關注是同一件事的兩面。

免費版夠不夠用，取決於網址總數而非頁面數

五百這個數字被誤解得最厲害。免費版的上限計的是本次量測實際抓到、去重之後的不同網址，不是頁面數，也不是請求次數：圖片、樣式表、指令碼、轉址鏈中實際處理到的網址、帶參數的重複版本，都算在內。一個三百頁的網站，實際量測量可能是數千筆。頁面數會嚴重低估用量，拿頁面數判斷會不會撞上限，很容易失準。

↔ 左右捲動檢視完整表格

計入上限的項目	說明	對總數的影響
HTML 頁面	一般人理解的「頁數」，只是總數的一部分	直接計入
圖片、樣式表、指令碼	每個資源網址都是獨立一筆	大幅墊高總數
轉址中途網址	轉址鏈中實際處理到的不同網址各計一筆	墊高總數
帶參數的重複版本	追蹤參數讓同一頁變成多筆	墊高總數並污染報表

估算的方法很樸素：先量一個子目錄，看資源與重複版本把總數墊高到什麼程度，再推全站規模；用清單模式餵一組已知網址做局部盤點時，計算範圍就只限這份清單與其資源。這比憑頁面數猜測可靠得多，也順便讓你看見自己網站的重複版本氾濫到什麼程度。

要不要付費，除了網址數，還要看功能需求。官方常見問答把界線畫得清楚：免費版有限制，渲染、自訂擷取與 API 整合等功能需要授權，授權按使用者計價，方案結構列在官方定價頁；移除五百筆上限之後，量測規模仍受本機硬體影響，沒有無限這回事。判斷順序是：先用免費版把基本問題查一遍，確實需要進階功能、或網址總數真的超過上限，這筆授權費才有名目。

免費版的對策有兩條：子目錄分批量測，或用清單模式餵一組已知網址做局部抽查。抽查終究是抽查，不能替代全站盤點，分批結果也缺跨目錄的關聯，結論要註明範圍。還有一件事要說清楚：Include、Exclude 這類範圍設定屬於授權功能，不是繞過上限的後門。工具預算怎麼排、有沒有中文介面的選擇，可以併進中文工具比較的視野一起評估。

按下開始之前，先回答三個取證問題

同一個網站，兩個人量出來的結論可能差很大，因為設定直接改變爬蟲看見的世界。按下開始之前，三個問題先回答清楚，報告才解釋得通，比較才有意義。

讓爬蟲扮演誰

預設遵守 robots 規則，量的是守規則的檢索器視角；關閉遵守，量的是無視封鎖的視角。兩種都是合法證據，意義不同：前者貼近一般搜尋爬蟲的處境，後者用於檢視被擋住的部分。診斷時要知道自己取的是哪一種，混用會讓結論失去解釋力。還要記得兩個前提：這套軟體不是 Googlebot，模擬不了 Google 完整的檢索與索引處理；清單只涵蓋本次設定下找到的網址，超出這個範圍的說法都是推測。

讓爬蟲看到什麼

請求打出去，先拿到的是靜態 HTML；瀏覽器端的 JavaScript 再把它變成你看到的畫面。量測條件的選擇就落在這個分層：目標欄位住在原始回應裡，靜態模式就夠；欄位要靠腳本執行才存在，才需要切換渲染模式。渲染會增加量測的時間與資源需求，幅度依網站與設定而異，開了就要核對結果是否如預期，取捨的背景知識在JavaScript SEO。永遠開或永遠關，都是把選擇權交出去。

自訂擷取是靜態回應與渲染這組分層裡最實用的延伸。依官方設定文件的說明，擷取預設從回傳的靜態 HTML 取資料，欄位若由瀏覽器端腳本產生，才需要切到渲染模式並核對結果；定位方式支援 XPath、CSS Path 與 Regex，不是只抓畫面上看得到的文字。用得好，量測升級為資料收集：全站的價格欄位、發佈日期、結構化資料欄位、圖片替代文字，一次盤成清單，後續應用不受 SEO 限制。

範圍劃到哪

參數的處理要看目的。例行盤點時把追蹤參數收斂掉，同一頁不會被拆成多列，報表乾淨好讀；要調查重複版本時反而留著，讓多列現形，才知道同一頁被參數拆成幾種樣子、嚴重到什麼程度。範圍同理，用子目錄或清單框住，量得快，但結論的有效範圍也跟著縮小，每份報表都該寫清楚自己的邊界，這是報告可信度的來源。

量測結果出現「畫面上有、報表裡沒有」的時候，除錯順序照這三題走：先查渲染設定，再查範圍，再查 robots 與連結可發現性，以及授權狀態。常見的「軟體壞了」，答案多半在這幾個地方。

報表要被修掉，先換掉交付的單位

量測做完，真正的難題才開始：怎麼讓問題被修掉。挑一個發現，把它寫成工程師能直接開工的單位：哪批網址、在什麼條件下量到什麼、預期改成什麼狀態、驗收時怎麼重現。例如「產品頁樣板整批網址的標題欄位空白，靜態模式量得；預期每頁補上專屬標題；驗收是同設定重爬，這批網址的標題欄位不再空白」。重現條件、責任範圍與驗收證據到齊，單子才進得了排程，缺任何一角，它就會停在待辦裡。把每個發現整理成這種單位，是量測者自己的工作，沒有人會代勞。

欄位拆開來看：證據交代問題網址與資料來源，目標寫明預期修正成什麼狀態，重查指定驗收方式，修完用相同條件再量一次，確認問題是否解除。接手的人需要可以分工、可以回報完成的單位，不是一份還要另行分析的原始資料。

↔ 左右捲動檢視完整表格

欄位	要寫什麼	舉例
問題網址	受影響的頁面或樣板範圍	舊文章目錄整批
證據來源	量測報表與篩選條件	回應碼清單篩出 404
修正目標	預期改成什麼狀態	選單與相關文章改連新網址
重查方式	驗收條件與再量測方式	同設定重爬，站內連向舊網址的連結歸零

軟體的 Issues 面板要正確理解。面板把發現分為 Issue、Warning、Opportunity 三類，加上高、中、低優先級；照官方面板說明的定位，這些是查核方向的提示，不是期限，也不該直接抄成待辦。什麼時候修、修到什麼程度，來自你對修正成本、牽連頁數、頁面重要性的判斷；分級用處理時程呈現就好：當週急件、當月排程、觀察名單。常見的誤讀順手避開：把刻意設定的 noindex 當錯誤回報，把字數建議當截斷的硬規則，兩者都會浪費工程團隊的信任。

開單用樣板思維。同一個頁面樣板的問題，修一處等於修數百列，工單按樣板開、不按網址開，一個問題一張單，接手的人才能分工。工單上的語言也要切換：工程師需要的是重現條件與預期行為，不是 SEO 術語。與其寫「這頁有 canonical 問題」，不如寫「這批網址的標準網址標記指向測試網域，預期改指正式網域，重查時這批網址的標準網址欄位應全部顯示正式網域」。前一種寫法把預期留在你自己腦裡，對方還得回頭來問；後一種把重現條件與預期行為寫齊，工程師看單就能動手。

先修什麼，可以從一份研究抓方向：Ahrefs 的標題標記研究（2021 年 11 月）分析過搜尋結果前十名合計近百萬個網址，約 7.4% 連標題標記都沒有。這個數字說明缺標題的頁面未必進不了前段，搜尋端會自己補上替代文字；只是補出來的那句話，未必是你想講的訊息。把標題與描述補齊，成本低、確定性高，適合排進第一批工單，寫法參考標題標記的寫法，完整的優化方法在站內優化指南。

修完還不算結案：重查與收錄佐證

「應該修好了」不等於結案。一般的驗收方式，是用與初診相同的設定、相同的範圍再量一次，比對問題狀態是否解除；如果被修的正是量測設定本身，就把設定變更記錄下來，另安排一次對照量測。站內的修復，用站內的重查結案就夠了；搜尋端收錄後來怎麼變化，屬於另一份獨立觀察，兩者之間有時間差。把收錄變化列為追蹤項目，別把它當成驗收條件，先講清楚這個分界，才不會有人天天盯著報表問為什麼還沒反應。

重查報表的讀法有個紀律：新舊問題分開看。核對工單上的項目是否解除，用初診的問題清單逐項比對；同期間新冒出來的問題，單獨開單處理，不要混進同一份驗收裡。混著看有兩個壞處：修好十項、新出現三項，看起來像沒修乾淨，功勞被埋掉；新問題藏在一堆舊數字裡，也不容易被發現。

量測的節奏由網站的變動頻率決定，不由日曆決定。模板部署、大規模改網址、分類整併、外部系統交接，這些事件各觸發一次量測；變動少的站，間隔自然拉長，變動密集的站，間隔就跟著縮短。單次報表累積成序列，問題越早現形，回溯原因的成本越低。盤點結果回饋內容排程，哪些主題該更新、哪些舊文該整併，接上內容年度更新的規劃，技術量測就從一次性任務，變成經營節奏的一部分。軟體的功能清單也會一路往長（官方更新紀錄）；這類改版對已經建立節奏的團隊負擔不大，新的檢查項目就當成免費多出來的視野，併進下一輪量測就好。

不必硬用爬蟲解的問題，交給對的工具

知道何時停用，跟知道何時開用一樣重要。問題一旦回到關鍵字需求、排名走勢、反向連結或整體工具預算，爬蟲就該退場。按量測對象分工：站內即時回應給爬蟲，搜尋索引側給 Google 後台，外部資料庫的快照給各自的工具，不要拿一個工具去回答另一個工具的問題。

站內往外連的連結也需要保養：文章推薦的外部資源會下線、網域會搬家，讀者點出去撲空，傷的是內容的可信度。量測時順手把指向失效網域的連結標記出來，定期換上仍有效的替代來源，這是內容維護的固定工序，跟反向連結經營是兩件事。工具箱怎麼排預算、怎麼分工，工具橫向評比與SEO 軟體總覽提供更完整的視野，挑選標準回到你的症狀與團隊規模，工具的知名度不該排在前面。

回到開場那位行銷負責人。她後來交出的，是一份能同時向老闆與工程師交代的東西：按症狀排序的證據、幾張寫清楚驗收方式的工單、一個約定好時程的重查。頁數對不上，不一定代表故障，但每一筆差異都要能被解釋，報告才算讀完；放下判決書的讀法、照診斷順序走，紅字就只是待辦事項。下一次報表再冒出整排警示，她知道先看分布、再開單、再重查，這個順序就是她的答案。