DeepSeek Harness (dsh) menjalankan agent yang bisa melakukan pekerjaan nyata, dan sedikit pekerjaan SEO yang lebih cocok untuknya daripada pipeline URL belum terindeks: baca daftar, periksa setiap URL, klasifikasi, tunggu persetujuan, kirim, verifikasi. Setiap tahap adalah perintah atau file — persis wilayah yang dikuasai agent harness.
Dua pertanyaan menentukan cara Anda mengaturnya. Ingin batch sekali jalan yang bisa diskrip dan dimasukkan ke cron? Jalankan headless. Ingin menontonnya bekerja, menjawab pertanyaannya, dan menyetujui setiap batch di jendela obrolan? Gunakan web UI. Panduan ini menunjukkan kedua jalur, dan pipeline di bawahnya sama untuk keduanya. Jika Anda ingin penjelasan mendalam tentang arti «Discovered – currently not indexed» dan «Crawled – currently not indexed» serta cara membacanya, kami bahas di versi Hermes Agent dari alur kerja ini; di sini kami fokus pada eksekusi lewat dsh.
Pilih jalur Anda
Headless sekali jalan | Web UI + jadwal | |
|---|---|---|
Paling cocok untuk | Batch berskrip, cron, jalan gaya CI, pengujian | Triage interaktif, pengaturan pertama kali, mempelajari keputusan agent |
Mulai |
|
|
Persetujuan | Daftar yang sudah disetujui di file; agent bertanya lewat alat pertanyaannya saat aturan membutuhkan manusia | Bertanya langsung di obrolan, setujui per batch |
Penjadwalan | cron (atau alat jadwal dsh jika profil Anda memuat plugin Schedule) | Sama, tapi Anda melihat setiap jalan |
Keluaran | File laporan di folder proyek | File laporan plus transkrip obrolan |

