«Discovered – currently not indexed» और «Crawled – currently not indexed» Search Console की पेज इंडेक्सिंग रिपोर्ट की दो सबसे आम पंक्तियाँ हैं, और साथ ही दो सबसे ग़लत समझी जाने वाली पंक्तियाँ भी। ये तकनीकी विफलता जैसी दिखती हैं, लेकिन असल में ये Google का आपके पेज के बारे में प्राथमिकता और गुणवत्ता का फ़ैसला होता है। बार-बार ज़ोर से भेजने से कुछ नहीं बदलेगा। कारण ठीक करने से — बदलेगा।
यह गाइड एक पूरा लूप है जिसे आप Hermes Agent को सौंप सकते हैं: URL की सूची लें, हर पेज की जाँच करें, असली कारण तय करें, मरम्मत कतार मंज़ूर करें, और सिर्फ़ उन्हीं पेजों को Google Indexing API से भेजें जो इंडेक्स होने लायक हैं। अंत में आपके पास एक दोहराने योग्य साप्ताहिक pipeline होगी, न कि एक बार का बटन-क्लिक सत्र।
आपको क्या मिलेगा
- वर्गीकृत इन्वेंट्री: कौन-सा URL discovered में अटका है, कौन-सा crawled-but-not-indexed में, और कौन-सा कभी नहीं भेजा जाना चाहिए
- Indexing API को मंज़ूर की गई भेजने की सूची, साथ में कारण सहित skip सूची
- सत्यापन लूप जो दिखाता है कि आपकी भेजाई गई चीज़ें सचमुच असर दिखाती हैं या नहीं
आपको चाहिए: Hermes Agent इंस्टॉल और काम करता हुआ (hermes chat से सत्र शुरू होता है; नवीनतम इंस्टॉलेशन चरण आधिकारिक दस्तावेज़ hermes-agent.nousresearch.com/docs पर देखें), Search Console property पर owner एक्सेस, और Google क्रेडेंशियल के दो सेट (एक GSC पढ़ने के लिए, एक Indexing API के लिए)। पहली सेटअप के लिए 60–90 मिनट रखें, फिर हर साप्ताहिक रन के लिए लगभग 15 मिनट। «पूरा» का मतलब: आपके भेजे गए URL कुछ हफ़्तों में Inspection API में असली स्टेटस मूवमेंट दिखाते हैं, या आपके पास साफ़ सबूत है कि यह क्यों नहीं हिलेगा।
दोनों स्टेटस को सही ढंग से पढ़ें
Google आपकी साइट पर अटका नहीं है। वह फ़ैसला लेता है, और स्टेटस बताता है कि वह कौन-सा फ़ैसला है।
स्टेटस | असली मतलब | सामान्य कारण | कब भेजें |
|---|---|---|---|
Discovered – currently not indexed | Google को URL के बारे में पता है (sitemap या लिंक से) लेकिन उसने अभी क्रॉल नहीं किया | कम क्रॉल प्राथमिकता, कमज़ोर या अनुपस्थित आंतरिक लिंक, बड़ी साइटों पर क्रॉल बजट का दबाव, नई साइट, धीमा या भारी JavaScript रेंडरिंग, लगातार बदलता sitemap | प्राथमिकता सिग्नल (खासकर आंतरिक लिंक) ठीक करने के बाद, फिर एक बार |
Crawled – currently not indexed | Google ने URL ले लिया और उसे इंडेक्स में जोड़ने से मना कर दिया | डुप्लिकेट या लगभग-डुप्लिकेट कंटेंट, पतली कंटेंट, canonical दूसरे URL की ओर इशारा करता है, क्रॉल के समय noindex, soft 404, कम समझा जाने वाला मूल्य | केवल तब जब आपने कुछ बदला हो: कंटेंट, canonical या noindex |
Indexed | इंडेक्स में है | — | कभी नहीं |
Excluded | क्रॉल किया गया और जानबूझकर छोड़ा गया (noindex, canonical, चुना हुआ डुप्लिकेट, ब्लॉक) | — | कभी नहीं; जाँचें कि बहिष्करण जानबूझकर है या नहीं |
एक वाक्य में नियम: सिर्फ़ उन्हीं URL को भेजें जिन्हें आपने सचमुच बदला है या जो दूसरी नज़र के लायक हैं। Indexing API एक नोटिफिकेशन चैनल है, रैंकिंग ओवरराइड नहीं। पतले पेज को उसके ज़रिए 10 बार भेजने से 10 बार वही फ़ैसला मिलेगा।
इसे agent पर क्यों चलाएँ
GSC का «Request indexing» बटन सार्वजनिक API नहीं देता, इसलिए स्क्रिप्ट से उसे दबाने का कोई आधिकारिक तरीका नहीं है। सबसे नज़दीकी ऑटोमेशन Google Indexing API है, जो URL नोटिफिकेशन सीधे स्वीकार करता है। Agent यहाँ तीन कारणों से रखने लायक है:
- लूप यांत्रिक और लंबा है: inventory → inspect → classify → fix → submit → verify। हर हफ़्ते दोहरता है।
- ऑडिट ट्रेल चाहिए: आपको एक फ़ाइल चाहिए जो रिकॉर्ड करे कि कौन-सा URL कब और क्यों भेजा गया।
- मंज़ूरी गेट चाहिए: Google को लिखने वाला हिस्सा इंसान द्वारा समीक्षित होना चाहिए। Hermes उसी विभाजन के इर्द-गिर्द बना है — skills, प्रोजेक्ट फ़ोल्डर और मंज़ूरी नियमों के साथ।
शुरू करने से पहले: आपको क्या चाहिए
- Hermes Agent इंस्टॉल हो। आगे बढ़ने से पहले
hermes chatसे पुष्टि करें। - GSC property जो आपकी है,
sc-domain:example.comफ़ॉर्मेट में (पूरा URL नहीं)। - रीड एक्सेस: Search Console API के लिए Google Cloud का OAuth क्लाइंट (client ID + secret)। GSC skill के स्क्रिप्ट इससे sitemap सूचीबद्ध करते हैं, सर्च एनालिटिक्स चलाते हैं और URL जाँचते हैं।
- राइट एक्सेस: Google Cloud प्रोजेक्ट जिसमें Indexing API चालू है और service account की JSON कुंजी है। service account का ईमेल GSC → सेटिंग्स → उपयोगकर्ता और अनुमतियाँ में Owner के रूप में जोड़ें। अगर भेजने पर 403 आता है — यही छूटा हुआ चरण है।
- Python 3 साथ
pip install google-auth google-api-python-client। - प्रोजेक्ट फ़ोल्डर, जैसे
/hermes-seo-project, जिसमेंcontext/,data/,qa/औरapproval-rules.mdहों, जिसमें लिखा हो कि भेजने का चरण हमेशा इंसानी हस्ताक्षर माँगे।
चरण 1: URL इन्वेंट्री बनाएँ
Hermes की skills डायरेक्टरी (~/.hermes/skills) में दो GSC skills कॉपी करें: रीड स्किल (sitemaps, सर्च एनालिटिक्स, URL जाँच) और इंडेक्सिंग स्किल (भेजने का स्क्रिप्ट)। अगर harness ने उन्हें कैटलॉग किया है तो Hermes उन्हें skill_view से भी लोड कर सकता है।
फिर Hermes से प्रोजेक्ट फ़ोल्डर के चैट सत्र में पूछें:
sc-domain:example.com के सभी sitemap सूचीबद्ध करें, हर URL को उसकी lastmod तारीख के साथ लें, और परिणाम data/url-inventory.csv में लिखें। जो sitemap नहीं खींच पाए उसे चिह्नित करें।
Hermes टर्मिनल टूल से sitemap कमांड चलाकर CSV लिखता है। अच्छा आउटपुट कैसा दिखता है: बिना डुप्लिकेट वाला CSV, जिसमें URL, lastmod और सोर्स sitemap हो। गुणवत्ता जाँच: पाँच रैंडम पंक्तियाँ देखें और कुल संख्या GSC के sitemap रिपोर्ट से मिलाएँ। अगर सूची खाली है या ऑथेंटिकेशन फेल है, तो GSC ऑथेंटिकेशन फ्लो दोबारा चलाएँ; रीड स्क्रिप्ट को नया OAuth टोकन चाहिए।
चरण 2: जाँचें और वर्गीकृत करें
अब agent URL Inspection API से इन्वेंट्री को बैचों में जाँचता है, जो हर पेज की नवीनतम कवरेज स्टेटस देता है। अगला चरण माँगें:
data/url-inventory.csv के हर URL की जाँच करें। तीन फ़ाइलों में बाँटें: data/to-submit.txt (इंडेक्स नहीं हुआ, माँगने लायक), data/skip.txt (हर URL के लिए एक-पंक्ति कारण सहित), और data/needs-fix.txt (इंडेक्स नहीं हुआ और किसी ऐसी चीज़ से रुका है जिसे हम बदल सकते हैं)।
Inspection API हर property के हिसाब से रेट-लिमिटेड है (Google Cloud Console में अपनी मौजूदा कोटा जाँचें; हर दिन हज़ारों रिक्वेस्ट, लेकिन असीमित नहीं)। बड़ी साइटों के लिए इस राउंड को सबसे नई lastmod तारीख वाले URL तक सीमित रखें — जिन्हें आपने इस तिमाही में सचमुच बदला है। गुणवत्ता जाँच: skip सूची का नमूना लें। उसमें ज़्यादातर noindex, दूसरी जगह इशारा करता canonical, और डुप्लिकेट होने चाहिए, न कि वे पेज जिनकी आपको परवाह है। अगर हज़ारों URL वाली साइट पर agent खाली needs-fix सूची बनाता है, तो संभवतः इन्वेंट्री चरण पेज चूक गया है। इनपुट चौड़ा करें।
चरण 3: भेजने से पहले ट्राइएज
यह वह चरण है जिसे लोग छोड़ देते हैं। हर अटके URL को इस क्रम में कारण और मरम्मत से जोड़ें:
कारण | मरम्मत | मरम्मत के बाद भेजें? |
|---|---|---|
पेज की ओर कोई आंतरिक लिंक नहीं | संबंधित इंडेक्स्ड पेजों से कॉन्टेक्स्टुअल लिंक जोड़ें | हाँ |
बिल्कुल नई साइट या पेज | मरम्मत के लिए कुछ नहीं; एक बार भेजें और 1–2 हफ़्ते रुकें | हाँ, एक बार |
robots.txt से ब्लॉक | उस पाथ का ब्लॉक हटाएँ | हाँ |
क्रॉल तो हुआ लेकिन डुप्लिकेट या पतला | पेज को फिर से लिखें, मिलाएँ या हटाएँ | केवल असली कंटेंट बदलाव के बाद |
canonical दूसरे URL की ओर | ग़लत होने पर canonical ठीक करें; जानबूझकर हो तो यह URL भेजना बंद करें | केवल तब जब आपने ठीक किया हो |
क्रॉल के समय noindex मौजूद | noindex हटाएँ और Google को फिर से क्रॉल करने दें | हाँ, हटाने के बाद |
soft 404 या बेकार pagination/archive | पेज ठीक करें या हटाएँ | नहीं — स्थायी रूप से skip करें |
Hermes से मरम्मत कतार को टेबल के रूप में बनाने को कहें: URL, संदिग्ध कारण, सबूत (जाँच का नतीजा या कंटेंट समीक्षा), सुझाई गई कार्रवाई, जोखिम स्तर। हर पंक्ति को चैट में मंज़ूर करें। आपका approval-rules.md इसे अनिवार्य बनाए: agent तैयार करे, आप मंज़ूर करें, और कम जोखिम से ऊपर की कोई चीज़ बिना हस्ताक्षर न भेजी जाए।
मंज़ूरी गेट agent की तैयारी को लिखने वाले चरण से अलग करता है।
मरम्मत खुद सामान्य SEO काम है: कंटेंट दोबारा लिखना, canonical साफ़ करना, आंतरिक लिंक। यह pipeline भेजने का आधा हिस्सा कवर करता है; Hermes सीरीज़ के audit और refresh लेख बाकी आधा कवर करते हैं।
भेजने की सूची «ठीक हो सकता है» और «इंडेक्स होने लायक» का प्रतिच्छेदन है।
चरण 4: Indexing API से भेजें
कतार मंज़ूर होने के बाद URL को data/approved-urls.txt में रखें और Hermes से इंडेक्सिंग स्किल चलवाएँ:
python3 ~/.hermes/skills/gsc-indexing/scripts/index_submit.py check-auth
python3 ~/.hermes/skills/gsc-indexing/scripts/index_submit.py submit --urls-file data/approved-urls.txtडिफ़ॉल्ट नोटिफिकेशन प्रकार URL_UPDATED है, जो नए या बदले हुए पेज के लिए चाहिए। तीन नंबर याद रखें: डिफ़ॉल्ट कोटा 200 URL प्रति दिन और 600 रिक्वेस्ट प्रति मिनट; और 403 का मतलब है कि service account property का Owner नहीं है। अगर मंज़ूर सूची 200 से ज़्यादा है, तो कई दिनों में बाँटें; Hermes बाकी बैच शेड्यूल कर सकता है।
जो पेज पहले से इंडेक्स्ड है उसे कभी न भेजें, और skip सूची कभी न भेजें। बेकार नोटिफिकेशन सिर्फ़ कोटा जलाते हैं और शोर पैदा करते हैं।
चरण 5: सत्यापित करें, फिर रुकें
भेजने के तुरंत बाद status सिर्फ़ बताता है कि Google के पास आपके नोटिफिकेशन का मेटाडेटा है या नहीं, यह नहीं कि पेज इंडेक्स हुआ है। असली जाँच कई दिनों बाद आती है।
Hermes से बैच के 3–7 दिन बाद पूछें:
data/approved-urls.txt के URL फिर से जाँचें और पिछले रन की तुलना में स्टेटस बदलाव की रिपोर्ट दें।
स्वस्थ गति है discovered → crawled → indexed। कुछ हफ़्तों में यह ऐसा दिखता है: बिना-इंडेक्स सूची सिकुड़ती है, और आपकी असली मरम्मत (नए आंतरिक लिंक, दोबारा लिखा टेक्स्ट) इंडेक्स में दिखती है। याद रखें GSC डेटा कुछ दिन लेट आता है, और Google अपने शेड्यूल से फिर से क्रॉल करता है। असली मरम्मत के बाद 10–14 दिनों तक «Crawled – currently not indexed» में अटका URL क्वालिटी सिग्नल है, भेजने की समस्या नहीं। कंटेंट काम पर लौट जाएँ।
लूप को चलता रखें
पाइपलाइन को साप्ताहिक रूटीन बनाएँ: पिछले रन के बाद के नए और बदले URL → जाँचें → वर्गीकृत करें → ट्राइएज → मंज़ूर करें → भेजें → लॉग करें। Hermes रीड-ओनली हिस्सा (इन्वेंट्री, इंस्पेक्शन, वर्गीकरण) शेड्यूल पर बिना निगरानी चला सकता है और हर सोमवार कतार पेश कर सकता है। भेजने का चरण अपने मंज़ूरी गेट के पीछे रखें, और qa/indexing-log.md में लगातार लॉग रखें: भेजने की तारीख, URL, नोटिफिकेशन प्रकार, नतीजा। उस लॉग के छह महीने ही यह मापने का एकमात्र ईमानदार तरीका है कि pipeline काम कर रही है या नहीं।
ईमानदार सीमाएँ
- Google Indexing API को
JobPostingयाBroadcastEventस्ट्रक्चर्ड डेटा वाले पेजों के लिए दस्तावेज़ित करता है। आम पेजों के लिए इसका उपयोग व्यापक SEO प्रैक्टिस है, लेकिन Google हर पेज प्रकार के लिए इंडेक्सिंग या सपोर्ट की गारंटी नहीं देता। - «Request indexing» बटन के लिए कोई सार्वजनिक API नहीं है। Indexing API सबसे नज़दीकी ऑटोमेशन है, वही बटन नहीं।
- भेजना प्राथमिकता नहीं बनाता। अगर पेज मरम्मत, भेजने और इंतज़ार के बाद भी इंडेक्स नहीं हुआ, तो अगला जवाब कंटेंट क्वालिटी है, कोई और नोटिफिकेशन नहीं।
अक्सर पूछे जाने वाले प्रश्न
क्या Indexing API आम पेजों के लिए काम करता है? यह आपके भेजे गए किसी भी URL को स्वीकार करता है। Google का आधिकारिक दस्तावेज़ इसे JobPosting और BroadcastEvent पेजों तक सीमित करता है, इसलिए आम पेज भेजना best-effort मानें: उपयोगी, आम, और कभी गारंटीड नहीं।
भेजने के बाद भी मेरा URL «Discovered – currently not indexed» क्यों है? वह स्टेटस आमतौर पर क्रॉल प्राथमिकता का मतलब है, विफलता का नहीं। पेज की ओर इशारा करते आंतरिक लिंक जाँचें, देखें कि robots.txt पाथ ब्लॉक करता है या नहीं, और पेज JavaScript पर कितना निर्भर है। फिर रुकें: नई साइट पर discovery से crawl तक एक-दो हफ़्ते लग सकते हैं।
क्या 200 URL प्रति दिन काफ़ी है? ज़्यादातर साइटों के लिए हाँ, क्योंकि आपको सिर्फ़ सचमुच बदले गए URL भेजने चाहिए। अगर नियमित रूप से ज़्यादा हों, तो व्यावसायिक मूल्य के हिसाब से प्राथमिकता दें और Google Cloud Console में कोटा बढ़ाने की माँग करें।
क्या Indexing API से पेज तेज़ी से रैंक होता है? नहीं। यह Google को बताता है कि URL बदला है। रैंकिंग का फ़ैसला अलग है, और उसे Google के सिस्टम लेते हैं, आपके नोटिफिकेशन की मात्रा नहीं।
Search Console में «Request indexing» क्लिक करने से इसमें क्या फ़र्क है? मंशा एक जैसी, तंत्र अलग। वह बटन सिर्फ़ UI है जिसका कोई सार्वजनिक API नहीं; Indexing API स्क्रिप्टेबल चैनल है। दोनों में से कोई भी Google के इस फ़ैसले को ओवरराइड नहीं करता कि पेज इंडेक्स में आने लायक है या नहीं।
लेखक: जूलियन मर्सर, Auspia में 14 वर्षों के Technical SEO प्रैक्टिशनर। जूलियन crawlability, इंडेक्सिंग, schema और उन तकनीकी बुनियादों के बारे में लिखते हैं जो Google और AI सिस्टम को वेबसाइट सही ढंग से पढ़ने देती हैं।
