入口頁铺出去之後，很多人會卡在同一個問题上：蜘蛛到底什么时候来。等它自己發現，還是想办法主動告诉它。sitemap 和主動提交就是干這件事的，但它們各自解决的是不同环节，混在一起用反而容易白忙一场。
sitemap 解决的是“有哪些 URL”，不是“该不该抓”
先把定位说清楚。sitemap 的本质是一份清單，作用是把站点里存在哪些 URL 摆到明面上，减少蜘蛛靠連結一层层爬才能發現的情况。它不负责告诉搜尋引擎這個頁面值不值得抓，更不负责保證收錄。
實际使用时有几個硬性约束值得记住：單個 sitemap 文件里的 URL 數量一般有上限（常见是 5 萬條），文件大小也有上限，超了就要拆。文件需要放在域名根目錄或者 robots.txt 里能指到的位置。里面的 URL 必须和實际能訪問的地址完全一致，带 www 和不带 www 混着寫，等于凭空多出一批無效地址，白白消耗抓取预算。
還有一個细节容易被忽略：lastmod 要真實。不少批量生成脚本為了“看起来一直在更新”，每次跑都把所有 URL 的時間戳刷成目前時間。短期看不出問题，時間一長，這個字段就失去參考價值了。
多域名场景下，sitemap 怎么组织
蜘蛛池往往不止一個域名，這时候组织方式比單個站点复杂一些。
每個域名單獨一份
最稳妥的做法是每個域名下都有自己的 sitemap.xml，並在该域名的 robots.txt 里寫上對應的 Sitemap 行。這样做的好處是归属清晰：某個域名出問题、被停掉或者解析失效时，只要把這份 sitemap 撤掉就行，不會牵连其他域名。
域名數量多的时候，手工维護不現實，一般用脚本按域名模板生成。生成逻辑要和入口頁的生命周期绑定：入口頁下线了，sitemap 里對應的條目也要跟着去掉，別让文件變成歷史垃圾堆。
sitemap index 适合大站，不适合拿来跨域名匯總
sitemap index 是一個索引文件，指向多份子 sitemap，主要用于單個站点 URL 數量特別大的情况。有些运营者會想用一個 index 把几十個域名的 sitemap 全部串起来，提交一次了事。這種做法並不推荐：跨域名的 URL 混在一個索引里，归属關系模糊，某個域名出問题时也不好單獨收回。
如果确實想集中管理，可以在後台做一份匯總台帳，但對外提交仍然按域名分開，這是更清楚的方式。
主動提交的几條路
- 搜尋资源平台的提交接口：按天或按配額計算，超出就不再接收。因為有配額，就不适合無差別地全量推送，應该優先挑那批刚上线、確認可訪問、内容结构完整的入口頁。
- IndexNow 這類共用协议：一次提交，多家搜尋引擎可以共享。前提是域名下要放置驗證用的 key 文件並能正常訪問，驗證過不了，提交就是無效動作。
- RSS 或 Atom：适合持續有小幅更新的站点，把新入口頁放進 feed，让订阅式的抓取路径带上它們。老站点没有更新习惯的话，這條路的收益有限。
- 内鏈與首頁入口：说到底，最稳定的發現路径還是連結。首頁或栏目頁给出明确入口，比任何提交接口都持久。
几個容易白費功夫的坑
- sitemap 里塞進 404、301 跳轉頁或者带 noindex 的地址。蜘蛛拿到清單後逐一驗證，遇到一批無效地址，對你整個文件的信任度都會下降。
- 提交频率過高，把配額花在已经被抓過、甚至已经收錄的頁面上。真正需要加速的是新頁面，不是老頁面。
- 只提交不维護内鏈。蜘蛛来了一次，顺着連結發現不了別的入口頁，抓完就走，提交的意义被削掉一半。
- 把提交当成開關，觉得点了就一定會被抓、被抓就一定會被收錄。這两個环节都不由提交動作决定。
- 多個域名共用一份 sitemap 文件，URL 交叉出現，導致蜘蛛在不同域名之間反复跳轉，浪費抓取次數。
节奏上的一些建议
新入口頁上线时，先自己確認几件事：返回 200、没有 noindex、頁面對蜘蛛可訪問、連結能被正常解析。這几項不達标的时候提交，等于把問题主動送到蜘蛛面前，反而不如先修好。
提交本身建议少量多次，按天或按周分批走，跟着入口頁的上线节奏来。同时保留观察习惯：服務器日誌里哪些入口頁被訪問過、返回什么狀態、停留多久，這些信息比提交成功的提示有用得多。某批入口頁長期没有任何抓取痕迹时，回头查 robots 設定、响應速度、DNS 解析，比繼續加大提交量更有效。
提交和 sitemap 只是缩短被發現的時間，抓不抓、抓多少，最终還是搜尋引擎根據入口頁本身的情况和站点整体表現来决定的。把它当成一個通知手段，比当成一個開關更合适。