聊 URL 發現，多數人從蜘蛛那一侧入手：内鏈怎么铺、Sitemap 怎么寫、目錄该宽還是该深。這些做法本质上都是被動等待——线索摆在那儿，蜘蛛什么时候来、来了抓不抓，主動權不在站長手里。還有另一條路径：把 URL 主動告诉搜尋引擎，让它在最短時間内知道這個地址存在。
被動發現和主動通知，解决的不是同一個問题
被動發現决定的是某個 URL 大概多久之後可能被蜘蛛看到。一個正常的内鏈入口，新頁面在几小时到几天内被發現都算常见；如果連結藏在列表第三頁之後，可能是几周。主動通知改變的是起点：提交之後，URL 會直接進入搜尋引擎的發現队列，不再需要等蜘蛛顺着連結爬過来。
但它只改變起点。提交成功不等于被抓取，更不等于被收錄。搜尋引擎接收的是一個待办條目，最终抓不抓、收不收，還是取决于内容质量、站点整体信任度和服務器表現。
IndexNow 的机制
IndexNow 是目前最常见的主動提交协议，由 Bing 等搜尋引擎推動，Google 未加入该协议。它的實現很轻：
- 在站点根目錄放一個文本文件，文件名是 key，文件内容也是這個 key；
- 提交时請求 https://api.indexnow.org/indexnow，參數带上 url 與 key；
- 也可以 POST 一段 JSON，一次提交一批 URL。
接口返回 200 或 202，表示請求已被接收。202 不是失敗，它通常意味着提交通過了初步校驗、進入後續處理。真正需要關心的是校驗失敗：key 文件取不到、key 不匹配、URL 與 key 的域名對不上，這些會返回 4xx。
提交前先確認几件事
- URL 目前返回 200。把 404、410 或者還在跳轉的地址提交上去，只會浪費一次机會。
- URL 是最终地址，不是中間跳轉的那一段。
- 内容确實已经上线。頁面還是空的、還是占位文案，提交了也没意义。
- 不要重复刷同一個 URL。协议本身對高频重复提交有节流，提交一次就够了。
Sitemap、内鏈、主動提交，三者分工不同
- Sitemap：全量线索池，适合周期性更新。它保證的是這些 URL 迟早會被看到，但不保證时效。
- 内鏈：决定抓取深度和頁面的相對重要程度，這部分無法被提交替代。一個没有内鏈的頁面，就算被主動提交抓了一次，後續也很难有稳定的重訪。
- 主動提交：适合时效性强的场景——刚發布的文章、刚改過标题或正文的頁面、刚刚生效的栏目調整。
三者不冲突。把 IndexNow 当成 Sitemap 的替代品，往往會發現提交過的頁面依然很久不被重訪。
几個容易踩的坑
一是把主動提交当成收錄開關，提交完就盯着收錄量看變化，几天没動静就認為這個协议没用。二是只提交新頁面，忽略已更新頁面——正文重寫、标题調整、價格變動，這些同样值得通知。三是提交後立刻修改 URL 结构，让搜尋引擎拿到一個已经失效的地址。四是保留測試环境的提交脚本，把内網地址或预览域名也發出去。
主動提交是加速被發現，不是保證被收錄。它的價值只有在站点本身能被正常抓取的前提下才成立。
怎么判断有没有真的起作用
比較實际的做法是對着服務器日誌看。记錄提交時間，然後在日誌里找對應時間窗口内搜尋引擎 UA 的訪問记錄，看第一次抓取距提交隔了多久。可以用小批量做對照：同一批更新内容，一半走提交、一半只靠内鏈和 Sitemap，观察首次抓取時間的差异。
注意 User-Agent 是可以伪造的，日誌里出現類似 UA 不等于就是官方蜘蛛。判断真實身份，反查 IP 归属比看字符串更可靠。
最後一点，無论走哪條通道，前提都是站点本身能稳定响應。服務器長期超时、返回 5xx，提交次數再多也只是把队列堆得更長。URL 發現的效率，最终還是被抓取能力限制着。