SEO 流量下降怎麼查：8 個診斷步驟、關鍵詞波動七型與原因四級寫法

太長不看版： 流量掉了，第一個動作是查證，不是改網站。我們的診斷順序固定是 8 步：定幅度、定範圍、查比較基準、拆主機名、排除技術故障、看收錄、按搜尋引擎分、寫結論。最常把人帶錯方向的有兩個：比較基準本身異常（我們接手的一個 1 萬多篇影音內容站，一週 -27.9%，拉長到 8 週看才發現是前一週剛好是近 10 週最高），以及 GA4↗ 沒按主機名拆（站群合計 -20%，主域拆出來是 +57.5%）。判斷方向用「關鍵詞波動七型」，寫結論時把原因分成已確認、高概率、待驗證、已排除四級，不准寫「演算法波動」這種沒有證據的句子。

結論只能從資料往回推

流量掉了，第一步該查什麼？先別查，流量下降診斷的規則是結論只能從資料往回推：依序看資料變化、範圍、頁面、詞與頁面現況，最後才下判斷，不能先有答案再找數字。

流量下降時最常見的錯誤，是先有一個答案，再去找支持它的數字。有人一看到曲線往下就說「被演算法打了」，然後開始改標題、刪文章、調內鏈。等到真正的原因查出來，網站已經被改過一輪，前後的數據也混在一起，沒辦法判斷哪個動作有效。

所以我們把順序寫死：數據變化 → 變化範圍 → 具體頁面 → 具體詞 → 頁面現況 → 判斷。每一步都要有東西才能進下一步，不能跳。這條規則不是我們發明的，Google 自己的流量下降除錯指南↗也是先要你看下降的形狀與範圍，再談原因。

還有兩條原則跟著這個順序一起用。第一條是看絕對值，不只看比例。搜尋結果頁跌 50% 可能只少了 500 個點擊，文章頁跌 10% 卻可能少了 2 萬個。報告裡如果只寫百分比，大家的注意力會被最刺眼的那個數字拉走，而它不一定是最該處理的。

第二條是以線上為準。狀態碼、robots、canonical、sitemap 一律直接 curl 正式站。Search Console、Bing、Yandex 的報表都有幾天到幾週的延遲，拿它們推斷「網站現在是什麼狀態」很容易誤判。報表告訴你過去發生過什麼，線上才告訴你現在是什麼。

8 個診斷步驟，順序不能換

流量下降診斷的 8 步依序是定幅度、定範圍、查比較基準、拆主機名、排除技術故障、看收錄、按引擎分、寫結論，順序不能換。

這 8 步是我們在幾個大型內容站來回修正出來的。每一步要回答的問題和產出如下：

順序的道理是：前面的步驟成本低、排除力強，後面的步驟成本高。步驟 3 和 4 只要換一個日期區間、加一個維度就能做完，卻能推翻一半以上的「流量下降」。步驟 5 和 6 要逐頁檢查，花的時間多得多。如果一開始就跳去查收錄，常常查了半天才發現根本沒有在掉。

步驟 5 有一個細節值得多講。排除技術故障時，要檢查的不只是首頁，還有跌最多的那幾頁。首頁通常最受照顧，它正常不代表模板頁正常。檢查項目也要具體：狀態碼是不是 200、robots 是不是 index、canonical 是不是指向自己、這頁能不能被抓取。哪一項不對，問題就很可能在那裡。這部分的基礎設定可以對照 robots.txt 與索引設定，大型站的頁型規範則寫在大型網站索引管理那篇。

比較基準陷阱：有時候不是這週掉，是上週太高

流量下降有時是比較基準太高的假象：1 萬多篇的影音站週減 27.9%，拉 8 週日資料才發現被比的那週是近 10 週最高。

這是我們最常遇到、也最容易讓人白忙的情況。我們接手的一個 1 萬多篇的影音內容站，某週報表顯示比前一週少了 27.9%。看起來很嚴重，已經超過 10% 的專項門檻。

但把每日數據拉到 8 週一看，答案很清楚：被拿來比的那一週（9/27–10/3）是近 10 週最高的一週，下降的主要原因就是基準太高。長假也會把基準墊高，日期剛好落在假期前後時要特別留意。如果只看週對週，接下來那一輪的調整全部都會是在修一個不存在的問題。

