Search Console 網頁索引報表：揪出未收錄頁面

先把話說在前頭：網頁索引報表是一份「健康檢查報告」，不是業績報表

不少人都有過這種經驗：打開 Google Search Console（以下簡稱 GSC），點進左側選單的「索引」→「網頁」，看到一個刺眼的數字：未建立索引的網頁。第一個反應是網站是不是被 Google 懲罰了。

這種反應通常是把索引報表當成流量報表。看到許多網址被標成未建立索引，不代表網站受到處罰，也不表示每個網址都需要修；要先確認那些頁面原本是否就應該被索引。

換句話說，網頁索引報表回答的是一個具體問題：Google 是否把已知網址收進索引？它跟流量高低沒有直接對應關係。頁面可以成功建立索引卻沒有自然流量；未建立索引也可能是重複網址、noindex、抓取問題或 Google 尚未選擇該頁。根據 Ahrefs 對數百萬頁面的研究（2023 年 12 月），超過九成的網頁沒有取得 Google 自然搜尋流量；這不能直接推論成未索引比例或內容品質判決。

換個比喻。Google 的索引就像一座超大型圖書館的書庫，而網頁索引報表是圖書館管理員交給你的一張「收書清單」，上面逐條寫著：這本收了、那本沒收、那本因為跟另一本內容重複所以僅留一份。你的工作是讀懂管理員在每一條旁邊寫下的備註，看到「沒收」先別急著緊張，再判斷哪些該補件、哪些本來就不該收。

接下來就帶你把這件事做完：讀懂備註、判斷輕重、建立一套可以反覆執行的索引健檢流程。如果你還沒安裝或驗證過 GSC，建議先看過 GSC 完整安裝與驗證教學 把基礎環境架好；如果你想先把「索引」這個概念本身搞懂，如何確認網頁被索引 會幫你打底；想把 GSC 放進整個 SEO 工具堆疊，也可參考 SEO 工具完整評比。接下來我們直接鑽進報表的細節。

報表的骨架：兩大狀態，以及未建立索引的原因

現行網頁索引報表的總覽主要分成「已建立索引」與「未建立索引」，再於未建立索引項目下列出原因；舊版報表常見的「排除」不是第三個並列總狀態。Google 官方的網頁索引報表說明把這份報表定義為檢視網站上哪些網頁已建立索引的入口。介面與狀態名稱可能調整，診斷時要以帳戶當下顯示及官方說明為準。

這裡有一個關鍵認知：未建立索引不等於出錯。原因可能是頁面有技術障礙、屬於替代或重複網址、被 noindex 排除、尚未被選擇建立索引，或原本就不需要出現在搜尋結果。要先看報表原因與網址用途，不能把所有未索引頁面歸為品質不足。

理解這一點之後，你讀報表的方式會整個改變。你不會再把「未建立索引」當成警報，而是把它當成 Google 寫給你的一封信，信裡逐項說明它為什麼把某些網址退件。下面幾節，我們就把這封信拆開來讀。

報表裡兩個最容易被放過的欄位

除了狀態之外，報表還提供兩個欄位，多數人點開報表僅盯著網址清單看，完全跳過它們，但這兩個欄位才是診斷的關鍵線索。

• 來源：未索引原因表的 Source 指問題來源為 Google 或 Website，不是網址從 Sitemap 或參照網頁被發現的路徑；發現資訊應另到 URL 檢查查看。
• 最後檢索日期：比對範例網址上次抓取與修改時間，再視需要使用網址檢查工具確認即時回應；重新處理請求不保證立即抓取。

把這兩個欄位養成習慣一起看，你對報表的判讀能力會比僅看狀態名稱的人高出一個檔次。

「已檢索，目前尚未建立索引」對上「已發現，目前尚未建立索引」：兩個最常被搞混的狀態

這兩個狀態名稱長得幾乎一樣，背後的因果機制卻完全不同，而它們也是整份報表裡出現頻率最高、最讓站主焦慮的兩條。以下用爬蟲的行為來拆解，你一看就懂。

