一句话先说结论： 如果某个 URL 卡在 Search Console 的 Crawled - currently not indexed，说明 Google 已经读过这页，并且主动决定不收录它，最常见的原因就是内容深度不够。最快的修法：打开最薄的那一篇，补上至少三个它现在缺的具体元素（一张真实截图、一个对比表格、一段命令/配置、一个具体数字、一条第一手结果），然后走 URL Inspection -> Request Indexing。重新抓取通常 2-5 天内发生，是否收录的判定可能要 1-4 周。别一次性批量提交——Search Console 对每个资源每天的手动请求大约只放行 10-12 个（截至 2026 年 6 月）。
“深度”不等于“长”。300 字的精彩短文也能排名，1500 字的泛泛而谈则不行。Google 判的是 information gain（信息增量）：这页有没有别处找不到的东西？2026 年 3 月核心更新之后，这个信号成了内容质量的主导评判项——拥有原创数据的站点可见度大约 +22%，而 AI 改写的页面流量大约掉了 71%（SE Ranking，2026 年 3 月更新后）。下面是判定标准和修复闭环。
先确认你到底是哪种状态
下面这两个在 Page indexing 报告里（Search Console 左侧导航 -> Indexing -> Pages）长得很像，含义却不同：
| 状态 | 含义 | 该怎么办 |
|---|---|---|
Discovered - currently not indexed | Google 知道有这个 URL，但还没抓取 | 多半是抓取预算 / 内链问题，不是深度问题。补内链、提交 sitemap。 |
Crawled - currently not indexed | Google 抓过了，但选择不收录 | 几乎都是内容质量 / 深度 / 重复问题。本文针对这个。 |
如果你是第二种，继续往下看；如果是第一种，你的问题在“被发现”，不在“深度”。
常见原因
1. 主题页不足约 300 字 / 全是泛泛而谈
300 字以下基本无救——除非是定义型词条（如词典）。常见的薄内容模式：
- “X 的好处” -> 列 5 条都是套话（提升效率、节省时间、增强体验……）
- “如何 X” -> 全是动词不带具体步骤（“使用工具”、“配置设置”）
- “Y 是什么” -> 维基百科开头那段的改写
如何判断： 把你的页面和该关键词搜索结果里前 10 名对比。如果你的内容量不到他们的 30%、且没有他们没有的独特信息，就是深度不够。Google 并没有公布字数目标——业界常用的独有内容下限大约在 600-800 字，但字数只是替代指标，不是目标。
2. 没具体示例 / 数字 / 截图
Google 靠“具体信号”估算信息密度。一篇 1500 字全是抽象描述的文章，弱于一篇 600 字带 3 张截图、2 段代码、1 个表格的文章。
如何判断——数一下渲染后 HTML 里的具体元素：
curl -sL https://yourdomain.com/your-page | grep -coE '<(img|code|pre|table)'
# 结果小于 3 = 太抽象3. 没有第一手 / 独家信息（Information Gain 问题）
这是 2026 年最关键的一条。Google 的 information gain 评分奖励那些相对已收录内容“多出新东西”的页面，2026 年 3 月核心更新把它推成了内容质量的首要杠杆。它直接对应 E-E-A-T 里的第一个 E（Experience，经验）：你亲手跑过，就有别人没有的数据。
会被过滤掉的：
- 维基百科 / 官方文档的改写
- 别的博客文章的 paraphrase（复述）
- AI 直接生成、没有人工 fact-check 也没有第一手结果
能换来收录的：
- 你真的跑过的实验，以及你得到的数字
- 你自己截的工具 / 控制台 / 报错截图
- 你踩过的边界情况和失败案例（这是纯粹的信息增量——没人会去抄一个失败）
- 你的偏好以及理由，而不是“两面都说说”的中立总结
2026 年 3 月更新后被报道的幅度：带专有数据或第一手案例的页面可见度 +15-25%；模板化或改写的内容掉 30-50%；纯 AI 内容农场的页面掉 60-80%（SE Ranking / 行业追踪，2026）。
4. 没回答用户真实想知道的相邻问题
用户搜 “Astro 部署 Vercel” 时，他几乎肯定还想知道：
- 环境变量怎么配？
- build command 怎么改？
- 部署预览（preview deployments）怎么开？
- 域名怎么绑？
只回答标题问题，用户就会跳出去找别的页，这是个负面信号。把明显的后续问题在同一页里答掉。
5. 大量靠 AI 生成、缺人工编辑痕迹
跟“被过滤”相关的 AI 文本特征：
- 段落结构太工整（每段都 3 句、首句总结）
- 用词偏书面化、缺口语连接词
- 没有具体的人称、日期、地点
- 列表不分主次（全 5 条同等长度）
Google 反复强调过：AI 内容不会因为“是 AI 写的”被罚，而是因为缺乏原创性和第一手专业度被罚。两种情况修法一样：注入模型不可能知道的具体细节。
最短修复路径
Step 1：用信号密度脚本扫出薄页
// scripts/audit-depth.mjs
import fg from "fast-glob";
import fs from "node:fs";
import matter from "gray-matter";
const issues = [];
for (const f of fg.sync("src/content/**/*.{md,mdx}")) {
const { content } = matter(fs.readFileSync(f, "utf8"));
const text = content.replace(/```[\s\S]+?```/g, "").replace(/\!\[.*?\]\(.+?\)/g, "");
const words = text.split(/\s+/).filter(Boolean).length;
const images = (content.match(/!\[/g) || []).length;
const codeBlocks = (content.match(/```/g) || []).length / 2;
const tables = (content.match(/^\|/gm) || []).length;
const headings = (content.match(/^##+ /gm) || []).length;
const score = words + images * 100 + codeBlocks * 80 + tables * 50 + headings * 30;
if (words < 600) issues.push(`THIN (${words}w, score ${score}): ${f}`);
if (headings < 3) issues.push(`FLAT (${headings} sections): ${f}`);
if (images + codeBlocks + tables === 0) issues.push(`ABSTRACT (no img/code/table): ${f}`);
}
console.log(issues.join("\n"));跑完按分数从低到高排，先修最差的。再和 Page indexing 报告对照，把精力花在 Google 已经拒收的 URL 上，而不是本来就健康的页面。
Step 2：对每篇薄页做“信号密度注入”
按这个顺序补——凑够三个就停：
- 加 1 张真实截图：自己工具的截图、对比图、流程图。比 stock photo 强很多，因为它是第一手的。
- 加 1 个表格：对比 / 价格 / 时间线 / 步骤。结构化数据 Google 容易解析，也很难泛泛地伪造。
- 加 1 段代码 / 配置 / 命令：showing 胜过 telling。
- 加 1 个具体数字：不要“很多”“许多”，要
127、2.3s、$29/月。 - 加 1 条第一人称结果：“我们 2026 年 3 月试过 X，结果 Y”，包括哪里出了问题。
Step 3：补“相邻问题”段落
从 Google 自带的 “People also ask” 区块（在普通 SERP 里搜你的关键词）或 AnswerThePublic 这类工具里捞真实的后续问题。挑 3-5 个，每个写成一个 H2。这也正是能搭起 Google 看重的“域名级主题权威”的真实深度。
Step 4：用第一段就告诉用户独有价值
差：
本文将为您详细介绍 Astro 部署 Vercel 的完整流程，希望对您有所帮助。好：
2026 年 5 月我把博客从 Netlify 迁到 Vercel，整个过程 17 分钟。这篇文章把那 17 分钟记下来，包括踩的两个坑（环境变量大小写 + build command 默认值错），以及怎么把 cold start 从 800ms 降到 150ms。第一段就定调：这页有具体的、独有的、能用的信息——给读者看，也给 Google 的质量分类器看。
Step 5：砍掉或合并最薄的 20%
不是所有页都能救。走完 Step 1-4 后还是薄的页面，三种处理：
- 合并进一篇更强的 pillar 文章，再把旧 URL
301重定向过去。 - 直接用
410（或404）删掉，并从 sitemap 移除。 - 加
noindex暂留，等有时间再补深。
一堆薄页会拖累整站质量信号，所以做减法其实是在帮你想留的那些页。
Step 6：请求重新抓取，然后等对的时长
打开 URL Inspection（Search Console 顶部搜索框），粘进修好的 URL，点 Request Indexing。几个容易踩坑的点（截至 2026 年 6 月）：
- 手动上限大约是每个资源每天 10-12 个；一旦用满，按钮会灰掉约 24 小时。先修、先提交价值最高的页面。
- Request Indexing 只是排一次重新抓取。重新抓取通常 2-5 天内发生；是否收录的判定可能要 1-4 周，而且从不保证。
- 批量改动时，靠你的 sitemap（重新提交）和内链，而不是猛点这个手动按钮。
如何确认已经修好
修完约 4 周后回看 Page indexing 报告。健康目标：
- 修过的 URL 中，至少 50% 已进入索引（状态变成
Indexed）。 - 整站
Crawled - currently not indexed的总数下降至少 20%。
用 URL Inspection 抽查一个 URL：现在应该显示 “URL is on Google”。如果毫无动静，说明你补的内容还是太抽象——对着前 10 名重新审一遍，再加第一手细节。（一个提醒：Google 在 2025 年 11-12 月出过一次 Page indexing 报告的数据故障，所以如果你哪天看到不合常理的隔夜暴涨，先用 URL Inspection 核对再做反应。）
常见问题
Crawled - currently not indexed 等于被惩罚吗？
不是。它既不是人工处罚（manual action）也不是惩罚，而是一个软性的质量判定——Google 选择不为这页花索引空间。把深度补上、请求重新抓取就行，没有什么可“申诉”的。
一个页面要多少字才能被收录？ 没有硬阈值。字数只是信息量的替代指标，不是目标。300 字以下的页面除非是定义型，否则很难存活；600-800 字的真正独有内容是更稳的底线。一篇具体的 400 字页面强过一篇泛泛的 1500 字页面。
我一周前点了 Request Indexing，什么都没发生，是坏了吗？ 通常没坏。重新抓取一般要 2-5 天，收录判定最长 4 周。反复点不会更快，还会耗掉你的每日配额。先确认线上页面确实变了（用 URL Inspection 里的 “Test live URL”），然后等。
2026 年 AI 写的内容还能被收录吗？ 能，前提是有信息增量。Google 罚的是缺乏原创性和第一手专业度，不是“用了 AI”。一篇你 fact-check 过、又塞进自己截图、数字和失败案例的 AI 初稿照样能收录；一篇复述已有页面的就不行。
我的页面是独有的，却还是没被收录——还能查什么？
检查是否误加了 noindex、canonical 是否指到了别处、是不是没有内链的孤儿页（orphan page），或者你自己站里有近似重复的内容。URL Inspection 的覆盖详情大多会直接点名这些问题。
预防建议
- 写之前先列大纲——8 个以上 H2 通常意味着真的有深度。
- 每篇文章硬规则：至少 1 张截图 + 至少 1 个表格或代码 + 至少 1 个具体数字。
- 第一段必须传达独有信息——你做过 / 用过 / 测过的东西。
- 不写“X 是什么”系列，除非你能给出维基百科没有的细节。
- AI 初稿在发布前必须人工 fact-check + 加第一手经验——信息增量就是从这里来的。