किसी AI एजेंट को Google Search Console का डेटा देने के छह काम के तरीके हैं: होस्टेड OAuth कनेक्टर, कम्युनिटी का बनाया MCP सर्वर, सीधे Search Console API, BigQuery में बल्क एक्सपोर्ट, स्प्रेडशीट ब्रिज, या फिर Search Console का अपना बिल्ट-इन AI कॉन्फ़िगरेशन, जिसमें कोई एजेंट ही नहीं लगता। इनमें दो मिनट से लेकर लगभग पूरा दिन तक लग सकता है, और आपके लिए सही तरीका इस बात पर टिका है कि आपको 16 महीने से पुराना डेटा चाहिए या नहीं।
यही आखिरी बात असली मोड़ है, इसलिए पहले इसे ही समझ लीजिए। Search Analytics API एक रिक्वेस्ट में ज़्यादा से ज़्यादा 25,000 रो लौटाता है और सिर्फ़ 16 महीने की हिस्ट्री रखता है। 16 महीने के बाद डेटा चला जाता है, छिपता नहीं, सीधे डिलीट हो जाता है। अगर आपको इससे लंबी हिस्ट्री चाहिए, तो इस लिस्ट का सिर्फ़ एक तरीका वह दिला सकता है, और उसे ज़रूरत पड़ने से पहले ही शुरू करना होगा।
तरीका 1: होस्टेड OAuth कनेक्टर
सेटअप: 2 से 5 मिनट। कोई कोड नहीं।
आप किसी SEO एजेंट प्रोडक्ट को अपने Google अकाउंट से ऑथराइज़ करते हैं, प्रॉपर्टी चुनते हैं, और कनेक्शन सर्वर पर सेव होकर हर क्वेरी में दोबारा इस्तेमाल होता है। ज़्यादातर मार्केटर्स के लिए यही सही रास्ता है, और इसकी वजह आलस नहीं है। वजह यह है कि गड़बड़ियों को संभालने का काम आपके लिए पहले से हो चुका होता है। अच्छा बना कनेक्टर कनेक्शन न होने पर अंदाज़ा लगाने के बजाय आपसे कनेक्ट करने को कहता है, आपके पास कई प्रॉपर्टी हों तो सही वाली चुनता है, और 25,000 रो की सीमा के आगे का पेजिनेशन बिना आपके सोचे खुद कर लेता है।
हमारे अपने इम्प्लीमेंटेशन में Search Console टूल पर read-only का टैग लगा है। पहली कॉल पर यह चेक करता है कि कोई एक्टिव कनेक्शन है या नहीं; अगर नहीं है, तो इंटीग्रेशन स्क्रीन पर सीधे ले जाने वाला इंटरैक्टिव कनेक्ट प्रॉम्प्ट दिखाता है, और आपके लौटते ही बातचीत वहीं से आगे बढ़ा देता है।
ट्रेड-ऑफ़: आपको वही टूल मिलते हैं जो वेंडर ने बनाए हैं। अगर आपको ऐसी क्वेरी चाहिए जो उन्होंने बनाई ही नहीं, तो वह आपको नहीं मिलेगी।
तरीका 2: Search Console का MCP सर्वर
सेटअप: 15 से 45 मिनट। डेवलपर वाली थोड़ी समझ ज़रूरी है।
Model Context Protocol AI असिस्टेंट्स को बाहरी सिस्टम से जोड़ने का एक ओपन क्लाइंट/सर्वर स्टैंडर्ड है। यानी MCP सपोर्ट करने वाला कोई भी क्लाइंट, जैसे Claude Desktop, Claude Code, Cursor वगैरह, सीधे Search Console सर्वर को कॉल कर सकता है।
एक ज़रूरी बात: GA4 के लिए Google अपना MCP सर्वर पब्लिश करता है, लेकिन Search Console के लिए Google का कोई आधिकारिक MCP सर्वर नहीं है। जो मौजूद हैं, वे कम्युनिटी के बनाए कई अच्छे इम्प्लीमेंटेशन हैं, जैसे mcp-server-gsc, जो regex फ़िल्टरिंग के साथ 25,000 रो की सीमा तक सर्च एनालिटिक्स डेटा निकालता है और read-only है।
कॉन्फ़िगरेशन आपके MCP क्लाइंट में एक JSON ब्लॉक होता है, जो आपके क्रेडेंशियल्स के साथ सर्वर की तरफ़ इशारा करता है:
{
"mcpServers": {
"search-console": {
"command": "npx",
"args": ["-y", "mcp-server-gsc"],
"env": { "GOOGLE_APPLICATION_CREDENTIALS": "/path/to/service-account.json" }
}
}
}ट्रेड-ऑफ़: आप अपने सर्च डेटा के क्रेडेंशियल्स एक कम्युनिटी पैकेज के भरोसे छोड़ रहे हैं। इसलिए सोर्स कोड पढ़िए, read-only स्कोप को तरजीह दीजिए और वर्ज़न पिन कर दीजिए। साथ ही यह भी देख लीजिए कि सर्वर जिस प्रोटोकॉल वर्ज़न पर चलता है, वह आपके क्लाइंट की उम्मीद से मेल खाता है या नहीं।
तरीका 3: सर्विस अकाउंट के साथ Search Console API
सेटअप: 1 से 3 घंटे। यहाँ आप कोड लिख रहे हैं।
सबसे ज़्यादा कंट्रोल, और सबसे ज़्यादा मेहनत। स्टेप्स ये हैं:
- एक Google Cloud प्रोजेक्ट बनाइए, या कोई पुराना इस्तेमाल कीजिए।
- उस पर Search Console API चालू कीजिए।
- एक सर्विस अकाउंट बनाइए और उसकी JSON key डाउनलोड कीजिए।
- सर्विस अकाउंट के ईमेल एड्रेस को Search Console प्रॉपर्टी पर ही यूज़र के तौर पर जोड़िए, Restricted (read-only) परमिशन के साथ।
- उस key से अपने एजेंट को ऑथेंटिकेट कीजिए और
searchanalytics.queryकॉल कीजिए।
स्टेप 4 वही है जिसे लगभग हर कोई भूल जाता है। Cloud में क्रेडेंशियल बना लेने से उसे प्रॉपर्टी का एक्सेस नहीं मिल जाता। ये दो अलग-अलग परमिशन सिस्टम हैं, और दूसरा स्टेप छोड़ने पर एक आम-सा 403 एरर आता है, जो प्रॉपर्टी एक्सेस की नहीं बल्कि API चालू न होने की समस्या जैसा लगता है। मानकर चलिए कि एक बार इसमें बीस मिनट तो जाएँगे।
पेजिनेशन के साथ एक मिनिमल क्वेरी बॉडी कुछ ऐसी दिखती है:
{
"startDate": "2026-04-01",
"endDate": "2026-06-30",
"dimensions": ["query", "page"],
"rowLimit": 25000,
"startRow": 0
}हर पेज पर startRow को 25,000 से बढ़ाइए, और जब किसी रिस्पॉन्स में माँगी गई संख्या से कम रो आएँ, तो रुक जाइए। बाकी सब, जैसे कोटा संभालना, रिट्राई और टोकन रिफ़्रेश, अब आपको खुद बनाना है।
ट्रेड-ऑफ़: पूरी आज़ादी, लेकिन कोटा, पेजिनेशन, रिट्राई और टोकन रिफ़्रेश की ज़िम्मेदारी अब आपकी है। यह तरीका तब चुनिए जब एजेंट को ऐसी क्वेरी चाहिए जो कोई कनेक्टर नहीं देता, या जब डेटा आपके अपने इन्फ्रास्ट्रक्चर से बाहर नहीं जाना चाहिए।
तरीका 4: BigQuery में बल्क एक्सपोर्ट
सेटअप: लगभग एक घंटा, और पहला एक्सपोर्ट आने में 48 घंटे तक।
16 महीने वाली समस्या का हल सिर्फ़ यही तरीका है, और इसे आज ही सेट कर लेना चाहिए, भले अभी ज़रूरत न हो। वजह साफ़ है: यह हिस्ट्री पीछे से नहीं, आज से आगे की तरफ़ जमा करता है।
Google के बल्क डेटा एक्सपोर्ट डॉक्यूमेंटेशन के मुताबिक़ स्टेप्स ये हैं:
- ऐसा Google Cloud प्रोजेक्ट बनाइए या चुनिए जिस पर बिलिंग चालू हो। यह ज़रूरी है, वैकल्पिक नहीं।
- उस पर BigQuery API और BigQuery Storage API चालू कीजिए।
- Search Console के सर्विस अकाउंट को प्रोजेक्ट पर दो रोल दीजिए: BigQuery Job User और BigQuery Data Editor।
- Search Console में Settings खोलिए, फिर Bulk data export, और वहाँ Cloud प्रोजेक्ट ID के साथ डेटासेट की लोकेशन डालिए।
- इंतज़ार कीजिए। पहला एक्सपोर्ट 48 घंटे के अंदर आता है, और उसके बाद रोज़ एक्सपोर्ट चलते हैं।
फ़ैसला करने से पहले दो बातें जान लीजिए। प्राइवेसी की वजह से गुमनाम (anonymized) क्वेरी एक्सपोर्ट में शामिल नहीं होतीं, इसलिए BigQuery के टोटल Search Console इंटरफ़ेस से हूबहू मेल नहीं खाएँगे। यह बग नहीं, अपेक्षित बात है; वरना दोनों की तुलना करने वाला एजेंट ऐसा अंतर रिपोर्ट करेगा जो असल में है ही नहीं। दूसरी बात, डेटासेट की लोकेशन बाद में बिना शुरू से सब दोबारा किए बदली नहीं जा सकती, इसलिए इसे सोच-समझकर चुनिए।
डेटा BigQuery में आने के बाद आपका एजेंट Search Console API के बजाय SQL से क्वेरी करता है, जिससे रो की सीमा और हिस्ट्री की सीमा दोनों एक ही झटके में हट जाती हैं। छोटी साइटों के लिए खर्च BigQuery के फ़्री टियर में ही रहता है, लेकिन बड़ी साइटों के लिए असली पैसा लगता है। इसलिए एजेंट से कहिए कि पूरी टेबल स्कैन करने के बजाय पार्टिशन डेट कॉलम पर फ़िल्टर करे। जो एजेंट किसी बड़ी प्रॉपर्टी के तीन साल के डेटा पर बिना सीमा वाला SELECT * चला देगा, उसका बिल आप लंबे समय तक याद रखेंगे।
ट्रेड-ऑफ़: इसमें पैसा लगता है, सभी विकल्पों में सबसे ज़्यादा इन्फ्रास्ट्रक्चर इसी में है, और पहले दिन यह आपको कुछ नहीं देता। लेकिन कई सालों के विश्लेषण का रास्ता भी सिर्फ़ यही है।
तरीका 5: स्प्रेडशीट ब्रिज
सेटअप: 10 से 20 मिनट। कोई कोड नहीं।
किसी ऐड-ऑन या Apps Script से Search Console का डेटा तय समय पर Google Sheets में एक्सपोर्ट कीजिए, फिर Sheets एक्सेस वाले एजेंट को उस शीट पर लगा दीजिए। अगर आपका एजेंट पहले से स्प्रेडशीट पढ़ता है और आप आज दोपहर तक ही उसके सामने डेटा चाहते हैं, तो यह व्यावहारिक विकल्प है।
ट्रेड-ऑफ़: डेटा उतना ही ताज़ा होता है जितना आखिरी एक्सपोर्ट, सब कुछ पहले से उसी के हिसाब से फ़िल्टर होता है जिसने शीट सेट की, और एजेंट ऐसी फ़ॉलो-अप क्वेरी नहीं चला सकता जिसकी किसी ने पहले से कल्पना न की हो। जबकि एजेंट लिया ही इसी काबिलियत के लिए था। इसे बस काम चलाऊ इंतज़ाम मानिए।
तरीका 6: कोई कनेक्शन ही नहीं
सेटअप: कुछ नहीं।
Search Console में AI पहले से मौजूद है। Google का AI-पावर्ड कॉन्फ़िगरेशन आपको अपनी ज़रूरत का विश्लेषण आम भाषा में लिखने देता है और उसे रिपोर्ट के फ़िल्टर, तुलना और मेट्रिक्स में बदल देता है। “इस तिमाही में /blog वाले मेरे पेजों के ट्रैफ़िक की तुलना पिछले साल की इसी तिमाही से करो” जैसा कुछ लिखिए, और रिपोर्ट खुद सेट हो जाती है।
इसकी सीमाएँ समझ लीजिए, जिन्हें Google खुद साफ़ बताता है: यह सिर्फ़ Search results की Performance रिपोर्ट पर काम करता है, Discover या News पर नहीं; यह फ़िल्टर, तुलना और मेट्रिक्स सेट करता है, लेकिन टेबल को सॉर्ट या डेटा एक्सपोर्ट नहीं कर सकता; और Google चेतावनी देता है कि AI आपकी बात गलत समझ सकता है, इसलिए विश्लेषण पर भरोसा करने से पहले लगाए गए फ़िल्टर देख लीजिए। यह सिर्फ़ कॉन्फ़िगरेशन है: न GA4 और Search Console को साथ जोड़कर सोचता है, न किसी बदलाव की वजह खोजता है।
इसके अलावा, अब Search Console में Google की AI सरफ़ेस से आने वाले ट्रैफ़िक के लिए जेनरेटिव AI परफ़ॉर्मेंस रिपोर्ट भी हैं। अगर आपका सवाल AI सरफ़ेस पर विज़िबिलिटी को लेकर है, तो यही आधिकारिक स्रोत है, और किसी थर्ड-पार्टी का अनुमान इसकी जगह नहीं ले सकता।
कौन-सा तरीका चुनें?
| तरीका | सेटअप | 16 महीने से आगे | किसके लिए सबसे अच्छा |
|---|---|---|---|
| होस्टेड कनेक्टर | 2-5 मिनट | नहीं | जो मार्केटर्स आज ही जवाब चाहते हैं |
| MCP सर्वर | 15-45 मिनट | नहीं | जो डेवलपर्स पहले से MCP क्लाइंट इस्तेमाल करते हैं |
| सीधा API | 1-3 घंटे | नहीं | कस्टम क्वेरी, डेटा अपने ही सिस्टम में |
| BigQuery एक्सपोर्ट | 1 घंटा + 48 घंटे | हाँ | कई सालों का विश्लेषण, बड़ी साइटें |
| स्प्रेडशीट ब्रिज | 10-20 मिनट | नहीं | अस्थायी जुगाड़ |
| बिल्ट-इन AI कॉन्फ़िगरेशन | कुछ नहीं | नहीं | रिपोर्ट जल्दी बनाने के लिए, जाँच-पड़ताल के लिए नहीं |
ज़्यादातर टीमें आखिर में इसी कॉम्बिनेशन पर पहुँचती हैं: रोज़मर्रा के सवालों के लिए होस्टेड कनेक्टर, और बैकग्राउंड में चुपचाप चलता BigQuery एक्सपोर्ट, ताकि एक साल बाद उनके पास ऐसी हिस्ट्री हो जो किसी और के पास नहीं। ये दोनों एक-दूसरे के मुकाबले में नहीं हैं।
क्या एजेंट को Search Console का एक्सेस देना सुरक्षित है?
काफ़ी हद तक, तीन शर्तों के साथ। सिर्फ़ read-only एक्सेस दीजिए। Search Console की परमिशन में साइटमैप सबमिट करने और रिमूवल की रिक्वेस्ट भेजने की क्षमता भी शामिल है, और एजेंट को इनमें से किसी की ज़रूरत नहीं। पर्सनल OAuth ग्रांट के बजाय सीमित स्कोप वाले सर्विस अकाउंट को तरजीह दीजिए, ताकि एक्सेस हटाना किसी एक कर्मचारी के अकाउंट पर निर्भर न रहे। और राइट करने वाले टूल्स को वेब-फ़ेच टूल्स से अलग रखिए: जो एजेंट किसी कॉम्पिटिटर का पेज पढ़ता है, वह बाहर के किसी व्यक्ति का लिखा टेक्स्ट आपके निर्देशों वाली उसी कॉन्टेक्स्ट विंडो में ले आता है, और अगर उस पेज में छिपे हुए कमांड डाले गए हों, तो एक भोला-भाला एजेंट उन पर अमल कर सकता है। हमारा रनटाइम फ़ेच किए गए कंटेंट को अविश्वसनीय मानकर अलग घेरे में रखता है, उस टर्न को “दूषित” (tainted) मार्क करता है, और बाकी टर्न में write-टैग वाला हर टूल तब तक मना कर देता है जब तक कोई इंसान मंज़ूरी न दे। Search Console की क्वेरी read-टैग वाली होती है, इसलिए वह दोनों हालात में सुरक्षित है।
सेटअप की आम गलतियाँ और उनका असली मतलब
| लक्षण | आम वजह | समाधान |
|---|---|---|
| हर क्वेरी पर 403, जबकि API चालू है | सर्विस अकाउंट को प्रॉपर्टी पर यूज़र के तौर पर कभी जोड़ा ही नहीं गया | Search Console की प्रॉपर्टी सेटिंग्स में उसका ईमेल Restricted परमिशन के साथ जोड़िए |
| रिज़ल्ट खाली, कोई एरर नहीं | प्रॉपर्टी URL मेल नहीं खाता: डोमेन प्रॉपर्टी बनाम URL-प्रीफ़िक्स प्रॉपर्टी, या आखिर का स्लैश छूटा हुआ | प्रॉपर्टी स्ट्रिंग को ठीक वैसे ही कॉपी कीजिए जैसे Search Console दिखाता है |
| एजेंट शक पैदा करने वाले गोल-मोल टोटल बताता है | रिज़ल्ट 25,000 रो की सीमा पर कट गया और उसे पूरा मान लिया गया | startRow से पेजिनेशन कीजिए, या एजेंट से कहिए कि कट जाने पर साफ़ बताए |
| आँकड़े Search Console इंटरफ़ेस से अलग हैं | BigQuery एक्सपोर्ट में गुमनाम क्वेरी शामिल नहीं, या तारीख़ की सीमा अलग है | BigQuery में यह अपेक्षित है; वरना टाइमज़ोन और पक्की तारीख़ें जाँचिए |
| बल्क एक्सपोर्ट सेट है, पर कोई डेटासेट नहीं दिख रहा | अभी 48 घंटे पूरे नहीं हुए, या प्रोजेक्ट पर बिलिंग चालू नहीं | इंतज़ार कीजिए, फिर बिलिंग और दोनों IAM रोल जाँचिए |
| MCP सर्वर चालू होता है, पर कोई टूल नहीं दिखाता | क्रेडेंशियल्स का पाथ गलत है, या क्लाइंट के साथ प्रोटोकॉल वर्ज़न मेल नहीं खाता | देखिए कि env पाथ सही जगह पहुँचता है, और सर्वर कौन-सा स्पेक वर्ज़न सपोर्ट करता है |
तरीका कोई भी हो, ये दो बातें सही रखिए
पेजिनेशन ईमानदारी से संभालिए। जो एजेंट 25,000 रो माँगता है, ठीक 25,000 पाता है और फिर टोटल बताता है, वह असल में कटा हुआ डेटा रिपोर्ट कर रहा है। उसे निर्देश दीजिए कि या तो पेजिनेशन करे या साफ़ बताए कि रिज़ल्ट सीमा तक पहुँच गया।
पक्की तारीख़ें इस्तेमाल कीजिए। “पिछला महीना” जैसे सापेक्ष शब्द प्रॉपर्टी के टाइमज़ोन और क्वेरी चलने के समय के हिसाब से तय होते हैं। Search Console के ऐसे विश्लेषण की यही सबसे आम वजह है जो पूरे आत्मविश्वास के साथ, तर्कसंगत लगते हुए भी गलत निकलता है।
कनेक्शन बन जाने के बाद, एजेंट Search Console के डेटा में असल में क्या-क्या खोज सकता है वाले लेख में वे विश्लेषण हैं जो चलाने लायक हैं, और Autopilot तरीका 1 में बताए गए होस्टेड कनेक्टर वाले रास्ते को ही लागू करता है।
Get a free AI ranking consultation
Want your brand to show up when ChatGPT, Gemini and Perplexity answer questions in your market? Tell us about your site and our team will send a personalized strategy.
