اللغات

كيفية تنفيذ Hreflang خطوة بخطوة

شيفرة عملية لطرق hreflang الثلاث: وسوم رأس HTML وترويسات HTTP من نوع Link وإشارات خريطة موقع XML، مع قواعد الصياغة وأتمتة CMS على نطاق واسع وسير التحقق من صحة النشر.

نُشر أول مرة: 2 يوليو 2026 · آخر تحديث: 13 أغسطس 2026 · Advanced
اللغات
AIمن تأليفAI v2
دليل واحد في هذه الصفحة

توجد ثلاث طرق فقط لإضافة hreflang: وسوم link في رأس HTML، أو ترويسات استجابة HTTP من نوع Link للملفات غير المكتوبة بـHTML مثل PDF، أو مدخلات xhtml:link في خريطة موقع XML، وهي الأنسب على نطاق واسع. اختر طريقة واحدة؛ فـGoogle تتعامل معها بالتساوي ولا فائدة من جمعها. تخضع كل طريقة لقاعدتين لا تقبلان التفاوض: الإشارة الذاتية، أي أن تسرد كل صفحة نفسها، والتبادلية، أي إذا أشارت A إلى B وجب أن تشير B إلى A وإلا تجاهلت Google الزوج. تتكون الرموز من لغة ISO 639-1 ومنطقة اختيارية وفق ISO 3166-1 alpha-2، ويمثل x-default الخيار الاحتياطي. ولّد كل شيء من مصدر حقيقة واحد، ثم تحقق من الرأس المعروض لا من مصدر الصفحة وحده؛ ففي دراستي لـ374 756 نطاقًا، كان لدى أكثر من 67 % من إعدادات hreflang مشكلة واحدة على الأقل.

الخلاصة — ثلاث طرق، اختر واحدة: وسوم HTML من نوع <link> داخل <head>، أو ترويسات HTTP من نوع Link:، وهي الخيار الوحيد للملفات غير المكتوبة بـHTML مثل PDF، أو مدخلات <xhtml:link> في خريطة موقع XML، وهي الأنسب على نطاق واسع لأن ملفًا واحدًا تولده الآلة أسهل في ضمان الجودة. تقول Google إن الطرق الثلاث متكافئة ولا فائدة من جمعها. تخضع كل طريقة للإشارة الذاتية والتبادلية، وتستخدم عناوين URL مطلقة، ورمز لغة ISO 639-1 مع منطقة اختيارية وفق ISO 3166-1 alpha-2. ولّد كل شيء من مصدر حقيقة واحد؛ فـhreflang الذي يُصان يدويًا يتدهور. ثم تحقق من الرأس المعروض، وازحف إلى العنقود كله للتحقق من التبادلية، وأعد الفحص بعد كل تغيير في URL. لا تعِد توجيه الزواحف تلقائيًا حسب الموقع الجغرافي.

قبل كتابة سطر من الشيفرة: ثلاثة قرارات

1. أي طريقة. توضح Google أن الاختيار يتعلق بالراحة لا الأداء: “The three methods are equivalent from Google’s perspective and you can choose the method that’s the most convenient for your site.” (الترجمة العربية) «الطرق الثلاث متكافئة من منظور Google، ويمكنك اختيار الطريقة الأنسب لموقعك». قاعدتي التقريبية:

Evidence for this claim Google supports equivalent HTML, HTTP-header, and sitemap methods for declaring localized versions; HTTP headers can be used for non-HTML files such as PDFs. Scope: Google Search hreflang implementation methods. Confidence: high · Verified: Google: Localized versions
  • بضعة عناوين URL وموقع ثابت أو بسيط ولغات ومناطق قليلة ← وسوم HTML من نوع <link>.
  • أصول غير مكتوبة بـHTML، مثل PDF والمستندات ← ترويسات HTTP من نوع Link:؛ فلا خيار آخر لأن PDF لا يحتوي <head>.
  • لغات ومناطق كثيرة، أو مسار قائم لخرائط الموقع، أو إعداد headless/JAMstack ← خريطة موقع XML تُولد برمجيًا.

تعرض عدسة أشجار القرار هذه الخيارات في مخطط تدفق فعلي.

