DeepSeek Harness(dsh)は実際の作業ができるエージェントを実行します。そして、未インデックス URL パイプラインほどこれに適した SEO 業務はほとんどありません: リストを読み、各 URL を検査し、分類し、承認を待ち、送信し、検証する。どの段階もコマンドかファイルであり、まさにハーネスエージェントが得意とするものです。
セットアップを左右するのは 2 つの質問です。スクリプト化して cron に置けるワンショットバッチが欲しいなら、ヘッドレスで実行します。動く様子を見ながら質問に答え、バッチごとにチャットで承認したいなら、Web UI を使います。このガイドでは両方のパスを示します。下にあるパイプラインはどちらも同じです。2 つのステータスの深い解説(Google がなぜ一部のページをクロールし他をクロールしないのかを含む)は Hermes Agent 版のこのワークフロー で扱いました。ここでは dsh での実行に焦点を当てます。
パスの選択
ヘッドレス・ワンショット | Web UI + スケジュール | |
|---|---|---|
向いている用途 | スクリプト化バッチ、cron、CI 風実行、テスト | 対話型トリアージ、初回セットアップ、エージェントの判断を学ぶ |
起動 |
|
|
承認 | ファイル内の事前承認リスト。ルールに人間が必要な場合、エージェントは質問ツールで聞く | チャットで質問に回答し、バッチごとに承認 |
スケジュール | cron(またはプロファイルが Schedule プラグインを読み込めば dsh のスケジュールツール) | 同じ。ただし毎回の実行が見える |
出力 | プロジェクトフォルダ内のレポートファイル | レポートファイルに加えてチャットのトランスクリプト |
バッチにはヘッドレス、初回実行には Web UI。下のパイプラインは同じ。
両方のパスに共通するルールが 1 つあります: 書き込みステップ(Google への送信)は人間の承認ゲートの後ろに置きます。ヘッドレスモードでは、エージェントが生成したファイルをレビューしてから submit コマンドを実行させる、という形です。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が動作するかヘッドレスタスクが成功すればインストール確認になります。 - 所有する GSC プロパティ。
sc-domain:example.com形式。 - 読み取り認証情報: Search Console API 用の OAuth クライアント(クライアント ID + シークレット)。
- 書き込み認証情報: Indexing API を有効にした Google Cloud プロジェクト、サービスアカウントの JSON キー、そしてサービスアカウントのメールアドレスを GSC → 設定 → ユーザーと権限でオーナーとして追加。送信で 403 が返る場合はこのステップが失敗しています。
- ワークスペースに 2 つの GSC スクリプトフォルダ: 読み取りスキル(サイトマップ、サーチアナリティクス、URL 検査)とインデックススキル(
index_submit.py)。Python 3 とpip install google-auth google-api-python-client。 - プロジェクトフォルダ。例:
~/gsc-indexing-projectにdata/、scripts/、logs/。
Google 側のセットアップはどのエージェントでも同じで、gsc-indexing スキルのドキュメントが Cloud Console の手順を説明しています: Indexing API の有効化、サービスアカウントの作成、キーのダウンロード、オーナーとしての追加。
パス A: ワンショットのヘッドレス実行
ヘッドレスモードは dsh --profile headless "タスク": 1 つのタスク、1 つの答え、終了。パイプライン全体を 1 つのプロンプトにまとめるか、デバッグしながら数回の実行に分けます。
初回実行(プロジェクトフォルダから):
dsh --profile headless "GSC インデックスパイプラインのステージ 1 を実行してください。gsc_query.py スクリプトで sc-domain:example.com のサイトマップを一覧し、lastmod 付きのすべての URL を取得して重複を除き、data/url-inventory.csv に書き出してください。総数を報告してください。"良い出力の目安: 実在する CSV で、GSC のサイトマップレポートと一致する件数があり、でっち上げの列がないこと。品質チェック: ファイルを開いて 5 URL をスポットチェックします。エージェントが認証エラーを報告したら、GSC の OAuth フローをやり直して再実行します。読み取りスクリプトには新しいトークンが必要です。
ステージ 2:
dsh --profile headless "data/url-inventory.csv の URL を URL Inspection API で検査し、data/to-submit.txt、data/skip.txt(1 行の理由付き)、data/needs-fix.txt に分割してください。lastmod が直近 90 日以内の URL だけを含めてください。"エージェントは検査スクリプトをバッチで実行します(API はプロパティごとにレート制限あり。現在の割り当て量は Google Cloud Console で確認)。分割結果を確認します: スキップリストは noindex、canonical 逸脱、重複ページが大半であるべきです。数千 URL のサイトで needs-fix が空になるなら、入力ウィンドウを広げます。
ステージ 3 は承認ゲートで、無人実行は絶対にしません:
dsh --profile headless "data/needs-fix.txt と data/skip.txt を読んでください。修正・送信キューを表でドラフトしてください: URL、推定原因(内部リンクなし、重複、canonical、noindex、薄い、ソフト 404)、証拠、提案アクション、リスクレベル。何も送信しないでください。"表示されるレポートで表をレビューし、data/to-submit.txt を承認した URL だけに編集してからステージ 4 を実行します:
dsh --profile headless "data/approved-urls.txt の URL をインデックススクリプトで送信してください(index_submit.py submit --urls-file data/approved-urls.txt)。最初に check-auth を実行してください。すべての結果を logs/submissions.log に記録してください。"期待される出力: URL ごとに通知結果が 1 行、403 なし。復旧パス: 403 はサービスアカウントがプロパティのオーナーでないこと、429 は 1 日 200 または 1 分 600 の割り当てに達したことを意味します。リストを日を分けて送信します。途中で死んだ場合は dsh --profile headless --resume <session> で再開します。
パス B: Web UI と週次スケジュール
dsh web はブラウザ UI を 127.0.0.1:3080 に開きます。同じステージをチャットで、ただし対話的に行います: エージェントは分類リストの確認を求め、submit コマンドの実行前にもう一度確認します。このライブ承認フローが、初回セットアップでこのパスを選ぶ主な理由です。あなたの 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."
プロファイルが Schedule プラグインを読み込まない場合も、同じ結果を cron で実現できます。ヘッドレスコマンドをラップする 1 行です:
0 9 * * 1 cd ~/gsc-indexing-project && dsh --profile headless "週次の GSC インデックス検査を実行し、送信キューをドラフトしてください。" >> logs/weekly.log 2>&1
スケジュールは最初の 3 つの停止点を回し、送信は人間のゲートの内側に留まる。
送信ステップはスケジュールに含めないでください。週次の検査、分類、キュードラフトは無人で実行できますが、送信は人間を待ちます。
エージェントが適用するトリアージルール
分類とキューは小さな表に依存します。すべての実行が同じルールを使うよう、プロジェクトフォルダに置くべきです:
原因 | 修正 | 修正後に送信するか |
|---|---|---|
内部リンクが 1 本もない | インデックス済みページから文脈のあるリンクを追加 | はい |
真新しいページ | 修正不要。一度送信して 1–2 週間待つ | はい、一度だけ |
robots.txt でブロック | パスをブロック解除 | はい |
重複または薄いコンテンツ | 書き直す、統合する、または削除 | 実際に変更した場合のみ |
canonical が他を指している | 間違いなら修正。意図的なら URL を落とす | 修正した場合のみ |
クロール時に noindex | noindex を外す | 外した後、はい |
ソフト 404、アーカイブ、価値のないファセット | 修正するか削除。恒久的にスキップ | いいえ |
2 つのステータスの深い読み方(Google がなぜ一部のページをクロールし他をクロールしないのかを含む)は Hermes Agent ガイド にあります。原因はどのハーネスがパイプラインを実行しても同じです。
検証して、待つ
各バッチの後、status で通知を確認します。それは Google が URL のメタデータを持っていることを示すだけで、ページがインデックスされたことを示しません。3–7 日後、送信した URL を再検査して状態を比較します。健全なパターンは 1–2 週間で discovered → crawled → indexed です。GSC のデータは数日遅れ、Google は独自のスケジュールで再クロールするため、本物の修正の後 10–14 日「Crawled – currently not indexed」のままの URL は、送信の問題ではなくコンテンツ品質の判断です。ログファイルでこれが見えます: 日付、URL、通知タイプ、次回実行時の検査状態。それこそが測定です: 通知件数の増加ではなく、未インデックスリストが時間とともに縮小すること。
正直な限界
- Indexing API は公式には
JobPostingとBroadcastEventのページ向けに文書化されています。通常ページの送信は広く行われている手法ですが、Google はすべてのページタイプについて保証もサポート約束もしていません。 - Search Console の「インデックス登録をリクエスト」ボタンには公開 API がありません。Indexing API は最も近いスクリプト化チャネルであり、ボタンの複製ではありません。
- 自動化は優先度を作りません。修正して送信しても未インデックスのままなら、次の手はコンテンツ作業であり、もう一度のスケジュール実行ではありません。
FAQ
Web UI なしでヘッドレスモードだけで実行できますか?できます。dsh --profile headless "タスク" は 1 タスクを実行して終了します。認証情報は引き続き ~/.dsh/ にあり、読み取りスクリプトも同じように動きます。パイプラインを一度 Web UI で確認してからスクリプト化してください。
実行が途中で死んだら、作業は失われますか?いいえ。dsh --profile headless --resume <session> で再開し、送信スクリプトを再実行します。重複 URL は除外されるため、同じバッチで通知済みの URL を再送信しても害はありません。
複数の GSC プロパティを管理しています。サイトごとにすべて繰り返すのですか?スクリプトは --site sc-domain:... 引数を受け取るため、1 つのワークスペースで複数プロパティのインベントリとログを管理できます。プロパティごとに承認キュー 1 つ、送信コマンド 1 つを維持します。あるサイトの割り当てエラーが他をブロックしません。
著者: Camille Rhodes、Auspia で 300 以上の AI コンテンツワークフローを設計してきたアーキテクト。コンテンツ自動化、パブリッシングシステム、AI エージェントを信頼できる成長オペレーションに変えるワークフローについて執筆。
