关键词注册表和 GEO 意图注册表用 page_slug 连接后，每页得到一张意图卡：排哪些词+主答哪些问+复述哪些问+明确不答哪些问。叠加产生四象限诊断，其中"有词无问"的页面有排名但永远不被 AI 引用（多数 Pillar 页在这格），"无词有问"的页面零搜索量但被 AI 引用（不该按 SEO 标准砍掉）。

双骨架：把词的地图和问的地图叠在同一张 slug 上

前三篇分别讲了：为什么需要第二张表、这张表长什么样、表里的意图怎么分类。

这篇把它和原来那张表叠起来。叠起来之后会发生一件事——你会立刻看到自己站上有哪些页面是“半个页面”。

连接键：page_slug

两张表的连接方式很简单，因为它们本来就指向同一批页面。

关键词注册表                        GEO 意图注册表
keyword  → page_slug          qid → answer_unit (= page_slug + anchor)
                    ↓                        ↓
                    └──────  page_slug  ─────┘
                                ↓
                    这一页排什么词 + 答什么问

answer_unit 里的 slug 部分就是连接键，anchor 部分是 GEO 侧独有的精度。

一句话概括叠加之后得到的东西：

一页的完整意图 = 它排的词 + 它答的问。 只有词，是给 Google 看的半个页面；只有问，是给 AI 看的半个页面。

四象限：叠加立刻暴露的两类问题页

把全站页面按“有没有词、有没有问”分到四格里，是这个模块最有诊断价值的一张图。

	有词（注册表里有归属）	无词
有问（是某条意图的主答块）	✅ 健康页	🟡 纯 GEO 页
无问	🟡 纯 SEO 页	❌ 幽灵页

四格的处置完全不同。

🟡 右上：纯 GEO 页——最容易被误杀的一格

这类页面在 GSC 里很难看：搜索量低、曝光少、排名一般。按传统 SEO 的清理逻辑，它是“低价值页面”，该合并或删掉。

但它可能正是被 AI 引用最多的页面。

原因在第一篇讲过：带完整约束条件的提问在关键词工具里显示零搜索量。一个专门回答“60% 硫酸 80°C 该选什么材质”的页面，关键词工具告诉你这个组合没人搜；但它可能每周被 Perplexity 引用好几次，而且引来的是正在做选型的工程师。

处置规则：删页面之前先看 citation_status。GSC 数据不足以判定一个页面的死活——那是只用一只眼睛看站。

🟡 左下：纯 SEO 页——最普遍的一格

这是绝大多数站的大头，尤其是 Pillar 页。

一个典型的品类旗舰页：词很多（centrifugal pump manufacturer、industrial pump supplier、custom pump OEM），排名也不错，流量也有。但你从头到尾读一遍，找不出一个自包含的问答块——全是品类介绍、能力展示、产品列表、公司实力。

这类页面在 AI 搜索里是隐形的。不是因为写得差，是因为它没有任何一块能被 LLM 直接嵌进答案里。RAG 检索时，它的每一个 chunk 都是“某公司介绍自己”，匹配不上任何一个具体问题。

这解释了一个常见困惑：为什么我排名不错的页面，在 AI 里从来没被引用过。

处置规则：不用重写整页，补 2–4 个自包含问答块就够。Pillar 页该补的是 ② 条件选型型和 ③ 权衡型（见上一篇），因为这两类天然是跨型号的，正好属于 Pillar 的层级。

❌ 右下：幽灵页

既没有注册表归属，也不是任何一条意图的主答块。它存在的唯一原因通常是“当年建站时顺手做的”。

处置规则：合并到相关页面或下线。下线要按内链架构的规矩做 301，不要直接删——页面积累的那点权重和外链是资产。

✅ 左上：健康页

词和问都有。应用选型页最容易做到这一格，因为它天然既承接场景长尾词，又能回答具体工况问题。

处置规则：不用动，但要进季度实测集。

页面意图卡

四象限是站级视角。落到单页，叠加的产物是一张意图卡——这也是“让每页意图更清晰”这件事最具体的形态。

┌─ 页面意图卡 ─────────────────────────────────────────────┐
│ /products/cp-100/                        page_type: cluster-sku │
├──────────────────────────────────────────────────────────┤
│ SEO 侧（词）                                              │
│   PKW  CP-100 centrifugal pump specifications             │
│   SKW  cp100 flow rate · cp100 dimensions · cp100 pressure│
│   NKW  manufacturer · supplier · OEM · what is · how does │
├──────────────────────────────────────────────────────────┤
│ GEO 侧（问）                                              │
│   主答  Q-017 最高工作温度        [④验证型]               │
│         └ fact: products.cp-100.temp_max                  │
│         Q-023 能否处理含固颗粒     [④验证型]               │
│         Q-031 是否有 ATEX 认证     [⑤资格合规型]           │
│   复述  Q-004 磁力泵 vs 机封长期成本 [③权衡型]             │
│         └ 主答块在 /blog/mag-drive-vs-seal/#cost          │
│   不答  Q-041 中国最好的泵厂是哪家   [⑥不可自答]           │
│         └ 站外提及，见第 44 篇                             │
├──────────────────────────────────────────────────────────┤
│ 判定                                                      │
│   词问配比 3 词 : 3 主答            ✅ 均衡                │
│   主答块 anchor 均已落地             ✅                    │
│   复述块与主答块首句一致             ✅                    │
│   上次实测 2026-07-12（cited ×2）    ⚠️ 已超 90 天          │
└──────────────────────────────────────────────────────────┘

