搜索抓取

Sitemap 提交后蜘蛛没来:按这份清单逐项排查

Sitemap 是蜘蛛发现 URL 的常用入口,但提交不等于抓取。本文从文件可访问性、URL 质量、lastmod 更新信号、日志核对、内链配合和服务器响应几个环节,给出一份可逐项执行的排查清单,帮助定位问题所在,而不是反复重新提交。

搜索抓取

Sitemap 提交后蜘蛛没来:按这份清单逐项排查

Sitemap 常被当成把 URL 交给蜘蛛的快捷方式,但提交之后没有抓取,原因往往不在提交这个动作本身。蜘蛛是否来、什么时候来,取决于文件能不能读、里面的 URL 值不值得抓,以及站内路径和服务器状态是否配合。下面是一份可以逐项核对的清单。

先确认 Sitemap 文件能被正常读取

第一步不是看蜘蛛,而是看 Sitemap 本身。用一个未登录的浏览器或无缓存环境访问 Sitemap 地址,确认返回 200,而不是 301 链太长、403 或 5xx。Content-Type 通常是 application/xml 或 text/xml,如果被服务器返回成 text/html,蜘蛛可能会把它当成普通页面处理。

XML 格式错误也会导致整份文件被跳过。检查标签是否闭合、URL 是否做了转义、是否包含非法字符。如果 Sitemap 很大,还要确认分片文件都能单独访问,并且索引文件里的地址指向正确。

看 Sitemap 里的 URL 是否值得进入抓取队列

蜘蛛读完 Sitemap 后,并不会立刻抓取全部 URL。它会结合页面状态、重复度和站内重要性做筛选。以下几种情况容易让 URL 停在队列外:

  • URL 返回 404、410 或软 404,蜘蛛抓一次后就会降低信任。
  • 页面被 robots.txt 屏蔽,Sitemap 里却仍然保留。
  • 页面 canonical 指向别的 URL,或本身是重复内容。
  • URL 带大量参数,且参数组合没有收敛,蜘蛛会认为可抓版本太多。
  • 页面需要登录或必须提交表单才能看到内容。

把这些 URL 留在 Sitemap 里,不会增加抓取,反而会让蜘蛛对整份清单的准确性打折扣。定期清理无效地址,比堆更多 URL 更有用。

lastmod 要真实,不要每篇都改

很多站点会在每次生成 Sitemap 时把全部 URL 的 lastmod 更新为当前时间。短期看像是“告诉蜘蛛我更新了”,长期看会让 lastmod 失去参考价值。蜘蛛更关注的是内容是否真的发生了变化。如果只是模板或边栏改动,没有必要改 lastmod。

相对稳妥的做法是:只有正文、标题、关键信息确实更新时才调整对应 URL 的 lastmod;批量更新时也尽量分批,不要一天内全站同时变动。

从访问日志核对蜘蛛是否真的读取过 Sitemap

不要凭感觉判断。到服务器访问日志里搜索 Sitemap 文件的请求记录,看蜘蛛有没有来、返回状态是多少、频率如何。如果 Sitemap 被频繁读取,但里面的 URL 没有后续抓取,问题更可能在 URL 筛选或站内路径上。

日志里能看到“来过”,但看不到“为什么没继续抓”。所以要把 Sitemap 读取记录和具体 URL 的抓取记录分开看。

内链与抓取入口是否配合

Sitemap 提供的是 URL 清单,不是抓取路径。蜘蛛仍然会从首页、栏目页、列表页、相关推荐等位置发现链接。如果一个 URL 只出现在 Sitemap 里,站内没有任何入口指向它,蜘蛛对它的重要性判断会偏低。重要页面至少要有稳定的内链入口,并且链接是普通的 a href,而不是依赖点击事件或 JavaScript 后才生成。

服务器响应与抓取节奏

如果服务器响应时间经常超过几秒,或者间歇性返回 5xx,蜘蛛会主动降低抓取频率。这种情况下,Sitemap 写得再完整,抓取速度也会被压制。先解决稳定性和响应速度,再谈 Sitemap 的覆盖量。

一个可执行的排查顺序

  1. 直接访问 Sitemap,确认状态码、类型和 XML 格式。
  2. 抽查若干 URL,确认返回 200、可索引、不是重复页面。
  3. 检查 lastmod 是否真实,避免全站同时变动。
  4. 在日志中确认蜘蛛读取 Sitemap 的记录和状态。
  5. 检查这些 URL 是否有站内入口,链接是否可被直接抓取。
  6. 观察服务器响应时间和错误率,排除稳定性问题。
  7. 保持一段时间不要反复改 Sitemap,给蜘蛛一个稳定的观察窗口。

Sitemap 更像是给蜘蛛的一份线索清单,不是收录保证。把文件本身、URL 质量、更新信号、日志核对和内链路径都检查一遍,比反复重新提交更容易找到真正卡住的位置。