索引推送
上線一個頁面不代表它會被爬取。在新的網域上，Google 可能會將 Sitemap 中找到的網址擱置數週。本技能是頁面上線當天及後續追蹤直到建立索引的例行工作。請使用全部四個通道；它們觸及不同的搜尋引擎並有不同的限制。
| 通道 | 觸及範圍 | 每日限制 | 方式 |
|---|---|---|---|
IndexNow (scripts/indexnow.mjs) | Bing、Yandex、Naver、Seznam、Yep。不含 Google | 每次請求 10,000 個網址 | 一個指令 |
| Search Console 網址檢查 → 要求索引 | 每個資源約 10 個網址；約在美國太平洋時間午夜重置 | 瀏覽器，一次一個網址 | |
| Search Console Sitemap → 重新提交 | 無顯著限制 | 瀏覽器，一個欄位 | |
| Bing 網站管理員工具 → 提交網址 | Bing | 100 個網址 | 瀏覽器，貼上清單 |
「要求索引」是真正推動 Google 索引我們頁面的關鍵：八個停留在「不明」或「已發現」狀態的網址，在我們提出要求後大約一天內全部被索引。僅靠 Sitemap 和 IndexNow 會讓 Google 頁面繼續等待。
瀏覽規則。 Search Console 和 Bing 網站管理員是需登入的網站：請以人類的速度一次處理一個頁面，切勿對它們的使用者介面進行自動化操作。這同樣適用於任何社群網站。若某個網站對你進行速率限制或封鎖，請停止並告知使用者。
一次性設定
- Search Console： 新增一個「網域」資源（透過 DNS TXT 記錄驗證）。絕對不要刪除那筆 TXT 記錄；沒有它驗證會失效。
- Bing 網站管理員工具：「從 Google Search Console 匯入」是最快的方式。GSC 網域資源無法匯入；Bing 會建立一個網址前綴網站（
https://example.com/）來取代，這仍然可行。請也在那裡提交 Sitemap。 - IndexNow 金鑰檔案，在首次提交前部署：
KEY=$(openssl rand -hex 16) printf '%s' "$KEY" > public/$KEY.txt # 任何可從網站根目錄提供的資料夾 # 提交、部署，然後確認它只印出金鑰，沒有其他內容： curl -s "https://example.com/$KEY.txt"package.json中："seo:indexnow": "INDEXNOW_KEY=<key> node scripts/indexnow.mjs --host example.com" - 佇列檔案
docs/seo/index-queue.md（範本如下），提交到儲存庫中。不要放在暫存或暫存資料夾中。
工作流程：頁面上線當天
- 確認頁面已上線。 自有網站，依序請求：
for p in /blog/new-post /zh/blog/new-post; do curl -s -o /dev/null -w "%{http_code} $p\n" "https://example.com$p" done curl -s https://example.com/blog/new-post | grep -o '<link rel="canonical"[^>]*>' - IndexNow。
npm run seo:indexnow -- /blog/new-post /zh/blog/new-post npm run seo:indexnow -- --sitemap # 在大型版本發布後，或不確定什麼改變了時使用www.與裸網域的差異。 - 更新佇列。 透過比對線上的 Sitemap 與已提交的快照來找出自上次執行以來的新增內容（首次執行時，只需儲存快照；
--dry-run不需要金鑰）：node scripts/indexnow.mjs --host example.com --sitemap --dry-run 2>/dev/null | sort > sitemap-now.txt comm -13 docs/seo/sitemap-snapshot.txt sitemap-now.txt # 自快照後新增的網址 mv sitemap-now.txt docs/seo/sitemap-snapshot.txt - 在 Search Console 中重新提交 Sitemap，於新增大量網址或新區塊之後：Sitemaps → 輸入
https://example.com/sitemap.xml→ 提交。比較「已發現的頁面」與你自己的計數。它會過時：我們的 Sitemap 顯示 243 個，直到我們重新提交後才變成 423。 - 在 Search Console 中要求索引，從佇列頂端開始：
- 開啟 Search Console 並確認網址中的帳戶（
/u/0/、/u/1/、/u/2/）顯示了該資源。帳戶索引在不同日子之間會變更；請使用列出該資源的那一個。 - 將網址貼到頂端的檢查列中，等待結果，點擊要求索引，等待即時測試（約一分鐘）。
- 只有在出現「已要求索引」對話框時才算數。沒有對話框表示未成功，通常是因為該帳戶缺少權限。
- 第一次嘗試時出現「發生錯誤」：重試一次。通常會成功。
- 「已超過配額」：當天停止；配額約在美國太平洋時間午夜重置。每天大約可處理 10 個。
- 在佇列列中寫入日期。
- 開啟 Search Console 並確認網址中的帳戶（
- Bing 提交網址： Bing 網站管理員工具 → URL Submission → 提交網址 → 從佇列中貼上接下來的網址，每行一個，直到用盡頁面上顯示的剩餘配額（每天 100 個）。在佇列列中寫入日期。
- 記錄 每個動作一行寫入
docs/seo/log.md，並附上部署或提交參考：- main=abc1234 已上線。IndexNow 18 個網址 → 200。GSC 要求了 10 個（第 11 個超過配額）。Bing 提交了 100 個，佇列中剩 44 個。
後續追蹤，1 到 3 天後
先在網址檢查中檢查最新的頁面（Bing 有其類似的網址檢查功能，狀態也類似）：
| 狀態 | 意義 | 處理方式 |
|---|---|---|
| 網址已存在於 Google | 已索引 | 標記為已索引，從佇列移除，記錄下來 |
| Google 不認識這個網址 | 不在 Google 已讀取的 Sitemap 中，找不到任何連結 | 重新提交 Sitemap、新增內部連結、要求索引 |
| 發現 – 目前尚未索引，參照頁面：未偵測到 | Google 僅從 Sitemap 知道這個網址，尚未爬取 | 從已經被爬取且造訪過的頁面建立連結；爭取外部連結；要求索引 |
| 已檢索 – 目前尚未索引 | 已擷取，但判定尚不值得索引 | 檢查內容是否過於單薄或近似重複（翻譯、範本頁面）；改善或合併。更多請求無濟於事 |
| 重複，Google 選擇了不同的 canonical | Canonical 或 hreflang 混淆 | 修正 canonical 標籤；確保語言版本內容不重複 |
| 重新導向的頁面 / 找不到 (404) | Sitemap 中的網址錯誤 | 修正 Sitemap |
「參照頁面：未偵測到」是關鍵線索：解決方案是連結，而不是更多提交。對我們有效的方法：從首頁與頂級指南的頁尾區塊連結最新的五篇文章、在相關文章之間交叉連結，以及一個公開的 GitHub 儲存庫，其 README 連結到這些頁面。
Search Console 的成效數據會延遲 2-3 天。不要根據昨天的數字來評判一個頁面。
佇列檔案範本
# 索引佇列
頂端 = 下一個要提交的項目。排序：最新優先；英文和中文先於其他語言。
限制：Google 要求索引每天每個資源約 10 個（約美國太平洋時間午夜重置）。Bing 提交網址每天 100 個。
| URL | 新增日期 | Google 已要求 | Bing 已提交 | 已索引 |
|---|---|---|---|---|
| https://example.com/blog/new-post | 2026-11-07 | 11-08 | 11-07 | |
| https://example.com/zh/blog/new-post | 2026-11-07 | | 11-07 | |
檢查清單
- 每個網址已上線：200、自我 canonical、在 Sitemap 中、從已爬取的頁面有連結
- IndexNow 為新的和變更的網址回傳 200 或 202
- 佇列已更新並按優先順序排序
- 在大量新增後重新提交 Sitemap；已發現的數量相符
- Search Console 要求索引達配額上限，每個都有對話框確認
- Bing 提交網址達配額上限
- 記錄行已寫入，附有提交或部署參考；已註明後續檢查日期
我們遇過的陷阱
- 要求索引連續三天沒用。 從未出現確認對話框。瀏覽器的預設 Google 帳戶沒有該資源的存取權；改成以擁有該資源的帳戶（不同的
/u/N/）開啟 Search Console 後立刻解決。幾天後該資源又在另一個索引下開啟。 - 「無效的 Sitemap 位址」。 在網域資源上，輸入
sitemap.xml會失敗；完整的https://example.com/sitemap.xml才有效。 - 過時的 Sitemap 計數。 在網站有 100 個頁面後，Search Console 仍顯示 11 個已發現的頁面，直到我們重新提交；之後從 243 變成 423。
- 未連結的頁面依然隱形。 兩篇沒有任何內部連結的指南，數天後仍處於「Google 不認識這個網址」的狀態。
- 配額的猜測。 我們最初假設每天約 4 個請求；實際約為 10 個。第 11 個會回傳「已超過配額」。
- 當天的第一個請求失敗，出現「發生錯誤」。重試一次就成功了。
- 遺失佇列。 一份包含 115 個網址的 Bing 清單存放在暫存資料夾中，在 session 重啟後消失，我們從 Sitemap 重建了它。請將佇列保留在儲存庫中。
- 佇列長度超過配額。 在忙碌的一天後，115 個網址等待著 100 個 Bing 名額。優先順序決定了哪些先被處理：英文和中文的新文章優先，翻譯在後。
- session 中沒有瀏覽器。 Search Console 和 Bing 需要瀏覽器；IndexNow 不需要。先執行 IndexNow，記錄缺口，留到下次 session 補上。
- 202，然後 200。 IndexNow 對使用新金鑰的首次提交回覆 202，之後回覆 200。兩者都是成功。
- 翻譯耗盡配額。 Sitemap 中 441 個網址裡約 392 個是翻譯。手動提交所有翻譯會耗盡數天的配額在新網域很少被索引的頁面上。
相關技能
- seo-page：建立本技能所要建立索引的頁面。
- programmatic-pages：一次上線大量網址；佇列優先順序在此處最為重要。
- multilingual-seo：應優先發布與提交哪些語言版本；hreflang。
- competitor-pages、trend-keywords：有時效性的頁面，應放在佇列最前面。
- keyword-research：決定最初要存在哪些頁面。
- ai-search：針對 AI 爬蟲的 llms.txt 和 robots.txt；Bing 的索引也為 Copilot 提供資料。
- seo-daily-report：回報哪些頁面已建立索引，以及明天佇列中有哪些。