入口页铺出去之后，很多人会卡在同一个问题上：蜘蛛到底什么时候来。等它自己发现，还是想办法主动告诉它。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 只是缩短被发现的时间，抓不抓、抓多少，最终还是搜索引擎根据入口页本身的情况和站点整体表现来决定的。把它当成一个通知手段，比当成一个开关更合适。