Pillar 页和 cluster 页：Google 和 AI 搜索都偏爱的站点结构

pillar/cluster 不是什么 SEO 黑魔法，它只是一种内容组织方式，正好对上 Google 的 helpful content 系统和 AI 答案引擎判断”这个站到底懂不懂这个主题”的逻辑。做对了，pillar 页能上宽词排名，cluster 页能上长尾排名，它们之间的链接图会告诉爬虫”这个站在这个主题上是有深度的”。多数独立开发者犯的错，是把这个结构装在脑子里，而不是编码进内容 schema——一旦进了 schema，构建脚本就能帮你强制执行。

一句话总结

把 pillar/cluster 当数据维护：在 frontmatter schema 里加一个 pillar 字段，自动生成”本指南包含”列表和”返回 pillar”链接，两个方向都写描述性锚文本，再跑一个审计脚本，标出弱 pillar（cluster 少于 4 个）和孤儿 cluster（pillar 还没发）。5 个强 pillar 胜过 15 个半成品。下面是全部代码。

pillar 页和 cluster 页到底是什么

pillar page 宽泛覆盖一个主题（例如”如何搭一个内容站”）。cluster page 深入覆盖一个子主题（例如”如何向 Search Console 提交 sitemap”）。每个 cluster 向上链到 pillar，pillar 向下链到每个 cluster。Google 读这张链接图，就会判断这个站在这个主题上认真投入过。同样的双向结构也正是 AI 答案引擎在找的东西：截至 2026 年 6 月，ChatGPT、Perplexity、Gemini 和 Google AI Mode 越来越倾向引用主题连贯、互相打通的内容群，而不是孤立的零散文章——因为互相打通的覆盖读起来像真本事，而不是某篇蒙对的文章。

按目前能排上、能被引用的情况，推荐长度：

页面类型	字数（典型）	职责
pillar	2500-4000	高层总览；链到每个 cluster；是该主题的 canonical 权威
cluster	1200-2500	把一个具体问题或一个侧面讲透

长度是参考，不是目标。一个链了 10 篇深度 cluster 的 pillar，不需要把它们再重复一遍；整个 cluster 集合的覆盖度，比 pillar 自己的字数更重要。

怎么判断你已经有这个结构（或者还没有）

• 你能一口气说出站上 top 5-10 个主题簇。
• 每个 pillar 页有 5-15 个 cluster 页指向它。
• 任意 cluster 页距首页不超过 3 次点击。（埋在 4 层以上的页面爬取频率更低，也会被当成不重要。）
• 内链锚文本用的是目标关键词，不是”点这里”或”阅读更多”——通用锚文本几乎传不了任何主题信号。
• 新文章很自然就能归到已有 pillar，不需要手动重排。

如果上面有两条以上不成立，下面的步骤能补上。

开始前准备

• 已经发了至少 20-30 篇可以归类。低于这个量，先写 cluster，pillar 后补。
• 内容 schema 能加一个 pillar 字段。
• 能在 prebuild 里跑个小 Node 脚本审计链接。

实操步骤

1. frontmatter 加 pillar 字段。 扩 Zod schema，让关系变成数据而不是记忆：

// src/content/config.ts
schema: z.object({
  // ...
  pillar: z.string().optional(),    // 此文所属 pillar 的 slug
  isPillar: z.boolean().default(false),
}),

cluster 文章：

---
title: "如何向 Search Console 提交 sitemap"
urlSlug: "submit-sitemap-search-console"
pillar: "submit-website-to-google"
isPillar: false
---

pillar 文章：

---
title: "2026 把新站提交给 Google"
urlSlug: "submit-new-site-to-google-2026"
isPillar: true
---

2. 想 5-10 个 pillar 主题。 每个需要至少 10-20 个候选 cluster，否则太窄。pillar 超过 10 个说明摊得太薄——Google 奖励的是几个主题上的深度，而不是很多主题上的浅尝辄止。

3. 先写 cluster 再写 pillar。 先写 pillar 容易写空。每个 pillar 先发 5-7 篇 cluster，再回头写 pillar。因为难想的部分已经想透了，pillar 会更厚实、更诚实。

4. pillar 的”子文章列表”用程序自动生成。 pillar layout 里，绝不手维护：

