Sitemap 在 URL 发现里扮演什么角色
不少人把 Sitemap 当成“提交了就会被收录”的开关，实际它更像是一份候选清单。蜘蛛发现 URL 的渠道有好几条：外链、内链、历史抓取记录、Sitemap 以及其他声明文件。Sitemap 的价值在于，它能把那些内链层级很深、或者暂时没有外链指向的 URL 主动摆到蜘蛛面前，缩短发现环节的等待时间。但发现只是第一步，能不能抓、抓了之后怎么处理，取决于页面本身的可访问性和内容质量。
索引文件与分片：规模变大后怎么组织
单个 Sitemap 文件有明确上限：5 万个 URL、未压缩体积不超过 50MB。超过之后就需要拆分成多个文件，再用一个 Sitemap 索引文件把它们串起来。索引文件本身只列出各个子 Sitemap 的地址，不直接列页面 URL。
拆分时的几个实际注意点
- 按内容类型拆通常比按时间拆更好维护，例如文章、商品、专题各一个文件。
- 子文件之间不要互相嵌套，索引文件只引用最末一级的 Sitemap。
- 文件地址尽量保持稳定，频繁改名会让已经抓过的记录变成无效路径。
- 压缩成 .gz 是被支持的，但要保证解压后内容完整、编码正确。
lastmod 什么时候真正有用
lastmod 表示页面内容的最后修改时间。它有用的前提是准确。如果每次生成 Sitemap 都把全部 URL 的 lastmod 刷成当前时间，蜘蛛很快会发现这个字段不可信，进而忽略它，甚至降低对整份文件的信任度。
比较稳妥的做法是：只在内容确实发生实质变化时更新对应条目的 lastmod。比如正文补充、价格调整、库存变化这类会改变页面主要信息的改动。模板微调、广告位轮换、时间戳自动刷新这类不影响主体内容的改动，不建议动 lastmod。
把 lastmod 当成“我改了所以你要来看”的信号，前提是它真的代表改动。
Sitemap 和内链的分工
Sitemap 负责告诉蜘蛛“有这么个 URL”，内链负责告诉蜘蛛“这个 URL 有多重要、和别的页面是什么关系”。两者不能互相替代。一个只存在于 Sitemap、站内没有任何链接指向的页面，即使被抓取，也很难获得稳定的回访，因为它在站点结构里没有位置。
反过来，链接受限的深层页面如果只靠内链发现，可能要等很久。这时候用 Sitemap 补一刀，是合理的搭配。
写好之后怎么验证
- 确认 Sitemap 地址能在浏览器直接打开，返回 200 而不是 404 或跳转。
- 检查 robots.txt 里是否声明了 Sitemap 地址，注意路径完整、大小写正确。
- 抽查若干条目，确认其中的 URL 都是可访问的、返回 200 的规范化地址。
- 过一段时间看抓取日志，观察这些 URL 是否出现蜘蛛的访问记录，以及抓取后的状态码分布。
- 如果长期没有抓取痕迹，先排查文件本身是否可读、条目是否有效，再考虑其他因素。
几个容易被忽略的细节
- Sitemap 里不要放被 robots.txt 拦截的 URL，两者矛盾会让信号变混乱。
- 不要放重定向地址、404 页面、参数化筛选页这类不该被当作独立页面处理的 URL。
- 列表页如果要放进 Sitemap，最好只放第一页，后续分页交给内链处理。
- 文件更新频率不必太高，一天多次重写并不会明显加快发现速度。
Sitemap 做得好，能减少 URL 在发现环节的等待；但它解决不了内容层面和服务器层面的问题。把它当作一项稳定的基础配置，而不是抓取问题的万能钥匙，思路会更清楚。