SEO गाइड चरण 10: बहु-भाषा SEO

यह 13-चरणीय SEO गाइड का चरण 10 है। बहु-भाषा SEO आपको हर मार्केट को उनकी अपनी भाषा में सेवा देकर अपने ऑर्गेनिक ट्रैफ़िक को गुणा करने की अनुमति देता है — यदि गलत किया गया, तो यह डुप्लिकेट सामग्री का अराजकता पैदा कर सकता है।

आपकी हर जोड़ी गई भाषा आपके मौजूदा सामग्री पर एक गुणक है। एक भाषा में 50 पन्नों वाला एक साइट के पास 50 इंडेक्सेबल URL होते हैं। 5 भाषाएँ जोड़ें और आपके पास 250 हो जाते हैं। 20 भाषाएँ जोड़ें और आपके पास 1,000 हो जाते हैं। उन सभी URL में से प्रत्येक अपने स्थानीय Google परिणामों में स्वतंत्र रूप से रैंक कर सकता है।

लेकिन बहु-भाषा SEO SEO के तकनीकी रूप से सबसे जटिल क्षेत्रों में से एक है। गलत कार्यान्वयन डुप्लिकेट सामग्री, रैंकिंग पतन, और क्रॉल बजट की बर्बादी पैदा करता है। सही और गलत तरीके से अंतरराष्ट्रीयकरण की गई साइट के बीच का अंतर 10x ट्रैफ़िक का अंतर हो सकता है।

LANGR स्वयं 89 सक्रिय स्थानों में 108 भाषाओं में काम करता है — हमने बड़े पैमाने पर इन समस्याओं का समाधान किया है। यह गाइड वह सब कुछ साझा करता है जो हमने सीखा है।

बहु-भाषा SEO क्या शामिल करता है

बहु-भाषा SEO 8 महत्वपूर्ण क्षेत्रों में फैला है:

Hreflang कार्यान्वयन — गूगल को बताना कि कौन सा पन्ना कौन सी भाषा में है
स्थानीय राउटिंग रणनीतियाँ — उपडोमेन बनाम उपफोल्डर बनाम TLD
अनुवाद की गुणवत्ता — मशीन बनाम मानव बनाम हाइब्रिड अनुवाद
अंतरराष्ट्रीय लक्ष्यीकरण — खोज कंसोल कॉन्फ़िगरेशन
सामग्री स्थानीयकरण — अनुवाद से परे: सांस्कृतिक अनुकूलन
RTL समर्थन — दाएँ से बाएँ (अरबी, हिब्रू, फ़ारसी)
भाषा पहचान — सही संस्करण को स्वचालित रूप से प्रस्तुत करना
डुप्लिकेट सामग्री — परस्पर भाषाओं में ख़ुद को नष्ट होने से रोकना

1. Hreflang कार्यान्वयन

Hreflang टैग खोज इंजनों को बताते हैं कि कौन सा URL कौन सी भाषा और क्षेत्र को सेवा देता है। ये बहु-भाषा SEO का तकनीकी आधार हैं — और सबसे सामान्य गलत कॉन्फ़िगर किया गया तत्व है।

बुनियादी hreflang संकेतन:

<link rel="alternate" hreflang="en" href="https://example.com/page" />
<link rel="alternate" hreflang="da" href="https://example.com/da/page" />
<link rel="alternate" hreflang="de" href="https://example.com/de/page" />
<link rel="alternate" hreflang="x-default" href="https://example.com/page" />

महत्वपूर्ण नियम:

हर पन्ने को सभी वैकल्पिक संस्करणों का संदर्भ देना चाहिए (स्वयं सहित)
x-default फॉलबैक को निर्दिष्ट करता है (आमतौर पर अंग्रेजी या एक भाषा चयनकर्ता)
Hreflang टैग का पारस्परिक होना आवश्यक है (पृष्ठ A B को लिंक करता है, B को A के लिए वापस लिंक करना चाहिए)
ISO 639-1 भाषा कोड (en, da, de) का उपयोग करें न कि देश के कोड
क्षेत्र-विशिष्ट सामग्री के लिए: en-us, en-gb, pt-br (भाषा-क्षेत्र)
प्रति पृष्ठ अधिकतम ~50 hreflang प्रविष्टियाँ (प्रदर्शन सीमा)

तीन स्थानीयकरण विकल्प:

| विधि | के लिए सर्वोत्तम | नुकसान | |------|----------------|--------| | इन | छोटे साइट (< 10 भाषाएँ) | HTML को बड़ा करता है, धीमा पार्सिंग | | HTTP हैडर | नॉन-HTML फ़ाइलें (PDFs, APIs) | व्यापक रूप से समर्थित नहीं है | | XML साइटमैप | बड़े साइट (10+ भाषाएँ) | क्रॉलर द्वारा धीमा पता लगाना |

साइटमैप hreflang उदाहरण:

<url>
  <loc>https://example.com/page</loc>
  <xhtml:link rel="alternate" hreflang="en" href="https://example.com/page" />
  <xhtml:link rel="alternate" hreflang="da" href="https://example.com/da/page" />
  <xhtml:link rel="alternate" hreflang="de" href="https://example.com/de/page" />
  <xhtml:link rel="alternate" hreflang="x-default" href="https://example.com/page" />
</url>

सामान्य hreflang त्रुटियाँ:

स्वयं-उल्लेखित टैग का गायब होना (पृष्ठ स्वयं शामिल नहीं है)
गैर-पारस्परिक टैग (A B को संदर्भित करता है, लेकिन B A को संदर्भित नहीं करता)
गलत भाषा कोड (dk की बजाय da डेनिश के लिए)
गैर-200 URLs (रीडायरेक्ट, 404s) को इंगित करना
x-default को भाषा-विशिष्ट पृष्ठ के साथ मिलाना

क्या करें: अपनी साइट को क्रॉल करें और सभी hreflang टैग का निर्यात करें। गैर-पारस्परिक संबंधों की जाँच करें — यह सबसे सामान्य त्रुटि है और इस कारण Google पूरी hreflang सेटअप की अनदेखी कर सकता है।

2. स्थानीय राउटिंग रणनीतियाँ

आप विभिन्न भाषाओं के लिए URL को कैसे संरचित करते हैं, इसका SEO, उपयोगकर्ता अनुभव, और तकनीकी जटिलता पर प्रभाव पड़ता है। तीन मुख्य दृष्टिकोण हैं:

उपफोल्डर (अनुशंसित)

example.com/en/page
example.com/da/page
example.com/de/page

फायदे: एकल डोमेन प्राधिकरण, प्रबंधित करने में आसान, एक SSL प्रमाणपत्र, एक एनालिटिक्स प्रॉपर्टी, एक सर्च कंसोल प्रॉपर्टी, अधिकांश साइटों के लिए सर्वोत्तम।

नुकसान: ccTLDs के मुकाबले कम भू-लक्षित संकेत।

उपडोमेन

en.example.com/page
da.example.com/page
de.example.com/page

फायदे: क्षेत्र के अनुसार विभिन्न सर्वरों/CDNs पर होस्ट किया जा सकता है, अलग क्रॉल बजट।

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

देश-कोड TLD (ccTLD)

example.com (अंग्रेज़ी)
example.dk (डेनिश)
example.de (जर्मन)

फायदें: सबसे मजबूत भू-लक्षित संकेत, उपयोगकर्ता स्थानीय TLDs पर विश्वास करते हैं, प्रत्येक डोमेन स्वतंत्र है।

नुकसान: महंगा (20+ डोमेन खरीदना), प्रत्येक डोमेन के लिए अलग प्राधिकरण, जटिल लिंक बिल्डिंग, अलग एनालिटिक्स/कंसोल।

