SEO विशेषज्ञ एक बड़े साइट का तकनीकी ऑडिट शुरू करता है — और 10 मिनट बाद, Screaming Frog लगातार 403 Forbidden या 429 Too Many Requests दिखाना शुरू कर देता है। सुरक्षा सर्वर ने क्रॉलर को एक हमलावर बॉट समझ लिया और IP पते को ब्लॉक कर दिया। परिणाम — ऑडिट को फिर से शुरू करना पड़ेगा, और ग्राहक को बताना पड़ेगा कि रिपोर्ट में देरी क्यों हुई। प्रॉक्सी को क्रॉलर के लिए सही तरीके से सेट करके समस्या का समाधान किया जा सकता है — आइए समझते हैं कि कैसे।
क्यों साइटें ऑडिट के दौरान Screaming Frog को ब्लॉक करती हैं
Screaming Frog, Sitebulb, JetOctopus और Netpeak Spider तकनीकी रूप से उसी तरह काम करते हैं जैसे खोज इंजन के बॉट: वे तेजी से हजारों URL को एक साथ स्कैन करते हैं, HTML, CSS, JS और छवियों को डाउनलोड करते हैं, रीडायरेक्ट और स्टेटस कोड की जांच करते हैं। साइट की सुरक्षा (Cloudflare, Qrator, DDoS-Guard, होस्टिंग का अंतर्निहित WAF) के दृष्टिकोण से, यह संदिग्ध गतिविधि के रूप में दिखाई देता है — एक ही IP से बहुत अधिक अनुरोध एक छोटे समय में।
विशेष रूप से ऑडिट के दौरान ब्लॉक होने की घटनाएँ होती हैं:
- Wildberries जैसी संरचना पर बड़े ई-कॉमर्स साइटों के लिए, जिनमें पार्सिंग से सुरक्षा है;
- Cloudflare के पीछे की साइटों के लिए जिनमें "Under Attack" मोड या उच्च सुरक्षा स्तर सक्षम है;
- डायनामिक सामग्री वाले पोर्टल्स के लिए, जहाँ प्रत्येक अनुरोध सर्वर पर लोड उत्पन्न करता है (खोज, फ़िल्टर, उत्पाद लिस्टिंग);
- प्रतिस्पर्धियों की साइटों के लिए, जिनका आप अपने डोमेन से विश्लेषण कर रहे हैं — उनके पास आपके IP पर भरोसा करने का कोई कारण नहीं है।
अतिरिक्त जटिलता: यदि एजेंसी के पास एक स्थिर कार्यालय IP है, और साइटों का ऑडिट नियमित रूप से (दिन में कई ग्राहक) किया जाता है, तो यह IP जल्दी से सुरक्षा प्रणालियों की काली सूचियों में चला जाता है। इसके बाद, न केवल वर्तमान, बल्कि भविष्य के ऑडिट भी उसी पते से ब्लॉक हो जाते हैं — यहां तक कि उन साइटों के लिए जो पहले बिना किसी समस्या के खुलती थीं।
उत्तर कोड द्वारा ब्लॉक को कैसे पहचानें
प्रॉक्सी सेटिंग्स को बदलने से पहले, यह समझना महत्वपूर्ण है कि वास्तव में क्या हो रहा है। Screaming Frog स्टेटस कोड कॉलम में उत्तर कोड दिखाता है — इसके द्वारा क्रॉलिंग रुकने का कारण आसानी से पहचाना जा सकता है।
| उत्तर कोड | इसका क्या मतलब है | क्या करना है |
|---|---|---|
| 403 Forbidden | IP साइट की सुरक्षा द्वारा ब्लॉक किया गया है | IP बदलें, क्रॉलिंग की गति कम करें |
| 429 Too Many Requests | एक ही समय में अनुरोधों की सीमा से अधिक हो गया है | थ्रेड की संख्या कम करें, देरी जोड़ें |
| 503 Service Unavailable | सर्वर ओवरलोडेड है या बॉट सुरक्षा सक्षम है | User-Agent बदलें, रेजिडेंट IP का उपयोग करें |
| कोई उत्तर नहीं / टाइमआउट | IP काली सूची में है, अनुरोध नहीं पहुंचते | प्रॉक्सी पूल को पूरी तरह से बदलें |
यदि रिपोर्ट में हजारों URL पर एक ही कोड बार-बार दिखाई देता है — तो यह लगभग हमेशा IP द्वारा ब्लॉक होता है, न कि साइट की वास्तविक समस्या। सिद्धांत की जांच करना आसान है: उस समस्या URL को उसी IP से सामान्य ब्राउज़र में खोलें। यदि पृष्ठ सामान्य रूप से खुलता है, जबकि Screaming Frog 403 प्राप्त करता है — तो समस्या क्रॉलर में है, साइट में नहीं।
SEO क्रॉलिंग के लिए कौन सी प्रॉक्सी उपयुक्त हैं
प्रॉक्सी के प्रकार का चयन कार्य पर निर्भर करता है: अपने साइट का एक बार का ऑडिट, प्रतियोगियों की नियमित निगरानी या सुरक्षित मार्केटप्लेस का स्कैनिंग। हम तीन मुख्य प्रकारों और उनके क्रॉलर्स के लिए उपयुक्तता को समझते हैं।
| प्रॉक्सी का प्रकार | गति | ब्लॉक होने का जोखिम | कब उपयोग करें |
|---|---|---|---|
| डेटा सेंटर प्रॉक्सी | उच्च | सुरक्षित साइटों पर मध्यम-उच्च | अपने साइट का ऑडिट बिना सख्त सुरक्षा के |
| रेजिडेंट प्रॉक्सी | मध्यम | कम | प्रतिस्पर्धियों का ऑडिट, Cloudflare के पीछे की साइटें, मार्केटप्लेस |
| मोबाइल प्रॉक्सी | मध्यम-निम्न | न्यूनतम | सबसे आक्रामक सुरक्षा, दुर्लभ बिंदु ऑडिट |
अधिकांश नियमित तकनीकी ऑडिट के लिए, रेजिडेंट प्रॉक्सी सबसे अच्छा संतुलन प्रदान करते हैं — वे प्रदाताओं के वास्तविक IP पते का उपयोग करते हैं, इसलिए साइट की सुरक्षा क्रॉलर के अनुरोधों को सामान्य उपयोगकर्ता के ट्रैफ़िक के रूप में मानती है। यह विशेष रूप से महत्वपूर्ण है यदि आप अपने डोमेन का विश्लेषण नहीं कर रहे हैं, बल्कि किसी प्रतिस्पर्धी या कठोर एंटी-बॉट सिस्टम के साथ मार्केटप्लेस का विश्लेषण कर रहे हैं।
डेटा सेंटर प्रॉक्सी एक अच्छा विकल्प बनी रहती हैं जब आप अपने साइट का ऑडिट कर रहे हैं और पहले से IP रेंज को WAF या Cloudflare के स्तर पर व्हाइटलिस्ट में जोड़ सकते हैं — तब स्कैनिंग की गति अधिकतम होगी बिना ब्लॉक होने के जोखिम के।
Screaming Frog में प्रॉक्सी का चरण-दर-चरण सेटअप
Screaming Frog "बॉक्स से बाहर" प्रॉक्सी का समर्थन करता है, सेटअप में कुछ मिनट लगते हैं:
- प्रोग्राम खोलें और मेनू में जाएं Configuration → System → Proxy.
- Use Proxy Server for All Traffic के लिए चेक बॉक्स लगाएं।
- प्रदाता से प्राप्त प्रॉक्सी सर्वर का पता और पोर्ट दर्ज करें।
- यदि प्रॉक्सी लॉगिन और पासवर्ड द्वारा प्रमाणीकरण की आवश्यकता है — तो पहले अनुरोध पर पॉप-अप में उन्हें निर्दिष्ट करें।
- OK पर क्लिक करें और सेटिंग्स लागू करने के लिए क्रॉलिंग को फिर से शुरू करें।
एक महत्वपूर्ण बिंदु: Screaming Frog मुफ्त और भुगतान संस्करण में एक समय में केवल एक प्रॉक्सी सर्वर के साथ काम कर सकता है। यदि आपको तात्कालिक IP रोटेशन की आवश्यकता है (50,000 पृष्ठों से अधिक स्कैन करते समय प्रासंगिक), तो प्रदाता की ओर से स्वचालित IP परिवर्तन के साथ प्रॉक्सी का उपयोग करें — यह स्वयं क्रॉलर में सेट नहीं किया जाता है, बल्कि प्रॉक्सी सेवा के व्यक्तिगत खाते में सेट किया जाता है, जहाँ IP परिवर्तन का अंतराल निर्धारित किया जाता है (उदाहरण के लिए, हर 10 मिनट या प्रत्येक नए अनुरोध पर)।
यह योजना एक पते पर लोड को कम करती है: क्रॉलर एक पोर्ट के साथ काम करना जारी रखता है, और उसके पीछे IP स्वचालित रूप से बदलता है, और साइट एक विशेष पते से अत्यधिक अनुरोधों की आवृत्ति नहीं देखती है।
बड़े साइटों के लिए गति और थ्रेड सेटिंग्स
काम करने वाली प्रॉक्सी के साथ भी, अत्यधिक आक्रामक क्रॉलिंग गति सेटिंग्स ब्लॉक को प्रेरित करेंगी। Screaming Frog में इसके लिए Configuration → Speed अनुभाग जिम्मेदार है। 100,000 पृष्ठों वाली साइटों के लिए अनुशंसित मान:
- Max Threads: सुरक्षित साइटों के लिए 2–5, बिना सख्त सुरक्षा वाली साइटों के लिए 10–15;
- Max URI/s: प्रारंभ में 2–3 अनुरोध प्रति सेकंड तक सीमित करें, धीरे-धीरे बढ़ाएं, उत्तर कोड पर नज़र रखते हुए;
- Custom User-Agent: Configuration → HTTP Header अनुभाग में वास्तविक ब्राउज़र का User-Agent उपयोग करें, यदि साइट क्रॉलर्स को हेडर के आधार पर ब्लॉक करती है;
- Respect robots.txt / crawl-delay: यदि यह निर्दिष्ट है तो Crawl-delay निर्देश का सम्मान करें — अनदेखी अक्सर सर्वर स्तर पर बैन का कारण बनती है।
बॉट सुरक्षा के साथ आक्रामक साइटों के लिए, केवल वहां JavaScript Rendering मोड को सक्षम करना भी फायदेमंद है जहाँ यह वास्तव में आवश्यक है (React/Vue पर SPA साइटें) — JS का रेंडरिंग सर्वर पर लोड को अचानक बढ़ा देता है और एक IP के माध्यम से क्रॉल करते समय ब्लॉक होने की संभावना को बढ़ा देता है।
100,000+ पृष्ठों को स्कैन करते समय IP का रोटेशन
जितना बड़ा साइट होगा, उतना ही महत्वपूर्ण है IP पतों के बीच लोड को सही तरीके से वितरित करना। इस पैमाने के ऑडिट के लिए दो योजनाएँ काम करती हैं:
समय के अनुसार रोटेशन। IP हर 5–15 मिनट में स्वचालित रूप से बदलता है, अनुरोधों की संख्या की परवाह किए बिना। यह समान रूप से लंबे समय तक क्रॉलिंग के लिए उपयुक्त है, जब स्कैनिंग कई घंटों तक फैली होती है।
अनुरोध के अनुसार रोटेशन। प्रत्येक नया HTTP अनुरोध नए IP से पूल से जाता है। यह मोड ब्लॉक से अधिकतम सुरक्षा प्रदान करता है, लेकिन कुकी-आधारित प्रमाणीकरण या साइट के सत्रीय पैरामीटर के साथ सही काम करने में बाधा डाल सकता है — एक शुद्ध तकनीकी ऑडिट (स्टेटस कोड, रीडायरेक्ट, मेटा-टैग संग्रह) के लिए यह महत्वपूर्ण नहीं है।
उन एजेंसियों के लिए जो कई ग्राहक साइटों का समानांतर ऑडिट करती हैं, यह परियोजनाओं के अनुसार IP पूल को विभाजित करना समझदारी है — यह उस स्थिति को रोकता है जहाँ एक डोमेन पर ब्लॉक "गलती से" दूसरे साइट के साथ काम करते समय IP की प्रतिष्ठा पर फैलता है।
व्यवहार में सलाह: बड़े ऑडिट से पहले, वर्तमान गति और प्रॉक्सी सेटिंग्स के साथ 500–1000 URL पर एक परीक्षण क्रॉलिंग चलाएँ। यदि इस समय में 403/429 त्रुटियाँ नहीं आईं, तो आप पूरे साइट पर स्कैनिंग को सुरक्षित रूप से बढ़ा सकते हैं।
ऑडिट शुरू करने से पहले चेकलिस्ट
- ✅ प्रॉक्सी कनेक्ट किया गया है और उपलब्धता पर परीक्षण किया गया है (curl या अलग ब्राउज़र के माध्यम से जांच);
- ✅ Max Threads और Max URI/s पहले प्रोग्राम के लिए संवेदनशीलता से सेट किए गए हैं;
- ✅ User-Agent सही तरीके से सेट किया गया है, WAF पर संदेह नहीं उठाता;
- ✅ Respect robots.txt सक्षम है, यदि साइट स्पष्ट रूप से Crawl-delay का पालन करने के लिए कहती है;
- ✅ JavaScript Rendering केवल वास्तविक आवश्यकता पर सक्षम है;
- ✅ साइट के आकार के 20,000–30,000 पृष्ठों से अधिक होने पर IP का रोटेशन सेट किया गया है;
- ✅ क्रॉलिंग की प्रगति को सहेजना सक्षम है (Configuration → Save Crawl) सत्र टूटने की स्थिति में;
- ✅ मार्केटप्लेस और सुरक्षित पोर्टल्स के ऑडिट के लिए रेजिडेंट या मोबाइल प्रॉक्सी का चयन किया गया है, डेटा सेंटर के बजाय।
प्रॉक्सी के माध्यम से क्रॉल करते समय सामान्य गलतियाँ
शुरुआत में बहुत अधिक गति। विशेषज्ञ अक्सर तुरंत अधिकतम थ्रेड सेट करते हैं, ऑडिट को तेज करने की उम्मीद में। परिणामस्वरूप, साइट की सुरक्षा तुरंत प्रतिक्रिया करती है, और कुछ मिनटों में पूरा प्रॉक्सी पूल काली सूची में चला जाता है।
सभी ग्राहक परियोजनाओं के लिए एक स्थिर IP। यदि एजेंसी एक ही डेटा सेंटर प्रॉक्सी का उपयोग करती है, तो महीने में दर्जनों ऑडिट के लिए, उस IP की प्रतिष्ठा जल्दी गिर जाती है — विभिन्न साइटों की सुरक्षा प्रणालियाँ संदिग्ध पतों के बारे में डेटा साझा करती हैं (उदाहरण के लिए, Cloudflare IP Reputation)।
geo-टारगेटिंग की अनदेखी। यदि ऑडिट की जाने वाली साइट एक विशिष्ट क्षेत्र के लिए सेट की गई है (उदाहरण के लिए, एक रूसी ई-कॉमर्स साइट जो विदेशी ट्रैफ़िक को भू-प्रतिबंधित करती है), तो किसी अन्य देश के IP के साथ प्रॉक्सी का उपयोग करना खुद में पहुंच को सीमित करने का कारण बनेगा — यहां तक कि आक्रामक क्रॉलिंग के बिना भी।
प्रक्रिया में निगरानी की कमी। कुछ घंटों के लिए क्रॉलिंग शुरू करने के बाद, विशेषज्ञ अक्सर मध्यवर्ती उत्तर कोड की जांच नहीं करते हैं। परिणामस्वरूप, वे केवल समाप्ति पर समस्या का पता लगाते हैं, जब रिपोर्ट का आधा हिस्सा ब्लॉकिंग त्रुटियों से भरा होता है, न कि साइट के वास्तविक डेटा से।
निष्कर्ष
Screaming Frog में तकनीकी ऑडिट के दौरान ब्लॉकिंग लगभग हमेशा तीन कारकों के संयोजन से हल होती है: सही प्रॉक्सी का प्रकार, उचित क्रॉलिंग गति और सही IP रोटेशन। बिना सख्त सुरक्षा वाले अपने साइटों के लिए, डेटा सेंटर प्रॉक्सी के साथ व्हाइटलिस्ट में जोड़ना पर्याप्त है। प्रतियोगियों, मार्केटप्लेस और Cloudflare के पीछे की साइटों के ऑडिट के लिए, ऐसे IP की आवश्यकता होती है जो सामान्य उपयोगकर्ता ट्रैफ़िक के रूप में दिखते हैं।
यदि आप नियमित रूप से अन्य डोमेन या सुरक्षित साइटों का ऑडिट करते हैं, तो हम रेजिडेंट प्रॉक्सी से शुरू करने की सिफारिश करते हैं — वे सबसे आक्रामक एंटी-बॉट सिस्टम पर ब्लॉकिंग के जोखिम को कम करते हैं। अधिकतम सुरक्षित संसाधनों पर बिंदु कार्यों के लिए, मोबाइल प्रॉक्सी पर विचार करना चाहिए, और अपनी अवसंरचना के बड़े ऑडिट के लिए डेटा सेंटर प्रॉक्सी एक अच्छा और तेज़ समाधान बनी रहती हैं।