站点地图（sitemap）几乎是每个站点的标配，但配好之后常年不看的情况也很常见。它本身不决定页面是否被收录，只是给搜索引擎提供一份地址清单，帮助发现那些靠站内链接不容易被找到的页面。问题往往出在清单本身：地址失效、类型混杂、重复堆叠。时间一长，这份文件就从“辅助发现”变成了“噪音来源”。
先明确 sitemap 能做什么、不能做什么
能做的：告诉抓取方“站内还有这些 URL”，尤其是新页面、深层页面、内链较少的页面。不能做的：承诺抓取，承诺收录，承诺排名。把 sitemap 当成收录开关，是很多误判的起点。它的价值在于“减少被发现的时间成本”，仅此而已。
哪些地址不该出现在清单里
- 会跳转的地址：返回 301 或 302 的旧 URL，应该直接写最终地址。
- 已经失效的页面：404、410、已下线的活动页、已删除的商品页。
- 被 robots.txt 屏蔽的目录：既然不让抓，就没必要提交，否则只会增加矛盾信号。
- 带 noindex 的页面：登录页、搜索结果页、隐私政策之外的运营页等。
- 参数页：筛选、排序、会话 ID、追踪参数生成的地址，容易成倍膨胀。
- 内部与测试地址：后台入口、草稿预览、预发布域名。
- 大量重复的分页中间页：按站点策略保留首屏或关键页，其余谨慎处理。
确实应该放进去的部分
栏目首页、主要的内容详情页、更新频率较高的页面、以及确有必要单独被发现的结构页。如果站点有图片或视频资源，并且希望它们被单独发现，可以另建对应的地图文件，而不是全部塞进一个 URL 列表里。
分卷与索引文件
单个 sitemap 文件通常有数量与体积上的限制（常见是 5 万条、未压缩不超过 50MB），超过就要分卷，再用一个索引文件把各卷汇总起来。分卷时建议按类型或目录划分，例如文章、商品、栏目各一卷。这样做的好处很实际：某一类地址出问题时，排查范围是清楚的，而不是对着一份几万条的文件猜。
生成方式与 lastmod
- 由程序从数据源生成，而不是手工维护，避免遗漏与过期。
- 定时任务定期重建，频率与内容更新节奏匹配即可，不必每分钟一次。
- lastmod 写真实的最后修改时间。如果每次重建都把全站时间刷新一遍，这个字段很快就会被忽略。
- 生成后做一次基本校验：随机抽几条地址，确认返回状态正常。
提交之后要看什么
在 robots.txt 里声明位置，再到搜索后台提交，只是前半步。后半步是定期看覆盖报告：提交了多少、其中有多少被识别、有多少停在“已发现未收录”。重点不是追求比例高，而是发现异常——比如某类地址长期不被抓取，往往说明结构或内链有问题，而不是 sitemap 没写全。
一份简单的自查清单
- 清单里是否还有跳转地址和 404 地址。
- 是否存在与 robots.txt 规则冲突的目录。
- 参数页、搜索结果页是否被大量写入。
- 是否超过单文件限制，是否需要分卷和索引。
- lastmod 是否反映真实修改，而不是生成时间。
- 新上线的栏目和页面是否被自动纳入。
- 是否在 robots.txt 中正确声明了位置。
- 最近一次查看覆盖报告是什么时候。
一句话原则：sitemap 是给抓取方看的地址清单，不是给自己看的页面总表。凡是“我们内部知道就行”的地址，都不该出现在里面。
把这份清单纳入日常的站点维护节奏，比如每月顺手检查一次，比出了问题再回头翻要省事得多。它不复杂，难的是持续保持干净。