هندسة تحسين محركات البحث متعددة اللغات: Hreflang والروابط...

عندما يقدم موقع ويب محتوى بعدة لغات أو يستهدف عدة دول، تصبح البنية الأساسية عاملاً حاسماً في ظهوره في نتائج البحث. لقد رأينا عملاء يفقدون شهوراً من مكاسب التصنيف لأنهم خلطوا بين تحسين محركات البحث *متعدد اللغات* و*متعدد الجنسيات*، أو لأنهم طبقوا hreflang كفكرة لاحقة. في DigiForge، نتعامل مع البنية الدولية كطبقة أساسية - تماماً مثل الاستضافة وHTTPS. يشرح هذا المقال الأركان الثلاثة لتلك البنية: استراتيجية عناوين URL، وتنفيذ hreflang، وإدارة canonical. وسنتطرق أيضاً إلى سير عمل الفريق لأنه حتى أفضل إعداد تقني ينهار دون تنسيق جيد.

متعدد اللغات مقابل متعدد الجنسيات: اعرف الفرق

قبل الغوص في الخيارات التقنية، من الضروري التمييز بين تحسين محركات البحث متعدد اللغات ومتعدد الجنسيات. كما يشرح Search Engine Land، يركز تحسين محركات البحث متعدد اللغات على تقديم المحتوى بلغات مختلفة، غالباً لمستخدمين في عدة دول يتحدثون نفس اللغة. أما تحسين محركات البحث متعدد الجنسيات، فيستهدف دولاً مختلفة بمحتوى قد يكون بنفس اللغة لكنه مُكيَّف للتفضيلات المحلية أو اللوائح أو العملات. قد يستخدم موقع متعدد اللغات بنية URL واحدة لجميع الناطقين بالفرنسية، بينما قد يحتاج موقع متعدد الجنسيات إلى نسخ منفصلة لفرنسا وكندا وسويسرا - حتى لو كانت اللغة واحدة. فهم هذا التمييز يشكل نموذج URL واستراتيجية hreflang الخاصة بك منذ البداية.

استراتيجية URL: النطاقات الفرعية، الأدلة الفرعية، ونطاقات المستوى الأعلى لرمز الدولة

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

نطاقات المستوى الأعلى لرمز الدولة (ccTLDs)

نطاق ccTLD مثل example.fr أو example.de يرسل أقوى إشارة استهداف جغرافي. تربط محركات البحث النطاق بتلك الدولة، ويثق به المستخدمون غريزياً. الجانب السلبي هو التعقيد التشغيلي: كل ccTLD هو نطاق منفصل، لذا تحتاج إلى شهادات SSL منفصلة، وتكوينات استضافة منفصلة، ولا تتدفق قيمة الروابط بينها. بالنسبة لشركة تطلق موقعها في سوقين أو ثلاثة فقط، قد يكون هذا مقبولاً. أما لثلاثين سوقاً، فيصبح كابوساً صيانياً. علاوة على ذلك، إذا كان المحتوى الخاص بك متطابقاً عبر ccTLDs (مثلاً، موقع علامة تجارية عالمي)، فإنك تخفف السلطة وتجبر برامج الزحف على اكتشاف كل نطاق بشكل مستقل.

النطاقات الفرعية

نمط النطاق الفرعي مثل fr.example.com أسهل في الإدارة من نطاقات ccTLD، لكنه لا يزال يقسم الموقع من منظور الزاحف. تعامل Google النطاقات الفرعية ككيانات منفصلة، لذا فإن رصيد الروابط من النطاق الرئيسي لا ينتقل تلقائيًا إلى النطاق الفرعي. تحتاج أيضًا إلى إعداد خصائص تحليلات منفصلة وقد تواجه مشكلات في نطاق ملفات تعريف الارتباط. ومع ذلك، يمكن أن تكون النطاقات الفرعية مفيدة للإصدارات اللغوية التي تختلف اختلافًا جذريًا في المحتوى أو ملكية الفريق — على سبيل المثال، إذا كان فريقك الألماني يعمل بشكل مستقل ويدير مجموعته التقنية الخاصة. لكن بالنسبة لمعظم المشاريع، نجد أن النطاقات الفرعية تقدم احتكاكًا غير ضروري.

الدلائل الفرعية (أو المجلدات الفرعية)