所以步驟 3 的做法是固定的：不要只拿上一週比，至少拉 8 週的日數據，看這週落在曲線的哪個位置。再對一下日曆，前一段有沒有假期、活動、新聞事件。週對週的比較只適合當警報，不適合當結論。

主機名的陷阱跟這個很像。另一個內容站的 GA4 顯示站群合計 -20%，但按主機名拆開，主域其實是 +57.5%。下降的是鏡像網域，主站在漲。還有一次是 Google 流量從主域流到 CDN 直連網域，直連網域的工作階段從 708 漲到 1,693，主域看起來就像在掉。兩種情況，網站本身都沒有出問題，只是流量換了一個門牌號碼。

GA4 拆主機名用的是內建的主機名稱維度，各個維度的定義可以查 GA4 維度與指標說明↗。還有一個交叉檢查很好用：如果 GA4 在掉，但 Search Console 的點擊是穩的，先別懷疑 SEO↗，先去查埋點、歸因設定和跳轉。這時候兩邊在量的根本不是同一件事。

關鍵詞波動七型：先看是哪一型，再決定往哪查

關鍵詞波動分成七型，包含曝光降排名穩、曝光與排名皆降、大量詞同步降等，先判斷屬於哪一型，才知道該往哪個方向查。

定完範圍之後，下一步是判斷方向。我們把關鍵詞的變化歸成七型，每一型指向不同的調查方向：

第 1 型最常被誤讀。排名沒動、曝光少了，代表你的位置還在，只是那個詞的搜尋量下來了。這種情況改頁面沒有用，因為頁面不是原因。該做的是確認需求下降是季節性的、事件性的，還是長期趨勢，然後決定要不要把資源移去別的詞。

第 6 型則是最需要克制的一型。幾百個詞一起掉，直覺是一個一個去看、一個一個去改，但同步下降幾乎都有一個共同因素：某個模板改了、canonical 被批次設錯、內鏈結構動了，或一批頁面掉出索引。逐詞改不只沒效，還會把真正的原因蓋掉。正確的做法是把下降的詞對應回頁面，看這些頁面有什麼共通點。

第 7 型常被忽略，流量漲的時候沒人想查。但漲的原因如果寫不出來，下次就沒辦法複製。我們要求上漲也要寫出條件：哪類頁、哪些詞、做了什麼改動、時間是否對得上。

看起來是問題、其實不是的五種情況

看起來像流量問題、實際上不需處理的情況有五種，共同點是量測方式造成的錯覺，例如抽樣換批、站群合計混了不同網域。

這張表是從實際巡檢裡累積下來的。每一條都曾經讓人緊張過，查完才發現不需要處理：

這五條有一個共同點：都是量測方式造成的錯覺，不是網站本身的變化。抽樣換了樣本，問題數就會跳。拿 curl 去打需要簽名的網址，當然會失敗。合計數字把不同網域混在一起，方向就可能相反。看到異常時先問「我是怎麼量到這個數字的」，常常就能省下一整輪調查。

抽樣這件事要特別小心。URL Inspection 一次抽十幾條，只能用來發現問題，不能用來下全站結論。要講收錄率，一定要拿全量的索引報表對照。標籤頁這類大量頁型的判讀方式，我們在標籤頁治理那篇有更完整的說明，包括核心標籤還在索引時，代表的是排名掉而不是被移除。

只有一個搜尋引擎異常，就只修那個引擎

只有一個搜尋引擎異常時，就只做該引擎的專項、不動全站設定，因為大型站同時吃多個引擎的流量，改全站可能修好一邊弄壞兩邊。

步驟 7 背後是一條原則：只有一個搜尋引擎異常，就只做那個引擎的專項，不動全站結構。我們有兩個案例都是這樣處理的。一個是 Bing 持續回報 5xx，但 Google 和其他引擎抓取都正常。另一個是內容站的自然流量 -38%，這個站 85% 的自然流量來自 Yandex。

第二個案例發生在 2026 年 10 月，查法是：先看 Yandex 的可搜尋頁數有沒有降。結果沒有降，所以「頁面被大量移除」可以排除。剩下的方向是人名類關鍵詞的熱度回落，這一項目前只有相關性，所以標成待驗證。整個過程沒有動任何全站設定。

