SEO 常見錯誤的另一面：讓排名下滑的常是日常維護

週一早上九點，行銷負責人打開報表，自然搜尋流量比上個月少了三成，曲線已經連著四週往下走。把時間軸往回拉，找不到明顯的事件點：沒有收到任何違規通知，沒有換主機，結帳流程也沒動過。三週前團隊剛完成年度內容整理與改版上架，會議紀錄上寫的是「網站變整齊了」，當天沒有人反對。

接下來的討論很典型：主管問是不是被 Google 懲罰、要不要加買反向連結、要不要再生產一批新內容。房間裡的力氣全往外找答案，追演算法傳聞、懷疑對手搶走版面、猜測某次更新改了規則，越查越亂。這些反應共享同一個前提：把排名下滑當成外來的懲罰。前提換掉，調查方向就會翻面，因為可修復的下滑，源頭經常是自己幾週前那個看起來很正常的維護決定：下了一個指令、搬了一組網址、刪了一批頁面、把基礎做了半套、衝了產量，或者只是很久沒有走進報表。

要不要緊張，先看一個背景數字。Ahrefs 針對上百萬頁面的大規模研究追出的結論是：能從 Google 拿到搜尋流量的網頁，比例不到一成（2023 年 12 月資料）。「做更多」與「被看見」本來就是兩件事，量產內容換不到能見度；診斷的對象從來不是全站平均值，而是「曾經有、現在沒有」的那批頁面，找出把它們從有變成沒有的那個開關，比對著大盤焦慮有用得多。

檢查的順序可以借用一張簡單的地圖：搜尋引擎要推薦一個網頁，先要讀得到，這一關取決於爬取與索引；讀到之後要讀得懂，這一關取決於訊號與品質；讀懂了還要比得贏，這一關取決於需求與競爭頁面。最常被改壞的五類輸入，就落在這三道關卡上：索引被擋、正本錯亂、砍頁失血、體驗做半套、產量失焦。接下來依序走過五個檢查點，每一站給檢查動作、判斷依據、處置選項與驗收訊號，收在一張症狀對應處置的決策表，與一套以三個月為單位的觀察節奏。

快速重點：流量下滑先分流再動手，可修的源頭多半在站內輸入。抓取與收錄是兩個開關；正本網址逐頁判斷；刪頁前算需求、內鏈、外鏈三筆帳；綠燈要看欄位資料；新增頁面大量掛零就停手；每月看三個報表訊號。這些輸入壞掉時，都不會跳出警告。

流量下滑的第一現場：先分流，再動手

遇到曲線往下，先回答三個分流問題，再決定檢查順序。第一個分流是範圍：掉的是單一頁面、一組頁面，還是整個網站。單頁下滑多與該頁的指令、內容或連結有關；整站下滑才需要往技術層、演算法層與需求層查。第二個分流是速度：某一天斷崖式下墜，與連續數週緩跌，指向不同原因，前者常與指令變更、轉址錯誤或主機事件有關，後者更像內容老化或競爭位移的慢性變化。第三個分流是時間點：下滑起點前兩週，自己或團隊動過什麼，改版、砍頁、換外掛、調整網址結構，把變更日期逐一記下，對照曲線的轉折點，兩者重疊的位置就是第一順位的嫌疑犯。

分流做完，多半就能把「被懲罰」先放到一邊。Google Search Central 的文件把技術問題、內容變化、演算法更新與搜尋需求變化列為不同的診斷路徑，也明確提醒流量下滑不能直接等同手動處置：真正的判決會在報表留下紀錄，查得到、看得到；查無判決的下滑，才需要沿著自家的變更紀錄往下找。人工判決與自然衰退的外觀也不一樣，前者影響範圍明確、常伴隨特定頁面的整批消失，後者多是緩慢下沉、找得到起點卻找不到通知。先確認有沒有判決紀錄，再決定把力氣花在哪一邊，兩者的處理方式完全不同。

地圖在這裡派上用場。搜尋引擎推薦一個網頁的過程，可以拆成讀得到、讀得懂、比得贏三道關卡：索引被擋與正本錯亂發生在第一關，頁面根本沒進入評估；砍頁失血橫跨第一與第二關，節點消失同時影響抓取與主題訊號；體驗做半套與產量失焦主要在第二關，讀得到的頁面送出變差的品質訊號；報表判讀則是把三關的狀況換成可以追蹤的數字。之後每個檢查點都會標明它掛在哪一關，檢查完就知道自己修的是管線的哪一層，修錯樓層的常見後果是花了很多力氣，曲線依然不動。

