Google Search Console 網頁索引報表：理解網站索引問題細節 | 白話文商學院
Google Search Console 網頁索引報表的位置在左側選單「產生索引 → 網頁 → 網頁未編入索引的原因」，它列出 Google 發現卻沒收進索引庫的網址與原因，整份…
Google Search Console 網頁索引報表的位置在左側選單「產生索引 → 網頁 → 網頁未編入索引的原因」，它列出 Google 發現卻沒收進索引庫的網址與原因，整份報表共 15 種未編入索引原因 [來源：Google Search Central〈網頁索引報表簡介〉〈https://support.google.com/webmasters/answer/7474089〉〈2026〉]。先記住一個數字就夠了：報表裡超過一半的通知其實屬於 Google 正常篩選後的結果，並非錯誤，真正該動手的只有三大類，把力氣花在那裡比逐條修補有效率得多。
重點先看：報表裡只有三類值得動手，即爬取障礙、noindex／robots.txt 設定錯誤、以及「已檢索卻不索引」的內容品質問題；15 種原因裡超過一半是 Google 正常運作的結果 [來源：Google Search Central〈網頁索引報表簡介〉〈https://support.google.com/webmasters/answer/7474089〉〈2026〉]。
網頁索引報表的位置與介面邏輯
Search Console 的網頁索引報表藏在「產生索引 → 網頁 → 網頁未編入索引的原因」這條路徑底下，它列出所有被 Google 發現、卻沒收進索引庫的網址，以及背後原因。它本質上是一份篩選紀錄而非成績單：很多時候 Google 是「主動決定不要」，與你的網站出不出事無關。
要正確判讀這份報表，前提是先建立 Google 搜尋引擎的運作原理裡「爬取 → 索引 → 排名」三階段的觀念：沒被爬到不可能被索引，被爬到也不保證被索引，被索引更不保證有排名。把這條因果鏈記住，你看到報表時就不會把每條通知都當成危機。如果你還沒裝好 Search Console，先看 Google Search Console 安裝與驗證教學，再回來看這份報表會有脈絡得多。想把整套工具摸得更透，也可以搭配 Google Search Console 完整教學 一起讀。
報表的介面邏輯其實很單純。每個原因是一個分類，點進去會看到「具體的網址清單」，再點任何一個網址，就能用 GSC 網址檢查工具 深挖那一頁的技術細節。換句話說，報表是地圖，網址檢查才是放大鏡。想看整個網站的索引健康度，也可以先回頭看 Google Search Console 介紹與常用功能，把這套工具的全貌摸熟。累積一些實戰經驗後，再對照 Google Search Console 實戰技巧，排查會更俐落。
報表頂端會顯示幾個關鍵總量，值得先記住它們的意義。「已編入索引的網頁數」是你真正進到索引庫、有資格出現在搜尋結果的頁面總數，這個數字長期該呈現穩定上升或持平；「未編入索引的網頁數」則是被 Google 發現卻排除的頁面總數。兩者的比例本身就是健康訊號：一個內容站若未索引數遠高於已索引數，往往代表網站塞了大量低價值分頁（篩選參數頁、分頁標籤頁、空分類頁），這時該修的是網站架構本身，逐條去救那些被排除的頁面只會徒勞。把這兩個總量當成觀察起點，再看底下的 15 種原因分布，方向感就會清楚很多。
判讀前提是先搞懂 索引是什麼與如何確認網頁被索引，再來談問題；不確定某頁到底有沒有被收錄，可參考 Google 網頁收錄查詢教學 快速確認。
索引問題排除原則：先學會哪些不用理
碰到一堆索引通知，正確的起手式是把報表當成待辦清單分類，依序做四件事：搜尋那條通知原文、點進去看網址找共通點、判斷這個通知是不是「真正的問題」，最後只在真的修好時才按「驗證修正後的項目」。逐條翻譯 Google 文件反而最沒效率；這套流程走熟了，你看報表的時間可以少掉一半以上。
分類的第一個動作是搜尋那條通知原文，或直接把原文丟給 AI 問，多數原因都已有現成解釋。接著點進原因底下的網址清單，挑 5 到 10 個網址看共通模式，這比單看原因名稱更能鎖定根因，例如清一色都是 utm 參數網址，你馬上知道是 網址查詢參數 造成的替代頁面，不是網站壞掉。想更系統化地檢視自己的 SEO 觀念是否到位，可以對照 SEO 自學懶人包與底層邏輯。
分類過程中最關鍵也最常被忽略的觀念是「有些問題不是問題」。替代頁面、重複網頁、404、頁面會重新導向，這些常常是 Google 正確判斷後的結果，不是 bug。至於「驗證修正後的項目」這個補考機制，沒實際改善就狂按，對網站沒有任何好處，反而會干擾 Google 重新審核的節奏。
分類動作有個常被忽略的細節：報表裡每個原因的網址清單，右側都會顯示「最後檢索日期」。這個欄位是判斷要不要動手的重要線索。一個網址如果最後檢索日期是三個月前，你現在改了內容，Google 還沒回來重抓，報表顯示的還是舊狀態，這時按驗證才有意義；反之，如果檢索日期就在最近幾天，Google 顯然已經看過最新版本卻仍排除，那就是真的判斷為「不要」，問題出在內容品質或設定，光按驗證救不回來。把檢索日期納入判讀，能幫你把力氣集中到真正需要等待與真正需要改的兩種情況上。
| 步驟 | 動作 | 預期產出 |
|---|---|---|
| 1 搜尋原文 | 把通知名稱 Google 一次或問 AI | 知道這原因在講什麼 |
| 2 看網址清單 | 挑 5 到 10 個網址找共通點 | 鎖定根因方向 |
| 3 判斷真偽 | 這是 bug 還是 Google 正常篩選 | 決定要不要動手 |
| 4 驗證修正 | 真的修好才按 | 觸發 Google 重新審核 |
判斷「是不是問題」靠的是 SEO 基本功。如果你連 robots.txt 與 noindex 為何不能同時用 都還沒釐清，看到「網址遭到 robots.txt 封鎖」自然會慌。觀念先打底，報表的紅字就不會那麼嚇人。
三類問題的優先級評分卡：先把力氣花在刀口上
15 種原因同時出現在報表裡時，逐條處理很容易陷入見樹不見林的消耗戰。比較務實的做法是用一張評分卡排序：依「影響面」（這類原因吃掉多少你期望被索引的頁面）與「可修復性」（你能不能在合理時間內真的改動它）兩個維度打分，把資源壓到高分區。這套評分把報表的數字轉成可排序的判斷，憑感覺排序只會把力氣用錯地方。
影響面看的是「你期望被索引的頁面裡，有多少落進這個原因」。一個電商站如果有三萬個商品頁，其中八千個落在「已檢索，目前尚未建立索引」，影響面極大；相對地，同站有兩百個 utm 參數網址落在「替代頁面」，影響面就微乎其微，因為那本來就該被壓掉。可修復性看的則是「修起來要動用多少資源、技術可行性多高」：調一個 canonical 標籤是五分鐘的事，要工程師把主機回應時間壓到 200 毫秒以下則可能是跨季度的工程。把兩個維度各自打一到五分，相乘後排序，處理順序就會自然浮現。
| 原因類型 | 影響面（1-5） | 可修復性（1-5） | 綜合優先級 |
|---|---|---|---|
| 5XX 伺服器錯誤 | 5（整站層級） | 4（工程可解） | 20，最優先 |
| 已檢索，目前尚未建立索引 | 4-5（常是大宗） | 2-3（內容改造慢） | 12-15，高 |
| Soft 404 | 3-4 | 4（改狀態碼即可） | 12-16，高 |
| robots.txt 封鎖（誤擋） | 3 | 5（改規則秒解） | 15，高 |
| noindex 標記（誤設） | 3 | 5（移標籤秒解） | 15，高 |
| 已找到，目前尚未建立索引 | 3 | 2-3（主機升級慢） | 6-9，中 |
| 替代頁面（有正確標記） | 1 | 1（本來就該被壓） | 1，忽略 |
| 重複網頁、使用者未選取 | 2 | 3（補 canonical） | 6，中低 |
評分卡的使用節奏建議是兩到四週跑一次。把當週的報表數字填進影響面欄位，可修復性則依你團隊當下的工程能量調整。這張表最大的價值在於強迫你承認「替代頁面這類原因根本不該出現在待辦清單上」，把注意力從低分區抽離，集中到 5XX、Soft 404、crawled-not-indexed 這幾個真正決定索引健康的高分區。
舉一個可操作的判讀範例。假設一個內容站每月自然流量約三萬、商品與文章頁合計五千個網址，報表裡「已檢索，目前尚未建立索引」累積到一千兩百個，而「替代頁面」有四百個、5XX 伺服器錯誤只有八個。直覺上你可能想先清那四百個替代頁面，但套進評分卡後，crawled-not-indexed 的綜合分數最高（影響面 4、可修復性 3，約 12 分），應該優先從這一千兩百個頁面裡挑出搜尋意圖明確、只缺內外部連結支撐的子集去補強；5XX 雖然影響面大但數量少，列為第二順位交給工程排程；替代頁面分數最低，直接從待辦移除。兩到四週後再跑一次同樣的評分，分數分布的變化會告訴你這幾週的改善有沒有打在點上，比起只盯著絕對數字漲跌更有判斷力。
爬取障礙類：伺服器錯誤、robots.txt、noindex 與各種封鎖
只要 Googlebot 連網頁內容都拿不到，就不可能談索引。這類問題包含 5XX 伺服器錯誤、重新導向錯誤、robots.txt 封鎖、noindex 標記、401／403 權限封鎖，以及移除工具的主動封鎖，多半要工程師或主機商介入。先記住一個原則：爬取與爬取預算 是索引的前置條件，這層卡住，後面什麼都免談。想知道怎麼把有限的預算留給重要頁面，可以進一步看 爬取預算優化策略。
5XX 伺服器錯誤：網站本身壞掉
500、502、503 這類 500 層級錯誤代表伺服器出問題，網頁根本打不開，自然無法被索引。真正麻煩的是長期反覆發生，單次錯誤反而Google 會把這種網站視為不可靠，逐步降低爬取頻率，連帶影響其他正常頁面的收錄速度。解法是找工程師或主機商修伺服器，這超出一般行銷人自己能解的層級。
5XX 的排查有一個常見誤區：人為用瀏覽器打開頁面看得到內容，就以為伺服器沒事。問題在於 Googlebot 的請求特徵與一般瀏覽器不同，它不帶 cookie、不執行某些 JavaScript、User-Agent 是 Googlebot，有些伺服器或防火牆會對這類請求回 503 或直接擋掉。判斷方式是用網址檢查工具裡的「查看已測試網址」，它會顯示 Google 實際收到的 HTTP 狀態碼與回應內容，這才是 Google 的視角。如果工具顯示 200，但報表卻列 5XX，多半是間歇性錯誤，需要看主機端那段時間的錯誤日誌；如果工具也顯示 5XX，就是穩定可重現的問題，要從伺服器設定、主機負載或 WAF 規則下手。把「人看得到」與「Google 看得到」分開驗證，是排查這類問題的基本動作。
重新導向錯誤：Google 卡在半路
轉址鏈結過長、迴圈、最終網址壞掉，會讓 Googlebot 在多層 301／302 之間打轉，最後放棄。排查工具首選 網頁開發者工具 F12 或 Lighthouse，它們能直接畫出轉址路徑讓你看出卡在哪一跳。順帶一提，Canonical 標籤設錯 常和重新導向錯誤一起出現，因為兩者都會讓 Google 搞不清楚「到底哪一頁才是本尊」。
轉址鏈結過長的實務門檻沒有官方硬性數字，但業界普遍以「四跳以內」作為健康線。一條網址如果從舊站 A 301 到 B，B 再 302 到 C，C 又 301 到 D，D 才是目的地，Googlebot 在每一跳都要重新排隊等待，中途任何一跳回應變慢或暫時失效，整條鏈就斷掉。常見的成因是網站歷經多次改版，每次改版都只補一層轉址，舊的沒拆掉就一直疊上去。解法是把所有舊網址直接 301 指到最終目的地，中間不留任何過渡層，並定期用爬蟲工具檢查鏈結深度，避免過幾年又疊出新的一層。
robots.txt 封鎖：你主動設的禁令
robots.txt 是禁止爬取的設定，網址一旦符合封鎖規則，幾乎不會被索引。如果你想讓某頁被收錄，就得把那個網址從封鎖規則移除。要特別注意的是，robots.txt 與 noindex 不能同時用，擋了爬取又想移除索引，結果會兩頭落空。
robots.txt 封鎖還有一個容易踩的雷：封鎖規則與你「想索引」的目標自相矛盾。一個典型情境是網站把整個查詢參數目錄用 Disallow: /*? 全擋掉，結果連帶把分頁、篩選頁、甚至 utm 追蹤頁都封鎖了，但其中某些分頁是你期望被索引的重要入口。判斷方式是把被封鎖的網址貼進網址檢查工具，看它回報的封鎖規則是哪一條，再回頭對 robots.txt 檢查那條規則的覆蓋範圍是否過廣。修正時，放寬整條規則會把大量垃圾頁一起放行，更好的做法是用更精準的路徑或 Allow 例外，只把特定該索引的子路徑救回來。
noindex 標記：明確告訴 Google 不要索引
noindex 顧名思義就是「不要索引」。網址被加上 noindex，代表不希望 Google 收錄；想被收錄就移掉這個標籤。但動手前要先確認：這頁是不是真的該被索引？很多時候 noindex 是有意設定的，例如 不想被索引的四個方法 裡會提到的會員頁、搜尋結果頁、低品質分頁，本來就該擋。盲目移除反而會把垃圾頁塞進索引庫。
401 未授權、403 拒絕存取、移除工具封鎖
401 未授權代表頁面要求登入驗證，403 拒絕存取代表伺服器直接拒絕連線，兩者都讓 Googlebot 看不到內容，自然無法索引。判斷標準只有一個：這頁「應該」給使用者和 Google 看嗎？應該就開放權限，不應該就不用理會。至於「遭到網頁移除工具封鎖」，是你自己或協作者在 Search Console 的移除網址工具 [來源：Google Search Central〈使用移除工具安全地移除網頁〉〈https://support.google.com/webmasters/answer/16668565〉〈2026〉] 主動下達的封鎖，想恢復索引就去該工具取消要求。
- 5XX 伺服器錯誤：找工程師修主機，長期發生會被降爬取頻率。
- 重新導向錯誤：用 Lighthouse 或 F12 排查轉址鏈。
- robots.txt 封鎖：把該網址從封鎖規則移除。
- noindex 標記：確認該頁該被索引後再移除標籤。
- 401／403／移除工具：判斷該不該開放，該開放才解除封鎖。
404 與 Soft 404 的修復判斷
報表裡的 404 多半不是問題，因為它誠實回報「這頁沒了」，Google 不索引是合理結果；真正麻煩的是 Soft 404，頁面對使用者已經壞掉，卻回傳 200 正常狀態碼，讓 Google 白白浪費爬取資源去抓一個沒內容的頁面。前者是誠實，後者是說謊，傷害程度完全不同。
真正的 404：先問「為什麼這頁變 404」
404 Not Found 是網頁掛了、不存在。Google 不索引一個不存在的頁面，合理得不能再合理。所以你該問的不是「為什麼沒被索引」，而是「為什麼這頁變成 404」。如果是你主動刪除的舊頁，那就放著；如果是不該消失的頁面變成 404，那才是真正的 bug，要回頭查 網站架構 或 內部連結與網站架構優化 哪裡斷了。很多 404 其實源自建站階段埋下的結構問題，自架網站常見錯誤 值得趁早排除。
404 還有一種容易被誤判為「該修」的情況：外部連結或舊的內部連結指向一個你已經刪除的頁面。這時真正該動手的不是把 404 頁面救回來，而是處理那些斷掉的連結。若刪除的頁面有等價的新頁面，就設一條 301 把舊網址指到新頁面，既保留舊連結的價值，也引導使用者到正確位置；若沒有對應的新頁面，就把指向它的內部連結移除，避免持續產生 404。外部來源的 404 你無法控制對方修改，但可以在 內部連結與網站架構優化 時把站內指向清乾淨。把 404 從「要不要修頁面」轉成「要不要修連結」，判斷會準確很多。
Soft 404：用 200 狀態碼偽裝正常的說謊頁
Soft 404 是這份報表裡最該被重視的兩個項目之一。畫面顯示「找不到」「此頁面無法使用」，HTTP 卻回傳 200 正常狀態碼，這種矛盾會讓 Google 誤判頁面可用、反覆派爬蟲來抓，結果每抓一次就燒掉一點爬取預算，卻一頁都收不進索引庫。修法是跟工程師把壞掉頁面的狀態碼從 200 改回正確的 404 [來源：Google Search Central〈網頁索引報表簡介（Soft 404 說明）〉〈https://support.google.com/webmasters/answer/7474089〉〈2026〉]。
Soft 404 在不同系統上有幾個典型產地，認得這些產地能幫你批量抓出問題。電商站的篩選結果頁是最大宗：使用者選了一組篩選條件，剛好該分類沒有任何商品符合，畫面顯示「找不到符合的商品」，系統卻回 200，Google 就會把它當成正常頁面反覆爬。分頁機制是第二個產地：一個列表只有三頁，但 URL 規則允許存取第四、第五頁，這些不存在的分頁回 200 卻顯示「沒有更多內容」，同樣會被歸類為 Soft 404。搜尋結果頁是第三個：站內搜尋打了一個無結果的關鍵字，畫面「查無結果」卻回 200。這三類的共同點是「畫面告訴使用者沒內容，系統卻告訴 Google 有內容」，修法統一是讓這類頁面回傳正確的 404 狀態碼，或在合理情況下回 410（永久移除），讓 Google 知道不必再回來。
| 項目 | 狀態碼 | 頁面實際狀態 | 要不要修 |
|---|---|---|---|
| 真正 404 | 404 | 頁面不存在 | 看這頁該不該存在 |
| Soft 404 | 200 | 頁面壞掉卻偽裝正常 | 幾乎都該修 |
判斷標準很明確：404 要看這頁本來該不該存在；Soft 404 幾乎都該修，因為它代表系統回報不誠實。如果你正在做 網站搬家與改版，Soft 404 常常是大宗，改版後一堆分類頁被併掉，畫面跳到「找不到商品」卻回 200，這就是典型的 Soft 404 災情。
使用 WordPress 架站的人，遇到這類索引問題時可以先回頭檢查佈景主題與外掛設定，把 WordPress SEO 必做設定 走過一遍，往往能少掉一半排查時間。裝好網站後也別忘了走 WordPress 網站提交 Google Search Console 的流程，讓這份報表從一開始就有資料可看。
內容被爬到了卻不索引：Crawled-not-indexed 與 Discovered-not-indexed
網頁能被正常爬取，Google 卻不願意索引，問題多半不在技術，而在內容。「已檢索，目前尚未建立索引」代表 Google 看過內容但認為不值得收錄，問題多半在內容品質；「已找到，目前尚未建立索引」則是 Google 知道有這個網址但還沒爬，通常跟爬取預算不足有關。這兩項是內容經營者最常遇到、也最容易誤判的狀況。
已檢索，目前尚未建立索引：內容被判斷不值得收錄
Google 已經爬過這頁了，卻主觀判斷內容不夠好或不夠獨特，於是不收錄。這是整份報表裡最該被重視的項目之一，因為它直接指向「內容品質」這個沒有技術開關可扳的硬骨頭。改善方向是充實內容、加 站內站外四大類型連結、移除 黑帽 SEO 手法，必要時整頁改寫重發。要更全面地優化單頁體質，站內 SEO 終極攻略 是一套值得照著走的方法。如果你的內容還停留在抄改抄湊的層級，再怎麼按驗證都沒用。
至於「補連結」為什麼排在改善方向裡，外部研究也給了明確理由。Backlinko 分析約 1,180 萬筆 Google 搜尋結果後發現，大約 95% 的頁面一條反向連結都沒有，排名結果中的第一名頁面平均擁有的反向連結數量，更是第二名到第十名頁面的 3.8 倍 [來源：Backlinko〈Search Engine Ranking: We Analyzed 11.8 Million Google Search Results〉 https://backlinko.com/search-engine-ranking 2025-04-14]。也就是說，單頁如果完全沒有內外部連結支撐，被 Google 判斷為「不值得收錄」的機率會明顯升高，這也是改善「已檢索卻不索引」時不能只改文字、還要補連結的底層原因。
內容品質是個抽象詞，但可以拆解成幾個可操作的指標。它符不符合 搜尋意圖？有沒有展現 E-E-A-T 原則 裡的經驗與專業？資訊有沒有 資訊增益，還是只是把別人講過的話再講一次？在 AI 搜尋時代，內容還得對得上 Entity SEO 的實體語意，這些才是讓 Google 願意收錄的真正理由。
判斷一頁到底是「內容不夠好」還是「只是新頁面還沒被信任」，有一個時間維度的判讀方法。剛上線的新頁常常會短暫出現在「已檢索，目前尚未建立索引」，這是正常的冷啟動期，Google 還在累積對這個新網址的信心，通常伴隨站內連結與外部引用逐漸增加後會被收錄。判斷分界線建議抓在四到八週：若一頁上線超過這個區間仍卡在這個狀態，且你已經補過內部連結、內容也已充實，那比較可能是品質判定問題，要往內容獨特性、搜尋意圖契合度去改；若還在新頁冷啟動期，急著按驗證或反覆提交通常幫助有限，反而該把力氣放在累積連結與曝光。把「新頁等待」與「品質不足」分開對待，能避免把寶貴的改寫資源浪費在還沒到判斷點的頁面上。
用一個常見的內容站情境來看會更具體。一個每月自然流量約三萬到八萬的中型內容站，文章與分類頁合計約五千到兩萬個網址，報表裡「已檢索，目前尚未建立索引」累積到約八百到兩千個是相當普遍的狀況，比例上大約落在整站網址的百分之十五到二十五。這類站常見的狀況是，累積的頁面裡約六到七成屬於搜尋意圖偏弱、資訊增益低的「補水頁」（例如把同一主題拆成多篇薄文、或把別人講過的東西再講一次），只有約三到四成是搜尋意圖明確、只是缺內外部連結支撐的頁面。實務上能被救回來的，幾乎都集中在後者：補幾條從分類頁或相關文章來的內部連結、再累積少數幾條外部引用，約六到十二週後有機會陸續進索引；前者則因為本質是內容價值不足，光補連結通常救不回來，硬改寫的投資報酬率也很低。要誠實說明的一個限制是：上述比例與救回率是依這類站典型的表現幅度描述，並非量測得到的固定數字，實際會隨網站權重、主題競爭度與改寫品質而有明顯落差。決策角度建議是，先花一個報表週期把這批頁面按「搜尋意圖是否明確」分兩堆，只把力氣壓在有意圖的那一群，其餘的就讓它維持未索引、或直接整併刪除，比逐頁硬救更划算。
已找到，目前尚未建立索引：爬取預算還沒輪到
網址被 Google 發現了，但還沒實際爬取，通常是 Google 預期爬下去會造成主機負載過重，所以先排隊等。如果觀察一段時間始終沒被爬，多半是爬取預算太少。解法是把完全不重要的頁面用 robots.txt 擋掉，把有限的預算留給重要頁面；或提升主機效能讓 Google 爬得更順。搭配 XML Sitemap 主動提交網址清單，也能加速 Google 發現重要頁面。還沒建好 sitemap 的站，可以從 網站 Sitemap 入門指南 開始架設。
這兩項是最考驗耐心的。它們沒有明確的技術開關，改善後需要時間等待 Google 重新評估，急不得。持續更新整體網站品質、定期回來看這份報表，比單點修補有效。把 網頁速度 與 網站使用體驗核心指標 CWV 顧好，也有助於提升 Google 對網站的整體評價，間接改善這兩類問題；速度卡關時，網站快取設定 往往是最直接的解法。
| 狀態 | Google 做了什麼 | 問題出在 | 改善方向 |
|---|---|---|---|
| 已檢索，尚未建立索引 | 爬過內容了 | 內容品質不足 | 充實內容、加連結、改寫 |
| 已找到，尚未建立索引 | 知道有這網址，還沒爬 | 爬取預算不足 | 擋掉無用頁面、提升主機效能 |
Discovered-not-indexed 還有一個常被忽略的成因：網址的「發現路徑」不夠乾淨。Google 發現一個網址的管道很多，從 sitemap、內部連結、外部連結到它自己之前留下的歷史紀錄都有可能。如果一個網址只被 sitemap 列出、站內卻沒有任何連結指向它，Google 會把它視為「孤立、重要性低」的網址，優先級自然排得很後面。修正方式是確保你想被收錄的頁面，在站內至少有合理數量的內部連結指向，最好從首頁或分類頁能在兩到三次點擊內抵達。把「放進 sitemap」與「放進站內連結網」這兩件事同時做，比只靠 sitemap 推送有效得多。
重複內容與標準網址
「替代頁面」「重複網頁」這類通知九成是 Google 正常運作的結果。當多個網址內容重複，例如帶 utm 參數的網址，Google 會選一個標準網頁索引，其餘列為替代頁面。只有當「你認定的標準頁」被誤判成替代頁、或大量標準頁出錯時，才需要動 canonical。想搞懂 utm 到底怎麼影響網址，可先看 UTM 追蹤碼完整教學。
替代頁面（有適當的標準標記）：分身被正確指向
這代表分身已經被正確指向本尊，rel canonical 設定運作正常，通常不用處理。最常見的情境就是 utm 參數網址：你貼了一條帶 utm 的網址到社群，Google 發現它和原始網址內容相同，就把 utm 版列為替代頁面，原始網址才是標準頁。想釐清 utm 怎麼運作，可以看 UTM 參數教學與追蹤。
重複網頁、使用者未選取標準網頁
兩個頁面內容高度相似，你沒設 canonical，於是 Google 幫你選了一個當標準頁。如果你認同 Google 的選擇，不用動；不認同才用 canonical 機制來改。Google 之所以壓縮重複內容，是為了維護搜尋結果的多樣性，不是懲罰。詳細機制可以對照 SEO 重複內容指南與解法。
Google 選的標準網頁和使用者不同
你設了 canonical 指向 A，Google 卻選了 B 當標準頁。這通常代表 canonical 標籤設錯，或網站確實存在重複內容讓 Google 覺得 B 更適合。查看 Google 的選擇在「網頁索引 → Google 所選的標準網址」，你的宣告在「使用者宣告的標準網址」。少量出現不用緊張，數量多時才需要逐一檢查。
Google 拒絕採用你宣告的 canonical，背後常見三個原因，認得出來才能對症下藥。第一是宣告方向與內部連結權重不一致：你用 canonical 指向 A，但站內大量連結、選單、麵包屑都連到 B，Google 會把 B 當成真正的本尊，這時要嘛改 canonical 指向 B，要嘛調整內部連結全部指向 A。第二是兩個頁面內容相似度不足：canonical 是「聲明這兩頁是同一個內容」，若兩頁其實差很多，Google 會判定宣告無效而自己選，這時該做的是讓兩頁內容真正一致，或根本不該用 canonical 連它們。第三是宣告形成迴圈或指向一個自己被 noindex、被 robots.txt 封鎖的網址，這會讓 Google 直接忽略整組宣告。排查時把這三個方向都過一遍，Google 才會願意接受你選的標準頁。
重點只有一個：確保你想被收錄的那一頁被正確指定為標準。如果你連 網址命名與結構 都沒規劃好，重複內容自然會層出不窮。想從根本減少這類通知，把網站架構與 網址組成與結構 先理順，比事後補 canonical 有效得多。
行動優先索引時代的兩個隱藏陷阱
Google 已經全面採用行動優先索引（mobile-first indexing），這件事直接改變了網頁索引報表的判讀邏輯，卻很少被獨立拿出來講。官方在 2023 年 10 月正式宣布行動優先索引的遷移已完成，所有能在行動裝置運作的網站，現在都主要由行動版爬蟲檢索 [來源：Google Search Central Blog〈Mobile-first indexing is here〉 https://developers.google.com/search/blog/2023/10/mobile-first-is-here 2023-10-31]。這代表 Google 看到的「你的網站」就是行動版，桌面版的內容如果比行動版豐富，那些多出來的內容在 Google 眼裡等於不存在。當你在網頁索引報表看到某頁「已檢索，目前尚未建立索引」，而那頁的桌面版內容很完整、行動版卻被精簡掉了，根因就藏在這個落差裡。
陷阱一：行動版與桌面版內容不一致
最常見的不一致是行動版為了版面清爽，把表格、詳細規格、長段說明整段隱藏或刪掉。這在設計上是合理的取捨，但在行動優先索引下，被刪掉的內容就從 Google 的索引視野裡消失，頁面的資訊密度被嚴重低估，連帶被判斷為「內容薄弱」而不索引。排查方式是用網址檢查工具的「測試：行動裝置友好性測試」，對照同一頁在行動版與桌面版實際呈現的內容量，若行動版明顯少了一大塊，就要評估這個精簡是不是把排名支撐內容一起刪了。修正方向是把關鍵資訊在行動版保留下來，可用摺疊、分頁等互動方式兼顧版面與內容，避免直接移除導致資訊密度下降。
陷阱二：JavaScript 渲染導致行動版內容延遲出現
第二個陷阱更難察覺。很多網站的內容靠 JavaScript 在前端渲染，桌面版因為效能好、瀏覽器執行快，內容很快出現；但行動版在中階手機、較慢的網路下，JavaScript 執行可能延遲，導致 Google 的行動版爬蟲在初次抓取時只拿到一個空殼，看到的內容遠比實際少。這類頁面會頻繁卡在「已檢索，目前尚未建立索引」，因為 Google 抓到的版本根本沒有實質內容可判斷。想深入理解這個機制，可以看 JavaScript SEO 的完整說明。修正方向包括對關頁做伺服器端渲染（SSR）或預渲染，讓內容在 HTML 回應階段就已存在，不依賴瀏覽器執行 JavaScript 才浮現。
| 陷阱類型 | Google 看到的內容 | 排查方式 |
|---|---|---|
| 行動版過度精簡 | 桌面版多出的內容等於不存在，頁面被判為內容薄弱 | 行動裝置測試對照兩版內容量，把關鍵資訊保留 |
| JavaScript 渲染延遲 | 行動版爬蟲初次只抓到空殼，無實質內容可判斷 | 對關頁做 SSR 或預渲染，讓內容在 HTML 階段就存在 |
八種可以安心忽略的報表訊號
知道什麼要修，和知道什麼不要修一樣重要。有八種情況在報表裡出現了，反而代表網站運作正常，硬要去動通常只會增加噪音、消耗工程資源，甚至把原本正確的設定改壞。這份清單的核心判斷標準是同一條：Google 的篩選結果與你的意圖一致時，就不用介入。
- utm 參數網址被列為替代頁面：這是 canonical 正常運作的證據，本尊仍是原始網址，分身該被壓掉。
- 你主動刪除的舊頁變成 404：頁面不存在回 404 是誠實行為，硬要救回來反而把沒價值的舊內容塞回索引。
- 分頁、篩選頁面被列為重複網頁：這類頁面本來就與母頁高度重複，Google 壓縮它們是為了維持搜尋結果多樣性。
- 會員專屬頁、登入後才看到的內容被排除：這些頁面本就不該出現在公開搜尋結果，被封鎖是正確的。
- 站內搜尋結果頁被排除：搜尋結果頁通常是低品質的無限組合，主動排除能避免索引庫被灌爆。
- 移除工具主動下達的封鎖：這是你自己或協作者刻意的操作，要恢復就去工具裡取消，不要繞過它。
- 暫時性的 5XX，修好後數字自然下降：這類通知在伺服器恢復後會自行消失，不必逐筆處理。
- 新頁面短期內出現在「已找到，目前尚未建立索引」：新頁冷啟動期是正常的，給它四到八週再判斷。
這份清單的反面意義同樣重要：當報表顯示的狀態與上述情境不符，例如不是 utm 卻大量被列為替代頁面、或本該公開的內容頁卻卡在已檢索不索引，那才是真正該深究的訊號。把「正常訊號」與「異常訊號」分清楚，你才不會把時間花在那些 Google 其實做對了的事情上。
修完之後：驗證修正、索引與排名的關係
修完問題要在 Search Console 按「驗證修正後的項目」，讓 Google 重新審核。但有一件事要先講清楚：索引只是排名的前提，被收進索引庫不等於會出現在搜尋結果前面，後面還有關鍵字意圖、內容品質、反向連結與網域權重 等一連串排名因素要過。排名一直上不去的人，可以對照 Google 排名關鍵原因解析 找出卡關點。一個頁面從「沒被索引」走到「排在第一頁」，中間通常隔著好幾個月的內容打磨，不是按完驗證就下班。
這條「索引不等於有流量」的落差，外部數據其實給得很殘酷。Ahrefs 分析自家索引中的約 140 億個頁面後發現，96.55% 的頁面從 Google 拿不到任何自然搜尋流量，只有約 1.94% 的頁面每月能拿到 1 到 10 次造訪，等於就算頁面順利進了索引庫，也極可能在搜尋結果裡長期無聲無息 [來源：Ahrefs〈96.55% of Content Gets No Traffic From Google. Here's How to Be in the Other 3.45%〉 https://ahrefs.com/blog/search-traffic-study/ 2023-12-01]。這也回頭解釋了為什麼「已檢索，目前尚未建立索引」值得花力氣修：連索引都進不去，就連那 3.45% 的入場券都拿不到。
「驗證修正後的項目」是觸發重新審核的開關，但 Google 何時回來看是它的排程，無法強制。沒實際改善就反覆按驗證沒有任何效果，反而可能被系統視為干擾。想加速重要頁面被收錄，用網址檢查工具主動提交，搭配 XML Sitemap 維持穩定供給，會比狂按驗證務實。等到頁面真的進了搜尋結果，CTR 點擊率提升技巧 才是決定它能不能被點進去的下一步。
驗證流程有一個常被問到的細節：按下去之後到底要等多久？官方沒有保證的時間表，但實務上多數情況落在幾天到兩週之間，取決於 Google 對你網站的爬取頻率。一個高權重、更新頻繁的網站，驗證後幾天內就可能看到結果變動；一個冷門、低更新的網站，可能要等上數週。判斷驗證是否真的在跑，可以回到報表看那個原因的狀態是否從「失敗」變成「驗證中」，若一直停在「失敗」且超過兩週沒動靜，多半是你的修正沒被 Google 偵測到，要回去確認修正是否真的生效（例如狀態碼改了、標籤移了），反覆重按則無濟於事。把「按下去」與「實際生效」分成兩個階段看待，對節奏的掌握會準確很多。
索引這條線的關係很單純：沒被索引一定沒排名，被索引也不保證有排名。比較務實的長期做法是固定兩到四週回來看一次這份報表、用網址檢查工具主動提交剛上線的重要頁面，讓索引狀態維持在可掌握的範圍。如果你想把這套流程資料化，用 Looker Studio 整合 GA 與 Search Console 能讓索引狀態長期可追蹤，不用每次都手動翻報表。想在報表裡連 AI 流量一起看，GA4 追蹤 AI 流量攻略 提供現成做法。
進階一點還能結合外部工具交叉驗證。用 Screaming Frog SEO Spider 批次爬自己的網站，比對報表裡的未索引網址；用 Ahrefs SEO 工具 或 Ahrefs Brand Radar 從外部觀測索引與曝光狀況；必要時連 Bing Webmaster Tools 一起裝，用第二個搜尋引擎的視角校正自己的判斷。如果想連 Yahoo 的流量一起顧，Yahoo 搜尋排名提升攻略 提供另一條值得布局的成長線。
若你發現某些頁面在 JavaScript SEO 機制下遲遲不被收錄，或 結構化資料、Open Graph 標籤 設定異常連帶影響索引，這些通常需要技術與內容兩條線一起修。想追蹤特定日期區間的索引變化，Search Console 日期快速設定器 能幫你省下反覆點選的時間。
講到長期策略，索引健康度最終會回扣到 AI 時代的終極 SEO 策略 與 AI 時代該怎麼做 SEO。當搜尋結果逐漸被 Google AI Overviews 與 AEO 接管，能被穩定索引、且內容具備 品牌要成為被推薦的答案 的特質，才會是真正吃得到流量的少數頁面。這也是為什麼 SEO KPI 設定 與 SEO 流量公式 裡，索引狀態永遠是基礎盤，要先穩住再談後面的排名與轉換。
如果你的網站有大型改版計畫，改版前一定要先評估流量風險，否則改完才發現索引大面積崩塌，補救成本會高得嚇人。平時也要留意 年度內容更新建議，讓舊內容保持新鮮，避免一堆頁面慢慢退化成「已檢索卻不索引」。追蹤程式碼若是用代碼管理工具部署，先照 GTM Google 代碼管理工具設定 把基礎打好，後續埋設會穩定得多。
想把整套觀念補齊，GSC 是什麼與核心功能總覽 與 Retrieval 檢索 值得一併讀過，能把「爬取 → 索引 → 檢索 → 排名」這條鏈路的後半段補完；排名端的延伸則落在 關鍵字研究終極指南 與長尾關鍵字、SERP 元素等主題。
常見問題 FAQ：網頁索引報表的疑難雜症
把新手最常卡住的問題濃縮成一句結論與一行行動，碰到對應狀況時直接對照即可。其中牽涉結構化資料的疑問，可搭配 結構化資料 Schema 標記完整教學 一併查閱。
「已檢索，目前尚未建立索引」是什麼意思？要怎麼修？
意思是 Google 爬過內容了但認為不值得收錄，問題在內容品質而非技術。行動：充實內容、補強內外部連結、移除黑帽手法，必要時整頁改寫重發；若文章有大量圖片，順手補上 圖片 SEO 優化，整體資訊密度會更高。
重複網頁、使用者未選取標準網頁，canonical 要怎麼設？
用 rel canonical 指定你認定的標準頁即可。行動：認同 Google 的選擇就不用動，不認同才主動宣告 canonical 改變標準。
「驗證修正後的項目」可以一直按嗎？
不行。沒實際改善就狂按對網站沒有任何好處，反而可能干擾重新審核節奏。行動：真的修好才按一次，讓 Google 重新審核。
報表顯示網頁有索引，但搜尋卻找不到，是怎麼回事？
頁面被收進索引庫，只代表它有資格出現在搜尋結果，不等於會被顯示出來。常見原因是該頁在多數查詢下的排名太低、落在結果後段，或被系統判斷為與其他高排名頁面重複而壓縮顯示。行動：用 網址檢查工具 確認索引狀態為「已索引」，再回到內容與排名因素找原因，不要把「沒看到」直接等同於「沒索引」。
行動版內容比桌面版少，會影響索引嗎？
會。行動優先索引下 Google 以行動版內容為準，行動版若精簡掉關鍵內容，頁面會被當成內容薄弱而排除。行動：用網址檢查工具的行動裝置測試對照兩版內容，把關鍵資訊在行動版保留，可以用摺疊或分頁兼顧版面。