标签太多生成大量薄归档页(阈值 + 治理修法)

800 个 tag、600 个只有 1-2 篇 = 600 个 Google 不肯收录的薄归档页。设每标签最少文章阈值、合并近义词、其余 noindex 并移出 sitemap。

两年来编辑随意加 tag(「看起来有用!」),结果你有了 800 个 tag。其中 600 个各只有一两篇文章,而每个 tag 都生成自己的归档页。于是你现在有约 600 个只列一篇文章的归档页——比它指向的文章本身还薄。在 Google Search Console(Indexing -> Pages)里它们堆在 Crawled - currently not indexed 和 Discovered - currently not indexed 下,Googlebot 还会反复重爬它们,而不是去爬你真正的文章。

最快修法: 任何文章数低于某个下限的 tag(阈值 >= 5 是合理默认)就别生成公开页;然后对已经进了索引的薄 tag 页加 noindex 并把它们从 sitemap 移除。tag 当 metadata 没问题——tag 当 公开页 就需要阈值,否则成薄内容工厂。下面这套完整流程:设阈值、用 301 合并近义词、给残留的加 noindex 并移出 sitemap、再加治理让 tag 增殖不再发生。

有一点变化值得知道(已于 2026 年 6 月核实):noindex, follow 不是 永久状态。一开始 Google 会把 noindex, follow 的页面排除出搜索、同时仍跟随它的链接;但如果 noindex 挂了几个月,Google 就会把它当作 noindex, nofollow 处理,不再跟随那些链接。所以 follow 给你的是一段「可爬通过」的窗口期,而非永久。如果某篇文章的唯一入口就是这个薄 tag 页,那就先修好那篇文章的内链,再给 tag 加 noindex——别指望靠 follow 来一直保住那篇文章的可发现性。

常见原因

按命中率从高到低排列。

1. 无 tag 治理——任何人都能加新 tag

CMS 让任何作者在 frontmatter 里输入新 tag。两个作者同一周写出 ai-coding、ai-programming、code-with-ai——一个概念三个 tag。

如何判断: tag 列表里有明显近义词。跑一遍频率统计(见 Step 1),扫长尾里同一概念的变体。

2. 没有「tag 何时才成公开页」的阈值

每个 tag 不管文章数都成公开页。用过一次的 tag 就成了一个只带一篇文章的页面——比文章本身还薄。

如何判断: Search Console -> Indexing -> Pages,看「Crawled - currently not indexed」里的示例 URL,多数是 tag / 归档路径。或者用 Screaming Frog / Sitebulb 爬一遍按字数排序——tag 页都聚在最底部。

3. 没有合并 / 清理流程

tag 不断累积,没东西去修剪。两年后一半已休眠或是近义词,但每个还在生成页面。

如何判断: 看你 tag registry 或规范化脚本的 git log。「12+ 个月没编辑」就说明没有清理流程。

4. tag 同时充当 topic、子主题和关键词

ai、ai-coding、claude-code-tutorials、setting-up-claude、claude-setup——单看每个都说得通,但它们高度重叠,而且每个都是一个独立 tag 页。

如何判断: 挑一个 tag,看有多少其他 tag 跟它共享大部分文章。重叠高就说明没有清晰区分,归档页彼此近似重复。

5. 自动生成的 tag 页毫无编辑内容

tag 页只是「标签为 X 的文章」加一个列表——没有 intro、没有 curation、没有编辑点评。空模板加一篇文章就等于薄。

如何判断: 看 tag 页源码。如果全是模板套话、文章数 <= 2,那按定义就是薄页。

6. tag URL 因大小写 / 格式差异而增殖

/tag/AI、/tag/ai、/tag/AI-coding、/tag/ai-coding——大小写敏感的路由或不一致的规范化,会从一个概念造出多个重复 tag 页。

如何判断: 爬一遍找仅大小写或分隔符不同的 tag URL。如果两个都返回 200,规范化就坏了。

你属于哪一类

