DeepSeek Harness से «Discovered / Crawled – Currently Not Indexed» URL ठीक करें

DeepSeek Harness (dsh) ऐसे agent चलाता है जो असली काम कर सकते हैं, और SEO का बहुत कम काम बिना-इंडेक्स URL pipeline जितना इसके लिए फिट है: सूची पढ़ें, हर URL जाँचें, वर्गीकृत करें, मंज़ूरी रुको, भेजो, सत्यापित करो। हर चरण एक कमांड या फ़ाइल है — बिल्कुल वही क्षेत्र जहाँ agent harness माहिर है।

दो सवाल तय करते हैं कि आप इसे कैसे सेट करते हैं। एक बार चलने वाला बैच चाहिए जो स्क्रिप्टेबल हो और cron में लग सके? Headless चलाएँ। उसे काम करते देखना चाहते हैं, उसके सवालों का जवाब देना चाहते हैं, और हर बैच को चैट विंडो में मंज़ूर करना चाहते हैं? web UI इस्तेमाल करें। यह गाइड दोनों रास्ते दिखाता है, और दोनों के नीचे की pipeline एक ही है। अगर आप «Discovered – currently not indexed» और «Crawled – currently not indexed» का गहरा मतलब और उसे पढ़ने का तरीका जानना चाहते हैं, तो हमने उसे इस वर्कफ़्लो के Hermes Agent संस्करण में कवर किया है; यहाँ हम dsh से एक्ज़ीक्यूशन पर फोकस करते हैं।

अपना रास्ता चुनें

Headless बैचों के लिए, web UI पहले रन के लिए — नीचे की pipeline एक ही है।