Headless untuk batch, web UI untuk jalan pertama — pipeline di bawahnya sama.
Kedua jalur berbagi satu aturan: langkah tulis (mengirim ke Google) tetap di belakang gerbang persetujuan manusia. Dalam mode headless itu berarti Anda meninjau file yang dibuat agent sebelum membiarkannya menjalankan perintah kirim; dalam mode web Anda menyetujui di obrolan.
Yang Anda dapatkan
Folder proyek indexing/ yang berisi: inventaris URL, daftar terklasifikasi (to-submit.txt, skip.txt, needs-fix.txt), antrean kiriman yang disetujui, dan catatan jalan. Setiap jalan dsh menghasilkan laporan singkat: berapa yang dikirim, berapa yang dilewati dan mengapa, dan apa yang berubah sejak terakhir. Pengaturan pertama kali memakan 60–90 menit (sebagian besar kredensial sisi Google); jalan mingguan memakan 15 menit.
Sebelum mulai
- dsh terpasang dan dikonfigurasi. Perbarui ke rilis saat ini dengan
npx @deepseek-ai/dsh@latest webjika perlu. Kunci API dan setelan Anda ada di~/.dsh/(profiles, sessions,settings.yaml), dandsh webyang berfungsi atau tugas headless yang berhasil mengonfirmasi pemasangan. - Properti GSC yang Anda miliki, dalam format
sc-domain:example.com. - Kredensial baca: klien OAuth untuk Search Console API (client ID + secret) untuk skrip baca.
- Kredensial tulis: proyek Google Cloud dengan Indexing API diaktifkan, kunci JSON service account, dan email service account ditambahkan sebagai Owner di GSC → Setelan → Pengguna dan izin. 403 saat pengiriman berarti langkah ini gagal.
- Dua folder skrip GSC di workspace Anda: skill baca (sitemaps, analitik pencarian, pemeriksaan URL) dan skill indeksasi (
index_submit.py). Python 3 denganpip install google-auth google-api-python-client. - Folder proyek, mis.
~/gsc-indexing-projectdengandata/,scripts/,logs/.
Pengaturan sisi Google identik untuk setiap agent, dan dokumentasi skill gsc-indexing memandu Anda melalui langkah Cloud Console: aktifkan Indexing API, buat service account, unduh kunci, tambahkan sebagai Owner.
Jalur A: jalan headless sekali pakai
Mode headless adalah dsh --profile headless "tugas": satu tugas, satu jawaban, keluar. Taruh seluruh pipeline dalam satu perintah, atau tahapkan di beberapa jalan sambil men-debug.
Jalan pertama, dari folder proyek:
dsh --profile headless "Jalankan tahap 1 dari pipeline indeksasi GSC. Daftarkan sitemap untuk sc-domain:example.com menggunakan skrip gsc_query.py, ambil setiap URL dengan lastmod, hilangkan duplikat, dan tulis data/url-inventory.csv. Laporkan jumlah total."Seperti apa keluaran yang baik: CSV asli dengan jumlah yang cocok dengan laporan sitemap GSC, dan tanpa kolom karangan. Pemeriksaan kualitas: buka file dan cek lima URL acak. Jika agent melaporkan kesalahan autentikasi, jalankan ulang alur OAuth GSC dan coba lagi; skrip baca membutuhkan token baru.
Tahap 2:
dsh --profile headless "Periksa URL di data/url-inventory.csv melalui URL Inspection API dan bagi menjadi data/to-submit.txt, data/skip.txt (dengan alasan satu baris), dan data/needs-fix.txt. Hanya sertakan URL dengan lastmod dalam 90 hari terakhir."Agent menjalankan skrip pemeriksaan secara berkelompok (API dibatasi kecepatan per properti; periksa kuota Anda saat ini di Google Cloud Console). Periksa kewajaran pembagian: daftar lewati harus didominasi halaman noindex, canonical-away, dan duplikat. Jika situs dengan ribuan URL menghasilkan daftar needs-fix kosong, perlebar jendela input.
Tahap 3 adalah gerbang persetujuan, dan tidak pernah berjalan tanpa pengawasan:
dsh --profile headless "Baca data/needs-fix.txt dan data/skip.txt. Susun antrean perbaikan-dan-kirim sebagai tabel: URL, dugaan penyebab (tanpa tautan internal, duplikat, canonical, noindex, tipis, soft 404), bukti, tindakan yang diusulkan, tingkat risiko. Jangan kirim apa pun."Anda meninjau tabel dalam laporan yang dicetaknya, edit data/to-submit.txt agar hanya berisi URL yang Anda setujui, lalu jalankan tahap 4:
dsh --profile headless "Kirim URL di data/approved-urls.txt melalui skrip indeksasi (index_submit.py submit --urls-file data/approved-urls.txt). Gunakan check-auth dulu. Catat setiap hasil ke logs/submissions.log."Keluaran yang diharapkan: satu baris hasil notifikasi per URL, tanpa 403. Jalur pemulihan: 403 berarti service account bukan Owner properti; 429 berarti Anda kena kuota 200-per-hari atau 600-per-menit; bagi daftar ke beberapa hari. Jika jalan mati di tengah, dsh --profile headless --resume <session> melanjutkannya.
Jalur B: web UI plus jadwal mingguan
dsh web membuka UI browser di 127.0.0.1:3080. Obrolan melalui tahap yang sama, tapi interaktif: agent meminta Anda mengonfirmasi daftar terklasifikasi sebelum menyusun antrean, dan sekali lagi sebelum menjalankan perintah kirim. Alur persetujuan langsung itu adalah alasan utama memilih jalur ini saat pengaturan pertama: Anda melihat apa yang akan dilakukan agent terhadap properti Google Anda sebelum ia melakukannya.
Setelah pipeline berfungsi, tambahkan irama. Plugin Schedule di dsh mendaftarkan schedule_create, yang menjalankan ulang tugas pada pengatur waktu di dalam sesi langsung:
schedule_create: every 7 days, run "Inspect data/url-inventory.csv, classify new and changed URLs, and draft the submission queue. Do not submit."
Jika profil Anda tidak memuat plugin Schedule, hasil yang sama adalah baris cron yang membungkus perintah headless:
0 9 * * 1 cd ~/gsc-indexing-project && dsh --profile headless "Jalankan pemeriksaan indeksasi GSC mingguan dan susun antrean kiriman." >> logs/weekly.log 2>&1
Jadwal menjalankan tiga perhentian pertama; pengiriman tetap di belakang gerbang manusia.
Jauhkan langkah kirim dari jadwal. Pemeriksaan mingguan, klasifikasi, dan penyusunan antrean bisa berjalan tanpa pengawasan; pengiriman menunggu manusia.
Aturan triage yang diterapkan agent
Klasifikasi dan antrean bergantung pada tabel kecil, dan Anda harus menaruhnya di folder proyek agar setiap jalan memakai aturan yang sama:
Penyebab | Perbaikan | Kirim setelah diperbaiki? |
|---|---|---|
Tidak ada tautan internal ke halaman | Tambahkan tautan kontekstual dari halaman terindeks | Ya |
Halaman baru sama sekali | Tidak ada yang diperbaiki; kirim sekali, tunggu 1–2 minggu | Ya, sekali |
Diblokir robots.txt | Buka blokir jalur | Ya |
Konten duplikat atau tipis | Tulis ulang, gabungkan, atau hapus | Hanya setelah perubahan nyata |
Canonical mengarah ke tempat lain | Perbaiki jika salah; jika disengaja, buang URL | Hanya jika diperbaiki |
noindex saat perayapan | Hapus noindex | Ya, setelah dihapus |
soft 404, arsip, facet tanpa nilai | Perbaiki atau hapus; lewati permanen | Tidak |
Pembacaan lebih dalam tentang dua status, termasuk mengapa Google merayapi sebagian halaman dan tidak yang lain, ada di panduan Hermes Agent. Penyebabnya sama tidak peduli harness mana yang menjalankan pipeline.
Verifikasi, lalu tunggu
Setelah setiap batch, konfirmasi notifikasi dengan status: itu hanya membuktikan Google punya metadata untuknya, bukan bahwa halaman terindeks. Tiga sampai tujuh hari kemudian, periksa ulang URL yang dikirim dan bandingkan statusnya. Pola sehatnya adalah discovered → crawled → indexed dalam satu-dua minggu. Data GSC tertunda beberapa hari, dan Google merayapi ulang sesuai jadwalnya sendiri, jadi URL yang masih macet di «Crawled – currently not indexed» setelah 10–14 hari dengan perbaikan nyata di belakangnya adalah vonis kualitas konten, bukan masalah pengiriman. File catatan adalah tempat hal ini terlihat: tanggal, URL, jenis notifikasi, dan status pemeriksaan di jalan berikutnya. Itu juga pengukurannya: daftar belum terindeks harus menyusut seiring waktu, bukan jumlah notifikasi yang bertambah.
Batasan yang jujur
- Indexing API didokumentasikan resmi untuk halaman
JobPostingdanBroadcastEvent. Mengirim halaman biasa melewatinya adalah praktik umum, tapi Google tidak memberi jaminan dan tidak menawarkan janji dukungan untuk setiap jenis halaman. - Tidak ada API publik untuk tombol «Request indexing» di Search Console. Indexing API adalah saluran yang bisa diskrip terdekat, bukan replika tombol.
- Otomatisasi tidak menciptakan prioritas. Jika halaman tetap belum terindeks setelah Anda memperbaiki dan mengirimnya, langkah berikutnya adalah pekerjaan konten, bukan jalan terjadwal lagi.
FAQ
Bisakah saya menjalankan mode headless tanpa web UI sama sekali? Bisa. dsh --profile headless "tugas" menjalankan satu tugas dan keluar; kredensial tetap di ~/.dsh/, dan skrip baca bekerja sama. Gunakan web UI sekali untuk memverifikasi pipeline dari ujung ke ujung, lalu skripkan.
Jalan mati di tengah batch. Apakah saya kehilangan pekerjaan? Tidak. Lanjutkan dengan dsh --profile headless --resume <session>, dan jalankan ulang skrip kirim; ia menghilangkan duplikat URL, jadi mengirim ulang URL yang sudah dinotifikasi di batch yang sama tidak berbahaya.
Saya mengelola beberapa properti GSC. Apakah saya mengulang semuanya per situs? Skrip menerima argumen --site sc-domain:..., jadi satu workspace bisa menampung inventaris dan catatan beberapa properti. Simpan satu file antrean yang disetujui dan satu perintah kirim per properti, agar kesalahan kuota di satu situs tidak pernah memblokir yang lain.
Penulis: Camille Rhodes, Arsitek 300+ Alur Kerja Konten AI di Auspia. Camille menulis tentang otomatisasi konten, sistem penerbitan, dan alur kerja yang mengubah agent AI menjadi operasi pertumbuhan yang andal.