हमारी सिफारिश: उपफोल्डर राउटिंग 90% साइटों के लिए। यह सभी लिंक प्राधिकरण को एकल डोमेन पर संकेंद्रित करता है जबकि स्पष्ट स्थानीय संकेत प्रदान करता है। /{locale}/page प्रारूप का उपयोग करें।

https://langr.org/page        (अंग्रेज़ी, डिफ़ॉल्ट)
https://langr.org/da/page     (डेनिश)
https://langr.org/de/page     (जर्मन)
https://langr.org/ja/page     (जापानी)

क्या करें: यदि आप उपडोमेन का उपयोग कर रहे हैं और प्राधिकरण के साथ संघर्ष कर रहे हैं, तो उपफोल्डरों में माइग्रेट करने पर विचार करें। उपडोमेन से उपफोल्डरों में माइग्रेट करने वाली साइटों में आमतौर पर 3-6 महीनों में लिंक इक्विटी समेकित होने पर 20-50% ऑर्गेनिक ट्रैफ़िक में वृद्धि देखी जाती है।

3. अनुवाद गुणवत्ता बनाम मशीन अनुवाद

अनुवाद की गुणवत्ता सीधे रैंकिंग पर प्रभाव डालती है। Google मशीन अनुवाद का पता लगा सकता है और खराब अनुवादित पृष्ठों को कम मूल्यांकित कर सकता है। लेकिन 2026 में AI अनुवाद 2020 के सामान्य नियमों से नाटकीय रूप से बेहतर है।

अनुवाद गुणवत्ता स्पेक्ट्रम:

| स्तर | विधि | गुणवत्ता | लागत | सबसे अच्छा किसके लिए | |------|------|----------|-------|----------------------| | 1 | कच्चा GPT/DeepL आउटपुट | 60-75% | ~$0 | आंतरिक उपयोग, ड्राफ्ट | | 2 | AI + पोस्ट-एडिटिंग प्रॉम्प्ट्स | 75-90% | ~$0 | ब्लॉग सामग्री, गैर-चालू पृष्ठ | | 3 | AI + मानव समीक्षा | 90-97% | $0.03-0.08/शब्द | उत्पाद पृष्ठ, प्रमुख लैंडिंग पृष्ठ | | 4 | पेशेवर मूल भाषा अनुवादक | 97-100% | $0.10-0.25/शब्द | कानूनी, चिकित्सा, ब्रांड-क्रिटिकल |

2026 के लिए ключ Insight: स्तर 2 (गुणवत्ता संकेतों के साथ AI) अब अधिकांश वेब सामग्री के लिए पर्याप्त है। Google की डुप्लिकेट सामग्री एल्गोरिदम अब अच्छी गुणवत्ता वाले मशीन अनुवाद को दंडित नहीं करती — वे बुरे अनुवाद को दंडित करती हैं जो कोई मूल्य नहीं प्रदान करते।

SEO को नुकसान पहुँचाने वाले अनुवाद के संकेत:

अनूदित सामग्री के साथ मिश्रित अनुवादित खंड
UI तत्व (बटन, लेबल) अभी भी मूल भाषा में
सांस्कृतिक संदर्भ जो अनुवादित नहीं होते (अविवचन, मजेदार बातें, उदाहरण)
सभी भाषाओं में एक ही मेटा शीर्षक/विवरण

अनुवाद की गुणवत्ता को सत्यापित करने के लिए:

सुनिश्चित करें कि सभी दृश्य पाठ का अनुवाद किया गया है (जिसमें नेविगेशन, फूटर, फ़ॉर्म शामिल हैं)
क्षेत्र-विशिष्ट प्रारूप की सत्यापित करें (DD/MM/YYYY बनाम MM/DD/YYYY)
CTA का परीक्षण करें — क्या वे लक्षित भाषा में स्वाभाविक ध्वनि करते हैं?
मेटा टैग की जाँच करें — प्रत्येक भाषा के लिए शीर्षक और विवरण को स्वतंत्र रूप से लिखा जाना चाहिए
सुनिश्चित करें कि कोई कच्चे i18n कुंजी प्रकट नहीं हो रहे (जैसे, nav.home "Home" के बजाय)

