मंगलवार, 31 मार्च, 2026
अगर आपने Search Off the Record पॉडकास्ट का 105वां एपिसोड सुना है, तो आपने हमें एक ऐसे विषय पर गहराई से बात करते हुए सुना होगा जो हमारे (और हमारे सर्वर के) दिल के बेहद करीब है: Googlebot के काम करने का तरीका.
काफ़ी समय से, "Googlebot" नाम से एक ऐसे रोबोट की इमेज बनती है जो बिना थके, इंटरनेट पर मौजूद कॉन्टेंट को व्यवस्थित तरीके से पढ़ता है. हालांकि, सच्चाई थोड़ी मुश्किल और ज़्यादा दिलचस्प है. आज हम अपने क्रॉलिंग इन्फ़्रास्ट्रक्चर के बारे में बात करेंगे. साथ ही, हम खास तौर पर उस चीज़ पर फ़ोकस करेंगे जिसकी वजह से हमें परेशानी होती है: बाइटसाइज़ की सीमाएं.
पहली बात, Googlebot कोई एक प्रोग्राम नहीं है
सबसे पहले, हम इतिहास में मौजूद एक गलत नाम को ठीक कर लेते हैं. साल 2000 की शुरुआत में, Google के पास सिर्फ़ एक प्रॉडक्ट था. इसलिए, हमारे पास सिर्फ़ एक क्रॉलर था. "Googlebot" नाम का इस्तेमाल जारी रहा. हालांकि, आज Googlebot सिर्फ़ एक ऐसे प्लैटफ़ॉर्म का इस्तेमाल करता है जो एक सेंट्रलाइज़्ड क्रॉलिंग प्लैटफ़ॉर्म जैसा दिखता है.
जब आपको अपने सर्वर लॉग में Googlebot दिखता है, तो इसका मतलब है कि आपने सिर्फ़ Google Search देखा है. Google Shopping, AdSense वगैरह जैसे कई अन्य क्लाइंट, क्रॉल करने के अनुरोध इसी बुनियादी ढांचे के ज़रिए भेजते हैं. हालांकि, इनके क्रॉलर के नाम अलग-अलग होते हैं. ज़्यादा जानकारी के लिए, Google क्रॉलर के बुनियादी ढांचे की साइट पर जाएं.
2 एमबी की सीमा: आपके बाइट का क्या होता है?
यहां कुछ हद तक भ्रम की स्थिति पैदा हो सकती है. क्रॉलर इंफ़्रास्ट्रक्चर के हर क्लाइंट को, फ़ेच करने के लिए कुछ सेटिंग सेट करनी होती हैं. इन सेटिंग में, उपयोगकर्ता एजेंट स्ट्रिंग, robots.txt में उपयोगकर्ता एजेंट टोकन की खोज, और किसी एक यूआरएल से फ़ेच किए जाने वाले बाइट की संख्या शामिल होती है.
Googlebot, फ़िलहाल किसी भी यूआरएल के लिए ज़्यादा से ज़्यादा 2 एमबी का डेटा फ़ेच करता है. इसमें PDF शामिल नहीं हैं. इसका मतलब है कि यह किसी रिसॉर्स के सिर्फ़ शुरुआती 2 एमबी को क्रॉल करता है. इसमें एचटीटीपी हेडर भी शामिल है. PDF फ़ाइलों के लिए, यह सीमा 64 एमबी है.
इमेज और वीडियो क्रॉलर के लिए, थ्रेशोल्ड वैल्यू की एक बड़ी रेंज होती है. यह काफ़ी हद तक उस प्रॉडक्ट पर निर्भर करती है जिसके लिए वे डेटा फ़ेच कर रहे हैं. उदाहरण के लिए, इमेज सर्च के मुकाबले फ़ेविकॉन फ़ेच करने की सीमा बहुत कम हो सकती है.
अगर कोई अन्य क्रॉलर सीमा तय नहीं करता है, तो कॉन्टेंट टाइप के बावजूद डिफ़ॉल्ट रूप से 15 एमबी की सीमा लागू होती है.
आपके सर्वर से वायर के ज़रिए भेजे गए बाइट पर इसका क्या असर पड़ेगा?
- आंशिक फ़ेचिंग: अगर आपकी एचटीएमएल फ़ाइल का साइज़ 2 एमबी से ज़्यादा है, तो Googlebot पेज को अस्वीकार नहीं करता. इसके बजाय, यह फ़ेच करने की प्रोसेस को ठीक 2 एमबी पर रोक देता है. ध्यान दें कि इस सीमा में एचटीटीपी अनुरोध के हेडर शामिल हैं.
- कटऑफ़ को प्रोसेस करना: डाउनलोड किए गए हिस्से (पहले 2 एमबी बाइट) को हमारे इंडेक्सिंग सिस्टम और Web Rendering Service (WRS) को इस तरह से भेजा जाता है जैसे कि यह पूरी फ़ाइल हो.
- अनदेखे बाइट: 2 एमबी की सीमा के बाद मौजूद किसी भी बाइट को पूरी तरह से अनदेखा कर दिया जाता है. उन्हें न तो फ़ेच किया जाता है, न रेंडर किया जाता है, और न ही इंडेक्स किया जाता है.
- संसाधन शामिल करना: एचटीएमएल में बताए गए हर संसाधन (मीडिया, फ़ॉन्ट, और कुछ खास फ़ाइलों को छोड़कर) को WRS, Googlebot की मदद से फ़ेच करेगा. जैसे, पैरंट एचटीएमएल को फ़ेच किया जाता है. इनका अपना अलग बाइट काउंटर होता है, जो हर यूआरएल के लिए होता है. साथ ही, इन्हें पैरंट पेज के साइज़ में नहीं गिना जाता.
वेब पर मौजूद ज़्यादातर वेबसाइटों के लिए, 2 एमबी का एचटीएमएल पेलोड बहुत ज़्यादा होता है. इसलिए, आपको कभी भी इस सीमा तक पहुंचने की ज़रूरत नहीं पड़ेगी. हालांकि, अगर आपके पेज में बहुत ज़्यादा इनलाइन base64 इमेज, इनलाइन सीएसएस/JavaScript के बड़े ब्लॉक शामिल हैं या यह मेगाबाइट के मेन्यू से शुरू होता है, तो हो सकता है कि आपका असल टेक्स्ट वाला कॉन्टेंट या ज़रूरी स्ट्रक्चर्ड डेटा, गलती से 2 एमबी से ज़्यादा हो जाए. अगर उन ज़रूरी बाइट को फ़ेच नहीं किया जाता है, तो Googlebot के लिए वे मौजूद नहीं होती हैं.
बाइट रेंडर करना
जब क्रॉलर, बाइट (सीमा तक) को वापस पा लेता है, तो वह WRS को इसकी जानकारी देता है. WRS, JavaScript को प्रोसेस करता है और क्लाइंट-साइड कोड को एक्ज़ीक्यूट करता है. यह काम, आधुनिक ब्राउज़र की तरह ही किया जाता है, ताकि पेज की फ़ाइनल विज़ुअल और टेक्स्ट वाली स्थिति को समझा जा सके. रेंडरिंग की प्रोसेस में, JavaScript और सीएसएस फ़ाइलों को पुल किया जाता है और उन्हें एक्ज़ीक्यूट किया जाता है. साथ ही, XHR अनुरोधों को प्रोसेस किया जाता है, ताकि पेज के टेक्स्ट वाले कॉन्टेंट और स्ट्रक्चर को बेहतर तरीके से समझा जा सके. इसमें इमेज या वीडियो का अनुरोध नहीं किया जाता. अनुरोध किए गए हर रिसॉर्स के लिए, 2 एमबी की सीमा भी लागू होती है.
हालांकि, ध्यान रखें कि WRS सिर्फ़ उस कोड को लागू कर सकता है जिसे क्रॉलर ने फ़ेच किया है. इसके अलावा, WRS बिना किसी स्टेटस के काम करता है. इसका मतलब है कि यह अनुरोधों के बीच लोकल स्टोरेज और सेशन डेटा को मिटा देता है. इससे, डाइनैमिक और JavaScript पर निर्भर एलिमेंट को हमारे सिस्टम किस तरह से समझते हैं, इस पर असर पड़ सकता है.
अपने बाइट के लिए सबसे सही तरीके
यह पक्का करने के लिए कि Googlebot आपके कॉन्टेंट को बेहतर तरीके से फ़ेच और समझ सके, बाइट-लेवल के इन सबसे सही तरीकों का ध्यान रखें:
- अपने एचटीएमएल को छोटा रखें: भारी सीएसएस और JavaScript को बाहरी फ़ाइलों में ले जाएं. शुरुआती एचटीएमएल दस्तावेज़ का साइज़ 2 एमबी से ज़्यादा नहीं होना चाहिए. हालांकि, बाहरी स्क्रिप्ट और स्टाइलशीट को अलग से फ़ेच किया जाता है. इन पर अपनी सीमाएं लागू होती हैं.
-
क्रम मायने रखता है: अपने सबसे ज़रूरी एलिमेंट — जैसे कि मेटा टैग,
<title>एलिमेंट,<link>एलिमेंट, कैननिकल, और ज़रूरी स्ट्रक्चर्ड डेटा — को एचटीएमएल दस्तावेज़ में ऊपर की ओर रखें. इससे यह पक्का किया जाता है कि वे कटऑफ़ से नीचे न हों. - अपने सर्वर लॉग मॉनिटर करें: सर्वर से जवाब मिलने में लगने वाले समय पर नज़र रखें. अगर आपका सर्वर बाइट प्रोसेस नहीं कर पा रहा है, तो हमारे क्रॉलर अपने-आप क्रॉल करने की प्रोसेस को रोक देंगे, ताकि आपके इन्फ़्रास्ट्रक्चर पर ज़्यादा लोड न पड़े. इससे, क्रॉल करने की फ़्रीक्वेंसी कम हो जाएगी.
ध्यान दें कि यह सीमा तय नहीं है और वेब के विकास और एचटीएमएल पेजों के साइज़ में बढ़ोतरी के साथ-साथ, इसमें बदलाव हो सकता है. (या छोटा करें. उम्मीद है कि यह कम हो जाएगा.)
क्रॉलिंग कोई जादू नहीं है. यह बाइट के आदान-प्रदान की एक बहुत ही व्यवस्थित और बड़े पैमाने पर की जाने वाली प्रोसेस है. हमारे फ़ेचिंग इंफ़्रास्ट्रक्चर के काम करने के तरीके को समझकर, यह पक्का किया जा सकता है कि आपकी साइट का सबसे ज़रूरी कॉन्टेंट हमेशा फ़ेच किया जाए.
ऑप्टिमाइज़ करने के लिए शुभकामनाएं!
क्या आपको बिहाइंड-द-सीन के बारे में ज़्यादा जानकारी चाहिए? YouTube पर Search Off the Record पॉडकास्ट का 105वाँ एपिसोड देखें. इसके अलावा, इसे किसी भी पॉडकास्ट प्लैटफ़ॉर्म पर सुना जा सकता है!