2. مصدر حقيقة واحد. أيًا كانت الطريقة، يجب توليد الإشارات من موضع واحد: جدول اللغات والترجمات في قاعدة البيانات، أو حقل علاقات في CMS، أو جدول بيانات واحد للمواقع الصغيرة. وأسوأ نمط مضاد في hreflang هو صيانة الوسوم يدويًا لكل صفحة. ما إن ينحرف قالب لغة ومنطقة واحدة، تغيب روابط الإرجاع وتُسقط الأزواج.

3. لا تجمع الطرق. يمكنك تشغيل الطرق الثلاث كلها، لكن Google تقول إن لا فائدة في ذلك، وكل طريقة إضافية سطح آخر قد تختلف فيه النسخ الثلاث بعضها عن بعض.

Evidence for this claim Google requires fully qualified alternate URLs and reciprocal links, and recommends including each page itself in its alternate set. Scope: Google Search hreflang rules shared by all delivery methods. Confidence: high · Verified: Google: Hreflang guidelines

الطريقة 1 — وسوم HTML من نوع <link> داخل <head>

الصياغة، كما توردها Google حرفيًا:

<link rel="alternate" hreflang="lang_code" href="url_of_page" />

مجموعة عملية كاملة لعنقود متعدد اللغات والمناطق مع خيار احتياطي:

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

توضع هذه الكتلة نفسها على كل صفحة في العنقود، أي الصفحة الأمريكية والبريطانية والألمانية والصفحة الرئيسية، وتضم كل منها سطر الإشارة الذاتية الخاص بها. وهذا ما يحقق التبادلية.

الموضع قاعدة صارمة. تقول Google: “The <link> tags must be inside a well-formed <head> section of the HTML.” (الترجمة العربية) «يجب أن تكون وسوم <link> داخل قسم <head> سليم البنية في HTML». وتنصح عند استكشاف المشكلات: “If in doubt, paste code from your rendered page into an HTML validator to ensure that the links are inside the <head> element.” (الترجمة العربية) «عند الشك، الصق شيفرة الصفحة المعروضة في مدقق HTML للتأكد من وجود الروابط داخل عنصر <head>».

هذا أهم مما يبدو بسبب حالة إخفاق تتجاوزها معظم الأدلة المكتوبة: قد تُدفع وسوم hreflang خارج <head> إلى <body>، فتغدو غير صالحة. أشرت إلى ذلك مباشرة في شرائح Pubcon Vegas لعام 2019. لا يمكن للوسوم أن تقع في body بصورة مشروعة، وإلا استطاع موقع اختطاف بدائل موقع آخر؛ لكن وسم <p> مشوهًا أو محقونًا أو iframe قد يغلق <head> مبكرًا، فيُعرض كل ما بعده، بما فيه hreflang، داخل <body>. يكون الوسم موجودًا تقنيًا في المصدر لكنه غير صالح بصمت. وأسرع طريقة لتصحيح ذلك نقاط توقف DOM في المتصفح: راقب موضع الوسوم الفعلي في DOM المعروض، ثم ارجع إلى الترميز الذي كسر <head>.

تناسب وسوم HTML المواقع الصغيرة والمتوسطة ذات العدد المقبول من اللغات والمناطق، حيث لا تتضخم كتلة <link> في كل صفحة. أما الموقع الذي يضم عشرات اللغات والمناطق فتحمل كل صفحة فيه كتلة ترميز كبيرة، وهذا أحد أسباب اعتماد المواقع الكبيرة على طريقة خريطة الموقع.

لا تمزج hreflang مع سمات alternate أخرى في عنصر <link> نفسه. توضح إرشادات Google أن <link rel="alternate"> الذي يحمل hreflang يجب ألا يحمل سمة بديلة غير ذات صلة مثل media في الوسم نفسه. إذا احتجت إلى بديل لغة/منطقة وبديل استعلام وسائط للعنوان نفسه، فاستخدم عنصري <link> منفصلين، لا عنصرًا واحدًا مدمجًا. يسهل أن ينتج عن المزج وسم لا تستطيع Google تحليله لأي من الغرضين.

الطريقة 2 — ترويسات HTTP من نوع Link:

المعلومات نفسها، لكنها تُرسل في استجابة HTTP بدل HTML. الصياغة:

Link: <https://example.com/file.pdf>; rel="alternate"; hreflang="en",
      <https://de-ch.example.com/file.pdf>; rel="alternate"; hreflang="de-ch"

لاحظ الأقواس الزاوية حول كل عنوان URL، والسمات المفصولة بفواصل منقوطة، والفاصلة التي تفصل كل بديل. يُلحق كل عنوان URL في الترويسة بفاصلة.