क्या करें: अपने अनुवादित पृष्ठों की जाँच करें कि उनमें मिश्रित-भाषा सामग्री है। यदि किसी भी बटन, लेबल या UI तत्व अभी भी आपकी मूल भाषा में हैं, तो उन्हें तुरंत ठीक करें — मिश्रित-भाषा पृष्ठ Google को कम गुणवत्ता का संकेत देते हैं।

4. खोज कंसोल में अंतरराष्ट्रीय लक्ष्यीकरण

Google Search Console की अंतरराष्ट्रीय लक्ष्यीकरण सेटिंग्स Google को समझने में मदद करती हैं कि कौन से पृष्ठ किन देशों में रैंक करने चाहिए।

उपफोल्डर सेटअप के लिए:

आप प्रत्येक उपफोल्डर के लिए देश लक्ष्यीकरण निर्धारित नहीं कर सकते (केवल डोमेन/उपडोमेन के अनुसार)
इसके बजाय, hreflang + सामग्री भाषा + उपयोगकर्ता संकेत पर भरोसा करें
एक प्रति-स्थान साइटमैप सबमिट करें: sitemap-en.xml, sitemap-da.xml

ccTLDs के लिए:

.dk स्वचालित रूप से डेनमार्क के लिए लक्षित किया जाता है
.de स्वचालित रूप से जर्मनी के लिए लक्षित किया जाता है
कोई मैन्युअल कॉन्फ़िगरेशन की आवश्यकता नहीं है

सामान्य TLDs (.com, .org, .net) के लिए:

Search Console में प्रति प्रॉपर्टी "अंतरराष्ट्रीय लक्ष्यीकरण" सेट करें
प्राथमिक संकेत के रूप में hreflang का उपयोग करें

व्यावहारिक कदम:

अपने साइट को Search Console में सत्यापित करें (उपफोल्डर सेटअप के लिए एक प्रॉपर्टी)
hreflang टिप्पणियों के साथ अपनी साइटमैप सबमिट करें
गलतियों के लिए "अंतरराष्ट्रीय लक्ष्यीकरण" रिपोर्ट की जाँच करें
"कवरेज" रिपोर्ट पर प्रति भाषा की निगरानी करें (URL पैरामीटर फ़िल्टरिंग का उपयोग करें)
"उपयोगकर्ता द्वारा चयनित कैननिकल के बिना डुप्लीकेट" चेतावनियों की जाँच करें — ये अक्सर hreflang समस्याओं को इंगीत करते हैं

क्या करें: Search Console > प्रदर्शन > देश के द्वारा फ़िल्टर पर जाएं। देखें कि क्या जर्मनी में उपयोगकर्ता आपकी अंग्रेजी पृष्ठों पर पहुँच रहे हैं। यदि हाँ, तो आपकी hreflang कॉन्फ़िगरेशन में गलतियाँ हैं।

5. सामग्री स्थानीयकरण (केवल अनुवाद नहीं)

स्थानीयकरण शब्द-शब्द अनुवाद से परे है। यह सांस्कृतिक संदर्भ, स्थानीय खोज व्यवहार और बाजार-विशिष्ट आवश्यकताओं के अनुसार सामग्री को अनुकूलित करता है।

क्या स्थानीयकरण करें:

