क्रॉल करने से जुड़े आंकड़ों की रिपोर्ट

क्रॉल करने से जुड़े आंकड़ों की रिपोर्ट से पता चलता है कि Google ने आपकी वेबसाइट को कब और कितनी बार क्रॉल किया है. उदाहरण के लिए, आपके सर्वर पर कब और कितने अनुरोध आए, सर्वर से क्या रिस्पॉन्स भेजा गया, और सर्वर से जुड़ी क्या समस्याएं हुईं. इस रिपोर्ट से यह पता चलता है कि आपकी साइट को क्रॉल करते समय, Google को कोई समस्या हुई या नहीं.

यह रिपोर्ट ज़्यादा जानकारी रखने वाले उपयोगकर्ताओं के लिए है. अगर आपकी साइट में एक हज़ार से कम पेज हैं, तो आपके लिए इस रिपोर्ट का इस्तेमाल करना या क्रॉल करने की प्रोसेस के बारे में इतनी गहराई से जानना ज़रूरी नहीं है.

यह रिपोर्ट सिर्फ़ रूट-लेवल प्रॉपर्टी के लिए उपलब्ध है. इसका मतलब है कि प्रॉपर्टी, डोमेन प्रॉपर्टी (जैसे, example.com या m.example.com) या रूट लेवल की यूआरएल-प्रीफ़िक्स प्रॉपर्टी (जैसे, https://example.com, http://example.com, http://m.example.com) होनी चाहिए.

क्रॉल करने से जुड़े आंकड़ों की रिपोर्ट खोलें

C<span/>rawl Budget and the Crawl Stats report - Google Search Console Training

Search Console में, क्रॉल करने से जुड़े आंकड़ों की रिपोर्ट देखने के लिए (प्रॉपर्टी सेटिंग) > क्रॉल करने के बारे में आंकड़े पर क्लिक करें.

रिपोर्ट का इस्तेमाल करना

इस रिपोर्ट का इस्तेमाल करने से पहले, आपको नीचे दी गई जानकारी को समझ लेना चाहिए:

• Google Search कैसे काम करता है
• ज़्यादा जानकारी रखने वाले उपयोगकर्ताओं के लिए विषय. इसमें खास तौर पर साइटमैप से जुड़े विषयों, क्रॉल करने और इंडेक्स करने के बारे में जानकारी दी गई है.
• अपनी साइट का ऐक्सेस मैनेज करना: इसमें ऐक्सेस के साथ-साथ, साइट को क्रॉल होने से रोकने के लिए robots.txt के इस्तेमाल के बारे में भी जानकारी दी गई है.
• अगर आपकी साइट बड़ी है यानी उस पर हज़ारों-लाखों पेज हैं, तो क्रॉल बजट को मैनेज करने और उससे जुड़ी समस्याओं को हल करने के लिए, यह गाइड देखें.

डेटा के बारे में जानकारी

• इस रिपोर्ट में वही यूआरएल होते हैं जिन्हें क्रॉल करने का अनुरोध Google ने किया है. इसमें, अन्य रिपोर्ट की तरह कैननिकल यूआरएल की जानकारी शामिल नहीं होती.
• अगर किसी यूआरएल को सर्वर साइड पर रीडायरेक्ट किया गया है, तो रीडायरेक्ट चेन में हर अनुरोध को एक अलग अनुरोध के तौर पर गिना जाता है. अगर पेज 1, पेज 2 पर और पेज 2, पेज 3 पर रीडायरेक्ट करता है और Google, पेज 1 को क्रॉल करने का अनुरोध करता है, तो आपको पेज 1 (एचटीटीपी स्टेटस कोड 301/302 दिखाता है), पेज 2 (एचटीटीपी स्टेटस कोड 301/302 कोड दिखाता है), और पेज 3 (उम्मीद है कि एचटीटीपी स्टेटस कोड 200 कोड दिखाएगा) के लिए अलग-अलग अनुरोध दिखेंगे. ध्यान दें कि सिर्फ़ मौजूदा डोमेन के पेज दिखाए जाते हैं. वेबपेज से अलग किसी और फ़ाइल टाइप के लिए, रीडायरेक्ट रिस्पॉन्स "अन्य फ़ाइल टाइप" होगा. क्लाइंट-साइड के रीडायरेक्ट की गिनती नहीं की जाती है.
• ऐसे क्रॉल जो शुरू किए गए, लेकिन robots.txt फ़ाइल के उपलब्ध न होने की वजह से पूरे नहीं हो सके उन्हें भी क्रॉल की कुल संख्या में गिना जाता है. हालांकि, हो सकता है कि रिपोर्ट में, क्रॉल करने की उन कोशिशों के बारे में पूरी जानकारी मौजूद न हो. ज़्यादा जानकारी
• रिसॉर्स और दायरा:
  • सिर्फ़ चुने गए डोमेन के अनुरोध दिखाए जाते हैं. दूसरे डोमेन के अनुरोध नहीं दिखाए जाएंगे. चुनी गई किसी प्रॉपर्टी के बाहर होस्ट किए गए, इमेज जैसे पेज रिसॉर्स के अनुरोध भी इनमें शामिल हैं. इसलिए, अगर आपके example.com/mypage पेज में google.com/img.png इमेज है, तो google.com/img.png के लिए किया गया अनुरोध, example.com प्रॉपर्टी के क्रॉल करने से जुड़े आंकड़ों की रिपोर्ट में नहीं दिखाया जाएगा.
  • इसी तरह, सिबलिंग डोमेन (जैसे, en.example और de.example) के अनुरोध भी नहीं दिखाए जाएंगे. अगर en.example के लिए, क्रॉल करने से जुड़े आंकड़ों की रिपोर्ट देखी जा रही हो, तो उसमें de.example पर मौजूद किसी इमेज के लिए किए गए अनुरोध नहीं दिखेंगे.
  • हालांकि, सबडोमेन के लिए किए गए अनुरोध, पैरंट डोमेन से देखे जा सकते हैं. उदाहरण के लिए, example.com का डेटा देखने का विकल्प चुनने पर, आपको example.com, en.example, और de.example.com के साथ-साथ, example.com के नीचे किसी भी लेवल पर मौजूद किसी भी चाइल्ड डोमेन के लिए किए गए सभी अनुरोध दिखेंगे.
  • इसके उलट, अगर आपकी प्रॉपर्टी के रिसॉर्स का इस्तेमाल किसी दूसरे डोमेन के पेज के लिए किया जाता है, तो आपको होस्ट पेज से जुड़े क्रॉल करने के अनुरोध दिख सकते हैं. हालांकि, आपको ऐसा कोई कॉन्टेक्स्ट नहीं दिखेगा जो बताता हो कि रिसॉर्स को क्रॉल किया जा रहा है, क्योंकि इसका इस्तेमाल दूसरे डोमेन के पेज पर किया गया है. इसका मतलब है कि आपको यह नहीं दिखेगा कि इमेज example.com/imageX.png को क्रॉल किया गया है, क्योंकि यह anotherexample.com/mypage पेज में शामिल है.
  • क्रॉल करने से जुड़े डेटा में एचटीटीपी और एचटीटीपीएस, दोनों तरह के प्रोटोकॉल शामिल होते हैं. ऐसा, यूआरएल-प्रीफ़िक्स प्रॉपर्टी के लिए भी होता है. इसका मतलब है कि http://example.com के लिए, क्रॉल करने से जुड़े आंकड़ों की रिपोर्ट में http://example.com और https://example.com, दोनों के अनुरोध शामिल होते हैं. हालांकि, यूआरएल-प्रीफ़िक्स प्रॉपर्टी के यूआरएल, प्रॉपर्टी (http या https) के लिए बताए गए प्रोटोकॉल तक सीमित होते हैं.

वैसी समस्या जिसके बारे में पता है: क्रॉल करने से जुड़े आंकड़ों की रिपोर्ट में, क्रॉल करने के ज़्यादातर अनुरोध शामिल होते हैं, लेकिन हो सकता है कि कुछ अनुरोध शामिल न किए जाएं. ऐसा अलग-अलग वजहों से हो सकता है. हम समय के साथ अपनी कवरेज बढ़ा रहे हैं और उम्मीद करते हैं कि अगर सभी अनुरोध शामिल न भी हो पाएं, तब भी ज़्यादा से ज़्यादा अनुरोधों को शामिल किया जाए. इसलिए, आपको अपनी साइट के अनुरोध लॉग और यहां बताई गई संख्या में कुछ अंतर दिख सकता है.

रिपोर्ट में एक से दूसरी जगह जाना

यह रिपोर्ट, आपकी साइट क्रॉल किए जाने के बारे में नीचे दी गई जानकारी दिखाती है:

• क्रॉल करने के कुल अनुरोध
• डाउनलोड का कुल साइज़
• सर्वर से रिस्पॉन्स मिलने में लगने वाला औसत समय
• होस्ट की स्थिति
• क्रॉल करने पर मिलने वाले रिस्पॉन्स
• फ़ाइल टाइप
• क्रॉल करने का मकसद
• Googlebot का टाइप

किसी भी आइटम के बारे में ज़्यादा जानकारी देखने के लिए, सूची में उसके नाम पर क्लिक करें. इसमें, उदाहरण के तौर पर दिए गए यूआरएल की सूची भी शामिल है. क्रॉल करने के किसी खास अनुरोध के बारे में जानने के लिए, यूआरएल पर क्लिक करें. उदाहरण के लिए, जिस टेबल में रिस्पॉन्स को टाइप के हिसाब से ग्रुप किया गया है उसमें, एचटीएमएल लाइन पर क्लिक करें. इससे आपको अपनी साइट पर क्रॉल किए गए सभी एचटीएमएल पेजों के लिए, क्रॉल किए जाने की पूरी जानकारी दिखेगी. साथ ही, उदाहरण के तौर पर दिए गए यूआरएल में से किसी एक को चुनकर, क्रॉल करने में लगने वाला समय, रिस्पॉन्स कोड, रिस्पॉन्स का साइज़ जैसी जानकारी भी देखी जा सकती है.

होस्ट और चाइल्ड डोमेन

अगर आपकी प्रॉपर्टी, डोमेन लेवल (जैसे, example.com, http://example.com, https://m.example.com) की है और उसमें दो या उससे ज़्यादा चाइल्ड डोमेन (जैसे, fr.example.com और de.example.com) शामिल हैं, तो पैरंट डोमेन की रिपोर्ट देखी जा सकती है. इस रिपोर्ट में, सभी चाइल्ड डोमेन या किसी एक चाइल्ड डोमेन का डेटा हो सकता है.

किसी चाइल्ड डोमेन के लिए बनी रिपोर्ट देखने के लिए, पैरंट डोमेन के लैंडिंग पेज पर मौजूद होस्ट सूचियों में, उस चाइल्ड डोमेन पर क्लिक करें. पिछले 90 दिनों में ट्रैफ़िक पाने वाले सबसे लोकप्रिय 20 चाइल्ड डोमेन ही दिखाए जाते हैं.

उदाहरण के तौर पर दिए गए यूआरएल

टाइप के हिसाब से उदाहरण के तौर पर दिए गए यूआरएल की सूची देखने के लिए, ग्रुप किए गए किसी डेटा टाइप (रिस्पॉन्स, फ़ाइल टाइप, मकसद, Googlebot टाइप) की एंट्री पर क्लिक करें.

उदाहरण में सभी यूआरएल शामिल नहीं होते, कुछ ही यूआरएल होते हैं. अगर आपको सूची में कोई यूआरएल नहीं मिलता, तो इसका मतलब यह नहीं है कि हमने इसके लिए अनुरोध नहीं किया. उदाहरणों की संख्या दिन के हिसाब से तय हो सकती है. इसलिए, हो सकता है कि आपको किसी एक टाइप के अनुरोधों के लिए, किसी दूसरे टाइप के अनुरोधों के मुकाबले ज़्यादा उदाहरण दिखें. समय के साथ, यह अंतर कम होता जाएगा.

क्रॉल करने के कुल अनुरोध

आपकी साइट पर यूआरएल के लिए जारी किए गए क्रॉल करने के अनुरोधों की कुल संख्या, चाहे वे अनुरोध पूरे हों या नहीं. इसमें उन रिसॉर्स के लिए किए गए अनुरोध भी शामिल होते हैं जिन्हें आपके किसी पेज पर इस्तेमाल किया जाता है, लेकिन इसके लिए ज़रूरी है कि ये रिसॉर्स आपकी साइट पर मौजूद हों. उन अनुरोधों को नहीं गिना जाता जो साइट के बाहर होस्ट किए गए रिसॉर्स के लिए हों. एक ही यूआरएल के लिए मिले डुप्लीकेट अनुरोध अलग-अलग गिने जाते हैं. अगर आपकी robots.txt फ़ाइल ज़रूरत के मुताबिक उपलब्ध नहीं है, तो संभावित फ़ेच गिने जाते हैं.

पूरे न होने वाले जिन अनुरोधों की गिनती की जाती है उनमें ये शामिल हैं:

• ऐसे फ़ेच जो कभी किए नहीं गए, क्योंकि robots.txt फ़ाइल ज़रूरत के मुताबिक उपलब्ध नहीं थी.
• ऐसे फ़ेच जो डीएनएस रिज़ॉल्यूशन से जुड़ी समस्याओं की वजह से नहीं किए जा सके
• ऐसे फ़ेच जो सर्वर कनेक्टिविटी से जुड़ी समस्याओं की वजह से नहीं किए जा सके
• ऐसे फे़च जो रीडायरेक्ट लूप की वजह से छोड़ दिए गए

डाउनलोड का कुल साइज़

तय समयावधि में, क्रॉल करने के दौरान, आपकी साइट से कितनी बाइट डाउनलोड की गईं. अगर Google किसी ऐसे पेज रिसॉर्स को कैश मेमोरी में सेव करता है जो कई पेजों पर इस्तेमाल होता है, तो उस रिसॉर्स के लिए सिर्फ़ पहली बार अनुरोध किया जाता है (जब उसे कैश मेमोरी में सेव किया जाता है).

सर्वर से रिस्पॉन्स मिलने में लगने वाला औसत समय

किसी तय समयावधि में, आपकी साइट से मिले सभी रिसॉर्स के लिए रिस्पॉन्स देने में लगने वाला औसत समय. किसी पेज के हर रिसॉर्स को एक अलग रिस्पॉन्स के तौर पर गिना जाता है.

होस्ट की स्थिति

होस्ट की स्थिति से पता चलता है कि आपकी साइट क्रॉल करते समय, Google को होस्ट की उपलब्धता से जुड़ी समस्याएं हुईं या नहीं. इनमें से कोई एक स्थिति हो सकती है:

• 
  बहुत बढ़िया! पिछले 90 दिनों में, Google को आपकी साइट क्रॉल करने के दौरान, सर्वर से जुड़ी कोई समस्या नहीं मिली. इस स्थिति में आपको कुछ नहीं करना है.
• 
  पिछले 90 दिनों में, Google को आपकी साइट क्रॉल करने के दौरान, होस्ट की उपलब्धता से जुड़ी कम से कम एक गंभीर समस्या मिली. हालांकि, ऐसा हुए एक हफ़्ते से ज़्यादा हो गया. वह समस्या शायद बहुत कम समय तक रही हो या उसे हल कर लिया गया हो. आपको रिस्पॉन्स वाली सूची की जांच करके यह पता लगाना चाहिए कि किस तरह की समस्याएं हुई थीं और यह तय करना चाहिए कि आपको कोई कार्रवाई करने की ज़रूरत है या नहीं.इनमें इस प्रॉपर्टी के बाहर होस्ट किए गए किसी भी पेज रिसॉर्स (जैसे कि इमेज) के अनुरोध शामिल हैं.
• 
  पिछले हफ़्ते, Google को आपकी साइट क्रॉल करने के दौरान कम से कम एक गंभीर समस्या मिली. वह समस्या हाल ही में हुई थी, इसलिए आपको यह पता करने की कोशिश करनी चाहिए कि यह बार-बार होने वाली समस्या है या नहीं. रिस्पॉन्स वाली सूची की जांच करके यह पता लगाएं कि किस तरह की समस्याएं हुई थीं. साथ ही, यह तय करें कि आपको कोई कार्रवाई करने की ज़रूरत है या नहीं.

इस रिपोर्ट में क्या देखें

आम तौर पर, आपके होस्ट की स्थिति हरे रंग में दिखनी चाहिए. अगर आपकी उपलब्धता की स्थिति लाल रंग में दिख रही है, तो robots.txt की उपलब्धता, डीएनएस रिज़ॉल्यूशन, और होस्ट कनेक्टिविटी के लिए, उपलब्धता की जानकारी देखने के लिए क्लिक करें.

होस्ट की स्थिति की जानकारी

होस्ट की उपलब्धता की स्थिति का आकलन इन कैटगरी में किया जाता है. किसी भी कैटगरी में आने वाली गंभीर गड़बड़ी की वजह से, उपलब्धता की स्थिति कम हो सकती है. ज़्यादा जानकारी पाने के लिए, रिपोर्ट में किसी कैटगरी पर क्लिक करें.

हर कैटगरी के लिए, आपको चुनी गई समयावधि के लिए क्रॉल करने से जुड़े डेटा का चार्ट दिखेगा. चार्ट में बिंदुओं वाली लाल लाइन है. अगर इस कैटगरी के लिए मेट्रिक, बिंदुओं वाली लाइन से ऊपर थी (उदाहरण के लिए, अगर डीएनएस रिज़ॉल्यूशन बताए गए किसी दिन में 5% से ज़्यादा अनुरोध पूरे नहीं करता), तो यह कैटगरी के लिए समस्या मानी जाती है और उसकी स्थिति आखिरी बार दिखी समस्या के तौर पर नज़र आएगी.

• robots.txt फ़ेच करना
  यह ग्राफ़, क्रॉल की प्रोसेस के दौरान robots.txt अनुरोधों के पूरे न होने की दर दिखाता है. Google इस फ़ाइल के लिए बार-बार अनुरोध करता है और अगर अनुरोध कोई मान्य फ़ाइल (भरी हुई या खाली) या 404 (फ़ाइल मौजूद नहीं है) रिस्पॉन्स नहीं देता है, तो Google आपकी साइट को क्रॉल करना बंद कर देगा या तब तक क्रॉल नहीं करेगा, जब तक इसे स्वीकार करने लायक robots.txt रिस्पॉन्स नहीं मिलता. (ज़्यादा जानकारी नीचे दी गई है)
• डीएनएस रिज़ॉल्यूशन
  यह ग्राफ़ दिखाता है कि आपके डीएनएस सर्वर ने कब आपके होस्टनाम को नहीं पहचाना या क्रॉल करने के दौरान रिस्पॉन्स नहीं दिया. अगर आपको गड़बड़ियां दिखती हैं, तो अपने रजिस्ट्रार से संपर्क करें और पक्का करें कि आपकी साइट सही तरीके से सेट अप की गई है. साथ ही, यह देखें कि आपका सर्वर, इंटरनेट से कनेक्ट किया गया है या नहीं.
• सर्वर कनेक्टिविटी
  यह ग्राफ़, किसी यूआरएल को क्रॉल करने के दौरान सर्वर के काम नहीं करने या ठीक से काम नहीं करने की स्थिति दिखाता है. इन गड़बड़ियों को ठीक करने का तरीका जानने के लिए, सर्वर की गड़बड़ियां देखें.

robots.txt की उपलब्धता के बारे में ज़्यादा जानकारी

यहां इस बारे में ज़्यादा जानकारी दी गई है कि आपकी साइट को क्रॉल करने के दौरान, Google किस तरह robots.txt फ़ाइलों की जांच करता है और उन पर निर्भर रहता है.

आपकी साइट में robots.txt फ़ाइल होना ज़रूरी नहीं है, लेकिन इस फ़ाइल के लिए अनुरोध होने पर एक रिस्पॉन्स (जैसा नीचे बताया गया है) मिलना ज़रूरी है. ऐसा न होने पर, Google आपकी साइट को क्रॉल करना बंद कर सकता है.

• कामयाब robots.txt रिस्पॉन्स
• नीचे दिए गए सभी रिस्पॉन्स को कामयाब रिस्पॉन्स माना जाता है:
  • एचटीटीपी 200 और एक robots.txt फ़ाइल (फ़ाइल मान्य, अमान्य या खाली हो सकती है). फ़ाइल में सिंटैक्स की गड़बड़ियां होने पर भी अनुरोध को कामयाब माना जाता है. हालांकि, Google, सिंटैक्स की गड़बड़ी वाले किसी भी नियम को अनदेखा कर सकता है.
  • एचटीटीपी 403/404/410 (फ़ाइल मौजूद नहीं है). आपकी साइट में robots.txt फ़ाइल होना ज़रूरी नहीं है.
• नाकामयाब robots.txt रिस्पॉन्स
  • एचटीटीपी 429/5XX (कनेक्शन की समस्या)

किसी साइट को क्रॉल करने के दौरान Google किस तरह robots.txt फ़ाइलों के लिए अनुरोध भेजता है और उन्हें इस्तेमाल करता है, इसका तरीका यहां बताया गया है:

1. आपकी साइट को क्रॉल करने से पहले, Google यह पता लगाता है कि पिछले 24 घंटों में robots.txt से जुड़ा कोई अनुरोध पूरा हुआ है या नहीं.
2. अगर पिछले 24 घंटों में robots.txt से जुड़ा कोई अनुरोध पूरा हुआ है, तो Google उस robots.txt फ़ाइल का इस्तेमाल करके आपकी साइट क्रॉल करेगा. (ध्यान रखें कि '404 नहीं मिला' गड़बड़ी मिलने का मतलब है कि अनुरोध पूरा हुआ. हालांकि, इसका यह भी मतलब है कि कोई robots.txt फ़ाइल मौजूद नहीं है. इसलिए, साइट के किसी भी यूआरएल को Google क्रॉल कर सकता है.)
3. अगर पिछले 24 घंटों में कोई अनुरोध नहीं हुआ है या ऐसा अनुरोध मौजूद है जो पूरे नहीं हुआ है, तो Google आपकी robots.txt फ़ाइल के लिए अनुरोध करता है:
   • अगर robots.txt फ़ाइल मिलती है, तो क्रॉल करने की प्रोसेस शुरू हो सकती है.
   • अगर robots.txt फ़ाइल नहीं मिलती है, तो:
     • शुरुआती 12 घंटों के लिए, Google आपकी साइट को क्रॉल करना बंद कर देगा. हालांकि, वह आपकी robots.txt फ़ाइल के लिए अनुरोध करता रहेगा.
     • robots.txt फ़ाइल न मिलने पर, 12 घंटों से 30 दिनों तक Google उस robots.txt फ़ाइल का इस्तेमाल करेगा जिसे पिछली बार फ़ेच किया गया था. इस दौरान, Google आपकी robots.txt फ़ाइल के लिए अनुरोध करता रहेगा.
     • अगर 30 दिनों तक robots.txt फ़ाइल नहीं मिलती है, तो:
       • साइट का होम पेज उपलब्ध होने पर, Google यह मान लेगा कि साइट पर कोई robots.txt फ़ाइल नहीं है और वह बिना किसी पाबंदी के साइट को क्रॉल करेगा.
       • साइट का होम पेज उपलब्ध न होने पर, Google साइट को क्रॉल करना बंद कर देगा.
       • दोनों ही मामलों में, Google समय-समय पर आपकी robots.txt फ़ाइल के लिए अनुरोध करता रहेगा.

robots.txt फ़ाइल के उपलब्ध न होने की वजह से जो क्रॉल पूरे नहीं हुए उन्हें क्रॉलिंग की कुल संख्या में गिना जाता है. हालांकि, ये क्रॉल असल में पूरे नहीं किए गए. इसलिए, कुछ ग्रुपिंग रिपोर्ट (किसी मकसद से किए गए क्रॉल, रिस्पॉन्स के हिसाब से किए गए क्रॉल वगैरह) में, इन क्रॉल का ज़िक्र नहीं किया जाएगा. इसके अलावा, यह भी हो सकता है कि इन रिपोर्ट में, इन क्रॉल से जुड़ी पूरी जानकारी मौजूद न हो.

क्रॉल करने पर मिलने वाले रिस्पॉन्स

इस सूची में ऐसे रिस्पॉन्स दिखाए जाते हैं जो आपकी साइट को क्रॉल करने के दौरान Google को मिलते हैं. ये, रिस्पॉन्स के टाइप और क्रॉल करने पर मिलने वाले सभी रिस्पॉन्स के प्रतिशत के तौर पर ग्रुप किए जाते हैं. डेटा, अनुरोधों की कुल संख्या पर आधारित होता है, न कि यूआरएल के हिसाब से होता है. इसलिए, अगर Google ने यूआरएल के लिए दो बार अनुरोध किया है और पहली बार में 'सर्वर की गड़बड़ी' (500) और दूसरी बार में 'ठीक है' (200) मिला, तो रिस्पॉन्स, 50% 'सर्वर की गड़बड़ी' और 50% 'ठीक है' होगा.

इस रिपोर्ट में क्या देखें

ज़्यादातर रिस्पॉन्स, 200 या "अच्छी" तरह वाले अन्य रिस्पॉन्स होने चाहिए, जब तक कि आपकी साइट को फिर से व्यवस्थित न किया जा रहा हो या साइट को किसी दूसरे पते पर न ले जाया जा रहा हो. अन्य रिस्पॉन्स कोड मैनेज करने का तरीका जानने के लिए नीचे दी गई सूची देखें.

 

यहां कुछ सामान्य रिस्पॉन्स कोड और उन्हें मैनेज करने का तरीका बताया गया है:

अच्छे रिस्पॉन्स कोड

ये पेज ठीक से काम कर रहे हैं और इनकी वजह से कोई समस्या नहीं हो रही है.

• ठीक है (200): सामान्य स्थितियों में, ज़्यादातर रिस्पॉन्स, 200 रिस्पॉन्स वाले होने चाहिए.
• हमेशा के लिए किसी दूसरे पते पर ले जाया गया (301): आपका पेज, एचटीटीपी 301 या 308 (हमेशा के लिए किसी दूसरे पते पर ले जाया गया) रिस्पॉन्स भेज रहा है. हो सकता है कि आपको यही रिस्पॉन्स चाहिए हो.
• कुछ समय के लिए किसी दूसरे पते पर ले जाया गया (302): आपका पेज, एचटीटीपी 302 या 307 (कुछ समय के लिए किसी दूसरे पते पर ले जाया गया) रिस्पॉन्स भेज रहा है. हो सकता है कि आपको यही रिस्पॉन्स चाहिए हो. अगर इस पेज को हमेशा के लिए किसी दूसरे पते पर ले जाया गया है, तो पेज पर 301 रिस्पॉन्स दिखाएं.
• किसी दूसरे पते पर ले जाया गया (अन्य): यह एक मेटा रीफ़्रेश है.
• बदलाव नहीं किया गया (304): पिछली बार किए गए क्रॉल करने के अनुरोध के बाद से, पेज में कोई बदलाव नहीं हुआ है.

सही हो सकने वाले रिस्पॉन्स कोड

ये रिस्पॉन्स सही हो सकते हैं, लेकिन आपके पास यह जांचने का विकल्प है कि क्या ये वे रिस्पॉन्स ही हैं जो आपको चाहिए थे.

• मौजूद नहीं है (404) साइट पर या उससे बाहर, टूटे हुए लिंक की वजह से गड़बड़ियां हो सकती हैं. आपकी साइट पर मौजूद 404 कोड वाली सभी गड़बड़ियों को ठीक नहीं किया जा सकता और न ही ऐसा करना ज़रूरी है. अक्सर 404 कोड वाली गड़बड़ी भेजना सही होता है (उदाहरण के लिए, अगर कोई पेज वाकई बिना किसी बदलाव के चला जाता है). 404 कोड वाली गड़बड़ियों को ठीक करने या यह तय करने का तरीका जानें कि उन्हें ठीक करना है या नहीं.

खराब रिस्पॉन्स कोड

अगर आप चाहते हैं कि आपके पेजों को बेहतर तरीके से क्रॉल किया जाए, तो आपको इन गड़बड़ियों को लौटाने वाले पेजों को ठीक करना चाहिए.

• robots.txt उपलब्ध नहीं है: अगर आपकी robots.txt फ़ाइल एक दिन तक मौजूद नहीं रहती है, तो Google कुछ समय के लिए क्रॉल करना बंद कर देगा. ऐसा तब तक होगा, जब तक robots.txt के लिए किए गए अनुरोध पर उसे कोई स्वीकार करने लायक जवाब नहीं मिल जाता. ध्यान रखें कि अपनी robots.txt फ़ाइल को Google पर क्लोक न करें या उपयोगकर्ता एजेंट के हिसाब से, robots.txt पेज में बदलाव न करें.
  यह रिस्पॉन्स, robots.txt फ़ाइल के लिए "नहीं मिला (404)" पर लौटने जैसा नहीं है जिसे एक अच्छा रिस्पॉन्स माना जाता है. robots.txt के बारे में ज़्यादा जानकारी देखें.
• बिना अनुमति वाले पेज (401/407): आपको इन पेजों को robots.txt से ब्लॉक करना चाहिए, ताकि इन्हें क्रॉल न किया जा सके या फिर यह तय करना चाहिए कि उन्हें अनब्लॉक किया जाना चाहिए या नहीं. अगर इन पेजों पर सुरक्षित डेटा (बैंक खाता नंबर या पासवर्ड जैसा संवेदनशील डेटा) नहीं है और आप चाहते हैं कि उन्हें क्रॉल किया जाए, तो आप जानकारी को उन पेजों पर ले जा सकते हैं जो सुरक्षित नहीं हैं या लॉग इन किए बिना Googlebot को एंट्री की अनुमति देने के बारे में सोच सकते हैं. हालांकि, यह ध्यान रखें कि Googlebot के झूठे नाम से मेल भेजे जा सकते हैं, इसलिए Googlebot को एंट्री की अनुमति देने से पेज की सुरक्षा हट जाती है.
• सर्वर की गड़बड़ी (5XX): ये गड़बड़ियां, उपलब्धता से जुड़ी चेतावनियां देती हैं और हो सके, तो इन्हें ठीक करना चाहिए. थंबनेल चार्ट, यह अंदाज़ा लगाता है कि ये गड़बड़ियां कब हुईं. गड़बड़ियों के बारे में ज़्यादा जानकारी और सही समय देखने के लिए क्लिक करें. तय करें कि ये कुछ समय के लिए दिखने वाली समस्याएं हैं या ये आपकी साइट की उपलब्धता से जुड़ी गड़बड़ियां हैं. अगर Google आपकी साइट को बहुत बार क्रॉल कर रहा है, तो आप क्रॉल करने की दर कम करने का अनुरोध कर सकते हैं. अगर यह उपलब्धता से जुड़ी किसी गंभीर समस्या की ओर इशारा करता है, तो क्रॉल करने में होने वाली बढ़ोतरी के बारे में पढ़ें. इन गड़बड़ियों को ठीक करने का तरीका जानने के लिए, सर्वर की गड़बड़ियां देखें.
• अन्य क्लाइंट गड़बड़ी (4XX): यहां किसी अन्य 4XX (क्लाइंट-साइड) गड़बड़ी की जानकारी नहीं दी गई है. इन समस्याओं को हल करना ही बेहतर है.
• डीएनएस काम नहीं कर रहा है: डीएनएस सर्वर ने आपकी साइट पर मौजूद यूआरएल के लिए किए गए अनुरोधों पर रिस्पॉन्स नहीं दिया.
• डीएनएस गड़बड़ी: डीएनएस की अन्य गड़बड़ी. इसकी जानकारी नहीं है.
• फ़ेच करने से जुड़ी गड़बड़ी: खराब पोर्ट संख्या, आईपी पते या पार्स नहीं किए जा सकने वाले रिस्पॉन्स की वजह से पेज को फ़ेच नहीं किया जा सका.
• पेज तक नहीं पहुंचा जा सका: पेज को फिर से लोड करने में कोई दूसरी गड़बड़ी, जहां अनुरोध कभी सर्वर तक नहीं पहुंच सका. ये अनुरोध, सर्वर तक कभी नहीं पहुंचे, इसलिए ये आपके लॉग में नहीं दिखेंगे.
• पेज टाइम आउट: पेज के लिए अनुरोध करने का समय खत्म हो गया.
• रीडायरेक्ट से जुड़ी गड़बड़ी: एक अनुरोध रीडायरेक्ट करने के दौरान हुई गड़बड़ी, जैसे कि बहुत ज़्यादा रीडायरेक्ट, खाली रीडायरेक्ट या सर्कुलर रीडायरेक्ट.
• अन्य गड़बड़ी: एक दूसरी गड़बड़ी, जो ऊपर दी गई किसी भी कैटगरी में नहीं आती.

क्रॉल किए गए फ़ाइल टाइप

अनुरोध करने पर मिला फ़ाइल टाइप. हर टाइप के लिए प्रतिशत वैल्यू उस टाइप के रिस्पॉन्स का प्रतिशत होती है, न कि उस टाइप को पाने वाले बाइट का प्रतिशत.

फ़ाइल टाइप के लिए संभावित वैल्यू:

• एचटीएमएल
• इमेज
• वीडियो - काम करने वाले वीडियो फ़ॉर्मैट में से कोई एक फ़ॉर्मैट.
• JavaScript
• सीएसएस
• PDF
• अन्य एक्सएमएल - कोई एक्सएमएल फ़ाइल जिसमें आरएसएस, केएमएल, या एक्सएमएल पर बना कोई अन्य फ़ॉर्मैट शामिल नहीं है.
• JSON
• सिंडिकेशन - कोई आरएसएस या ऐटम फ़ीड
• ऑडियो
• भौगोलिक डेटा - KML या अन्य भौगोलिक डेटा.
• अन्य फ़ाइल टाइप - किसी अन्य फ़ाइल टाइप की जानकारी यहां नहीं दी गई है. इस ग्रुप में रीडायरेक्ट शामिल होते हैं.
• अज्ञात (ऐसे अनुरोध जिन पर कार्रवाई नहीं हो सकी) - अगर अनुरोध फ़ेल होता है, तो फ़ाइल टाइप की जानकारी नहीं मिलती है.

इस रिपोर्ट में क्या देखें

अगर आप उपलब्धता की समस्याएं या धीमी प्रतिक्रिया दर देख रहे हैं, तो यह जानने के लिए इस सूची में देखें कि Google किस तरह के रिसॉर्स क्रॉल कर रहा है और इससे आपकी साइट को क्रॉल करने की रफ़्तार कम क्यों हो सकती है. क्या Google ऐसी कई छोटी इमेज के लिए अनुरोध कर रहा है जिन्हें ब्लॉक किया जाना चाहिए? क्या Google ऐसे रिसॉर्स के लिए अनुरोध कर रहा है जो किसी दूसरी, कम रिस्पॉन्सिव साइट (स्क्रीन के हिसाब से साइज़ बदलने वाली साइट) पर होस्ट किए गए हैं? अलग-अलग फ़ाइल टाइप पर क्लिक करें, ताकि आप तारीख के हिसाब से रिस्पॉन्स देने में लगने वाला औसत समय और अनुरोधों की संख्या देख सकें. इससे आपको यह पता चलता है कि उस टाइप के रिस्पॉन्स की वजह से, साइट धीमे लोड होने या होस्ट की उपलब्धता से जुड़ी समस्याओं की संख्या बढ़ रही है या नहीं.

क्रॉल करने का मकसद

• खोज: जिस यूआरएल का अनुरोध किया गया था उसे Google ने पहले कभी क्रॉल नहीं किया था.
• रीफ़्रेश करना: किसी ऐसे पेज को फिर से क्रॉल करना जिसकी जानकारी है.

अगर आप तेज़ी से उन पेजों में बदलाव कर रहे हैं जिन्हें ज़रूरत के हिसाब से बार-बार क्रॉल नहीं किया जा रहा है, तो पक्का करें कि वे साइटमैप में शामिल हैं. धीरे-धीरे अपडेट होने वाले पेजों के लिए, आपको फिर से क्रॉल करने के लिए कहना पड़ सकता है. अगर आपने हाल ही में बहुत सारा नया कॉन्टेंट जोड़ा है या साइटमैप सबमिट किया है, तो आपको साइट पर डिस्कवरी (खोज) क्रॉल में उछाल दिखेगा.

Googlebot का टाइप

क्रॉल का अनुरोध करने के लिए इस्तेमाल किए जाने वाले उपयोगकर्ता एजेंट का टाइप. Google के पास कई उपयोगकर्ता एजेंट हैं, जो अलग-अलग वजहों से क्रॉल करते हैं और इनके अलग-अलग तरह से काम करते हैं.

Googlebot के टाइप की संभावित वैल्यू:

• स्मार्टफ़ोन: Googlebot स्मार्टफ़ोन
• डेस्कटॉप: Googlebot डेस्कटॉप
• इमेज: Googlebot इमेज. अगर इमेज, पेज रिसॉर्स के तौर पर लोड होती है, तो Googlebot के टाइप की गिनती पेज रिसॉर्स लोड के तौर पर की जाती है, न कि इमेज के तौर पर.
• वीडियो: Googlebot वीडियो. अगर वीडियो, पेज रिसॉर्स के तौर पर लोड होता है, तो Googlebot के टाइप की गिनती पेज रिसॉर्स लोड के तौर पर की जाती है, न कि वीडियो के तौर पर.
• पेज रिसॉर्स लोड: आपके पेज की ओर से इस्तेमाल किए गए रिसॉर्स के लिए दूसरा फ़ेच. जब Google, पेज को क्रॉल करता है, तो वह पेज को इंडेक्स करने से पहले रेंडर करने के लिए, लिंक किए गए ज़रूरी रिसॉर्स, जैसे कि इमेज या सीएसएस फ़ाइलों को फ़ेच करता है. यह रिसॉर्स वाला उपयोगकर्ता एजेंट है, जो इन रिसॉर्स के लिए अनुरोध करता है.
• AdsBot: AdsBot क्रॉलर में से कोई एक. अगर आपको इन अनुरोधों में बढ़ोतरी दिख रही है, तो शायद आपने हाल ही में अपनी साइट पर डाइनैमिक सर्च विज्ञापनों के लिए कई नए टारगेट बनाए हैं. मेरी क्रॉल दर अचानक क्यों बढ़ गई देखें. AdsBot, हर दो हफ़्ते में यूआरएल क्रॉल करता है.
• StoreBot: प्रॉडक्ट शॉपिंग क्रॉलर.
• अन्य एजेंट टाइप: अन्य Google क्रॉलर, जिसकी जानकारी यहां नहीं दी गई है.

अगर आपके क्रॉल करने की संख्या बढ़ रही है, तो जांच करें कि उपयोगकर्ता एजेंट किस टाइप का है. अगर AdsBot क्रॉलर की वजह से क्रॉल करने की संख्या बढ़ रही है, तो मेरी क्रॉल दर अचानक क्यों बढ़ गई देखें.

समस्या हल करना

क्रॉल दर बहुत ज़्यादा है

Googlebot, एल्गोरिदम का इस्तेमाल करता है, ताकि आपकी साइट पर क्रॉल करने के दौरान लोड न बढ़े. हालांकि, अगर किसी वजह से आपको क्रॉल दर को सीमित करना है, तो ऐसा करने का तरीका यहां जानें.

मेरी क्रॉल दर अचानक क्यों बढ़ गई?

अगर आप अपनी साइट पर बहुत सी नई जानकारी डालते हैं या उसमें वाकई काम की जानकारी मौजूद है, तो हो सकता है कि आपकी साइट को सामान्य से ज़्यादा बार क्रॉल किया जाए. उदाहरण के लिए:

• आपने अपनी साइट के एक बड़े हिस्से को, क्रॉल किए जाने के लिए अनब्लॉक कर दिया है
• आपने अपनी साइट में एक नया सेक्शन जोड़ा है, जो काफ़ी बड़ा है
• आपने नए पेज फ़ीड या URL_Equals नियमों को जोड़कर, डाइनैमिक सर्च विज्ञापनों के लिए बड़ी संख्या में नए टारगेट जोड़े हैं

अगर आपकी साइट इतनी ज़्यादा क्रॉल की जा रही है कि इसमें उपलब्धता से जुड़ी समस्याएं आने लगी हैं, तो इस समस्या को हल करने का तरीका यहां बताया गया है:

1. पता करें कि कौनसा Google क्रॉलर आपकी साइट को इतना ज़्यादा क्रॉल कर रहा है. अपने वेबसाइट के लॉग देखें या क्रॉल करने के बारे में आंकड़े की रिपोर्ट का इस्तेमाल करें.
2. तुरंत हल पाने के लिए:
   • अगर आपको इस समस्या का एक आसान हल चाहिए, तो ज़्यादा क्रॉल करने वाले एजेंट (googlebot, adsbot वगैरह) को आपकी साइट को क्रॉल करने से रोकने के लिए, robots.txt का इस्तेमाल करें. हालांकि, इसे लागू होने में एक दिन तक लग सकता है. इसे ज़्यादा समय के लिए ब्लॉक न करें. ऐसा करने से आपकी साइट को क्रॉल करने से जुड़ी प्रक्रिया पर लंबे समय तक असर पड़ सकता है.
   • अगर बढ़े हुए लोड का पता करना और उस पर कार्रवाई करना, दोनों काम डाइनैमिक तौर पर किए जा रहे हैं, तो एचटीटीपी 503/429 दिखाएं. ऐसा तब करें, जब आपकी खोज के नतीजों में वेब पेज दिखाने की सीमा पूरी होने वाली हो. ध्यान रखें कि 503 या 429 को दो या तीन दिनों से ज़्यादा न दिखाएं, नहीं तो इससे Google को यह निर्देश मिल सकता है कि वह आपकी साइट को लंबे समय तक, सामान्य से कम क्रॉल करे.
3. दो या तीन दिनों के बाद, जब Google की क्रॉल दर आपकी साइट के मुताबिक हो जाए, तो अपने robots.txt ब्लॉक हटाए जा सकते हैं. इसके अलावा, 503 या 429 गड़बड़ी कोड दिखाने बंद किए जा सकते हैं.
4. अगर आप AdsBot के क्रॉल करने से परेशान हैं, तो शायद समस्या यह है कि आपने अपनी साइट पर URL_Equals या पेज फ़ीड इस्तेमाल करके, डाइनैमिक सर्च विज्ञापन के लिए कई टारगेट बना दिए हैं. अगर आपके सर्वर में इन क्रॉल को हैंडल करने की क्षमता नहीं है, तो आपको अपने विज्ञापन के टारगेट सीमित करने होंगे, यूआरएल छोटे-छोटे बैच में जोड़ने होंगे या फिर ब्राउज़र में वेब पेज खोलने की अपनी क्षमता बढ़ानी होगी. ध्यान दें कि AdsBot हर दो हफ़्ते में आपके पेजों को क्रॉल करेगा, इसलिए आपको समस्या हल करनी होगी. ऐसा न करने पर वह बार-बार क्रॉल करेगा.

क्रॉल दर बहुत कम लग रही है

Google को आपकी क्रॉल दर बढ़ाने के लिए नहीं कहा जा सकता. हालांकि, आपको बहुत बड़ी या अक्सर अपडेट होने वाली वेबसाइटों के लिए, क्रॉल करने की प्रोसेस को कैसे मैनेज करें, इस बारे में ज़्यादा जानकारी मिल सकती हैं.

छोटी या मध्यम वेबसाइटों के लिए, अगर आपको लगता है कि Google आपकी पूरी साइट को क्रॉल नहीं कर रहा है, तो अपनी वेबसाइट के साइटमैप अपडेट करें और पक्का करें कि आपने किसी भी पेज को ब्लॉक नहीं कर रखा है.

मेरी क्रॉल दर क्यों कम हुई?

आम तौर पर, एक या दो हफ़्ते के दौरान आपकी साइट पर Google की क्रॉल करने की दर तकरीबन एक जैसी होनी चाहिए. अगर आपको अचानक गिरावट दिखती है, तो इसकी कुछ वजहें हो सकती हैं, जिनके बारे में यहां बताया गया है:

• आपने एक नया (या बहुत पेजों पर लागू होने वाला) robots.txt नियम जोड़ा है. पक्का करें कि आप सिर्फ़ उन ही रिसॉर्स पर रोक लगा रहे हैं जिन्हें रोकना आपके लिए ज़रूरी है. अगर कॉन्टेंट को समझने के लिए Google को सीएसएस या JavaScript जैसे खास रिसॉर्स की ज़रूरत है, तो पक्का करें कि आपने उन पर ऐसी कोई रोक न लगाई हो जिसकी वजह से Googlebot उन्हें ऐक्सेस न कर सके.
• अगर आपकी साइट धीरे काम रही है, तो Googlebot कम अनुरोधों को प्रोसेस करेगा, ताकि आपका सर्वर ओवरलोड न हो. यह जानने के लिए कि क्या आपकी साइट ज़्यादा धीरे काम कर रही है, क्रॉल करने से जुड़े आंकड़ों की रिपोर्ट देखें.
• अगर आपके सर्वर पर गड़बड़ी की दर बढ़ जाती है, तो Googlebot अनुरोध प्रोसेस करने की दर कम कर देगा, ताकि आपके सर्वर को ओवरलोड होने से बचाया जा सके.
• अगर साइट पर ऐसी जानकारी मौजूद है जिसमें कभी-कभी बदलाव होता है या जिसकी क्वालिटी बहुत अच्छी नहीं है, तो हो सकता है कि हम उसे ज़्यादा बार क्रॉल न करें. अपनी साइट पर ईमानदारी से गौर करें. ऐसे लोगों से ज़रूरी सुझाव लें जो आपकी साइट से नहीं जुड़े हैं. साथ ही, इस बारे में सोचें कि आपकी साइट के किन हिस्सों को और किस तरह बेहतर बनाया जा सकता है.

रिपोर्ट में दी गई क्रॉल करने की कुल संख्या का आपकी साइट के सर्वर लॉग में मौजूद क्रॉल की कुल संख्या से बहुत ज़्यादा होना

ऐसा हो सकता है कि क्रॉल करने की जो कुल संख्या रिपोर्ट में दिखाई गई है वह आपके सर्वर लॉग में मौजूद, Google के क्रॉल करने के अनुरोधों की संख्या से ज़्यादा हो. ऐसा तब ही होता है, जब बहुत देर तक robots.txt फ़ाइल उपलब्ध न होने की वजह से, Google आपकी साइट को क्रॉल नहीं कर पाता है. ऐसी स्थिति में, Google उन क्रॉल की गिनती करता है जो आपकी robots.txt फ़ाइल के उपलब्ध होने पर पूरे किए जा सकते थे. हालांकि, robots.txt फ़ाइल के उपलब्ध न होने की वजह से Google उन क्रॉल को पूरा नहीं कर पाया. यह समस्या है या नहीं, इसकी पुष्टि करने के लिए robots.txt फ़ेच करने का स्टेटस देखें.