दोनों रास्ते एक नियम साझा करते हैं: लिखने वाला चरण (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 property जो आपकी है, sc-domain:example.com फ़ॉर्मेट में।
• रीड क्रेडेंशियल: Search Console API के लिए OAuth क्लाइंट (client ID + secret)।
• राइट क्रेडेंशियल: Google Cloud प्रोजेक्ट जिसमें Indexing API चालू है, service account की JSON कुंजी, और service account का ईमेल GSC → सेटिंग्स → उपयोगकर्ता और अनुमतियाँ में Owner के रूप में जोड़ा गया है। भेजते समय 403 का मतलब यह चरण फेल हुआ।
• workspace में दो GSC स्क्रिप्ट फ़ोल्डर: रीड स्किल (sitemaps, सर्च एनालिटिक्स, 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 चालू करें, service account बनाएँ, कुंजी डाउनलोड करें, Owner के रूप में जोड़ें।

रास्ता A: एक बार का हेडलेस रन

Headless मोड है dsh --profile headless "काम": एक काम, एक जवाब, बाहर। पूरी pipeline एक ही कमांड में डालें, या डिबग करते समय कई रनों में चरणबद्ध करें।

पहला रन, प्रोजेक्ट फ़ोल्डर से:

dsh --profile headless "GSC इंडेक्सिंग pipeline का चरण 1 चलाएँ. gsc_query.py स्क्रिप्ट से sc-domain:example.com के sitemap सूचीबद्ध करें, हर URL को lastmod सहित लें, डुप्लिकेट हटाएँ, और data/url-inventory.csv लिखें. कुल संख्या रिपोर्ट करें."

अच्छा आउटपुट कैसा दिखता है: असली CSV जिसकी संख्या GSC के sitemap रिपोर्ट से मेल खाती है, और कोई मनगढ़ंत कॉलम नहीं। गुणवत्ता जाँच: फ़ाइल खोलें और पाँच रैंडम URL देखें। अगर agent ऑथेंटिकेशन एरर रिपोर्ट करता है, तो GSC का OAuth फ्लो दोबारा चलाकर फिर कोशिश करें; रीड स्क्रिप्ट को नया टोकन चाहिए।

चरण 2:

dsh --profile headless "data/url-inventory.csv के URL को URL Inspection API से जाँचें और data/to-submit.txt, data/skip.txt (एक-पंक्ति कारण सहित), और data/needs-fix.txt में बाँटें. सिर्फ़ पिछले 90 दिनों में lastmod वाले URL शामिल करें."

agent जाँच स्क्रिप्ट को बैचों में चलाता है (API हर property के हिसाब से रेट-लिमिटेड है; Google Cloud Console में अपनी मौजूदा कोटा देखें)। बँटवारे की तर्कसंगतता जाँचें: skip सूची में noindex, canonical-away और डुप्लिकेट पेजों का बोलबाला होना चाहिए। अगर हज़ारों URL वाली साइट पर needs-fix सूची खाली आती है, तो इनपुट विंडो चौड़ी करें।

चरण 3 मंज़ूरी गेट है, और यह कभी बिना निगरानी नहीं चलता:

dsh --profile headless "data/needs-fix.txt और data/skip.txt पढ़ें. बदलो-और-भेजो कतार को टेबल के रूप में तैयार करें: URL, संदिग्ध कारण (कोई आंतरिक लिंक नहीं, डुप्लिकेट, canonical, noindex, पतला, soft 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 के लिए एक नोटिफिकेशन-परिणाम पंक्ति, बिना किसी 403 के। रिकवरी रास्ता: 403 का मतलब service account property का Owner नहीं है; 429 का मतलब आप 200-प्रति-दिन या 600-प्रति-मिनट कोटा छू गए; सूची को कई दिनों में बाँटें। अगर रन बीच में मर जाए, dsh --profile headless --resume <session> उसे जारी रखता है।

रास्ता B: web UI प्लस साप्ताहिक शेड्यूल

dsh web 127.0.0.1:3080 पर ब्राउज़र UI खोलता है। चैट उन्हीं चरणों से गुज़रती है, लेकिन इंटरैक्टिव: agent कतार तैयार करने से पहले वर्गीकृत सूची की पुष्टि माँगता है, और भेजने का कमांड चलाने से पहले एक बार फिर। यह लाइव मंज़ूरी फ्लो पहली सेटअप में यह रास्ता चुनने का मुख्य कारण है: आप देखते हैं कि agent आपकी Google property के साथ क्या करने वाला है, इससे पहले कि वह करे।

जब pipeline काम कर जाए, तो लय जोड़ें। dsh का Schedule plugin 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 plugin लोड नहीं करता, तो वही नतीजा cron लाइन है जो headless कमांड को लपेटती है:

0 9 * * 1 cd ~/gsc-indexing-project && dsh --profile headless "साप्ताहिक GSC इंडेक्सिंग जाँच चलाएँ और भेजने की कतार तैयार करें." >> logs/weekly.log 2>&1

शेड्यूल पहले तीन स्टेशन चलाता है; भेजना इंसानी गेट के पीछे रहता है।

भेजने का चरण शेड्यूल से बाहर रखें। साप्ताहिक जाँच, वर्गीकरण और कतार तैयार करना बिना निगरानी चल सकता है; भेजना इंसान का इंतज़ार करता है।

agent जो ट्राइएज नियम लागू करता है

वर्गीकरण और कतार एक छोटी टेबल पर टिके हैं, और आपको उसे प्रोजेक्ट फ़ोल्डर में रखना चाहिए ताकि हर रन एक ही नियम इस्तेमाल करे:

दोनों स्टेटस की गहरी पढ़ाई, जिसमें Google कुछ पेज क्रॉल करता है और कुछ नहीं, इसका कारण शामिल है, Hermes Agent गाइड में है। कारण वही हैं चाहे कोई भी harness pipeline चलाए।

सत्यापित करें, फिर रुकें

हर बैच के बाद status से नोटिफिकेशन की पुष्टि करें: यह सिर्फ़ साबित करता है कि Google के पास उसका मेटाडेटा है, यह नहीं कि पेज इंडेक्स हुआ। तीन से सात दिन बाद भेजे गए URL दोबारा जाँचें और स्टेटस की तुलना करें। स्वस्थ पैटर्न है एक-दो हफ़्तों में discovered → crawled → indexed। GSC डेटा कुछ दिन लेट आता है, और Google अपने शेड्यूल से फिर क्रॉल करता है, इसलिए असली मरम्मत के पीछे 10–14 दिन बाद भी «Crawled – currently not indexed» में अटका URL कंटेंट क्वालिटी का फ़ैसला है, भेजने की समस्या नहीं। लॉग फ़ाइल वह जगह है जहाँ यह दिखता है: तारीख, URL, नोटिफिकेशन प्रकार, और अगले रन में जाँच की स्थिति। माप भी यही है: बिना-इंडेक्स सूची समय के साथ सिकुड़नी चाहिए, नोटिफिकेशन की संख्या नहीं बढ़नी चाहिए।

ईमानदार सीमाएँ

• Indexing API आधिकारिक रूप से JobPosting और BroadcastEvent पेजों के लिए दस्तावेज़ित है। आम पेज भेजना उसके ज़रिए आम प्रैक्टिस है, लेकिन Google हर पेज प्रकार के लिए गारंटी या सपोर्ट का वादा नहीं करता।
• Search Console के «Request indexing» बटन के लिए कोई सार्वजनिक API नहीं है। Indexing API सबसे नज़दीकी स्क्रिप्टेबल चैनल है, बटन की नकल नहीं।
• ऑटोमेशन प्राथमिकता नहीं बनाता। अगर आपके मरम्मत और भेजने के बाद भी पेज इंडेक्स नहीं हुआ, तो अगला कदम कंटेंट काम है, कोई और शेड्यूल्ड रन नहीं।

अक्सर पूछे जाने वाले प्रश्न

क्या मैं web UI बिल्कुल इस्तेमाल किए बिना सिर्फ़ headless मोड चला सकता हूँ? हाँ। dsh --profile headless "काम" एक काम चलाकर बाहर निकलता है; क्रेडेंशियल ~/.dsh/ में रहते हैं, और रीड स्क्रिप्ट वैसे ही काम करती हैं। pipeline को एंड-टू-एंड सत्यापित करने के लिए एक बार web UI इस्तेमाल करें, फिर स्क्रिप्ट करें।

रन बैच के बीच में मर गया। क्या मेरा काम खो जाएगा? नहीं। dsh --profile headless --resume <session> से जारी रखें, और भेजने वाली स्क्रिप्ट दोबारा चलाएँ; वह डुप्लिकेट URL हटाती है, इसलिए उसी बैच में पहले से नोटिफ़ाइड URL दोबारा भेजना हानिकारक नहीं है।

मैं कई GSC properties मैनेज करता हूँ। क्या मुझे हर साइट के लिए सब कुछ दोहराना होगा? स्क्रिप्ट --site sc-domain:... आर्ग्युमेंट स्वीकार करती है, इसलिए एक workspace कई properties की इन्वेंट्री और लॉग रख सकता है। हर property के लिए एक मंज़ूर कतार फ़ाइल और एक भेजने का कमांड रखें, ताकि एक साइट की कोटा ग़लती कभी दूसरी को ब्लॉक न करे।

लेखक: कैमिल रोड्स, Auspia में 300+ AI कंटेंट वर्कफ़्लो की आर्किटेक्ट। कैमिल कंटेंट ऑटोमेशन, पब्लिशिंग सिस्टम और उन वर्कफ़्लो के बारे में लिखती हैं जो AI agent को भरोसेमंद ग्रोथ ऑपरेशन में बदलते हैं।