Google के क्रॉलर और फ़ेचर (उपयोगकर्ता एजेंट) की खास जानकारी
Google, अपने प्रॉडक्ट के लिए कार्रवाइयां करने के लिए क्रॉलर और फ़ेचर का इस्तेमाल करता है. ये कार्रवाइयां अपने-आप या उपयोगकर्ता के अनुरोध पर ट्रिगर होती हैं. अपने-आप वेबसाइटें खोजने और स्कैन करने में इस्तेमाल होने वाले प्रोग्राम को "क्रॉलर" कहते हैं. इसे "रोबोट" या "स्पाइडर" भी कहा जाता है. फ़ेचर, wget जैसे प्रोग्राम की तरह काम करते हैं. आम तौर पर, ये उपयोगकर्ता की ओर से एक अनुरोध करते हैं. Google के क्लाइंट, तीन कैटगरी में आते हैं:
सामान्य क्रॉलर | Google के प्रॉडक्ट के लिए इस्तेमाल किए जाने वाले सामान्य क्रॉलर, जैसे कि Googlebot. ये अपने-आप क्रॉल करने के लिए, robots.txt के नियमों का हमेशा पालन करते हैं. |
खास मामलों वाले क्रॉलर |
स्पेशल-केस क्रॉलर, सामान्य क्रॉलर की तरह ही होते हैं. हालांकि, इनका इस्तेमाल खास प्रॉडक्ट के लिए किया जाता है. ऐसा तब होता है, जब क्रॉल की गई साइट और Google प्रॉडक्ट के बीच, क्रॉल करने की प्रोसेस के लिए कोई कानूनी समझौता होता है. उदाहरण के लिए, विज्ञापन पब्लिशर की अनुमति से AdsBot , robots.txt के ग्लोबल उपयोगकर्ता एजेंट (* ) को नज़रअंदाज़ कर देता है.
|
उपयोगकर्ता की ओर से ट्रिगर किए गए फ़ेचर | उपयोगकर्ता से ट्रिगर होने वाले फ़ेच फ़ंक्शन, ऐसे टूल और प्रॉडक्ट फ़ंक्शन का हिस्सा होते हैं जहां असली उपयोगकर्ता, फ़ेच करने की सुविधा को ट्रिगर करता है. उदाहरण के लिए, साइट की पुष्टि करने वाला Google का उपयोगकर्ता एजेंट, किसी उपयोगकर्ता के अनुरोध पर कार्रवाई करता है. |
Google के क्रॉलर और फ़ेचर की तकनीकी प्रॉपर्टी
Google के क्रॉलर और फ़ेचर को एक साथ हज़ारों मशीनों पर चलने के लिए डिज़ाइन किया गया है, ताकि वेब की पहुंच बढ़ने के साथ-साथ परफ़ॉर्मेंस और स्केल में सुधार हो सके. बैंडविथ के इस्तेमाल को ऑप्टिमाइज़ करने के लिए, इन क्लाइंट को दुनिया भर के कई डेटासेंटर में डिस्ट्रिब्यूट किया जाता है, ताकि वे उन साइटों के आस-पास मौजूद हों जिन्हें वे ऐक्सेस कर सकते हैं. इसलिए, आपके लॉग में कई आईपी पतों से साइटों पर विज़िट करने की जानकारी दिख सकती है. Google, मुख्य तौर पर अमेरिका के आईपी पतों के ज़रिए डेटा ऐक्सेस करता है. अगर Google को पता चलता है कि कोई साइट अमेरिका से किए जाने वाले अनुरोधों को ब्लॉक कर रही है, तो वह अन्य देशों में मौजूद आईपी पताें से क्रॉल करने की कोशिश कर सकता है.
ट्रांसफ़र के लिए इस्तेमाल होने वाले प्रोटोकॉल
Google के क्रॉलर और फ़ेचर, एचटीटीपी/1.1 और एचटीटीपी/2 के साथ काम करते हैं. क्रॉलर, प्रोटोकॉल के उस वर्शन का इस्तेमाल करेंगे जो क्रॉल करने की सबसे अच्छी परफ़ॉर्मेंस देता है. इसके अलावा, ये क्रॉल करने के पिछले अनुभव से जुड़े आंकड़ों के आधार पर, क्रॉल करने के सेशन के दौरान प्रोटोकॉल स्विच कर सकते हैं. Google के क्रॉलर, डिफ़ॉल्ट रूप से एचटीटीपी/1.1 प्रोटोकॉल वर्शन का इस्तेमाल करते हैं. एचटीटीपी/2 का इस्तेमाल करके, क्रॉल करने से आपकी साइट और Googlebot के लिए कंप्यूटिंग रिसॉर्स (जैसे, सीपीयू, रैम) बचाए जा सकते हैं. हालांकि, इससे साइट को किसी Google प्रॉडक्ट से जुड़ा कोई फ़ायदा नहीं मिलता. उदाहरण के लिए, इससे Google Search में आपकी साइट की रैंकिंग में कोई बढ़ोतरी नहीं होती.
एचटीटीपी/2 पर क्रॉल करने से ऑप्ट आउट करने के लिए, आप अपनी साइट को होस्ट करने वाले सर्वर को निर्देश दें कि जब Google आपकी साइट को एचटीटीपी/2 पर क्रॉल करने की कोशिश करे, तब वह 421
एचटीटीपी स्टेटस कोड दिखाए. अगर यह करना मुमकिन नहीं है, तो आपके पास क्रॉलिंग टीम को मैसेज भेजने का विकल्प भी है (हालांकि, यह स्थायी समाधान नहीं है).
Google का क्रॉलर इन्फ़्रास्ट्रक्चर, एफ़टीपी (RFC959 और उसके अपडेट के हिसाब से) और एफ़टीपीएस (RFC4217 और उसके अपडेट के हिसाब से) के ज़रिए भी क्रॉल करने की सुविधा देता है. हालांकि, इनका इस्तेमाल बहुत कम किया जाता है.
कॉन्टेंट को कोड में बदलने के लिए इस्तेमाल किए जाने वाले फ़ॉर्मैट
Google के क्रॉलर और फ़ेचर, इन कॉन्टेंट एन्कोडिंग (कंप्रेसन) के साथ काम करते हैं: gzip, deflate, और Brotli (br). Google के हर उपयोगकर्ता एजेंट के साथ काम करने वाली कॉन्टेंट एन्कोडिंग का विज्ञापन, उनके हर अनुरोध के Accept-Encoding
हेडर में किया जाता है. उदाहरण के लिए,
Accept-Encoding: gzip, deflate, br
.
क्रॉल दर और होस्ट लोड
हमारा मकसद, आपके सर्वर पर ज़्यादा दबाव डाले बिना, हर विज़िट में आपकी साइट के ज़्यादा से ज़्यादा पेज क्रॉल करना है. अगर आपकी साइट को Google के क्रॉल वाले अनुरोध से तालमेल रखने में समस्या आ रही है, तो क्रॉल दर को कम करने का अनुरोध किया जा सकता है. ध्यान दें कि Google के क्रॉलर को गलत एचटीटीपी रिस्पॉन्स कोड भेजने से, Google के प्रॉडक्ट में आपकी साइट के दिखने के तरीके पर असर पड़ सकता है.
एचटीटीपी को कैश मेमोरी में सेव करना
Google का क्रॉल करने वाला इन्फ़्रास्ट्रक्चर, एचटीटीपी कैश मेमोरी का इस्तेमाल करता है. इस बारे में एचटीटीपी कैश मेमोरी के स्टैंडर्ड में बताया गया है. खास तौर पर, ETag
रिस्पॉन्स- और If-None-Match
अनुरोध के हेडर के साथ-साथ, Last-Modified
रिस्पॉन्स- और If-Modified-Since
अनुरोध हेडर के ज़रिए ऐसा किया जाता है.
अगर एचटीटीपी रिस्पॉन्स में ETag
और Last-Modified
, दोनों रिस्पॉन्स हेडर फ़ील्ड मौजूद हैं, तो Google के क्रॉलर, एचटीटीपी स्टैंडर्ड के हिसाब से ETag
वैल्यू का इस्तेमाल करते हैं.
हमारा सुझाव है कि Last-Modified
हेडर के बजाय
ETag
का इस्तेमाल करें. ऐसा इसलिए, क्योंकि ETag
में तारीख को फ़ॉर्मैट करने से जुड़ी समस्याएं नहीं होतीं. यह सुझाव, खास तौर पर Google के क्रॉलर के लिए है, ताकि प्राथमिकता को कैश मेमोरी में सेव करने के लिए बेहतर तरीका मिल पाए.
एचटीटीपी को कैश मेमोरी में सेव करने के अन्य निर्देश काम नहीं करते.
Google के अलग-अलग क्रॉलर और फ़ेच फ़ंक्शन, शायद कैश मेमोरी का इस्तेमाल करें. यह इस बात पर निर्भर करता है कि वे किस प्रॉडक्ट से जुड़े हैं. उदाहरण के लिए, Googlebot
, Google Search के लिए यूआरएल को फिर से क्रॉल करते समय कैश मेमोरी में सेव करने की सुविधा देता है. वहीं, Storebot-Google
सिर्फ़ कुछ खास स्थितियों में कैश मेमोरी में सेव करने की सुविधा देता है.
अपनी साइट के लिए एचटीटीपी को कैश मेमोरी में सेव करने के लिए, होस्टिंग या कॉन्टेंट मैनेजमेंट सिस्टम की सेवा देने वाली कंपनी से संपर्क करें.
ETag
और If-None-Match
Google का क्रॉल करने वाला इन्फ़्रास्ट्रक्चर, ETag
और If-None-Match
के साथ काम करता है. इस जानकारी को एचटीटीपी को कैश मेमोरी स्टोर करने के स्टैंडर्ड में बताया गया है.
ETag
रिस्पॉन्स हेडर और उसके अनुरोध के दूसरे हेडर, If-None-Match
के बारे में ज़्यादा जानें.
Last-Modified और If-Modified-Since
Google का क्रॉल करने वाला इन्फ़्रास्ट्रक्चर, Last-Modified
और If-Modified-Since
के साथ काम करता है. इस जानकारी को एचटीटीपी कैश मेमोरी के स्टैंडर्ड में बताया गया है. हालांकि, इसके इस्तेमाल के लिए ये बातें ध्यान में रखनी चाहिए:
-
Last-Modified
हेडर में तारीख को एचटीटीपी स्टैंडर्ड के हिसाब से फ़ॉर्मैट किया जाना चाहिए. पार्स करने से जुड़ी समस्याओं से बचने के लिए, हमारा सुझाव है कि आप तारीख के इस फ़ॉर्मैट का इस्तेमाल करें: "Weekday, DD Mon YYYY HH:MM:SS Timezone". उदाहरण के लिए, "Fri, 4 Sep 1998 19:15:56 GMT". -
Cache-Control
रिस्पॉन्स हेडर काmax-age
फ़ील्ड सेट करना ज़रूरी नहीं है, लेकिन हमारा सुझाव है कि आप इसे सेट करें. इससे क्रॉलर यह तय कर पाएंगे कि किसी खास यूआरएल को फिर से कब क्रॉल करना है.max-age
फ़ील्ड की वैल्यू में वह अनुमानित सेकंड सेट करें जब कॉन्टेंट में कोई बदलाव नहीं होगा. उदाहरण के लिए,Cache-Control: max-age=94043
.
Last-Modified
रिस्पॉन्स हेडर और उसके अनुरोध के हेडर, If-Modified-Since
के बारे में ज़्यादा जानें.
Google के क्रॉलर और फ़ेचर की पुष्टि करना
Google के क्रॉलर, अपनी पहचान तीन तरीकों से बताते हैं:
-
एचटीटीपी
user-agent
के अनुरोध का हेडर. - अनुरोध का सोर्स आईपी पता.
- सोर्स आईपी का रिवर्स डीएनएस होस्टनेम.
Google के क्रॉलर और फ़ेचर की पुष्टि करने के लिए, इस जानकारी का इस्तेमाल करने का तरीका जानें.