最快的修法： 导出每个 URL 的字数和 90 天展示量，按字数升序排，把字数低于约 500、展示量近 0 的页面逐一打上 expand、merge、noindex 或 410 标签，然后真的把最弱的 20-40% 剪掉。剪本身就是修复：Google 是在站点层级评估质量的，剪掉弱页会抬高所有留下来的页面的门槛。别想着靠「全部扩写」来摆脱困境。
你发了 500+ 页。在 Google Search Console 的 Pages 报告（Indexing -> Pages）里，「Crawled - currently not indexed」 这一桶月月变大。内容审计发现很多页不到 300 字。流量集中在 Top 10% 的文章，剩下 90% 的展示量近乎为 0。首页看起来内容丰富，但 Google 把这个站当成低质站点——因为页面的平均质量太薄。
这件事在 2026 年比以往更要紧。大约从 2026 年 4 月起，Google 提高了对低价值 URL 的去索引（deindex）速度，因为索引膨胀的速度超过了真正有用内容的供给（Search Engine Journal 等多个 SEO 监测都报道了这波激增；Google 的 John Mueller 称这只是「有的站涨有的站跌」的常规清理）。薄页、模板页、AI 流水线页是第一批被剔除的。而按 Mueller 一贯的说法，「Crawled - currently not indexed」往往是整站质量信号，而不是单页 bug——所以修一页很难见效，抬高站点平均才有用。
常见原因
按命中率从高到低排列。
1. 程序化 SEO 页面缺少独有内容
你通过组合列表生成了 200 个「Best X for Y」页面，每个都模板化又稀疏。Google 看到的是模板，不是独有价值。
如何判断： 一批页面 URL 模式相同、字数都挤在 200-400 区间——典型的程序化形状。
2. AI 生成文章全套同一模板
换个来源的同一个问题：AI 流水线文章只够到「最低可接受门槛」，不再往上。每篇技术上「回答」了 query，但没加上任何用户搜不到的东西。
如何判断： 一批 AI 文章字数都聚在同一区间（500-800）、标题结构一样、例子套路一样。这正是 2026 年 Google 去索引最快的内容类型。
3. 另一个内容时代的老短文
2020 年以前的短文（300-500 字），那时算正常、现在算薄——标准升了，老内容没升。
如何判断： publishedAt 在约 2020 年以前、字数 < 600——时代不匹配。
4. 自动生成的 tag / 归档页
（见 Too many tags create thin archive pages。）这些经常混进薄页计数里。
如何判断： tag 页只列了 < 5 篇文章；按日期或作者生成的归档页只有自动内容。
5. 无编辑内容的「链接清单」页
一个「Best tools for X」页只是 10 个名字加一句话描述——页面本身没帮上忙，被链接的目的地才有用。
如何判断： 页面大部分是出站链接加极少解释，独有价值不超过被链页面已经提供的内容。
6. 没有各语言深度的翻译 stub
你机翻了一个 stub，现在它变成了两个语言的 stub，把薄页数量翻了倍。
如何判断： ZH 版字数与 EN 版几乎一致，两边都低于你的深度阈值。
每个页面属于哪一档？
动手之前先分类。真正要看的两个维度是需求（有没有人搜、你现实中能不能排上去）和当前深度。
| 话题需求 | 当前状态 | 处理 |
|---|---|---|
| 有真实搜索量、你能赢 | 薄但可救 | Expand |
| 多个近似重复的切角 | 3-5 篇互相重叠的薄页 | Merge 成一篇深页，其余 301 |
| 内部有用、不该进搜索 | tag/归档/工具页 | Noindex |
| 没需求、没未来用途 | 纯累赘 | 410（或 301 到真正的后继页） |
大多数薄页应该被合并或删除，而不是扩写。「全部扩写」恰恰是这堆东西当初长出来的原因。
最短修复路径
按收益从高到低。Step 1 审计，Step 2 按页决定，Steps 3-6 执行。
Step 1：导出 URL + 字数 + 最后修改时间 + 展示量
拉两份数据，按 URL 拼起来：
# A) 爬自己的站，拿到 URL + 字数 + 最后修改时间。
# 用 Screaming Frog（Word Count 列）、Sitebulb，
# 或对着 sitemap 跑一个自写脚本。
#
# B) 在 Google Search Console -> Performance 里导出最近
# 90 天每个页面的展示/点击（量大就用 Search Console API
# 或 Looker Studio 连接器拿全量）。
#
# 把 A + B 按 URL 拼接，然后：
# - 按字数升序排
# - 标出 字数 < 500 且 90 天展示量 ~ 0 的通常会发现 20-40% 的文章字数低于 500 且没有展示量——这就是薄堆。把它和 Pages 报告里 「Crawled - currently not indexed」 的导出对照一下：重叠很多就说明是质量问题，而不是爬取预算问题。
Step 2：每篇打 expand / merge / noindex / 410
用上面的决策表。要诚实：如果一个话题没有搜索需求、你也不会从强页面链向它，那它就是 merge 或 410，不是 expand。
Step 3：expand——做真深度，不是凑字数
- 看一下该 query 当前排前 3-5 的结果，补上它们覆盖、
你却没有的东西，再加上它们都缺的（原始数据、真实例子、
亲手实测、专家观点）
- 加 3-5 个具体、特定的例子（别用通用模板）
- 加一节「常见 pitfall」
- 加 FAQ，4-6 个卡住的用户真的会搜的问题
- UI 变了就重新截图
- 从一个强、且话题相关的页面加内部链接
（这才是把卡住的页面真正推进索引的动作）
- 重新看长度：一个真正的回答通常 1,200-2,000+ 字凑字数的填充不算修复。Google 的系统专门盯着填充，给薄页加水只会让它既薄又臃肿。
Step 4：merge——把 3-5 篇薄页合成一篇深指南
1. 选合并目标：组内最强的 URL 当 consolidated home
（现有排名 / 外链最好的那个）。
2. 把每篇薄页里最好的 1-2 节并进目标。
3. 其余 URL 301 重定向到目标。
4. 合完后确认目标过了你的深度门槛。5 篇薄页变 1 篇深页，全站平均随之上升。关键：只能 301 到真正相关的目标。301 到不相关的页面（或首页）会被 Google 当成 soft 404，那跟直接留着死链一样糟，甚至更糟。
Step 5：noindex / 410——刻意地执行
对于要留在站内、但要踢出搜索的页面（工具页、tag 页、薄但内部有用的页），用 noindex。Google 在重新爬到带 noindex 的页面后，1-7 天内就会把它从索引里去掉：
<!-- noindex：页面在站内仍可访问，但从搜索里掉出去 -->
<meta name="robots" content="noindex" />对于永久删除，最干净的信号是 HTTP 410 Gone。Google 去掉 410 URL 一般比普通 404 稍快一点（Mueller 说这只是个不大的时间优势，大约快几天）——因为 404 会留在重爬队列里（约 24h、7d、30d、90d 重试一次）以防它回来，而 410 是在说「别再回来了」。不管哪种，Google 都得先重爬到这个 URL 才能看到状态码，所以都不是即时的。
- 删掉 MDX 文件。
- 让该路径真正返回 410（静态托管的坑见下文），
或 301 到相关的后继页——绝不要指向首页。
- 别改成在 robots.txt 里屏蔽这个 URL：被屏蔽 + 曾被索引
常常会显示成 soft 404。静态托管的坑（Firebase / Vercel / Netlify）： 纯静态托管发不出真正的 410。Firebase Hosting 的 redirects 只支持 301 和 302——没有 410 这个 type。截至 2026 年 6 月，你现实的选项是：(a) 提供一个自定义错误页（Firebase 返回的是 404 而非 410——用于删除依然有效，只是比 410 慢）；(b) 用 Cloud Function / Cloud Run / 边缘函数挡在该路径前面，手动把状态置成 410；或 (c) 直接删页让它 404，再在 Search Console 的 Removals 工具（Indexing -> Removals）里临时把它藏起来（约 24h 生效）。Removals 是临时的（约 6 个月），必须配合永久的 404/410/noindex 一起用。
Step 6：4-8 周后重审
在 Search Console -> Pages 和 -> Performance 里盯着：
- 「Crawled - currently not indexed」数量往下走
- 已索引总页数下降（意料之中——你剪了），但
- 留下来的文章平均排名上升
- 幸存页面的展示/点击持平或上升如果这些都往对的方向动，剪对了。如果「Crawled - currently not indexed」没动，那要么剪错了页面、要么剪得不够狠——站点平均还是太低。
如何确认已修好
- 薄堆不再出现在 「Crawled - currently not indexed」 的导出里。
site:yourdomain.com（或 Pages 报告里的「Indexed」计数）下降了，但留下来那些页面的平均排名和总点击持平或上升——这就是「剪对了而不是剪伤了」的信号。- 对已 410 / 删除的 URL：
curl -I https://yoursite.com/old-url/返回410（或404），URL Inspection 工具显示「URL is not on Google」且没有 soft-404 警告。
预防建议
- 设一个真正的发布门槛：要看深度和独特性，不只是字数下限。一篇 1,500 字、却只是复述前排结果的页面，依然是薄页。
- 把季度内容审计排进团队日历——薄页会在两次上线之间静悄悄地堆起来。
- 给程序化页和 AI 流水线页真正的每页独有内容（原始数据、真实例子），否则就别发；这些是 2026 年最先被去索引的。
- 永远别把死页 301 到首页。要么 410/404，要么 301 到话题后继页。
- 别为了凑长度灌水。灌水可被检测，也抬不高质量。
常见问题
剪页面会不会伤流量？ 剪掉薄的、展示量近 0 的页面几乎不会损失有意义的流量，因为它们本来就没流量。风险在于剪错——删之前一定先看 90 天展示量；只要有一点流量或外链的，就用合并（301 到相关页）而不是直接删。
删页用 410 还是 404？ 内容彻底没了就用 410——Google 去掉它一般稍快一点（按 Mueller 的说法大约快几天）。URL 可能用同一 slug 回来就用 404。如果你的静态托管发不出 410，404 也行，只是清得慢一些。
薄页该 noindex 还是直接删？
如果页面在站内还有用途（内部导航、tag 聚合、工具页）但不该进搜索竞争，就 noindex。如果完全没用途，就删（410）。别对一个你其实想让它排名的页面 noindex——那应该去修或合并它。
为什么某一个明明不错的页面一直卡在「Crawled - currently not indexed」？ 这个状态常常是对整站质量的判定，而不是对那一个 URL 的评价。Google 会给平均质量低的站点上的页面降权。剪掉薄堆、再从强页面给它加内部链接，比单独改那个卡住的页面更有用。
到底是薄页拖累了其余，还是只是正常的索引延迟？ 如果新页能正常进索引、只有老 / 模板页被排除，那就是质量问题。如果所有页面都收录得慢，那可能是爬取预算或确实是个新站——动手剪之前先看 When an indexing delay is normal。