2021 में एक क्लाइंट मेरे पास एक WordPress ई-कॉमर्स साइट लेकर आया जो सात देशों को टार्गेट कर रहा था। उन्होंने एक ट्रांसलेशन एजेंसी को काम दिया था, सब कुछ WPML में डाला था, और कहा था कि काम हो गया। उन सात मार्केटों में से पाँच में ऑर्गेनिक ट्रैफिक असल में शून्य था। कम नहीं। शून्य। जर्मन पेज अंग्रेज़ी वाले को खा रहे थे। अरबी पेजों पर कहीं भी dir="rtl" एट्रिब्यूट नहीं था। और hreflang टैग? ऐसे URLs की ओर इशारा कर रहे थे जो पूरी तरह अलग पेजों पर 301-रीडायरेक्ट कर रहे थे।
यह तीन महीने की रिकवरी जॉब थी। मैंने ठीक-ठाक बिल किया, लेकिन तब से मैं इसके बारे में सोचता आ रहा हूँ, क्योंकि उस साइट पर हर एक समस्या लॉन्च से पहले एक अच्छी चेकलिस्ट चलाने से रोकी जा सकती थी।
तो यह रहा मेरा। वह सटीक क्रम जिसमें मैं इस पर काम करता हूँ, जो टूल्स मैं असल में खोलता हूँ, और वह चीज़ें जो अभी भी अनुभवी डेवलपर्स को पकड़ती हैं।
---
URL संरचना के साथ शुरू करें (कुछ भी और करने से पहले)
यह निर्णय स्थायी है। या कम से कम इतना स्थायी है कि आपको इसे ऐसे ही मानना चाहिए। मैंने देखा है कि एजेंसियां लाइव मल्टीलिंगुअल साइटों पर URL संरचना बदलती हैं और छह महीने की लिंक इक्विटी गायब हो जाती है।
आपके पास तीन विकल्प हैं: सबडायरेक्टरीज़ (/fr/), सबडोमेन (fr.), या ccTLD (site.fr)। अंतर्राष्ट्रीय टार्गेटिंग पर Google का अपना डॉक्यूमेंटेशन बिल्कुल स्पष्ट है कि तीनों काम करते हैं, लेकिन ट्रेड-ऑफ असली हैं।
अपने अधिकांश क्लाइंटों के लिए, मैं सबडायरेक्टरीज़ जाता हूं। एक डोमेन, अथॉरिटी का एक पूल, प्रबंधित करने के लिए एक क्रॉल बजट। सबडोमेन तब समझ आते हैं जब आपके पास वास्तव में अलग-अलग टीमें हों जो अलग-अलग ऑपरेशन चला रही हों (Seahawk के पास एक बार एक SaaS क्लाइंट था जहां US और EU प्रोडक्ट्स वास्तव में अलग-अलग नियामक प्रोडक्ट्स थे, सबडोमेन वहां सही थे)। ccTLD उन एंटरप्राइज़ के लिए हैं जिनके पास गंभीर स्थानीय ब्रांड मौजूदगी है और प्रत्येक के लिए अलग से डोमेन अथॉरिटी बनाने का बजट है।
एक चुनिए। इसे दस्तावेज़ित करिए। कोई भी एक पंक्ति टेम्पलेट कोड लिखने से पहले अनुमोदन लीजिए।
वह एक सबफ़ोल्डर गलती जो मैं बार-बार देख रहा हूं
लोग डिफॉल्ट भाषा को /en/ के अंतर्गत नेस्ट करते हैं बिना रूट से उचित रीडायरेक्ट सेट किए। तो site.com/ एक 200 रिटर्न करता है hreflang के बिना, site.com/en/ में सभी कंटेंट है, और Google दोनों को अलग-अलग थिन पेजेस के रूप में इंडेक्स करता है। अपने रूट को Accept-Language के आधार पर उचित लोकेल में रीडायरेक्ट करने के लिए सेट करिए, या बस रूट को डिफॉल्ट लोकेल सीधे सर्व करने दीजिए। इसे लटकता हुआ न छोड़िए।
---
Hreflang: इसे सही करिए या बिल्कुल न करिए
Hreflang वह हिस्सा है जो अधिकांश डेवलपर्स को घबराता है। बिल्कुल सही है। यह नाज़ुक है।
Google के hreflang स्पेक आपको भाषा-क्षेत्र कोड (en-GB, fr-FR) का उपयोग करने, टैग्स को आत्म-संदर्भात्मक बनाने (हर पेज खुद को संदर्भित करता है), और संबंध को द्विदिशात्मक बनाने (अगर /fr/ /en/ को इंगित करता है, तो /en/ को वापस /fr/ को इंगित करना चाहिए) के लिए कहता है। इनमें से कोई भी याद करिए और पूरी चीज़ चुप-चाप टूट जाती है। Google मैनुअल एक्शन नहीं फेंकेगा। यह सिर्फ आपके टैग्स को नज़रअंदाज़ करता है और अनुमान लगाता है।
यहाँ मेरा असली वर्कफ़्लो है:
- पहले एक स्प्रेडशीट में पूरा URL मैट्रिक्स बनाएँ। हर लोकेल, हर समकक्ष पेज URL।
- जहाँ संभव हो
<head>के ज़रिए लागू करें, साइटमैप्स के बजाय। साइटमैप्स काम करते हैं, लेकिन<head>लागू करना सोर्स देखकर ऑडिट करना आसान है। - hreflang ऑडिटिंग सक्षम करके स्टेजिंग साइट पर Screaming Frog चलाएँ। इश्यूज़ रिपोर्ट एक्सपोर्ट करें।
- Ahrefs के साइट ऑडिट से क्रॉस-चेक करें कि कोई अनाथ लोकेल पेज तो नहीं हैं (एक भाषा में पेज हैं लेकिन दूसरी भाषाओं में समकक्षों की ओर कोई hreflang नहीं)।
- 10-15 पेजों को मैनुअली स्पॉट-चेक करें। बस सोर्स देखें। पैटर्न को देखें।
एक चीज़ जो लोग लगातार गलत करते हैं: x-default। यह "अंग्रेज़ी संस्करण" नहीं है। यह उन यूज़रों के लिए फॉलबैक है जिनकी भाषा आपकी किसी भी लोकेल टैग से मेल नहीं खाती। अगर आप en-GB और en-US को खासतौर पर टार्गेट कर रहे हैं, तो एक कनाडाई अंग्रेज़ी बोलने वाले को कहीं लैंड करना चाहिए। वह है x-default। इसे अपने सबसे प्रासंगिक कैच-ऑल पेज की ओर इशारा करें, आमतौर पर रूट या एक लैंग्वेज-सिलेक्टर पेज।
---
क्रॉल बजट और इंडेक्सेशन
छोटी साइटों पर इससे ज़्यादा फ़र्क़ नहीं पड़ता। 8 भाषाओं में 50,000 पेजों वाली साइट पर, यह बिल्कुल मायने रखता है।
गणित सरल है: अगर आपकी English साइट में 6,000 पेज हैं और आप 7 भाषाएँ जोड़ते हैं, तो संभावित रूप से आपके पास 48,000 पेज हो सकते हैं जिन सभी को क्रॉल और इंडेक्स करने की जरूरत है। अधिकांश साइटों के पास इसे कुशलतापूर्वक सपोर्ट करने के लिए न तो आवश्यक authority होती है और न ही आंतरिक लिंक संरचना होती है।
मैं क्या करता हूँ:
- यह audit करना कि कौन से पेज वास्तव में translation के लायक हैं। सब कुछ नहीं होता। 2017 के ब्लॉग पोस्ट जिन्हें English में महीने में 3 विजिट मिलते हैं, उन्हें French संस्करण की जरूरत नहीं है।
- अलग-अलग locale-specific सितेमैप (sitemap-fr.xml, sitemap-de.xml) का उपयोग करें और उन सभी को
sitemap-index.xmlसे reference करें। Google Search Console आपको हर एक को अलग से submit और monitor करने देता है, जिससे debug करना कहीं ज्यादा आसान है। - अगर आप subdomains या ccTLDs पर हैं तो Search Console में प्रति property crawl stats check करें। एक domain पर subdirectories के लिए, URL path द्वारा फ़िल्टर किए गए coverage report का उपयोग करें।
- उन thin या machine-translated पेजों को noindex करें जिन्हें आपने अभी तक review नहीं किया है। गंभीरता से। एक पेज जिसे Google spam-quality content के रूप में index करता है, पूरे domain को नुकसान पहुँचाता है।
2019 में travel sector के एक क्लाइंट ने 12 language versions के साथ live push किया था, सभी DeepL द्वारा machine-translated थे बिना किसी human review के। English में solid traffic था, लेकिन 8 हफ्तों में हर दूसरी भाषा में बर्बाद हो गई। DeepL एक बेहतरीन टूल है (मैं अभी भी इसे first draft के रूप में उपयोग करता हूँ) लेकिन unreviewed output at scale एक trust signal nightmare है।
---
अनुवाद बनाम Transcreation
यह अंतर अधिकांश technical SEO professionals जितना स्वीकार करते हैं उससे कहीं अधिक मायने रखता है।
अनुवाद शब्दों को बदलना है। ट्रांसक्रिएशन इरादे, टोन और सांस्कृतिक संदर्भ को बदलना है। लैंडिंग पेजों, प्रोडक्ट डिस्क्रिप्शन और किसी भी चीज़ के लिए जिसमें आप रैंक करने के लिए पैसा खर्च कर रहे हैं, आप ट्रांसक्रिएशन चाहते हैं।
यहाँ व्यावहारिक चेकलिस्ट आइटम है: प्रत्येक टार्गेट मार्केट के लिए, ट्रैफिक पोटेंशियल द्वारा कम से कम शीर्ष 20 पेजों की एक नेटिव स्पीकर द्वारा समीक्षा करवाएँ। केवल व्याकरण के लिए नहीं। इसके लिए कि क्या कॉपी उस भाषा में एक असली इंसान की तरह लगता है या एक मशीन की तरह जिसने भाषा को मैनुअल से सीखा हो।
कीवर्ड रिसर्च प्रत्येक लोकेल के लिए अलग है। मैं इसके लिए Ahrefs का उपयोग करता हूँ। किसी अवधारणा के लिए जर्मन कीवर्ड केवल अंग्रेजी कीवर्ड का जर्मन शब्द नहीं है। सर्च बिहेवियर अलग है। कुछ मार्केटों में, यूजर्स अधिक औपचारिक रूप से सर्च करते हैं। दूसरों में, वे संक्षिप्त शब्द या स्लैंग का उपयोग करते हैं जो सीधे अनुवाद में कभी प्रकट नहीं होते। लोकेल-विशिष्ट कीवर्ड मैप्स बनाएँ। इसमें अधिक समय लगता है। यह इसके लायक है।
वे मार्केट्स जिन्हें आप सही तरीके से ट्रांसक्रिएट नहीं कर सकते उनके साथ क्या करें
अपने साथ ईमानदारी से रहें। अगर आप अभी जर्मन को सही तरीके से नहीं कर सकते, तो जर्मन लॉन्च मत करें। एक औसत दर्जे की बहुभाषी मौजूदगी कोई बहुभाषी मौजूदगी नहीं होने से भी बदतर है। गूगलबॉट आपको कोशिश करने का श्रेय नहीं देता।
---
प्रत्येक लोकेल के लिए तकनीकी ऑन-पेज चेक्स
यह सुस्पष्ट हिस्सा है। लेकिन यह वह जगह है जहाँ जीत होती है।
- `<html>` एलिमेंट पर `lang` एट्रिब्यूट। पेज के लोकेल से मेल खाना चाहिए।
<html lang="fr-FR">। हर टेम्प्लेट को चेक करें, केवल होमपेज नहीं। - RTL भाषाओं के लिए `dir` एट्रिब्यूट। अरबी, हिब्रू, उर्दू, फारसी:
<html dir="rtl">। और जाँचें कि आपका CSS वास्तव में इसे सपोर्ट करता है, केवल HTML एट्रिब्यूट नहीं। - कैनोनिकल टैग। प्रत्येक स्थानीयकृत पृष्ठ को स्वयं को कैनोनिकलाइज करना चाहिए। फ़्रेंच पृष्ठ स्वयं को कैनोनिकलाइज करता है, अंग्रेजी समकक्ष को नहीं। मैंने इसे गलत होते हुए गिनती से अधिक बार देखा है।
- मेटा शीर्षक और विवरण। प्रत्येक स्थान के अनुसार अनुवादित और अनुकूलित। अंग्रेजी में नहीं छोड़े गए। किसी टेम्पलेट से
[Page Name] | [Site Name]के साथ और मशीन-अनुवादित टैगलाइन से ऑटो-जनरेट नहीं किए गए। - संरचित डेटा। यदि आप Schema.org मार्कअप का उपयोग कर रहे हैं, तो
inLanguageप्रॉपर्टी पृष्ठ की भाषा को प्रतिबिंबित करनी चाहिए। ई-कॉमर्स के लिए, जाँचें किpriceCurrencyस्थान की अपेक्षित मुद्रा से मेल खाता है। - इमेज alt टेक्स्ट। अनुवादित। अक्सर नजरअंदाज किया जाता है क्योंकि यह दृश्यमान नहीं है। हमेशा जाँचा जाता है।
मैं इन सभी को कॉलम हेडर के रूप में एक साधारण Google Sheet का उपयोग करता हूँ। प्रत्येक स्थान के लिए एक पंक्ति। सत्यापित होने पर टिक करें। इसे क्लाइंट के साथ साझा करें ताकि वे समझ सकें कि क्या जाँचा गया था।
---
स्थानीय खोज और Google Business Profile
जिन क्लाइंट के बाजारों में भौतिक स्थान हैं, उनके लिए बहुभाषी SEO वेबसाइट पर नहीं रुकता।
Google Business Profile व्यावसायिक विवरण और सेवा सूचियों के लिए कई भाषाओं का समर्थन करता है। प्रत्येक स्थान के लिए प्राथमिक भाषा सही तरीके से सेट करें। यदि आपके पास पेरिस में एक कार्यालय है, तो उस स्थान के लिए GBP फ्रेंच में होना चाहिए, फ्रेंच-भाषा विवरण के साथ, अंग्रेजी HQ प्रोफ़ाइल से शब्दशः कॉपी नहीं किया गया।
NAP स्थिरता (नाम, पता, फोन) स्थानीय उद्धरण निर्देशिकाओं में बाजार के अनुसार महत्वपूर्ण है। जर्मनी में इसका मतलब है कि Das Örtliche और Gelbe Seiten पर सूचीबद्धि सही है, केवल Google पर नहीं। फ्रांस में, PagesJaunes। प्रत्येक बाजार का अपना उद्धरण पारिस्थितिकतंत्र है। लक्ष्य देश प्रति शीर्ष 10 उद्धरण स्रोतों को मैप करने के लिए एक दोपहर बिताना समय की बर्बादी नहीं है।
---
लॉन्च के बाद की निगरानी
लॉन्च अंत नहीं है। यह पता लगाने की शुरुआत है कि आपने क्या छोड़ा।
बहुभाषी साइटों के लिए मेरी पोस्ट-लॉन्च निगरानी सेटअप:
- Google Search Console को प्रत्येक लोकेल के लिए अलग से सेट करें (सबडोमेन या ccTLD) या सबडायरेक्टरी पाथ के लिए URL प्रीफिक्स प्रॉपर्टी का उपयोग करें।
- Search Console में "Legacy tools" के अंतर्गत International Targeting रिपोर्ट देखें। यह लॉन्च के कुछ हफ्तों के भीतर hreflang त्रुटियों को सामने लाएगी।
- Ahrefs में प्रत्येक लोकेल के लिए रैंक ट्रैकिंग सेट करें, सही देश/भाषा टार्गेटिंग का उपयोग करते हुए। "English, US" में ट्रैक किया गया एक कीवर्ड आपको उसी कीवर्ड के लिए अलग पोजीशन देगा जब इसे "German, Germany" में ट्रैक किया जाए।
- पहले 6 महीनों के लिए मासिक रूप से क्रॉल कवरेज की निगरानी करें। नए लोकेल पेज कभी-कभी "Discovered, not indexed" में हफ्तों तक फंसे रहते हैं। आमतौर पर यह क्रॉल बजट या आंतरिक लिंकिंग समस्या होती है।
- त्रैमासिक आधार पर कैनिबलाइजेशन की जांच करें। दो लोकेल पेज एक ही देश में एक ही क्वेरी के लिए प्रतिस्पर्धा कर रहे हैं यह संकेत है कि URL या hreflang सेटअप में कुछ गलत हुआ है।
एक fintech क्लायंट के साथ एक दर्दनाक अनुभव के बाद मैंने अपनी चेकलिस्ट में एक चीज जोड़ी: जांचें कि IP-आधारित रीडायरेक्ट hreflang को ओवरराइड नहीं कर रहे हैं। यदि आपका CDN या सर्वर IP जिओलोकेशन के आधार पर उपयोगकर्ताओं को रीडायरेक्ट कर रहा है, तो Googlebot (जो आमतौर पर US IPs से क्रॉल करता है) आपके गैर-अंग्रेजी पेजों को कभी नहीं देख सकता। उस fintech क्लायंट के पास CloudFront नियम थे जो गैर-US IPs को आक्रामक तरीके से रीडायरेक्ट कर रहे थे। यूरोपीय पेजों में शून्य इंडेक्सेशन क्यों था यह पता लगाने में हमें दो सप्ताह लगे।
---
सवाल-जवाब
क्या मुझे हर भाषा के लिए अलग Google Search Console संपत्ति की जरूरत है?
जरूरी नहीं। अगर आप एक डोमेन पर सबडायरेक्टरी का उपयोग कर रहे हैं (जैसे site.com/fr/), तो आप हर सबडायरेक्टरी के लिए URL-prefix संपत्ति का उपयोग कर सकते हैं, या सिर्फ रूट डोमेन संपत्ति का उपयोग करें और URL पाथ से फिल्टर करें। अगर आप सबडोमेन या अलग ccTLD पर हैं, तो अलग संपत्तियां प्रशासनिक ओवरहेड के लायक हैं क्योंकि आपको हर बाजार के लिए स्वच्छ डेटा मिलता है।
क्या 2024 में SEO के लिए मशीन अनुवाद काफी अच्छा है?
पहले ड्राफ्ट के लिए हां। मानव समीक्षा के बिना प्रकाशित करने के लिए, नहीं। DeepL और Google Translate काफी अच्छे हो गए हैं, लेकिन वे ऐसी सामग्री बनाते हैं जो व्याकरणिक रूप से सही है और स्वरिक रूप से सपाट है। सर्च इंजन अब उस सामग्री को अलग करने में तेजी से अच्छे हो रहे हैं जो किसी भाषा में स्वाभाविक रूप से पढ़ी जाती है और उस सामग्री से जिसका अनुवाद किया गया है। तेजी से आगे बढ़ने के लिए मशीन अनुवाद का उपयोग करें, फिर इंडेक्सिंग से पहले उच्च-मूल्य वाले पृष्ठों की समीक्षा करने के लिए एक मूल बोलने वाले को प्राप्त करें।
मैं एक बाजार को कैसे संभालूं जहां मेरे पास केवल आंशिक अनुवाद कवरेज है?
जब तक अनुवादित या आंशिक रूप से अनुवादित पृष्ठ तैयार न हों, तब तक उन्हें noindex करें। आधे-अधूरे locale पृष्ठों को सिर्फ इसलिए प्रकाशित न करें क्योंकि वे लाइव हैं। किसी भाषा में थिन सामग्री से विश्वास संकेतों को नुकसान लॉन्च में देरी से उलटना कठिन है।
सबसे आम hreflang गलती कौन सी है?
self-referential टैग का अभाव। हर पृष्ठ को अपने सभी समकक्षों की ओर इशारा करने के अलावा अपने आप में इशारा करने वाला hreflang टैग की जरूरत है। डेवलपर्स अक्सर cross-references को सही तरीके से लागू करते हैं और self-reference को भूल जाते हैं। Screaming Frog इसे लगभग 30 सेकंड में पकड़ लेगा, हर लॉन्च से पहले इसे चलाएं।
क्या मुझे URLs का अनुवाद करना चाहिए या उन्हें अंग्रेजी में रखना चाहिए?
उन्हें अनुवाद करें। /fr/chaussures/ फ्रेंच सर्च में /fr/shoes/ से बेहतर प्रदर्शन करता है क्योंकि slug प्रासंगिकता संकेतों में योगदान देता है। यह फ्रेंच भाषी उपयोगकर्ताओं को भी अधिक विश्वसनीय दिखता है। अतिरिक्त कार्यान्वयन प्रयास (आपको अपने CMS में locale-विशिष्ट राउटिंग और slug अनुवाद की आवश्यकता है) किसी भी बाजार के लिए इसके लायक है जिसे आप गंभीरता से लक्षित कर रहे हों।
---
Multilingual SEO कोई ऐसी चीज़ नहीं है जिसे आप एक बार टिक करके भूल जाएं। यह एक अनुशासन है। ऊपर दी गई checklist ने मुझे महंगे post-launch firefighting से कई बार बचाया है, जितना मैं स्वीकार करना चाहूँ, और यह अभी भी विकसित हो रही है। हर नया build मुझे कुछ सिखाता है। सबसे हाल ही में: हमेशा देखें कि CDN non-default-locale अनुरोधों के साथ क्या कर रहा है, इससे पहले कि आप किसी साइट को तैयार घोषित करें। हमेशा।