如何診斷技術性索引問題

診斷索引問題時，請從你需要的頁面著手，而不是看報告上的總數。先建立一份重要 URL 的清單，找出其中哪些未被收錄及原因，再依嚴重程度逐一處理：先處理伺服器與存取錯誤，接著是意外的封鎖、canonical 衝突、類似錯誤的頁面，最後才是 Google 單純選擇不收錄的頁面。在請 Google 驗證之前，先用 URL Inspection 的即時測試確認每項修正。

本手冊假設你已了解索引機制說明中介紹的各種狀態。

步驟 1：建立重要 URL 清單

「網頁索引」報告會計入 Google 已知的每個 URL，包括帶參數的網址、舊網址，以及你從未打算發布的頁面。「未收錄」的數字很大是正常現象，Google 也明確表示並非每個 URL 都應該被收錄(網頁索引報告)。因此，請從你自己的清單開始：

• 帶來流量的頁面：在 Performance → Pages 中，以三個月為範圍，取前 50 到 100 名。
• 帶來營收的頁面：產品、價格、服務與據點頁面，不論流量多寡。
• 新頁面：過去 90 天內發布的所有頁面。
• 你的 sitemap：其中應該恰好列出你希望被收錄的 canonical URL。你可以依 sitemap 篩選「網頁索引」報告，查看其中有多少 URL 已被收錄；「Sitemaps」報告中的每個 sitemap 也會連結到其 URL 的索引涵蓋範圍。

步驟 2：找出其中哪些未被收錄

若清單很短，可在 URL Inspection 中逐一檢查每個 URL。若清單較長，請開啟依 sitemap 篩選後的「網頁索引」報告，逐一檢視各項原因，確認你的重要 URL 是否出現在範例中。請記錄每個 URL 及其原因與原因的來源。Google 的經驗法則是：一般而言，只有來源標示為「網站」的問題，才是你能自行修正的。

步驟 3：依序處理各項原因

請依下列順序修正。每一層都可能掩蓋下一層，而且前面幾項同時影響的頁面最多。

用 URL Inspection 診斷單一 URL

對清單中的每個重要 URL，執行相同的五項檢查(URL Inspection 工具):

1. 閱讀判定結果與原因。「URL 未知於 Google」表示 Google 完全沒看過這個網址，所以要處理的是探索問題：從 Google 已經在抓取的頁面連結過去，並把它列入 sitemap。
2. 比對 canonical。 若 Google 選擇的 canonical 與使用者宣告的不同，表示 Google 收錄的是另一個 URL，而非這一個。在更動任何設定之前，先查看那個另一個 URL。
3. 檢查抓取狀況。 留意上次抓取日期、Google 是以智慧型手機還是桌面版身分抓取、是否允許抓取，以及頁面擷取是否成功。有一點要特別注意：當 robots.txt 封鎖抓取時，「允許建立索引？」一律顯示為「是」，因為 Google 無法看到自己無權擷取的頁面上的 noindex。
4. 執行 Test live URL。 預設檢視呈現的是上次被收錄的版本，可能已經過時。即時測試會立即擷取頁面，並顯示算繪後頁面的螢幕截圖，是找出「僅登入使用者可見」或「指令碼失敗後才出現」之內容的最快方法。
5. 修正之後才請求建立索引。 Google 設有每日配額，並表示對同一個 URL 重複提出請求並不會加快速度(要求 Google 重新檢索)。

較棘手狀態的說明

遭 robots.txt 封鎖不等於不被收錄。 robots.txt 控制的是抓取，而非索引；被封鎖但有其他頁面連結的 URL，仍可能在沒有內容的情況下被收錄。若要讓某個頁面不出現在 Google，請允許抓取並使用 noindex，可透過 meta 標記或 X-Robots-Tag 標頭設定(封鎖索引)。請記得，只有等 Google 重新抓取該頁面後，移除才會生效，這可能需要一段時間。

