一个网站上线前,我会检查哪些项目?
我踩过最贵的一次坑,是把 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 文档里写得很细,值得对着过一遍,而不是凭记忆配。
Core Web Vitals:Omni Calculator 把它当成不可商量的项
Omni Calculator 的广告负责人 Alexander Utz 说过一句我很认同的话:“页面速度对我们没有商量余地,我们的整个增长都依赖 SEO,Core Web Vitals 直接影响排名。”

Omni Calculator 首页还有一个 Discover Omni 板块,自我介绍是「用计算揭示世界的惊人真相」。
落到检查项上是三件具体的事。
LCP 看首屏最大的那块内容通常是什么——多数情况是一张图或一段标题。图要写明 width 和 height,格式优先 webp,首屏那张不要懒加载(懒加载的首屏图会直接把 LCP 推后)。
INP 看交互响应。工具站容易在这里翻车:一个几十兆的文本处理函数跑在主线程上,点一下卡两秒。这类活要么切片,要么丢给 WebAssembly 在后台跑。
CLS 看尺寸预留。广告位、图片、动态插入的提示条都要先占好高度,不然加载完成后页面往下跳一截。
还有一项几乎总能白捡几百 KB:字体。中文字体子集化、只加载用到的字重、配 font-display: swap,这三条做完,首屏通常能瘦一圈。别为了一个装饰性标题引入一整套字库。
顺带把结构化数据也验一遍——用 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 文件策略引自其官网说明。