谷歌索引200页重复内容，团队3周没发现

去年Q3，某团队一次常规部署干掉了200个页面的规范标签（canonical tags）。没人发现，直到三周后流量暴跌15%。修复代码花了10分钟，流量恢复用了6周。

这不是技术债，是流程债。作者把这段经历写进博客，核心观点很直接：SEO检查应该塞进CI/CD（持续集成/持续部署）流水线。但每次他跟其他开发者聊这事，得到的反应都一样——"我们试过在CI里跑Lighthouse，每次构建多等4分钟，后来弃了。"

Lighthouse很好，但用错了地方

Lighthouse是谷歌出的浏览器审计工具，跑一趟要启动无头Chrome实例、加载完整页面、执行性能审计、可访问性检查、SEO检查、生成报告。全面，也全面得笨重。

按web.dev官方文档，单页面Lighthouse运行耗时15-45秒。检查10个页面就是3-7分钟。对于每次PR（Pull Request，拉取请求）都要触发的CI流水线，这属于自杀式配置。大多数团队的选择很现实：直接跳过。

但作者认为问题出在工具选型，而非需求本身。他拆解了代码变更导致的SEO灾难，发现高度集中在几类场景：标题标签缺失或重复、元描述（meta description）为空、意外加上noindex指令、规范标签丢失或错误、图片alt属性缺失。没有一类是Lighthouse的专属领域。

换句话说，你需要的是HTML解析器，不是浏览器模拟器。前者跑完以秒计，后者以分钟计。

一个10秒级的替代方案

作者贴了一段自研的SEO linting脚本，核心依赖只有jsdom——一个Node.js的HTML解析库，无需真实浏览器。代码逻辑很直白：读取构建产物里的HTML文件，用CSS选择器抓取关键元素，做规则校验。

具体检查项包括：title标签是否存在且非空、长度是否超过60字符（触发警告而非错误）、meta description是否存在、robots元标签是否意外包含noindex、canonical链接是否存在、图片是否都有alt文本。

这套脚本在作者团队的CI里跑完全部检查，耗时不到10秒。对比Lighthouse的分钟级开销，差距在两个数量级。

但快不是唯一优势。更关键的是失败模式的可预测性——Lighthouse的分数波动受网络、机器负载、Chrome版本影响，而HTML解析的结果是确定的。你不需要为"为什么这次比上次慢20%"开会。

为什么开发者抵触SEO进CI

作者观察到一个组织层面的张力：SEO团队和工程团队的工作节奏不同频。SEO问题通常滞后显现——代码上线几周后，搜索排名才开始波动。而工程师的反馈回路是秒级的，单元测试红了立刻知道。

这种时差导致SEO检查在CI里的优先级天然偏低。加上Lighthouse的历史包袱——很多人第一次尝试就踩了性能坑，形成"SEO检查=拖慢构建"的肌肉记忆。

作者的建议是分阶段渗透：先用轻量级脚本守住底线（防止灾难性错误），再逐步扩展规则集。不要一上来就追求全面审计，那属于监控（monitoring）的范畴，该放在部署后而非构建时。

落地时的三个取舍

第一，检查范围。作者只扫描构建产物中的HTML文件，不碰动态路由。这意味着单页应用（SPA）的客户端渲染页面需要额外处理，但静态站点生成（SSG）的场景覆盖很完整。

第二，错误分级。missing title是error，title过长是warning。这个区分让团队能快速识别阻塞性问题，同时保留优化空间的可见性。

第三，执行时机。放在构建后、部署前，而非单元测试阶段。这样不会污染核心测试套件的信号，又能保证有问题的构建进不了生产环境。

作者在文末提到，这套脚本上线后，团队再也没出现过规范标签丢失的事故。但他也留了一个未解的问题：对于依赖客户端渲染的复杂应用，10秒级的检查方案边界在哪里？

你的团队是怎么处理SEO和CI/CD的关系的——是彻底不管，还是找到了比Lighthouse更轻的解法？