# 一个网站上线前，我会检查哪些项目？

URL: https://caijiao.org/posts/138
Source: docs/posts/138.md
Description: 我上线过一次忘了配 404，所有不存在的 URL 都返回 200 加首页内容，攒出一堆重复页面。清单里最值钱的几项都不是功能：状态码、canonical、robots、移动端、Core Web Vitals。

我踩过最贵的一次坑，是把 404 配错了。当时用的静态托管默认行为是：找不到就返回首页，状态码还是 200。上线两周后我在索引报告里看到一堆乱七八糟的 URL 全被收录了，内容一模一样。清这批页面比做这个站花的时间还长。

从那以后我有了这份清单。它不检查功能，只检查那些"上线当天看不出问题、几周后集中爆发"的东西。

## 404 必须真的返回 404，301 只跳一次

用 curl 抽查几个不存在的 URL，`-I` 看响应头，状态码必须是 404，不能是 200。

单页应用尤其容易踩：为了支持前端路由，把所有路径都回退到 index.html，结果连 `/asdfghjkl` 也返回 200。正确做法是只对已知路由前缀回退，其余走 404 分支。

跳转链也要数一下。A 跳 B 再跳 C 这种两跳的链，多半是 http→https、www→非 www 被拆成了两条规则，合成一条就好。

## canonical 和 robots，模板最容易带错的两处

canonical 要指向页面自己的规范 URL，包括带语言前缀的版本。分页页指向自己，而不是指向第一页——很多模板默认指向第一页，等于告诉搜索引擎后面几页不用收录。

robots.txt 亲自打开看一眼。出过的事故包括：预发布环境的 `Disallow: /` 被推到生产；模板里带的 `Disallow: /admin` 之类路径其实并不存在；开发环境留下的 `noindex` 元标签忘了删。

这两处出错的共同点是：本地测试完全正常，只有在真实抓取时才会显现。索引相关的规范在 [Google Search Central](/google-search-central/) 文档里写得很细，值得对着过一遍，而不是凭记忆配。

## Core Web Vitals：Omni Calculator 把它当成不可商量的项

Omni Calculator 的广告负责人 Alexander Utz 说过一句我很认同的话："页面速度对我们没有商量余地，我们的整个增长都依赖 SEO，Core Web Vitals 直接影响排名。"

![Omni Calculator 官网首页截图](/images/2026-09/omnicalculator.com.png)

*Omni Calculator 首页还有一个 Discover Omni 板块，自我介绍是「用计算揭示世界的惊人真相」。*

落到检查项上是三件具体的事。

LCP 看首屏最大的那块内容通常是什么——多数情况是一张图或一段标题。图要写明 width 和 height，格式优先 webp，首屏那张不要懒加载（懒加载的首屏图会直接把 LCP 推后）。

INP 看交互响应。工具站容易在这里翻车：一个几十兆的文本处理函数跑在主线程上，点一下卡两秒。这类活要么切片，要么丢给 [WebAssembly](/webassembly/) 在后台跑。

CLS 看尺寸预留。广告位、图片、动态插入的提示条都要先占好高度，不然加载完成后页面往下跳一截。

还有一项几乎总能白捡几百 KB：字体。中文字体子集化、只加载用到的字重、配 `font-display: swap`，这三条做完，首屏通常能瘦一圈。别为了一个装饰性标题引入一整套字库。

顺带把结构化数据也验一遍——用 [JSON-LD](/json-ld/) 写的标记，字段拼错时页面看起来毫无异常，只有校验工具会说。

跑分也要看场景。本地开发机上 Lighthouse 打出 95 分不代表线上没问题——真实用户的 CPU 慢得多、网络还在移动信号和 Wi-Fi 之间切换。至少用一台中低端手机、在普通 4G 下手动开一次页面，你会看到跑分里看不到的东西。

## 日志和错误上报，上线前就该能看见

上线之后第一个小时你一定会想看两样东西：访问日志里有没有大量 5xx，以及前端有没有抛异常。这两样如果上线前没配好，就只能靠用户来告诉你。

前端错误上报要带三样信息：错误堆栈、页面 URL、应用版本号。第三样最容易被漏，而没有它，你会对着一个报错不知道它属于哪次发布——尤其在一天发好几个版本的时候。

服务端日志至少要能回答"这个请求花了多久、返回了什么状态码"。工具站还要额外记一件事：每个工具被调用了多少次、失败了多少次、平均耗时。这几个数字会直接告诉你该优先优化哪个工具，而不是靠猜。

## 移动端和异常输入，值得人工过一遍

移动端我只查三件事：输入框字号小于 16px 会被浏览器自动放大页面；点击区域小于 40px 的目标很难点中；有没有出现横向滚动条。

异常输入是工具站的重灾区：粘贴一个空字符串、上传一个 0 字节文件、上传一个超出限制的大文件、中途断网。每一种都应该有一句人话提示，而不是转圈到超时。承诺也要写在页面上——TinyWow 那句"文件 1 小时后自动删除"就该放在上传区旁边，而不是埋在隐私政策里。

## 最后五分钟：回滚和内容自查

确认上一版产物还在，能一键切回；确认数据库备份真的恢复过一次（没验证过的备份不算备份）；确认健康检查端点在返回 200。

还有一条容易被跳过：把每个要上线的页面逐个问一遍"有没有人真的会用它"。Google 的质量文档里有一类专门针对"几乎没有付出努力就生成的内容"（4.6.6），而 Helpful Content System 在 2025 年已经升级成整站信号——一批凑数页面不再是它们自己没流量，而是会连累整站。

这份清单大概半小时能跑完，但我不会为了省这半小时跳过它——它挡住的不是小毛病，是那类"上线三周后才发现、然后要用三个月去修"的问题。

清单里如果只能跑两项，我会选状态码和 Core Web Vitals。功能错了当天就能改，被搜索引擎判成重复内容，要几周才恢复得回来。

---

*Omni Calculator 引述出自其广告负责人 Alexander Utz 的公开访谈；TinyWow 文件策略引自其官网说明。*