网站收录

重定向跳了几跳之后:收录核对先看蜘蛛最终落在哪个地址

改版、换域名或调整栏目结构后,站内往往留下一串跳转。从用户角度看地址栏最终变成新地址就没事了,但蜘蛛要沿着每一跳走一遍。核对收录时,先确认蜘蛛最终落在哪个地址、那一跳返回什么状态码,再判断问题出在抓取路径还是页面本身。

网站收录

重定向跳了几跳之后:收录核对先看蜘蛛最终落在哪个地址

改版、换域名、调整栏目结构之后,站内常常会留下一串跳转。从用户角度看,浏览器地址栏最终会变成新地址,体验没什么问题;但从收录角度看,蜘蛛要沿着每一跳走一遍,最终的地址才有机会进入索引。核对收录时如果只盯着旧地址,很容易得出错误结论。

先分清:跳转是被抓取的过程,不是被收录的结果

一个 301 或 302 本身也是蜘蛛要抓取的 URL。它抓到这个响应,知道该去下一个地址,再发起一次请求。整条链走完,只有最终的 200 页面才可能被索引。所以出现“旧地址还在索引里”或“新地址没动静”时,先确认蜘蛛到底停在哪一跳,比反复提交新 URL 更有用。

四类常见的跳转问题

多跳链:A → B → C

最常见的是改版分几次做,每一层都加了一条规则,最后形成三跳甚至更长。多跳不一定被判为错误,但会消耗额外的抓取配额,也让状态判断变得模糊。核对时把链条完整列出来,能合并的就直接指向最终地址。

跳到不相关的地址

栏目页关停后统一跳到首页,这是省事的做法,但首页和原页面主题不一致,蜘蛛和用户都拿不到对应内容。这类地址既不会被当作有效的替代版本,也容易长期停留在索引里。更稳妥的是跳到最接近的上层栏目或同类页面;确实没有对应内容,就让它返回正常的 404。

软跳转:JS 或 meta refresh

有些跳转不是通过 HTTP 状态码完成,而是靠页面内的脚本或 meta refresh 实现。这种页面返回的仍然是 200,蜘蛛会把它当成一个正常页面处理,索引里也可能保留它。核对时看到状态码是 200 而不是 3xx,就要留意是不是软跳转在起作用。

循环与断链

规则写错时会出现 A → B → A,或者跳转目标本身已经 404。前者让蜘蛛反复绕圈,后者等于把旧地址的价值送进死胡同。这两类问题在日志里通常表现为同一批地址被反复请求。

一套可执行的核对顺序

  1. 抽取一批样本 URL,用带跟随跳转的请求工具看完整链路和最终状态码。
  2. 记录每一跳的响应码、目标地址、跳转类型是永久还是临时。
  3. 确认最终地址返回 200,并且没有被 robots.txt 屏蔽、没有加 noindex。
  4. 确认最终地址自身规范,canonical 指向自己,而不是指向链条中的中间地址。
  5. 隔一段时间再抽查同一批样本,看链路是否稳定。

第三步经常被忽略:跳转规则改对了,最终地址却带着 noindex 或者被 robots.txt 挡住,结果依然是进不了索引。

收敛时可以做的几件事

  • 把多跳链压成一跳,直接指向最终地址。
  • 更新站内链接、导航和 sitemap,让蜘蛛不必先经过旧地址。
  • 临时跳转确认稳定后改成永久跳转,减少反复判断。
  • 定期扫一遍全站跳转规则,清掉指向 404 的死链和循环。
跳转正常只是必要条件,不代表最终页面一定被收录。页面质量、内容重复程度、站点整体情况都会影响结果,核对时把这几层分开看。

把“跳转链走通”和“最终页面被收录”当成两件事,核对的时候就不会把功夫花错地方。