SEO 是产品的一部分，不是发布后的补救

先让搜索引擎在第一次请求时就拿到正确的页面，再去操心关键词。

SEO 是产品的一部分，不是发布后才想的事。

自从我开始自己做产品，看过很多刚上线的网站，反复看到同一类问题。从渲染和语言路由，到 robots、sitemap、错误状态、测试环境、页面标签和关键词覆盖，几乎没有任何一项基础 SEO 设置是到位的。SEO 从来没有进入过构建流程。

最严重的几个 SEO 问题

新站上最常见的错误是：基础的 SEO 设施几乎到处都缺。客户端渲染、由浏览器决定的语言路由、robots.txt 和 sitemap 返回首页、不存在的 URL 返回 200、测试环境被 Google 收录、没有 canonical、没有 hreflang、没有 H1、没有可抓取的链接、没有结构化数据。

它们有一个共同点：在第一次请求时，搜索引擎拿不到一个能说明「这个页面是什么」的 HTML 页面。关键词再好，也没有地方落地。

SEO 从来没有成为构建流程的一部分。如果一个页面从一开始就不是按「需要被理解、被索引、被正确链接」来设计的，后面再补内容也只是打补丁。

第一个转变：把搜索查询当成市场信号

我开始认真对待 SEO，是因为 Search Console 里一个奇怪的查询——那时候我的产品页几乎还没有流量。

我的一个产品页上出现了一个拼错的、看起来不完整的搜索词。它让我看到，真实的查询是来自市场的一个弱信号，不该只被当成报表里的一行。一个真实查询至少包含三类信息：

• 需求信号：有人正在找某样东西；
• 分发信号：Google 已经把我的页面和这个意图关联起来了；
• 产品信号：这个搜索意图可能揭示出用户想解决的问题。

于是做法变成：先把真实查询当成一次需求探针，再决定要不要为它做一个专门的落地页。批量生产 SEO 页面然后等需求上门，是把顺序搞反了。

我在每个项目里都保持这个顺序：

真实查询 → 理解意图 → 验证相关性 → 做落地页 → 观察查询是否扩展

一个落地页回答一个问题

首页得讲清楚品牌、产品、功能、价格、下载等等。一个落地页只需要把某一个具体问题回答好。比如当我的产品看到「Mac 连上 Wi-Fi 但上不了网」这类真实查询时，一个专门讲这个问题的页面，对搜索引擎和用户来说，都比首页更有用。

上线之后要紧的是它带来了哪些新查询。如果一个模糊的词逐渐扩展成一整簇查询，那么某条目前服务得还不好的工作流，可能比任何单个关键词都更重要。

信任比一次点击更稀缺

在做竞品页面的时候，我犯过一个具体的错误：我把一个含义模糊的产品名当成了同一个产品，写下「这个竞品没有 Mac 版」。

有几个不相干的产品共用了同一个名字，而我们研究的只是其中一个。我现在遵循一条规则：

只要涉及竞品、品牌或产品名，先把实体消歧。

至少要确认：完整的产品名、开发者或公司、官网、有没有别的产品同名，以及平台、价格和功能方面的说法是否来自这个具体实体的官方来源。如果名字本身有歧义，就在首屏说清楚，而不是把澄清藏在页面底部。

信任是借不来的。 对一个小型独立产品来说，一次 SEO 点击几乎没有长期价值。但如果用户发现一个页面在故意混淆、隐瞒事实，或者夸大竞品的缺陷，他对整个产品和品牌的判断都会下降。

我的准则是：

搜索意图匹配页面承诺 × 页面承诺匹配产品能力

任何一层对不上，更多的点击只会把更多不匹配的用户送进门。

能用的顺序：渲染与路由、基础文件、测试环境，然后才是页面信号和关键词。

正确的顺序：先让搜索引擎拿到正确的页面

我现在用的顺序是：

1. 先修渲染和语言路由。 把首页和核心页面改到 SSR、SSG 或预渲染，让内容、唯一的 TDK、H1 和链接在第一次请求时就在 HTML 里。把根路径定下来，让每种语言都是一个清晰、可抓取的页面。
2. 补上基础文件和正确的错误状态。 提供真实的 robots.txt 和 sitemap.xml。不存在的 URL 应该返回 404 或 410，而不是全部重定向到首页。
3. 隔离测试环境。 内部测试和 dev 子域用鉴权挡起来。必须公开预览的页面用 noindex。
4. 补齐页面信号和关键词入口。 加上 canonical、hreflang、Open Graph、结构化数据和可抓取的内链，然后把已有的产品能力拆成功能页、教程和 FAQ。

这个顺序的关键在于：先让 Google 直接拿到正确的页面，再处理抓取、索引和页面信号，关键词和内容放在最后。一个站已经上线之后，不要急着加新页面。先把已有页面和基础打点理顺。

搜索意图、页面承诺和产品能力要先对得上，点击才值得争取。

我的实践：把 SEO 放进构建流程

说容易。我已经在自己项目里套用这个顺序：

• 主站 i18n：英文留在根路径，中文放在 /zh/ 下。每个翻译页都有 lang、canonical、双向 hreflang、OG locale 和 JSON-LD。未翻译的页面不暴露 /zh/ 路由，所以半成品永远不会被索引。
• 产品站的故障排查文章：针对「Mac 连上 Wi-Fi 但上不了网」这类查询，把症状决策表提到首屏，让 Google 和用户更快看到排查路径。FAQ 补充排查问题并链接到对应的文章。
• 竞品与对比页：先确认具体实体，把重叠之处和根本差异都写清楚，当竞品确实更适合某个需求时，直接说明。
• 多语言游戏页：修正 JSON-LD 的语言信号，让每种语言都有正确的 inLanguage，而不是全部标成 en。
• 私有 dashboard：公开访问加保护，登录页用 noindex，sitemap 排除内部页面。
• 每次发布的基线检查：发布当天提交 URL Inspection 和 sitemap 发现，存下部署哈希和改动清单，第 7 天看收录和抓取，第 14 天看查询扩展，第 28 天做一次更完整的判断。

共同的目标是：当搜索引擎和用户发出第一次请求时，一个真实、正确、能被理解的页面已经在那里。

SEO 是产品的一部分

这些观察里最大的教训是：

SEO 是产品的一部分，不是发布后的补救。

如果一个产品从第一天起就把「搜索引擎会怎么理解这个页面」当成一项需求，那 robots.txt、canonical 和收录基础在发布之前就已经存在了。

独立开发者没有运营团队来兜住我们漏掉的东西。SEO 是构建中正常的一部分：先让搜索引擎拿到正确的页面，再谈关键词。先解决一个真实问题，再去追流量。

我判断一个页面做得好不好的标准很简单：它是真实的、正确的、能被理解的。