كيفية حل الأخطاء المتكررة في علامات hreflang للمواقع متعددة اللغات

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

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

حدّد أولًا: هل تحتاج صفحتك فعلًا إلى hreflang؟

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

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

وخاصةً في مواقع B2B للتجارة الخارجية، من المفاهيم الخاطئة الشائعة توجيه جميع إصدارات اللغات إلى الصفحة الرئيسية، أو جعل كل صفحة تفاصيل منتج تشير فقط إلى إصدار اللغة للصفحة الرئيسية. يجب أن تُبنى hreflang على علاقة «صفحة بصفحة»: ينبغي أن ترتبط الصفحة الإنجليزية للمنتج A بالصفحات الألمانية أو الفرنسية أو اليابانية للمنتج A، لا أن ترتبط بشكل عام بالصفحات الرئيسية لكل اللغات.

الخطأ الأكثر شيوعًا: العلامات المتبادلة لا تشكل حلقة مكتملة

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

تتضمن مجموعة الصفحات المؤهلة عادةً ثلاث طبقات من العلاقات:

• تعلن كل صفحة إصدار لغتها الخاص، أي self-referencing hreflang؛
• تشير كل صفحة إلى إصدارات اللغة أو المنطقة الأخرى للمحتوى نفسه؛
• تبقى مجموعة عناوين URL المدرجة في جميع صفحات المجموعة نفسها متسقة.

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

لا تقوم بعض أنظمة CMS عند إضافة لغة جديدة إلا بتحديث الصفحة الحالية، ولا تُنشئ روابط جديدة بصورة متزامنة في صفحات اللغات القديمة؛ كما تحتفظ بعض المواقع بعناوين قديمة في علامات head للصفحات بعد ترحيل النطاق أو تعديل قواعد URL، رغم تحديث hreflang في خريطة الموقع. يؤدي ذلك إلى مشكلات مثل «غياب الرابط العائد» أو «تعذر تأكيد الصفحة البديلة».

صحة رمز اللغة لا تعني صحة رمز المنطقة أيضًا

تستخدم قيمة hreflang عادةً رمز اللغة، مع إضافة رمز المنطقة عند الحاجة، مثلen وde وfr-CA وes-MX. وتظهر المشكلة غالبًا عند الخلط بين اللغة والدولة والسوق.

يمكن للصفحة الألمانية الموجهة إلى المستخدمين في ألمانيا استخدامde-DE، ويمكن للصفحة الألمانية الموجهة إلى النمسا استخدام de-AT. ولكن إذا كان محتوى الصفحتين وأسعارهما وطريقة التسليم فيهما متطابقة تمامًا، ولم تُنسخ الصفحات إلا لتغطية دول مختلفة، فإن التقسيم القسري إلى إصدارات مناطق متعددة قد لا يحقق فائدة، بل يزيد من تعقيد الصيانة وتقييم المحتوى المكرر.

وعلى العكس، إذا كانت الصفحات الإنجليزية تخدم الولايات المتحدة والمملكة المتحدة على التوالي، وكانت العملة أو وحدات القياس أو شروط الخدمة أو معلومات الاتصال مختلفة، فينبغي استخدامen-US وen-GB بوضوح. كما أن استخدام en فقط ليس خطأً، لكنه يشير إلى إصدار عام «يناسب جميع المستخدمين الناطقين بالإنجليزية» ولا يمكنه التمييز بدقة بين إصدارات المناطق.

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

عند تكرار الأخطاء، تحقّق أولًا مما إذا كان URL قابلًا للفهرسة

لا تقبل محركات البحث عناوين URL الخاصة بـ hreflang التي «تبدو موجودة لكنها غير قابلة للاستخدام فعليًا». ينبغي أن يعرض كل عنوان ضمن العلامات صفحة رسمية متاحة، لا صفحة إعادة توجيه أو صفحة 404 أو صفحة يمنع robots الزحف إليها أو صفحة تحتوي على noindex.

تشيع الحالات التالية بشكل خاص في المواقع متعددة اللغات:

• لا تزال hreflang تستخدم عناوين http، بينما انتقل الموقع بالكامل إلى HTTPS؛
• يحتوي URL على معلمات جلسة أو تتبع أو تصفية، بينما يشير canonical إلى عنوان آخر؛
• بعد أن يصل المستخدم إلى URL بلغة معينة، تُجبره قواعد IP أو قواعد لغة المتصفح على إعادة التوجيه إلى لغة أخرى؛
• تم إيقاف الصفحة أو إعادة تصميمها، بينما لا تزال العلامات تشير إلى رابط المنتج القديم؛
• يشير canonical لصفحة لغة معينة إلى الصفحة الإنجليزية، ما يجعل محركات البحث تعدها صفحة مكررة بدلًا من إصدار مستقل.

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

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

اختر طريقة تنفيذ واحدة لتجنب تغطية المصادر المتعددة بعضها بعضًا

يمكن وضع hreflang في head لصفحة HTML، كما يمكن إرسالها عبر XML Sitemap؛ ويمكن لبعض الملفات غير HTML أيضًا استخدام رؤوس استجابة HTTP. بالنسبة لمعظم مواقع الشركات والمتاجر العابرة للحدود، يكفي استخدام HTML head أو Sitemap؛ فالمهم ليس تعدد الطرق، بل توحيد مصدر البيانات وتزامن التحديثات.

إذا كانت head للصفحة وSitemap وإضافة الخلفية تُخرج hreflang في الوقت نفسه وكانت محتوياتها غير متسقة، فسيصبح استكشاف الأخطاء وإصلاحها صعبًا للغاية. على سبيل المثال، قد تشير الروابط داخل الصفحة إلى URL جديد، بينما تحتفظ خريطة الموقع بـ URL قديم، ولا تتعرف إضافة SEO خارجية إلا على بعض اللغات، فتتشكل في النهاية مجموعة من العلاقات التي تبدو «معلّمة جميعها» ولكن يتعذر التحقق منها فعليًا.

عندما يكون حجم الموقع صغيرًا وإصدارات لغات الصفحات مستقرة، يكون إنشاء العلامات في head أكثر وضوحًا؛ أما المتاجر أو مواقع المحتوى ذات SKU الكثيرة واللغات المتعددة والتحديثات الجماعية المتكررة، فهي أنسب لإنشاء XML Sitemap من مصدر بيانات موحد. وبغض النظر عن الطريقة المستخدمة، ينبغي صيانة علاقات اللغة والمنطقة والصفحات كجزء من بيانات الموقع، لا الاعتماد على نسخ العلامات يدويًا من قبل موظفي التشغيل.

تحقق باستخدام «مجموعة صفحات واحدة» بدلًا من الإصلاح العشوائي للموقع بأكمله

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

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

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