توصيتنا الافتراضية في DigiForge هي نهج الدليل الفرعي: example.com/fr/ أو example.com/de/. كل المحتوى يعيش تحت نفس النطاق الجذري، لذا يتراكم رصيد الروابط بشكل طبيعي، وتكون التحليلات موحدة، ويكون SSL شهادة واحدة. تستخدم Google أيضًا مسار الدليل الفرعي كإشارة استهداف جغرافي عند إقرانه بـ hreflang ووسوم meta. الخطر الرئيسي هو أن شجرة الدلائل الفرعية سيئة التنظيم يمكن أن تخفف من السلطة الموضوعية للنطاق الجذري، لكن في الممارسة العملية هذا نادر إذا حافظت على نظافة مجلدات اللغة واستخدمت روابط داخلية مناسبة. هيكل الدليل الفرعي المنظم جيدًا يبسط أيضًا التوسع الدولي — إضافة لغة جديدة هو مجرد مجلد جديد مع تعليقات hreflang الخاصة به.

لا توجد إجابة واحدة تناسب الجميع. إذا كنت تستهدف اليابان فقط من نطاق .jp، فقد يكون ccTLD يستحق الجهد الإضافي. لكن إذا كنت تخدم الناطقين بالفرنسية في كندا وسويسرا وفرنسا، فإن مجلد /fr/ واحد مع تعليقات hreflang لكل منطقة هو أكثر كفاءة من ثلاثة نطاقات منفصلة. المفتاح هو ربط أهداف عملك بالنموذج التقني مبكرًا — وتوثيق القرار.

تنفيذ Hreflang: الجزء الأكثر صعوبة

يخبر Hreflang محركات البحث أي إصدار لغة أو إقليم من الصفحة يجب عرضه في موقع معين. من المعروف أنه من السهل ارتكاب الأخطاء فيه. الخطأ الأكثر شيوعًا هو استخدام hreflang كبديل لوسوم canonical — فهي تخدم أغراضًا مختلفة — أو حذف إدخالات hreflang المرجعية الذاتية. خطأ متكرر آخر هو رموز اللغة-الإقليم غير المتطابقة: على سبيل المثال، استخدام en-uk بدلاً من en-GB. غالبًا ما تمر هذه الأخطاء دون أن يلاحظها أحد حتى ينخفض الزيارات.

الصيغة والموضع

لديك ثلاثة خيارات لتحديد تعليقات hreflang: في HTML <head> كعناصر <link>، في رأس HTTP (للملفات غير HTML مثل PDF)، أو في خريطة موقع XML. نحن نفضل بشدة طريقة خريطة المواقع للمواقع التي تحتوي على أكثر من عدد قليل من الإصدارات اللغوية، لأنها تبقي الترميز خارج HTML وتجعل التدقيق أسهل. أيًا كانت الطريقة التي تختارها، يجب أن يتضمن كل إصدار لغة رابطًا يعود إلى نفسه وإلى جميع الإصدارات الأخرى. يشمل ذلك الصفحة الافتراضية أو الاحتياطية، والتي يجب أن تستخدم x-default. لا تتخط أبدًا الرابط المرجعي الذاتي — تعتمد محركات البحث على الطبيعة المتبادلة لـ hreflang لتأكيد العلاقة. بدونه، قد تتجاهل التعليق بالكامل.

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

مأزق شائع: حذف الرابط المرجعي الذاتي. تعتمد محركات البحث على الطابع المتبادل لـ hreflang لتأكيد العلاقة. وبدونه، قد تتجاهل التعليق بالكامل. احرص دائمًا على تضمين رابط من كل صفحة إلى نفسها.

رموز اللغة والمنطقة

استخدم رموز اللغة وفقًا لمعيار ISO 639-1 (مثل en وfr) وعند الحاجة، رموز المنطقة وفقًا لمعيار ISO 3166-1 alpha-2 (مثل en-GB وfr-CA). رمز المنطقة اختياري لكنه ضروري عندما تختلف اللغة نفسها حسب البلد — على سبيل المثال، en-US مقابل en-GB. لا تخمن الرموز أبدًا؛ ابحث عنها. حتى الخطأ المطبعي الصغير (مثل en-gb بأحرف صغيرة) يمكن أن يعطل التعليق. لاحظ أيضًا أن x-default ضروري للصفحات غير المخصصة للغة معينة، مثل صفحة البداية. وبدونه، قد يرى المستخدمون نسخة لغة غير مقصودة.

معالجة المحتوى المتطابق تقريبًا