分流與地圖之外，還有一個低成本的習慣能省下大量時間：變更日誌。把每一次改版、砍頁、調指令、換外掛的日期與範圍寫進同一份文件，附上負責人與原因。日誌的價值在於對照：曲線轉折的那一天，日誌上有沒有事件；日誌上的事件，曲線有沒有反應。有這份文件，多數下滑可以在幾分鐘內定位到候選原因；沒有它，只能靠當事人的記憶重建現場，而記憶對「看起來很正常」的維護動作特別不可靠。

兩篇延伸讀物分工清楚：技術地基的完整排查，從主機、網址結構到爬蟲溝通，看〈技術性 SEO 完全指南〉；把錯誤按戰略、內容、技術、連結、數據分層自查的架構，看〈SEO 常見錯誤五層健檢〉。那篇給分層地圖，這篇給診斷動線，互相接引而不重複。

抓取與收錄是兩個開關：四種不會出聲的擋法

頁面明明上線了，搜尋引擎卻不收錄，問題常出在四種不會發警告的擋法：robots.txt 封鎖沒有解除、noindex 殘留、搬家後轉址出現斷點、sitemap 失聯。理解這四種擋法的前提，是分清兩個開關的層級：robots.txt 管能不能抓，noindex 管抓了之後收不收，兩者在不同層作用，卻會互相蓋台。機制上，robots.txt 封鎖讓爬蟲連頁面都讀不到，meta 裡的 noindex 指令形同未下達；想控制收錄，卻先把讀取的門關上，指令就永遠送不到對方手裡。

開發期的封鎖，上線後忘了解除

最常見的劇本發生在上線那天。開發期間為了不讓未完成的頁面流入索引，團隊用 robots.txt 把整站封鎖；正式上線改用 noindex 管理特定頁面，卻沒有人回頭把那條封鎖刪掉。結果是爬蟲進不了頁面，頁面裡的 noindex 指令從未被讀到，而只要其他頁面的連結指得到它，網址仍可能以沒有內容的條目形式流入索引，等於兩頭落空。檢查的動作很樸素：打開根目錄的 robots.txt 逐行讀，確認封鎖範圍沒有涵蓋正式頁面，並核對上線清單裡有沒有「解除封鎖」這一項。兩個開關的正確分工與設定細節，〈robots.txt 與 noindex 的比較〉有完整拆解。

noindex 本身是正當工具，用對地方能省下可觀的抓取資源：站內搜尋結果頁、篩選器組合出的參數網址、沒有獨立價值的標籤彙整頁，都適合主動排除。要避免的只有兩種情況：把 noindex 留在已經該收錄的頁面上，以及用 robots.txt 擋掉希望被讀取的內容。指令沒有好壞，放錯位置的指令才是問題。

搬家的斷點，藏在舊網址裡

搬家與換網域是最容易留下斷點的維護動作。舊網址下架時少了 301，訪客與爬蟲都拿到 404；或轉址設了，幾次改版後累積成舊網址跳新網址、新網址又跳另一個網址的鏈，每一跳都是一次重新排隊。驗收的動作是把舊網址清單逐一打開，確認每一個都一跳到底，同時更新 sitemap 裡的網址。WordPress 站的搬家步驟與常見陷阱，整理在〈WordPress 網站搬家教學〉。權重移轉與重新收錄需要時間，沒有固定時程，搬完後的第一個月，定期核對索引狀態比盯流量數字有用。

sitemap 失聯，修復成本最低的一個

四種擋法裡，sitemap 失聯是成本最低的修復點。網址結構改了，sitemap 還列著舊網址，或提交的資源已經失效，搜尋引擎發現新頁面的速度就取決於隨機的連結漫遊，修復的成果也要更久才被讀到。把 sitemap 重新產生、提交，並在每次結構調整後同步更新，是投資報酬最划算的例行工作，完整做法見〈Sitemap 的產生與提交〉。它不會讓內容變強，但決定了每一個修復訊號能多快被讀到。

