大站做 SEO，别再盯着某个词排第几

案例来自我在一家英国分类信息网站的工作。站名和绝对数字都做了处理，只保留比例和量级。

我刚开始给一个几千万 URL 的分类信息站做 SEO 时，第一反应和很多人一样：拉关键词排名表，看哪些词掉了，一个个去查。

查了两周，发现这条路走不通。掉排名的词有几千个，背后的页面有几百万个，但这几百万个页面其实只由十几个模板生成：搜索结果页、帖子详情页、类目×城市落地页、商家主页。我盯着的每一个词，最后都指向同一个问题：某一类页面整体出了毛病。

这篇文章讲的就是这个转变，以及它对开发团队意味着什么。

一、大站的 SEO 单位是页面类型

小站做 SEO，单位是页面。一篇文章写好了，标题调一下，内链补几条，排名就能动。

大站不是这样。开发改一次搜索结果页的模板，影响的是几十万个 URL。反过来，SEO 想让某个词回升，能动的也只有模板。没有人会去手改一个帖子页的 H1。

所以我现在看问题的顺序反过来了：

1. 先按页面类型切流量和收录数据
2. 找出哪一类页面整体在跌、在膨胀、或者没被收录
3. 再回到具体关键词上验证

关键词排名表还是有用，但它是报警器，不是诊断工具。

二、「页面架构」具体指什么

「架构」这个词太虚，开发听了也不知道该改哪里。我把它拆成四块，每一块都能落到具体代码上。

1. URL 空间：哪些 URL 能被生成、能被收录

这是我见过最贵的问题。

那个站的站内搜索页有一个 URL 模式：/<类目路径>/uk/<城市>/srpsearch+<搜索词>。实测发现，中间的类目路径段完全不生效。只要是站内真实存在的类目，不管属于哪条业务线，都返回同一个搜索结果页，而且每个 URL 都把 canonical 指向自己。

结果是下面这组 URL 内容 100% 相同，却各自独立可索引：

/uk/hull/srpsearch+double+bed
/for-sale/uk/hull/srpsearch+double+bed
/for-sale/home-garden/uk/hull/srpsearch+double+bed
/business-services/.../massage-services/uk/hull/srpsearch+double+bed

最后一条是按摩服务类目的路径，返回的是双人床。

URL 空间等于「全部类目 × 全部城市 × 任意搜索词」，没有上限。在 Search Console 里的表现是：「已抓取，目前未编入索引」的页面比已编入索引的还多一半。Google 抓了，但不想要。

业务上的后果更直接：本地服务的点击同比腰斩，有曝光的 URL 数反而在涨。变体越来越多，每个变体都排得更差，头部词从前 5 掉到十几、二十几名。

这个问题，任何一个关键词都暴露不出来。

2. 收录控制：canonical、状态码、sitemap

URL 空间决定能生成什么，收录控制决定告诉 Google 要什么。

还是 srpsearch 这类页面，canonical 不仅没收口，还会自己改写搜索词：把 massage 改成 massage+london，但不跨路径前缀合并。两条不同前缀的 URL 各自指向两个不同的目标，重复问题原样保留。

另一个常见的坑是过期内容。分类信息站的帖子天天下架，Googlebot 抓帖子页的请求里，超过一半打在已经下架的帖子上。这部分抓取预算本来可以花在新帖子上。下架帖子返回 404、410 还是跳到类目页，看起来是个小决定，但它决定了爬虫的时间花在哪。

3. 渲染输出：服务端直出的 HTML 里有什么

我们做过一次帖子页和店铺页的 H 标签审计，抽了一百多个页面，对比服务端直出的 HTML 和浏览器渲染后的 DOM。

结论对开发很有用。两者一致，说明问题出在服务端组件本身。不用讨论客户端渲染，也不用上预渲染，直接改服务端组件就行，需求范围一下子清楚了。

SEO 交给开发的需求，最好能精确到这个程度：改哪个组件，改完之后服务端 HTML 里应该出现什么。

4. 抓取预算：爬虫的时间花在哪

大站一定要看爬虫日志，而且要先把日志洗干净。

我们第一次拉 Googlebot 日志时，所有 UA 里带 Google 的请求加起来，有接近四成是 AdsBot。它是广告质量检查的爬虫，跟自然搜索的抓取无关。不剔除的话，所有关于抓取预算的判断都是歪的。

洗干净之后能回答的问题很具体：每类页面被抓多少次，抓到的是新页面还是旧页面，多少请求浪费在 404 和重复页上。这些数字可以直接变成开发的优先级。

三、SEO 能帮开发的最大的忙是少做

写到这里，SEO 好像又在给开发派活。其实我觉得 SEO 对开发最有价值的一件事，是告诉开发哪些页面不该存在。

URL 空间收掉一半，影响的不只是排名：

• 爬虫请求少了，服务器压力小了
• 缓存命中率高了
• 需要维护、监控、测试的页面类型少了

