不少站点把 sitemap 当成推进收录的开关：提交一份文件，等几天没动静，再提交一次，然后怀疑是不是格式写错了。实际上 sitemap 只做一件事——把站点希望被发现的 URL 集中告诉爬虫，省去它们靠外链和站内链接慢慢摸索的过程。它不决定页面能不能被抓取，更不决定页面能不能进索引。清单本身的质量，才决定它是帮忙还是添乱。
先分清 sitemap 管什么、不管什么
sitemap 影响的是 URL 发现环节。一个页面最终能不能出现在搜索结果里，还要依次经过抓取、渲染、内容判断和索引几个步骤。如果页面本身返回 404、被 robots.txt 拦住、带着 noindex 标签，或者内容与站内其他页面高度重复，那它出现在 sitemap 里只会让爬虫白跑一趟，浪费的就是站点本可以分配给有效页面的抓取次数。
适合放进清单的 URL
- 返回 200 状态码、允许被索引的页面，这是最基本的前提。
- canonical 指向自身的规范版本。如果某页的 canonical 指向了别处，放进来没有意义。
- 新发布、近期有实质更新的内容，配合真实的时间戳，能让爬虫知道这里有变化。
- 站内入口较浅、通过正常点击路径不容易被发现的页面，比如层级较深的产品详情页或老文章。
- 你希望优先被处理的少数重点 URL，数量不必多，但确实重要。
不建议放进去的 URL
- 被 noindex 标记的页面。清单里说“请抓”，页面上说“别编入索引”，两个信号互相打架。
- 会跳转的地址。301、302 的目标页更适合直接出现，跳转链接放在清单里属于多绕一步。
- 已经返回 404 或 410 的旧 URL。页面下线后，sitemap 也应该同步清理。
- 筛选、排序、追踪参数产生的变体。这类 URL 数量可以无限膨胀，把清单撑满却对应不到独立内容。
- canonical 指向其他页面的副本页，它们本来就不该作为独立条目存在。
- 站内搜索结果页、用户中心、购物车、打印页等功能型页面。
lastmod 别随便刷新
有些站点每次生成 sitemap 就把所有 URL 的 lastmod 更新成当天时间，以为这样能催一催。结果是这个字段很快失去可信度——爬虫发现每次来时间戳都变，但页面内容一模一样，之后就只按普通节奏处理，不再优先看它。真实的时间戳只需要在内容确实改动时更新，比如正文增删、价格调整、信息纠正。模板层面的样式变化，通常不必算作内容更新。
文件本身的几个细节
- 单个 sitemap 文件最多 5 万条 URL，未压缩体积不超过 50MB，超了就拆分成多个并用索引文件串联。
- 里面的地址写成完整绝对路径，带协议和域名，不要用相对路径。
- URL 中的特殊字符要正确编码，避免因编码不一致导致同一页面出现两个版本。
- 文件可以被 gzip 压缩，这对大站点能明显减少传输开销。
- 在 robots.txt 里声明 sitemap 位置，或者通过搜索资源平台后台提交，两者并不冲突。
提交之后会发生什么
提交成功只代表文件被读取，不代表清单里的 URL 会被立刻抓取，更不代表会进入索引。合理的观察窗口是一到两周，期间可以看资源平台里的抓取统计，确认爬虫是否真的访问了这些地址。如果几天内毫无抓取记录，问题多半出在 URL 本身或者文件获取上，而不是提交次数不够。反复重提交同一份清单，除了增加后台记录，一般不会改变什么。
一份可执行的自查顺序
- 从清单里随机抽几条 URL，用工具确认返回 200、没有 noindex、canonical 自指。
- 检查 robots.txt 是否误挡了这些路径，尤其注意新加的规则。
- 确认 sitemap 文件能被正常访问，返回 200 且内容类型正确，没有因权限或缓存问题变成空文件。
- 查看服务器日志，看爬虫最近是否来过、频率如何、抓取的是不是清单里的地址。
- 对确实重要但没有抓取记录的页面，回头检查站内入口是否太深，能不能从首页几步内点到。
sitemap 的价值在于让爬虫少走弯路，而不是让页面自动进入索引。把它当成一张地图，而不是一个按钮。
最后提醒一句：清单需要维护。页面下线、改版、合并之后，sitemap 应该跟着变，而不是一直保留历史版本。一个干净、与站点当前状态相符的清单，比一份内容庞大却一半失效的文件有用得多。