---
import { getCollection } from 'astro:content';
const { lang, urlSlug } = Astro.props.article.data;
const clusters = (await getCollection('articles', (a) =>
  a.data.lang === lang && a.data.pillar === urlSlug && !a.data.isPillar
)).sort((a, b) => a.data.title.localeCompare(b.data.title));
---
<h2>本指南包含</h2>
<ul>
  {clusters.map((c) => (
    <li>
      <a href={`/${lang}/articles/${c.data.urlSlug}/`}>{c.data.title}</a>
      <p>{c.data.description}</p>
    </li>
  ))}
</ul>

5. cluster 回链 pillar 也自动渲。 cluster layout 里渲一个”属于”块，免得忘了回链：

---
const { lang, pillar } = Astro.props.article.data;
const p = pillar
  ? (await getEntry('articles', `${lang}/${pillarPath}/${pillar}`))
  : null;
---
{p && (
  <aside class="pillar-up">
    属于：<a href={`/${lang}/articles/${p.data.urlSlug}/`}>{p.data.title}</a>
  </aside>
)}

6. 两个方向的锚文本都要描述性。 pillar → cluster 锚文本描述 cluster 主题；cluster → pillar 锚文本描述 pillar 主题。换着说，别在每条链上重复同一个完全匹配的词。2026 年一个可用的配比（针对同一个目标页）：大约 15-25% 完全匹配关键词、30-40% 部分匹配、其余用语义近义变体。永远别用”点这里""阅读更多”或直接写 slug。

7. 跑 pillar/cluster 审计脚本。 在 Google 发现之前先找出弱 pillar 和孤儿 cluster：

// scripts/audit-pillars.mjs
import { readdirSync, readFileSync } from 'node:fs';
import { join } from 'node:path';
import matter from 'gray-matter';

const byPillar = new Map();
const pillars = new Set();

function walk(dir) {
  for (const f of readdirSync(dir, { withFileTypes: true })) {
    const full = join(dir, f.name);
    if (f.isDirectory()) walk(full);
    else if (f.name.endsWith('.mdx')) {
      const { data } = matter(readFileSync(full, 'utf8'));
      if (data.isPillar) pillars.add(data.urlSlug);
      else if (data.pillar) {
        if (!byPillar.has(data.pillar)) byPillar.set(data.pillar, []);
        byPillar.get(data.pillar).push(data.urlSlug);
      }
    }
  }
}
walk('src/content/articles');

for (const p of pillars) {
  const count = (byPillar.get(p) || []).length;
  if (count < 4) console.warn(`WEAK PILLAR (${count}): ${p}`);
}
for (const [pillar, kids] of byPillar) {
  if (!pillars.has(pillar)) {
    console.warn(`ORPHAN CLUSTERS (no pillar published yet) for "${pillar}": ${kids.join(', ')}`);
  }
}

8. 每季度复盘。 少于 4 条 cluster 链入的 pillar 是弱的。没有 pillar 的孤儿 cluster 需要补 pillar。把脚本接进 prebuild，弱 pillar 会作为构建告警出现，而不是三个月后才发现。

执行检查清单

• schema 包含 pillar + isPillar 字段。
• pillar 页根据 frontmatter 自动渲 cluster 列表，不手维护。
• 每篇 cluster 有 back-link 块。
• 审计脚本接到 prebuild，弱 pillar 和孤儿都会告警。
• 两侧锚文本都描述性、有变化。

怎么验证生效了

权威信号是按月累积的，不是几天的事，所以先看先行指标：

• Search Console → Performance → Pages： pillar URL 在宽关键词上累积曝光，cluster 接住长尾查询。
• 对 cluster 做 URL Inspection： pillar 出现在”Referring page”/ referring URLs 里，说明回链被爬到了。
• Lighthouse → Accessibility →“Links have discernible names”： 全绿说明锚文本是真文字，不是裸图标或空链接。
• 爬取深度： 抽查每篇 cluster 是否在距首页 3 次点击以内可达。

容易踩的坑