Search Console / 爬虫里的症状最可能的原因去看
频率列表里大量近义词 tag无治理(1)Step 3 + Step 5
几百个单篇文章的 tag 页无阈值(2)Step 2
tag 列表只增不减无清理(3)Step 3 + Step 5
同一批文章挂在很多重叠 tag 下tag = 主题 + 关键词(4)Step 3
tag 页除了文章列表没别的文字空模板(5)Step 2(砍掉)或做成 hub
/tag/AI 和 /tag/ai 都返回 200大小写 / 格式重复(6)在 schema 层规范化(预防)

最短修复路径

按收益从高到低。Step 1 审计;Step 2-4 减少;Step 5-6 锁定并衡量。

Step 1:审计 tag 分布

# 统计整个内容树里每个 tag 的文章数
grep -rh "^tags:" src/content/articles/en \
  | tr ',' '\n' \
  | sed 's/^[" ]*//;s/["]*$//' \
  | sort | uniq -c | sort -nr

输出是 数量 tag,从高到低。每个低于阈值(如 < 5)的 tag 都是「从公开页里去掉」的候选。把这份列表存下来——它是 Step 2 和 Step 3 的输入。

Step 2:设公开页阈值

在 tag 页生成器里,只有 tag 达到阈值时才生成路由:

// src/pages/tag/[slug].astro
export async function getStaticPaths() {
  const articles = await getCollection("articles");
  const tagCounts = countTags(articles);

  return Object.entries(tagCounts)
    .filter(([, count]) => count >= 5)   // 只生成 >= 5 篇的 tag
    .map(([slug]) => ({ params: { slug }, props: { /* ... */ } }));
}

低于阈值的 tag 仍然保留在文章 frontmatter 里(作为内部 metadata、以及相关文章逻辑的依据有用),但不再生成可爬取的页面。怎么定这个数字:>= 5 是稳妥默认;文章偏短就提到 >= 8-10;只有当每个 tag 页本身还带有真正的编辑文字时,才降到 >= 3。

Step 3:合并近义词

ai-coding     <- ai-programming, code-with-ai, ai-code
claude-setup  <- setting-up-claude, claude-installation

每个合并:

  1. 选定 canonical tag(用得最多、名字最清晰、最贴近用户实际搜索的写法)。
  2. 把每篇文章的 frontmatter 都改成用 canonical tag。
  3. 把旧 tag URL 用 301 重定向到 canonical tag URL(这样任何外链以及 Google 对旧 URL 的记忆都会转移过去)。
  4. 确认 canonical tag 页现在列出了合并后的全部文章。

重跑 Step 1 后,canonical tag 应该已经吸收了你合并掉的所有变体的文章数。

Step 4:给已索引的薄 tag 页加 noindex

对于 Google 已经爬过、但现在低于阈值(或无法合并)的 tag 页,在模板里加 robots meta 标签:

<!-- tag 页模板,articleCount < 5 时 -->
<meta name="robots" content="noindex, follow" />

有三点能让它真正生效——全部对照 Google 当前文档核实过(2026 年 6 月):

  • 该页 不能 在 robots.txt 里被屏蔽。如果 Googlebot 抓不到它,就永远看不到 noindex,URL 反而会一直留在索引里。让它能被爬、读到 tag、然后把页面剔除。
  • 把这些 URL 从 XML sitemap 里移除。 一个被 noindex 的 URL 还列在 sitemap 里是矛盾信号,会浪费 crawl budget;sitemap 里应只放 canonical、可索引的 URL。
  • follow 是临时的。一开始 Google 会跟随链接,但挂了几个月的 noindex 最终会被当作 noindex, nofollow。如果某个薄 tag 页是通往某篇文章的唯一路径,请在加 noindex 之前,先从 hub 或相关文章区块给那篇文章补一条真正的内链。

如果你已经把某个 tag 从生成器里彻底删掉了,那就给它的 URL 返回 410 Gone——这表示永久移除,Google 会比对 404 更快地把它丢掉。

Step 5:加 tag 治理

在 repo 里建一份 curated 允许列表:

// src/lib/allowed-tags.ts
export const ALLOWED_TAGS = [
  "ai", "ai-coding", "claude", "claude-code", "chatgpt", "cursor",
  "openai-api", "anthropic-api", "prompt-engineering",
  // ... 共约 50 个
] as const;

