不少站点把 Sitemap 当成一份“提交完就等蜘蛛来抓”的清单，但蜘蛛对它的使用方式更接近“参考线索”。写进去的 URL 和真正被抓的 URL，中间隔着好几道筛选：清单本身的格式、URL 的价值、站点的响应速度、内链是否给了入口。把这些搞明白，Sitemap 才不至于变成一份没人读的名单。
Sitemap 解决的是发现，不是抓取
Sitemap 的主要价值，是让蜘蛛知道“这个站点还有这些 URL 存在”，尤其是那些内链层级深、站内入口少的页面。但它不决定抓取时间，也不决定是否收录。抓不抓、什么时候抓，取决于蜘蛛自己的调度，以及站点在它访问时的响应表现。换句话说，它是一条兜底通道，而不是主力通道。心态摆正，后面很多判断会简单得多。
该放进去的 URL
- 返回 200 且可索引的页面，使用规范地址，不带多余的跟踪参数；
- 内链较深、曝光机会少的页面，比如详情页、历史文章、长尾列表；
- 新发布、希望尽快被发现的页面；
- 分类页、分页等有独立价值的列表页，前提是它们本身可索引。
判断标准其实只有一条：这个 URL 打开后是正经内容页，并且你希望它出现在搜索结果里。不符合这条的，先别急着往里加。
通常不该放进去的 URL
- 被 noindex 的页面：一边告诉蜘蛛别收录，一边让它来抓，信号是矛盾的；
- 301、302 跳转的旧地址：直接写跳转后的目标地址更省事；
- 已经 404 或 410 的失效页面；
- 筛选、排序、会话等参数组合出来的 URL，很容易把清单撑大；
- 后台、登录、购物车一类没有索引价值的路径。
清单臃肿最直接的后果，是蜘蛛把有限的时间花在低价值 URL 上，真正需要的页面反而排在后面。
分片与索引文件
单个 Sitemap 有容量上限，通常是 5 万个 URL 或 50MB 未压缩体积，两者先到为准。超过之后要拆成多个子文件，再用一个索引文件把它们列出来。
- 按类型拆：文章、商品、分类各自一份，便于分别观察；
- 按目录或语言拆，出问题时影响范围可控；
- 子文件地址必须是完整可访问的 URL，索引文件里不能写相对路径。
拆分不是麻烦，而是让排查更具体。某个子文件读取异常时，你至少知道问题出在哪一类页面上。
lastmod 要写实话
lastmod 是蜘蛛判断“这个页面值不值得重访”的参考之一。如果每次生成都刷成当前时间，而内容其实没变，这个字段很快会失去可信度。内容真正改动时再更新，是更稳妥的做法。为了看起来新鲜而频繁改动，通常得不偿失。
Sitemap 替代不了内链
Sitemap 能让 URL 被发现，但页面被抓到之后能不能继续往外走，靠的是页面里的链接。一个只在 Sitemap 里出现、站内没有任何入口的页面，抓取往往不稳定，重访也少。Sitemap 是补充，内链是主干，两者不该互相顶替。重要的页面，两条路都留着更稳。
怎么验证有没有起作用
- 在搜索后台查看 Sitemap 的读取状态，以及已被发现的 URL 数量；
- 对比提交数量和实际被抓的数量，差距大的那部分通常就是低价值页面；
- 在服务器日志里筛出 Sitemap 相关请求，看蜘蛛多久来读一次；
- 观察被发现的 URL 里，有多少是被内链先发现的，有多少是靠 Sitemap。
如果发现大部分 URL 都靠 Sitemap 才被发现，说明内链结构还有需要补的地方，而不是 Sitemap 写得不够多。
维护节奏
Sitemap 不需要频繁重建，但上新快、下架也快的站点，保持它和站点实际状态一致会更省事：删除的页面及时从清单里去掉，新增的及时加进来，别让失效地址长期堆着。频率稳定，比偶尔集中更新一次更实用。
Sitemap 是一份线索清单，不是抓取指令。写得准，比写得多有用。
把它当成 URL 发现链条中的一环，和内链、日志观察配合起来用，比单独指望它更接近实际情况。