عندما يكون المحتوى متماثلًا بشكل أساسي عبر اللغات (مثل صفحة علامة تجارية عالمية مع تغييرات لغوية فقط)، فإن hreflang وحده كافٍ — لا تحتاج إلى علامات canonical منفصلة لكل متغير. ولكن إذا كانت لديك صفحة باللغة الإنجليزية وصفحة باللغة الفرنسية تغطيان نفس الموضوع ولكن كُتبتا بشكل مستقل، فيجب أن تحتوي كل صفحة على canonical مرجعي ذاتي يشير إلى عنوان URL الخاص بها، ويجب أن يربط hreflang بينهما كبدائل. تتعايش canonical وhreflang؛ لا تلغي إحداهما الأخرى. من المفاهيم الخاطئة الشائعة أن hreflang تعني علاقة canonical — وهذا غير صحيح. إنهما إشارتان متعامدتان.

علامات Canonical عبر اللغات: توازن دقيق

تخبر علامة canonical محركات البحث أي نسخة من الصفحة هي الموثوقة عند وجود نسخ مكررة. في سياق متعدد اللغات، غالبًا ما ينشأ الارتباك: بعض الفرق تضع canonical لجميع المتغيرات اللغوية على عنوان URL للغة الافتراضية. هذا خطأ دائمًا تقريبًا. فهو يخبر Google أن الصفحة الفرنسية هي نسخة مكررة من الصفحة الإنجليزية ولا ينبغي فهرستها. النتيجة: يختفي حركة المرور الفرنسية لديك. لقد قمنا بتدقيق مواقع حيث تم إلغاء فهرسة أقسام لغوية كاملة بسبب هذا الخطأ الوحيد.

النهج الصحيح هو جعل النسخة الأساسية (canonical) لكل لغة تشير إلى نفسها. إذا كان لديك محتوى متطابق حقًا (مثل أوصاف المنتجات التي تترجمها آليًا دون تغييرات)، يمكنك استخدام hreflang للإشارة إلى أنها بدائل — ولكن يجب أن تظل canonical تشير إلى نفسها. تفهم محركات البحث أن الصفحات المرتبطة عبر hreflang ليست مكررة؛ بل هي متغيرات لغوية موجهة لجماهير مختلفة. هناك استثناء شرعي واحد: المحتوى المُوزَّع (syndicated). إذا نشرت نفس المقالة باللغة الإنجليزية على موقعك الرئيسي وباللغة الإسبانية على موقع شريك، يمكنك استخدام رابط الإنجليزية كـ canonical للصفحة الإسبانية — ولكن فقط إذا لم تستخدم hreflang أيضًا. مزج canonical عبر اللغات مع hreflang يرسل إشارات متضاربة. عمليًا، ننصح عملاءنا بتجنب هذا الموقف تمامًا وإنشاء محتوى فريد لكل لغة.

في DigiForge، قمنا مرة بمراجعة موقع حيث كان القسم الألماني بأكمله يشير بـ rel="canonical" إلى النسخة الإنجليزية. كانت الصفحات الألمانية إما غير مفهرسة أو ذات ترتيب ضعيف. إصلاح canonical ليشير إلى نفسه — مع hreflang المناسب — أعاد الصفحات الألمانية إلى الفهرس في غضون أسابيع.

سير عمل الفرق: الحفاظ على حيوية البنية

البنية التقنية ليست سوى نصف المعركة. غالبًا ما يحدد التنسيق بين الفرق في الأسواق المختلفة ما إذا كان التنفيذ سيبقى بعد إعادة التصميم. يوضح Search Engine Journal خطوات عملية لتعزيز التعاون: ابدأ صغيرًا بقناة Slack مشتركة أو مجلد إنترانت حيث يشارك أعضاء الفريق النصائح والرؤى. بمرور الوقت، نم إلى جلسات مشاركة معرفية ربع سنوية أو ورش عمل إقليمية.

وجدنا أن توثيق أفضل ممارسات تحسين محركات البحث — خاصة قواعد hreflang و canonical — في دليل حي يرافق المشروع أمر ضروري. الكثير من المواقع الدولية تتعطل لأن مطورًا في سوق ما يضيف مجلد لغة جديدًا دون تحديث تعليقات hreflang في خريطة الموقع XML. وجود مصدر واحد للحقيقة (مستند مشترك أو ملف تكوين في نظام التحكم بالإصدارات) يقلل هذه الأخطاء بشكل كبير. بالإضافة إلى ذلك، نوصي بإنشاء دليل مركزي لتحسين محركات البحث يمكن الوصول إليه من جميع الأسواق، مع أمثلة على الترميز الصحيح. استخدم فهرس خريطة موقع مشترك يتضمن جميع إصدارات اللغات، يتم تحديثه عبر CI/CD. قم بإعداد اختبارات آلية تتحقق من تبادلية hreflang ومرجعية canonical الذاتية. أخيرًا، عقد اجتماع شهري بين فرق تحسين محركات البحث التقنية والترجمة لاكتشاف الانحرافات مبكرًا.

