搜索抓取

Sitemap 的写法与维护:分片、lastmod 与提交后的核对

站点地图不是抓取主力,它的作用是提前告知 URL 存在。本文从文件格式的硬性上限、lastmod 的填写原则、与内链和 robots 的分工,到提交后如何用日志和报告核对,梳理一份能长期维护的 Sitemap 写法。

搜索抓取

Sitemap 的写法与维护:分片、lastmod 与提交后的核对

站点地图(Sitemap)不是让蜘蛛抓取的主力,内链才是。它的价值在于把内链不太好覆盖的、或者刚刚生成的 URL 提前告知搜索引擎,减少“地址被发现但迟迟不进队列”的情况。但 Sitemap 本身有格式和数量上的硬约束,写得不规范反而会拖慢处理。下面按文件格式、lastmod、与其他通道的分工、上线后的核对四块来说。

一、文件本身的硬约束

单个 Sitemap 文件最多 50,000 条 URL,未压缩状态下不超过 50MB。超过这个规模就要拆成多个子文件,再用 sitemap index 汇总成一个索引文件。

  • 索引文件可以指向多个子文件,子文件里的 URL 需要与所在域名一致,跨域需要先在对应工具里验证权限
  • 只放返回 200 且允许被索引的地址,301、404 以及被 robots.txt 拦截的地址不要放
  • 用 gzip 压缩是可以接受的,但压缩并不能突破 50,000 条的上限
  • XML 声明、命名空间、编码要规范,格式错误会导致整个文件解析失败

二、lastmod 要如实填写

lastmod 是给蜘蛛判断“是否值得重访”的参考字段。常见的两种做法都会让它失去信息量:一是全站统一一个时间戳,二是每次生成文件时全部刷新一遍。

更稳妥的做法是,只在正文、主要结构化数据、价格或库存这类实质内容发生变化时,更新对应 URL 的 lastmod。模板调整、样式修改、导航改动不必更新。如果站点是全量生成页面,至少要保证 lastmod 与页面上可见的更新时间一致,否则两边对不上,反而降低这个字段的可信度。

三、和其他通道的分工

Sitemap 解决的是“告诉你有这个 URL”,并不解决“蜘蛛愿意爬”。真正决定蜘蛛能不能走到页面上的,还是可以稳定点击的内链路径。

  • 重要页面仍要有内链入口,Sitemap 只是补充,不要拿它替代导航和正文链接
  • 被 canonical 收敛掉的重复地址,Sitemap 里应当放 canonical 指向的那一个
  • 分页和筛选参数页一般不必全量放进去,只挑有独立价值的放
  • robots.txt 里被 Disallow 的目录不要出现在 Sitemap,两边冲突时以抓取规则为准

四、提交之后的核对

提交文件位置只是把地址告知搜索引擎,处理需要时间,也不保证每一条 URL 都会被抓取或收录。核对时主要看两个地方:服务端日志里这些 URL 有没有出现蜘蛛请求,以及站长工具里 Sitemap 的读取状态和已发现 URL 数。

  1. 先确认文件能被正常访问,返回 200,Content-Type 正确
  2. 看报告里的“已发现 URL 数”与实际条数是否接近,差得太多通常是解析失败或部分条目被忽略
  3. 抽样几个 URL,看日志里有没有对应的抓取请求,没有就回到入口页和内链去检查
  4. 长期没被抓取的 URL,先判断它是否属于低价值页面,再决定是补内链还是从文件里移除

五、几个常见错误

  • URL 写成相对路径,或者带上了会话参数
  • 大量 404、302 地址长期留在文件里不清理
  • 索引文件里再嵌套索引文件
  • 一次提交几十万条几乎相同的页面,稀释了处理优先级
把 Sitemap 当作通知渠道,而不是入场券。

定期维护比一次性全量提交更重要。建议每月核对一次文件里的状态码分布,把已经失效或已经合并的地址清掉,保持文件短小准确。数量不多但都是有效 URL,处理效率通常好过塞进一大批低质量地址。