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 變成可靠成長營運的工作流程。