متى تحتاج إليها: للموارد غير المكتوبة بـHTML. لا يحتوي PDF أو ملف .doc أو صورة تُخدم مباشرة على <head> يحمل وسوم <link>، ولذلك تكون الترويسة وسيلتك الوحيدة لربط hreflang بها.

اعتبارات الإعداد: تضبط هذه الترويسات في طبقة الخادم أو CDN، مثل تعليمة Apache من نوع Header، أو add_header في Nginx، أو قاعدة ترويسة استجابة في Cloudflare/Fastly/CloudFront، أو استجابة التطبيق. ولأن البنية التحتية تضبط الترويسة بدل ترميز كل مستند، يسهل كسر قاعدة التبادلية هنا؛ فعادة ما تُضبط ترويسة PDF الإنجليزي والألماني بصورة منفصلة. لذلك عليك التأكد من أن كل واحدة تسرد المجموعة كاملة، بما فيها نفسها. اجعل توليد الترويسة معتمدًا على جدول اللغات والمناطق نفسه المستخدم في HTML أو خريطة الموقع.

الثابت الذي يجب الحفاظ عليه: تحمل كل استجابة بديلة المجموعة الكاملة المتطابقة في كل مرة. لا يكفي أن تسرد ترويسة PDF الإنجليزي البديل الألماني؛ بل يجب أن تحمل استجابة PDF الألماني المجموعة نفسها في الاتجاه المعاكس، أي نفسه وكل بديل آخر، في كل استجابة لا أول استجابة يصادفها الزاحف وحدها. تعامل مع الترويسة كمخرج مولد، لا إعداد منفرد تضبطه ثم تنساه.

الطريقة 3 — إشارات <xhtml:link> في خريطة موقع XML

على نطاق واسع يكون هذا عادة الاختيار الصحيح: يعيش العنقود كله في ملف أو بضعة ملفات تولدها الآلة، ولا يتضخم <head> في كل صفحة، ولأن رسم العلاقات كله في موضع واحد تكون هذه أسهل طريقة بفارق كبير لضمان الجودة. الصياغة:

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
  xmlns:xhtml="http://www.w3.org/1999/xhtml">
  <url>
    <loc>https://www.example.com/english/page.html</loc>
    <xhtml:link rel="alternate" hreflang="de"
                href="https://www.example.de/deutsch/page.html"/>
    <xhtml:link rel="alternate" hreflang="en"
                href="https://www.example.com/english/page.html"/>
  </url>
  <url>
    <loc>https://www.example.de/deutsch/page.html</loc>
    <xhtml:link rel="alternate" hreflang="de"
                href="https://www.example.de/deutsch/page.html"/>
    <xhtml:link rel="alternate" hreflang="en"
                href="https://www.example.com/english/page.html"/>
  </url>
</urlset>

أمران يوقعان الناس في الخطأ عند استخدام خريطة الموقع:

  1. إعلان نطاق الأسماء إلزامي. لا يمثل xmlns:xhtml="http://www.w3.org/1999/xhtml" في عنصر <urlset> زخرفة اختيارية؛ إذا حذفته أصبح كل <xhtml:link> في الملف غير صالح.
  2. يجب أن تكون كل كتلة <url> مكتملة ذاتيًا. لاحظ أن كتلتي <url> أعلاه تسردان البديلين مع <loc> الخاص بكل منهما. يحمل كل مدخل <url> المجموعة الكاملة: الإشارة الذاتية وكل البدائل. والتبادلية في خريطة الموقع تعني ببساطة أن «تسرد كتلة كل عنوان URL جميع عناوين URL في العنقود، بما فيها نفسها».

هناك سلوكان يفيد فهمهما كي لا تبالغ في هندسة المولد: لا تبالي Google بترتيب أبناء <xhtml:link> داخل كتلة <url>، فلا تهدر الوقت في فرزها، كما لا تُحتسب إشارات <xhtml:link> ضمن حد خريطة الموقع البالغ 50 000 عنوان URL لكل ملف؛ لأنها أبناء مدخل <url> وليست مدخلات <url> مستقلة.

