「Discovered – currently not indexed」和「Crawled – currently not indexed」是 Search Console 的「網頁索引建立」報表中最常見的兩行，也是最常被誤解的兩行。它們看起來像技術失敗，但實際上通常是 Google 對你的頁面做出的優先順序與品質判斷。更用力地送出不會改變結果，修正原因才會。
這份指南是你可以整個交給 Hermes Agent 的完整流程: 抓取 URL 清單、檢查每個頁面、判斷真正的原因、核准修正佇列、只把值得收錄的頁面透過 Google Indexing API 送出。完成後，你擁有的會是每週可重複執行的流程，而不是一次性狂點按鈕的會議。
完成後你會得到
- 分類好的清單: 卡在 discovered 的 URL、已爬取但未收錄的 URL、以及一開始就不該送出的 URL
- 已送出至 Indexing API 的核准清單，以及附理由的略過清單
- 驗證步驟，顯示你的送出是否真的有效
你需要的條件: 已安裝且能運作的 Hermes Agent(hermes chat 開啟對話。最新安裝步驟見官方文件 hermes-agent.nousresearch.com/docs)、一個你擁有所有權的 Search Console 資源、以及兩組 Google 憑證(一組讀取 GSC、一組用於 Indexing API)。第一次設定約 60–90 分鐘，之後每週執行約 15 分鐘。「完成」的定義: 你送出的 URL 在兩週內於檢查 API 中出現真實的狀態變化，或你有明確證據說明為什麼不會變。
正確解讀這兩個狀態
Google 不是卡在你的網站上。它做了決定，而狀態會告訴你是哪種決定。
狀態 | 實際意義 | 常見原因 | 何時送出 |
|---|---|---|---|
Discovered – currently not indexed | Google 知道 URL 存在(從 sitemap 或連結)，但還沒爬取 | 爬取優先權低、內部連結薄弱或沒有、大型網站的爬取預算壓力、全新網站、又慢又重的 JS 渲染、sitemap 頻繁變動 | 改善優先權訊號(主要是內部連結)之後，送一次 |
Crawled – currently not indexed | Google 抓取了 URL，但決定不加入索引 | 重複或近似重複內容、內容太薄、canonical 指向其他 URL、爬取時存在 noindex、軟 404、被判定價值偏低 | 只有在你真的改變了東西之後: 內容、canonical 或 noindex |
Indexed | 已在索引中 | — | 不要送 |
Excluded | 已爬取且刻意排除(noindex、canonical、重複選擇、封鎖) | — | 不要送; 確認排除是否為刻意安排 |
一句話總結: 只送出你實際改過、或值得再看一次的 URL。Indexing API 是通知管道，不是排名覆寫器。把內容太薄的頁面送 10 次，得到的還是同一個判斷 10 次。
為什麼要交給 agent 跑
GSC 的「要求建立索引」按鈕沒有公開 API，所以沒有官方方法可以用腳本按它。最接近的自動化是 Google Indexing API，它直接接受 URL 通知。Agent 在這裡有價值的理由有三個:
- 流程機械又冗長: 清單 → 檢查 → 分類 → 修正 → 送出 → 驗證。每週重複。
- 需要稽核軌跡: 你需要一個檔案記錄哪些 URL 在何時、為何被送出。
- 需要核准關卡: 寫入 Google 的部分應該由人類審核。Hermes 正是圍繞這個分工設計的，具備技能、專案資料夾與核准規則。
開始前需要什麼
- Hermes Agent 已安裝。繼續之前先用
hermes chat確認。 - 你擁有所有權的 GSC 資源。使用
sc-domain:example.com格式(不是完整網址)。 - 讀取權限: 用於 Search Console API 的 Google Cloud OAuth 用戶端(用戶端 ID + 密鑰)。GSC 技能腳本用這個列出 sitemap、跑搜尋分析、檢查 URL。
- 寫入權限: 已啟用 Indexing API 的 Google Cloud 專案和服務帳戶 JSON 金鑰。把服務帳戶 email 加入 GSC → 設定 → 使用者與權限的擁有者。如果送出回傳 403，就是漏了這一步。
- Python 3 與
pip install google-auth google-api-python-client。 - 專案資料夾。例如
/hermes-seo-project，裡面有context/、data/、qa/，以及一份規定送出步驟永遠需要人為簽核的approval-rules.md。
步驟 1: 建立 URL 清單
把兩個 GSC 技能複製到 Hermes 的技能目錄(~/.hermes/skills): 讀取技能(sitemap、搜尋分析、URL 檢查)和索引技能(送出腳本)。如果 harness 已把技能編目，也可以用 skill_view 載入。
然後在專案資料夾的聊天對話中請 Hermes 執行:
列出 sc-domain:example.com 的所有 sitemap，抓取每個 URL 及其 lastmod，寫入 data/url-inventory.csv。任何抓取失敗的 sitemap 都要標記。
Hermes 會透過 terminal 工具執行 sitemap 指令並寫出 CSV。什麼是好的輸出: 一份去重複的 CSV，包含 URL、lastmod、來源 sitemap。品質檢查: 抽查五列，並把總數與 GSC 的 sitemap 報表對照。如果清單是空的或認證失敗，重新跑一次 GSC 認證流程; 讀取腳本需要新的 OAuth token。
步驟 2: 檢查與分類
接著，agent 會透過 URL Inspection API 批次檢查清單，取得每個頁面目前的涵蓋狀態。請它執行下一階段:
檢查 data/url-inventory.csv 中的每個 URL。分成三個檔案: data/to-submit.txt(未收錄且值得送出)、data/skip.txt(每個 URL 附一行理由)、data/needs-fix.txt(未收錄且卡在我們可以改的東西上)。
檢查 API 每個資源有速率限制(在 Google Cloud Console 查看目前配額; 每天數千次但不是無限)。大型網站請把這輪限定在 lastmod 最新、也就是你這季真的改過的 URL。品質檢查: 抽樣略過清單。大部分應該是 noindex、指向其他 URL 的 canonical、重複頁面，而不是你在意的頁面。如果幾千個 URL 的網站卻得到空的 needs-fix，可能是清單階段漏了頁面，請擴大輸入範圍。
步驟 3: 送出前先判斷
這是大家最常跳過的一步。把卡住的 URL 對應到原因與修正，依這個順序:
原因 | 修正 | 修正後送出? |
|---|---|---|
頁面沒有任何內部連結 | 從相關的已收錄頁面加入有脈絡的連結 | 是 |
全新網站或頁面 | 不用修; 送出一次，等 1–2 週 | 是，一次就好 |
被 robots.txt 封鎖 | 解除該路徑的封鎖 | 是 |
已爬取但重複或太薄 | 重寫、合併或刪除 | 只有真正改過內容之後 |
canonical 指向其他 URL | 錯的話修正 canonical; 故意的話停止送出這個 URL | 只有修正之後 |
爬取時有 noindex | 移除 noindex 讓 Google 重新爬取 | 移除之後，是 |
軟 404、沒有價值的分頁/封存 | 修正頁面或刪除 | 否 — 永久略過 |
請 Hermes 把修正佇列做成表格: URL、推定原因、證據(檢查結果或內容檢查)、建議動作、風險等級。在聊天中逐列核准。你的 approval-rules.md 應該把這定為必要: agent 準備、你核准、超過低風險的一律要簽核才能送出。
核准關卡把 agent 的準備工作和寫入步驟分開。
修正本身是一般的 SEO 工作: 重寫內容、清理 canonical、內部連結。這套流程負責的是送出那一半; 修正那一半由 Hermes 系列的稽核與刷新文章負責。
送出清單是「可修正」與「值得收錄」的交集。
步驟 4: 透過 Indexing API 送出
佇列核准後，把 URL 放進 data/approved-urls.txt，讓 Hermes 執行索引技能:
python3 ~/.hermes/skills/gsc-indexing/scripts/index_submit.py check-auth
python3 ~/.hermes/skills/gsc-indexing/scripts/index_submit.py submit --urls-file data/approved-urls.txt預設通知類型是 URL_UPDATED，適合新頁面或變更的頁面。三個數字要記住: 預設配額是每天 200 個 URL、每分鐘 600 次請求; 而 403 代表服務帳戶不是資源的擁有者。核准清單超過 200 個就分成多天送出，剩下的批次可以讓 Hermes 排程。
絕不要送出已收錄的頁面，也絕不要送出略過清單。浪費的通知只會燒掉配額和製造雜訊。
步驟 5: 驗證，然後等待
送出後的 status 只告訴你 Google 有沒有這筆通知的中繼資料，不代表頁面已收錄。真正的確認在幾天之後。
批次送出 3–7 天後，請 Hermes:
再次檢查 data/approved-urls.txt 中的 URL，並回報與上次執行相比的狀態變化。
健康的進展是 discovered → crawled → indexed。幾週內看起來會是這樣: 未收錄清單縮小，你實際做的修正(新的內部連結、重寫的內容)出現在索引中。記得 GSC 資料會延遲幾天，Google 也會照自己的時程重新爬取。修正後 10–14 天仍停在「Crawled – currently not indexed」的 URL 是品質訊號，不是送出的問題，把它升回內容工作處理。
讓流程持續運作
把流程變成每週例行公事: 上次以來新增或更新的 URL → 檢查 → 分類 → 判斷 → 核准 → 送出 → 記錄。Hermes 可以讓唯讀部分(清單、檢查、分類)依排程無人執行，每個星期一把佇列呈給你。送出步驟保留在核准關卡內，並在 qa/indexing-log.md 持續記錄: 送出日期、URL、通知類型、結果。六個月的記錄是衡量流程是否有效唯一誠實的方法。
誠實的界線
- Google 把 Indexing API 的文件範圍限定在帶有
JobPosting或BroadcastEvent結構化資料的頁面。把它用在一般頁面是廣為流傳的 SEO 做法，但 Google 不保證每個頁面類型都會收錄或提供支援。 - 「要求建立索引」按鈕沒有公開 API。Indexing API 是最接近的自動化，但不是同一個按鈕。
- 送出不會創造優先權。如果頁面在你修正、送出、等待之後仍未收錄，下一個答案是內容品質，而不是再一次通知。
常見問題
Indexing API 可以用在一般頁面嗎?它接受你送出的任何 URL。Google 官方文件把它限定在 JobPosting 和 BroadcastEvent 頁面，所以把一般頁面的送出當作盡力而為: 有幫助、很常見、但永遠不保證。
送出之後為什麼還是「Discovered – currently not indexed」?這個狀態通常代表爬取優先權，而不是失敗。檢查指向該頁面的內部連結、robots.txt 是否封鎖路徑、頁面是否重度依賴 JavaScript。然後等待: 新網站的發現到爬取可能耗時一兩週。
每天 200 個 URL 夠嗎?對大多數網站夠，因為你本來就只該送出真正改過的 URL。如果經常有更多，就依商業價值排序，並在 Google Cloud Console 申請提高配額。
Indexing API 會讓排名變快嗎?不會。它只是通知 Google URL 變了。排名是另一套判斷，由 Google 的系統決定，跟你的通知次數無關。
這跟按 Search Console 的「要求建立索引」有什麼不同?意圖相同，機制不同。按鈕是純 UI、沒有公開 API; Indexing API 是可以腳本化的管道。兩者都不能覆寫 Google 對頁面該不該進索引的判斷。
作者: Julian Mercer，Auspia 技術 SEO 實務工作者，14 年資歷。撰寫關於可爬取性、索引建立、結構化資料，以及讓 Google 和 AI 系統都能正確讀懂網站所需的技術基礎。