मुद्रा और मूल्य निर्धारण: स्थानीय मुद्रा प्रदर्शित करें (€ जर्मनी में, kr डेनमार्क में, ¥ जापान में)
तारीख/समय प्रारूप: 25/06/2026 (EU) बनाम 06/25/2026 (US) बनाम 2026/06/25 (ISO/जापान)
फोन नंबर: अंतरराष्ट्रीय के लिए स्थानीय प्रारूप के साथ देश कोड
पते: स्थानीय डाक प्रारूप के अनुसार मेल करें
सामाजिक प्रमाण: स्थानीय ग्राहक नाम, स्थानीय कंपनियाँ, स्थानीय केस स्टडी
CTA: स्वर को अनुकूलित करें (जर्मन/जापानी में औपचारिक, अंग्रेजी/डेनिश में अनौपचारिक)
छवियाँ: छवियों में टेक्स्ट स्थानीयकरण करें, सांस्कृतिक रूप से उपयुक्त दृश्य सामग्री का उपयोग करें
कानूनी: EU के लिए GDPR, प्रत्येक देश के लिए विभिन्न कुकी सहमति आवश्यकताएँ
उदाहरण: स्थानीय ब्रांड, स्थानीय वेबसाइटें, स्थानीय संदर्भ

सामग्री जो सीधे अनुवादित नहीं होनी चाहिए:

स्थानीय विषयों के बारे में ब्लॉग पोस्ट (मार्केट के अनुसार अद्वितीय लिखें)
केस स्टडी (स्थानीय व्यवसायों का उपयोग करें)
मूल्य निर्धारण पृष्ठ (बाजार के अनुसार विभिन्न मूल्य निर्धारण मान्य हैं)
समाचार सामग्री (क्षेत्रीय प्रासंगिकता भिन्न होती है)

कीवर्ड स्थानीयकरण: कीवर्ड का अनुवाद न करें — उन्हें मूल भाषा में शोध करें। अंग्रेजी में "कार बीमा" डेनिश में "bilforsikring" हो सकता है, लेकिन खोज मात्रा में आगे बढ़ने वाला शब्द सच में "forsikring bil" हो सकता है (शब्द क्रम भिन्न)। स्थानीय कीवर्ड अनुसंधान उपकरणों का उपयोग करें।

क्या करें: सभी भाषाओं में अपने मूल्य निर्धारण पृष्ठ की जांच करें। क्या यह सही स्थानीय मुद्रा दिखा रहा है? क्या आपके CTA सांस्कृतिक रूप से उपयुक्त हैं? "Get Started Free" CTA को जर्मन में "Jetzt kostenlos testen" होना चाहिए — यह एक शाब्दिक अनुवाद नहीं है, बल्कि यह वह है जो जर्मन उपयोगकर्ता देखना चाहते हैं।

6. RTL समर्थन

दाएँ से बाएँ भाषाएँ (अरबी, हिब्रू, फ़ारसी/पारसी, उर्दू, पश्तो) के लिए महत्वपूर्ण लेआउट अनुकूलन की आवश्यकता होती है। दाएँ से बाएँ सामग्री को बाएँ से दाएँ लेआउट के साथ प्रस्तुत करना आपके साइट के लिए ~500 मिलियन मूल वक्ताओं के लिए अप्रयुक्त बना देता है।

तकनीकी कार्यान्वयन:

<!-- दिशा का पता लगाएं और लागू करें -->
<html lang="ar" dir="rtl">

RTL में क्या पलटना चाहिए:

पाठ संरेखण (दाईं ओर संरेखित मुख्य पाठ)
लेआउट दिशा (साइडबार बाएँ से दाएँ स्थानांतरित होते हैं)
नेविगेशन क्रम (उलट)
दिशा के अर्थ वाले आइकन (तीर, प्रगति पट्टियाँ)
पैडिंग और मार्जिन (बाएँ/दाएँ मानों को पलटें)
बॉर्डर रेडियस (कोने के मूल्यों को पलटें)
CSS फ्लेक्सबॉक्स/ग्रिड दिशा

जो पलटना नहीं चाहिए:

फोन नंबर और गणितीय अभिव्यक्तियाँ
बाएँ से दाएँ ब्रांड नाम और लोगो
ऑडियो/वीडियो प्लेयर कंट्रोल
क्षैतिज स्क्रॉल संकेतक
एंबेडेड कोड ब्लॉक

CSS दृष्टिकोण (आधुनिक):

/* तार्किक गुणों का उपयोग करें */
.card {
  margin-inline-start: 1rem;  /* margin-left को बदलता है */
  padding-inline-end: 0.5rem; /* padding-right को बदलता है */
  border-start-start-radius: 8px; /* LTR में शीर्ष-बाएँ, RTL में शीर्ष-दाएँ */
}

RTL परीक्षण:

में dir="rtl" जोड़ें और प्रत्येक पृष्ठ की जांच करें
सुनिश्चित करें कि अरबी/हिब्रू पाठ पठनीय है (गड़बड़ Unicode नहीं)
फ़ॉर्म इनपुट का परीक्षण करें (पाठ प्रविष्टि दिशा)
जाँच करें कि संख्याएँ RTL पाठ के भीतर सही रूप से शो हो रही हैं

क्या करें: यदि आप अरबी या हिब्रू का समर्थन करते हैं, तो उन स्थानों के लिए अपने HTML तत्व में dir="rtl" जोड़ें और CSS तार्किक गुणों (margin-inline-start के बजाय margin-left) का उपयोग करें। यह एकल परिवर्तन RTL लेआउट मुद्दों के 80% को ठीक कर देता है।

7. भाषा पहचान और रूटिंग

आप यह निर्धारित करने के लिए किस भाषा संस्करण को दिखाते हैं, उपयोगकर्ता अनुभव और SEO दोनों को प्रभावित करता है।

सर्वोत्तम अभ्यास: URL-आधारित प्राथमिकता कुकी के साथ

पहली यात्रा: URL के आधार पर सामग्री दिखाएँ (जैसे, /da/page = डेनिश)
रूट URL (/): Accept-Language हैडर के आधार पर रीडायरेक्ट करें या डिफ़ॉल्ट (अंग्रेजी) दिखाएँ
हथोर बदलना: जब उपयोगकर्ता भाषा चुनता है, तो कुकी सेट करें और भविष्य की यात्राओं पर इसका सम्मान करें
कभी नहीं: एक भाषा-विशिष्ट URL से दूर रीडायरेक्ट करें

क्या से बचें:

IP-आधारित रीडायरेक्ट (Google अमेरिकी IPs से क्रॉल करता है → केवल अंग्रेजी को अनुक्रमित करता है)
केवल JavaScript भाषा पहचान (खोज इंजन JS को विश्वसनीय तरीके से निष्पादित नहीं कर सकते)
/de/page को अंग्रेजी उपयोगकर्ताओं के लिए /en/page पर रीडायरेक्ट करना (hreflang को बाधित करता है)
क्लोकिंग (उपयोगकर्ता-एजेंट के आधार पर अलग सामग्री दिखाना)

सही रीडायरेक्ट व्यवहार:

उपयोगकर्ता यात्रा: /             → 302 रीडायरेक्ट `/ {detected-locale}/`
उपयोगकर्ता यात्रा: /da/page      → डेनिश सामग्री प्रदान करें (कभी भी दूर रीडायरेक्ट न करें)
उपयोगकर्ता यात्रा: /nonexistent  → 404 (डिफ़ॉल्ट भाषा पर रीडायरेक्ट न करें)

SEO-सम्बंधित नियम: हर भाषा URL को Googlebot द्वारा बिना रीडायरेक्ट किए सीधे पहुँचा जाना चाहिए। यदि Google /da/page को क्रॉल करता है और /en/page पर रीडायरेक्ट होता है, तो यह आपकी डेनिश सामग्री को अनुक्रमित नहीं करेगा।