四種擋法都不會主動通知，只能從報表反推。GSC 的網址檢查工具會顯示 Google 上一次抓取時實際讀到的 robots 與 canonical 指令，等於直接看到搜尋引擎眼中的那一頁；索引報表可以下載已建立、未建立、已排除三份清單，把排除原因彙總，系統性的指令錯誤會自己浮出來，例如整個目錄被封鎖、某類頁面全部宣告了同一個正本。名單比百分比有用：知道哪些頁面、什麼原因，才有辦法修；收錄比例下降本身只是症狀，不是診斷。操作的順序建議固定：先看單一網址的檢查結果，確認指令層沒有問題，再拉整份清單看規模，單點與全面兩種視角交替使用，才分得清楚是單頁的設定錯誤，還是範本或外掛造成的系統性預設值問題。

相似網址誰是正本：canonical 是逐頁判斷的第三票

同一份內容有多個網址版本時，誰是正本就成為問題。canonical 的機制是讓頁面自己宣告正本在哪裡，等於投出代表權的一票；重複的認定發生在網址與網址之間，所以這票要投得準，前提是逐頁判斷，不能只用一條規則套滿全站。協定版本、參數版本、分頁、列印用的頁面，每一種組合的重複認定都可能不同，先分清楚手上這批網址屬於哪一種，設定才有依據。

先看一個模擬情境。中型電商改版後，佈景主題的預設值讓全站商品頁的正本宣告一概落在首頁，站長半年後盤點才發現：商品頁的長尾查詢長期歸零，首頁也沒有因此變強，因為首頁的內容跟那些查詢無關。集中投票的機制被誤用時，傷害是雙向的，該拿流量的頁面拿不到，收到訊號的頁面接不住。沒有人動過任何設定，訊號流向卻整個被改寫，這正是維護型問題的特徵：安靜、合規、而且每天都在發生。

canonical 的判斷單位是單一網址，不是整個網站。內容與另一個網址重複的版本，才把正本指向代表網址；帶查詢參數的網址要先確認內容是否與乾淨版本相同再決定；分頁的每一頁內容不同，通常保留自身網址作為 canonical，讓每一頁都可以被索引。把全站頁面一律指向首頁，等於宣告首頁以外的內容都不存在，這也是最常見的誤用。完整的設定原則與常見錯誤，整理在〈Canonical URL 完全指南〉。

把逐頁判斷變成可執行的批次動作，靠的是全站爬取。用站內爬蟲匯出每頁的 canonical 宣告與重複網址群組，協定版本、參數版本、分頁會自然分堆，這份清單就是修正的工作清單；改版後重跑一次，還能當作設定沒有跑掉的驗收。批次檢查比逐頁人工可靠，也把「 canonical 要逐頁確認」從原則變成排程裡的一個動作。

砍頁之前先算三筆帳：頁面是節點，不是檔案

內容本來就需要除舊佈新，問題出在把頁面當檔案看。頁面同時是內部連結的節點、主題覆蓋的一部分、外部連結的落地點，刪除一個頁面，這三個角色同時消失；低流量本身不足以決定刪除，因為流量只是結果，不是頁面價值的全部。動手之前先算三筆帳：這個主題還有沒有人搜尋、站內有多少頁面依賴它、站外有沒有連結落在它身上，三筆帳的答案決定頁面該留、該改，還是該收。

另一個模擬情境。在地服務網站每年固定整理內容，某一年把數十篇「看起來沒人看」的舊頁一次下架，沒有設轉址；幾週後整站曝光開始走低，幅度不大，方向卻一致。單看每一頁都是合理決定，疊起來卻是拔掉一整排節點：內部連結斷裂、主題覆蓋出現缺口、曾經指向這些頁面的外部連結全部落空。沒有任何人做錯單一決定，系統卻變弱了，這類傷害最難歸因，因為每一步都有整理的正當理由。

三筆帳各有查法：搜尋需求看搜尋建議、相關搜尋與後台查詢資料，確認是否還有人用這組字找答案；內部連結用站內爬蟲的匯出報表，統計有多少頁面依賴它傳遞主題與權重；外部連結交給 Ahrefs 或 Semrush 的反向連結報表。低流量本身不足以決定刪除，只要需求、內鏈、外鏈任何一筆仍有殘值，就先評估更新、合併或轉址，刪除留給三筆全空的頁面。即使誤刪，頁面多半救得回來，只是索引與排名要重算，費時而且未必回到原本的水位。

這裡有一條推論界線要劃清楚。Google 負責爬取基礎架構的團隊在官方說明中定位，爬取預算的管理特別與大型、快速變動的網站有關；單一篇頁面零流量，不能直接推論成整站的抓取資源被排擠。把「頁面沒表現」直接解讀成「浪費資源所以要刪」，中間跳過了需求、連結與內容重疊的逐頁確認，正是誤刪的起點；零流量也不等於低品質，一個頁面可以暫時沒有排名，卻仍在主題架構裡扮演角色。

