你搜到一个网站的内页,标题和描述都对得上,点进去却直接蹦到网站首页,这种事挺让人烦躁的。不光是用户烦,站长其实也烦,因为这意味着之前辛苦做的内页收录权重全白费了。
我从几个实际场景来分析一下原因。
最常见的是301跳转设置范围过大。有些站长换域名或者改版的时候,图省事在服务器层面写了一条规则,把所有URL请求全部301到首页。这种做法如果放在伪静态规则里,比如Nginx或者Apache的rewrite规则,写成了所有路径匹配都跳转到根域名,那就相当于把整个网站的内页全部判了死刑。搜索引擎蜘蛛来抓取内页的时候,收到的响应码是301,它会认为这个页面已经永久搬家了,于是慢慢把内页从索引里撤掉,只保留首页。
第二个原因是canonical标签标错了。这个是隐蔽性问题,页面本身能正常打开,但源代码里有一段link rel等于canonical的代码,指向的是首页地址。搜索引擎看到这个标签会理解为当前页面只是首页的副本,真正的权威版本应该是首页。不光是搜索引擎,有些浏览器插件遇到这个标签也会帮你直接跳转。这种情况经常出现在用CMS建站的时候,模板调错变量,把全站canonical都写成了固定首页地址。
再说说JS脚本强制跳转。你打开内页的时候页面确实加载了,但页面上有一段JavaScript检测当前URL是不是首页,如果不是就执行window.location替换。这种跳转搜索引擎抓取的时候可能不会执行脚本,所以收录照样存在,但真实用户打开就会被强扭过去。常见于某些广告联盟的代码植入,或者网站被恶意挂了跳转代码,也可能是不良开发者做的劫持操作。

还有一个容易被忽视的原因是程序配置问题。比如WordPress后台设置的站点地址是带www的,但内页链接是不带www的,服务器又没有做301归一化,这个时候访问不带www的内页可能被主机商默认配置重定向到首页。另外一些伪静态页面的规则冲突也会导致内页匹配到错误的重写规则,最后落入首页路由。
手机端和PC端分离的站点更容易遇到这种事。你搜到的内页是PC版,但移动端访问时被识别为非移动设备,某些响应式方案没写好,在判断设备类型的时候所有非手机请求都先做了一个302到首页再弹回PC首页。这类问题在用了第三方移动适配服务之后特别常见。
比较棘手的情况是服务器层面设置了强制HTTPS,但证书只覆盖根域名。用户访问内页HTTP版本时,服务器尝试做HTTPS转发,配置里把路径丢了,结果就跳到首页。这种要检查SSL配置里的rewrite规则是否保留了URI参数。
最后说一个现象,很多网站删除旧内容后舍不得返回404,管理员为了用户体验友好,把所有不存在的路径统一转发到首页。搜索引擎发现这种软404行为后,会逐渐把那些历史页面删出索引。这其实是最普遍的情况,内页内容被下架了,但收录没有及时清理,用户在搜索结果里点到的实际上是残留快照。
如果你遇到这个问题,先用浏览器开发者工具看一下网络请求状态码。301还是302,还是200之后脚本跳转,这决定了排查方向。再用谷歌搜索的移动端友好测试工具模拟抓取看返回内容,或者用站长平台的抓取诊断直接看服务器返回的HTML源码,能直接发现是服务器重定向还是页面级跳转。
修复起来不算复杂,核心思路是保证每一个被收录的URL最终返回200状态码并且展示对应内容。如果确实需要跳转也要保证目标地址是某个具体的新页面,而不是一刀切跳首页。改完规则以后记得去搜索引擎站长后台提交索引更新,耐心等到蜘蛛重新抓取。