एक साल पहले, Google की खोज परिणामों को एक GET-रिक्वेस्ट के साथ num=100 पैरामीटर के साथ स्पार्स करना संभव था - सौ परिणाम शुद्ध HTML में आते थे। 2026 में, यह अब काम नहीं करता: Google ने बिना JavaScript के पहुंच को समाप्त कर दिया, प्रति पृष्ठ सौ परिणामों को काट दिया और खोज परिणामों में AI Overviews ब्लॉक जोड़ा, जो असिंक्रोनस रूप से रेंडर होता है और हर IP से दिखाई नहीं देता। हम समझते हैं कि नए हालात में SERP को कैसे इकट्ठा किया जाए, जहाँ छिपे हुए जाल हैं और क्यों प्रॉक्सी के प्रकार का चयन पार्सर से भी अधिक महत्वपूर्ण हो गया है।
यह गाइड किसके लिए है
खोज परिणामों का पार्सिंग (SERP scraping) केवल SEO स्थितियों के बारे में नहीं है। आज इसका उपयोग करते हैं:
- SEO विशेषज्ञ और एजेंसियाँ — ऑर्गेनिक ट्रैफिक, फीचर्ड स्निप्पेट्स, "लोग भी पूछते हैं", स्थानीय परिणाम और यह कि क्या वेबसाइट AI Overviews में शामिल हुई है, को ट्रैक करते हैं।
- बाजार विश्लेषक — यह मॉनिटर करते हैं कि Google वाणिज्यिक खोजों पर AI ब्लॉकों में किसे उद्धृत करता है, और प्रतिस्पर्धियों के पहले पृष्ठ में क्या बदलाव आता है।
- AI और डेटा टीमें — SERP को RAG सिस्टम, मॉडल प्रशिक्षण और तथ्य-जांच के लिए डेटा स्रोत के रूप में इकट्ठा करती हैं।
सभी को एक समस्या साझा है: Google 2026 में सक्रिय रूप से स्वचालित ट्रैफिक को जीवित ट्रैफिक से अलग करता है, और सही बुनियादी ढांचे के बिना डेटा संग्रह पहले कुछ दर्जन खोजों पर टूट जाता है।
क्या बदला: स्क्रैपर्स पर Google के तीन हमले
गाइड को ईमानदार रखने के लिए, हम यह समझते हैं कि पुराने निर्देश अब क्यों काम नहीं करते।
जनवरी 2025 — SearchGuard। Google ने JavaScript चैलेंज सिस्टम को लागू किया: सामान्य HTTP अनुरोध requests या httpx के माध्यम से अब HTML नहीं प्राप्त करता, बल्कि चैलेंज पृष्ठ प्राप्त करता है। बिना JavaScript के, परिणाम देखना संभव नहीं है — सीधे "फेस-टू-फेस" पार्सिंग तुरंत गिर जाती है।
सितंबर 2025 — num=100 का अंत। Google ने उस पैरामीटर को हटा दिया, जो एक अनुरोध पर 100 परिणाम देता था। अब शीर्ष 100 दस अलग-अलग अनुरोधों के साथ पेजिनेशन है। गहरे मॉनिटरिंग के लिए, यह सचमुच अनुरोधों की संख्या में दस गुना वृद्धि है (और, तदनुसार, प्रॉक्सी और बजट पर लोड)।
दिसंबर 2025 — कानूनी दबाव। 19 दिसंबर 2025 को Google ने SerpApi के खिलाफ DMCA शिकायत दर्ज की, यह कहते हुए कि SearchGuard एक "तकनीकी सुरक्षा उपाय" (technological protection measure) है, और इसके обход पर एंटी-परिस्थितियों के नियम लागू होते हैं। यह प्रकरण अभी तक हल नहीं हुआ है, लेकिन यह टोन सेट करता है: Google का ग्रे पार्सिंग तकनीकी और कानूनी रूप से महंगा होता जा रहा है।
अलग से उल्लेखनीय है: Google का आधिकारिक कस्टम सर्च API बंद किया जा रहा है — मौजूदा ग्राहकों को 1 जनवरी 2027 तक माइग्रेशन की समय सीमा दी गई है। इसका मतलब है कि "कानूनी" विकल्प भी संकुचित हो रहा है।
खोज परिणामों की मुख्य नई विशेषता — AI Overviews
AI Overviews (पूर्व में SGE) — यह खोज परिणामों के शीर्ष पर स्रोतों के लिंक के साथ एक AI द्वारा उत्पन्न सारांश है। स्क्रैपिंग के लिए, यह 2026 का सबसे जटिल तत्व है, तीन कारणों से।
इनकी संख्या अधिक है। Ahrefs के अनुसार, AI Overviews लगभग 30% खोजों में दिखाई देते हैं; बाद के अनुमानों (Olostep) के अनुसार, यह सभी खोजों का 48% और सूचना संबंधी खोजों का 80% तक पहुँचता है। इस ब्लॉक को नजरअंदाज करना — यह जानबूझकर अधूरी खोज परिणामों को इकट्ठा करना है।
ये असिंक्रोनस रूप से रेंडर होते हैं। ब्लॉक तीन अवस्थाओं में मौजूद होता है: यह HTML में तुरंत आता है (सबसे कम बार), मुख्य पृष्ठ के कुछ सेकंड बाद JavaScript के माध्यम से लोड होता है (सबसे सामान्य मामला) या बिल्कुल नहीं दिखाई देता। लेट लोडिंग में कच्चा HTTP उत्तर एक खाली कंटेनर होता है — सामग्री बाद में खींची जाती है, और पार्सर को इंतजार करना पड़ता है (व्यवहार में — ब्राउज़र स्वचालन में लगभग 8 सेकंड)।
ये हर IP से दिखाई नहीं देते। यह एक महत्वपूर्ण बिंदु है, जिसके बारे में पुराने गाइड चुप हैं: Google मोबाइल उपयोगकर्ताओं को AI खोज के लिए प्राथमिक दर्शक मानता है। व्यवहार में इसका मतलब है कि डेटा सेंटर-IP से AI Overview अक्सर बिल्कुल नहीं दिया जाता है, जबकि उसी अनुरोध को मोबाइल ऑपरेटर के माध्यम से पूरा ब्लॉक लौटाता है। यहां तक कि शीर्ष एग्रीगेटर्स भी अधूरापन को स्वीकार करते हैं: SerpApi ने 2026 की शुरुआत में AI Overviews की सफल पहचान के बारे में लगभग 68% का दावा किया।
चरण-दर-चरण विश्लेषण: 2026 में SERP कैसे इकट्ठा करें
- आकार निर्धारित करें। ~100 अनुरोध प्रति दिन अपनी ब्राउज़र स्वचालन पर वास्तव में खींचा जा सकता है। 100 से 10,000 तक — एक प्रबंधित पार्सर या SERP-API की आवश्यकता होती है। 10,000 से अधिक प्रति दिन बिना एंटरप्राइज बुनियादी ढांचे के बैचों और वेबहुक के बिना नहीं किया जा सकता। यह आगे के सभी स्टैक को निर्धारित करता है।
- सही URL इकट्ठा करें। बुनियादी एंडपॉइंट — /search, प्रमुख पैरामीटर: q (अनुरोध, URL-एन्कोडिंग), hl (इंटरफेस की भाषा), gl (खोज का देश), start (पेजिनेशन: start=10 — दूसरी पृष्ठ, start=20 — तीसरी और इसी तरह)। याद रखें: num=100 अब काम नहीं करता, गहराई केवल पेजिनेशन के माध्यम से बढ़ती है।
- ब्राउज़र रेंडरिंग का उपयोग करें। चूंकि बिना JavaScript के कोई परिणाम नहीं है, बुनियादी स्टैक — Playwright या Selenium के साथ हेडलेस Chromium। स्वचालन के मार्करों को अवश्य हटा दें (फ्लैग --disable-blink-features=AutomationControlled), अन्यथा एंटी-बॉट नियंत्रित ब्राउज़र को नेविगेटर गुणों के आधार पर पहचान लेगा।
- AI Overview की प्रतीक्षा करें। पृष्ठ लोड होने के बाद तुरंत DOM को न पकड़ें: नेटवर्कआइडल को स्थिर होने दें और ब्लॉक के लोड होने की प्रतीक्षा करें (संकेत — 8 सेकंड तक)। ब्लॉक की उपस्थिति को "AI Overview" शीर्षक के पाठ द्वारा अधिक विश्वसनीयता से निर्धारित किया जाता है, न कि CSS वर्गों द्वारा — ये Google में गतिशील होते हैं और बदलते हैं (शर्तों के अनुसार Kevs9, Y3BBE आज एक हैं, कल दूसरे)।
- संरचना के अनुसार पार्स करें, न कि वर्गों के अनुसार। ऑर्गेनिक को शीर्षक टैग (h3) और अर्थशास्त्र के अनुसार लें, न कि नाजुक वर्ग नामों के अनुसार। 2026 में उपलब्ध परिणामों में: ऑर्गेनिक परिणाम, फीचर्ड स्निप्पेट्स, "लोग भी पूछते हैं", संबंधित खोजें, ज्ञान ग्राफ, स्थानीय पैक, विज्ञापन और AI Overview के भीतर उद्धरण।
- IP को घुमाएं और धीमा करें। अनुरोधों के बीच यथार्थवादी विराम (4–12 सेकंड) डालें और लगभग हर 5 मिनट में IP बदलें, शहर/ऑपरेटर को बदलते रहें। बहुत समान रिदम और एक IP — कैप्चा तक पहुँचने का सबसे तेज़ रास्ता है।
छिपे हुए जाल
- “खाली” AI Overview। यदि आप लोडिंग के तुरंत बाद DOM को लेते हैं, तो लेटेड ब्लॉक खाली होगा — और आप यह तय करेंगे कि यह नहीं है। हमेशा प्रतीक्षा और पुनः जांच का समय रखें।
- डोग्रिडिंग के लिए एक बार की सत्र। कुछ API में AI Overview के लेटेड लोड के लिए सत्र की कुंजी एक बार की होती है और लगभग 60 सेकंड तक जीवित रहती है — इसे बाद में पुनः उपयोग करने की उम्मीद न करें।
- डेटा सेंटर पर झूठी बचत। सस्ते डेटा सेंटर-IP 5–10 अनुरोधों पर कैप्चा पकड़ते हैं और इसके अलावा AI Overviews नहीं दिखाते हैं। बचत अधूरे डेटा और बर्बाद समय में बदल जाती है।
- नाजुक चयनकर्ता। CSS वर्ग नामों से जुड़े — पार्सर निकटतम डिज़ाइन परिवर्तन पर टूट जाएगा। पाठ और संरचना पर टिके रहें।
- अनुरोधों का समान प्रिंट। सभी धाराओं पर समान User-Agent, समय और हेडर बॉटनेट का संकेत देते हैं। अपने फिंगरप्रिंट को IP की तरह विविधता दें।
किस प्रकार की प्रॉक्सी चुनें
2026 में, प्रॉक्सी, न कि पार्सर, यह निर्धारित करता है कि क्या आप पूर्ण परिणाम देखेंगे। कार्यों के अनुसार विभाजित करें।
मोबाइल प्रॉक्सी — AI Overviews और सबसे "भारी" अनुरोधों के लिए। चूंकि Google AI ब्लॉकों को पहले मोबाइल दर्शकों को देता है, वास्तविक ऑपरेटर IP (T-Mobile, Verizon, Vodafone और समान) सबसे स्थिर रूप से AI Overview को ट्रिगर करते हैं और अधिक अनुरोधों को सहन करते हैं — अवलोकनों के अनुसार, 50–200 अनुरोधों तक घर्षण आने से पहले, जबकि डेटा सेंटर पर 5–10। इसके अलावा, मोबाइल CGNAT-IP एक पते को सैकड़ों जीवित ग्राहकों के साथ साझा करता है, इसलिए Google इसे प्रतिबंधित करने से डरता है। यदि आपका कार्य विशेष रूप से AI Overviews को इकट्ठा करना या सबसे सुरक्षित SERP की निगरानी करना है, तो मोबाइल प्रॉक्सी से शुरू करें।
रेसिडेंशियल प्रॉक्सी — ऑर्गेनिक और मात्रा के लिए कार्यशील घोड़ा। सामान्य खोज परिणाम, स्थितियों, फीचर्ड स्निप्पेट्स और स्थानीय पैक को इकट्ठा करने के लिए, रेसिडेंशियल IP (घरेलू प्रदाताओं के पते) मूल्य और सफलता का सबसे अच्छा अनुपात देते हैं। इन्हें वास्तविक उपयोगकर्ता से अलग करना कठिन है, और रोटेशन एक ही पते से संग्रह को स्केल करने की अनुमति देता है। जब AI Overview फोकस में नहीं है, बल्कि मात्रा और भूगोल महत्वपूर्ण हैं, तो रेसिडेंशियल प्रॉक्सी के साथ रोटेशन सबसे अच्छा विकल्प है।
डेटा सेंटर — केवल ड्राफ्ट रन के लिए। तेजी से और सस्ते, लेकिन Google के खिलाफ 2026 में कुछ ही अनुरोध जीवित रहते हैं और AI ब्लॉकों को नहीं देखते हैं। यह पार्सर की लॉजिक को डिबग करने के लिए उपयुक्त है, न कि वास्तविक संग्रह के लिए।
यदि आप निश्चित नहीं हैं कि किसी विशेष कार्य के लिए क्या लेना है, तो 2026 में रेसिडेंशियल बनाम मोबाइल प्रॉक्सी की समीक्षा से शुरू करें: वहां विस्तार से बताया गया है कि किस प्रकार का विकल्प पैसे बचाता है और कहाँ डेटा।
निष्कर्ष
2026 में Google का पार्सिंग "पार्सर लिखने" का कार्य नहीं रहा। SearchGuard ने JavaScript को रेंडर करने के लिए मजबूर किया, num=100 की समाप्ति ने अनुरोधों की संख्या को दस गुना बढ़ा दिया, और AI Overviews ने एक ब्लॉक जोड़ा जो मुख्य रूप से मोबाइल IP से दिखाई देता है और देरी से लोड होता है। तकनीकी रूप से सब कुछ हल किया जा सकता है: ब्राउज़र स्वचालन, संरचना के अनुसार पार्सिंग, समझदारी से विराम और रोटेशन। लेकिन वह आधार, जिस पर संग्रह की पूर्णता और स्थिरता टिकी होती है, वह सही प्रॉक्सी है: AI Overviews और सुरक्षित अनुरोधों के लिए मोबाइल, ऑर्गेनिक और मात्रा के लिए रेसिडेंशियल। अपनी आवश्यकता के अनुसार प्रॉक्सी के प्रकार से शुरू करें — और पार्सर कैप्चा पर ठोकर खाना बंद कर देगा।
```