Sitemap 经常被当成一次性任务：上线时生成一个文件，提交到搜索资源平台，然后就不管了。实际运营中，栏目会调整，内容会下架，URL 规则会变化，新页面每天都在产生。如果 Sitemap 长期不变，蜘蛛仍然会通过外链、内链和站内路径发现一部分内容，但发现效率可能变低，尤其是那些入口较浅、内链较少的页面。
需要先明确一点：Sitemap 是给搜索引擎的参考路线，不是收录保证。它可以帮助蜘蛛了解站点有哪些 URL、大致什么时候更新，但最终是否抓取、是否索引，仍取决于页面质量、站点整体情况和搜索引擎的判断。所以维护 Sitemap 的目标不是“提交后坐等收录”，而是减少蜘蛛发现和判断的障碍。
Sitemap 维护中常见的问题
- 只提交首页或几个栏目页：大量详情页没有被列入，蜘蛛只能顺着链接一层层爬。
- 长期不更新：新增文章、新上架页面没有及时进入 Sitemap，lastmod 也停留在很久以前。
- 把不可索引的 URL 也放进去：比如带参数的筛选页、已删除页面、需要登录的页面、robots.txt 中禁止抓取的目录。这会增加蜘蛛的无效访问。
- 全站塞进一个文件：单个 Sitemap 文件有 URL 数量和大小限制，太大时应该拆分。
- 提交后不验证：文件返回 404、格式错误、域名写错，自己却不知道。
一份可执行的 Sitemap 自查清单
1. 确认文件能正常访问
在浏览器和命令行中分别访问 Sitemap 地址，确认返回 200 状态码，内容类型正确。常见位置是根目录下的 /sitemap.xml，也可以是 /sitemap_index.xml。如果使用了 CDN 或缓存，注意缓存是否导致旧文件一直被返回。
2. 只放希望被索引的 URL
Sitemap 不是站点所有 URL 的备份。应该只包含 canonical 版本、返回 200 状态码、且允许被索引的页面。已经设置 noindex 的页面、重定向地址、404 页面、带会话 ID 或排序参数的 URL，都不适合放进去。否则蜘蛛可能把抓取预算花在低价值地址上。
3. 按内容类型拆分 Sitemap
当站点规模变大时，可以把文章、产品、栏目、标签等分别生成 Sitemap，再用一个索引文件汇总。这样便于在搜索资源平台中单独观察抓取和索引情况，也方便排查某一类 URL 的问题。
4. lastmod 要诚实
lastmod 表示页面最后实质更新的时间，不是每次发布或同步的时间。如果只是改了发布时间、换了模板样式，内容主体没有变化，不建议批量刷新 lastmod。频繁造假会让搜索引擎逐渐不信任这个字段。
5. 在 robots.txt 中声明
可以在 robots.txt 里加上 Sitemap 地址，方便蜘蛛找到。注意 robots.txt 中的 Sitemap 指令只是声明位置，不会替代搜索资源平台中的提交。如果站点有多个子域或独立移动端，应该分别声明对应的 Sitemap。
6. 用服务器日志验证
提交后不要只看“已提交”状态。过一段时间检查服务器日志，看看蜘蛛是否真的抓取了 Sitemap 文件，以及是否顺着其中的 URL 进行了访问。如果 Sitemap 被抓取但页面访问很少，可能需要检查页面质量、内链结构或抓取频率设置。
维护节奏怎么定
不需要每天手动改 Sitemap，但可以让它跟随内容系统自动更新。对于更新频繁的站点，建议每次发布内容时自动追加或重新生成；对于更新较少的站点，至少每周或每两周检查一次。每次大改版、栏目调整、URL 规则变化后，都应该重新生成并提交。
可以建立一个简单的检查习惯：打开 Sitemap 地址是否能访问；随机点几个 URL 是否正常；在搜索资源平台看已提交和已索引的数量是否明显异常；对照日志看蜘蛛是否在抓取新页面。
把 Sitemap 当成站点运营的常规配置，而不是上线时才想起来的一次性动作。它不能保证收录，但可以减少新页面被发现的随机性。
最后提醒：Sitemap 只是 URL 发现体系中的一环。内链、导航、栏目页、站内搜索、外部链接同样重要。如果站点结构本身混乱，Sitemap 写得再全，蜘蛛也未必愿意深入抓取。先把可索引的 URL 整理清楚，再谈提交和更新，效果会更实际。