Cara Memperbaiki URL «Discovered / Crawled – Currently Not Indexed» dengan DeepSeek Harness

Jalankan pipeline indeksasi Search Console di dalam DeepSeek Harness: batch headless sekali jalan dengan dsh --profile headless, atau sesi web UI interaktif dengan putaran terjadwal mingguan — kedua jalur mengirim daftar melalui Google Indexing API (200 URL/hari)

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

dsh --profile headless "tugas"

dsh web (membuka 127.0.0.1:3080)

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

Diagram keputusan yang membandingkan jalur headless sekali jalan dsh dengan web UI plus putaran terjadwal

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 web jika perlu. Kunci API dan setelan Anda ada di ~/.dsh/ (profiles, sessions, settings.yaml), dan dsh web yang 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 dengan pip install google-auth google-api-python-client.
  • Folder proyek, mis. ~/gsc-indexing-project dengan data/, 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:

bash
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:

bash
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:

bash
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:

bash
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:

bash
0 9 * * 1 cd ~/gsc-indexing-project && dsh --profile headless "Jalankan pemeriksaan indeksasi GSC mingguan dan susun antrean kiriman." >> logs/weekly.log 2>&1
Diagram putaran jadwal mingguan untuk pipeline indeksasi dsh dengan titik berhenti persetujuan manusia

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 JobPosting dan BroadcastEvent. 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.

Jelajahi topik ini

Lanjutkan alur pertumbuhan yang sama