क्या करें: सुनिश्चित करें कि Googlebot सीधे आपकी सभी भाषा URLs पर पहुँच सकता है। Search Console में, किसी गैर-अंग्रेजी URL पर URL जाँच उपकरण का उपयोग करें। यदि यह रीडायरेक्ट दिखाता है, तो अपनी रूटिंग लॉजिक को ठीक करें।

8. भाषाओं के बीच डुप्लिकेट सामग्री

बहु-भाषा साइटों को अनोखे डुप्लिकेट सामग्री चुनौती का सामना करना पड़ता है: विभिन्न भाषाओं में समान पृष्ठ एक दूसरे के साथ खोज परिणामों में प्रतिस्पर्धा कर सकते हैं।

जब डुप्लिकेट सामग्री समस्या बन जाती है:

जब पृष्ठ 90%+ समान होते हैं (अनूदित सामग्री नहीं)
वही URL दोनों संस्करणों के साथ पहुंच योग्य (जैसे /page और /en/page)
कैननिकल टैग गायब होना दोनों संस्करणों को अनुक्रमित करने की अनुमति देता है
Hreflang त्रुटियाँ Google को "गलत" संस्करण चुनने का कारण बनती हैं

समाधान:

| समस्या | समाधान | |---------|----------| | अनुवादित पृष्ठ | अनुवादित होने तक noindex का उपयोग करें, या स्पष्ट भाषा संकेतक के साथ अंग्रेजी दिखाएँ | | डबल URLs (/page + /en/page) | 301 रीडायरेक्ट एक को दूसरे पर | | Google गलत भाषा इंडेक्स कर रहा है | hreflang पारस्परिकता को ठीक करें, Search Console में सत्यापित करें | | निम्न गुणवत्ता वाले अनुवाद अनुक्रमित | अनुवाद की गुणवत्ता में सुधार करें या कम भाषाओं में समेकित करें |

कैननिकल टैग रणनीति:

<!-- प्रत्येक भाषा पृष्ठ का अपना कैननिकल होता है -->
<!-- /en/page -->
<link rel="canonical" href="https://example.com/en/page" />

<!-- /da/page -->
<link rel="canonical" href="https://example.com/da/page" />

कभी भी एक भाषा से दूसरी भाषा के लिए कैननिकल न बढ़ाएँ (जैसे, डेनिश कैननिकल इंग्लिश में इशारा करना) — यह Google को पूरी तरह से डेनिश संस्करण को अनदेखा करने के लिए बताता है।

क्या करें: Google में site:yourdomain.com "your page title" खोजें। यदि आप एक ही क्वेरी के लिए अंग्रेजी और अनूदित दोनों संस्करण देखते हैं, तो आपके पास डुप्लिकेट सामग्री या hreflang समस्या है।

बहु-भाषा SEO चेकलिस्ट

हर अंतरराष्ट्रीय साइट के लिए इस पर चलें:

[ ] सभी पृष्ठों पर hreflang टैग, स्वयं-उल्लेखित और x-default को शामिल करते हुए
[ ] सभी hreflang संबंध पारस्परिक हैं (क्रॉलर द्वारा जांजें)
[ ] सही स्थानीय राउटिंग (उपफोल्डर अनुशंसित): /{locale}/page
[ ] भाषा-विशिष्ट URLs से स्वचालित रीडायरेक्ट नहीं
[ ] अनुवाद की गुणवत्ता मान्य की गई (कोई मिश्रित-भाषा पृष्ठ नहीं)
[ ] मेटा शीर्षक और विवरण प्रत्येक भाषा के लिए अद्वितीय (नहीं दोहराए गए)
[ ] मुद्रा, तिथियाँ, और प्रारूप स्थानीयकृत किए गए
[ ] अरबी/हिब्रू/फ़ारसी के लिए RTL समर्थन लागू किया गया (यदि लागू हो)
[ ] प्रत्येक स्थान के लिए साइटमैप को Search Console में सबमिट किया गया
[ ] प्रत्येक भाषा पृष्ठ का अपना कैननिकल URL है (किसी अन्य भाषा की ओर इशारा नहीं कर रहा)
[ ] किसी भी पृष्ठ पर कोई कच्ची i18n कुंजी दृष्टिगोचर नहीं
[ ] सभी पृष्ठों पर भाषा स्विचर सुलभ (समान पृष्ठों से लिंक रहित, होमपेज नहीं)

