构建通过，SEO 却坏了：部署会破坏哪些检查发现不了的东西

部署是周五上线的。构建通过，测试通过，预览看起来没问题，网站对每个打开它的人都运行正常。三周后，有人发现来自 Google 的注册量少了三分之一。

原因通常很小：布局里的一行代码、从测试环境复制过来的一项设置、匆忙加上的一条重定向。访客察觉不到，构建和测试也检查不到，因为它们都不会像搜索引擎那样去读页面。

本文列出我们最常见的几种改动、每一种的识别方法，以及每次生产环境部署后都可以执行的一套简短检查流程。

为什么测试发现不了 #

测试检查的是页面能不能用：按钮能提交，价格算得对，页面返回 200。搜索引擎读取的是另一些东西，主要在 <head> 里，以及服务器在任何 JavaScript 运行之前发送的 HTML 中。一个页面可以对人完全正常，同时却在告诉 Google 不要索引它。

而且 Google 反映得很慢。被移出索引的页面会在几天内逐渐失去流量，Search Console 还要再过几天才会报告。到那时，这次改动早已被后来的部署淹没。

八种不会让网站出错、却会破坏搜索的改动 #

1. 从测试环境带过来的 noindex #

SEO 里代价最高的一行代码：

<meta name="robots" content="noindex">

它通常来自一项在生产环境中也生效的测试环境设置、一个在缺少环境变量时会自动加上它的组件，或者一个从非公开页面复制来的模板。同样的指令也可能以 HTTP 头的形式出现，即 X-Robots-Tag: noindex，在页面源代码里根本看不到。

2. robots.txt 屏蔽的范围超出预期 #

本来给测试环境用的 Disallow: /，或者一条覆盖了比预期更多路径的新规则。有两个细节让问题比看上去更严重：被 robots.txt 屏蔽的页面无法被抓取，所以 Google 永远看不到它的内容和它的 noindex；而 Google 不支持在 robots.txt 里写 noindex，那一行不起任何作用。

3. 指向别处的 canonical #

canonical 标签告诉 Google 哪个地址是主地址。一次部署之后，它可能在所有页面上都指向首页，指向 my-project-git-main-team.vercel.app 这样的预览地址，或者指向 http:// 而不是 https://。Google 把 canonical 当作一个强信号，错误的 canonical 可能把你的排名转移到一个没人访问的地址上。

4. 只有在 JavaScript 运行后才出现的内容 #

一次重构把商品列表或文章正文从服务器端移到了浏览器端：页面看起来一模一样，但服务器发送的 HTML 现在几乎是空的。Google 确实会运行 JavaScript，但时间更晚，也不一定完整。凡是希望被搜到的内容，放在服务器 HTML 里才稳妥。

5. 重定向和状态码 #

原来返回 200 的页面现在返回 404，或者重定向到首页，或者要经过三次重定向才能到达。永久迁移应该是一次 301 或 308，直接跳到最终地址。持续数天的 5xx 类错误会让 Google 减少抓取，最终把页面移出索引。

6. 丢了页面的站点地图 #

新的路由或 CMS 的改动，生成的站点地图缺少了一些带来流量的网址，或者包含了现在会重定向的地址。站点地图不是排名因素，但 Google 靠它快速发现页面，你也靠它在 Search Console 中按页面查看索引问题。

7. 被默认值覆盖的标题、描述和页内标题 #

一个共享布局开始用网站名称覆盖页面标题，或者所有页面都用同一段描述。发生在一个页面上不算灾难；发生在带来大部分访问量的那 20 个页面上，损失就是实实在在的。

8. 不再互相指向的语言版本 #

在多语言网站上，hreflang 链接告诉 Google 应该向谁展示哪个版本。这些链接必须是双向的：如果日文页面指向英文页面，英文页面也必须指回来。一次只改了某一种语言网址的部署会破坏这种对应关系，Google 可能在搜索结果中显示错误的语言。

两分钟检查一个页面 #

抽查不需要专门的工具。在终端中运行：

# Status code, redirects and the X-Robots-Tag header
curl -sIL https://www.example.com/pricing | grep -iE "^HTTP|^location|x-robots-tag"

# robots meta tag and canonical in the server HTML
curl -sL https://www.example.com/pricing | grep -ioE '<meta[^>]+robots[^>]*>|<link[^>]+canonical[^>]*>'

# robots.txt as it is now
curl -s https://www.example.com/robots.txt

要确认主要内容是否在服务器 HTML 中，请用查看网页源代码打开页面（不要用检查工具，它显示的是 JavaScript 运行之后的页面），然后搜索正文中的一句话。在 Search Console 中，网址检查工具会显示 Google 抓取并渲染后的页面，以及它是否允许被编入索引。

每次生产环境部署后的检查流程 #

手动检查每个页面并不现实，所以只检查重要的页面：

1. 列出你的重点页面。 在 Search Console 中打开效果，按点击次数对过去三个月的页面排序，取前 10 到 20 个。你的搜索流量大部分来自这些页面。
2. 每次部署后，对这些页面执行上面的检查： 状态码、标签和 HTTP 头中的 noindex、canonical、标题，以及服务器 HTML 中的一句正文。
3. 只要路由、CMS 或框架有变动，就查看 robots.txt 和站点地图。
4. 记下每个页面"正常"时的样子（状态码 200、canonical 指向自身、标题），这样一有变化就很明显。
5. 在接下来的一周里留意 Search Console。 网页报告和重点页面的点击次数，会暴露那些漏网的问题。

这份清单的大部分内容，也属于完善的网站每月维护。区别在于时机：部署后立即检查，发现问题时它还只是一次可以回滚的提交，而不是三周的流量损失。

我们开发 Hawk Delta，正是为了给我们维护的 Vercel 网站做这件事：每次生产环境部署后，它会把重要页面与上一个正常版本进行比较，并通过邮件告诉你哪里坏了、涉及多少搜索流量，以及如何修复。目前它正在进行免费的内测。