Lighthouse SEO 得分：电商分类页获得满分 100 分
在一个微小的静态页面上伪造 Lighthouse SEO 得分 100 分很容易。但在一个真实的电商分类页上则难得多，因为这类页面包含产品卡片、图片、价格、库存状态、过滤器、规范标签（canonicals）、结构化数据，而且后端还必须提供新鲜的商业数据。
我在 2026 年 6 月 17 日对 `https://www.cigge.se/e-cigaretter/engangs-vape` 运行了 Lighthouse。桌面端结果全面干净：性能 100 分、无障碍性 100 分、最佳实践 100 分、SEO 100 分。移动端表现同样出色：性能 97 分、无障碍性 100 分、最佳实践 100 分、SEO 100 分。
这并不意味着该页面的 SEO 工作已经“完成”。这意味着技术基础足够牢固，SEO 工作可以专注于内容、意图、内部链接、商业数据和权威性，而无需再与错误的标记、缓慢的渲染或混乱的抓取信号作斗争。
结果
| Lighthouse 审计项 | 桌面端 | 移动端 |
|---|---|---|
| --- | ---: | ---: |
| 性能 | 100 | 97 |
| 无障碍性 | 100 | 100 |
| 最佳实践 | 100 | 100 |
| SEO | 100 | 100 |
测试的 URL 是一个真实的电商分类页，而非精简的演示路由。这一点很重要。分类页通常是无头电商（headless ecommerce）最先变得混乱的地方。
在我合作或测试过的瑞典电子烟电商页面中，我从未见过更快的分类页结果。只有在经过受控的竞争对手基准测试后，我才会称其为瑞典最快的电子烟网站，但这个页面是一个强有力的候选者：桌面端 Lighthouse 满分，移动端性能 97 分，且页面上包含真实的商业数据。
产品详情页只有一个主要产品。而分类页则包含许多产品、许多图片、排序、过滤器、分页、产品可用性、价格变动、营销文本和内部链接。页面必须同时服务于购物者、搜索引擎和 CMS 团队。
Lighthouse SEO 得分证明了什么
Lighthouse 是 Google Chrome 团队提供的一款自动化审计工具。它检查性能、无障碍性、最佳实践、SEO 以及其他网络质量信号。Google PageSpeed Insights 也使用 Lighthouse 进行实验室诊断。
绿色得分并不能保证排名。Google 自己的文档将 90 分及以上视为良好，而一旦页面承载真实的产品数据和生产脚本，完美的 100 分就很难维持。
因此，我将这个 Lighthouse SEO 得分视为一个技术证明点，而非庆功时刻。该页面通过了那些经常阻碍电商 SEO 的基线检查：可抓取的 HTML、正确的元数据、可访问的结构、稳定的性能，以及没有明显的浏览器或安全错误。
为什么电商让这件事变得困难
电商页面会产生一些在简单营销页面上不会出现的 SEO 失败模式。
产品网格可能会加载过多的 JavaScript。如果产品图片没有正确调整大小和确定优先级，可能会破坏性能。过滤器可能会制造抓取陷阱。分页可能会分散信号。CMS 描述可能会破坏标题结构。变体 URL 可能会创建重复页面。库存更新可能会迫使大规模缓存清除。后端图片 URL 可能会泄露本地或私有路径。结构化数据可能会偏离购物者看到的内容。
任何一层薄弱都可能拖累整个页面。
这个得分源于将分类页视为一个系统，而不仅仅是一个带有几个元标签的模板。同样的系统视角也支撑着我在 使用 Next.js 扩展电商规模→ 方面的工作。
得分背后的 SEO 工作
重要的工作发生在运行 Lighthouse 之前。
我们清理了分类页的规范标签（canonicals），使第一页和分页的分类路由共享一致的基础。这减少了重复页面的混淆，并防止分页与主分类 URL 产生冲突。
当可编辑的分类描述未提供 H1 时，我们恢复了模板 H1 回退机制。这听起来很小，但缺少 H1 是抓取数据中最明显的技术 SEO 缺陷之一。
我们修复了 sitemap 来源处理，确保公共 URL 从正确的 storefront 来源解析，而不是泄露后端假设。Sitemap 应该是枯燥乏味的。如果它包含错误的主机、不可索引的 URL 或被阻止的 URL，就会浪费抓取注意力。
我们加强了本地化规范标签和 hreflang 返回链接。当每种语言都指向外部却没有收到匹配的返回路径时，多语言电商 SEO 就会失败。
我们还强化了产品和商户的结构化数据。电商 schema 必须与现实匹配：产品、报价、可用性、商户详情和运输详情需要与页面及后端状态保持一致。
抓取清理的意义远超一个得分
Lighthouse 截图是一个干净的产物，但更深层的 SEO 价值来自于围绕它的抓取修复。
随后的技术审计清楚地显示了方向：
| 问题类型 | 之前 | 之后 |
|---|---|---|
| --- | ---: | ---: |
| 被 Robots 阻止的 URL | 1,612 | 7 |
| 缺少 H1 | 999 | 67 |
| Sitemap 中不可索引的 URL | 1,185 | 14 |
| 缺少 hreflang 返回链接 | 102 | 4 |
| 多个 H1 | 245 | 2 |
| H1 结构非顺序 | 2,529 | 2 |
这些数字比绿色圆圈更让我关心。Lighthouse 告诉我页面通过了高质量的实验室检查。抓取数据告诉我，网站正变得更容易被搜索引擎大规模理解。
性能需要严格的缓存纪律
性能得分并非来自某一次图片调整。
Storefront 使用基于 PrestaShop 后端的 Next.js 前端。这种设置在缓存边界清晰时能提供速度，而在失效范围过宽时则会带来痛苦。
我们转向了范围有限的失效策略，而不是全站清除。产品事件、库存事件、分类变更、制造商更新、图片变更、CMS 编辑以及博客/引导事件并不需要相同的爆炸半径。当库存事件清除整个 storefront 时，用户会因为页面变慢和缓存变冷而付出代价。
更好的模型很简单：失效最小且有用的缓存标签集，然后让前端继续快速提供稳定的分类和产品页面。同样的工程模式也出现在我的 使用 Next.js 构建自定义 CRM CMS→ 工作中：赋予编辑者权力，同时不让动态数据损害前端。
这就是为什么分类页可以承载真实的电商数据，同时仍能达到桌面端性能 100 分和移动端性能 97 分。
干净的 HTML 仍然重要
现代电商团队通常将 SEO 视为元数据加 schema。这太狭隘了。
页面仍然需要语义化的 HTML。它需要一个合理的 H1。它需要可以在不破坏文档的情况下进行分类复制编辑。它需要将产品链接渲染为链接。它需要具有正确尺寸和 alt 文本的图片。它需要规范 URL，这些 URL 不会因为过滤器或分页状态混入错误的层而发生变化。
这就是 PageBuilder 和富文本工作重要的地方。CMS 编辑器应该让内容变得更简单，而不是创建格式错误的分类 HTML。Tiptap React 编辑器→ 的工作帮助保持了可编辑块的实用性，同时仍然尊重 storefront 的 HTML 和安全规则。
当我在 无头 WordPress 迁移→ 期间重建旧内容系统时，也应用了同样的规则：保持编辑器体验灵活，但保持公共 HTML 可预测。
我不会从此声称什么
我不会声称 Lighthouse SEO 100 分意味着该页面将排名第一。
搜索排名仍然取决于查询意图、产品范围、定价、品牌信任度、内部链接、反向链接、内容质量、用户行为以及 Google 如何解读整个网站。
我也不会将 Lighthouse 作为唯一的性能来源。实验室结果很有用，因为它们是可重复的。现场数据也很重要，因为它来自真实用户在真实设备和网络上的数据。
诚实的主张更窄但也更强：这个电商分类页在表现得像一个商业页面的同时，通过了严格的技术质量门槛。
实际要点
对于电商 SEO，我希望技术平台不要成为障碍。
这意味着分类页渲染有用的 HTML。规范标签和 sitemap 讲述同一个故事。Hreflang 是互惠的。产品数据和结构化数据相匹配。在后端进行小改动后，缓存保持温暖。编辑者可以添加内容而不损坏页面结构。图片加载速度快，且不会隐藏产品。
当这些部分对齐时，像这样的 Lighthouse SEO 得分才成为可能。更重要的是，SEO 团队可以将时间花在真正能产生复利效应的工作上：内容、产品覆盖、内部链接、转化和权威性。
我将 Lighthouse 结果视为工程质量的证据。得分是可见的部分。价值在于其背后的系统。