Sitemap（站点地图）是站点向搜索引擎主动提交 URL 清单的一种方式。它不能让页面一定被收录，也不能替代内链和内容质量，但它能减少「蜘蛛根本不知道这个地址存在」的情况。问题在于，很多站点的 sitemap 是上线时生成过一次，之后基本没人再打开看过：里面躺着已经删除的页面、被 robots 挡住的目录、几万条带参数的筛选结果。这样的文件不但帮不上忙，还可能占用抓取时间。下面按自查的思路，把 sitemap 容易出问题的地方过一遍。
一、先确认蜘蛛有没有真的读它
在动手改内容之前，先确认这份文件是被访问过的。可以打开服务器日志或 CDN 日志，搜索 sitemap 的路径，看最近的抓取记录里有没有搜索引擎的访问，返回状态是不是 200。如果长期没有任何访问记录，先别急着优化条目，而要检查两件事：一是 robots.txt 里有没有把它挡住，二是文件本身是不是返回了 404、403 或者超时。
顺带看一眼返回的 Content-Type，确保是 XML 而不是 text/html。有些服务器配置会把 .xml 当成普通文本返回，虽然多数情况下仍能解析，但出现异常时排查会更麻烦。
二、逐条核对清单里的 URL 是否还成立
把 sitemap 里的 URL 抽一批出来，按下面几类问题过一遍：
- 已删除或改版的页面：栏目下线、活动结束、商品下架后，对应的 URL 如果还留在 sitemap 里，蜘蛛每次来都会撞上 404，次数多了会降低对这个文件的信任。
- 被 robots 屏蔽的地址：sitemap 里出现 Disallow 的目录，属于自相矛盾。要么放开抓取，要么把它从清单里去掉。
- 需要登录或跳转的页面：一访问就 302 到登录页的地址，放进去没有意义。
- 重复 URL：带与不带 www、带与不带结尾斜杠、http 与 https 混在一起的版本同时存在，需要统一成最终形态。
- 参数页：筛选、排序、分页组合出来的地址，数量容易失控，建议只保留少量有实际检索价值的入口。
- 不该出现的页面：站内搜索结果页、购物车、测试页、后台入口，都不适合出现在公开清单里。
三、lastmod 别乱写
lastmod 是用来告诉蜘蛛「这个页面最近确实有变化」的字段。如果每次生成 sitemap 都把全站 lastmod 刷成当天，等于对所有页面喊了一遍「都更新了」。蜘蛛跑几次发现内容没变，就会开始忽略这个字段，等到某天你真的更新了重点页面，反而传不出信号。
更稳妥的做法是让它跟着内容系统的真实修改时间走：正文有实质改动才更新，只改排版、只换配图、只调整推荐位，都不必动它。
四、按内容类型拆开维护
当站点规模到几万条以上时，把所有 URL 塞进一个文件既不便于排查，也不方便区分优先级。常见的拆法是：
- 文章或资讯类一个文件，更新频繁，可以单独提交。
- 栏目页、聚合页一个文件，数量少但重要。
- 商品或下载详情页一个文件，按分类或时间分批。
- 再用一个索引文件（sitemap index）把它们串起来。
这样某个模块出问题时，影响范围可控，也方便在 Search Console 里单独看每份文件的提交和抓取情况。
五、提交之后仍要定期回看
sitemap 不是一次性的交付物，而是一份需要跟着站点一起更新的清单。站点改版、栏目合并、URL 规则调整之后，它往往是第一个被遗忘的文件。
建议把它纳入固定的检查节奏：每次改版或大规模下线内容后重新生成一次，每月抽一批 URL 用抓取工具或浏览器实际打开看看状态码，把它和站内链接、robots.txt、canonical 三者的说法对齐。清单里的地址应该都是能正常访问、允许抓取、且指向最终版本的页面——做到这一点，它才算真正在帮忙。