الأتمتة صديقك. غالبًا ما نكتب نصوصًا برمجية تزحف على خريطة الموقع وتتحقق من أن كل تعليق hreflang متبادل. يمكن لنص بايثون بسيط باستخدام lxml اكتشاف المراجع الذاتية المفقودة أو رموز المناطق المكسورة. قم بدمج هذه الفحوصات في خط أنابيب النشر الخاص بك بحيث لا تصل خريطة موقع خاطئة إلى الإنتاج أبدًا.

import requests
from lxml import etree

# Example check: verify hreflang reciprocity
sitemap_url = 'https://example.com/sitemap.xml'
response = requests.get(sitemap_url)
root = etree.fromstring(response.content)
ns = {'xhtml': 'http://www.w3.org/1999/xhtml'}

urls = {}
for url in root.findall('{http://www.sitemaps.org/schemas/sitemap/0.9}url'):
    loc = url.find('{http://www.sitemaps.org/schemas/sitemap/0.9}loc').text
    alternates = url.findall('xhtml:link', ns)
    for alt in alternates:
        hreflang = alt.get('hreflang')
        href = alt.get('href')
        if href == loc and hreflang:
            # self-reference found
            pass
        else:
            # check if href reciprocates
            pass
# More robust logic needed in practice

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

شبكة متوهجة من العقد المترابطة تمثل روابط hreflang متعددة اللغات على خلفية داكنة — التحقق الآلي من مجموعات hreflang يضمن ربط كل عقدة لغوية بشكل صحيح.

تجميع القطع معًا: إطار استراتيجي

كل موقع متعدد اللغات فريد من نوعه، لكننا وجدنا أن اتباع عملية قرار منظمة يساعد في تجنب الأخطاء الأكثر شيوعًا. ابدأ بتوضيح ما إذا كنت تستهدف اللغات أم الدول أم كليهما. ثم اختر نموذج URL يتناسب مع قدراتك التشغيلية. قم بتطبيق hreflang في خريطة الموقع، وليس في HTML المضمّن، وتأكد من أن كل صفحة تشير canonical إلى نفسها. أخيرًا، استثمر في التواصل بين الفريق والفحوصات الآلية.

إليك قائمة مراجعة سريعة نستخدمها في DigiForge عند التخطيط لبنية متعددة اللغات:

تحديد الجماهير المستهدفة: حسب اللغة أم الدولة أم كليهما؟
اختيار نموذج URL (ccTLD أو نطاق فرعي أو دليل فرعي) وتوثيق السبب.
إعداد hreflang في خرائط الموقع، بما في ذلك x-default والإشارات الذاتية.
التأكد من أن كل صفحة لغة تحتوي على canonical يشير إلى نفسها.
إنشاء دليل أسلوب SEO مشترك وعملية توزيع.
تنفيذ التحقق الآلي في خط أنابيب CI/CD.
مراقبة تغطية الفهرسة في Google Search Console لكل لغة.

المكسب هو موقع تفهمه محركات البحث دون غموض — حيث يحصل مستخدم في كيبيك على النسخة fr-CA، ومستخدم في برلين على النسخة de، ويتراجع الجميع إلى x-default. هذا المستوى من الدقة ليس ترفًا؛ إنه الفرق بين المنافسة عالميًا والبقاء غير مرئي دوليًا.

إذا كنت تخطط لتوسع دولي أو تحتاج إلى فك تشابك إعداد متعدد اللغات قديم، تواصل مع DigiForge. لقد بنينا وراجعنا ما يكفي من هذه البنى لنعرف الاختصارات التي تعمل — وتلك التي تحرق.

هندسة تحسين محركات البحث متعددة اللغات: Hreflang والروابط الأساسية واستراتيجية عناوين URL الحقيقية

متعدد اللغات مقابل متعدد الجنسيات: اعرف الفرق

استراتيجية URL: النطاقات الفرعية، الأدلة الفرعية، ونطاقات المستوى الأعلى لرمز الدولة