太長不看版： 大型網站 SEO↗ 難的地方不在技巧，在規模。網址多到不可能逐頁看，所以每個決定都要能寫成規則批次執行。網域、搜尋引擎、執行人都不只一個，所以每個結論都要拆開來驗證。這篇先講我們接手的幾個大型內容站有哪六個共同特徵，再講六條不會變的原則（先數據後結論、原因分四級、看絕對值、單引擎問題只做單引擎、「暫不調整」也是方案、以線上為準），最後用六章摘要把索引管理、內容剪枝、標籤頁治理、流量下降診斷、分工與驗收、批量發文品質關卡串起來，每章都連到完整的那一篇。
大型網站跟一般網站差在哪：六個共同特徵
我們判斷一個網站算不算大型，看的不是流量，而是網址多到無法逐頁處理，這個差別帶出六個共同特徵。
這裡說的「大型網站」不是指流量大，是指網址多到沒辦法一頁一頁處理。
2026 年 9 月到 10 月，我們同時處理了幾個大型內容站。最小的一個是 1 萬多篇的影音內容站，另一個是 8 萬篇文章的內容站，還有一個 UGC 內容站的 sitemap 列了 45.8 萬個網址。題材不一樣、後台不一樣、團隊也不一樣，但我們在它們身上看到的問題重複度高得驚人。整理下來是六個特徵，而這六個特徵幾乎決定了整套方法論長什麼樣：
| 特徵 | 我們看到的實例 | 對 SEO 的影響 |
|---|---|---|
| 網址量極大 | 8 萬篇文章、45.8 萬網址的 sitemap、1 萬多篇影音頁 | 抓取額度是瓶頸，收錄率天生偏低 |
| 鏡像／直連網域多 | 一個站有 3 個鏡像網域，另一個有 CDN 直連網域 | 流量與收錄被分到別的網域 |
| 多搜尋引擎各自重要 | 一個站 85% 自然流量來自 Yandex | 只看 Google 會誤判 |
| 標籤／聚合頁失控 | 每篇中位數 13 個標籤、8,131 個標籤頁有曝光 | 容易被判成門頁或批量低品質頁 |
| 批量發文 | 每人每天 30 篇、多人同時發 | 模板性錯誤一次擴散到幾十篇 |
| 改動由他人執行 | SEO 寫需求，技術與運營排期 | 「已完成」的項目會被改回去 |
網址量極大是所有問題的根。Google 自己在大型網站的抓取額度說明↗裡講得很直接：網址量大到一定程度，搜尋引擎就不會每頁都抓、每頁都收。這時候「收錄率偏低」是常態，不是事故。真正要做的是決定哪些頁值得被抓，再把其餘的頁讓開。也因為量太大，任何「我們逐篇檢查一下」的方案都不成立，所有處理都要能寫成條件、按名單批次跑。
鏡像網域是這類站很特別的地方。鏡像通常是故意留給打不開主站的使用者，不是技術債。但它會把流量和收錄分走，GA4↗ 如果不按主機名拆，看到的數字方向可能完全相反。我們有一個站在 2026 年 9 月底的 GA4 站群合計是 -20%，拆出主網域來看其實是 +57.5%。另一個站在 2026 年 10 月中，Google 流量從主網域流到 CDN 直連網域，直連網域的工作階段從 708 漲到 1,693。主機名這個維度在 GA4 的維度與指標說明↗裡就有，只是很少人會在第一時間拆它。
多搜尋引擎這件事，做台灣市場的人特別容易忽略。我們接手的一個站，85% 的自然流量來自 Yandex。幾個鏡像站則有百度和 Yandex 的流量。對這些站來說，只開 Search Console 做判斷，等於只看了一小塊。改全站結構之前，要先想到這個改動在其他引擎上會發生什麼事。
聚合頁失控通常是標籤。一個 8 萬篇的內容站，每篇文章的標籤數中位數是 13，前 10% 的文章掛到 18 個，有曝光的標籤頁多達 8,131 個。標籤頁是這類站非品牌流量的主體，也是最大的風險來源。
批量發文的風險是錯誤會成批出現。一個團隊每人每天發 30 篇、好幾個人同時發，一個模板錯誤就是幾十篇。這種錯誤靠人眼逐篇看是擋不住的，只能靠流程。
最後一個特徵最常被低估：改動由他人執行。SEO 寫需求，技術和運營排期上線，SEO 自己改不了程式碼。這帶來一個很具體的後果：已經標「已完成」的需求，過一段時間會被改回去。我們遇過一個站，2026 年 2 月已完成的「分頁第 2 頁 noindex」到了 10 月又變回 index。另一個站 3 月已完成的 VideoObject 結構化資料↗，10 月再去看已經不見了。
這六個特徵合起來，對方法論提出三個要求：規則要先於個案、證據要先於結論、驗收不是一次性的動作。下面六條原則就是從這三個要求長出來的。
六條基本原則
六條基本原則是先資料後結論、原因分四級、看絕對流量、單引擎問題只做單引擎、暫不調整也算方案、以線上為準。
這六條原則是後面所有章節的共同前提。每一條我們都違反過，而且每一次違反都付出了代價，所以把它們放在最前面。
1. 先數據，後結論
順序固定：數據變化 → 變化範圍 → 具體頁面 → 具體關鍵字 → 頁面現況 → 判斷。不准先下結論再回頭找數據。大型站的數據量足夠支持任何一種說法，你先有了結論，就一定找得到支持它的圖表。
2. 原因分四級寫
寫報告時，每個原因都要標級別：
| 級別 | 定義 |
|---|---|
| 已確認 | 有技術、數據或頁面證據 |
| 高概率 | 多個維度互相印證 |
| 待驗證 | 只有相關性 |
| 已排除 | 查過，可以排除 |
「演算法波動」「內容深度不足」這種寫法一律不准出現。它們不是原因，是放棄找原因。分四級的好處是讀報告的人一眼知道哪些可以動手、哪些還要再查，也逼寫報告的人誠實面對自己到底知道多少。
3. 看絕對流量，不只看比例
搜尋結果頁 -50% 可能只少了 500 個點擊，文章頁 -10% 可能少了 2 萬個。比例會讓小頁型看起來很嚴重，絕對值才告訴你該先處理哪裡。
4. 只有一個搜尋引擎異常，就只做那個引擎的專項
我們遇過兩次很典型的情況：2026 年 9 月一個站只有 Bing 報 5xx，其他引擎都正常。2026 年 10 月另一個站自然流量掉了 38%，拆開看 85% 是 Yandex。兩次的處理都一樣：只針對那個引擎查，不動全站結構。改全站結構去解單一引擎的問題，很可能把另外兩個引擎原本正常的流量一起賠掉。
5. 「暫不調整」是有效方案
不是每個下降都要動手。但「暫不調整」要寫清楚四件事：為什麼不改、觀察什麼指標、觀察多久、什麼條件出現才動。少了這四件，「暫不調整」就只是沒做事。
6. 以線上為準
狀態碼、robots、canonical、sitemap 一律直接 curl 正式站。Search Console、Bing Webmaster Tools、Yandex Webmaster 的報表都有幾天到幾週的延遲，可以用來看趨勢，不能用來推斷「現在」長什麼樣子。這條聽起來最基本，卻是最常被跳過的一條，因為後台報表打開就有，curl 要多做一步。
索引管理：先決定哪些頁值得被收錄
大型網站的索引管理，是先用頁型規範表決定哪些頁優先被收錄，再用四條 sitemap 規則與鏡像網域處理來落實。
大型站的地基是索引。網址量大到抓取額度不夠用的時候，該問的已經不是「怎麼讓所有頁都被收錄」，而是「怎麼讓值得排名的頁優先被收錄」。我們的做法是一張頁型規範表：首頁、分類首頁到第 5 頁、文章頁 index 並進 sitemap。首頁分頁、分類第 6 頁以後、標籤分頁、作者分頁、歸檔、站內搜尋結果一律 noindex, follow 且不進 sitemap。標籤頁滿 3 篇才 index。提需求前先對照這張表，符合就是有依據的需求，自己另訂標準就是跟團隊規範衝突。
sitemap 有四條規則，每一條都是踩過才寫下來的。第一，只放回 200、可索引的網址：一個站的 sitemap 裡有 5 個 301 到首頁的網址，結果 Google 從 2026 年 3 月起就沒再讀這份 sitemap，到 10 月重新提交才恢復。第二，子 sitemap 要讓 Google 全部知道：一個站有 46 個子 sitemap、45.8 萬個網址，Search Console 只提交了 9 個，Google 只認得約 10 萬個網址。第三，每天看「上次讀取」日期，超過 3 天沒讀就要查。第四，有流量的老頁不在 sitemap 要補回：一個站的 sitemap 只收某個 ID 以後的文章，517 篇有曝光的舊文不在裡面。規格面可以對照 sitemaps.org 的協定↗、Google 的大型 sitemap 說明↗，以及 Yandex 的 sitemap 說明↗。
鏡像網域的處理要先問業務，再決定手段，由輕到重有三種：鏡像逐頁 canonical 指回主站對應頁。鏡像加 X-Robots-Tag: noindex 讓使用者照常能用但不被收錄。確認鏡像不需要給使用者用之後才全部 301。如果只想讓 Google 不收某批頁，用 <meta name="googlebot" content="noindex, follow">，Bing、Yandex、百度都不受影響，寫法見 Google 的 robots meta 說明↗。頁型規範表全文、canonical 與 301 的細則、鏡像決策怎麼開會，都在大型網站索引管理：頁型規範、sitemap 與鏡像網域。如果你對 sitemap 本身還不熟，可以先看 sitemap 完整指南和 robots.txt 與索引控制。
內容剪枝：把抓取額度讓給有價值的頁
內容剪枝是用 16 個月資料分成 A、B、C 三層，只動確定沒流量的舊文，作用是讓出抓取額度，不直接帶來流量。
剪枝的第一步是分層，而且要用 16 個月的數據分，不是用直覺。A 層是核心：近 90 天有點擊，或貢獻了前 80% 的流量，列進保護清單，不改網址、不 noindex、不合併，只做加強。B 層是 16 個月內有一定點擊的頁，維持並視情況優化。C 層是 Google 16 個月都沒展示過的頁，要再拆：在其他引擎或鏡像有流量的不動，全無流量的舊文才是「只對 Google noindex」的候選，全無流量的新文先觀察。我們在一個 1 萬多篇的影音內容站上做這件事，C 層 9,528 篇拆出來是 4,977 篇不動、3,105 篇舊文進候選、1,350 篇新文先觀察。
剪枝有幾條紅線：不刪文章、不批量回 410 或 404（大批錯誤頁本身就是負面訊號）、不整批加 noindex。要做就按 ID 名單、只對 Google 做。另外報告裡要講清楚，剪枝的作用是把抓取額度讓給有價值的頁，它不會直接帶來流量。我們抽查 C 層時發現約一半是「已收錄但沒有任何曝光」，問題是排不上去，不是沒被收錄，這種頁剪了也不會讓誰的排名立刻往上跳。
重複內容合併要有硬證據。我們用的依據是影片 hash 完全相同，不是標題相似：只看標題會把不同日期的榜單、同一系列的不同段落、換了細節的不同影片都誤判成重複。按標籤配對抽查 50 組，真正同主題的只有約 6 組。Google 對重複網址的處理原則可以看合併重複網址↗。完整的分層門檻、合併後要從哪些地方把連結拿掉、連載系列為什麼不合併，寫在大量內容剪枝：A／B／C 分層與剪枝紅線。
標籤頁治理
標籤頁治理先鎖住貢獻前 80% 流量的核心標籤並做內容化，再合併變體、修正 noindex 規則，並限制每篇最多 6 個標籤。
一個 8 萬篇文章的內容站，標籤頁每天的點擊從 98,570 掉到 20,977，跌了 79%。拆開來看，問題的形狀很清楚：每篇文章標籤數中位數 13。只掛 1 篇文章的標籤佔 84%。8,015 個標籤頁用同一個標題模板。78% 的 description 不到 70 字。208 個核心詞被 2,904 個變體標籤包含。這些特徵加在一起，很接近 Google 垃圾內容政策↗裡描述的門頁和批量低品質頁。
治理順序是：先鎖住貢獻前 80% 流量的核心標籤（那個站是 697 個），只做內容化，自訂 title、140 到 160 字的 description、100 到 200 字的介紹、相關標籤連結。再把變體合併，有流量的 301 到主標籤，沒流量的從文章移除並保持 noindex。接著修 noindex 規則。分頁第 6 頁起 noindex。把整句標籤和涉及隱私的標籤從文章移除。最後在源頭限制每篇最多 6 個標籤、優先用已有標籤。
這裡最容易犯的錯是 noindex 規則。「只有 1 頁就 noindex」聽起來很合理，但它是按頁數判斷，不是按文章數。2026 年 10 月我們做全量標籤審計時發現，那個站因為這條規則，有 86 個標籤在 16 個月內點擊 ≥1,000 卻被 noindex。判讀也有一個關鍵：我們用 URL Inspection 抽查前 40 名的核心標籤，40 個全部還在索引裡，所以是排名掉了，不是被移除，方向是品質，不是技術。指標表、對照組怎麼讀，都在標籤頁 SEO 治理：判斷指標、治理順序與對照組。
流量下降診斷：八個步驟，加上「看起來是問題其實不是」
流量下降診斷固定走八步，從定幅度、拆主機名到按引擎分，並先排除看起來是問題其實不是的情況。
流量下降的診斷我們固定走八步：定幅度、定範圍、查比較基準、拆主機名、排除技術故障、看收錄、按引擎分、寫結論。幅度有門檻：±5% 以內觀察，5 到 10% 查來源和下降頁，超過 10% 做專項，連續 3 到 7 天下降就算幅度小也要看。
第三步「查比較基準」最常救命。一個站在 2026 年 10 月中看起來週對週掉了 27.9%，拉 8 週的日數據才發現，前一週剛好是近 10 週最高的一週，長連假也把基準拉高了。下降是真的，但沒有那麼嚴重，也不需要大動作。
關鍵字的波動也有固定的讀法。曝光降、排名穩，是需求下降。曝光和排名一起降，是頁面競爭力或索引。曝光穩、CTR 降，看標題描述或 SERP 版面。只有少數核心詞降，查蠶食或被替換。大量詞同步降，要找共同因素（模板、canonical、內鏈、索引），不要逐詞改。這套七型分類和 Google 的搜尋流量下降偵錯說明↗方向一致，但多了「按主機名拆」和「按引擎分」兩步，那是大型多網域站才需要的。
還有一類值得單獨列出來：看起來是問題、其實不是。巡檢報告「新增 50 個問題」，可能只是抽樣換了一批頁，總數持平。新文章 Google 不認識，1 到 2 天內是正常的。影片串流網址被非瀏覽器客戶端請求時回 400，是 CDN 每次渲染重新簽名的正常行為。只有一個引擎報 5xx，其他都正常，就是那個引擎的問題。完整的八步、七型和誤判清單在網站流量下降怎麼查：八步診斷與關鍵字波動七型。
分工、監控與批量發文
SEO 改不了程式碼時，靠固定格式的需求、每日與每週監控，以及 12 項批量發文品質關卡，讓別人執行的改動不會走樣。
SEO 改不了程式碼的時候
大型站的 SEO 大多數時候是在寫需求，不是在改網站。我們的需求格式固定是：需求、示例連結、現況（附原始碼）、問題、修改後、例外、優先級 P0 到 P3、驗收標準。提之前要先驗證，抽樣至少 50 頁看分布，不拿 2 頁下結論。數字一致到不自然（例如 60 頁的 description 全部剛好 130 字）就是模板設定，該找開發，不是運營。測試服驗收要逐字比對 TDK、H1、robots，我們有一批 13 項的需求，測試服驗下來只有 8 項過。節奏上每 2 週提 1 批、每批 2 到 4 項，巡檢多出來的放 backlog。
監控分每天和每週。每天看 6 項：Search Console 流量、索引與抓取、Bing、Yandex、GA4（按主機名拆）、線上巡檢加舊需求複查。每週一對照基線、累計索引抽查樣本。這裡有一條紀律很重要：抽樣結論只能說抽樣。我們抽查一個站 15 條網址，只有首頁被收錄，看起來很慘。但全量的索引報表是已收錄 15.3k、未收錄 88.2k。抽樣用來發現問題，對外的數字一律用全量。需求格式、原因四級的報告寫法和監控表，整理在大型網站 SEO 分工：需求、驗收、複查與監控節奏，整體作業框架也可以對照 SEO 作業系統。
批量發文的品質關卡
批量發文的錯誤都是模板性的，品質只能靠發布前的固定檢查。我們的清單有 12 項，通用化之後是：頻道分類對不對、標題和正文一致、有沒有殘留來源站的品牌詞、生成標記有沒有清掉、文末有沒有離題的垃圾段落、有沒有孤兒標題、有沒有重複句、圖片是不是用了引用式語法、圖床網域有沒有失效、第一張圖的語法有沒有漏字元、圖片 ALT 是不是檔名、影片網址是不是只留相對路徑。發布後還要用真實瀏覽器打開、等 5 秒、捲到底，確認圖片張數對、沒有原始碼外露、影片點了會動。
最重要的一條經驗：自動修正腳本一定要附「修完再檢查」的 lint，任一項命中就不准發布。我們有一次自動修正腳本自報 30/30 全部乾淨，人工驗收還是抓到 2 篇有問題。這和 Google 對 AI 生成內容的指引↗講的是同一件事：怎麼產生的不是重點，發出去的東西對讀者有沒有用才是。完整的 12 項和前台驗收步驟在AI 批量發文的品質關卡：發布前 12 項與前台驗收，驗收腳本的設計思路可以參考我們用同一把尺量了自己 24 個網站。
接手一個大型站，第一週照這個順序
接手大型站的第一週，先確認數據是對的，再接上會擴散的問題，最後才做結構優化，順序如下：
- 第一天盤點權限：文件、Search Console、GA4、Bing、Yandex，缺的一次申請完。
- 讀索引管理，對照頁型規範表把現況抓一次，sitemap 的「上次讀取」日期先看。
- 讀流量下降診斷，把 GA4 按主機名拆開，確認你看到的趨勢是真的。
- 標籤頁有曝光的話，讀標籤頁治理。文章量大且收錄低，讀內容剪枝。
- 每天有批量發文的話，先把發文品質關卡接上，再談其他優化。
- 開始提需求之前讀分工與驗收，先查文件有沒有提過、已完成的有沒有被改回去。
這個順序的邏輯是先確認你看到的數據是對的，再處理會持續擴散的問題，最後才是結構性的優化。Bing 那一側的基本要求可以順手對照 Bing Webmaster Guidelines↗。如果你希望有人把這整套直接跑在你的站上，從盤點到每週回報，可以看看我們的 SEO 建站與代營運服務。
常見問題
網址多少才算「大型網站」？
沒有固定門檻。比較實用的判斷是：你還能不能逐頁檢查。我們處理過的站從 1 萬多篇到 sitemap 45.8 萬個網址都有，共同點是抓取額度不夠用、收錄率天生偏低，任何處理都必須寫成規則批次執行。只要你發現「一頁一頁看」已經不現實，這篇的方法就適用。
收錄率很低，是不是要把沒收錄的頁全部刪掉？
不要。大批刪除或回 404、410，本身就是負面訊號。先分層：有點擊的頁列保護清單，零曝光的頁再看其他引擎和鏡像有沒有流量，真正全無流量的舊文才考慮只對 Google noindex。而且剪枝的作用是讓出抓取額度，不會直接帶來流量。
只有 Yandex（或 Bing）掉量，要不要調整全站？
不要。單一引擎異常就只做那個引擎的專項，例如查該引擎的可搜尋頁數、排除原因、抓取錯誤。改全站結構可能把其他引擎原本正常的流量一起賠掉。這是六條原則裡的第四條。
Search Console 的資料可以拿來判斷現在的狀態嗎？
只能看趨勢。Search Console、Bing、Yandex 的報表都有幾天到幾週的延遲，狀態碼、robots、canonical、sitemap 要直接 curl 正式站確認。另外，抽樣檢查的結果只能代表抽樣，對外報告的數字要用全量報表。
鏡像網域一定要 301 到主網域嗎？
不一定。鏡像常常是故意保留給打不開主站的使用者。先問業務需不需要它，再從輕到重選：逐頁 canonical 指回主站、加 X-Robots-Tag noindex、最後才是全部 301。整批加 noindex 前要確認標籤不會同時出現在鏡像上，否則鏡像在其他引擎的流量會一起掉。
相關文章
- strategyAI 批量發文的品質關卡：發布前 12 項檢查、前台驗收與修後再查每天幾十篇 AI 輔助產出的文章，錯誤幾乎都是模板性的，一錯就是十幾篇。這篇整理我們實際在用的發布前 12 項檢查、發布後的前台驗收步驟、自動修正為什麼一定要配修後檢查，以及驗證時最常被誤判的三件事：原始 HTML、UA 與背景分頁。
- strategyGEO 實測：Perplexity 引用我們 39 次，只推薦 13 次我們用付費版 ChatGPT 與 Perplexity Pro、加上 Google AI Overviews，把 20 題採購與資訊問題各問 3 次。Perplexity 54 則回答有 39 則引用了我們的頁，卻只有 13 則把我們列進推薦。這篇公開題目、口徑、數字，以及 AI 說它為什麼不推薦。實測日 2026-10-18。
- strategy內容剪枝怎麼做：大型網站的 A／B／C 分層、四條紅線與重複內容合併上萬篇的大型網站做內容剪枝，先用 16 個月資料分 A／B／C 三層，再守住四條紅線：不刪文、不批量 410、不整批 noindex、不承諾剪完就有流量。重複內容只認影片 hash，不認標題。附一個 1 萬多篇影音內容站的實際分層數字。