# 一个新网站应该先做功能还是先做SEO？

URL: https://caijiao.org/posts/109
Source: docs/posts/109.md
Description: Omni Calculator 的 URL 是 /finance/annual-income 这种结构，广告负责人说页面速度没有商量余地——这两件事都在写第一行代码之前决定。

我见过最贵的一次返工，来自一个上线三个月、已经有一批稳定访客的小工具站。作者想把某一类页面统一换个名字——原来的 URL 是拼出来的参数串，没有层级。改完的当月，那一整类页面的搜索流量消失了大半，花了两个多月才恢复。

功能优先还是 SEO 优先，这个问题本身是假的。它们建立在同一个决策之上：**URL 结构和页面生成方式**。这个决策发生在动手之前，一旦上线就很难回头。

## /finance/ 和 /other/，这两个目录比关键词清单重要

看 Omni Calculator 的 URL：/finance/annual-income、/finance/margin、/finance/salary-to-hourly、/other/test-grade。

![Omni Calculator 计算器分类页截图](/images/2026-09/omnicalculator.com.png)

*Omni Calculator 首页按 Biology、Chemistry、Construction 等十几个分类铺开，Math 和 Finance 体量最大。*

目录名就是它的品类地图。这个结构带来几个直接的好处：新增页面时不用纠结放哪儿，同一个目录下的页面天然互相链接，一份 sitemap 也能按目录分片——哪个目录更新了就提交哪一份，抓取预算花在刚改动的地方。

反过来看那种 `/tool?id=123` 的结构，功能照样能做，但页面之间没有可描述的关系，永远拿不到"这一组页面属于同一类"这个信号。

要把它落成稳定的秩序，前期只需守三条：目录名用小写英文加连字符；层级最多两层；URL 一旦发布就不再改动，确实需要调整时保留旧地址做跳转。

## 「页面速度没有商量余地」是一句架构决策

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

这句话听着属于优化环节，其实属于立项环节。因为它要求的是：

**结果页 HTML 在服务端就是完整的。** 用 [React](/react/) 做组件化开发没问题，但要走服务端或构建期预渲染，别把内容留给浏览器去填充一个空壳。这个决定写在脚手架里，后期改要动整条渲染链路。

**每个页面独立、静态、可被缓存。** 首屏不依赖任何接口，静态资源走长缓存，压缩这块交给 [Nginx](/nginx/)（brotli、缓存头、反代一层即可）。这些配置在项目第一天加进去是半小时的事，等到流量起来了再加，等于一边开飞机一边换引擎。

**交互留在客户端。** 真正频繁变化的只是计算结果，用前端算，不让网络往返参与首屏。

## 第一周就该做完的三件事

这几件事常被当成"SEO 工作"，我更愿意把它们当作发布流水线的一部分。

**接入 Search Console。** 上线第一天就要做，因为"哪些页面没被索引"这件事知道得越早越便宜。[/google-search-central/02-search-console-setup](/google-search-central/02-search-console-setup) 里写得很细。

**生成 sitemap，并预留分片。** 趁页面还少的时候确定生成逻辑，页面数量上来以后自动分片，不用重写。规范见 [/google-search-central/04-sitemaps-robots](/google-search-central/04-sitemaps-robots)。

**给模板留出属于每个页面的唯一实体字段。** 每个页面要能说出自己算的是哪一个量、单位是什么。这个字段现在就要填满，别等到批量加结构化标记时才发现模板里没给它留位置。

## 功能做完再补 SEO，代价一次性涨一个数量级

我见过不少站点是"先把功能做完，SEO 以后再说"的顺序，后果通常集中在三件事上，每一件都比提前说清楚贵得多。

**改 URL。** 上线三个月之后调整路径，等于把已经积累的记录一次性作废。旧地址跳转不是免费的：要走一段识别期，期间流量掉下去再慢慢回来。这笔损失和我开篇说的那次返工是一模一样的形状。

**改渲染方式。** 一开始用纯客户端渲染写的站，后来要改成构建期或服务端渲染，动的是模板、数据获取方式和缓存策略，几乎等于重写。反过来，一开始就确定服务端渲染的方向，后面只是往里填内容。

**改信息结构。** 每个页面缺了"唯一的实体字段"，等到要批量加结构化标记时才发现在模板里塞不下，只能回头改数据模型。这一项我最常遇到，因为它不痛不痒，一直拖到批量处理时才爆发。

这三件事的共同点是：**它们都不是 SEO 动作，是架构动作。** 所以把它们放在"以后再做"的计划里，实际上排到了永远做不了的位置。

## SEO 也不能替你把坑填平

反过来说，把 SEO 当成万能药是另一个极端。Omni Calculator 之所以能有 1429 万月访问，前提是真的存在几百个需要被计算的量，而每一个页面都准确地算了它。这里的 /finance/margin 主词搜索量 55000 拿到 49169 访问，/finance/salary-to-hourly 是 42000 到 45940，接近一比一的转化靠的是页面真的把这件事做完了。

一条可以今天就做完的事：**先写个脚本把候选页面的 URL 全部打出来，自己扫一遍。** 如果连你都看不出哪个页面是给谁的，生成器也不会比你的思路更清楚——先回去修列表，别急着写代码。

---

*Omni Calculator 单页数据来自 Ahrefs 公开案例，Alexander Utz 的表述引自其公开访谈。*