एचटीटीपी स्टेटस कोड, नेटवर्क की गड़बड़ियों, और डीएनएस की गड़बड़ियों का Google Search पर क्या असर पड़ता है
इस पेज पर बताया गया है कि Google Search पर अलग-अलग
एचटीटीपी स्टेटस कोड,
नेटवर्क की गड़बड़ियों, और डीएनएस की गड़बड़ियों का कैसे असर पड़ता है. हमने यहां ऐसे 20 मुख्य स्टेटस कोड के बारे में बताया है जो Googlebot को वेब पर मिले हैं. साथ ही, हमने नेटवर्क और डीएनएस की सबसे अहम गड़बड़ियों के बारे में भी बताया है. इसमें, हमने
418 (I'm a teapot)
जैसे कुछ खास स्टेटस कोड को शामिल नहीं किया है. इस पेज पर बताई गई सभी समस्याओं के लिए, एक गड़बड़ी या चेतावनी जनरेट होती है. इस गड़बड़ी या चेतावनी को
Search Console की
इंडेक्स कवरेज रिपोर्ट में देखा जा सकता है.
एचटीटीपी स्टेटस कोड
एचटीटीपी स्टेटस कोड तब जनरेट होते हैं, जब साइट को होस्ट करने वाला सर्वर, किसी क्लाइंट (उदाहरण के लिए, ब्राउज़र या क्रॉलर) के अनुरोध का जवाब देता है. हर एचटीटीपी स्टेटस कोड का अलग मतलब होता है, लेकिन अनुरोध का नतीजा अक्सर एक जैसा ही होता है. उदाहरण के लिए, ऐसे कई स्टेटस कोड हैं जिनका इस्तेमाल रीडायरेक्ट के लिए किया जाता है, लेकिन उनसे मिलने वाला नतीजा एक ही होता है.
Search Console, 4xx–5xx
के बीच आने वाले स्टेटस कोड और रीडायरेक्ट न कर पाने की स्थिति बताने वाले
स्टेटस कोड (3xx
), दोनों के लिए गड़बड़ी के मैसेज जनरेट करता है. अगर सर्वर ने
2xx
स्टेटस कोड के साथ जवाब दिया है, तो जवाब में दिखाए गए पेज के कॉन्टेंट को
इंडेक्स किया जा सकता है.
एचटीटीपी स्टेटस कोड | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|
2xx (success) |
Google, कॉन्टेंट की समीक्षा करके यह तय करता है कि उसे इंडेक्स किया जा सकता है या नहीं. अगर कॉन्टेंट में कोई गड़बड़ी दिखती है, जैसे कि
कोई खाली पेज या कोई गड़बड़ी का मैसेज, तो Search Console
|
|||||||||||
3xx (redirection) |
Googlebot एक बार में ज़्यादा से ज़्यादा 10 बार रीडायरेक्ट को फ़ॉलो करता है. अगर 10 बार के बाद भी क्रॉलर को कॉन्टेंट नहीं मिलता है, तो Search Console, साइट की इंडेक्स कवरेज रिपोर्ट में रीडायरेक्ट से जुड़ी गड़बड़ी दिखाएगा. Googlebot, कितनी बार रीडायरेक्ट को फ़ॉलो करता है, यह हर उपयोगकर्ता एजेंट के हिसाब से अलग होता है. उदाहरण के लिए, Googlebot स्मार्टफ़ोन के लिए यह सीमा Googlebot इमेज की सीमा से अलग हो सकती है. Googlebot, रीडायरेक्ट करने वाले यूआरएल से मिला कॉन्टेंट अनदेखा कर देता है और इंडेक्स करने के लिए, आखिरी टारगेट यूआरएल के कॉन्टेंट का इस्तेमाल करता है.
|
|||||||||||
4xx (client errors) |
इंडेक्स करने वाले Google के सिस्टम उन यूआरएल का कॉन्टेंट इंडेक्स नहीं करते हैं जिन्हें इंडेक्स करने पर
अगर यूआरएल से
|
|||||||||||
5xx (server errors) |
सर्वर की
अगर यूआरएल से
|
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 के इंडेक्स से कुछ ही दिनों में हटा दिया जाएगा. 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.34dig +nocmd @b.iana-servers.net example.com +noall +answer
... - अगर आपने पिछले 72 घंटों में अपने डीएनएस कॉन्फ़िगरेशन में बदलाव किए हैं, तो हो सकता है कि पूरी दुनिया में मौजूद डीएनएस नेटवर्क पर, इन बदलावों को लागू होने में कुछ समय लगे.
- अगर आप अपना खुद का डीएनएस सर्वर चला रहे हैं, तो पक्का करें कि वह ठीक हो और उस पर ज़रूरत से ज़्यादा लोड न हो.