三筆帳算完，處置分成四個選項：更新、合併、轉址、刪除，刪除排在末位。內容仍符需求只是過時的頁面，更新的回收速度通常最好；內容互相重疊的頁面群，合併成一篇更完整的母頁；確定下架但仍有連結或舊書籤流量的頁面，設 301 指向語意最接近的存活頁，全部導向首頁會被視為實質上的找不到頁面。依官方對轉址的說明，轉址鏈的成本在於抓取排隊與等待，能一跳到底就一跳到底；301 與 302 的選擇邏輯與常見誤用，見〈301 與 302 轉址的選擇〉。

善後比下架本身重要。同步修復指向舊網址的內部連結、更新 sitemap、記下這批網址的變更日期，之後才能對照報表驗收；誤刪的頁面固然救得回來，排名要重新累積卻是另一回事，時間與結果都沒有保證。改版或重新設計時，視覺過時是更新的理由，不是刪除的理由，這條判準能擋掉多數不必要的下架；版面層面的常見問題，可對照〈網頁設計的常見錯誤〉逐項排查。

綠燈不代表沒事：HTTPS、行動版與分數的三個下半套

基礎項目的風險不在完全沒做，在做一半。憑證裝了但雙版本並存、行動版做了但沒有用真的手機走過、分數綠了但看錯了報表，這三種下半套都不會顯示為錯誤，只會反映在差一點的排名與說不上來的體驗問題上。判斷的標準要從「有沒有」換成「完整性」，這一節的三個檢查點才會有意義。

HTTPS 的兩個半套症狀

HTTPS 自 2014 年起被列為排名訊號，官方定位是門檻型的訊號，安裝憑證是基本功，不是加分魔法（見官方公告）。半套的第一個症狀是雙版本並存：https:// 開得了，http:// 也還活著，而且沒有自動轉址，兩個版本各自累積連結與資料，訊號被拆成兩半，外部連結如果連的是舊版本，價值就落在不想要的那一邊。另一個症狀是混合內容：加密只蓋住頁面骨架，圖片或腳本仍用 http:// 載入，瀏覽器把鎖頭換成不安全提示，訪客在讀到內容之前就先看到警告。修復清單不長：強制轉址、改寫資源網址、更新 sitemap 與 canonical、在 GSC 新增 https 資源；憑證的種類與安裝，見〈SSL 憑證的選擇與安裝〉，HTTPS 與排名的關係整理在〈HTTPS 的 SEO 影響〉。

行動版是評分的現場

行動優先索引已經全面實施，搜尋引擎評估的依據是行動版的呈現（見2023 年 10 月的官方公告）。流量結構也在同一邊：Statista 的統計顯示，全球網站流量裡，行動裝置占超過六成（2026 年 4 月）。只用桌機檢查網站，等於隔著玻璃看考場。實測三步驟：用行動網路、不接 Wi-Fi，打開最常被搜尋的三個頁面，計時到可以開始閱讀的秒數；每一頁從頭滑到尾，找被截斷的文字、超出螢幕的圖、要兩根手指才點得到的按鈕；在頁面中段停下互動一次，看版面會不會跳動。十分鐘走完，常能抓到坐在桌機前永遠不會發現的問題。

實測找到的問題，多半集中在幾個來源：表格與圖片沒有做伸縮處理、按鈕沿用桌機的尺寸、彈窗蓋住正文又找不到關閉鍵、字級與行距以桌機標準直接套到小螢幕。這些不是搜尋引擎直接懲罰的項目，卻決定訪客讀不讀得下去；修復的優先順序以擋住內容的問題為先，樣式差異放後面，把有限的心力花在真的會把人推走的地方。

分數在實驗室，體驗在欄位

Core Web Vitals 以 LCP、INP、CLS 三項指標衡量載入與互動體驗（指標定義見 web.dev 的文件）。測速工具跑出全綠，只代表受控環境裡的模擬過關，那是實驗室資料：指定的設備、指定的網速，同樣的條件可以一再重現，適合定位問題與除錯，卻代表不了訪客的真實體驗。