• 把 pillar 写成 1 万字大杂烩，什么都讲。 结构化总览 + 链出，胜过把每个子主题都埋进去的一堵墙。
• pillar → cluster 链了，cluster 不回链。 双向链就是整个机制本身；单向链会让 cluster 看着像孤儿。
• 所有链都用同一个锚文本。 用相关词换着说；一模一样的完全匹配锚文本看着像操纵，也加不了新信号。
• pillar 设太多。 5 个强 pillar 永远胜过 15 个半成品。
• cluster 列表硬编码在 pillar 里。 你发下一篇 cluster 那一刻它就老化了。自动生成。
• 把 pillar/cluster 当 URL 结构（/pillar/<x>/cluster/<y>/）。它是逻辑结构，不是 URL 结构。这些页可以全平铺在 /articles/ 下。

FAQ

• pillar 页要多长？ 截至 2026 年 6 月，一般 2500-4000 字，但覆盖度比字数重要。链了 10 篇深度 cluster 的 pillar，不需要再重复它们。
• cluster 之间可以互相链吗？ 可以，相关时就应该链。模式是 hub-and-spoke，但子主题真的相关时，spoke 之间也可以连。
• 需要专门的 /pillar/ URL 结构吗？ 不需要。这是逻辑结构不是 URL 结构。pillar 和 cluster 都可以放在 /articles/ 下。
• pillar 之间有重叠怎么办？ 选一个作为 canonical，把另一个合并掉，或者把范围划窄到不再重叠。两个 pillar 抢同一个宽词，会把权威分散掉。
• 这对 AI 搜索有帮助吗，还是只对 Google？ 有帮助。答案引擎（ChatGPT、Perplexity、Gemini、Google AI Mode）更倾向引用互相打通、主题连贯、署名清晰的页面群，而不是孤立文章，所以同一套结构也能帮你被引用。
• 要加 JSON-LD WebPage about schema 吗？ 可选但有用。pillar 标 WebPage，加 about 指向主题实体，让主题关系在结构化数据里显式表达。

相关阅读

• 如何避免内容重复
• 如何做站内内容审计
• 内容站栏目结构怎么设计
• 长尾关键词网站怎么规划
• 新站先做内容广度还是深度

外部参考：Google Search Central 内链最佳实践 与 Search Engine Land 的 topic clusters 指南。

标签: #独立开发 #内容运营 #SEO #建站策划 #Pillar / Cluster #Technical SEO

相关文章

独立开发 / 建站指南

内容站季度复盘节奏：真能发现问题

一份 4 小时的季度复盘模板，在流量漂移、话题腐化、排名下滑变严重之前把它们抓出来，附具体的 GSC 查询、AI Overview 检查和决策规则（2026 年 6 月）。

2026/05/23 #独立开发 #内容运营

独立开发 / 建站指南

内容站招人：写手、编辑、运营什么时候招

内容站在 1 人、2 人、3 人、5 人各阶段需要哪些角色，附 2026 年自由写手、编辑、VA 的真实报价，告诉你下一个人招在哪里才解瓶颈，而不是徒增工资。

2026/05/23 #独立开发 #内容运营

独立开发 / 建站指南

内容站快速扩量时怎么避免内容重复：在 Google 之前先发现自己的重复页

站点过几百篇之后，内容重复会悄悄把收录拖死。用脚本化流程在 Google 发现之前先把重复页揪出来——附真实的 embedding 成本和 Search Console 信号。

2026/05/15 #独立开发 #内容运营

独立开发 / 建站指南

内容站文章数量与质量怎么平衡

数量买覆盖，质量买排名。用 Search Console 数据驱动的决策流程，加上构建期强制的质量下限，每月判断该投哪边。

2026/05/15 #独立开发 #内容运营

独立开发 / 建站指南

内容站过 1000 篇怎么管：一套脚本优先的实操手册

过 1000 篇要靠脚本，不靠意志力。生成式内容索引、重复扫描、内链检查、加上 Search Console 退役货架流程，附 2026 年最新 API 限额。

2026/05/15 #独立开发 #内容运营

独立开发 / 建站指南

新内容站的前 30 天：一份能让你被收录的计划

一份具体的新站 30 天计划：在 Search Console 拿到收录、锁死 URL 结构、写满 15-20 篇成簇的文章，并跳过现在不必管的事。

2026/05/15 #独立开发 #内容运营