太長不看版： 網址量上萬的內容站，抓取額度是瓶頸，收錄率天生偏低，不可能一頁一頁救。我們的做法是先定一張「頁型規範表」，決定哪幾種頁可以進索引、哪幾種一律 noindex, follow，再讓 sitemap 只放回 200 的可索引網址、子 sitemap 全部讓 Google 知道、每天看上次讀取日期。鏡像與直連網域先問業務要不要留，再從 canonical、X-Robots-Tag、301 三種做法裡挑一種。GA4↗ 一定要按主機名拆，否則站群合計和主域的方向可能完全相反。只想讓 Google 不收的頁，用 googlebot 專用的 meta，不要整批加通用 noindex。
大型站收錄低，問題通常不在內容量
大型網站收錄率低，是因為內容不夠嗎？通常不是，而是抓取額度被低價值網址占滿，而不是內容量不足。多寫文章也無法解決。
我們接手過一個 sitemap 裡有 45.8 萬個網址的影音內容站。GSC 的索引報表寫著已收錄 15.3k、未收錄 88.2k，而 Google 實際「已知」的網址只有大約 10 萬個。也就是說，sitemap 裡超過三分之二的網址，Google 連看都還沒看到。這種站多寫一千篇文章沒有用，新文章只會繼續排在抓取隊伍的後面。
網址量一大，抓取額度就是天花板。Google 在大型網站抓取額度說明↗裡講得很直接：額度有限的時候，爬蟲花在低價值網址上的時間，就是沒花在重要網址上的時間。所以大型站的索引管理不是「讓更多頁進索引」，而是讓值得排名的頁先進去，其他頁讓路。
這篇講的是地基那一層：頁型、sitemap、canonical、301、鏡像網域、GA4 分析口徑。內容層的剪枝（哪些舊文要讓出額度）我們在大量內容剪枝那篇另外講，兩篇要搭著看。
先有一張頁型規範表
頁型規範表按頁面類型事先規定哪些頁進索引、哪些一律 noindex, follow，之後所有需求都對照它。
大型站的頁面雖然多，頁型其實就十幾種。與其一頁一頁判斷，不如先按頁型定規則，之後所有需求都拿這張表對照。我們實際在用的版本，重點如下：
| 頁型 | robots | 進 sitemap |
|---|---|---|
| 首頁、分類首頁到第 5 頁、文章頁 | index, follow | 首頁、分類首頁、文章 |
| 首頁分頁、分類第 6 頁以後、標籤分頁、作者分頁、歸檔、站內搜尋結果 | noindex, follow | 不放 |
| 標籤頁：3 篇以上 | index | 不放 |
| 標籤頁：1–2 篇 | noindex（滿 3 篇自動轉回 index） | 不放 |
| 404 頁 | 狀態碼必須是 404，不能回 200 | 不放 |
這張表的關鍵是 noindex, follow 而不是 noindex, nofollow。分頁、歸檔、搜尋結果本身不值得排名，但它們是爬蟲走到深層文章的路，把 follow 留著，連結還是能傳遞。meta 的寫法和各值的意思可以對照 Google 的 robots meta 說明↗。
分頁有兩個細節常被漏掉。第一頁的連結要輸出根路徑，不要輸出 /page/1/，否則同一頁會有兩個網址。標題也不要寫「第1頁」，第 2 頁起才加頁碼。
這張表另一個用途是讓需求有依據。在大型站，SEO↗ 通常改不了程式碼，要靠提需求給技術團隊排期。需求符合規範表，就是有依據的需求。自己臨時另訂一套標準，等於跟團隊既有規範打架，對方很難排。
還有一種狀況要先處理：專案文件跟團隊規範寫得不一樣。我們遇過團隊規範要求首頁分頁 noindex，但那個專案的文件完全沒提。這時候不要直接提需求，先問負責人照哪一份，確認之後再動。
sitemap 的四條規矩
sitemap 只放 200 且可索引的網址、子檔全部提交、每天看上次讀取日期，有流量的老頁要補回。
sitemap 在小站是「有就好」，在大型站是 Google 決定抓取順序的重要訊號。我們用下面四條管，每一條都有踩過的坑。協定本身的格式限制（單檔 5 萬網址、50MB）見 sitemaps.org 的協定說明↗。
1. 只放回 200、可索引的網址
我們管過一個自然流量有八成五來自 Yandex 的內容站，它的 sitemap 裡混了 5 個早就 301 到首頁的舊欄位網址。結果那份 sitemap 從 2026 年 3 月 14 日之後就沒有再被讀取過，一直到 10 月 16 日我們清掉跳轉網址、重新提交，才恢復讀取。sitemap 裡放會跳轉的網址，Google 會降低讀取頻率，這是我們看到最直接的一次。
2. 子 sitemap 要全部讓 Google 知道
前面那個 45.8 萬網址的站，問題就出在這裡。網站實際有 46 個子 sitemap，GSC 只提交了 9 個，Google 只認得大約 10 萬個網址。解法是提交 sitemap 索引檔，或把每個子檔都提交。Google 的大型 sitemap 管理說明↗也是建議用索引檔把子檔串起來。補交之後已知網址和收錄數怎麼變，我們還在追蹤，目前沒有可以公開的結論。
3. 每天看「上次讀取」日期
GSC 的 sitemap 報表有一欄「上次讀取」。我們每天巡檢都看這一欄，超過 3 天沒讀就要查原因。上面那個半年沒被讀的案例，如果早一點看這一欄，不會拖那麼久。
搭配的原則是以線上為準。狀態碼、robots、canonical、sitemap 內容一律 curl 正式站確認，GSC、Bing、Yandex 的報表都有幾天到幾週的延遲，只能用來看趨勢，不能用來推斷「現在」線上長什麼樣。
4. 標籤頁不放，但有流量的老頁要補回
規範上標籤頁不進 sitemap。反過來，有流量的舊頁面如果不在 sitemap 裡，要補回去。我們接手的一個 1 萬多篇的影音內容站，sitemap 只收了某個文章 ID 之後的新文，往前有 517 篇在 GSC 有曝光的舊文完全不在 sitemap 裡。sitemap 怎麼產、怎麼分檔，基礎做法可以看我們的 sitemap 設定指南。
canonical 與 301：只留一個入口
canonical 逐頁指回對應頁，301 只留一個入口網域並保留原路徑，不全跳首頁、不用 302。
canonical 的原則很簡單：每一頁指向自己。鏡像站則要逐頁指回主站的對應頁，不是全部指到主站首頁。全部指首頁等於告訴 Google「這幾萬頁都是首頁的重複」，這種 canonical 不是被忽略，就是把內頁一起拖下水。Google 對重複網址的處理邏輯，可以看合併重複網址↗那篇。
301 我們用這幾條規範：
- 只保留一個入口網域，其他入口 301 過去。
- 禁止全部跳首頁，要保留原本的路徑與參數，跳到對應頁。
- 禁止用 302 代替 301。
- 禁止泛解析，任何子網域都能打開的設定會製造大量重複頁。
合併頁面一定用 301，而且目標要是主網址。我們看過標籤合併時用 302 跳到某個「最新排序」頁的案例，既不是永久跳轉，目標也不是該被收錄的網址，兩個錯一次犯。
評論參數、分頁評論這類髒參數（例如 ?replyTo=、?comment-page=），也要 301 回乾淨網址。這類網址在大型站會自己長出成千上萬條，放著不管就是在吃抓取額度。robots.txt 能擋哪些、不該擋哪些，在 robots.txt 與索引設定那篇有比較完整的說明。
鏡像與多網域：先問業務，再挑三種做法之一
鏡像網域先問業務還要不要給人用，再從逐頁 canonical、X-Robots-Tag noindex、301 擇一。
大型內容站的鏡像網域，很多是故意留著的，給打不開主站的使用者用。處理鏡像的第一個問題不是技術問題，是業務問題：這個鏡像還要不要給人用？問清楚了，再從下面三種做法挑，由輕到重：
| 做法 | 適用情況 | 使用者還能用鏡像嗎 |
|---|---|---|
| 鏡像逐頁 canonical 指回主站 | 基本盤，多數站已經做了 | 可以 |
鏡像回應加 X-Robots-Tag: noindex | 鏡像是故意保留，但不想它被收錄、分走主站流量 | 可以 |
| 鏡像全部 301 到主域 | 已確認鏡像不需要給使用者用 | 不行，會被帶到主域 |
canonical 是建議不是指令，搜尋引擎可以不採用，所以只靠第一種，鏡像還是可能被收錄。第二種用 HTTP 標頭加 noindex，不必改頁面模板，鏡像照常能開，是「要留給人用、但不給搜尋引擎」時最乾淨的做法。第三種最徹底，但等於把鏡像收掉，業務沒點頭之前不要做。
我們接手的另一個影音內容站有 3 個鏡像網域，還有一個 CDN 直連網域。這種站在決定做法之前，一定要先把每個網域的流量拆出來看，這就牽涉到下一段的 GA4。
GA4 一定要按主機名拆
GA4 必須按主機名拆開看，因為站群合計和主域的流量方向可能完全相反，例如合計 -20%、主域卻是 +57.5%。
多網域的站，GA4 報表預設是全部加在一起。這會讓人看錯方向。我們 2026 年 9 月 29 日看過一個站群，合計自然流量是 -20%，看起來很糟。按主機名拆開之後，主域其實是 +57.5%，掉的是鏡像。如果照合計數字去「救流量」，等於在修一個沒壞的主站。
反方向的情況也有。那個 1 萬多篇的影音內容站，2026 年 10 月 13 日拆主機名時發現 Google 帶來的流量正在從主域流向 CDN 直連網域，直連網域的工作階段從 708 漲到 1,693。合計看起來持平，實際上是主域在被分流。
做法是在報表或探索裡加上「主機名稱」維度（GA4 的維度與指標定義見 Analytics 說明中心↗），每天看自然搜尋流量時固定按主機名拆。流量下降時要排查哪些地方，Google 的搜尋流量下降偵錯↗可以當清單用，但多網域的站，拆主機名要排在最前面。
只想讓 Google 不收：用 googlebot 專用 meta
只想讓 Google 不收，就用 googlebot 專用 meta，不要加通用的 robots noindex。
這是我們在大型站最常用、也最容易出事的一招。主站跟鏡像如果共用同一個後台，主站加的 meta 標籤會同時出現在鏡像上。那個 1 萬多篇的站做剪枝時，Google 16 個月零曝光的 9,528 篇裡，有 4,977 篇在其他引擎或鏡像上還有流量。這時候如果整批加通用的 <meta name="robots" content="noindex">，鏡像在其他引擎的流量會一起掉。
如果目的只是讓 Google 不收、把抓取額度讓給重要頁，就用 Google 專用的寫法：
<meta name="googlebot" content="noindex, follow">
這個標籤只有 Googlebot 會讀，Bing、Yandex、百度不受影響。Yandex 也有自己的 yandex 專用名稱，規則見 Yandex 的 meta robots 說明↗。Bing 的收錄原則則在 Bing 網站管理員指南↗。我們做多引擎站有一條固定原則：只有一個引擎有問題，就只對那個引擎處理，不改全站結構。
要老實說的是：googlebot 專用 noindex 對抓取額度實際有多少幫助，我們還沒有驗證完。那個 1 萬多篇的站，全無流量的舊文已經按 ID 列成候選名單，效果要等實施後追蹤。剪枝的作用本來就是把額度讓給有價值的頁，不會直接帶來流量，報告裡要先講清楚，不要讓業務期待隔週流量就漲。
每一次索引調整上線後，我們都會照同一份清單驗收、再追蹤幾週，做法跟我們量自己 24 個網站時用的是同一套紀律。如果你的站也是網址量大、網域多、收錄卡住，可以看看我們的 SEO 網站服務是怎麼分工、怎麼驗收的。
這篇是大型網站 SEO 指南的其中一章，六個工作面的全貌和接手第一週的處理順序都整理在那裡。
常見問題
noindex 的頁要不要同時從 robots.txt 擋掉？
不要。robots.txt 一擋，爬蟲就讀不到頁面上的 noindex，反而可能靠外部連結把網址留在索引裡。要不收就讓它能被抓、讀到 noindex。要省抓取額度但頁面根本不該存在，才考慮 robots.txt。
標籤頁為什麼不放進 sitemap？
標籤頁數量容易失控，放進 sitemap 等於主動請 Google 把額度花在聚合頁上。標籤頁照頁型規範表處理：3 篇以上 index、1–2 篇 noindex，但不主動送進 sitemap，讓它靠站內連結被發現。
鏡像網域直接 301 到主域不是最省事嗎？
技術上最省事，但很多鏡像是留給打不開主站的使用者，301 之後這些人就用不了。先問業務鏡像還要不要給人用。要的話，用 X-Robots-Tag noindex 就能讓它不被收錄，使用者照常能開。
GSC 顯示 sitemap 很久沒讀取，要先查什麼？
先 curl 一次 sitemap 裡的網址，看有沒有 301、404 或 noindex 的頁混在裡面。我們遇過的案例就是 5 個跳轉網址讓整份 sitemap 半年沒被讀，清掉後重新提交才恢復。
相關文章
- 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 萬多篇影音內容站的實際分層數字。