这张卡不是新增的维护负担。它是把原本散在你脑子里的判断写下来——这一页到底是干什么的、它负责回答什么、哪些问题明确不归它管。

写不出来的那几页，本来就是意图不清的页。 这是意图卡最直接的用处：它把“我说不清这页是干嘛的”从一种模糊的不安，变成一个具体的、可以排期修的问题。

四种页型的词问配比

Pillar-Cluster 拓扑定义的四种页型，在两张表上的分布天然是不均衡的。知道每种页型缺哪一半，补起来才不会乱补。

页型	天然状态	缺什么	该补哪几类意图
Pillar 旗舰页	词多、问少	缺问	② 条件选型型、③ 权衡型（跨型号的问题天然属于品类层）
SKU 详情页	词少、问多	缺词	别硬补词。它的词就该只有型号词，抢品类大词是 Cannibalization
应用选型页	两边都不缺	—	最容易做成健康页，优先做
技术资源页	问多、词中等	缺主答归属	① 定义型、③ 权衡型的主场；但要小心和 SKU 页抢同一个问题

三条容易做错的：

Pillar 页缺问，但不能补 ④ 验证型。 “CP-100 最高多少度”这种问题的主答块该在 SKU 页——Pillar 页答它，等于把品类页做成了型号页，同时违反了注册表 NKW 里“Pillar 页不要过度具体化”的约定。Pillar 页该答的是“这个品类里怎么选”，不是“某个型号是多少”。

SKU 页缺词是正常的，不要补。 看到 SKU 页只有两三个词就想给它加词，是把 GEO 的思路错用到 SEO 侧了。SKU 页的词少是设计使然。

技术资源页最容易抢主答。 一篇“离心泵材质选型指南”会覆盖一堆问题，很容易把本该归应用页的 ② 类问题吃掉。冲突判定规则在下一篇讲。

复述不该靠人复制，该靠渲染

第 74 篇讲了一致复述的三条规矩。落到实现，有一条判断比三条规矩都重要：

改一条标准答案，你要动几个文件？

答案是 1 → 你用架构解决了这件事。答案是 3 → 你在用纪律维持它，迟早失守。

三个页面手抄同一句话，能维持三个月。三个月里会发生：有人在某一页顺手润色了措辞、事实层的数字改了但只改了两处、新来的同事在第四个页面又写了一遍。到时候你不会知道哪一份是准的。

这就是事实层的两种死法里“用架构代替纪律”那条原则，从事实层搬到了答案层——凡是靠“记得同步”维持的一致性，时间长了一定失守。

正确的形态是：canonical_answer 存一处，页面通过组件引用它渲染，复述块不手写。

意图注册表（一处）
  Q-017 canonical_answer: "The CP-100 operates from -20°C to 120°C..."
        ↓ 渲染时注入
  /products/cp-100/#max-operating-temperature        （主答块）
  /applications/chemical-transfer/#temp-limits       （复述块）
  /blog/high-temp-pump-selection/#cp100-range        （复述块）

改一次，三处同时变。具体在 Astro 里怎么接（内容集合 + 组件），收在本模块的工具箱篇，正文不展开。

过渡期怎么办：存量站不可能一次改成渲染式。折中做法是先允许手写，但把一致性对账加进构建流程——手写可以，分叉了必须报错。这个脚本在第 78 篇。

内链的第二重含义

内链架构设计讲了内链的两个作用：自下而上传权重、自上而下分意图。叠加 GEO 之后有第三个。

chunk 被单独提取之后，块里带不带链接，决定 LLM 能不能顺藤摸瓜。

具体场景：一个复述块被检索到了，它给出了一句标准答案，但用户的问题需要更多上下文。如果这个块里有一条指向主答块的链接，AI 搜索引擎（尤其是会做多轮检索的那类）有机会跟过去拿到完整信息；如果没有，这条答案就到此为止。

所以复述块要带回链。 这条规则很具体：

<h3>What is the maximum operating temperature of the CP-100?</h3>
<p>The CP-100 centrifugal pump operates from -20°C to 120°C
(-4°F to 248°F) in its standard configuration.
<a href="/products/cp-100/#max-operating-temperature">Full CP-100
specifications →</a></p>