已檢索，目前尚未建立索引（Crawled, currently not indexed）代表 Googlebot 已檢索這個頁面，但目前沒有建立索引。內容品質、重複性與獨立價值都可能是原因，卻不能僅看這個狀態就斷定「內容太差」；也要用網址檢查工具確認 Google 看到的內容、正規網址、回應狀態與網站內部連結。

已發現，目前尚未建立索引（Discovered, currently not indexed）是更前面的階段。Google 知道網址存在，但目前尚未檢索。官方說明常見情況是 Google 原本想抓取，但預期當時抓取可能讓網站超載，因此改期；大量低價值網址、伺服器狀況與內部連結也值得一起檢查，不能簡化成「權重不夠」。

如果「已發現」長期累積，先分辨是少數新網址，還是大量重要頁面都未被抓取。大型或網址容易膨脹的網站，才需要進一步檢查爬取需求、主機承載與低價值參數頁；一般小站不必一看到這個狀態就進行「爬取預算優化」。相關方向可參考 爬取預算優化策略。

還有一個實務提醒。這兩個狀態都會自己變動。一個今天顯示「已發現，目前尚未建立索引」的頁面，可能兩週後 Google 終於排到、抓了、收了，狀態就翻成已建立索引。所以看到這兩個狀態，第一個動作是先記下來、等一到兩個檢索週期再看，別急著動手改東西。急著改，反而在 Google 還沒抓到舊版本時就把頁面改得面目全非，徒增困擾。

重複網頁的整束處理：canonical、備用網頁，以及 Google 自己選的正規網址

網頁索引報表裡有一整類狀態跟「重複」有關，這是大家最常看不懂、也最容易下錯藥的一區。原因出在多數人沒搞清楚一件事：Google 處理重複內容的方式，不是懲罰，而是合併。

當 Google 發現網站上有兩個或多個網址的內容幾乎一樣（例如產品頁加上追蹤參數、http 與 https 版本，或排序參數頁），通常會選一個代表版本，並嘗試整合重複網址的部分訊號。這個代表叫做正規網址（canonical URL）；canonical 是提示，不保證 Google 一定照站方指定，也不能理解成所有排名訊號必然完整轉移。

報表裡跟重複相關的狀態主要有三條，它們對應的是 Google 做這個合併決策時的不同情境。

備用網頁（已正確指定正規網頁）

這是最理想的狀態。你透過 canonical 標籤或其他方式明確告訴 Google「這個頁面的正規版本是另一個網址」，而 Google 接受了你指定的版本。被標成備用網頁的那個網址不會被索引，這完全正常，也不需要修。你在這裡該做的僅有一件事：確認你指定的正規網址真的是你想排名的那個頁面。canonical 標籤的設定邏輯，可以對照 Canonical URL 標準網址。

重複網頁（Google 選擇了不同的正規網頁）

這條就要留意了。它的意思是：你指定了某個網址當正規版本，但 Google 自己選了另一個。Google 不一定總是聽你的，當它認為你選的正規網址不如它選的那個合理時（例如你指向了一個被 noindex 的頁面、或指向了一個根本抓不到的網址），它會覆寫你的決定。

遇到這個狀態，點進去看 Google 選的是哪一個。如果它選的版本正好也是你心目中正確的那個，那就把你的 canonical 標籤改成跟它一致，消除這個不一致的訊號。如果它選的是錯的（例如選了一個帶追蹤參數的網址），那你需要檢查內部連結結構，確保全站連向這個內容時都用同一個乾淨網址，讓 Google 看到更強的一致性訊號。

重複網頁（使用者未指定正規網頁）

這條代表你什麼都沒設，Google 自己判斷重複並自己選了一個代表。這在中小網站偶爾出現沒什麼大礙，但如果你的電商網站有大量篩選參數組合，每個組合都被當成獨立網址，你就會看到這一條爆量。這時候問題出在你的網址結構和參數處理，屬於全站層級的事，不是修單一頁面能解決的。相關的參數管理，需要從網址結構和篩選機制兩端一起治理。