兩種資料的來源不同，回答的問題也不同。實驗室資料在受控環境用指定的設備與網速重現載入過程，適合重現問題與除錯；欄位資料來自真實 Chrome 使用者的實際造訪，判定基準是 75% 的造訪是否達標，反映訪客真正的裝置與網路條件。實驗室綠燈、欄位紅燈的組合並不少見，多半發生在訪客以手機與不穩定網路為主的網站；兩份報表要一起判讀，指標定義與優化手法整理在〈Core Web Vitals 完全攻略〉，web.dev 的說法也一致：速度重要，因為它影響的是真實的人，不是分數本身。

邊界同樣要說清楚：頁面體驗訊號與既有排名系統共同評估（見2020 年 5 月的官方說明），不單獨決定排名，把分數當萬靈丹或完全無視它，兩種態度都偏了。分數壓不下來時，往主機回應、圖片壓縮與第三方腳本找，比反覆調整前端有效；每個環節的拆解與先後順序，見〈網站速度優化〉。

產量什麼時候變成負債：停手的判斷線

「內容越多，被搜尋到的機會越多」，是聽起來合理的誤解。停手線看三個訊號：新增頁面大量掛零、前兩成頁面貢獻了絕大多數流量、底部一長排零流量頁面。當量產的薄頁開始稀釋整站的平均品質訊號，產量就從資產變負債；處置方向是合併、改寫或轉址收斂，把資源集中到需求還在的主題上，而不是繼續加頁面。

Backlinko 整理的排名因素研究（2025 年 4 月）把結論收在意圖契合與內容深度上，這兩項才是高排名頁面的共通條件。同一個查詢寫十篇薄薄的變體，各方面訊號都輸給一篇真正回答意圖的完整內容；數量在這裡沒有補償作用，頁面數增加的是維護面積，不是被推薦的理由。

關鍵字堆砌的現代變形

堆砌沒有消失，只是換了外觀。舊式的頁尾塞詞一眼就能認出，現代的堆砌句子通順、文法無誤，同一個詞換著句型反覆出現，讀完卻記不住任何資訊，這是為搜尋引擎而寫的特徵。判斷的方法很直接：把關鍵字遮掉，看這段話對人還有沒有資訊量。為查詢而寫，是看到字有量就生內容；為意圖而寫，是先問打這組字的人要解決什麼，再決定內容的形式、長度與深度。兩種寫法外觀相近，送出的訊號完全不同。

意圖定了形式。找定義的人需要一段直接的答案；找步驟的人需要可照做的順序與檢查點；要比較的人需要基準、條件與代價；準備購買的人需要規格、價格與風險。同一個主題對應到不同意圖時，拆成不同頁面各自回答，比擠在同一頁裡每樣都講一點來得清楚，也讓每一頁的訊號更集中，讀者與搜尋引擎都更容易判斷這一頁在回答什麼。

生成工具把產出通順內容的成本壓到接近零，第一手經驗卻依然難以量產，E-E-A-T 裡的 Experience 正是通順與可信之間的差距來源。既有內容海的處理原則：需求仍在的主題保留，重疊的頁面合併，最強的幾篇用真實經驗改寫加深。判斷界線與砍頁那一節同一條：零流量不等於低品質，抓取資源的管理主要影響大型、快速變動的網站，多數網站該優先看的其實是需求覆蓋與深度。流量如何累積的完整拆解，見〈自然流量的組成〉。

大量依賴 JavaScript 渲染的網站，衝量之餘得先驗證爬蟲讀得到這些內容，寫給看不到的對象，產量再高都不會變現；渲染層的檢查方法，見〈JavaScript SEO 的基礎〉。

報表是聽診器，不是計分板：GSC 的三個早期訊號

報表欄位很多，每次先看三個訊號就好：排名與點閱率的背離、「已檢索，尚未建立索引」的規模與名單、軟式 404。工具免費，差距在讀法：狀態欄描述的是目前如何，不是判決書。介面還不熟的話，先從〈Google Search Console 的功能導覽〉開始。

排名還在，點擊在掉

頁面排名不變，點擊卻往下走，問題常出現在搜尋結果上的文案。Backlinko 的點閱率統計（2025 年 4 月）顯示，第一名的自然點閱率大約三成上下，之後快速遞減；標題與描述讓人不想點，等於把名次換來的曝光折價賣掉。調整的方向是讓標題講清楚這一頁給誰、給什麼，描述補上內容的限制與差異。搜尋引擎可能改寫標題，所以調整後要看曝光與點閱率的變化再決定下一步，不預設改幾個字一定有效。

「已檢索，尚未建立索引」要分開判斷

