2021 में मुझे एक क्लाइंट की 14,000-पृष्ठ की ई-कॉमर्स साइट मिली जिसकी पिछली एजेंसी ने "अंतरराष्ट्रीय SEO किया था"। ऑडिट के तीन सप्ताह बाद मुझे Google Search Console में 31,000 hreflang त्रुटियां मिलीं। इकतीस हज़ार। साइट के सात भाषा संस्करण थे और हर एक पृष्ठ को अपना self-referencing टैग नहीं था। जर्मन पृष्ठ फ्रेंच URLs की ओर संकेत कर रहे थे। x-default एक ऐसे URL की ओर संकेत कर रहा था जो कहीं और 301-redirect हो रहा था। गैर-अंग्रेजी बाज़ारों से organic ट्रैफ़िक आठ महीने से बंद था और किसी ने भी संबंध नहीं बनाया।
वह एक परियोजना शायद सबसे बड़ा कारण है कि मैं अब hreflang कार्यान्वयन को एक first-class इंजीनियरिंग समस्या के रूप में मानता हूँ, न कि एक afterthought के रूप में जो आप अनुवाद sprint के दौरान जोड़ते हैं।
तो चलिए इसे सही तरीके से शुरू करते हैं।
---
hreflang असल में क्या करता है (और क्या नहीं करता है)
मैं इसे छोटा रखूंगा क्योंकि ज्यादातर लोगों को पहले से ही एक सामान्य विचार है। hreflang एक HTML attribute है (या HTTP header, या XML sitemap entry) जो Google को बताता है कि किसी page का कौन सा version किस language और region combination से corresponds करता है। यह rankings को सीधे change नहीं करता। यह बदलता है कि Google किस URL को किस user को किस country में दिखाता है।
बस इतना ही। यह एक signal है, directive नहीं। अगर implementation broken है या contradictory है तो Google इसे ignore कर सकता है। और करता है। नियमित रूप से।
यह क्या नहीं करता: यह users को गलत regional version access करने से block नहीं करता, यह आपकी content strategy को replace नहीं करता, और absolutely thin translated pages के लिए compensate नहीं करता जो सिर्फ machine-translated copies हैं जिनमें कोई localization effort नहीं है।
कुछ भी पढ़ने से पहले Google के अपने hreflang documentation को पढ़ने लायक है। यह एक stale biscuit से ज्यादा सूखा है लेकिन यह accurate है।
---
पांच Mistakes जो मुझे लगभग हर Audit में दिखाई देती हैं
Self-Referencing Tags का अभाव
यह बड़ी वाली है। एक hreflang cluster में हर page में एक tag होना चाहिए जो अपने आप को point करे। सिर्फ दूसरे variants नहीं। अपने आप को।
अगर आपका English page example.com/en/product/ के पास /de/product/ और /fr/product/ को point करने वाले tags हैं लेकिन /en/product/ को point करने वाला hreflang="en" भूल जाता है, तो पूरा cluster technically invalid है। Google जरूरी नहीं कि एक hard error throw करे लेकिन यह पूरे signal set में अपना confidence कम कर देगा।
मैंने यह mistake उन sites पर देखा है जो developers द्वारा बनाए गए थे जिन्होंने एक blog post पढ़ा, एक example देखा जिसमें दो variants थे, और कभी self-referencing tag notice नहीं किया क्योंकि example बुरी तरह से लिखा गया था। Names नहीं ले रहा हूं।
रिटर्न टैग गायब हैं या टूटे हुए हैं
hreflang एक दोतरफा संबंध है। अगर आपका English पेज आपके German पेज की ओर इशारा करता है, तो German पेज को वापस English पेज की ओर इशारा करना चाहिए। अगर वह रिटर्न टैग छूट जाए तो Google को एक टूटा हुआ हैंडशेक दिखता है।
2021 के प्रोजेक्ट पर जिसका मैंने जिक्र किया, एक डेवलपर ने केवल English टेम्पलेट में hreflang जोड़ा था। German, French और Spanish टेम्पलेट में कोई hreflang ही नहीं था। तो Google को आधी बातचीत मिल रही थी और वह समझदारी से सभी को नजरअंदाज कर रहा था।
गलत भाषा कोड
BCP 47 भाषा टैग का उपयोग करें। इसका मतलब है en सामान्य रूप से English के लिए, en-GB British English के लिए, en-US American English के लिए। न कि en_GB। न कि english। न कि ENG।
मुझे Seahawk में पिछले साल ऑडिट की गई एक fintech साइट पर lang="english-uk" मिला। डेवलपर ने स्पष्ट रूप से केवल अनुमान लगाई थी। यह 14 महीने तक लाइव रहा था।
x-default या तो गायब है या गलत है
x-default को एक पेज की ओर इशारा करना चाहिए जो उन उपयोगकर्ताओं को हैंडल करता है जिनकी भाषा या क्षेत्र आपके किसी अन्य वेरिएंट से मेल नहीं खाता। आमतौर पर आपका होमपेज या एक भाषा-चयन पेज। यह सिर्फ "English संस्करण" का पर्यायवाची नहीं है। मैंने x-default को एक ऐसे URL की ओर इशारा करते देखा है जो 404 रिटर्न करता है, एक redirect chain की ओर, और एक बार, यादगार तरीके से, एक staging environment की ओर।
अगर आपके पास कोई समझदारी भरा fallback पेज नहीं है, तो x-default को गलत तरीके से उपयोग करने से बेहतर है कि आप इसे छोड़ दें। लेकिन आमतौर पर आपके पास एक होना चाहिए।
Canonical और hreflang को गलत तरीके से एक साथ उपयोग करना
आपके canonical tag और आपके hreflang tags एक दूसरे का विरोध नहीं करना चाहिए। अगर /en-gb/page/ का canonical /en/page/ की ओर इशारा करता है, लेकिन hreflang भी अपने आप को en-GB के रूप में घोषित करता है, तो आपने एक signal conflict बना दिया है। Canonical प्रभावी रूप से कह रहा है "मैं इस URL का पसंदीदा संस्करण नहीं हूँ" जबकि hreflang कह रहा है "मैं British English users के लिए पसंदीदा संस्करण हूँ"। Google को किसी एक interpretation को चुनना पड़ता है और वह अक्सर दोनों में से कोई नहीं चुनता।
---
बड़ी साइट्स पर लागू करें — अपना दिमाग खोए बिना
Template-Level बनाम Page-Level
50 pages की साइट पर, आप हर hreflang tag को manually बना सकते हैं। 5,000 pages की साइट पर, आप नहीं कर सकते। आपको उन्हें programmatically generate करना होगा।
सबसे स्वच्छ approach जो मुझे मिला है वह है अपने URL mappings को एक structured data source (एक database table या छोटे projects के लिए एक flat JSON file भी) में store करना और tags को render time पर generate करना। WordPress में, Yoast SEO और Rank Math दोनों standard setups के लिए reasonably अच्छी तरह से काम करते हैं, लेकिन दोनों विफल हो जाते हैं जब आपकी URL structures भाषाओं में एक predictable /en/, /de/, /fr/ prefix pattern का पालन करने के बजाय अलग हों।
अगर आपके URLs non-uniform हैं (कहें, translated slugs जैसे example.com/en/running-shoes/ और example.com/de/laufschuhe/), तो आपको एक explicit mapping table की जरूरत है। कोई plugin यह automatically figure नहीं करेगा। मैंने यह 2022 में एक sportswear client पर महंगे तरीके से सीखा था जिसके translated slugs English ones से completely independent थे।
XML साइटमैप विधि
बहुत बड़ी साइट्स के लिए, मैं inline HTML tags के ऊपर XML sitemap method को prefer करता हूँ। यह <head> को clean रखता है, programmatically audit करना आसान है, और आप page templates को छुए बिना sitemap को update कर सकते हैं।
Format कुछ इस तरह दिखता है (conceptually, code fence के बिना): हर <url> block में multiple <xhtml:link> entries होती हैं, एक हर language variant के लिए self-referencing one सहित। xmlns:xhtml namespace declaration <urlset> element में present होना चाहिए या पूरी चीज़ silently break हो जाती है।
एक समस्या यह है: साइटमैप तरीका केवल तभी काम करता है जब Google ने हाल ही में आपके साइटमैप को क्रॉल और इंडेक्स किया हो। अगर आपकी बड़ी साइट पर क्रॉल बजट की समस्याएं हैं, तो HTML तरीका ज्यादा भरोसेमंद है क्योंकि Googlebot हर पेज को क्रॉल करते समय टैग को इनलाइन पढ़ता है।
गैर-HTML कंटेंट के लिए HTTP हेडर्स
क्या आपके पास PDF या अन्य गैर-HTML फाइलें हैं जिन्हें hreflang की जरूरत है? HTTP हेडर्स का इस्तेमाल करें। आपका सर्वर rel="alternate" और hreflang एट्रिब्यूट के साथ एक Link हेडर लौटाता है। यह व्यावहार में दुर्लभ है लेकिन मैंने बड़ी कानूनी और वित्तीय साइटों को देखा है जहां हजारों मल्टी-लैंग्वेज PDF डॉक्यूमेंट हैं जहां यह वास्तव में मायने रखता है।
---
वह टूलिंग जो वास्तव में मदद करती है
देखिए, मैंने सालों से बहुत सारे टूल्स का इस्तेमाल किया है। ये वो हैं जिनके लिए मैं वास्तव में जाता हूं:
- Screaming Frog SEO Spider: एक क्रॉल चलाएं, hreflang टैब पर जाएं। यह गायब रिटर्न टैग, गायब self-reference, टूटे हुए URL और अमान्य लैंग्वेज कोड को एक जगह फ्लैग करेगा। यह हर अंतर्राष्ट्रीय ऑडिट पर मेरा पहला रुकने की जगह है। £199/year पर यह सबसे अच्छा-मूल्य तकनीकी SEO टूल है जो मैं जानता हूं।
- Ahrefs Site Audit: अच्छा सेकेंडरी चेक, विशेषकर अगर आप एक ही प्लेटफॉर्म में ऑर्गेनिक ट्रैफिक डेटा के साथ क्रॉस-रेफरेंस करना चाहते हैं।
- Merkle द्वारा hreflang Tags Testing Tool: निःशुल्क, https://technicalseo.com/tools/hreflang/ पर उपलब्ध। URL पेस्ट करें, यह पूरे क्लस्टर की जांच करता है। मरम्मत के बीच में किसी विशेष पेज की जल्दी जांच के लिए शानदार।
- Google Search Console: Legacy Tools के तहत International Targeting रिपोर्ट। अपडेट होने में धीमा लेकिन यह Google कैसे वास्तव में आपके कार्यान्वयन को पढ़ रहा है इसका आधार सत्य है।
- Sitebulb: अगर आप एक ऐसा visual crawler चाहते हैं जो शुरुआती लोगों के लिए ज्यादा आसान reporting देता हो, तो Sitebulb hreflang cluster relationships को visualize करने का अच्छा काम करता है।
जिसका मैं उपयोग नहीं करता: वे hreflang generator tools जो आपके लिए एक static tag block तैयार करते हैं जिसे आप copy-paste कर सकें। ये syntax सीखने के लिए ठीक हैं। 20 पेजों से ज्यादा किसी भी चीज़ के लिए ये बेकार हैं क्योंकि आप इसे manually maintain करने के लिए फिर से लौट जाते हैं।
---
बड़े स्तर पर Auditing: एक प्रक्रिया जो काम करती है
यह वह वास्तविक step-by-step है जो मैं हर international audit पर चलाता हूँ, 200+ multilingual sites पर यह करने के बाद refined:
- Screaming Frog से site को crawl करें, यह सुनिश्चित करते हुए कि अगर site एक JS framework का उपयोग करता है तो JavaScript rendering चालू है।
- hreflang data को एक spreadsheet में export करें। URLs को उनके intended cluster के आधार पर group करें।
- हर cluster के लिए check करें: self-referencing tag, सभी variants से return tags, valid BCP 47 codes, consistent canonical alignment।
- x-default URLs को 200 status codes के लिए check करें। 301s नहीं। 200s।
- अपने XML sitemaps के विरुद्ध cross-reference करें अगर आप sitemap method का उपयोग कर रहे हैं। sitemap में हर URL को 200 return करना चाहिए।
- Merkle testing tool के माध्यम से 20-30 pages का एक नमूना चलाएँ ताकि यह verify हो सके कि Google वाकई वही पढ़ रहा है जो आप सोच रहे हैं।
- Search Console से International Targeting report निकालें और विशेष रूप से "No return tag" errors को देखें। ये लगभग हमेशा उन templates का लक्षण होते हैं जो नई language जोड़ी जाने के समय update नहीं किए गए थे।
- ठीक करें, 2 हफ्तों में re-crawl करें, Search Console में verify करें कि error count गिर गया है (GSC के data को fixes को पूरी तरह reflect करने में 4-6 हफ्ते लग सकते हैं)।
यह एक बार की प्रक्रिया नहीं है। हर quarter में अपने calendar में एक recurring crawl डालें। International sites बदलते हैं। नए pages add होते हैं, पुराने pages redirect होते हैं, और hreflang clusters silently break हो जाते हैं जब कोई देख नहीं रहा होता।
---
hreflang का इस्तेमाल कब न करें
यह ज्यादातर guides में skip हो जाता है और यह मुझे पागल कर देता है।
अगर आपके पास एक language है लेकिन multiple regions हैं (मान लीजिए, UK और Australia दोनों English में हैं), तो hreflang का use करने लायक है लेकिन केवल अगर content वाकई उन users के लिए serve करने के लिए काफी अलग है। अगर आपके UK और AU pages 95% identical हैं, तो आप clarity से ज्यादा confusion पैदा कर सकते हैं। Google एक variant को universally दिखाना चुन सकता है और आपके hreflang signals को ज्यादातर ignore किया जाएगा।
अगर आपको international markets से बहुत कम traffic मिल रहा है, तो hreflang implement करने में एक हफ्ता खर्च करना समय का सबसे अच्छा इस्तेमाल नहीं हो सकता। एक well-structured URL hierarchy, <html lang=""> attributes के साथ और Search Console में geotargeting settings तब तक आपको adequately cover करेंगे जब तक traffic volume एक full implementation को justify न करे।
और अगर आपकी site एक single-page app है जिसमें dynamic content loading है, तो पहले rendering side को ठीक करें। मैंने hreflang को perfectly implement करते देखा है static HTML shell में जबकि actual page content JavaScript-rendered था और Googlebot को सिर्फ एक loading spinner दिख रहा था। Internationalisation signals की चिंता करने से पहले indexability को fix करें।
---
FAQ
क्या hreflang टैग रैंकिंग को सीधे प्रभावित करते हैं?
नहीं। hreflang सिग्नल Google को बताते हैं कि किस यूजर को कौन सा URL दिखाना है, न कि उस URL को कैसे रैंक करना है। अप्रत्यक्ष रूप से, सही पेज को सही यूजर के सामने लाने से pogo-sticking कम होती है और एनगेजमेंट मेट्रिक्स में सुधार होता है, जिसका रैंकिंग पर अप्रत्यक्ष असर हो सकता है। लेकिन hreflang टैग जोड़ने से कोई सीधी रैंकिंग बूस्ट नहीं मिलता।
Google को hreflang में बदलाव प्रोसेस करने में कितना समय लगता है?
आमतौर पर बदलाव Search Console डेटा में पूरी तरह दिखने में 4-8 हफ्ते लगते हैं। क्रॉल फ्रीक्वेंसी यहाँ मायने रखती है। धीमी क्रॉल रेट वाली बड़ी साइट्स के लिए, यह 12 हफ्तों तक खिंच सकता है। बदलाव करने के बाद अगले दिन परिणाम न देखें। आप खुद को पागल कर देंगे।
क्या मैं Shopify स्टोर में hreflang का उपयोग कर सकता हूँ?
हाँ, लेकिन Shopify की नेटिव इंटरनेशनलाइजेशन (Markets के माध्यम से) अगर आप subfolders या subdomains का उपयोग कर रहे हैं तो बहुत कुछ यह काम आपके लिए संभाल लेती है। अगर आप अलग-अलग क्षेत्रों के लिए अलग-अलग स्टोर का उपयोग कर रहे हैं, तो आपको hreflang को मैनुअली theme कस्टमाइजेशन या ऐप के माध्यम से लागू करना होगा। मैंने यहाँ शुरुआती बिंदु के रूप में Shopify के अपने इंटरनेशनल SEO गाइडेंस का उपयोग किया है। यह काफी व्यापक है।
भाषा टार्गेटिंग और देश टार्गेटिंग में क्या अंतर है?
भाषा टार्गेटिंग (उदा., hreflang="es") कहती है: यह स्पेनिश भाषी लोगों को दिखाएँ, चाहे वे कहीं भी हों। देश टार्गेटिंग (उदा., hreflang="es-MX") कहती है: यह विशेष रूप से मेक्सिको में स्पेनिश भाषी लोगों को दिखाएँ। जब आपकी कंटेंट उस भाषा के सभी बोलने वालों के लिए एक जैसी हो तो केवल भाषा टैग का उपयोग करें। जब मूल्य निर्धारण, मुद्रा, या महत्वपूर्ण कंटेंट क्षेत्र के हिसाब से भिन्न हो तो भाषा-देश टैग का उपयोग करें।
मेरी hreflang errors उसके बाद बढ़ गईं जब मैंने उन्हें ठीक किया। ऐसा क्यों?
आमतौर पर क्योंकि कुछ tags को ठीक करने से Google आपके pages को ज़्यादा aggressively crawl करने लगता है और अब वह errors खोज रहा है जो पहले report नहीं हो रहे थे। यह एक reporting artifact है, इसका मतलब यह नहीं कि fixes से चीजें बदतर हुईं। आगे बढ़ते रहिए, 4 हफ्तों में फिर से crawl करवाइए।
---
Hreflang सचमुच उन चीजों में से एक है जहाँ 90% सही होना लगभग उतना ही बुरा है जितना 0% सही होना। टूटे हुए signals शोर पैदा करते हैं जिस पर Google सीखता है कि भरोसा न करे। इसे सही तरीके से करने का समय लीजिए, इसे नियमित रूप से audit करते रहिए, और इसे infrastructure के रूप में treat कीजिए। आपका international organic traffic आपको शांति से धन्यवाद देगा, जो सबसे अच्छे तरह का धन्यवाद है।