Soft 404 陷阱：你的頁面明明回傳 200，為什麼還是被判死

這是整份報表裡最陰險的一條，也是最值得單獨拿出來講的狀態。Soft 404 的全名是「軟性 404」，它的弔詭之處在於：你的伺服器明明對這個網址回傳了正常的 200 狀態碼，頁面也打得開，Google 卻把它當成「不存在的頁面」處理，不收進索引。

Soft 404 通常表示頁面以成功回應碼提供「找不到」或空白等內容，讓 Google 判斷它實際上不存在。這不是所有低價值或排名差頁面的通稱，應查看實際回應與渲染結果。

• 空頁面或近乎空的頁面：頁面載入了，但主要內容區塊是空的，例如一個分類頁底下所有產品都下架了，僅剩下導覽列和「目前沒有商品」幾個字。
• 「找不到結果」訊息：搜尋結果頁、篩選頁回傳了「查無符合條件的內容」，這類頁面對 Google 來說跟 404 沒兩樣。
• 主要內容載入失敗：伺服器、資源或 JavaScript 問題可能讓 Google 只看見空白或錯誤訊息，需用即時測試確認。

Soft 404 危險的地方在於它不會像真正的 404 一樣被你察覺。真正的 404 你在報表裡會看到、伺服器記錄也會記，但 Soft 404 的頁面在你眼裡是「正常的、打得開的」，所以你根本不會想到去檢查它。結果是，你以為這個頁面在線上正常運作，其實它在 Google 眼裡已經是死頁。

商品分類暫時沒有商品時，Google 可能依頁面內容與回應方式判定為 Soft 404，也可能保留索引。若分類仍會使用，可提供有用說明、替代商品或補貨資訊；若永久移除且沒有替代內容，則應回傳合適的 404 或 410，不能只讓空頁持續回傳 200。

正確的應對方式不是去改這個頁面的 HTTP 狀態碼，真正的根本處理是：讓沒有內容的頁面回傳真正的 404 或 410，別用 200 空殼硬撐。如果是暫時性的缺貨，可以保留頁面但放上有意義的說明（例如預計補貨日期、替代商品推薦），讓頁面在空檔期仍然對使用者有價值。

伺服器錯誤、找不到、被封鎖：報表裡真正的紅色警報

前面講的狀態，多半屬於「Google 做了選擇」的範疇，不管是品質考量還是資源排程。但報表裡有一整束狀態，問題出在你的硬體或設定層面，跟 Google 的選擇無關，是這些技術障礙讓 Google 想收都收不進去。這些才是真正該亮紅燈的項目，因為它們每一個都在擋掉本來有價值的頁面。

伺服器錯誤（5xx）

當 Googlebot 抓取某個網址，你的伺服器回傳了 500、502、503 這類錯誤，這個網址就會被歸到這裡。背後原因五花八門：伺服器負載過高、資料庫連線逾時、部署期間剛好被撞上、主機商那端出了狀況。Google 的設計是容忍短暫波動的，偶爾一兩次 5xx 不會立刻把頁面踢出索引，但如果錯誤持續出現，Google 會判定這個頁面不穩定，慢慢把它從索引裡移除。

實務上，這條最該看的指標是持續性。一個頁面昨天還好好的，今天突然冒出 5xx，多半是你剛改了什麼、或伺服器正在維護。報表上看到它時，先別慌，去伺服器記錄或主機商後台確認當下是不是真的有錯誤。如果已經修好了，用網址檢查工具觸發重新檢索，狀態會在下次回報時更新。

找不到（404）與重新導向錯誤

404 可能來自刻意刪除、網址變更或錯誤連結，不一定需要修正。若有真正對應的新頁面，可永久轉址；沒有替代內容就保留 404 或 410，並更新站內連結與 Sitemap，不要一律導向首頁。

