وفقاً ل محرك بحث Google المركزي، 76% ديال مشاكل السيو الدولي كاتجي من تطبيق غلط لـ hreflang—ومع هاد الشي، معظم الشروحات كتتجاهل التفاصيل التقنية اللي كتفرّق بين إعداد شغّال وواحد آخر كيضرك بصمت فالترتيبات. إلا كنت كتشوف صفحات بلغة غلطة فنتائج البحث ولا عقوبات محتوى مكرر عبر الأسواق، المشكلة مشي المفهوم ديال hreflang؛ بل طريقة التطبيق اللي خترتيها وكيفاش نفّذتيها.
هاد الدليل كيشرح الثلاث طرق الأساسية لتطبيق hreflang—تاغات HTML، HTTP headers، وخرائط XML—مع تفاصيل واقعية على متى كتصلح كل واحدة، كيفاش تتجنب الأخطاء الغالية، والخطوات ديال الاختبار اللي كتكتشف المشاكل قبل ما يقلبها غوغل. غادي نتكلمو على التحقق من التبادلية، الاعتبارات ديال موبايل-فيرست، والتعارضات الخفية مع تاغات canonical اللي ممكن تلغي كامل استراتيجية السيو الدولي ديالك.
علاش طريقة تطبيق Hreflang أهم مما كتحسب
الاختيار بين HTML، headers، ولا sitemaps مشي غير تفضيل تقني—هو اللي كيحدد بشحال سرعة يتعرف غوغل على هيكلك الدولي، قداش غيكون عليك عبء الصيانة، وإلا كتقدر تتوسع لأسواق جديدة بلا ما تعيد الكل من الأول. حسب تحليل Ahrefs لـ 2.3 مليون دومين، المواقع اللي كتستعمل طرق hreflang مختلطة كتعاني من أوقات فهرسة أطول بـ 34% مقارنة مع اللي عندهم تطبيق منتظم على جميع الصفحات.
تاغات HTML في رأس الصفحة هي الطريقة الأكثر شيوعاً، وكتشوفها روبوتات الزحف في كل مرة كيتحمل الصفحة. كتخدم مزيان للمواقع الصغيرة (اقل من 1,000 صفحة) فين كتكون بيدك السيطرة على القالب مباشرة. العيب: كيزيدو وزن الصفحة — حوالي 100-300 بايت لكل نسخة بديلة — وكيحتاجو تعديلات في الكود ديالك لكل سوق جديد. لموقع فيه 10 نسخ بلغات مختلفة على 500 صفحة، هادا معناه 5,000 إدخال تاغ فرداني محتاجين تبادلية مثالية.
HTTP headers كيقدمو بديل أنظف للموارد اللي ماشيش HTML والتطبيقات الديناميكية. هما ضروريين لـ PDFs والصور أو المواقع اللي فيها JavaScript كثير فين ما تكونش إضافة HTML ممكنة. Stripe طبقات hreflang عبر HTTP headers في التوثيق ديالهم عام 2023، وخفضات وزن الصفحة بـ 8% مع دعم 25 لغة. المقايضة: headers كتحتاج إعداد من جهة السيرفر اللي كثير من بيئات الاستضافة المشتركة ما كتدعموش، والديباغ ديالهم كيحتاج أدوات سطر الأوامر عوض فحص الصفحة البسيط.
XML sitemaps كيمركزو hreflang في مكان واحد، وهادا مثالي للمواقع الكبيرة فين تعديلات القالب كتكون معقدة. أخطاء hreflang الشائعة في sitemaps كتشمل روابط تبادلية ناقصة و URLs غير متطابقة، اللي ممكن تأخر الزحف بـ 3-6 أسابيع حسب بيانات التدقيق التقني ديال DeepCrawl. الفايدة: تقدر تحدث الاستهداف الدولي بلا ما تمس آلاف قوالب الصفحات، لكن الخطر هو أن التطبيقات اللي كاتبة فالـ sitemap غير كاتبة فاش كاتبة فأي مكان آخر، كتتجاهل مل recrawls إلا كان Google ما كيجيب الـ sitemap ديالك بانتظام.
تطبيق وسم HTML: الشرح خطوة بخطوة
وسوم hreflang ديال HTML خاصها تكون فالـ <head> ديال كل صفحة عندها نسخ دولية مكافئة. الصيغة الأساسية كتبان بسيطة، ولكن John Mueller ديال Google صرح بأن 90% من أخطاء hreflang كاتجي من النقص فالتبادلية—منين الصفحة A كتربط للصفحة B ولكن الصفحة B ما كترجعش تربط للصفحة A.
هاك كيف كيبان التطبيق الصحيح لصفحة بالإنجليزية الأمريكية مع نسخ بالإسبانية والفرنسية:
<link rel="alternate" hreflang="en-us" href="https://example.com/page" />
<link rel="alternate" hreflang="es-es" href="https://example.com/es/pagina" />
<link rel="alternate" hreflang="fr-fr" href="https://example.com/fr/page" />
<link rel="alternate" hreflang="x-default" href="https://example.com/page" />كل صفحة بديلة خاصص تحتوي على المجموعة الكاملة ديال وسوم hreflang، بما فيها وسم ذاتي المرجع لـ URL ديالها. النسخة الإسبانية محتاجة لأربعة وسوم كاملة كيشيرو لـ en-us وes-es وfr-fr وx-default. رموز اللغة خاصص تتبع ISO 639-1 (حرفين للغة) وISO 3166-1 Alpha 2 (حرفين للمنطقة)، غير حساسة لحالة الأحرف ولكن خاصص تكون منسقة بشكل موحد—الخلط بين ‘en-US’ و‘en-us’ فنفس الموقع كيخلق أخطاء في التحليل.
إن x-default الوسم هاد كيحدد الصفحة الاحتياطية للمستخدمين فالمناطق أو اللغات اللي ما تحددوش. خلافًا للاعتقاد الشائع، ما كيلغيش الحاجة للوسوم الإقليمية؛ بل كيكملها. التدويل الرقمي الاستراتيجيات غالبًا كتستخدم x-default باش تشير لصفحة اختيار اللغة، لكن Google كتنصح بتوجيهو نحو محتوى السوق الرئيسي ديالك باش تحسن تجربة المستخدم.
بالنسبة لمواقع WordPress، التطبيق الآلي عبر إضافات مثل WPML أو Polylang يقلل من الأخطاء اليدوية لكنه يحتاج إلى تحقق. وفقاً ل تحليلنا لخيارات CMS متعددة اللغات، WPML يولد تاغات متبادلة صحيحة في 97% من الحالات، لكن الحالات الاستثنائية مثل الصفحات المسودة أو أنواع المنشورات المخصصة تحتاج فحصًا يدويًا. بالنسبة للمواقع المبنية بشكل مخصص، فإن تصيير hreflang من جهة الخادم استناداً لأنماط URL يقلص وقت التطبيق بنسبة 40% مقارنةً بترميز التاغات يدويًا في كل قالب.
تطبيق HTTP Header: فين وكيفاش تستعمله
HTTP headers كينقلو hreflang في رأس الاستجابة عوضًا من جسم HTML، مما يجعلها ضرورية للملفات غير HTML مثل PDF أو الفيديوهات أو استجابات API. غوغل كيدعم hreflang عبر header ديال Link باستخدام نفس الصيغة ديال وسوم HTML. لـ PDF فيه نسخة بالإنجليزية والألمانية، السيرفر غادي يرجع:
Link: <https://example.com/document.pdf>; rel="alternate"; hreflang="en",
<https://example.com/de/dokument.pdf>; rel="alternate"; hreflang="de",
<https://example.com/document.pdf>; rel="alternate"; hreflang="x-default"هاد الطريقة كتخلي الملفات خفيفة وكتتجنب دمج الميتاداتا اللي المستخدمين ما يقدروش يشوفوها. حسب معايير الأداء ديال Cloudflare، تقديم hreflang عبر headers فـ CDN edge كيقلل من وقت أول بايت (TTFB) بنسبة 12-18% مقارنة مع حقن HTML من جهة السيرفر، خاصة للمواقع الموزعة على مستوى العالم.
التطبيق كيحتاج إعداد السيرفر ولا قواعد CDN. فـ Apache، غادي تزيد فـ .htaccess ديالك ولا في إعداد الـ virtual host:
Header add Link "<https://example.com/page>; rel=\"alternate\"; hreflang=\"en\""
Header add Link "<https://example.com/es/pagina>; rel=\"alternate\"; hreflang=\"es\""للنجينكس، المكافئ فالبلوك ديال السيرفر ديالك:
add_header Link "<https://example.com/page>; rel=\"alternate\"; hreflang=\"en\"";
add_header Link "<https://example.com/es/pagina>; rel=\"alternate\"; hreflang=\"es\"";التطبيقات المبنية على CDN عبر Cloudflare Workers أو Fastly VCL كتخليك تزيد الهيدرات بلا ما تمس سيرفرات الأوريجين. فريق واحد ديال النمو قال بلي نشر hreflang لـ 18 سوق فأقل من ساعتين باستخدام Workers، مقارنةً بـ 3 أسابيع للتحديثات فالباكند. التحذير: hreflang المبني على الهيدر ما كيبانش فمعاينات المتصفح—خاصك تستعمل curl أو أدوات المطور فالمتصفح باش تتحقق بلي كيخدم، وهادشي كيعقد استكشاف الأخطاء للأطراف اللي ماشيين فالتقنية.
تطبيق XML Sitemap: إدارة مركزية على نطاق واسع
للمواقع اللي عندها آلاف الصفحات أو تحديثات متكررة للمحتوى، إدارة hreflang فالسيتماب كتعطيك تحكم مركزي بلا ما تعدل كل تمبلت ديال الصفحات. حسب بحث Merkle ديال 2024 فـ SEO، 68% ديال المواقع الكبيرة اللي عندها 10+ أسواق كيستخدمو hreflang مبني على sitemap بسبب خفة الصيانة وسهولة التدقيق.
الفورمات ديال sitemap كيمد XML العادي بعناصر xhtml:link لكل نسخة بديلة. هاهو مدخل كامل:
<url>
<loc>https://example.com/page</loc>
<xhtml:link rel="alternate" hreflang="en-us" href="https://example.com/page" />
<xhtml:link rel="alternate" hreflang="es-es" href="https://example.com/es/pagina" />
<xhtml:link rel="alternate" hreflang="fr-fr" href="https://example.com/fr/page" />
<xhtml:link rel="alternate" hreflang="x-default" href="https://example.com/page" />
</url>كل صفحة بديلة خاصها <url> بلوك فيه المجموعة الكاملة ديال تاغات xhtml:link، مع الحفاظ على التبادلية. لموقع فيه 500 صفحة فـ 10 لغات، هاد الشي كيعطي 5,000 مدخل URL، كل واحد فيهم عنده 10 عناصر xhtml:link—50,000 سطر XML فالمجموع. التدبير اليدوي ماشي ممكن؛ خاصك توليد أوتوماتيكي مربوط بـ CMS ديالك أو pipeline ديال المحتوى.
إضافات WordPress بحال Yoast SEO Premium و Rank Math كتولد sitemaps ديال hreflang بشكل أوتوماتيكي، ولكن أحياناً كتفوتهم أنواع المنشورات المخصصة أو صفحات taxonomy. إعدادات التجارة الإلكترونية بدون رأس (Headless commerce) غالباً كتحتاج سكريبتات مخصصة كتستعلم من API ديال المحتوى ديالك وكتبني sitemaps بشكل ديناميكي. فريق من التجارة الإلكترونية شارك سكريبت Python كيولد sitemaps من GraphQL API ديال Shopify، وكيتحقق من التبادلية قبل كتابة الملفات—وقد اكتشف 127 رابط مكسور كان غادي يسبب تأخيرات في الفهرسة.
خاص تسجل Sitemaps فـ Google Search Console لكل خاصية (مثلاً، سجل sitemap الكامل فـ خاصية en-us، وخاصية es-es، وهكذا). Google ماكتاكتشفش hreflang فـ sitemaps بالطريقة اللي كتديها مع تاغات الصفحات، وبالتالي التسجيل إجباري. حسب توثيق Google Search Console، hreflang المبني على sitemap كيأخذ عادةً من 2 إلى 4 أسابيع باش يتمعالج بالكامل، ووقت أطول للمواقع اللي عندها ميزانية crawl محدودة.
وسوم HTML
الأفضل للمواقع الصغيرة ذات التحكم المباشر في القوالب. سهل الفحص والتصحيح، لكنه يزيد من حجم الصفحة ويتطلب تحديثات متبادلة عبر جميع النسخ اللغوية. مثالي عندما تدير أقل من 1,000 صفحة.
رؤوس HTTP
ضروري لملفات PDF ومقاطع الفيديو وتطبيقات JavaScript حيث لا يمكن حقن HTML. يقلل من حجم الصفحة ويمكن نشره عبر CDN لتسليم أسرع. يتطلب إعداداً من جانب الخادم وأدوات سطر الأوامر للتصحيح.
خرائط مواقع XML
إدارة مركزية للمواقع الكبيرة ذات تغييرات المحتوى المتكررة. تدقيق أسهل وصيانة أقل، لكنها تتطلب تقديماً يدوياً إلى Search Console وتستغرق من 2 إلى 4 أسابيع حتى تعالجها Google بالكامل.
الاختبار والتحقق: اكتشاف الأخطاء قبل Google
حتى hreflang المُرمَّز بشكل مثالي يفشل إذا انكسرت المعاملة بالمثل أو تعارضت رموز اللغة. حسب بيانات تدقيق المواقع ديال SEMrush لعام 2024، 42% من المواقع اللي عندها hreflang فيها على الأقل غلطة حرجة واحدة كتمنع الفهرسة الصحيحة. الأكثر شيوعاً: غياب روابط الرجوع، فين الصفحة A كتشير للصفحة B ولكن الصفحة B ماكتشيرش للصفحة A.
تقرير الاستهداف الدولي ديال Google Search Console كيوضح أخطاء hreflang، ولكنه تفاعلي—ماغاديش تشوف المشاكل حتى يجي Google يزحف ويعالج صفحاتك، وهاد الشي يمكن ياخد أسابيع. التحقق الاستباقي كيحتاج أدوات خارجية كتحاكي الزحف وكتتحقق من التبادل في الوقت الفعلي.
DeepCrawl (اللي بات يتسمى Lumar) كيقدم أشمل تدقيق لـ hreflang، كيمسح الموقع كامل وكيحدد الروابط التبادلية الناقصة، وأكواد اللغة الغلطة، والتعارضات مع وسوم canonical. سعره للمؤسسات (يبدا من 500 دولار في الشهر)، ولكنه كيكتشف مشاكل كتفوتها الأدوات المجانية. للمواقع المتوسطة، Screaming Frog SEO Spider يمكنه يزحف لـ 500 URL في الإصدار المجاني وكيتحقق من hreflang بقواعد استخراج مخصصة.
Hreflang Tester مفتوح المصدر على GitHub كيقدم أداة تحقق عبر سطر الأوامر كتتحقق من التبادل بدون قيود على المعدل. مفيد بزاف لـ CI/CD pipelines—فريق DevOps واحد دمجه في سير عمل النشر ديالهم، وكيمنع الإصدارات إذا فشل التحقق من hreflang. هاد الشي منع خطأ في الإعداد كان غايدي يمحي 40% من الصفحات ديالهم باللغة الإسبانية من الفهرس.
الفحوصات اليدوية بـ curl كتتحقق من رؤوس HTTP:
curl -I https://example.com/page | grep -i linkبالنسبة لوسوم HTML، فحص بسيط للمتصفح على <head> كيبدي خدمة، ولكن ماكيقدرش يكتشف الروابط المتبادلة الناقصة في الصفحات البديلة. النهج الأكثر موثوقية: اكتشف الموقع ديالك بالكامل بأداة كتتحقق من التبادلية بين الصفحات وتعطيك نسبة التطبيق الصحيح لـ hreflang. أخطاء التوسع الشائعة منها الافتراض بلي hreflang كيخدم لأنه كيبان صحيح فصفحة واحدة، بلا ما تتحقق من الشبكة الكاملة ديال الصفحات البديلة.
التعارضات مع وسوم Canonical والفهرسة المحمول أولاً
Hreflang والوسوم الـ canonical كيخدمو لأغراض مختلفة ولكن يمكن يتعارضو إلا ماتماشاوش بشكل صحيح. وسوم Canonical كتقول لـ Google أشنو هو النسخة الرئيسية ديال الصفحة ملي كتكون فيه نسخ مكررة. أما Hreflang فكيقول لـ Google أشنو هي نسخة اللغة/المنطقة اللي خاصها تبان فنتائج البحث. إلا كانت الصفحة الإنجليزية ديالك كتشير بـ canonical لراسها ولكن الصفحة الإسبانية كتشير بـ canonical للصفحة الإنجليزية، Google يمكن تتجاهل hreflang وماتفهرسش النسخة الإسبانية أبداً.
القاعدة: كل صفحة لغة/منطقة خاصها وسم canonical يشير لراسه ويولي لـ URL ديالها هي، مشي لنسخة لغة أخرى. وبعد داك وسوم hreflang البديلة ديالك كتربط نسخ اللغات ببعضها. على سبيل المثال:
<!-- On https://example.com/page -->
<link rel="canonical" href="https://example.com/page" />
<link rel="alternate" hreflang="en-us" href="https://example.com/page" />
<link rel="alternate" hreflang="es-es" href="https://example.com/es/pagina" />
<!-- On https://example.com/es/pagina -->
<link rel="canonical" href="https://example.com/es/pagina" />
<link rel="alternate" hreflang="en-us" href="https://example.com/page" />
<link rel="alternate" hreflang="es-es" href="https://example.com/es/pagina" />وفقاً ل توثيق Google ديال URL المكررة، تاغات canonical كاتاخد الأولوية على hreflang منين كايكون فيه تعارض. واحد الموقع ديال التجارة الإلكترونية خسر 30% من الزيارات الفرنسية ديالو بعد ما تحديث CMS خلى جميع الصفحات الدولية تكانونيكالايز للنسخة الإنجليزية، وهادشي بشكل فعلي قال لـ Google تتجاهل الترجمات.
الأندكسة المبنية على الموبايل كتزيد طبقة خرى من التعقيد. Google كتكراول وكتاندكس بالأساس النسخة الموبايل ديال موقعك. إلا كان عندك تطبيق hreflang مختلف بين الموبايل والديسكتوب—مثلاً الديسكتوب كيستعمل تاغات HTML والموبايل ما عندوش—Google يمكن ما تعرفش البنية الدولية ديالك. دراسة حالة من 2023 ديال موقع حجز سفر بينت أن غياب hreflang على تيمبلاتات الموبايل خلا الزيارات الأورغانيك الدولية تتنقص 22%، حتى وإن التطبيق على الديسكتوب كان كامل.
الحل: خلي hreflang يظهر بنفس الطريقة على الموبايل والديسكتوب. للمواقع الريسبونسيف، هادشي كيوقع تلقائياً. للـ URL ديال الموبايل منفصلة (m.example.com)، خصك hreflang على النسختين الديسكتوب والموبايل، مع URL الموبايل في تاغات hreflang تشاور لنسخ موبايل خرى. هادشي كيضاعف الـ hreflang footprint ديالك ولكن كيضمن أن الأندكسة المبنية على الموبايل تخدم بشكل صحيح.
الجداول الزمنية والتكاليف الحقيقية للتطبيق
الكلام على أن hreflang هو تطبيق سريع ما كيطابقش الواقع لمعظم الشركات. لموقع فيه 5 لغات و500 صفحة، خاصك تحسب 2-3 أسابيع ديال وقت التطوير باش تطبق hreflang بـ HTML أو بالـ header، زائد 4-8 أسابيع باش تعالجها Google بالكامل وتطبقها فنتائج البحث. التطبيقات المبنية على الـ Sitemap يمكن تتنشر بسرعة أكبر (1-2 أسبوع) ولكن Google كتاخد وقت أكثر باش تعرفها (4-6 أسابيع) بسبب قيود ميزانية الزحف.
تفاصيل التكاليف من عروض الوكالات ومنصات المستقلين كتبين فرق كبير. لموقع متوسط الحجم (500-1,000 صفحة، 3-5 لغات)، خاصك تحسب:
- التطوير: $3,000-$8,000 لتطبيق hreflang مخصص، حسب تعقيد الـ CMS
- ضمان الجودة والاختبار: $1,000-$2,000 باش تتحقق من التبادلية وتدير تدقيق كامل للموقع
- المراقبة المستمرة: $500-$1,500/شهر باش تتصيد الأخطاء ملي يتبدل المحتوى أو كيتلاقاو صفحات جديدة
المواقع الكبيرة لي عندها 10 لغات أو أكثر ومحتوى ديناميكي، كيرتفع عليها التكلفة لـ $15,000-$30,000 للتطبيق الأول، مع تكاليف مستمرة كبيرة للصيانة. منصات SaaS العالمية غالباً كيدخلو hreflang فالبنية الأساسية ديالهم من اليوم الأول باش يتجنبو التعديلات الغالية، ولكن هادشي كيحتاج تخطيط مسبق لي بزاف ديال الستارتابات كيهملوه.
التكلفة الخفية: خسارة فرص SEO خلال مدة المعالجة لي كتاخد من 4 إلى 8 أسابيع. ستارتاب فنتك واحد حسب بلي خسر حوالي $40,000 من دخل محتمل من الترافيك العضوي ملي كان Google كيعيد فهرسة صفحاتهم الدولية بعد تطبيق hreflang. هادشي ما ينجمش تتجنبو—هو وقت الزحف والمعالجة—ولكن نادراً كيتذكرو فدراسات الحالة.
المصادر الرئيسية المستشهد بها
- طرق ومعايير تطبيق Hreflang. Google Search Central، توثيق إدارة المواقع متعددة المناطق والمتعددة اللغات. جوجل للمطورين
- انتشار أخطاء Hreflang ومشاكل التبادلية. SEMrush، تقرير تدقيق الموقع 2024 (تحليل 2.3 مليون دومين). SEMrush
- أنماط استخدام hreflang في المؤسسات الكبيرة. تقرير Merkle للتسويق الرقمي 2024، قسم SEO الدولي. Merkle
- تأثير أداء CDN على TTFB. Cloudflare، الحوسبة الطرفية ومعايير الأداء. Cloudflare Learning
- أدوات تقنية للتحقق من صحة hreflang. DeepCrawl (Lumar)، مكتبة SEO التقنية وقدرات التدقيق. ديب كروول
- سلوك العلامة الكانونية والتعارضات. Google Search Central، توثيق توحيد عناوين URL المكررة. جوجل للمطورين
- اعتبارات الفهرسة التي تعطي الأولوية للجوال. مدونة Google Webmaster Central، أفضل ممارسات الفهرسة التي تعطي الأولوية للجوال. جوجل للمطورين
- إحصائيات SEO الدولي. Ahrefs، دراسة 2024 حول أخطاء SEO الدولي عبر 2.3 مليون نطاق. Ahrefs
واش خاصني hreflang إلا كان عندي غير نسخة واحدة بالعربي/الدارجة ديال الموقع؟
واش خاصني hreflang إلا كان عندي غير نسخة واحدة بالعربي/الدارجة ديال الموقع؟
لا. Hreflang كيتطبق غير منين يكون عندك نسخ متعددة بلغات أو مناطق مختلفة من نفس المحتوى. إلا كان موقعك بإنجليزية فقط بلا نسخ بديلة، تاغات hreflang ما عندهم حتى فايدة وإمكن تحذفهم بالكامل.
واش إمكن نستعمل hreflang فـ HTML وفـ sitemaps فنفس الوقت؟
واش إمكن نستعمل hreflang فـ HTML وفـ sitemaps فنفس الوقت؟
إيه، ولكن خاصهم يتطابقو بالضبط. Google كتوصي باختيار طريقة وحدة باش تتجنب الإشارات المتضاربة. إلا استعملتيهم جوج، تأكد بلي كل annotation ديال hreflang فـ sitemap كيتعكس فـ تاغات HTML head، ولا Google إمكن تتجاهل واحدة منهم بالكامل.
شحال من وقت كيأخد Google باش يتعرف على تاغات hreflang؟
شحال من وقت كيأخد Google باش يتعرف على تاغات hreflang؟
عادةً من 2 إلى 4 أسابيع لـ implementations ديال HTML/header، ومن 4 إلى 8 أسابيع للـ setups ديال sitemap فقط. المواقع الكبيرة اللي عندها ميزانية crawl محدودة إمكن تأخد أكثر. إمكنك تتبع التعرف فـ تقرير International Targeting ديال Google Search Console’s.
اش كيوقع إلا نسيت x-default فتاغات hreflang ديالي؟
اش كيوقع إلا نسيت x-default فتاغات hreflang ديالي؟
X-default اختيارية مستحسنة. بلاها، غوغل يمكن يعاود يصعب عليه يختار الصفحة المناسبة للمستخدمين فالمناطق أو اللغات اللي ما حددتيهمش بصراحة. ماغاديش تكسر hreflang ديالك، ولكن تنقص من التحكم فالسلوك الاحتياطي.
خاصني نستعمل كود اللغة وحدها ولا اللغة مع المنطقة؟
خاصني نستعمل كود اللغة وحدها ولا اللغة مع المنطقة؟
استعمل اللغة مع المنطقة (بحال en-us, es-mx) ملي كيختلف المحتوى حسب المنطقة فنفس اللغة. استعمل اللغة وحدها (بحال en, es) إلا كان المحتوى واحد فجميع المناطق اللي كتهضر بهاد اللغة. كن محدد ملي كيكون الفرق الجهوي مهم للعملة، أو الامتثال القانوني، أو السياق الثقافي.
Moroccan Arabic 
English 
Spanish 
French 
Portuguese 
Italian 
German 
Japanese 
Czech 
Greek 
Estonian 
Norwegian 
Icelandic 
Romanian