为什么有些页面被收录，却几乎没有展示？

收录和展示之间隔着"排名"这一层。页面进了索引，只是说 Google 认为它值得存着；它出现不出现在结果里，取决于排在第几位。排在第 5 页之后的页面，展示数会低到看起来像没收录一样——而 Search Console 的效果报告默认只统计有展示的查询，你要是不主动按页面筛，很容易误判成"Google 没抓"。

定位方法就一步：在效果报告里按页面过滤，看"平均排名"那一列。平均排名 60 和展示数 0，指向的是完全不同的两类问题。

排名靠后的那一批，先查是不是被自己人挤掉了

3000 页的站里，最常见的不是"竞争不过外站"，是站内有两个页面抢同一个查询。两个页面各拿一半权重，都排在 40 名开外，加起来的展示还不如合并之后一个页面拿得多。

查法很直接：Search Console 的查询报告里点开一个查询，看下面的"网页"列表。如果一个查询下面挂了两三个 URL，这就是内耗。处理办法是合并加 301，不要靠微调标题去区分——Google 已经明确表达了它更希望一个意图对应一个页面。

canonical 写反了，页面就变成别人的影子

第二高频原因是 <link rel="canonical">。程序化站特别容易在这里出错：模板里 canonical 自动生成，逻辑写成了"指向同类型第一个页面"或者"指向去掉参数的版本"，结果成百上千个页面集体指向首页。

这批页面会被完整抓取、可能也会被收录，但永远不会获得展示——因为 Google 认为它们只是另一个 URL 的副本。判据是在页面源码里搜 canonical，确认它指向自己。这一条应该在构建脚本里做成断言，输出前校验，而不是靠上线后抽查。

多语言变体互相抢，是整批塌方

Omni Calculator 有 30 多种语言版本，这种规模的国际化站，hreflang 一旦写错，损失是整批的。

Omni Calculator 首页把 Math 做成了最大的入口，688 个计算器全在这一格后面。

规则里最容易错的有两条。一是必须互相回指：中文页要声明英文页，英文页也必须声明中文页，单向声明会被忽略。二是每组变体里必须包含自己：/zh/foo 的 hreflang 集合里得有指向 /zh/foo 自己的那一条，漏了整组失效。

失效的后果不是"多语言不生效"这么温和——同一内容的多个语言版本会变成互相竞争的重复页面，全部被压到很后面的位置，展示数一起掉到接近 0。声明的三种投放位置（HTML head、HTTP 头、sitemap）和取值规则在 Google Search Central 的国际化部分。

还有一类：页面本身没问题，是这个查询没有搜索量

排查时容易漏掉的一种情况是——页面写得很好、canonical 正确、没有重复变体，展示数依然是 0，因为这个查询根本没人搜。

程序化生成的站特别容易中招。按参数组合生成页面时，米→光年 这种组合在技术上完全成立、页面也完整，但没有人会搜。它在索引里安静地待着，展示数永远是 0，而且拉低整站的"有展示页面占比"。

判据是回过头查关键词工具：这一页的目标查询有没有量。没有量就合并或下线，别因为它"也是个有效组合"就留着。

结构化数据缺失，让你在结果页里少了一整块面积

展示数低还有一类原因不是排名问题，是点击机会问题。页面排在第 8 位，但结果页上它只是一行蓝色链接，而旁边第 9 位的页面带着星级和折叠问答块。

对每个页面补一条 JSON-LD 是最划算的改动。工具页用 WebApplication，带计算说明的可以给 FAQPage，教程页用 TechArticle。要注意类型不能乱套——给一个纯工具页标 Article，属于标记了页面上不存在的内容，反而会丢掉富媒体资格。分类型的模板在 JSON-LD 里。

URL 层面还有一个隐蔽杀手

同一个页面能通过多个地址访问——带不带结尾斜杠、大小写不同、带不带 index.html——这些重复地址会各自被抓取，权重被摊薄到几个副本上，每一个都排不上去。

在 Nginx 层统一掉是最省事的做法：定好规范形式，把非规范形式全部 301 过去。全站只用小写、结尾斜杠策略一致。这条规则要在第一天就定死，后期改会牵动大量已收录 URL，期间的波动往往比问题本身还大。

一批页面展示数为 0 时，按上面四条的先后顺序查，通常十分钟能定位到具体是哪一条，比反复改正文有用得多。

Omni Calculator 30+ 语言、2026 年 6 月访问约 1429 万（Semrush 估算）。