很多站点在生成 XML Sitemap 之后，就把它当成一项已经完成的任务：提交到搜索资源平台，然后等待蜘蛛按图索骥。实际情况是，Sitemap 只是给蜘蛛提供了一份候选清单，它并不能保证每个 URL 都会被及时抓取，也不承诺收录。蜘蛛会结合站点内链、历史抓取记录、服务器响应状况等因素，决定什么时候来看、看多少。
Sitemap 能做什么，不能做什么
XML Sitemap 的主要价值是帮助蜘蛛发现那些内链较少、层级较深或新产生的 URL。它像一张补充地图，而不是抓取指令。对于已经在站内导航、列表页和正文链接中频繁出现的 URL，Sitemap 的边际作用通常有限；而对于孤立页面、分页较深的商品或文章，Sitemap 可以降低被漏掉的可能性。
需要注意，Sitemap 中的 URL 数量多，不代表抓取量会等比例增加。蜘蛛仍然会评估站点整体质量、更新频率和服务器承载能力。如果 Sitemap 里塞了大量低质、重复或参数化 URL，反而可能让蜘蛛对这份文件的信任度下降。
分片与索引文件：让 Sitemap 保持可读
单个 Sitemap 文件有大小和 URL 数量上限。当站点 URL 达到数万甚至更多时，通常需要拆分成多个分片文件，再用一个索引文件（sitemap index）把它们组织起来。这样做不只是为了符合协议限制，也能让蜘蛛分批读取，减少单次请求的压力。
分片时建议按内容类型或目录划分，例如文章、商品、专题、标签页各自成片。这样蜘蛛在读取某个分片时，能更清楚地知道这批 URL 属于哪类内容。索引文件里只放分片地址，不要再混入具体页面 URL，保持结构清晰。
lastmod 怎么写才不容易被忽略
lastmod 表示页面最后修改时间。如果写得不准确，比如每次生成 Sitemap 都统一刷新成当前时间，蜘蛛多次比对后可能会降低对这个字段的参考程度。比较稳妥的做法是：只在页面内容确实发生实质变化时更新 lastmod，格式使用标准的日期或日期时间。
对于聚合页、列表页这类内容频繁变动的页面，lastmod 可以随新内容加入而更新；对于长期不变的静态页，则没有必要反复改动。蜘蛛会把 lastmod 当作一个参考信号，但它不会仅凭这个字段就立刻重新抓取。
Sitemap 要配合内链和服务器稳定性
Sitemap 提供的 URL，最终仍要经过抓取排队、DNS 解析、服务器响应等环节。如果站点经常出现超时或 5xx，蜘蛛即使从 Sitemap 里拿到了 URL，也可能推迟或减少抓取。保持服务器稳定、响应时间可控，是让 Sitemap 发挥作用的底层条件。
同时，不要用 Sitemap 替代站内链接。蜘蛛在抓取一个页面时，会顺着页面上的链接继续发现新 URL。如果 Sitemap 里有大量页面在站内没有任何入口，这些页面即使被蜘蛛看到，也缺少上下文和权重传递，抓取优先级通常不会太高。把重要页面放进合理的栏目和列表页，再让 Sitemap 做补充，效果会更稳。
几个常见误区
- 把所有 URL 都塞进一个文件：超过协议限制后，蜘蛛可能只读取到一部分，分片和索引文件更利于维护。
- 频繁提交新 Sitemap 就期待立刻抓取：提交只是通知，抓取安排由蜘蛛根据整体情况决定。
- 忽略 robots.txt 中的 Sitemap 声明：在 robots.txt 里写明 Sitemap 地址，可以帮助蜘蛛更快找到这份文件。
- 让 Sitemap 包含重定向或 404 地址：这会浪费抓取机会，也容易让蜘蛛对文件质量产生负面判断。
把 Sitemap 看成一份持续维护的路线说明，而不是一次性的提交任务。分片清晰、lastmod 准确、与内链和稳定服务器配合，才更有可能让蜘蛛按图回访。
最后，定期检查 Sitemap 的抓取情况：在搜索资源平台或服务器日志中观察蜘蛛对 Sitemap 文件的访问频率、读取到的分片数量，以及从 Sitemap 进入的 URL 后续是否被正常抓取。根据这些反馈调整分片策略和更新节奏，比盲目增加 URL 数量更有意义。