重新導向錯誤則是另一回事。它不是網址不存在，而是你的轉址設壞了。常見的狀況是轉址鏈結太長（A 跳 B、B 跳 C、C 又跳回 A 形成迴圈），或者轉址指向的目標本身回傳錯誤。Googlebot 跟到一半放棄，這個網址就被標成重新導向錯誤。排查的方法是拿瀏覽器的開發者工具追蹤網址的跳轉路徑，看它到底卡在哪一環。

遭到 robots.txt 封鎖

這條特別值得提出來講，因為它常常是無心之過釀成的最大損失。robots.txt 是一份告訴爬蟲「哪些路徑不要抓」的清單，問題出在它的封鎖規則是按路徑比對的，一個寫得太寬的 Disallow 規則，可能連帶把你以為沒事的重要目錄整個封掉。

實際常見的狀況是：站長為了擋掉一個測試用的子目錄，在 robots.txt 寫了一行 Disallow，結果規則寫得太鬆，把整個產品分類頁的路徑都涵蓋進去。網站前台看起來一切正常，使用者點得到、買得到，但 Google 從那一天起就再也沒抓過那些頁面，排名和流量悄悄往下掉，站長卻完全不知道原因。這類問題的可怕之處在於它無聲無息，你不去翻 robots.txt 跟這份報表，根本察覺不到。

排查的做法很直接。報表裡點進「遭到 robots.txt 封鎖」這條，看被封的是哪些網址路徑，然後開你的 robots.txt 檔案，逐行比對是哪一條規則把這些路徑涵蓋進去的。修掉之後，等 Google 下次檢索就會解封。如果你想更系統性地理解 robots.txt 的撰寫邏輯，robots.txt 介紹 有完整的規則說明。

這幾條狀態有一個共通點：它們全部是技術性、可修復的問題，而且修了之後效果通常立竿見影。一個被封鎖的重要頁面解封、一個斷掉的轉址修好，往往比花一週去打磨內容更能即時挽回能見度。這也是為什麼接下來那張分診矩陣，會把這幾條排在「立即處理」的最優先位置。

把報表當成分診站：一張索引修復優先矩陣

報表裡可能出現十幾種狀態，但它們的重要性天差地遠。如果你不排優先順序，就會把時間花在修一些根本不影響生意的狀態上。這裡把它們整理成一張分診矩陣，你每次打開報表，照著這張表把網址分類就好。

這張矩陣的精髓在於：它強迫你把注意力放在「本來該被收、卻沒被收」的網址上。這些才是你的能見度正在流失的地方；至於那些本來就不該被收的網址，Google 不收它反而是在幫你做資源管理。

判斷索引需求應看頁面用途與內容。分頁第幾頁並不能單獨決定是否排除；Google 建議分頁各有獨立網址與 self-canonical。排序或列印版本再依重複程度處理，可參考noindex 的適用情境。

robots.txt、noindex、移除工具：三種「不要被收錄」手段的差別與風險

講到索引控制，這三個工具的名稱常被混在一起講，但它們的作用層級和風險完全不同。搞混它們，最常見的後果是：你以為自己在排除一個頁面，結果連帶把整個目錄都封鎖了，或者反過來，你以為已經移除了，其實 Google 根本沒收到指令。

這裡有一個非常經典的陷阱：robots.txt 和 noindex 不要同時用。原因在於作用階段。如果你在 robots.txt 封鎖了某個網址，Googlebot 根本不會去抓那個頁面；既然沒抓，頁面裡的 noindex 標籤它也看不到。結果是，如果那個頁面之前已經被索引了，你用 robots.txt 封鎖它、想藉此移除索引，Google 反而無法看到你想移除的意圖，已索引的舊版本會繼續留在資料庫裡。

如果要長期移除一個仍可保留存取的頁面，通常讓它保持可檢索並提供 noindex，直到 Google 重新抓取並處理。之後是否再用 robots.txt 管理抓取，要看網站規模與目的；robots.txt 不是存取控制，也可能讓 Google 無法讀到更新後的 noindex，因此不應套用固定的「先 noindex、再封鎖」流程。私人內容要用登入、權限或密碼保護。

