「Discovered – currently not indexed」和「Crawled – currently not indexed」是 Search Console 的「网页编入索引」报表中最常见的两行，也是最常被误解的两行。它们看起来像技术失败，但实际上是 Google 对你的页面做出的优先级与质量判断。更用力地提交不会改变结果，修复原因才会。
这份指南是你可以整个交给 Hermes Agent 的完整流程: 抓取 URL 清单、检查每个页面、判断真正的原因、核准修复队列、只把值得收录的页面通过 Google Indexing API 提交。完成后，你拥有的是每周可重复的流程，而不是一次性狂点按钮的会议。
完成后你会得到
- 分类好的清单: 卡在 discovered 的 URL、已抓取但未收录的 URL、以及一开始就不该提交的 URL
- 已提交至 Indexing API 的核准清单，以及附理由的跳过清单
- 验证步骤，显示你的提交是否真的有效
你需要的前置条件: 已安装且能运行的 Hermes Agent(hermes chat 开启对话。最新安装步骤见官方文档 hermes-agent.nousresearch.com/docs)、一个你拥有所有权的 Search Console 资源、以及两套 Google 凭据(一套读取 GSC、一套用于 Indexing API)。第一次设置约 60–90 分钟，之后每周执行约 15 分钟。「完成」的定义: 你提交的 URL 在两周内在检查 API 中出现真实的状态变化，或你有明确证据说明为什么不会变。
正确解读这两个状态
Google 不是卡在你的网站上。它做了决定，而状态会告诉你这是哪种决定。
状态 | 实际含义 | 常见原因 | 何时提交 |
|---|---|---|---|
Discovered – currently not indexed | Google 知道 URL 存在(从 sitemap 或链接)，但还没抓取 | 抓取优先级低、内部链接薄弱或没有、大型网站的抓取预算压力、全新网站、又慢又重的 JS 渲染、sitemap 频繁变动 | 改善优先级信号(主要是内部链接)之后，提交一次 |
Crawled – currently not indexed | Google 抓取了 URL，但决定不加入索引 | 重复或近似重复内容、内容太薄、canonical 指向其他 URL、抓取时存在 noindex、软 404、被判定价值偏低 | 只有在你真的改变了东西之后: 内容、canonical 或 noindex |
Indexed | 已在索引中 | — | 不要提交 |
Excluded | 已抓取且刻意排除(noindex、canonical、重复选择、屏蔽) | — | 不要提交; 确认排除是否为刻意安排 |
一句话总结: 只提交你实际改过、或值得再看一次的 URL。Indexing API 是通知管道，不是排名覆盖器。把内容太薄的页面提交 10 次，得到的还是同一个判断 10 次。
为什么要交给 agent 跑
GSC 的「请求编入索引」按钮没有公开 API，所以没有官方方法可以用脚本按它。最接近的自动化是 Google Indexing API，它直接接受 URL 通知。Agent 在这里有价值的理由有三个:
- 流程机械又冗长: 清单 → 检查 → 分类 → 修复 → 提交 → 验证。每周重复。
- 需要审计轨迹: 你需要一个文件记录哪些 URL 在何时、为何被提交。
- 需要核准关卡: 写入 Google 的部分应该由人类审核。Hermes 正是围绕这个分工设计的，具备技能、项目文件夹与核准规则。
开始前需要什么
- Hermes Agent 已安装。继续之前先用
hermes chat确认。 - 你拥有所有权的 GSC 资源。使用
sc-domain:example.com格式(不是完整网址)。 - 读取权限: 用于 Search Console API 的 Google Cloud OAuth 客户端(客户端 ID + 密钥)。GSC 技能脚本用它列出 sitemap、跑搜索分析、检查 URL。
- 写入权限: 已启用 Indexing API 的 Google Cloud 项目和服务账号 JSON 密钥。把服务账号 email 加入 GSC → 设置 → 用户和权限的所有者。如果提交返回 403，就是漏了这一步。
- Python 3 与
pip install google-auth google-api-python-client。 - 项目文件夹。例如
/hermes-seo-project，里面有context/、data/、qa/，以及一份规定提交步骤永远需要人工签核的approval-rules.md。
步骤 1: 建立 URL 清单
把两个 GSC 技能复制到 Hermes 的技能目录(~/.hermes/skills): 读取技能(sitemap、搜索分析、URL 检查)和索引技能(提交脚本)。如果 harness 已把技能编目，也可以用 skill_view 加载。
然后在项目文件夹的聊天会话中请 Hermes 执行:
列出 sc-domain:example.com 的所有 sitemap，抓取每个 URL 及其 lastmod，写入 data/url-inventory.csv。任何抓取失败的 sitemap 都要标记。
Hermes 会通过 terminal 工具执行 sitemap 命令并写出 CSV。什么是好的输出: 一份去重的 CSV，包含 URL、lastmod、来源 sitemap。质量检查: 抽查五行，并把总数与 GSC 的 sitemap 报表对照。如果清单是空的或认证失败，重新跑一次 GSC 认证流程; 读取脚本需要新的 OAuth token。
步骤 2: 检查与分类
接着，agent 会通过 URL Inspection API 批量检查清单，取得每个页面当前的覆盖状态。请它执行下一阶段:
检查 data/url-inventory.csv 中的每个 URL。分成三个文件: data/to-submit.txt(未收录且值得提交)、data/skip.txt(每个 URL 附一行理由)、data/needs-fix.txt(未收录且卡在我们能改的东西上)。
检查 API 每个资源有速率限制(在 Google Cloud Console 查看当前配额; 每天数千次但不是无限)。大型网站请把这一轮限定在 lastmod 最新、也就是你这季度真的改过的 URL。质量检查: 抽样跳过清单。大部分应该是 noindex、指向其他 URL 的 canonical、重复页面，而不是你在意的页面。如果几千个 URL 的网站却得到空的 needs-fix，可能是清单阶段漏了页面，请扩大输入范围。
步骤 3: 提交前先判断
这是大家最常跳过的一步。把卡住的 URL 对应到原因与修复，按这个顺序:
原因 | 修复 | 修复后提交? |
|---|---|---|
页面没有任何内部链接 | 从相关的已收录页面加入有上下文的链接 | 是 |
全新网站或页面 | 不用修; 提交一次，等 1–2 周 | 是，一次就好 |
被 robots.txt 屏蔽 | 解除该路径的屏蔽 | 是 |
已抓取但重复或太薄 | 重写、合并或删除 | 只有真正改过内容之后 |
canonical 指向其他 URL | 错的话修正 canonical; 故意的话停止提交这个 URL | 只有修正之后 |
抓取时有 noindex | 移除 noindex 让 Google 重新抓取 | 移除之后，是 |
软 404、没有价值的分页/存档 | 修正页面或删除 | 否 — 永久跳过 |
请 Hermes 把修复队列做成表格: URL、推定原因、证据(检查结果或内容检查)、建议动作、风险等级。在聊天中逐行核准。你的 approval-rules.md 应该把这条定成硬规则: agent 准备、你核准、超过低风险的一律要签核才能提交。
核准关卡把 agent 的准备工作和写入步骤分开。
修复本身是一般的 SEO 工作: 重写内容、清理 canonical、内部链接。这套流程负责的是提交那一半; 修复那一半由 Hermes 系列的审计与刷新文章负责。
提交清单是「可修复」与「值得收录」的交集。
步骤 4: 通过 Indexing API 提交
队列核准后，把 URL 放进 data/approved-urls.txt，让 Hermes 执行索引技能:
python3 ~/.hermes/skills/gsc-indexing/scripts/index_submit.py check-auth
python3 ~/.hermes/skills/gsc-indexing/scripts/index_submit.py submit --urls-file data/approved-urls.txt默认通知类型是 URL_UPDATED，适合新页面或变更的页面。三个数字要记住: 默认配额是每天 200 个 URL、每分钟 600 次请求; 而 403 代表服务账号不是资源的所有者。核准清单超过 200 个就分成多天提交，剩下的批次可以让 Hermes 排程。
绝不要提交已收录的页面，也绝不要提交跳过清单。浪费的通知只会烧掉配额和制造噪音。
步骤 5: 验证，然后等待
提交后的 status 只告诉你 Google 有没有这笔通知的元数据，不代表页面已收录。真正的确认在几天之后。
批次提交 3–7 天后，请 Hermes:
再次检查 data/approved-urls.txt 中的 URL，并汇报与上次执行相比的状态变化。
健康的进展是 discovered → crawled → indexed。几周内看起来会是这样: 未收录清单缩小，你实际做的修复(新的内部链接、重写的内容)出现在索引中。记得 GSC 数据会延迟几天，Google 也会按自己的时间表重新抓取。修复后 10–14 天仍停在「Crawled – currently not indexed」的 URL 是质量信号，不是提交的问题，把它升级回内容工作处理。
让流程持续运行
把流程变成每周例行公事: 上次以来新增或更新的 URL → 检查 → 分类 → 判断 → 核准 → 提交 → 记录。Hermes 可以让只读部分(清单、检查、分类)按排程无人执行，每个星期一把队列呈给你。提交步骤保留在核准关卡内，并在 qa/indexing-log.md 持续记录: 提交日期、URL、通知类型、结果。六个月的记录是衡量流程是否有效唯一诚实的方法。
诚实的边界
- Google 把 Indexing API 的文档范围限定在带有
JobPosting或BroadcastEvent结构化数据的页面。把它用在一般页面是广为流传的 SEO 做法，但 Google 不保证每个页面类型都会收录或提供支持。 - 「请求编入索引」按钮没有公开 API。Indexing API 是最接近的自动化，但不是同一个按钮。
- 提交不会创造优先级。如果页面在你修复、提交、等待之后仍未收录，下一个答案是内容质量，而不是再一次通知。
常见问题
Indexing API 可以用在一般页面吗?它接受你提交的任何 URL。Google 官方文档把它限定在 JobPosting 和 BroadcastEvent 页面，所以把一般页面的提交当作尽力而为: 有帮助、很常见、但永远不保证。
提交之后为什么还是「Discovered – currently not indexed」?这个状态通常代表抓取优先级，而不是失败。检查指向该页面的内部链接、robots.txt 是否屏蔽路径、页面是否重度依赖 JavaScript。然后等待: 新网站的发现到抓取可能耗时一两周。
每天 200 个 URL 够吗?对大多数网站够，因为你本来就只该提交真正改过的 URL。如果经常有更多，就按商业价值排序，并在 Google Cloud Console 申请提高配额。
Indexing API 会让排名变快吗?不会。它只是通知 Google URL 变了。排名是另一套判断，由 Google 的系统决定，跟你的通知次数无关。
这跟按 Search Console 的「请求编入索引」有什么不同?意图相同，机制不同。按钮是纯 UI、没有公开 API; Indexing API 是可以脚本化的管道。两者都不能覆盖 Google 对页面该不该进索引的判断。
作者: Julian Mercer，Auspia 技术 SEO 从业者，14 年资历。撰写关于可抓取性、索引建立、结构化数据，以及让 Google 和 AI 系统都能正确读懂网站所需的技术基础。