التوليد برمجيًا. الهدف كله من طريقة خريطة الموقع أن تكون نتيجة ثانوية لبيانات الترجمة في CMS. إذا كان CMS يعرف مسبقًا أن /english/page.html و/deutsch/page.html ترجمتان إحداهما للأخرى، فعلى مولد خريطة الموقع اجتياز جدول العلاقات وإصدار كتل <xhtml:link> وقت البناء أو عند طلب الخريطة. عندئذ لا يستطيع hreflang الانحراف عن الواقع؛ إذ يُعاد توليده من مصدر الحقيقة كل مرة، وتصبح إضافة لغة ومنطقة تغييرًا في البيانات لا تعديلًا يدويًا عبر مئات الصفحات.

للفرق التي لا تملك موارد تطوير، أنشأت قالب Google Sheets خفيفًا في دليل Ahrefs لـhreflang: تبويب Setup لاختيار لغة افتراضية وما يصل إلى أربعة بدائل، وتبويب URLs للصق عناوين كل لغة في أعمدة، وتبويب Results يولد كتلة XML لخريطة الموقع تلقائيًا. إنه تجسيد لفكرة «مصدر حقيقة واحد» في المواقع التي لا تبرر تكاملًا حقيقيًا مع CMS.

القواعد التي تنطبق أيًا كانت الطريقة

هذه القواعد مستقلة عن الطريقة ولا تقبل التفاوض.

  • الإشارة الذاتية. تسرد كل صفحة، أو كتلة <url>، أو ترويسة نفسها. يصف Mueller ذلك بأنه اختياري لكنه ممارسة جيدة، وقد غاب في 18,0 % من النطاقات في دراستي؛ أتمته فلا يكلفك شيئًا.
  • التبادلية. “Each language version must list itself as well as all other language versions.” (الترجمة العربية) «يجب أن تسرد كل نسخة لغوية نفسها وسائر النسخ اللغوية». وتوضح Google التنفيذ: “If two pages don’t both point to each other, the tags will be ignored. This is so that someone on another site can’t arbitrarily create a tag naming itself as an alternative version of one of your pages.” (الترجمة العربية) «إذا لم تشر الصفحتان كل منهما إلى الأخرى، فستُتجاهل الوسوم. يمنع ذلك شخصًا في موقع آخر من إنشاء وسم اعتباطيًا يسمي موقعه نسخة بديلة من إحدى صفحاتك». يسقط رابط إرجاع واحد مفقود الزوج.
  • عناوين URL مطلقة ومكتملة. “Alternate URLs must be fully-qualified, including the transport method (http/https)” (الترجمة العربية) «يجب أن تكون عناوين URL البديلة مكتملة، بما فيها طريقة النقل (http/https)»؛ أي https://example.com/foo لا //example.com/foo أو /foo. ويجب أن يطابق URL بدقة الشكل الذي تفهرسه Google: البروتوكول وwww والشرطة المائلة الختامية وحالة الأحرف، وإلا أخفقت مطابقة رابط الإرجاع.

استخدام الرموز الصحيحة

تبدأ سمة hreflang برمز اللغة وفق ISO 639-1، وقد يتبعه رمز اختياري للمنطقة وفق ISO 3166-1 Alpha 2. اجمعهما بشرطة: en-US. يمكنك استهداف لغة وحدها (es تعني الإسبانية في كل مكان)، لكن لا يمكنك استهداف منطقة وحدها؛ فاللغة تأتي أولًا دائمًا.

الأخطاء التي أراها أكثر من غيرها، وظهرت كذلك في بيانات الدراسة:

  • en-UK بدل en-GB؛ فـuk تعني الأوكرانية ورمز منطقة المملكة المتحدة هو gb.
  • jp بدل ja لليابانية، وcn بدل zh للصينية.
  • رموز من ثلاثة أحرف (ger وeng) حيث يلزم رمز ISO 639-1 من حرفين.
  • استخدام EU أو UN أو UK رموزًا للمناطق؛ فلا يمثل أي منها هدفًا صالحًا وفق ISO 3166-1 alpha-2.

x-default هو القيمة المحجوزة للخيار الاحتياطي، مثل محدد لغة أو صفحة رئيسية تعيد التوجيه تلقائيًا وتخدم المستخدمين الذين لا يطابقون أيًا من اللغات والمناطق الصريحة:

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

إنه غير إلزامي. كان العنصر الأكثر غيابًا في دراستي، إذ حذفته 56,3 % من النطاقات، لكن غياب x-default لا يكسر العنقود مثل غياب وسم تبادلي؛ بل تعود Google إلى اكتشاف اللغة والمنطقة بنفسها للمستخدمين غير المطابقين. أضفه على أي حال؛ فهو بند في قائمة التحقق لا ما يكسر العنقود. ويوجد موضوع فرعي مخصص لـx-default في هذا العنقود.

