站点运营

站点运营:站点地图自查,别让 sitemap 塞满失效与不该出现的地址

站点地图是对外的一份地址承诺,长期不维护反而会浪费蜘蛛的到访时间。本文梳理 sitemap 常见的三类问题——混入重定向或 noindex 地址、lastmod 失真、分片与索引文件无人管,并给出一套可以照着做的定期自查流程,帮助站点运营者让清单和站内真实状态保持一致。

站点运营

站点运营:站点地图自查,别让 sitemap 塞满失效与不该出现的地址

站点地图(sitemap)看起来只是一份 XML 文件,实际是对外发出的一份地址承诺:清单里的每个地址,都应该是你希望被索引、并且确实能正常打开的页面。文件生成一次就放着不管,蜘蛛按图索骥却频频撞上跳转和错误页,这份承诺就变成了负担。

sitemap 的定位:可索引地址清单

很多人把 sitemap 当成“全站地址备份”,于是把所有能想到的 URL 都塞进去。更合理的定位是:只放那些你希望被收录、且当前返回正常状态的规范地址。不在这份清单里的页面依然可以被抓取和索引,sitemap 只是提高发现效率,不是收录开关。

三类最常见的问题

一、混进了不该出现的地址

  • 已经被 301 跳转的旧地址,清单里还留着老路径;
  • 设置了 noindex 的页面,sitemap 和 meta 指令互相矛盾;
  • 筛选参数页、排序参数页、会话追踪参数页被批量写入;
  • 已经下线返回 404 或 410 的内容,仍停留在清单中;
  • 登录页、后台页、测试环境域名等不该公开抓取的地址;
  • 分页列表的第二页之后,是否收录需要单独判断,不宜默认全放。

这些地址看不出问题,直到你拿日志去看蜘蛛实际访问了什么,才发现大量请求落在无效路径上。

二、lastmod 失去参考价值

有些站点每次生成 sitemap 时,把全部地址的 lastmod 刷成同一个时间戳;有些则长期不更新,页面改了好几轮,时间还停在最初。两种情况都会让这个字段失去意义。更稳妥的做法是:只有当页面正文或主要内容确实发生实质变化时,才更新该地址的 lastmod,模板调整、广告位替换这类改动不必触发。

三、分片与索引文件无人维护

当站点规模变大,通常会按栏目或时间拆成多个子 sitemap,再用一个索引文件(sitemap index)把它们串起来。单个 sitemap 文件不宜超过 5 万条地址、未压缩大小不宜超过 50MB。常见故障是:新增了子文件却忘了加进索引,或者某个子文件报错、返回 404,导致整批地址静默失效。

一套可以照着做的维护流程

  1. 导出并抽样校验。把 sitemap 中的地址拉成列表,脚本批量请求,记录状态码、跳转链和目标地址、页面上的 canonical 与 robots 指令。
  2. 过滤出四类异常。状态码非 200 的、跳转到其他地址的、canonical 指向别处的、带 noindex 的——这些都应该从清单里移除或替换。
  3. 剔除参数与低价值地址。把带追踪参数、排序参数、重复内容特征的地址清理掉。
  4. 校正 lastmod。用内容系统的实际更新时间生成,而不是用生成脚本的运行时间。
  5. 检查索引文件。确认每个子文件都能访问、都已登记、条数在限制之内。
  6. 在 robots.txt 中声明位置。确认声明的路径可访问、没有被人为拦截。
  7. 重新提交并观察日志。提交后过一段时间再看服务器日志,确认蜘蛛访问的地址分布是否更集中在你希望的位置。

这套流程不需要天天跑。规模不大的站点,每月一次即可;内容更新频繁的站点,可以每周抽一次,重点看新增和下线两部分。

和其它信号保持一致

sitemap 不是孤立文件。它应该和 robots.txt 的抓取规则、页面上的 canonical 标签、内链结构指向的方向保持一致。如果内链都指向 A 地址,canonical 也写 A,sitemap 里却登记的是 B,蜘蛛收到的就是三份互相矛盾的信号。

清单整洁不等于一定被收录,收录与否取决于搜索引擎自己的判断。你能做的是把门口的路修平,别让蜘蛛在无效地址上反复折返。

把 sitemap 当成一项需要定期检查的运营事项,而不是一次性的技术配置,它才能真正发挥“指路”的作用。