如果你做過 SEO，一定遇到過這種抓狂時刻：頁面已經更新了，甚至你自己都檢查過很多遍沒問題，但搜索引擎就是不來抓，或者抓了很久才反映到索引裏。IndexNow 的出現，其實就是爲了解決這個“通知成本太高”的問題：與其讓搜索引擎靠 sitemap 或隨機抓取碰運氣，不如你在頁面變化時主動告訴它：這幾個 URL 變了。

先把預期說清：IndexNow 不會讓你立刻排名，它也不是跳過質量審覈的捷徑。它做的事情更像是把發現與抓取這一步變得更及時、更穩定。對於內容更新頻繁、URL 量比較大、或者經常下架產品的站點，IndexNow 往往能讓“變化被看見”的速度快一截，間接減少舊信息造成的誤導和跳出。

一句話理解 IndexNow：你發“變更清單”，引擎按清單來抓

傳統方式裏，sitemap 像是一張全量目錄，搜索引擎會定期來讀，但它並不知道哪些 URL 真的變了。IndexNow 更像增量更新：你新增了頁面、改了內容、刪了產品，就把這些 URL 打包成請求發出去。引擎收到後，會把它們加入待抓取隊列。你不用每天盯着它有沒有來抓，但你能把“我已經通知了”這件事做成確定性動作。

什麼時候值得用（以及什麼時候別浪費時間）

  • 值得用：產品經常上下架、價格/庫存經常變；新聞/博客更新頻繁；大站點抓取預算緊張；遷移/改版後需要更快讓引擎跟上。
  • 不建議優先：站點基礎技術問題一堆（robots 攔了、canonical 混亂、404 很多）；內容質量不穩定。因爲這類站點的瓶頸通常不在通知，而在頁面本身。

配置步驟：關鍵就 2 件事（key + 放對位置）

IndexNow 的配置看起來有點技術，但真正容易錯的就兩點：key 文件放錯位置、以及 URL 版本不一致。標準做法是：生成一個 key（一串字符），然後把這個 key 作爲文件名，放到你站點根目錄下（也就是訪問 https://example.com/{key}.txt 能直接打開的地方），文件內容也放同樣的 key。這樣引擎才能確認你有權限代表這個站點發送通知。

你完成 key 文件之後，就可以開始推送 URL 了。推送的 URL 要和你的網站最終版本一致：全站是 https 就不要推 http；你統一了不帶 www 就不要推帶 www。很多人推送成功了卻沒效果，最後發現是 URL 版本混用，等於你在通知一個並不存在的站點版本。

最小可用的推送節奏：先手工跑通，再考慮自動化

新手不需要一上來做複雜集成，你可以先用最小動作跑通：每次發佈文章/上新產品時，把 URL 記錄到一個列表裏，湊夠 10～50 個就推送一次。等你確認“推送—抓取—索引更新”的鏈路是通的，再考慮自動化（例如 CMS 發佈後自動推送）。這樣做的好處是：你能知道問題出在哪一步，而不是一開始就把系統搞複雜。

POST https://api.indexnow.org/indexnow
{
  "host": "example.com",
  "key": "YOUR_KEY",
  "keyLocation": "https://example.com/YOUR_KEY.txt",
  "urlList": [
    "https://example.com/page-a",
    "https://example.com/page-b"
  ]
}

驗收：你怎麼知道自己配置對了？

  • 用瀏覽器能打開 key 文件（返回碼 200），內容就是那串 key。
  • 推送的 URL 在站點裏能正常訪問（非 404/非跳轉到另一個版本）。
  • 過一段時間後，在 Bing Webmaster Tools 裏能看到抓取/索引趨勢變化（不用追求秒收錄，但至少應當更穩定）。

常見坑：推送了不該推的 URL，結果把站點搞亂了

最常見的問題是推送了 noindex 頁面、參數頁、站內搜索頁，等於你在主動邀請引擎來抓一堆你自己都不想被收錄的內容。正確做法是：先把站點的索引策略理清楚（哪些該收錄、哪些不該），再把推送範圍限定在確實需要被發現的頁面。如果你擔心索引膨脹，先讀這篇：索引膨脹怎麼控。

延伸閱讀

參考資料