為什麼不能為了一個引擎改全站？因為大型站通常同時吃好幾個引擎的流量。為了修 Bing 的抓取去改 robots、改 canonical，Google 和 Yandex 也會一起被影響，結果可能是修好一邊、弄壞兩邊。各引擎的規則也不完全一樣，Bing 有自己的站長指南↗，Yandex 對 robots meta 標籤↗的支援也和 Google 不同。真的需要只針對 Google 的動作，可以用 Google 的 robots meta 規範↗裡的 googlebot 標籤，其他引擎不受影響。這個做法在大量內容剪枝那篇有實際用法。

結論怎麼寫：原因分四級，「暫不調整」也是方案

流量下降的結論要把原因標成已確認、高概率、待驗證、已排除四級，「暫不調整」也是方案，但要寫明原因、指標、期間與觸發條件。

步驟 8 寫結論時，每一個原因都要標出證據等級：

「已排除」這一級最常被省略，但它其實最有價值。寫出「已排除被移除：Yandex 可搜尋頁數沒有降」，下一個接手的人就不用再查一次。也讓看報告的人知道，你不是只列了自己想到的原因，而是把可能性一條條關掉了。

同時有幾句話是禁止出現在結論裡的，例如「演算法波動」「內容深度不足」。不是說這些不可能是原因，而是這種句子沒有附證據，沒辦法驗證也沒辦法推翻，寫了等於沒寫。真的懷疑是品質問題，就要寫出比對了什麼、看到什麼差異，然後放在對應的等級裡。

最後是方案。「暫不調整」是有效的方案，比較基準造成的假下降、只是需求回落的第 1 型，常常就該這樣處理。但它不能只寫四個字，要寫清楚四件事：為什麼不改、要觀察什麼指標、觀察多久、出現什麼條件才動手。沒有這四件事的「暫不調整」，其實只是不想處理。

拿前面 Yandex 那個案例套進格式，結論的骨架大概長這樣（觀察天數與升級條件是範例寫法，依你的站調整）：

現象：自然流量 -38%（附來源與拉取日期）
範圍：這個站 85% 自然流量來自 Yandex
已排除：頁面被大量移除（Yandex 可搜尋頁數未降）
待驗證：人名類關鍵詞熱度回落（只有相關性）
方案：暫不調整全站設定，只做 Yandex 專項
觀察：Yandex 可搜尋頁數、核心詞曝光；寫明觀察天數，以及「可搜尋頁數開始下降就升級處理」這類條件

這套流程本身不需要特殊工具，Search Console、GA4 和 curl 就夠了。真正難的是每次都照順序走，不在第二步就跳到結論。如果你想把這套診斷和每週監控放進固定流程，可以參考我們的 SEO 作業系統。sitemap 讀取狀態這類收錄面的基礎，則在 sitemap 完整指南。需要有人長期替你的網站盯數據、在掉的時候照這 8 步查清楚，可以看看我們的 SEO 建站與代營運服務。

這篇是大型網站 SEO 指南的其中一章，六個工作面的全貌和接手第一週的處理順序都整理在那裡。

常見問題

流量掉多少才需要處理？

±5% 以內先觀察。5–10% 要查來源和下降最多的頁面。超過 10% 開專項處理。另外，連續 3–7 天都在下降，即使每天幅度不大也要看，因為緩慢下滑比一次性的跳水更容易被忽略。

Search Console 和 GA4 的趨勢不一樣，要信哪一個？

先不要選邊。GA4 在掉但 Search Console 點擊穩，通常是埋點、歸因或跳轉的問題。再來要確認 GA4 有沒有按主機名拆，站群合計和主域常常方向相反。兩邊對齊之後，再判斷是不是 SEO 的問題。

為什麼週對週的比較不夠？

因為上一週可能本身就不正常。我們遇過一週 -27.9%，拉到 8 週日數據才看出主要是前一週剛好是近 10 週最高。假期也會把基準墊高。週對週適合當警報，結論要放回更長的曲線裡看。

只有 Bing 或 Yandex 掉，要不要改網站結構？

不要。只有一個引擎異常，就只做那個引擎的專項。改 robots 或 canonical 會同時影響其他引擎，很可能修好一邊、弄壞另一邊。

結論裡可以寫「演算法更新」嗎？

可以提，但要有證據並標上等級。只有時間點吻合，就是「待驗證」。「演算法波動」如果沒有任何證據支持，就不應該出現在結論裡。

---

了解我們的廣告策略與投放服務 →