التنفيذ على نطاق واسع — أساليب CMS والمنصات

WordPress. لا يولد Yoast SEO وسوم hreflang بمفرده. لإخراج الوسوم فعليًا تحتاج إلى إضافة متعددة اللغات مثل WPML أو Polylang. يولد WPML hreflang تلقائيًا لكل صفحة لها ترجمات، ويضيف x-default يشير إلى نسخة اللغة الافتراضية، ويدرج الإشارات افتراضيًا في خريطة موقع XML. ويوجد إعداد في WPML ← Languages ← SEO Options باسم “Display alternative languages in the HEAD section” إذا أردت إخراج وسوم الرأس بدل خريطة الموقع أو إضافة إليها. راجع وثائق WPML لاستخدامه مع Yoast.

Shopify. يولد Shopify Markets وسوم hreflang مترابطة تبادليًا تلقائيًا بعد إعداد الأسواق واللغات ونشر المحتوى وربطه في التنقل، فيزيل بتصميمه أكثر حالات الإخفاق شيوعًا، وهي غياب الروابط المتبادلة. لكن وسوم Markets التلقائية تكون غالبًا للغة فقط (fr وde) لا للغة والمنطقة (fr-FR وfr-CA)، وهذا لا يكفي للعلامات التي تحتاج تحديدًا إقليميًا، مثل الفرنسية لفرنسا وكندا وبلجيكا. عندئذ تستخدم وسوم <link> يدوية في theme.liquid، وتعرض وثائق Shopify لـhreflang في القالب النمط، أو تستخدم تطبيقًا. انتبه لأن مزج وسوم Markets التلقائية مع الوسوم اليدوية أو وسوم التطبيق مصدر موثق للتعارض. اختر طريقة واحدة.

مخصص / headless / مؤسسات. ولّد الإشارات من جدول علاقات الترجمة وقت البناء أو الخدمة، كما في قسم خريطة الموقع أعلاه. إنه مبدأ «مصدر حقيقة واحد» نفسه؛ إذ يصبح hreflang مخرجًا محسوبًا من بيانات يحملها CMS بالفعل، لا أثرًا يُصان يدويًا ويتدهور.

أخطاء تنفيذ تكسر العنقود

إعادة التوجيه التلقائية حسب الموقع الجغرافي/IP. هذا إخفاق مختلف عن أخطاء الصياغة وهو أسوأ. إذا أعدت توجيه الزوار، ولا سيما الزواحف، إلى نسخة استنادًا إلى الموقع المتوقع، فقد تزيل عناقيد إقليمية كاملة من الفهرسة لأن Googlebot يزحف غالبًا من الولايات المتحدة. وكما قلت في شرائح Pubcon: “would redirect search engines to where they crawl from. Google for instance mostly crawls from the US so we would effectively de-index all geo pages.” (الترجمة العربية) «سيعيد ذلك توجيه محركات البحث إلى المكان الذي تزحف منه؛ فـGoogle مثلًا تزحف غالبًا من الولايات المتحدة، ولذلك سنزيل فعليًا كل الصفحات الجغرافية من الفهرسة». وهناك جانب تنظيمي أيضًا، هو التعرض المحتمل لقواعد الاتحاد الأوروبي المناهضة للحجب الجغرافي. النمط الصحيح هو أعد توجيه المستخدمين ولا تعِد توجيه الزواحف قط: اكتشف الزوار البشر وأعد توجيههم اختياريًا، لكن دع الروبوتات تصل إلى كل نسخة URL مباشرة، واجعل hreflang يحمل إشارة التوجيه. توصي إرشادات Google للمواقع متعددة المناطق بشريط اقتراح غير مزعج بدل إعادة التوجيه التلقائية لهذا السبب تحديدًا.

توجيه hreflang إلى عناوين URL غير أساسية أو معاد توجيهها أو تحمل noindex. إذا تغير عنوان لغة ومنطقة وأضيفت إعادة التوجيه لكن hreflang ظل يشير إلى العنوان القديم، أصبح العنقود يشير إلى 301 أو 404؛ وقد أشارت 16,9 % من النطاقات في دراستي إلى صفحات معطلة أو معاد توجيهها. وبالمثل يجب أن تجعل كل نسخة نفسها رابطًا أساسيًا؛ فتوجيه hreflang إلى عنوان تستبعده عملية تحديد الأساسي، أو إلى صفحة تحمل noindex، يكسر رابط الإرجاع، وقد أشارت 8,0 % إلى عناوين غير أساسية.