canonical 衝突通常是自己造成的。 Google 將重新導向與 rel="canonical" 視為強訊號，sitemap 的收錄視為弱訊號，並偏好 HTTPS(整合重複的 URL)。典型的衝突是 canonical 標記指向某個 URL，而導覽列、sitemap 與內部連結卻都使用其變體(結尾斜線、大寫字母、追蹤參數、http://)。讓它們一致，衝突通常會在下次抓取時解決。

Soft 404 分為兩種。 有些確實是不存在的頁面，例如回傳 200 的「找不到商品」範本，這類應該回傳 404 或 410。另一些是在 Google 看來內容空洞的真實頁面，例如沒有商品的分類頁，或指令碼失敗後內容才載入的頁面，這類需要提供 Google 看得到的內容，即時測試的螢幕截圖可以協助確認。

「已檢索 - 目前尚未建立索引」是一種判斷，而不是錯誤。 Google 抓取了該頁面，並決定暫時不保留；之後可能會被收錄，也可能不會。請誠實自問這個頁面提供了什麼。常見的情況包括：其他頁面的淺層變體、只有兩篇文章的標籤頁，以及內容與其他十個網站所說大同小異的文章。請讓頁面明顯更好或更有差異，或將它合併到已經如此的頁面。

「已找到 - 目前尚未建立索引」通常與連結有關。 Google 知道這個 URL，但還沒有抓取。對大多數網站而言，解法是從 Google 已在抓取的頁面連結到該頁面，並將它保留在 sitemap 中。Google 的抓取預算指南針對的是範圍更窄的族群：頁面超過一百萬且每週更新，或頁面超過 10,000 且每日更新的網站(管理抓取預算)。如果你屬於這種情況，請精簡 URL 清單：整合重複內容、封鎖不應被擷取之 URL 的抓取、對已移除的頁面回傳 404 或 410，並修正 soft 404，因為它們會被持續抓取。

步驟 4：驗證修正

當某項原因下的 URL 都已修正後，在「網頁索引」報告中開啟該原因，並按下 Validate fix，只需按一次。Google 會先檢查幾個抽樣頁面；若問題仍在，驗證就會停止。否則，Google 會重新檢查所有已知受影響的 URL，並將每個標示為通過或未通過。Google 表示驗證通常最長約需兩週，有時會久得多。即使沒有提出驗證要求，Google 也可能在一般抓取過程中發現修正。

何時該收手

當某個狀態背後的 URL 是你不需要被收錄的（參數、篩選檢視、站內搜尋結果、舊的重新導向），或某個頁面已經改善、連結並重新提交，但過了幾個月 Google 仍不收錄時，就可以停止追查。此時比較有用的做法通常是把該頁面合併到更強的頁面並設定重新導向，而不是再次請求建立索引。

AutoPSEO 如何提供協助

AutoPSEO 把步驟 2 變成持續進行的檢查。Index Tracker 可容納最多 1,800 個由你挑選的 URL，每天透過 URL Inspection API 重新檢查其中最多 200 個（最久未檢查的優先，且在 Google 每個資源每天 2,000 次檢查的額度內），並標示過去 30 天內被移出索引的頁面，以及 Google 已有 120 天未抓取的頁面。當被追蹤的 URL 從索引中消失或重新回到索引時，Index flip 警示會發送到 Slack、Microsoft Teams 或 webhook(警示)。URL Inspection 與 Sitemaps 可直接在應用程式內使用，而 Bing 抓取問題則從 Bing 的角度呈現同類型的問題。

對於新頁面，IndexNow 會將已變更的 URL 通知 Bing 及其他支援 IndexNow 的搜尋引擎；Google 並未參與 IndexNow，因此要讓 Google 發現頁面，仍須依靠 sitemap 與內部連結。內容引擎產出的文章會交付到你自己的網站，由網站像處理其他頁面一樣發布並建立連結；當你的網站宣告了 IndexNow 金鑰時，AutoPSEO 會在每個已發布或更新、位於你主機上的網址發出 IndexNow 通知，並記錄 IndexNow 的回應(交付)。