साइट एक अंग्रेजी भाषी उपयोगकर्ता को अमेरिका से एक पृष्ठ दिखाती है, जबकि Googlebot, जो शारीरिक रूप से माउंटेन व्यू के डेटा सेंटर में है, — एकदम अलग। औपचारिक रूप से यह पहले से ही क्लोकिंग है, भले ही आप केवल सामग्री को क्षेत्र के अनुसार अनुकूलित करना चाहते थे। भू-रीडायरेक्ट की 6 सामान्य गलतियों पर चर्चा करते हैं, जिनकी वजह से साइटें अपनी रैंक खोती हैं, मैनुअल दंड प्राप्त करती हैं और साझेदारी नेटवर्क में पूरे डोमेन को बैन किया जाता है।
भू-रीडायरेक्ट क्या है और यह व्यवसाय के लिए क्यों आवश्यक है
भू-रीडायरेक्ट एक तंत्र है, जो स्वचालित रूप से उपयोगकर्ता को उसकी देश के अनुसार अनुकूलित साइट के संस्करण पर पुनर्निर्देशित करता है: अलग भाषा, मुद्रा, मूल्य, प्रस्ताव। ऑनलाइन स्टोर इसका उपयोग करते हैं ताकि जर्मनी से खरीदार तुरंत यूरो में कीमतों के साथ जर्मन संस्करण पर पहुँच सके, न कि डॉलर में कैटलॉग को देखे। आर्बिट्राजर्स भू-रीडायरेक्ट का उपयोग बंडलों में करते हैं, ताकि भू-ट्रैफ़िक के आधार पर अलग-अलग ऑफ़र दिखा सकें — उदाहरण के लिए, Tier-1 देशों के उपयोगकर्ताओं को एक लैंडिंग, और अन्य को एक स्टॉप या अन्य उत्पाद।
समस्या यह है कि वही तर्क, जो उपयोगकर्ता के देश को IP के माध्यम से निर्धारित करता है, Googlebot पर भी लागू होता है। और Google के बॉट के IP पते शारीरिक रूप से अमेरिका में होते हैं, चाहे वे किसी भी देश के लिए पृष्ठ को अनुक्रमित कर रहे हों। यदि भू-रीडायरेक्ट प्रणाली क्रॉलर को जीवित व्यक्ति से अलग नहीं करती है, तो परिणाम एक ही होता है — Google उस पृष्ठ को देखता है, जिसे असली आगंतुक देखते हैं। यह Google सर्च सेंट्रल के अनुसार क्लोकिंग की औपचारिक परिभाषा है, और इसके लिए दंड — रैंकिंग में गिरावट से लेकर डोमेन को पूरी तरह से अनुक्रमण से बाहर करने तक।
Googlebot और मानव अलग-अलग पृष्ठ क्यों देखते हैं
यह भिन्नता तीन कारणों से एक साथ उत्पन्न होती है, और आमतौर पर ये एक-दूसरे पर चढ़ते हैं। सबसे पहले, Googlebot साइट को Google के स्वामित्व वाले IP पतों से क्रॉल करता है, और ये पते भू-सेवाओं (MaxMind, IP2Location और समान) द्वारा लगभग 100% मामलों में अमेरिकी के रूप में निर्धारित होते हैं। दूसरे, Googlebot अपना खुद का User-Agent भेजता है, जिसे अक्सर अलग कोड शाखा द्वारा संसाधित किया जाता है — कभी-कभी जानबूझकर, ताकि अनुक्रमण को न तोड़ा जाए, और कभी-कभी बस डेवलपर की गलती से। तीसरे, Googlebot का JS-रेंडरिंग के दौरान व्यवहार ब्राउज़र से भिन्न होता है: क्रॉलर उस रीडायरेक्ट को निष्पादित नहीं कर सकता, जो क्लाइंट-साइड JavaScript पर निर्भर है, और तब वह उस पृष्ठ के बिल्कुल अलग संस्करण को अनुक्रमित करता है, जिसे एक व्यक्ति JS चालू होने पर देखता है।
इसमें CDN-कैशिंग जोड़ें, जो एक देश के संस्करण पर "अटक" सकता है और इसे सभी को वितरित कर सकता है, और आपको ऐसी स्थिति मिलती है, जहाँ बिना किसी बुरे इरादे के साइट के मालिक के लिए खोज इंजन सामग्री को अनुक्रमित करता है, जो दर्शकों को दिखाई दे रही है। नीचे — छह विशिष्ट परिदृश्य हैं, जिनमें यह सबसे अधिक होता है।
गलती 1: IP के आधार पर रीडायरेक्ट बिना बॉट के User-Agent की जांच किए
सबसे सामान्य गलती — रीडायरेक्ट की तर्क केवल IP के माध्यम से देश के निर्धारण पर आधारित होती है, बिना यह जांचे कि अनुरोध कौन कर रहा है: व्यक्ति या क्रॉलर। परिणामस्वरूप, एक अमेरिकी IP रेंज से आने वाला Googlebot स्वचालित रूप से साइट के US संस्करण पर पहुँच जाता है, भले ही पृष्ठ मूल रूप से रूस या कजाकिस्तान से अनुरोधों के लिए प्रचारित किया गया हो। कुछ हफ्तों के स्कैनिंग के बाद, Google का अनुक्रमण "गलत" सामग्री के संस्करण से भरा होता है, और लक्षित क्षेत्रों में रैंकिंग बिना किसी स्पष्ट कारण के गिरने लगती है।
समाधान — हमेशा ज्ञात User-Agent और खोज इंजन बॉट्स (Googlebot, Bingbot, YandexBot) के IP रेंज को भू-रीडायरेक्ट से बाहर करना, उन्हें निश्चित देश के अनुसार पृष्ठ का कैनोनिकल संस्करण देना। User-Agent की जांच एक आवश्यक, लेकिन अपर्याप्त बाधा है, क्योंकि इसे आसानी से धोखा दिया जा सकता है, इसलिए गंभीर परियोजनाएँ अतिरिक्त रूप से IP को रिवर्स DNS लुकअप के माध्यम से सत्यापित करती हैं, जैसा कि Google द्वारा Googlebot की सत्यापन के लिए स्वयं की दस्तावेज़ीकरण में अनुशंसित है।
गलती 2: वास्तविक उपयोगकर्ताओं के बजाय डेटा सेंटर के IP के साथ परीक्षण करना
दूसरी गलती परीक्षण के चरण में उत्पन्न होती है। डेवलपर या मार्केटर भू-रीडायरेक्ट का परीक्षण सामान्य डेटा सेंटर प्रॉक्सी या VPN के माध्यम से करता है, और तर्क इस तरह से काम करता है जैसे कि यह आवश्यक देश से वास्तविक उपयोगकर्ता हो। लेकिन डेटा सेंटर के IP घरेलू ट्रैफ़िक से आसानी से अलग किए जा सकते हैं — कई CDN और एंटी-फ्रॉड सिस्टम उन्हें अलग ध्वज के साथ चिह्नित करते हैं, और भू-लक्षित करने की कुछ तर्क ऐसे पते के लिए अलग तरीके से व्यवहार कर सकती है, जो सामान्य घरेलू ISP के IP के लिए।
अंततः परीक्षण "सफल" होता है, विकास सर्वर पर रीडायरेक्ट सही ढंग से काम करता है, जबकि प्रोडक्शन में लक्षित देश के वास्तविक उपयोगकर्ताओं को वह संस्करण नहीं मिलता है, क्योंकि प्रदाता की भू-स्थान डेटाबेस या CDN नियम उनके IP को अलग तरह से व्याख्या करता है, जो परीक्षण डेटा सेंटर के पते से भिन्न होता है। सही परीक्षण के लिए रिहायशी प्रॉक्सी का उपयोग करना उचित है — इनमें आवश्यक देश के वास्तविक घरेलू प्रदाताओं के IP होते हैं, और भू-सेवाएँ उन्हें उसी तरह पहचानती हैं जैसे वे जीवित उपयोगकर्ता को पहचानती हैं। यह वास्तविक आगंतुक साइट को जो देखेगा, उसकी ईमानदार तस्वीर देता है, न कि "प्रकार" डेटा सेंटर के IP के लिए सरल संस्करण।
गलती 3: कैश और Vary-हेडर की अनुपस्थिति
यदि साइट CDN (Cloudflare, Fastly, Akamai) के पीछे है और भू-रीडायरेक्ट मूल सर्वर के स्तर पर लागू किया गया है, न कि स्वयं CDN पर, तो ऐसी स्थिति में आना आसान है जब CDN पहले दिए गए पृष्ठ के संस्करण को कैश कर लेता है और इसे सभी को वितरित करता है — अगली आगंतुक के देश की परवाह किए बिना। यह तब होता है जब सर्वर के उत्तर में सही Vary: Accept-Language या भू-प्रमुखता के लिए समान कैशिंग कुंजी निर्दिष्ट नहीं की जाती है।
इस मामले में, Googlebot पहले दौरे पर "सही" संस्करण को पकड़ सकता है, इसे अपनी अनुक्रमण प्रणालियों में कैश कर सकता है, और फिर हफ्तों तक उसी संस्करण को पुनः प्राप्त करता है, भले ही अन्य देशों के लिए सामग्री कब की बदल गई हो। इस बीच, उपयोगकर्ता वर्तमान, लेकिन अलग संस्करण देखते हैं — असंगति धीरे-धीरे बढ़ती है और इसे विभिन्न भू-स्थान के लिए सर्वर के उत्तर की सीधी तुलना के बिना निदान करना मुश्किल होता है, जैसे कि curl के माध्यम से हेडर को बदलकर या आवश्यक भू-स्थान के साथ प्रॉक्सी के माध्यम से।
गलती 4: JS-रीडायरेक्ट, जिसे बॉट अलग तरह से इंटरप्रेट करता है
Googlebot JavaScript को निष्पादित कर सकता है, लेकिन यह महत्वपूर्ण देरी के साथ करता है (दूसरी लहर का रेंडरिंग दिनों तक ले सकता है) और हमेशा उपयोगकर्ता के ब्राउज़र के समान नहीं होता है। यदि भू-रीडायरेक्ट क्लाइंट-साइड JS के माध्यम से लागू किया गया है — उदाहरण के लिए, window.location के माध्यम से geo-API के लिए fetch अनुरोध के बाद — तो पहले पास में क्रॉलर रीडायरेक्ट होने से पहले पृष्ठ को अनुक्रमित कर सकता है, अर्थात् उस विशेष क्षेत्र के लिए "गलत" सामग्री का संस्करण।
यह विशेष रूप से एकल पृष्ठ लैंडिंग (SPA) के लिए महत्वपूर्ण है, जहाँ व्यक्तिगतकरण की सारी तर्क क्लाइंट साइड पर होती है। सही दृष्टिकोण — भू-निर्धारण और रीडायरेक्ट को सर्वर साइड पर निष्पादित करना (CDN के एज-फंक्शन, Node.js पर मिडलवेयर, Nginx में नियम), ताकि Googlebot और उपयोगकर्ता HTTP-रीडायरेक्ट 302 प्राप्त करें इससे पहले कि पृष्ठ ब्राउज़र में रेंडर होना शुरू हो। यह इस बात पर निर्भरता को समाप्त करता है कि क्रॉलर उस विशेष समय पर JS को कैसे प्रोसेस करेगा।
गलती 5: एक URL बिना hreflang के विभिन्न भाषाई संस्करणों के लिए
पाँचवी गलती — एक ही URL पर कई भाषाई संस्करणों को बिना hreflang मार्कअप के सेवा देने का प्रयास। Google सीधे अनुशंसा करता है: यदि एक ही URL पर सामग्री उपयोगकर्ता की स्थानीयता के आधार पर भिन्न होती है, तो या तो प्रत्येक संस्करण के लिए अलग URL (सबडोमेन, सबफोल्डर या अलग डोमेन) दिए जाने चाहिए, जिसमें क्रॉस hreflang मार्कअप हो, या सभी को एक ही संस्करण दिखाना चाहिए, जिसमें बॉट भी शामिल हैं, और मैन्युअल रूप से भाषा बदलने की क्षमता जोड़ना चाहिए।
बिना hreflang के Google शारीरिक रूप से यह नहीं समझ सकता कि /product रूसी में और /product अंग्रेजी में — यह जानबूझकर विभिन्न दर्शकों के लिए अलग सामग्री है, न कि एक संस्करण को दूसरे के लिए छिपाने का प्रयास। परिणामस्वरूप, अनुक्रमण में एक यादृच्छिक संस्करण (आमतौर पर वह, जो बॉट को अंतिम क्रॉलिंग के दौरान उपलब्ध था) आता है, और यही सभी क्षेत्रों में रैंकिंग में आता है, जो परिणामों की प्रासंगिकता और रूपांतरण पर नकारात्मक प्रभाव डालता है।
गलती 6: VPN और मोबाइल प्रॉक्सी वाले उपयोगकर्ताओं के लिए कोई फॉलबैक नहीं
छठी गलती Googlebot से अधिक वास्तविक उपयोगकर्ताओं से संबंधित है — लेकिन यह भू-रीडायरेक्ट के विषय से सीधे संबंधित है, क्योंकि अक्सर बॉट के लिए व्यवहार को "सुधारने" का प्रयास इसे VPN या मोबाइल इंटरनेट वाले जीवित लोगों के लिए तोड़ देता है। मोबाइल ऑपरेटरों के उपयोगकर्ता अक्सर CGNAT (Carrier-Grade NAT) के माध्यम से नेटवर्क में प्रवेश करते हैं, जब हजारों ग्राहक एक ही बाहरी IP का उपयोग करते हैं, और भू-डेटाबेस ऐसे IP को पड़ोसी देश का या पूरी तरह से गलत तरीके से पहचान सकता है।
यदि साइट पर देश/भाषा का मैन्युअल स्विचर फॉलबैक के रूप में नहीं है, तो "गलत" निर्धारित IP वाला उपयोगकर्ता प्रासंगिक संस्करण पर अटका रहता है, इसे बदलने की कोई संभावना नहीं होती — और बस चला जाता है। इस तरह के परिदृश्य का परीक्षण करने के लिए, साइट के व्यवहार की जांच मोबाइल प्रॉक्सी के माध्यम से करना उचित है, जो CGNAT के भू-स्थान के व्यवहार के साथ वास्तविक ऑपरेटरों के IP का अनुकरण करते हैं — यह समस्या को पहले से देखने में मदद करता है, इससे पहले कि वास्तविक उपयोगकर्ता इसे खोजें और समर्थन में लिखें।
विभिन्न देशों से Google की नजरों से भू-रीडायरेक्ट की जांच कैसे करें
प्राथमिक निदान के लिए मुख्य उपकरण — Google सर्च कंसोल में "Googlebot के रूप में देखें" फ़ंक्शन (URL जांच उपकरण), जो दिखाता है कि Google क्रॉलर वास्तव में कौन सा HTML प्राप्त करता है। यदि वहाँ वह संस्करण नहीं दिखता है, जो आप अपने देश से ब्राउज़र में देखते हैं, — समस्या पुष्टि हो गई। लेकिन सर्च कंसोल हमेशा अमेरिकी IP से क्रॉल करता है, इसलिए क्षेत्रों के अनुसार साइट के व्यवहार की तुलना के लिए एक अलग परीक्षण परत की आवश्यकता होती है।
व्यावहारिक रूप से, मार्केटर्स और SEO विशेषज्ञ एंटी-डिटेक्ट ब्राउज़र में कई प्रोफाइल बनाते हैं — Dolphin Anty, AdsPower, Multilogin या GoLogin — और प्रत्येक प्रोफाइल को आवश्यक देश के प्रॉक्सी से जोड़ते हैं, ताकि मैन्युअल रूप से उपयोगकर्ता का मार्ग तय कर सकें: साइट खोलें, देखें कि कौन सा संस्करण लोड हुआ, कौन सा Accept-Language हेडर गया, क्या रीडायरेक्ट काम किया और किस URL पर। ऐसे परीक्षणों के लिए रिहायशी प्रॉक्सी सुविधाजनक होते हैं, जिनमें शहर या ऑपरेटर का सटीक चयन होता है — वे वास्तविक आगंतुक का सबसे ईमानदार अनुकरण देते हैं, डेटा सेंटर के पते के विपरीत, जिन्हें कुछ सेवाएँ भू-स्थान के मूल्यांकन से पहले ही संदिग्ध के रूप में चिह्नित कर सकती हैं।
| प्रॉक्सी का प्रकार | किस जांच के लिए उपयुक्त है | गलत परिणाम का जोखिम |
|---|---|---|
| रिहायशी प्रॉक्सी | आवश्यक देश/शहर में सामान्य घरेलू उपयोगकर्ता का अनुकरण | कम |
| मोबाइल प्रॉक्सी | CGNAT और मोबाइल भू-स्थान के दौरान व्यवहार की जांच | कम |
| डेटा सेंटर प्रॉक्सी | देश के अनुसार रीडायरेक्ट के कार्य का त्वरित परीक्षण | उच्च: भू-डेटाबेस का एक हिस्सा IP को घरेलू से अलग तरीके से चिह्नित करता है |
सर्वर लॉजिक के व्यवहार की जांच (न कि दृश्य रेंडर) के लिए, User-Agent को Googlebot पर और X-Forwarded-For हेडर को आवश्यक देश के IP पर बदलकर curl के माध्यम से सर्वर की कच्ची प्रतिक्रिया को देखना उपयोगी होता है — यह दिखाएगा कि सर्वर किस HTTP स्थिति और स्थान को देता है किसी भी JS-रेंडरिंग से पहले, और ऊपर सूचीबद्ध गलती 4 और गलती 1 को एक ही कमांड में पकड़ने की अनुमति देगा।
भू-रीडायरेक्ट की सुरक्षित सेटिंग के लिए चेकलिस्ट
- Googlebot, Bingbot और YandexBot को User-Agent के माध्यम से भू-रीडायरेक्ट की तर्क से बाहर रखा गया है और रिवर्स DNS के माध्यम से पुष्टि की गई है
- रीडायरेक्ट सर्वर साइड (302/307) पर लागू किया गया है, न कि केवल क्लाइंट-साइड JavaScript के माध्यम से
- भू-स्थान/भाषा के लिए सही CDN कैशिंग के लिए
Varyहेडर सेट किया गया है - प्रत्येक भाषाई संस्करण के लिए क्रॉस hreflang मार्कअप के साथ अलग URL है
- गलत तरीके से निर्धारित IP के लिए फॉलबैक के रूप में देश/भाषा का दृश्य मैन्युअल स्विचर है
- परीक्षण आवश्यक देशों से रिहायशी और मोबाइल प्रॉक्सी के माध्यम से किया जाता है, न कि केवल डेटा सेंटर के पते के माध्यम से
- हर तिमाही यह जांचा जाता है कि Google सर्च कंसोल क्या दिखा रहा है — संस्करण वास्तविक उपयोगकर्ताओं द्वारा देखे जाने वाले संस्करण के साथ मेल खाता है
निष्कर्ष
Googlebot जो देखता है और जो उपयोगकर्ता देखता है, के बीच का भेद शायद ही कभी जानबूझकर खोज इंजन को धोखा देने का प्रयास होता है — अधिकतर यह एक संचयित तकनीकी ऋण होता है: बॉट की जांच के बिना IP के आधार पर रीडायरेक्ट, Vary-हेडर के बिना कैश, JS-रीडायरेक्ट, जिसे क्रॉलर निष्पादित नहीं कर पाता, और भाषाई संस्करणों के लिए hreflang की अनुपस्थिति। इनमें से प्रत्येक गलती अकेले में छोटी लगती है, लेकिन मिलकर वे Google की नजरों में क्लोकिंग का एक क्लासिक चित्र बनाती हैं — इसके साथ संबंधित दंड के साथ।
यह सुनिश्चित करने का एकमात्र विश्वसनीय तरीका कि साइट बॉट्स और लोगों के लिए समान रूप से ईमानदारी से व्यवहार करती है, नियमित रूप से इसे आवश्यक देशों के वास्तविक IP से जांचना है। ऐसी निदान के लिए, हम रिहायशी प्रॉक्सी का उपयोग करने की सिफारिश करते हैं, ताकि सामान्य घरेलू उपयोगकर्ता का अनुकरण किया जा सके और मोबाइल प्रॉक्सी CGNAT वाले परिदृश्यों की जांच के लिए — यह आपके प्रत्येक क्षेत्र में आपकी दर्शकों द्वारा वास्तव में देखी जाने वाली तस्वीर को अधिकतम ईमानदारी से देता है, और समस्या को पकड़ने में मदद करता है इससे पहले कि Google का एल्गोरिदम इसे खोजे।