至於移除工具，它是 Google 提供的一個應急手段。當你需要快速讓某個網址從搜尋結果消失（例如不小心發布了敏感內容、或頁面被植入惡意程式碼），可以用它申請暫時移除。Google 官方說明明確指出，移除工具是暫時性的措施，目的是在持久性的移除機制（如 noindex 或刪除頁面）生效之前，先讓網址從搜尋結果消失。講白一點，移除工具是OK繃，不是根治。你貼上去之後，還是得在背後把真正的移除機制做好，否則六個月後那個網址會自己跑回來。

行動裝置優先索引：為什麼你的桌面版沒事，手機版卻讓 Google 拒收

索引控制還要理解行動裝置優先索引（Mobile-first Indexing）。Google 從 2023 年下半年起，已幾乎全面改用智慧型手機代理程式看到的內容建立索引（見 Google Search Central Blog 的公告）。它描述的是採用哪個版本建立索引，不是「有手機版就加分」的獨立排名訊號。

這跟網頁索引報表有什麼關係？關係大了。如果一個頁面的桌面版內容完整豐富，但手機版因為版面設計、JavaScript 轉譯、或圖片延遲載入的關係，讓主要內容在手機上根本沒有正常顯示，那麼 Google 抓到的、據以判斷要不要索引的，就是那個殘缺的手機版。結果就是：你以為這個頁面內容很好應該被收，Google 卻看到一個空洞的手機版，把它判定為品質不足或 Soft 404，不收進索引。

這在 JavaScript 重度使用的網站特別常見。桌面瀏覽器有充足的運算資源可以把動態內容渲染出來，但 Googlebot 在行動裝置模式下抓取時，如果 JavaScript 執行失敗或內容是靠使用者互動才觸發載入的，Google 就抓不到那塊內容。關於 JavaScript 對 SEO 的具體影響，可以對照 JavaScript SEO。

可用 GSC 的網址檢查工具執行「測試實際網址」，查看 Googlebot 取得的 HTML、畫面截圖與載入資源，再和實際手機版比較。若主要內容需要點擊後才載入、遭 robots.txt 擋住，或手機版本身缺少內容，索引就可能不完整。Core Web Vitals 主要衡量使用體驗，並非索引效率的直接指標，兩者不要混為一談。

已建立索引，但沒有內容：一個更安靜的陷阱

「Page indexed without content」表示 Google 已索引網址，但因某些原因無法讀取內容。官方列出的可能原因包括對 Google 隱藏內容或無法處理的格式；它不等同網站真的空白，也不是 robots.txt 封鎖狀態。

遇到這個狀態時，應檢查 Google 與一般使用者取得的回應是否不同、內容格式是否可處理，以及載入是否出錯。JavaScript 可列為調查面向，但不能把它定為最典型或唯一原因。

用 URL 檢查比對已抓取資料與即時測試，必要時檢查伺服器及 CDN 回應。依確認的原因調整內容輸出或渲染方式；SSR 是一種實作選項，不能保證適用所有索引問題。

這條狀態之所以是「安靜的陷阱」，是因為它在報表上顯示的仍是「已建立索引」，粗心的人會直接略過，以為沒事。但一個被收進索引、內容卻是空的頁面，跟沒被收進索引其實沒兩樣，它不會為你帶來任何流量。所以當你做索引健檢時，別僅盯著未建立索引那一塊，偶爾也抽幾個已建立索引的頁面，確認 Google 真的看到了你以為它看到的內容。

從報表到行動：一份照著做的索引健檢清單

讀到這裡，你應該已經能讀懂報表上每一條狀態在說什麼了。但讀懂和會修是兩回事。下面提供一份可以直接照著執行的索引健檢清單，建議每個月或每次有大規模內容更新之後跑一遍。這不是一個要你一次做完的龐大工程，而是一個讓你在三十分鐘內能掌握網站索引健康度的例行檢查。