这些本来就是开发自己想要的。SEO 不该只是一个提需求的角色，它也可以帮开发团队砍掉不必要的复杂度。

四、需求写成验收条件，不要写成建议

我早期写的需求文档里全是「建议优化」「建议考虑」。开发看了不知道做到什么程度算完。

现在我尽量把 SEO 需求写成可以测试的不变量：

• 这类 URL 的 canonical 必须指向 X 规则生成的地址
• 下架超过 N 天的帖子返回 410
• 服务端 HTML 里每页有且只有一个 H1，内容是 Y 字段
• sitemap 里只出现返回 200 且 canonical 自指的 URL

每一条都能写成自动化检查，放进上线前的回归测试里。SEO 最怕的不是开发不做，而是做完之后某次改版又悄悄改回去了。写成测试，这个问题就解决了一半。

五、SEO 在网站里，到底是顾问还是产品

经常有人问我这个问题。我的回答是：在大站，SEO 应该是产品，但只对一部分东西当产品。

只当顾问，在大站做不成事。 顾问的产出是建议，决定权在别人手里。产品经理背的是转化和留存，SEO 的建议永远是「重要但不紧急」。更糟的是没人对结果负责：自然流量掉了，产品说是按 SEO 建议做的，SEO 说自己只是给建议。上面那个 srpsearch 的问题存在了很久，不是没人看得出来，是没有人负责它。

但也不能什么都当产品。 帖子页首先是给买家和卖家用的，SEO 去定它的功能和交互，既越界，也没那个判断力。

我现在的分工是这样的：

• SEO 说了算的：页面类型清单、URL 规则、canonical、状态码、sitemap、robots，还有纯粹为搜索而生的页面，比如类目×城市落地页。这些 SEO 直接当产品经理，有自己的路线图，自然流量也算在 SEO 头上。
• SEO 给约束的：帖子页、商家页、首页这些核心页面。SEO 规定服务端必须输出什么，功能怎么做由产品决定。
• SEO 守门的：把上面这些约束写成自动检查。

判断自己处在哪个位置，可以问三个问题：

1. 改一条 URL 规则，是需要说服别人，还是你说了算？
2. 有没有研发专门给 SEO 排期，还是只能往产品需求里插队？
3. 如果一次上线把 canonical 改坏了，会不会被自动拦下来？

我自己的情况是：前两个问题，我说了算，也有自己的研发；第三个，现在还拦不住。

有了决定权和研发以后，难点变了。以前是推不动，现在是守不住。我的团队刚把 canonical 修好，别的团队下一次发版可能就给碰坏了。我往往要等几周后，在 Search Console 看到收录数字异常才发现，那时候流量已经掉下去了。大站出一次回归，损失可能比做一个新需求带来的收益还大。

所以我现在在补的就是第三条，先从最小的版本做起：每类页面挑几十个代表 URL，每天检查状态码、canonical、robots、H1、结构化数据，跟前一天比，一有变化就报警。先做到第二天就能发现问题，再把这套检查接进发版流程，检查不过就不让上线。

决定权让你能把事情做成，守门能力让做成的事不被改坏。

六、AI 引用：一个还没验证完的假设

最后说一下现在大家都关心的 AI 搜索引用。

我的假设是：在 AI 引用这件事上，页面类型的作用可能比在传统排名里更大。AI 摘要要从页面里抽取事实，一个结构稳定、字段齐全、有结构化数据的页面类型，比一篇写得好但格式随意的页面更容易被抽出来用。比如商家主页，服务范围、地区、评价、营业时间都是固定字段，天然适合被引用。

但这只是假设。目前公开的「AI 引用因素」研究大多来自工具厂商，样本和方法都不透明，因果关系也没理清。我自己手上的数据还不够下结论。等有了靠谱的观测，我再单独写一篇。

七、附带一个教训：第三方工具的数据要二次验证

写这些案例的过程中，我自己也犯过一次错。

有段时间 Ahrefs 显示某个 /Services/Health 路径在「massage birmingham」这个词上排第 2，而这个 URL 实测返回 404。我当时的结论是「Google 在给一个 404 页面排名，点击全部流失」。

后来用 Search Console 查了一下，Google 根本不认识这个 URL。真实情况是，Google 在搜索结果里用面包屑代替 URL 显示，Ahrefs 把面包屑「Services › Health & Beauty」解析成了一个假地址。排第 2 的其实是正常的类目页。

所以涉及具体 URL 的结论，我现在都会用 Search Console 或实时搜索结果再核一遍。大站数据量大，一个工具的解析错误很容易被放大成一个「重大发现」。

结尾

大站做 SEO，关键词排名是结果，页面类型才是能动手的地方。

如果只能给开发团队留一样东西，我会留一张页面类型清单：每一类页面有多少 URL、该不该被收录、canonical 规则是什么、服务端必须输出哪些字段。SEO 和开发都照着这张表工作，很多争论就不会发生。