然后加一个 CI check(或在 prebuild 里跑的 content:audit 脚本),当文章用了 ALLOWED_TAGS 之外的 tag 时让构建失败。这就强制在任何新 tag——以及任何新 tag 页——出现之前,先有一次 code review 的对话。

Step 6:等重爬并衡量

重爬不是即时的。对活跃站点,Google 通常会在两到四周内重新访问并重新判断;大批 tag 页可能更久。在 Search Console -> Indexing -> Pages 里跟踪这几项:

  • 已索引 tag 页数 应随薄页被剔除而下降。
  • Crawled - currently not indexed 这一桶应该缩小(里面多数本来就是你的薄 tag 页)。
  • 收回的 crawl budget 应表现为新文章被收录得更快——盯几篇近期文章的 time-to-index。

如何确认已修复

  1. 生成器: 跑一次生产构建,在产物里 grep tag 路由。低于阈值的 tag 应该不再生成 /tag/<slug>/ 文件。
  2. 线上响应头: 对 https://yoursite.com/tag/<thin-tag>/ 跑 curl -I 并抓一次 HTML,应看到要么 410,要么 200 且 <head> 里含 <meta name="robots" content="noindex, follow">。
  3. sitemap: 打开 sitemap.xml(或 tag sitemap),确认没有任何被 noindex 的 tag URL 还列在里面。
  4. Search Console: 对某个曾经的薄 tag URL 用 URL Inspection,它应报告 “noindex detected” / “Excluded by ‘noindex’ tag”,说明 Google 已看到并遵从该指令。
  5. 趋势计数: 接下来几周里,Pages 报告的已索引数和「Crawled - currently not indexed」数应持续下降。

常见问答

给 600 个 tag 页加 noindex 会伤排名吗? 不会,恰恰相反。那些页本来就没在排名——它们只是稀释站点质量、浪费 crawl budget。移除薄的、近似重复的归档页,反而把爬取和质量信号集中到真正在排名的文章上。

noindex 还是 410,该用哪个? 保留 tag 页、但暂时想让它能被爬通去到它的链接 -> 用 noindex, follow。tag 已彻底删掉、URL 也该消失 -> 用 410 Gone。410 更干净、去索引更快,但只有当这个 tag 在生成器里确实不复存在时才用。

为什么不直接在 robots.txt 里屏蔽 tag 页? 因为 robots.txt 屏蔽的是 爬取,不是 索引。一个 Google 已经知道的被屏蔽 URL 可能继续留在索引里(常表现为一个没有描述的 URL),而 Googlebot 永远看不到你的 noindex 去把它剔除。要移除就允许爬取、用 noindex;robots.txt 留给那些你压根不想被抓取的 URL。

noindex, follow 会一直传递链接权重吗? 不会。Google 一开始会跟随链接,但长期挂着的 noindex 最终会被当作 noindex, nofollow,那些链接就不再计入。别把被 noindex 的 tag 页当成永久的内链层——重要文章要直接从 hub 链过去。

小站点该用什么阈值? 如果你有几百篇文章,每个 tag >= 5 比较合理。少于约 100 篇:考虑 >= 3,或者干脆不做公开 tag 页,先靠分类页加内链,等内容深度够了再让 tag 页真正有用。

Search Console 多久才反映出变化? 活跃站点通常两到四周内 Google 会重爬并重新判断;大批 tag 页可能要一个月以上。别在 URL Inspection 里批量提交它们——让自然重爬去捡。

预防建议

  • 在代码里维护一份 curated ALLOWED_TAGS 列表;引入新 tag 必须走 code review。
  • 公开 tag 页保留最少文章阈值(如 >= 5),其余只作 metadata。
  • 在 schema 层规范化 tag 格式(小写、kebab-case),让大小写 / 格式重复无从产生。
  • 每季度重跑一次 Step 1 审计,在近义词积累之前就合并。
  • 高价值 tag(>= 10 篇),把 tag 页当 hub 对待:加编辑 intro 和精选排序,让它配得上一个索引位。
  • 把被 noindex 和非 canonical 的 URL 排除在 XML sitemap 之外。
  • 约 50 个 curated tag 加强力 tag 页,胜过 800 个 tag 加一堆薄页。

相关阅读

标签: #内容运营 #站点质量 #站点审计 #排查 #标签页