索引健檢六步流程

1. 記下兩個基準數字。打開報表，記下「已建立索引」和「未建立索引」的網頁數，跟內容發布、下架及改版紀錄一起比較。沒有適用所有網站的固定月變動百分比；異常與否要看預期的網址數量是否同步變化。
2. 先確認重要網址是否受技術問題影響。伺服器錯誤、robots.txt 誤封與意外 404 應優先處理；刻意刪除的網址回傳 404 則可能完全正常。先核對網址用途，再判斷損失與優先級。
3. 抽查 Soft 404 與已檢索未索引。不用全部看完，挑流量或商業價值最高的幾個網址，用網址檢查工具看 Google 實際抓到的內容是什麼。如果抓到的是殘缺的手機版或空洞內容，回去修頁面本身。
4. 確認 canonical 一致性。看「Google 選擇了不同正規網頁」這條，確認 Google 選的版本跟你想排名的版本一致。不一致的，把全站內部連結和 canonical 標籤統一指向正確網址。
5. 檢查 Sitemap 覆蓋率。使用報表的 Sitemap 篩選，看看你的重要頁面是不是都有靠 Sitemap 被提交。如果有重要頁面是靠參照網頁被發現的、卻不在 Sitemap 裡，把它補進去。
6. 把確定不要的頁面收乾淨。對於已確認沒有獨立搜尋用途的篩選或重複列印版本，確認它們有正確的 noindex 或 canonical 處理，讓 Google 把爬取資源留給有價值的頁面。

這六步走完，你對網站當下的索引健康度會有一個清楚的掌握，而且你修的每一項都是會實際影響能見度的事，不是虛功。

修好報表支援驗證的問題後，可以使用「驗證修正」要求 Google 檢查一組受影響網址；不是每種未建立索引原因都有這個按鈕。處理時間沒有固定天數，驗證也不等同保證建立索引，期間應查看通知與網址狀態，而不是反覆送出請求。

一個常被忘記的觀念：索引是起點，不是終點

這裡要提醒你一個觀念。被索引僅是拿到了進入搜尋結果的入場券，不等於會有排名、更不等於會有流量。Backlinko 分析超過一千一百萬筆 Google 搜尋結果的研究（2025 年 4 月）指出，排名高低受到頁面載入速度、反向連結、內容深度、搜尋意圖契合度等多重因素影響。換句話說，索引報表解決的是「你的頁面在不在場內」的問題，至於在場內能排到哪裡，那是另一整套學問，涉及 E-E-A-T 經驗權威訊號、頁面優化、反向連結 等等。

但這份報表的價值在於，它是所有這些努力的前提。一個連索引都沒進去的頁面，你再怎麼優化內容、再怎麼累積連結，都不可能出現在搜尋結果裡。所以把這份報表讀熟、把索引健康度顧好，是你做其他所有 SEO 工作之前的基本功。地基不穩，上面蓋什麼都會晃。

還有一個觀念值得補充。索引健檢屬於該定期回診的習慣，像做健康檢查一樣，不是那種做完一次就交差的工程。網站會持續長大、改版、累積新頁面，每一次變動都可能悄悄引入新的索引問題：一個改版後的轉址沒設好、一個新上線的分類頁內容太薄、一個被你遺忘的舊外掛在 robots.txt 寫了一條多餘的規則。這些問題在發生當下往往無聲無息，等你發現流量往下掉了才回頭找原因，中間已經隔了好幾週。把索引報表排進你的月度例行檢查，成本很低，卻能讓你在問題還小的時候就接住它。

如果你照著這份清單走完一輪，發現網站的索引狀況其實沒你想像的那麼糟，那也很好。網頁索引報表最大的價值，往往不是讓你發現一堆問題，而是讓你心裡有底，知道你的網站在 Google 眼裡到底是什麼狀態。這份踏實感，比任何技巧都重要。