DeepSeek Harness(dsh)能运行真正做事的 agent，而很少有 SEO 工作比未索引 URL 流程更适合它: 读清单、检查每个 URL、分类、等核准、提交、验证。每个阶段都是命令或文件，正是 harness agent 擅长的事。
两个问题决定你怎么设置。你想要可以脚本化、丢进 cron 的一次性批次吗? 用 headless 跑。你想看着它运行、回答它的提问、在聊天窗口逐批核准吗? 用 Web UI。这份指南两条路都讲，底层的流程对两者都一样。如果想深入了解「Discovered – currently not indexed」与「Crawled – currently not indexed」的含义和判读方法，我们在 Hermes Agent 版的这份流程 中详细讲过; 这里聚焦 dsh 的执行。
选择你的路径
Headless 一次性 | Web UI + 排程 | |
|---|---|---|
最适合 | 脚本化批次、cron、CI 风格执行、测试 | 交互式判断、初次设置、学习 agent 会做什么决定 |
启动 |
|
|
核准 | 文件中的预先核准清单; 规则需要人时，agent 用它的提问工具问 | 在聊天中直接问，逐批核准 |
排程 | cron(或如果你的 profile 加载了 Schedule 插件，用 dsh 的排程工具) | 一样，但每次执行都看得到 |
输出 | 项目文件夹中的报告文件 | 报告文件加聊天记录 |
批次用 headless、首次执行用 Web UI，底层流程相同。
两条路共享一个规则: 写入步骤(提交到 Google)保持在人工核准关卡之后。headless 模式意味着你先审核 agent 产生的文件，才让它执行提交命令; Web 模式则在聊天中核准。
完成后你会得到
一个 indexing/ 项目文件夹，内含: URL 清单、分类好的清单(to-submit.txt、skip.txt、needs-fix.txt)、核准的提交队列、执行记录。每次执行 dsh 会产生一份简短报告: 提交几个、跳过几个与原因、和上次相比的变化。第一次设置 60–90 分钟(大部分时间花在 Google 端凭据)，每周执行 15 分钟。
开始之前
- 已安装并设置 dsh。 需要时用
npx @deepseek-ai/dsh@latest web更新到当前版本。你的 API 密钥和设置放在~/.dsh/(profiles、sessions、settings.yaml)，dsh web能跑或 headless 任务成功就算安装确认。 - 你拥有所有权的 GSC 资源，使用
sc-domain:example.com格式。 - 读取凭据: 用于 Search Console API 的 OAuth 客户端(客户端 ID + 密钥)。
- 写入凭据: 已启用 Indexing API 的 Google Cloud 项目、服务账号 JSON 密钥，并把服务账号 email 加为 GSC → 设置 → 用户和权限下的所有者。提交时 403 表示这一步失败。
- 工作区中的两个 GSC 脚本文件夹: 读取技能(sitemap、搜索分析、URL 检查)和索引技能(
index_submit.py)。Python 3 与pip install google-auth google-api-python-client。 - 项目文件夹，例如
~/gsc-indexing-project，内含data/、scripts/、logs/。
Google 端的设置对任何 agent 都一样，gsc-indexing 技能的说明文档会带你走完 Cloud Console 步骤: 启用 Indexing API、创建服务账号、下载密钥、加为所有者。
路径 A: 一次性的 headless 执行
Headless 模式是 dsh --profile headless "任务": 一个任务、一个答案、结束。可以把整个流程放进一个提示词，或边调试边分几次执行。
第一次执行(在项目文件夹):
dsh --profile headless "执行 GSC 索引流程的第一阶段。用 gsc_query.py 脚本列出 sc-domain:example.com 的 sitemap，抓取所有含 lastmod 的 URL，去重后写入 data/url-inventory.csv。汇报总数。"什么是好的输出: 一份真实的 CSV，总数与 GSC 的 sitemap 报表相符，没有编造出来的字段。质量检查: 打开文件抽查五个 URL。如果 agent 汇报认证错误，重新执行 GSC OAuth 流程再试; 读取脚本需要新的 token。
第二阶段:
dsh --profile headless "用 URL Inspection API 检查 data/url-inventory.csv 中的 URL，分成 data/to-submit.txt、data/skip.txt(附一行理由)和 data/needs-fix.txt。只包含 lastmod 在最近 90 天内的 URL。"agent 会分批执行检查脚本(API 每个资源有速率限制; 在 Google Cloud Console 查看当前配额)。检查分割结果: 跳过清单应该以 noindex、canonical 指向他处、重复页面为主。如果几千个 URL 的网站却跑出空的 needs-fix，就加宽输入时间范围。
第三阶段是核准关卡，绝对不无人执行:
dsh --profile headless "读取 data/needs-fix.txt 和 data/skip.txt。把修复与提交队列做成表格: URL、推定原因(没有内部链接、重复、canonical、noindex、太薄、软 404)、证据、建议动作、风险等级。不要提交任何东西。"在报告中审核表格，把 data/to-submit.txt 编辑成只含你核准的 URL，然后执行第四阶段:
dsh --profile headless "用索引脚本提交 data/approved-urls.txt 中的 URL(index_submit.py submit --urls-file data/approved-urls.txt)。先执行 check-auth。把每个结果记到 logs/submissions.log。"预期输出: 每个 URL 一行通知结果，没有 403。恢复路径: 403 表示服务账号不是资源的所有者; 429 表示你碰到了每天 200 个或每分钟 600 次的配额，把清单分天提交。如果执行中途挂掉，dsh --profile headless --resume <session> 可以接续。
路径 B: Web UI 加每周排程
dsh web 在 127.0.0.1:3080 打开浏览器 UI。用聊天执行同样的阶段，但改为交互式: agent 会请你确认分类清单，执行提交命令前再确认一次。这个即时核准流程是初次设置选择这条路的主要原因: 在它对你的 Google 资源动手之前，你会先看到它要做什么。
流程能跑之后，加上节奏。dsh 的 Schedule 插件注册了 schedule_create，会在线上对话内以计时器重复执行任务:
schedule_create: every 7 days, run "Inspect data/url-inventory.csv, classify new and changed URLs, and draft the submission queue. Do not submit."
如果 profile 没有加载 Schedule 插件，同样的结果可以用一行 cron 包住 headless 命令:
0 9 * * 1 cd ~/gsc-indexing-project && dsh --profile headless "执行每周 GSC 索引检查并草拟提交队列。" >> logs/weekly.log 2>&1
排程只跑前三站; 提交保留在人工关卡。
不要把提交步骤放进排程。每周的检查、分类、队列草拟可以无人执行，提交则等一个人。
agent 套用的判断规则
分类和队列依赖一张小表格，你应该把它放在项目文件夹，让每次执行都用同一套规则:
原因 | 修复 | 修复后提交? |
|---|---|---|
页面没有任何内部链接 | 从已收录的相关页面加入有上下文的链接 | 是 |
全新页面 | 不用修; 提交一次，等 1–2 周 | 是，一次 |
被 robots.txt 屏蔽 | 解除路径屏蔽 | 是 |
重复或太薄的内容 | 重写、合并或删除 | 只有真正改变之后 |
canonical 指向他处 | 错就修正; 故意的话放弃这个 URL | 只有修正之后 |
抓取时有 noindex | 移除 noindex | 移除之后，是 |
软 404、存档、没有价值的 faceted 页面 | 修正或删除; 永久跳过 | 否 |
这两个状态的深入判读(包括 Google 为什么抓某些页面不抓其他的)在 Hermes Agent 指南 中。原因与哪个 harness 执行流程无关。
验证，然后等待
每批提交后，用 status 确认通知: 那只能证明 Google 有它的元数据，不代表页面已收录。三到七天后重新检查提交的 URL 并比较状态。健康的模式是一两周内 discovered → crawled → indexed。GSC 数据会延迟几天，Google 也按自己的时间表重新抓取，所以修复后 10–14 天仍停在「Crawled – currently not indexed」的 URL 是内容质量的裁决，不是提交的问题。记录文件让这一切可见: 日期、URL、通知类型、下次执行时的检查状态。这才是衡量标准: 未收录清单应该随时间缩小，而不是通知次数增加。
诚实的边界
- Indexing API 官方文档只涵盖
JobPosting与BroadcastEvent页面。把一般页面送过去是常见做法，但 Google 对每个页面类型都不提供保证，也没有支持承诺。 - Search Console 的「请求编入索引」按钮没有公开 API。Indexing API 是最接近的脚本化管道，不是按钮的复制品。
- 自动化不会创造优先级。页面在你修复并提交后仍未收录，下一步是内容工作，而不是再跑一次排程。
常见问题
可以完全不用 Web UI、只跑 headless 模式吗?可以。dsh --profile headless "任务" 执行一个任务就结束; 凭据仍放在 ~/.dsh/，读取脚本照常运行。先用 Web UI 端到端验证一次流程，再脚本化。
执行中途挂掉，工作会丢失吗?不会。用 dsh --profile headless --resume <session> 接续，再重新执行提交脚本; 它会去重相同 URL，所以同一批中已通知过的 URL 重发无害。
我管理多个 GSC 资源，每个网站都要重来一遍吗?脚本接受 --site sc-domain:... 参数，所以一个工作区可以放多个资源的清单与记录。每个资源保留一个核准队列文件、一个提交命令，一个网站的配额错误就不会卡住其他网站。
作者: Camille Rhodes，Auspia 300+ AI 内容工作流的架构师。撰写关于内容自动化、发布系统，以及把 AI agent 变成可靠增长运营的工作流。
