Google Search पर एचटीटीपी स्टेटस कोड, नेटवर्क की गड़बड़ियों, और डीएनएस की गड़बड़ियों का कैसे असर पड़ता है

इस पेज पर बताया गया है कि Google Search पर अलग-अलग एचटीटीपी स्टेटस कोड, नेटवर्क की गड़बड़ियों, और डीएनएस की गड़बड़ियों का कैसे असर पड़ता है. हमने यहां ऐसे 20 मुख्य स्टेटस कोड के बारे में बताया है जो Googlebot को वेब पर मिले हैं. साथ ही, हमने नेटवर्क और डीएनएस की सबसे अहम गड़बड़ियों के बारे में भी बताया है. इसमें, हमने 418 (I'm a teapot) जैसे कुछ खास स्टेटस कोड को शामिल नहीं किया है. इस पेज पर बताई गई सभी समस्याओं के लिए, एक गड़बड़ी या चेतावनी जनरेट होती है. इस गड़बड़ी या चेतावनी को Search Console की पेज को इंडेक्स करने के बारे में जानकारी देने वाली रिपोर्ट में देखा जा सकता है.

एचटीटीपी स्टेटस कोड

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

Search Console, 4xx–5xx के बीच आने वाले स्टेटस कोड और रीडायरेक्ट न कर पाने की स्थिति बताने वाले स्टेटस कोड (3xx), दोनों के लिए गड़बड़ी के मैसेज जनरेट करता है. अगर सर्वर ने 2xx स्टेटस कोड के साथ जवाब दिया है, तो जवाब में दिखाए गए पेज के कॉन्टेंट को इंडेक्स किया जा सकता है.

इस टेबल में Googlebot को मिले एचटीटीपी स्टेटस कोड हैं. साथ ही, इसमें यह भी बताया गया है कि Google हर स्टेटस कोड को कैसे मैनेज करता है.

एचटीटीपी स्टेटस कोड

2xx (success)

Google, कॉन्टेंट की समीक्षा करके यह तय करता है कि उसे इंडेक्स किया जा सकता है या नहीं. अगर कॉन्टेंट में कोई गड़बड़ी दिखती है, जैसे कि कोई खाली पेज या गड़बड़ी का मैसेज, तो Search Console soft 404 गड़बड़ी वाला मैसेज दिखाएगा.

200 (success)

Google, इंडेक्स करने वाले सिस्टम को कॉन्टेंट भेजता है. इंडेक्स करने वाले सिस्टम, कॉन्टेंट को इंडेक्स कर सकते हैं. हालांकि, यह ज़रूरी नहीं है कि कॉन्टेंट को हमेशा इंडेक्स किया ही जाए.

201 (created)
202 (accepted)

Googlebot तय समय तक कॉन्टेंट का इंतज़ार करता है. इसके बाद, जितना भी कॉन्टेंट मिलता है, वह उसे इंडेक्स करने वाले सिस्टम को भेज देता है. इंतज़ार करने का समय, उपयोगकर्ता एजेंट के हिसाब से अलग-अलग होता है. उदाहरण के लिए, Googlebot स्मार्टफ़ोन के लिए यह समय Googlebot इमेज के समय से अलग हो सकता है.

204 (no content)

Googlebot, इंडेक्स करने वाले सिस्टम को सिग्नल भेजता है कि उसे कोई कॉन्टेंट नहीं मिला. Search Console, साइट के पेज को इंडेक्स करने के बारे में जानकारी देने वाली रिपोर्ट में, एक soft 404 गड़बड़ी दिखा सकता है.

3xx (redirection)

Googlebot एक बार में ज़्यादा से ज़्यादा 10 बार रीडायरेक्ट को फ़ॉलो करता है. अगर 10 बार के बाद भी क्रॉलर को कॉन्टेंट नहीं मिलता है, तो Search Console, साइट के पेज को इंडेक्स करने के बारे में जानकारी देने वाली रिपोर्ट में रीडायरेक्ट की गड़बड़ी दिखाएगा. Googlebot, कितनी बार रीडायरेक्ट को फ़ॉलो करता है, यह हर उपयोगकर्ता एजेंट के हिसाब से अलग होता है. उदाहरण के लिए, 'Googlebot स्मार्टफ़ोन' के लिए यह संख्या 'Googlebot इमेज' की संख्या से अलग हो सकती है.

robots.txt होने पर, Googlebot आरएफ़सी 1945 के मुताबिक, कम से कम पांच बार रीडायरेक्ट को फ़ॉलो करता है. इसके बाद, वह रुक जाता है और robots.txt फ़ाइल के लिए, रीडायरेक्ट को 404 की तरह मानता है.

Googlebot, रीडायरेक्ट करने वाले यूआरएल से मिला कॉन्टेंट अनदेखा कर देता है और इंडेक्स करने के लिए, आखिरी टारगेट यूआरएल के कॉन्टेंट का इस्तेमाल करता है.

301 (moved permanently)

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

302 (found)

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

303 (see other)
304 (not modified)

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

307 (temporary redirect) 302 के बराबर.
308 (moved permanently) 301 के बराबर.

4xx (client errors)

इंडेक्स करने वाले Google के सिस्टम उन यूआरएल का कॉन्टेंट इंडेक्स नहीं करते हैं जिन्हें इंडेक्स करने पर 4xx स्टेटस कोड मिलता है. साथ ही, अगर इंडेक्स किए गए यूआरएल के लिए 4xx स्टेटस कोड मिलता है, तो उन्हें इंडेक्स से हटा दिया जाता है.

अगर यूआरएल से 4xx स्टेटस कोड मिलता है, तो Googlebot ऐसे यूआरएल से मिले कॉन्टेंट को अनदेखा कर देता है.

400 (bad request)

429 को छोड़कर, सभी 4xx गड़बड़ियों को एक जैसा ही माना जाता है: Googlebot, इंडेक्स करने वाले सिस्टम को यह सिग्नल भेजता है कि कॉन्टेंट मौजूद नहीं है.

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

401 (unauthorized)
403 (forbidden)
404 (not found)
410 (gone)
411 (length required)
429 (too many requests)

Googlebot को 429 स्टेटस कोड से यह पता चलता है कि सर्वर पर लोड ज़्यादा है. साथ ही, वह इसे सर्वर की गड़बड़ी मानता है.

5xx (server errors)

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

अगर robots.txt फ़ाइल, 30 से ज़्यादा दिन तक सर्वर की गड़बड़ी वाले स्टेटस कोड भेजती है, तो Google, कैश मेमोरी में सेव की गई robots.txt की पिछली कॉपी का इस्तेमाल करेगा. अगर robots.txt की पिछली कॉपी उपलब्ध नहीं है, तो Google यह मानकर चलता है कि क्रॉल करने की कोई पाबंदी नहीं है.

अगर यूआरएल से 5xx स्टेटस कोड मिलता है, तो Googlebot ऐसे यूआरएल से मिले कॉन्टेंट को अनदेखा कर देता है.

500 (internal server error)

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

502 (bad gateway)
503 (service unavailable)

soft 404 गड़बड़ियां

soft 404 गड़बड़ी एक यूआरएल है, जो लोगों को एक ऐसे पेज पर ले जाता है जहां 'यह पेज मौजूद नहीं है' लिखा हो. इसके अलावा, इस पेज पर 200 (success) स्टेटस कोड भी दिखता है. कुछ मामलों में, यह गड़बड़ी एक ऐसा पेज हो सकती है जो खाली हो या जिस पर कोई खास कॉन्टेंट मौजूद न हो.

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

  • सर्वर-साइड इन्क्लूड (एसएसआई) फ़ाइल मौजूद न होने पर.
  • डेटाबेस से कनेक्शन टूट जाने पर.
  • खोज के नतीजों का अंदरूनी पेज खाली होने पर.
  • JavaScript फ़ाइल अनलोड होने या मौजूद न होने पर.

200 (success) स्टेटस कोड दिखाने के बाद, गड़बड़ी का मैसेज दिखाने या इसका सुझाव देने या पेज पर किसी तरह की गड़बड़ी दिखाने से, लोगों को खराब अनुभव मिलता है. उपयोगकर्ताओं को ऐसा लग सकता है कि वह पेज एक लाइव पेज है जो असल में काम करता है, लेकिन उन्हें किसी गड़बड़ी के साथ दिखाया जाता है. ऐसे पेजों को Search में शामिल नहीं किया जाता है.

जब पेज पर मौजूद कॉन्टेंट के आधार पर Google के एल्गोरिदम को पता चलता है कि असल में यह गड़बड़ी वाला पेज है, तो Search Console, साइट की पेज को इंडेक्स करने के बारे में जानकारी देने वाली रिपोर्ट में पेज की soft 404 गड़बड़ी की जानकारी दिखाता है.

soft 404 की गड़बड़ियां ठीक करना

soft 404 गड़बड़ियों को ठीक करने के कई तरीके हैं. आपके पेज का स्टेटस क्या है और आपको किस तरह के बदलाव करने हैं, इसके आधार पर इनमें से कोई तरीका चुना जा सकता है:

पता लगाएं कि आपके उपयोगकर्ताओं के लिए इनमें से कौनसा तरीका सबसे अच्छा रहेगा.

पेज और कॉन्टेंट अब मौजूद नहीं है

अगर आपने अपना पेज हटा दिया है और आपकी साइट पर ऐसा कोई दूसरा पेज मौजूद नहीं है जिसका कॉन्टेंट हटाए गए पेज के कॉन्टेंट से मेल खाता हो, तो उपयोगकर्ताओं को पेज पर 404 (not found) या 410 (gone) रिस्पॉन्स (स्टेटस) कोड दिखाएं. इन स्टेटस कोड से सर्च इंजन को यह पता चलता है कि पेज मौजूद नहीं है और उसके कॉन्टेंट को इंडेक्स नहीं किया जाना चाहिए.

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

  • वेबसाइट पर आने वाले लोगों को साफ़ तौर पर बताएं कि वे जो पेज खोज रहे हैं वह मौजूद नहीं है. ऐसी भाषा का इस्तेमाल करें जो लोगों को समझ आए और उनका ध्यान खींचे.
  • पक्का करें कि आपका 404 पेज, दिखने और इस्तेमाल करने में आपकी साइट के बाकी पेजों के जैसा ही हो. इसमें, नेविगेशन भी शामिल है.
  • इस पेज पर, अपने सबसे लोकप्रिय लेखों या पोस्ट के लिंक दें. इनके अलावा, अपनी साइट के होम पेज का लिंक भी दें.
  • उपयोगकर्ताओं को टूटे हुए लिंक की शिकायत करने का तरीका बताएं.

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

पेज या कॉन्टेंट को अब किसी दूसरी साइट पर ले जाया गया है

अगर आपके पेज को किसी दूसरी साइट पर ले जाया गया है या उसके बदले कोई और पेज तैयार किया गया है, तो उपयोगकर्ता को दूसरे यूआरएल पर रीडायरेक्ट करने के लिए 301 (permanent redirect) दिखाएं. ऐसा करने से, इस्तेमाल करने वाले लोगों के ब्राउज़िंग अनुभव में कोई रुकावट नहीं आएगी. साथ ही, सर्च इंजन को अपने पेज के नए यूआरएल के बारे में बताने का यह एक अच्छा तरीका है. आपका यूआरएल सही कोड दिखा रहा है या नहीं, इसकी पुष्टि करने के लिए, यूआरएल जांचने वाले टूल का इस्तेमाल करें.

पेज और कॉन्टेंट अब भी मौजूद है

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

नेटवर्क और डीएनएस की गड़बड़ियां

नेटवर्क और डीएनएस की गड़बड़ियां होने पर, Google Search में यूआरएल की मौजूदगी पर इनका तुरंत और गलत असर पड़ता है. Googlebot, नेटवर्क के टाइम आउट होने, कनेक्शन रीसेट करने, और डीएनएस की गड़बड़ियों को 5xx सर्वर की गड़बड़ियों की तरह ही मानता है. नेटवर्क की गड़बड़ियां होने पर, क्रॉल करने की प्रक्रिया तुरंत धीमी होने लगती है. ऐसा इसलिए होता है, क्योंकि नेटवर्क की गड़बड़ी मौजूद होने से यह पता चलता है कि शायद सर्वर, आने वाले लोड को हैंडल नहीं कर पा रहा है. Googlebot, साइट को होस्ट करने वाले सर्वर तक नहीं पहुंच पाता है. इसलिए, Google को सर्वर से कोई कॉन्टेंट नहीं मिलता है. कॉन्टेंट की कमी की वजह से, Google क्रॉल किए गए यूआरएल को इंडेक्स नहीं कर सकता. साथ ही, इंडेक्स हो चुके जिन यूआरएल को ऐक्सेस नहीं किया जा सकता उन्हें Google के इंडेक्स से कुछ ही दिनों में हटा दिया जाएगा. Search Console, हर गड़बड़ी के लिए, गड़बड़ी से जुड़े कई मैसेज जनरेट कर सकता है.

नेटवर्क की गड़बड़ियों को डीबग करना

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

  • अपनी फ़ायरवॉल की सेटिंग और लॉग देखें. हो सकता है कि वहां नियमों का ऐसा सेट मौजूद हो जो ज़्यादातर आईपी पतों को क्राॅल होने से रोकता हो. पक्का करें कि Googlebot के आईपी पतों को फ़ायरवॉल के किसी भी नियम से ब्लॉक न किया गया हो.
  • नेटवर्क ट्रैफ़िक की जांच करें. tcpdump और Wireshark जैसे टूल का इस्तेमाल करके, टीसीपी पैकेट को कैप्चर करें और उनका विश्लेषण करें. इन टूल की मदद से, ऐसी अनियमितताओं का पता लगाया जा सकता है जो नेटवर्क के किसी खास हिस्से या किसी सर्वर मॉड्यूल के बारे में बताती हों.
  • किसी भी संदिग्ध गतिविधि का पता न चलने पर, होस्टिंग की सेवा देने वाली कंपनी से संपर्क करें.

सर्वर के ऐसे किसी भी हिस्से में गड़बड़ी हो सकती है जो नेटवर्क के ट्रैफ़िक को मैनेज करता हो. उदाहरण के लिए, कुछ नेटवर्क इंटरफ़ेस बहुत लोड होने की वजह से सभी पैकेट ट्रांसफ़र नहीं कर पाते हैं. इस वजह से टाइम आउट (कनेक्शन न बना पाना) की स्थिति बनती है और कनेक्शन भी रीसेट होते हैं (RST पैकेट भेजा जाता है, क्योंकि एक पोर्ट गलती से बंद हो जाता है).

डीएनएस की गड़बड़ियों को डीबग करना

आम तौर पर, डीएनएस की गड़बड़ियां गलत कॉन्फ़िगरेशन की वजह से होती हैं. हालांकि, Googlebot की डीएनएस क्वेरी को ब्लॉक करने वाले किसी फ़ायरवॉल नियम की वजह से भी ये गड़बड़ियां हो सकती हैं. डीएनएस की गड़बड़ियों को डीबग करने के लिए, ये करें:

  • अपने फ़ायरवॉल के नियमों की जांच करें. पक्का करें कि Google के किसी भी आईपी पते को फ़ायरवॉल के किसी नियम से ब्लॉक न किया गया हो. इसके अलावा, यह भी पक्का करें कि UDP और TCP, दोनों अनुरोधों को अनुमति दी गई हो.
  • अपने डीएनएस रिकॉर्ड की जांच करें. यह पक्का करें कि आपका A रिकॉर्ड, सही आईपी पते और CNAME रिकॉर्ड, सही होस्टनेम पर ले जा रहे हों. उदाहरण के लिए: 
    dig +nocmd example.com a +noall +answer
    dig +nocmd www.example.com cname +noall +answer
  • यह जांच करें कि आपके सभी नाम सर्वर, आपकी साइट के सही आईपी पतों पर ले जा रहे हों. उदाहरण के लिए: 
    dig +nocmd example.com ns +noall +answer
example.com.    86400  IN  NS  a.iana-servers.net.
example.com.    86400  IN  NS  b.iana-servers.net.
dig +nocmd @a.iana-servers.net example.com +noall +answer
example.com.    86400  IN  A  93.184.216.34
dig +nocmd @b.iana-servers.net example.com +noall +answer
...
  • अगर आपने पिछले 72 घंटों में अपने डीएनएस कॉन्फ़िगरेशन में बदलाव किए हैं, तो हो सकता है कि पूरी दुनिया में मौजूद डीएनएस नेटवर्क पर, इन बदलावों को लागू होने में कुछ समय लगे. आपके पास Google की सार्वजनिक डीएनएस कैश मेमोरी को रीफ़्रेश करके, इन बदलावों के लागू होने की गति को बढ़ाने का विकल्प है.
  • अगर आपका खुद का डीएनएस सर्वर है, तो पक्का करें कि वह ठीक हो और उस पर ज़रूरत से ज़्यादा लोड न हो.