LANGR बहु-भाषा SEO की जांच कैसे करता है

LANGR के पास बहु-भाषा SEO के लिए दो समर्पित मॉड्यूल हैं:

i18n-checker: आपके पृष्ठ के 5 स्थानीय संस्करणों तक क्रॉल करता है और जाँचता है:

Hreflang टैग की पूर्णता और पारस्परिकता
अनुपलब्ध स्थानीय URL (404 या रीडायरेक्ट लौटाना)
स्थानीयताओं के बीच हार्डकोडेड/अनुवादित स्ट्रिंग्स (फॉलबैक पहचान)
दृश्य टेक्स्ट के रूप में उजागर कच्चे i18n कुंजी
अनुवाद कवरेज प्रतिशत

अनुवाद स्कैनर: AI-संचालित गुणवत्ता मूल्यांकन:

0-100 पैमाने पर अनुवाद की प्राकृतता का मूल्यांकन करता है
मशीन अनुवाद के अवशेषों का पता लगाता है
अन्यथा अनुवादित पृष्ठों में अनुवादित खंड की पहचान करता है
UI तत्वों (बटन, लेबल, नेविगेशन) को मुख्य सामग्री से अलग जाँचता है

इन मॉड्यूलों का संयोजन आपके बहु-भाषा कार्यान्वयन की तकनीकी (hreflang, रूटिंग, कैननिकल) और गुणवत्ता (अनुवाद, स्थानीयकरण) दृष्टिकोण से जांच करता है — LANGR के 13 SEO अनुशासन में से दो।

सामान्य बहु-भाषा गलतियाँ (प्रभाव के आधार पर क्रमित)

गैर-पारस्परिक hreflang — Google पूरी सेटअप की अनदेखी करता है
IP के आधार पर स्वचालित-रीडायरेक्टिंग — गैर-अंग्रेजी संस्करणों को अनुक्रमित करने से Googlebot को रोकता है
भाषाओं में एक ही मेटा टैग — अनुवादित पृष्ठों की रैंकिंग क्षमता को बर्बाद करते हैं
मिश्रित-भाषा पृष्ठ — अंग्रेजी में बटन, जर्मन में सामग्री = कम गुणवत्ता संकेत
कोई x-default नहीं — Google आपकी फॉलबैक संस्करण निर्धारित नहीं कर सकता
URLs का शाब्दिक अनुवाद करना — /about-us → /uber-uns ठीक है, लेकिन इसे संगत रखना चाहिए
RTL की अनदेखी — 500M+ मूल वक्ताओं के लिए टूटे हुए लेआउट
कैननिकल का कोई अन्य भाषा की ओर इशारा करना — Google के सूचकांक में अनुवादित संस्करण को मार डालता है

आगे क्या?

चरण 11: B2B लीड डिस्कवरी — ऑटोमेटेड प्रॉस्पेक्टिंग, डोमेन-आधारित लीड स्कोरिंग, और SEO निष्कर्ष के आधार पर आउटरीच के साथ SEO डेटा को योग्य लीड में बदलना।

यह गाइड LANGR की 13-चरणीय SEO श्रृंखला का हिस्सा है। एक मुफ्त ऑडिट करें ताकि आप देख सकें कि आपकी साइट सभी 13 अनुशासनों में कहाँ खड़ी है।

SEO गाइड चरण 10: बहु-भाषा SEO — अपने रैंकिंग को कमजोर किए बिना वैश्विक दर्शकों तक पहुँच