這個狀態的官方語意常被讀反。GSC 的說明文件把「已檢索，尚未建立索引」定義為目前狀態：Google 抓取過這個網址，但尚未建立索引，日後仍可能被收錄；它不是永不收錄的判決，也不能單憑這個狀態推論內容太薄或品質不足。要與 noindex、重複內容與正本網址的排除狀態分開判斷：先用網址檢查核對上次抓取與正本宣告，再看內容是否值得獨立收錄。真正需要留意的是長期且大規模的停滯，那才指向品質或指令的系統性問題。

名單怎麼清：把報表下載成清單，重要頁面優先處理，薄頁面對照產量那一節的停手線。逐頁確認收錄狀態的操作方法，見〈網頁收錄的查詢方法〉。

軟式 404 與監控的升級

軟式 404 的判準是回傳 200、內容實質上在說找不到；短頁面或下架頁不會自動成立，要看渲染後的實際內容。先看渲染結果，再決定回 404 或 410、補替代內容或修正訊號。這類頁面默默消耗抓取資源，又不帶來排名，把它們算清楚，等於幫下一輪的抓取騰出位置。

監控的升級路徑：從總點擊與總曝光兩個數字，升級成分層指標與逐頁收錄追蹤；各層該看什麼，見〈SEO KPI 的指標地圖〉。網頁索引報表各欄位的解讀順序，也有完整的報表導讀可以對照著走。

把檢查點接成一條動線：症狀對應處置的決策表

檢查點分散在各節，遇到狀況時需要一張按圖索驥的表。下面以症狀為列鍵：當流量在掉、一時不知該從何查起時，從第一列往下對，找到相符的症狀，照檢查動作與判斷依據走，通常就能鎖定問題出在評估管線的哪一層；每一列補上驗收訊號，修了之後看什麼數字判斷有效，直接寫在同一列裡。

表會用之後，順序比勤快重要。先恢復能見度，指令與網址層的修復讓頁面回到評估範圍；再止血，轉址與連結修復止住訊號流失；然後建立觀測，固定的報表節奏讓下一次異動有對照基準；體質與策略的優化放在觀測穩定之後。順序反了，常見的結果是邊修邊漏，每一步看起來都有做，曲線卻沒有反應。

修復順序與驗收：怎麼知道真的好了

修復有滯後性。重新抓取與處理的速度不受站長控制，變動的節奏也不會配合行事曆，觀察建議以三個月為一個單位，看的順序是：索引狀態先動，曝光跟著回溫，點擊與平均排名的變化落在後面。這是報表的閱讀順序，不是兌現時程；訊號沒有出現，回到診斷層核對哪個環節沒有修到位，比換一個偏方實在。修復也不保證回到原狀，能做到的是把輸入修對，讓評估在正常的時間尺度裡反應。觀察期間把每個修正動作的日期寫進變更日誌，曲線動了才知道是哪一個動作生效；同一時間改五件事再一起看結論，等於把驗收的因果關係拆掉，下次出問題還是只能猜。

月度健檢的固定菜單，走完大約一個上午：

1. 索引與指令覆核：下載索引報表清單，彙總排除原因，抽查重要頁面的網址檢查結果。
2. 轉址與搬家盤點：對照網址變更紀錄，確認轉址鏈沒有新增、舊網址沒有漏設。
3. 憑證與行動實測：無痕視窗測 http:// 是否自動轉址，行動網路實際走一遍重點頁面。
4. 內容需求覆蓋：檢查新增頁面的掛零比例，處置方向是合併與加深，不是再生產。
5. 報表節奏固定化：三個早期訊號走一遍，記下數字與變更日期，讓下個月有得比。

把這套節奏排程化、不再依賴記性，系統化的執行方法整理在〈SEO 執行的完整流程〉。已經在掉排名的網站，先照〈排名下滑的搶救分流〉區分技術、需求與版面變化，再做例行保養；兩種動作的目的不同，前者找原因，後者防復發。

這些修復考驗紀律，沒有新工具的話題性，也不會在一週內給出戲劇性的曲線。把注意力從「做更多」移到「修好輸入」，是累積資產的方向；涉及架構調整或大規模改版、內部沒有把握時，再考慮外部協助，Whoops 的網站健檢與顧問服務可以陪著把整條動線走完，自己照著走也完全可以。

動線走完之後，留下來的不只是修好的幾個問題，還有一套每次流量異動都能重走的檢查流程。先把漏水的開關關掉，再談加新東西；順序對了，修復才會累積，而不是不斷歸零。