Boloop 閱讀示意圖（AI 生成）：端點可訪問、抓取、地圖處理和索引是不同的信號。
Boloop 的網站地圖曾有一個容易讓人重複修改配置的狀態：瀏覽器可以打開，HTTP 檢查可以取得完整 XML，但 Search Console 卻仍顯示無法讀取。後來，Google 的實時測試也曾成功抓取，但正式地圖記錄還沒有顯示成功下載的時間。
截至 2026 年 10 月 22 日上午，這個問題還不能宣佈完全解決。然而，幾個原本等待的目錄頁面已經被 Google 收錄。這些並存的結果提醒我不應使用單一的綠色或紅色標記來概括整個搜索鏈路。
一張地圖至少有四種不同的結果
第一種是網站公開端點可以訪問：原始地址回傳成功狀態、XML MIME 類型和完整正文。第二種是 Google 的某次實際請求可以取得文件，例如實時測試。第三種是 Search Console 的正式地圖處理狀態。第四種是地圖中每個頁面的索引結果。
四者之間有關聯，但不能互相替代。自家的客戶端取得 200 狀態碼，不能證明 Google 上次訪問也是 200；實時測試成功，不能證明正式地圖已經處理；地圖處理成功，也不保證每個頁面都被收錄。
Google 的 Sitemaps API 將 isPending 定義為尚未處理，lastDownloaded 記錄最近下載時間。這些信息比單看界面上的舊錯誤更適合幫助區分狀態。Google Sitemaps API 欄位說明
先排除自己可以確認的故障
早期排查時，我們分別發送了 GET 和 HEAD 請求，確認沒有意外轉跳，回應類型正確；然後使用 XML 解析器讀取完整正文，檢查命名空間、轉義以及 URL 是否重複、是否指向同一正式來源。還需要檢查 robots.txt 是否允許地圖和目標公開頁面的訪問。
當時還更換了 Googlebot 的 User-Agent。回應與普通請求的位元組一致，可以排除應用對這個請求頭作差異處理的一些可能性；但這仍是自己客戶端發出的請求，不是真正來自 Google 網路的抓取證明。
我們也檢查了地圖生成程式碼的公開發佈條件和失敗回應。不應因為一次讀取成功，就推論資料庫故障或邊緣瞬時錯誤從未發生；同樣，沒有觀察到失敗，也不足以據此修改安全設定。
對照實驗有用，但要保留比較條件
排查期間，我們還準備了一個同內容的靜態地圖進行對照，以縮小「動態生成路徑」和「地圖內容本身」之間的差異。這樣的實驗必須確保兩個檔案內容相同，並記錄部署、提交和讀取時間。
如果一個檔案已經更新、另一個沒有，或比較期間正式站還有其他變更，就不能把它們的狀態差異直接歸因於動態與靜態。即使比較條件一致，實驗通常也只能縮小範圍，不能唯一認定 Google 處理失敗的原因。
退役測試端點後，失效提交記錄也要與正式地圖分開。把舊測試檔案的 404 錯誤留在界面上繼續討論，很容易讓後續的排查混入另一個已經不存在的物件。
目錄已收錄地圖，但地圖仍待處理
10 月 22 日上午的觀察中，英文 Skills 和 Articles 目錄已顯示收錄，Projects 和 About 的索引檢查也有明確通過結果；與同時期，正式 sitemap 的 API 記錄仍顯示 isPending: true 和 lastDownloaded: null。
這時記錄中的 0 errors、0 warnings 不能解讀成地圖解析成功，因為尚未出現成功處理所需的證據。反之，地圖待處理也不能用來否認那些頁面已經收錄的結果。
頁面請求還存在配額和去重問題。Boloop 對已被 Google 接受的索引請求保留記錄，後續只追蹤，不在每次巡檢時重新點擊提交。Google 也明確說明，對同一 URL 重複請求不會加快抓取，提出請求本身不保證收錄。Google 重新抓取說明
什麼時候該繼續調查，什麼時候該繼續觀察
如果精確地圖地址現在回傳 404、轉跳到登入頁、XML 損壞，或 Google 實時測試提供了明確抓取失敗，就沿著那個有證據的失敗繼續修復。若公開回應正常、實時測試成功、正式記錄仍待處理，就保留提交時間、最後下載時間和頁面索引結果，按計畫觀察變化。
對於 Boloop，目前合理結論是：已有檢查沒有重現站內的地圖讀取障礙，但正式處理仍未完成，原因尚未確定。接下來需要的是新的下載或處理證據，而不是每天修改一個地圖地址再提交。
這篇文章沒有提供一個「修改完畢立刻收錄」的按鈕。它提供的一套排查順序是：先確認網站回傳什麼，再核對 Google 實際取得什麼，最後分別判斷地圖和頁面的最終狀態。這樣，即使問題仍在等待，也知道哪些已經查清，哪些還沒有。