Skip to main content
Back to blog

SEO گائیڈ مرحلہ 10: کثیر زبان SEO — عالمی سامعین تک پہنچنا بغیر رینکنگ کو کمزور کیے

·18 min read·by LANGR SEO

SEO گائیڈ مرحلہ 10: کثیر زبان SEO

یہ 13 مرحلوں کی SEO گائیڈ کا مرحلہ 10 ہے۔ کثیر زبان SEO آپ کو اپنے نامیاتی ٹریفک میں اضافہ کرنے کی اجازت دیتا ہے، ہر مارکیٹ کو ان کی اپنی زبان میں خدمات پیش کرتا ہے — اگر غلط کیا جائے تو یہ مواد کے دوہرے پن کا سبب بنتا ہے۔


آپ جتنی زیادہ زبانیں شامل کرتے ہیں، اتنا ہی آپ کے موجودہ مواد پر ملنے والا ضرب بڑھتا ہے۔ ایک زبان میں 50 صفحات والا سائٹ کے پاس 50 انڈیکس ایبل URLs ہوتے ہیں۔ 5 زبانیں شامل کریں اور آپ کے پاس 250 ہوں گے۔ 20 زبانیں شامل کریں تو آپ کے پاس 1,000 ہو جائیں گے۔ ان میں سے ہر ایک URL اپنے مقامی گوگل نتائج میں علیحدہ علیحدہ رینک کر سکتا ہے۔

لیکن کثیر زبان SEO SEO کے تکنیکی طور پر سب سے زیادہ پیچیدہ شعبوں میں سے ایک ہے۔ غلط عملی جامہ دوہرے مواد، رینکنگ میں کمزوری، اور کرال بجٹ کے ضیاع کا باعث بنتا ہے۔ صحیح اور غلط طریقے سے بین الاقوامی بنایا گیا سائٹ میں 10 گنا ٹریفک کا فرق ہو سکتا ہے۔

LANGR خود 89 فعال مقامات پر 108 زبانوں میں کام کرتا ہے — ہم نے ان مسائل کو بڑے پیمانے پر حل کیا ہے۔ یہ گائیڈ وہ سب کچھ شیئر کرتا ہے جو ہم نے سیکھا ہے۔

کثیر زبان SEO کے دائرہ

کثیر زبان SEO 8 اہم شعبوں کا احاطہ کرتا ہے:

  1. Hreflang عملی جامہ — گوگل کو بتانا کہ کون سا پیج کون سی زبان پیش کرتا ہے
  2. لوکیل روٹنگ کی حکمت عملی — ذیلی ڈومین بمقابلہ ذیلی فولڈر بمقابلہ TLD
  3. ترجمے کا معیار — مشینی بمقابلہ انسانی بمقابلہ ہیبریڈ ترجمہ
  4. بین الاقوامی ہدف — تلاش کنسول کی تشکیل
  5. مواد کی مقامی نوعیت — صرف ترجمے سے آگے: ثقافتی ایڈاپٹیشن
  6. RTL سپورٹ — دائیں سے بائیں کی زبانیں (عربی، عبرانی، فارسی)
  7. زبان کی تشخیص — خودکار طریقے سے صحیح ورژن فراہم کرنا
  8. دوہرے مواد کی روک تھام — زبانوں کے درمیان متصادم ہونے سے بچنا

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 اندراجات (کارکردگی کی حد)

تین جگہوں کے اختیارات:

| طریقہ | بہترین کے لیے | نقصانات | |-------|---------------|----------| | in | چھوٹے سائٹس (< 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 ٹیگ برآمد کریں۔ غیر باہمی تعلقات کے لیے چیک کریں — یہ سب سے عام غلطی ہے اور گوگل کو آپ کے مکمل hreflang سیٹ اپ کو نظر انداز کرنے پر مجبور کرتی ہے۔

2. لوکیل روٹنگ کی حکمت عملی

آپ مختلف زبانوں کے لیے URLs کو کس طرح تشکیل دیتے ہیں، یہ 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. ترجمے کا معیار بمقابلہ مشینی ترجمہ

ترجمے کا معیار براہ راست رینکنگ پر اثر انداز ہوتا ہے۔ گوگل مشینی ترجمہ کو شناخت کر سکتا ہے اور خراب ترجمہ شدہ صفحات کی قیمت کم کر سکتا ہے۔ لیکن 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 کے لیے اہم بصیرت: سطح 2 (معیاری پرامپٹس کے ساتھ AI) اب زیادہ تر ویب مواد کے لیے کافی ہے۔ گوگل کے دوہرے مواد کے الگورڈمز اب اچھے مشینی ترجمے کو سزا نہیں دیتے — وہ خراب ترجمے کی سزا دیتے ہیں جو کوئی قدر فراہم نہیں کرتا۔

ایسے ترجمے کی علامات جو SEO کو نقصان پہنچاتی ہیں:

  • ترجمہ شدہ مواد کے ساتھ غیر ترجمہ شدہ حصے
  • UI عناصر (بٹن، لیبل) اب بھی ماخذ زبان میں
  • مقامی شکل کی ترتیب میں تبدیلی نہیں کی گئی (تاریخ، کرنسیاں، فون نمبر)
  • ثقافتی حوالہ جات جو ترجمہ نہیں ہوتے (محاورے، مذاق، مثالیں)
  • تمام زبانوں میں ایک ہی میٹا عنوان/تفصیل

ترجمے کے معیار کی تصدیق کیسے کریں:

  1. چیک کریں کہ تمام دکھائی دینے والا مواد ترجمہ کیا گیا ہے (نیویگیشن، فوٹر، فارم شامل ہیں)
  2. مقامی شکل کی ترتیب کی تصدیق کریں (DD/MM/YYYY بمقابلہ MM/DD/YYYY)
  3. CTAs کو جانچیں — کیا وہ ہدف زبان میں قدرتی لگتے ہیں؟
  4. میٹا ٹیگ چیک کریں — عنوان اور تفصیل ہر زبان کے لیے علیحدہ لکھے جانے چاہئیں
  5. یہ تصدیق کریں کہ کوئی خام i18n کلیدیں ظاہر نہیں ہو رہی ہیں (جیسے، nav.home بجائے "Home")

فوری فائدہ: اپنے ترجمہ شدہ صفحات کو مخلوط زبان کے مواد کے لیے چیک کریں۔ اگر کوئی بٹن، لیبل، یا UI عناصر ابھی بھی ماخذ زبان میں ہیں تو انہیں فوری طور پر ٹھیک کریں — مخلوط زبان کی صفحات گوگل کے لیے کم معیار کا اشارہ دیتے ہیں۔

4. تلاش کنسول میں بین الاقوامی ہدف بندی

گوگل سرچ کنسول کی بین الاقوامی ہدف بندی کی ترتیبات گوگل کو سمجھنے میں مدد کرتی ہیں کہ کون سے صفحات کون سے ممالک میں رینک ہونا چاہئیں۔

ذیلی فولڈر سیٹ اپ کے لیے:

  • آپ ہر ذیلی فولڈر کے لیے ملک کی ہدف کو ترتیب نہیں دے سکتے (صرف ڈومین/ذیلی ڈومین کے لیے)
  • اس کے بجائے، hreflang + مواد کی زبان + صارف کے اشارے پر انحصار کریں
  • ہر لوکیل کے لیے سائٹ میپ جمع کریں: sitemap-en.xml, sitemap-da.xml

ccTLDs کے لیے:

  • .dk خودبخود ڈنمارک کے لیے ہدف بنایا جاتا ہے
  • .de خودبخود جرمنی کے لیے ہدف بنایا جاتا ہے
  • کوئی دستی ترتیب کی ضرورت نہیں

جنرک TLDs (.com, .org, .net) کے لیے:

  • تلاش کنسول میں ہر پراپرٹی کے لیے "بین الاقوامی ہدف بندی" مرتب کریں
  • بنیادی اشارے کے طور پر hreflang کا استعمال کریں

عملی اقدامات:

  1. تلاش کنسول میں اپنے سائٹ کی تصدیق کریں (ذیلی فولڈر سیٹ اپ کے لیے ایک پراپرٹی)
  2. اپنا سائٹ میپ hreflang تشریح کے ساتھ جمع کریں
  3. "بین الاقوامی ہدف بندی" رپورٹ میں غلطیوں کی جانچ کریں
  4. "کوریج" رپورٹ کی نگرانی کریں ہر زبان کے لیے (URL پیرامیٹر کی فلٹرنگ کا استعمال کریں)
  5. "جو صارف کے منتخب کردہ کینونک کے بغیر دوہرے" کی انتباہات کی جانچ کریں — یہ اکثر hreflang مسائل کی نشاندہی کرتے ہیں

فوری فائدہ: سرچ کنسول > پرفارمنس > ملک کے لحاظ سے فلٹر پر جائیں۔ چیک کریں کہ آیا جرمنی کے صارفین آپ کے انگریزی صفحات پر پہنچ رہے ہیں بجائے جرمن کے۔ اگر ہاں، تو آپ کی hreflang تشکیل میں غلطیاں ہیں۔

5. مواد کی مقامی نوعیت (صرف ترجمے کی ضرورت نہیں)

مقامی نوعیت صرف لفظی ترجمے سے آگے بڑھ کر ہے۔ یہ مواد کو ثقافتی سیاق و سباق، مقامی تلاش کے رویے، اور مارکیٹ کے مخصوص ضروریات کے لیے ڈھال دیتا ہے۔

کیا مقامی نوعیت دینی ہے:

  • کرنسی اور قیمتیں: مقامی کرنسی دکھائیں (€ جرمنی میں، kr ڈنمارک میں، ¥ جاپان میں)
  • تاریخ/وقت کے انداز: 25/06/2026 (EU) بمقابلہ 06/25/2026 (US) بمقابلہ 2026/06/25 (ISO/جاپان)
  • فون نمبرز: بین الاقوامی کے لیے ملک کے کوڈ کے ساتھ مقامی شکل
  • پتے: مقامی پوسٹل شکل کو مطابقت دیں
  • سماجی ثبوت: مقامی صارفین کے نام، مقامی کمپنیاں، مقامی کیس اسٹڈیز
  • CTAs: لہجہ ڈھالیں (جرمن/جاپانی میں رسمی، انگریزی/ڈینش میں غیر رسمی)
  • تصاویر: تصاویر میں تحریر کو مقامی بنائیں، ثقافتی اعتبار سے موزوں بصریات کا استعمال کریں
  • قانونی: یورپی یونین کے لیے GDPR، مختلف ملکوں کے لیے کوکی کے رضامندی کی ضروریات
  • مثالیں: مقامی برانڈز، مقامی ویب سائٹس، مقامی حوالہ جات

ایسے مواد جو براہ راست ترجمہ نہیں ہونا چاہیے:

  • مقامی موضوعات پر بلاگ کی پوسٹس (مارکیٹ کے لیے منفرد لکھیں)
  • کیس اسٹڈیز (مقامی کاروباروں کا استعمال کریں)
  • قیمتوں کے صفحات (ہر مارکیٹ کے لیے مختلف قیمتیں درست ہیں)
  • خبروں کا مواد (علاقائی مناسبت مختلف ہوتی ہے)

کیورڈز کی مقامی نوعیت: کیورڈز کا ترجمہ نہ کریں — انہیں مقامی طور پر تحقیق کریں۔ انگریزی میں "کار انشورنس" ڈینش میں "bilforsikring" ہو سکتا ہے، لیکن تلاش کی حجم کا لیڈر ممکنہ طور پر "forsikring bil" ہو سکتا ہے (مختلف لفظی ترتیب)۔ مقامی کیورڈ ریسرچ ٹولز کا استعمال کریں۔

فوری فائدہ: اپنے قیمتوں کے صفحے کو ہر زبان میں چیک کریں۔ کیا یہ درست مقامی کرنسی دکھا رہا ہے؟ کیا آپ کے CTAs ثقافتی اعتبار سے مناسب ہیں؟ "فری شروع کریں" کا CTA جرمن میں "Jetzt kostenlos testen" میں تبدیل کرنے کی ضرورت ہو سکتی ہے — یہ ایک لفظی ترجمہ نہیں، بلکہ جو جرمن صارفین توقع کرتے ہیں۔

6. RTL سپورٹ

دائیں سے بائیں زبانیں (عربی، عبرانی، فارسی/فارسی، اردو، پشتو) اہم لے آؤٹ کے ایڈاپٹیشن کی ضرورت ہوتی ہیں۔ RTL مواد کو بائیں سے دائیں لے آؤٹ کے ساتھ پیش کرنا تقریباً 500 ملین مادری بولنے والوں کے لیے آپ کی سائٹ کو ناقابل استعمال بنا دیتا ہے۔

تکنیکی عملی جامہ:

<!-- سمت کا پتہ لگائیں اور نافذ کریں -->
<html lang="ar" dir="rtl">

RTL میں کیا پلٹنا ضروری ہے:

  • متن کی صف بندی (جسمانی متن کا دائیں جانب سے صف بند ہونا)
  • لے آؤٹ کی سمت (سائیڈ بارز بائیں سے دائیں منتقل ہوتے ہیں)
  • نیویگیشن کا آرڈر (الٹ)
  • سمت سے جڑی علامات (تیر، ترقی کے بار)
  • پیڈنگ اور مارجن (بائیں/دائیں کی اقدار پلٹنا)
  • بارڈر ریڈیئس (کونے کی اقدار پلٹنا)
  • CSS flexbox/grid کی سمت

کیا نہیں پلٹنا چاہیے:

  • فون نمبر اور ریاضی کے اظہار
  • دائیں سے بائیں برانڈ کے نام اور لوگو
  • آڈیو/ویڈیو پلےئر کنٹرولز
  • افقی اسکرول کا اشارہ
  • ایمبیڈڈ کوڈ بلاکس

CSS کا طریقہ (جدید):

/* منطقی خصوصیات کا استعمال کریں */
.card {
  margin-inline-start: 1rem;  /* مارجن-بائیں کے لئے متبادل */
  padding-inline-end: 0.5rem; /* padding-دائیں کے لیے متبادل */
  border-start-start-radius: 8px; /* LTR میں اوپر بائیں، RTL میں اوپر دائیں */
}

RTL کی جانچ:

  • میں dir="rtl" شامل کریں اور ہر صفحہ چیک کریں
  • تصدیق کریں کہ عربی/عبرانی متن قابل پڑھائی ہے (ناخواندہ یونیکوڈ نہیں ہونا چاہیے)
  • فارم کی ان پٹ کی جانچ کریں (متن کی سمت)
  • چیک کریں کہ نمبر RTL متن کے اندر درست طور پر ظاہر ہوتے ہیں

فوری فائدہ: اگر آپ عربی یا عبرانی کی حمایت کر رہے ہیں تو ان مقامات کے لیے اپنے HTML عنصر میں dir="rtl" شامل کریں اور CSS منطقی خصوصیات (margin-inline-start بجائے margin-left) کا استعمال کریں۔ یہ ایک تبدیلی 80% RTL لے آؤٹ کے مسائل حل کرتی ہے۔

7. زبان کی تشخیص اور روٹنگ

آپ یہ فیصلہ کرتے ہیں کہ صارف کو کون سی زبان کے ورژن کو دکھانا ہے، اس کا اثر UX اور SEO دونوں پر پڑتا ہے۔

بہترین طریقہ: URL-based with preference cookie

  1. پہلی بار: URL کی بنیاد پر مواد دکھائیں (جیسے، /da/page = ڈینش)
  2. روٹ URL (/): Accept-Language ہیڈر کی بنیاد پر ری ڈائریکٹ کریں یا ڈیفالٹ (انگریزی) دکھائیں
  3. دستی سوئچ: جب صارف زبان منتخب کرتا ہے، تو ایک کوکی مرتب کریں اور آئندہ دوروں پر اس کا احترام کریں
  4. کبھی نہیں: زبان مخصوص URL سے آگے ری ڈائریکٹ کریں

کیا سے بچنا چاہیے:

  • IP کی بنیاد پر ری ڈائریکشنز (گوگل امریکہ کے IPs سے کرال کرتا ہے → صرف انگریزی انڈیکس کرتا ہے)
  • جاوا اسکرپٹ پر مبنی زبان کی تشخیص (تلاش کے انجن جاوا اسکرپٹ کو قابل اعتماد طریقے سے نہیں چلا سکتے)
  • /de/page کو انگریزی صارفین کے لیے /en/page میں ری ڈائریکٹ کرنا (hreflang کو توڑتا ہے)
  • پوشیدہ مواد (مختلف مواد کو صارف ایجنٹ کی بنیاد پر دکھانا)

صحیح ری ڈائریکٹ کی رفتار:

صارف کی آمد: /               → 302 ری ڈائریکٹ کے لیے /{detected-locale}/
صارف کی آمد: /da/page        → ڈینش مواد پیش کریں (کبھی آنے سے دور نہ ہو)
صارف کی آمد: /nonexistent    → 404 (ڈیفالٹ زبان کی طرف نہ ری ڈائریکٹ کریں)

SEO-اہم قاعدہ: ہر زبان کا URL براہ راست گوگل بوٹ کے لیے قابل رسائی ہونا چاہیے بغیر ری ڈائریکشنز کے۔ اگر گوگل /da/page کو کرال کرتا ہے اور /en/page کی طرف ری ڈائریکٹ ہوتا ہے تو وہ آپ کے ڈینش مواد کو کبھی انڈیکس نہیں کرے گا۔

فوری فائدہ: یہ تصدیق کریں کہ گوگل بوٹ آپ کے تمام زبان کے URLs کو براہ راست رسائی حاصل کر سکتا ہے۔ تلاش کنسول میں، ایک غیر انگریزی URL پر URL کی جانچ کے لیے ٹول کا استعمال کریں۔ اگر یہ ری ڈائریکٹ دکھاتا ہے تو اپنے روٹنگ منطق کو درست کریں۔

8. زبانوں میں دوہرے مواد

کثیر زبان سائٹس کے سامنے ایک منفرد دوہرے مواد کا چیلنج آتا ہے: مختلف زبانوں میں ملتے جلتے صفحات آپس میں تلاش کے نتائج میں ایک دوسرے کے ساتھ مقابلہ کر سکتے ہیں۔

جب دوہرے مواد کا مسئلہ بنتا ہے:

  • صفحات جو 90%+ ایک جیسے ہیں مختلف زبانوں میں (غیر ترجمہ شدہ مواد)
  • ایک ہی URL جو لوکیل کے پری فکس کے ساتھ اور بغیر قابل رسائی ہے (/page اور /en/page)
  • کینونیکل ٹیگ غائب ہے جو دونوں ورژن کو انڈیکس کرنے کی اجازت دیتا ہے
  • Hreflang کی غلطیاں جو گوگل کو "غلط" ورژن منتخب کرنے کی طرف اشارہ کرتی ہیں

حل:

| مسئلہ | حل | |-------|----| | غیر ترجمہ شدہ صفحات | noindex کا استعمال کریں جب تک کہ ترجمہ نہ ہو، یا واضح زبان کے اشارے کے ساتھ انگریزی دکھائیں | | ڈبل URLs (/page + /en/page) | 301 میں سے ایک کو دوسرے کی طرف ری ڈائریکٹ کریں | | گوگل غلط زبان کو انڈیکس کر رہا ہے | hreflang باہمی تعلقات کو درست کریں، تلاش کنسول میں تصدیق کریں | | کم معیار کے ترجمے جو انڈیکس ہوگئے | ترجمے کے معیار کو بہتر بنائیں یا کم زبانوں میں یکجا کریں |

کینونیکل ٹیگ کی حکمت عملی:

<!-- ہر زبان کا صفحہ اپنی خود کی کینونیکل -->
<!-- /en/page -->
<link rel="canonical" href="https://example.com/en/page" />

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

کبھی بھی ایک زبان سے دوسری زبان کی طرف کینونیکل کا اشارہ نہ دیں (جیسے ڈینش کا کینونیکل انگریزی کی طرف) — یہ گوگل کو بتاتا ہے کہ ڈینش ورژن کو مکمل طور پر نظر انداز کر دیا جائے۔

فوری فائدہ: گوگل میں site:yourdomain.com "آپ کا صفحہ عنوان" تلاش کریں۔ اگر آپ دیکھتے ہیں کہ انگریزی اور ترجمہ شدہ ورژن دونوں ایک ہی تلاش کے لیے ظاہر ہو رہے ہیں تو آپ کے پاس دوہرے مواد یا hreflang کا مسئلہ ہے۔

کثیر زبان SEO چیک لسٹ

ہر بین الاقوامی سائٹ کے لیے یہ مکمل کریں:

  • [ ] تمام صفحات پر hreflang ٹیگ، خود حوالہ اور x-default شامل ہیں
  • [ ] تمام hreflang تعلقات باہمی ہیں (کرالر کے ساتھ چیک کیا گیا)
  • [ ] درست لوکیل روٹنگ (ذیلی فولڈر کی سفارش کی): /{locale}/page
  • [ ] زبان کے مخصوص URLs سے کوئی خودکار ری ڈائریکشن نہیں
  • [ ] ترجمے کا معیار تصدیق شدہ (کوئی مخلوط زبان کے صفحات نہیں)
  • [ ] ہر زبان میں میٹا عنوان اور وضاحت منفرد ہیں (نہیں دہرائے گئے)
  • [ ] قیمتیں، تاریخیں، اور فارمیٹس مارکیٹ کے لحاظ سے مقامی نوعیت کے لیے
  • [ ] عربی/عبرانی/فارسی (اگر قابل اطلاق ہو) کے لیے RTL سپورٹ نافذ شدہ
  • [ ] تلاش کنسول میں ہر لوکیل کے لیے سائٹ میپ جمع کرایا گیا
  • [ ] ہر زبان کا صفحہ اپنی خود کی کینونیکل URL رکھتا ہے (دوسرے زبان کی طرف اشارہ نہیں کر رہا)
  • [ ] کسی بھی صفحے پر کوئی خام i18n کلیدیں نظر نہیں آئیں
  • [ ] تمام صفحات پر زبان کا سوئچر دستیاب ہے (برابر صفحات کی طرف جوڑنا، ہوم پیج نہیں)

LANGR کس طرح کثیر زبان SEO کی جانچ کرتا ہے

LANGR کے پاس کثیر زبان SEO کے لیے دو مخصوص ماڈیول ہیں:

i18n-checker: آپ کے صفحات کے 5 لوکیل مختلف اقسام کو کرال کرتا ہے اور چیک کرتا ہے:

  • Hreflang ٹیگ کی تکمیل اور باہمی تعلق
  • ناقابل رسائی لوکیل URLs (404 یا ری ڈائریکٹنگ)
  • مقامات میں سختی سے coded / غیر ترجمہ شدہ اسٹرنگز (بیک اپ کی دریافت)
  • خام i18n کلیدیں جو عوامی متن کے طور پر ظاہر ہوتی ہیں
  • ترجمے کی کوریج کا فیصد

ترجمے کا سکینر: AI کی طاقت پر مبنی معیار کا تخمینہ:

  • 0-100 پیمانے پر ترجمے کی قدرتی نوعیت کا اندازہ لگاتا ہے
  • مشینی ترجمے کے نقصانات کا پتا لگاتا ہے
  • دوسری صورت میں ترجمہ شدہ صفحات کے اندر غیر ترجمہ شدہ حصے کی نشاندہی کرتا ہے
  • جسمانی مواد سے الگ UI عناصر (بٹن، لیبل، نیویگیشن) کی جانچ کرتا ہے

ان ماڈیولز نے آپ کی کثیر زبان کی عملی جامہ کو تکنیکی (hreflang، روٹنگ، کینونکلس) اور معیار (ترجمہ، مقامی نوعیت) کے نقطہ نظر سے چیک کیا — LANGR کی 13 SEO ڈسپلن میں سے دو۔

عمومی کثیر زبان کی غلطیاں (اثر کے لحاظ سے درجہ بند)

  1. غیر باہمی hreflang — گوگل پورے سیٹ اپ کو نظر انداز کرتا ہے
  2. IP کی بنیاد پر خودکار ری ڈائریکٹ — غیر انگریزی ورژن کو انڈیکس کرنے سے ممنوع ہے
  3. زبانوں کے درمیان ایک ہی میٹا ٹیگ — ترجمہ شدہ صفحات کے رینکنگ کے امکانات کو ضائع کرتا ہے
  4. مخلوط زبان کے صفحات — انگریزی میں بٹن، جرمن میں مواد = کم معیار کا اشارہ
  5. کوئی x-default نہیں — گوگل آپ کے بیک اپ ورژن کا تعین نہیں کر سکتا
  6. URLs کا لفظی ترجمہ/about-us/uber-uns ٹھیک ہے، لیکن مستقل رکھیں
  7. RTL کو نظر انداز کرنا — 500M+ مادری بولنے والوں کے لیے ٹوٹا ہوا لے آؤٹ
  8. کینونیکل دوسری زبان کی طرف اشارہ کرنا — Google کی فہرست میں ترجمہ شدہ ورژن کو مار دیتا ہے

اگلا کیا ہے؟

مرحلہ 11: B2B لیڈ ڈسکوری — SEO کے ڈیٹا کو کوالیفائیڈ لیڈز میں تبدیل کرنا خودکار پروسپیکٹنگ، ڈومین پر مبنی لیڈ اسکورنگ، اور SEO کی دریافتوں کی طاقت سے تاثیر بغیر۔


یہ گائیڈ LANGR کی 13 قدمی SEO سیریز کا حصہ ہے۔ ایک مفت آڈٹ کریں تاکہ یہ جان سکیں کہ آپ کی سائٹ 13 ڈسپلن میں سے کس مقام پر ہے۔

Want to know where your site stands?

Run a free SEO audit — it takes under 60 seconds.

Related articles