DeepSeek Harness (dsh), gerçek iş yapan ajanları çalıştırır — ve çok az SEO görevi, dizine alınmamış URL pipeline'ından daha iyi uyar: listeyi oku, her URL'yi kontrol et, sınıflandır, onayı bekle, gönder, doğrula. Her aşama bir komut veya dosyadır — harness ajanlarının yaşadığı alan tam olarak budur.
İki soru yapılandırmanızı belirler. Komut dosyasıyla yazılıp cron'a konabilecek tek seferlik bir parti mi gerekiyor? Headless'a gidin. Her şeyin nasıl çalıştığını görmek, ajanın sorularına yanıt vermek ve partileri sohbette onaylamak mı istiyorsunuz? Web UI kullanın. Bu rehber her iki yolu da gösterir; alttaki pipeline ikisi için de aynıdır. İki durumun derinlemesine açıklaması (Google'ın neden bazı sayfaları tarayıp bazılarını taramadığı dahil) bu sürecin Hermes Agent sürümünde ayrıntılı olarak ele alınmıştır. Burada dsh üzerinden yürütmeye odaklanıyoruz.
Yol seçimi
Tek seferlik headless parti | Web UI + program | |
|---|---|---|
İdeal | Komut dosyalı partiler, cron, CI tarzı çalıştırmalar, testler | Etkileşimli triyaj, ilk kurulum, ajan kararlarını öğrenme |
Başlangıç |
|
|
Onay | Dosyada önceden onaylanmış liste; kurallar insan gerektiriyorsa ajan kendi soru aracıyla sorar | Sohbette canlı sorar, partiyi partiye onaylarsınız |
Program | cron (veya profiliniz Schedule eklentisini yüklüyorsa dsh'in programlama aracı) | Aynısı, ama her çalıştırma görünür |
Çıktı | Proje klasöründe rapor dosyaları | Rapor dosyaları artı sohbet transkripti |
Partiler headless, ilk kurulum Web UI. Aşağıdaki pipeline aynı.
Her iki yol da tek bir kuralı paylaşır: yazma aşaması (Google'a gönderim) insan onay kapısının arkasında kalır. Headless modda bu, ajana gönderim komutlarını çalıştırmasına izin vermeden önce ajanın oluşturduğu dosyaları gözden geçirmeniz anlamına gelir. Web modunda sohbette onaylarsınız.
Neler elde edersiniz
Şunları içeren bir indexing/ proje klasörü: URL envanteri, sınıflandırılmış listeler (to-submit.txt, skip.txt, needs-fix.txt), onaylanmış gönderim kuyruğu ve çalıştırma günlükleri. Her çalıştırmada dsh kısa bir rapor üretir: kaç tanesi gönderildi, kaç tanesi atlandı ve neden, bir öncekinden ne değişti. İlk kurulum 60–90 dakika (çoğunlukla Google kimlik bilgileri), haftalık çalıştırma 15 dakika.
Başlamadan önce
- dsh kurulu ve yapılandırılmış. Gerekirse
npx @deepseek-ai/dsh@latest webile güncelleyin. API anahtarınız ve ayarlarınız~/.dsh/içinde (profiles, sessions,settings.yaml);dsh webbaşlıyor veya headless görev başarılı = kurulum doğrulandı. - Sahibi olduğunuz bir GSC mülkü,
sc-domain:example.combiçiminde. - Okuma kimlik bilgileri: Search Console API için OAuth istemcisi (client ID + secret).
- Yazma kimlik bilgileri: Indexing API etkinleştirilmiş bir Google Cloud projesi, hizmet hesabı JSON anahtarı ve GSC → Ayarlar → Kullanıcılar ve izinler'de sahip olarak eklenmiş hizmet hesabı e-postası. Gönderimde 403 = bu adım başarısız.
- Workspace'te iki GSC komut dosyası klasörü: okuma skill'i (sitemap, Search Analytics, URL kontrolü) ve indeksleme skill'i (
index_submit.py). Python 3 vepip install google-auth google-api-python-client. - Proje klasörü, ör.
data/,scripts/,logs/içeren~/gsc-indexing-project.
Google kısmı her ajan için aynıdır; gsc-indexing skill belgeleri sizi Cloud konsolunda yönlendirir: Indexing API'yi etkinleştirin, hizmet hesabı oluşturun, anahtarı indirin, sahip olarak ekleyin.
Yol A: headless parti
Headless mod dsh --profile headless "görev" demektir: bir görev, bir yanıt, son. Hata ayıklarken pipeline'ın tamamını tek bir isteme koyarsınız ya da birkaç çalıştırmaya bölersiniz.
İlk çalıştırma (proje klasöründen):
dsh --profile headless "GSC indeksleme pipeline'ının 1. aşamasını çalıştır. gsc_query.py komut dosyasıyla sc-domain:example.com için sitemap'leri listele, tüm URL'leri lastmod ile çek, kopyaları ayıkla ve data/url-inventory.csv dosyasına yaz. Özet ver."İyi sonuç: GSC'deki sitemap raporuyla tutarlı bir özet içeren gerçek bir CSV ve uydurma sütunlar olmamalı. Kalite kontrolü: dosyayı açın ve rastgele beş URL'yi kontrol edin. Ajan kimlik doğrulama hatası bildirirse GSC OAuth akışını tekrarlayın ve yeniden deneyin; okuma komut dosyası taze bir token'a ihtiyaç duyar.
- aşama:
dsh --profile headless "data/url-inventory.csv içindeki URL'leri URL Inspection API üzerinden kontrol et ve data/to-submit.txt, data/skip.txt (her satırda nedeniyle) ile data/needs-fix.txt dosyalarına ayır. Yalnızca son 90 gün içinde lastmod'u olan URL'leri dahil et."Ajan kontrol komut dosyalarını partiler halinde çalıştırır (API'nin mülk başına hız limitleri vardır; güncel kota Google Cloud Console'da). Ayırmayı doğrulayın: atlananlar listesinde noindex, canonical reddi ve kopyalar baskın olmalı. Binlerce URL'si olan bir sitede needs-fix boşsa giriş penceresini genişletin.
- aşama — onay kapısı, asla gözetimsiz:
dsh --profile headless "data/needs-fix.txt ve data/skip.txt dosyalarını oku. Düzeltme ve gönderim kuyruğunu tablo halinde hazırla: URL, olası neden (iç bağlantı yok, kopya, canonical, noindex, zayıf içerik, soft 404), kanıt, önerilen işlem, risk seviyesi. Hiçbir şey gönderme."Rapordaki tabloyu inceleyin, data/to-submit.txt dosyasını onayladığınız URL'lere indirin ve 4. aşamayı çalıştırın:
dsh --profile headless "data/approved-urls.txt içindeki URL'leri indeksleme komut dosyasıyla gönder (index_submit.py submit --urls-file data/approved-urls.txt). Önce check-auth çalıştır. Her sonucu logs/submissions.log dosyasına yaz."Beklenen çıktı: 403 olmadan her URL için bir bildirim sonucu satırı. Kurtarma: 403, hizmet hesabının mülkün sahibi olmadığını; 429, günde 200 veya dakikada 600 kotasına takıldığınızı gösterir — listeyi günlere bölün. Çalıştırma yarıda ölürse dsh --profile headless --resume <session> ile devam edin.
Yol B: Web UI ve haftalık program
dsh web tarayıcı arayüzünü 127.0.0.1:3080'de açar. Aynı aşamalar, ama sohbet üzerinden ve etkileşimli: ajan sınıflandırma listelerini ve her gönderim komutundan önce bir kez daha onay ister. Bu canlı onay akışı, ilk kurulumda bu yolu seçmenin ana nedenidir: ajan Google mülkünüzle ne yapacağını yapmadan önce görürsünüz.
Pipeline oturduğunda ritim ekleyin. dsh'teki Schedule eklentisi schedule_create öğesini kaydeder ve canlı oturum içinde görevleri zamanlayıcıyla tekrarlar:
schedule_create: every 7 days, run "Inspect data/url-inventory.csv, classify new and changed URLs, and draft the submission queue. Do not submit."
Profiliniz Schedule eklentisini yüklemiyorsa, headless komutunun etrafındaki bir cron satırı aynı sonucu verir:
0 9 * * 1 cd ~/gsc-indexing-project && dsh --profile headless "Haftalık GSC indeksleme incelemesini çalıştır ve gönderim kuyruğunu hazırla." >> logs/weekly.log 2>&1
Program ilk üç istasyonu döndürür; gönderim insan kapısının arkasında kalır.
Gönderim aşamasını programa koymayın. Haftalık inceleme, sınıflandırma ve kuyruk hazırlığı gözetimsiz gidebilir; gönderim insanı bekler.
Ajanın kullandığı triyaj kuralları
Sınıflandırma ve kuyruk küçük bir tabloya dayanır. Her çalıştırmanın aynı kuralları kullanması için onu proje klasörüne koyun:
Neden | Düzeltme | Düzeltmeden sonra gönderilsin mi? |
|---|---|---|
İç bağlantı yok | Dizine alınmış sayfalardan bağlamsal bağlantılar ekleyin | Evet |
Tamamen yeni sayfa | Düzeltilecek bir şey yok; bir kez gönderin ve 1–2 hafta bekleyin | Evet, bir kez |
robots.txt engellemesi | Yol engellemesini kaldırın | Evet |
Kopya veya zayıf içerik | Yeniden yazın, birleştirin veya silin | Yalnızca gerçek değişiklikten sonra |
canonical başka yeri gösteriyor | Hatalıysa düzeltin; bilinçliyse URL'yi bırakın | Yalnızca düzeltmeden sonra |
Tarama anında noindex | noindex'i kaldırın | Evet, kaldırdıktan sonra |
Soft 404, arşivler, işe yaramaz facete'lar | Düzeltin veya silin; kalıcı atlama | Hayır |
İki durumun derinlemesine okuması (Google'ın neden bazı sayfaları tarayıp bazılarını taramadığı dahil) Hermes Agent rehberindedir. Pipeline'ı hangi harness çalıştırırsa çalıştırsın nedenler aynıdır.
Doğrulama, sonra bekleme
Her partiden sonra bildirimi status ile kontrol edin: bu yalnızca Google'ın URL meta verisine sahip olduğunu kanıtlar, sayfanın dizine alındığını değil. Gönderilen URL'leri 3–7 gün sonra yeniden kontrol edin ve durumları karşılaştırın. Sağlıklı desen 1–2 hafta içinde discovered → crawled → indexed'tir. GSC verileri birkaç gün gecikmeyle gelir ve Google kendi programına göre yeniden tarar — gerçek düzeltmelerden 10–14 gün sonra „Crawled – currently not indexed" içinde kalan bir URL, gönderim sorunu değil içerik kalitesi kararıdır. Günlük dosyası bunu görünür kılar: tarih, URL, bildirim türü, sonraki çalıştırmadaki kontrol durumu. Metrik şudur: zamanla daralan dizine alınmamışlar listesi, bildirim sayısı değil.
Dürüst sınırlamalar
- Indexing API resmi olarak
JobPostingveBroadcastEventsayfaları için belgelenmiştir. Sıradan sayfa gönderimi yaygın bir pratiktir, ancak Google hiçbir sayfa türü için garanti vermez ve destek sözü vermez. - Search Console'daki „Dizine eklenmesini iste" düğmesinin genel bir API'si yoktur. Indexing API en yakın komut dosyalı kanaldır, ama düğmenin kopyası değildir.
- Otomasyon öncelik yaratmaz. Bir sayfa düzeltme ve gönderimden sonra hâlâ dizine alınmıyorsa, sıradaki adım içerik işidir, bir planlı çalıştırma daha değil.
Sık sorulan sorular
Yalnızca headless'te, Web UI olmadan çalışabilir miyim? Evet. dsh --profile headless "görev" görevi çalıştırır ve biter. Kimlik bilgileri ~/.dsh/ içinde kalır ve okuma komut dosyaları aynı şekilde çalışır. Komut dosyası yazmadan önce pipeline'ı Web UI'da bir kez baştan sona geçirin.
Çalıştırma ölürse işimi kaybeder miyim? Hayır. dsh --profile headless --resume <session> ile devam edin ve gönderim komut dosyasını yeniden çalıştırın; URL'leri kopyadan ayıklar, bu yüzden aynı partiden zaten bildirilmiş URL'leri yeniden göndermek güvenlidir.
Birden çok GSC mülkü yönetiyorum. Her site için her şeyi yeniden mi yapmam gerekiyor? Komut dosyaları --site sc-domain:... bağımsız değişkenini kabul eder, bu yüzden tek bir workspace birden çok mülkün envanterlerini ve günlüklerini tutabilir. Her mülk için onaylanmış kuyruk dosyasını ve gönderim komutunu ayrı tutun; bir sitedeki kota hatası diğerlerini engellemez.
Yazar: Camille Rhodes, Auspia'da 300'den fazla AI içerik iş akışının mimarı. İçerik otomasyonu, yayın sistemleri ve AI ajanlarını güvenilir büyüme operasyonlarına dönüştüren süreçler hakkında yazar.
