在我们开始对外提供技术 SEO 服务之前,我们先做了大多数代理公司都会跳过的一件事:把整套流程用在自己身上。
我们对 prixelo.com 进行了一次完整的技术审计。不是测试环境,也不是演示站点,而是真实的网站——潜在客户在给我们发邮件之前会先看的那个网站。我们本以为只会发现几个小问题,结果找出了 7 个正在实实在在拖累我们的问题。
这篇文章就是那次审计的原始记录,未经删改。没有虚构的客户,没有编造的案例研究。只有我们在自家网站上发现的真实问题,以及每个 bug 揭示出的一个道理:搜索引擎实际看到的页面,和浏览器为你渲染出来的页面,是两回事。
站点地图漏掉了网站的大部分页面
我们打开 sitemap.xml,本以为只是走个形式,结果发现这个文件里只列出了我们真实页面中的一小部分。整块整块的内容——已经上线、有内部链接、本该参与排名的页面——完全不在其中。
站点地图不是可有可无的东西。它是你交给 Google 的一张地图,让它不必单靠爬取链接来猜测你的网站结构。一个已上线、有内部链接指向、但不在站点地图里的页面,最终或许还是会被收录,但速度更慢、可靠性更差,而且会向爬虫传递一个信号:你网站的元数据不可信。站点地图只要有一次出错,爬虫就更没有理由在其他地方也把它当作权威来源来对待。
我们的 Organization JSON-LD 全站范围内都是坏的
我们习惯用验证工具检查结构化数据。结果我们的数据没通过验证。每一个页面都是。
原因是一个模板转义的 bug——我们 Organization schema 里的某个字符在渲染时被错误编码,导致 JSON-LD 代码块在它出现的每一个页面上都存在语法错误。Google 不会部分解析损坏的 JSON,要么完整解析成功,要么直接丢弃整个代码块。所以不知道有多久,我们全站范围内实际上没有任何结构化数据传递给 Google,而我们却一直以为自己有完整的标记。这类 bug 在浏览器里不会报任何错误——页面看起来完全正常——也不会有任何提示,除非你专门用 schema 验证工具或者 Search Console 的富媒体搜索结果报告去查。
soft-404 却返回 HTTP 200
网站上一些失效或已删除的 URL 并没有返回 404 状态。它们提供的是兜底内容——一个通用页面——而服务器却告诉浏览器和每一个爬虫:"200 OK,这个页面存在。"
这就是 soft-404,而且比真正的 404 更糟糕。一个真正的 404 会清楚地告诉搜索引擎:这个 URL 已经没了,把它从索引里删掉。而 soft-404 告诉搜索引擎的却是:这个 URL 没问题,请继续抓取和收录它——尽管这里其实什么都没有。如果放任不管,这会白白浪费抓取预算在根本不存在的页面上,还可能稀释搜索引擎对你真实页面的评估,因为爬虫把时间和信任都花在了这些自称"存活"的死路上。
canonical 标签指向了错误的域名
有几个页面的 canonical 标签指向的是我们自己域名的非 www 版本,而那个版本本身又会重定向到别处——这是早期配置遗留下来的问题。canonical 标签是直接下给搜索引擎的指令:"把这个 URL 当作权威版本收录,而不是你现在正在看的这个。"一旦它指向了错误的地方,你就是在明确告诉 Google 把功劳记在你自己内容的另一个 URL 上。往好了说,这条指令会被忽略;往坏了说,你是在主动把自己的排名信号从真正需要它们的页面上引开。
meta description 在词语中间被截断
这个问题比较小,但正是这类小问题累积起来会侵蚀可信度:好几处 meta description 在原始 HTML 里就被截断在词语中间,而不只是在搜索结果里为了显示而被截短。这是模板或字符限制上的 bug,不是显示层面的问题,表现出来就是 <meta> 标签里躺着一句没写完的话——任何查看源代码的人都能看到,对一个想要显得可信的页面来说,这是一个不起眼却真实存在的粗心信号。
一份来自早于现有网站的目录的过期 robots.txt
这是最离奇的一个发现。实际提供服务的 robots.txt 根本不是我们当前代码库里的那份。它来自服务器上一个遗留的旧目录——本该被彻底淘汰的上一版网站留下的残余。线上应用完全不知道这个文件的存在,也不知道爬虫实际读取的正是它。
robots.txt 是爬虫最先请求的文件之一。如果实际提供的版本是 过期的,它可能会屏蔽本该可被抓取的路径,放行本不该放行的路径,或者干脆指向一个早已不存在的站点地图。而且因为它存在于正常部署路径之外,任何检查当前代码库的人都看不到它——你必须去检查这个 URL 实际返回的内容,而不是你以为自己部署了什么。
因为仅在客户端识别 slug,页面向爬虫返回"未找到"
最后一个问题出在 JavaScript 渲染上,这是任何采用客户端路由的项目都容易踩的坑。某些页面要显示哪些内容,取决于一个只有在浏览器里、JavaScript 执行之后才能解析出来的 slug。不会完整执行客户端 JavaScript 的爬虫——或者在解析完成之前就超时的爬虫——拿到的只是服务器最初返回的响应,找不到匹配的 slug,于是被扔进"未找到"的状态。这个页面对人来说完全正常,但对一个永远走不到能看见真实内容那一步的爬虫来说,它要么根本不可见,要么就是坏的。
这件事真正说明了什么
这些 bug 没有一个是稀奇古怪的。它们是任何一个走过了第一版、持续迭代过的网站都会出现的标准故障模式:没人下线的遗留基础设施、悄悄破坏了编码的模板改动、针对用户体验优化过、却从没对照爬虫行为检查过的路由方式。它们每一个在普通浏览器里都看不出来,除非有人专门去查爬虫看到的页面是什么样子,而不是人看到的样子。
这才是真正的工作内容。技术 SEO 不是关键词建议,也不是内容日历——它是要找出你网站在你眼中的样子,和它在决定是否收录、是否排名的系统眼中的样子,这两者之间的差距。我们在打造自己的SEO服务的过程中,修复了自家网站上全部 7 个问题,因为我们不打算去卖一份连自己都没先做过的审计。
如果你想知道自己的网站是不是也存在类似的问题,这正是我们 SEO 团队最先会去检查的内容——在谈论任何内容或排名之前。