صيغ URL غير المتسقة. يجب أن يتطابق عنوان hreflang والعنوان المفهرس بايتًا ببايت في الشكل، بما فيه الشرطة المائلة الختامية وwww والبروتوكول وحالة الأحرف. يؤدي عدم التطابق إلى إخفاق صامت في التبادلية.

التحقق من التنفيذ بعد الإطلاق

اعرض المصدر المعروض، لا المصدر الخام وحده. إذا حقنت JavaScript وسوم hreflang، فلن يعرض curl أو Ctrl+U، أي “View Page Source”، شيئًا، لكن الوسوم موجودة في DOM المعروض. أكد ذلك عبر GSC URL Inspection ← “Test Live URL” ← “View Tested Page”، أو باستخدام زاحف قادر على العرض. وهذا أكثر سبب يجعل شخصًا يقول «وسومي مفقودة» وهي سليمة، أو العكس: موجودة في المصدر لكنها معطلة لأنها تُعرض داخل <body>.

ازحف إلى العنقود كله ولا تفحص عنوان URL واحدًا. التبادلية علاقة بين الصفحات، ولذلك لا يخبرك فحص صفحة واحدة إلا بالقليل. شغّل زاحفًا عبر العنقود كله، مثل تدقيق hreflang في Screaming Frog أو Ahrefs Site Audit، لاكتشاف وسوم الإرجاع المفقودة والأهداف غير الأساسية والمراجع المعطلة على نطاق واسع. يرسم تبويب Hreflangs في Ahrefs Site Audit العنقود كرسم بياني بروابط معطلة حمراء، وهو أسهل بكثير في الفهم من CSV.

تحقق من نتائج البحث الحقيقية باستخدام &hl= و&gl=. ألحق معاملي لغة المضيف (&hl=) والموقع الجغرافي (&gl=) بعنوان بحث Google لمعاينة شكل نتائج لغة ومنطقة بعينها فعليًا بدل التخمين من موقعك.

التحقق ليس خطوة لمرة واحدة. اللغات والمناطق الجديدة وتغييرات URL أو إعادة التوجيه وتسرب إعدادات التطوير/الاختبار/التجهيز إلى الإنتاج أسباب متكررة للأعطال بعد الإطلاق. أدرج فحوص hreflang في اختبارات الانحدار وعمليات الزحف الدورية، لا في ضمان جودة يوم الإطلاق وحده. وصفت ذلك في المحاضرات: “any number of things can break from masking to things carrying over from dev/test/staging environments.” (الترجمة العربية) «قد يتعطل أي عدد من الأشياء، بدءًا من الإخفاء ووصولًا إلى ما ينتقل من بيئات التطوير والاختبار والتجهيز».

خرافات ينبغي إحالتها إلى التقاعد

  • «تعالج خرائط الموقع أسرع من وسوم HTML». خطأ. يُحل كلاهما وقت الزحف، وقد دحضت ذلك مباشرة. ميزة خريطة الموقع هي سهولة الصيانة وضمان الجودة، لا السرعة.
  • «لا تدعم Yandex hreflang في خرائط الموقع». خطأ؛ تؤكد وثائق Yandex دعم hreflang في خرائط الموقع.
  • «استخدم الطرق الثلاث للحصول على إشارة إضافية». لا فائدة وفق Google، وهذا يضاعف فقط مخاطر عدم الاتساق.
  • «غياب x-default يكسر العنقود». خطأ؛ فهو اختياري وتعود Google إلى اكتشافها الخاص.
  • «hreflang الخاطئ يعرضك لعقوبة». خطأ؛ إنه تلميح لا توجيه ملزم. يُتجاهل hreflang المعطل ولا يعاقب عليه.

إلى أين تنتقل بعد ذلك

هذا المقال هو العمق العملي تحت مركز hreflang؛ يغطي المركز ماهية hreflang وأهمية التبادلية وما تستخدمه Bing بدلًا منه. ويتعمق موضوع x-default الفرعي في القيمة الاحتياطية. وللاستراتيجية التي ينفذها ذلك، راجع ركيزة SEO الدولي؛ فـhreflang هو الطبقة التقنية لا بديلًا من التوطين الحقيقي.

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.