بنية sitemap لموقع متعدد اللغات: اللغات وميزانية الزحف
كيف تبني sitemap لموقع متعدد اللغات: ملف لكل لغة أو فهرس واحد، نقل hreflang إلى sitemap، انضباط lastmod، وأي عناوين URL تُترك خارجه.
بقلم Roozbeh Nazari · CEO
ملف sitemap هو الجزء الأقل نقاشًا والأكثر بناءً بشكل خاطئ في SEO التقني. في موقع أحادي اللغة، يكون sitemap المبني بشكل خاطئ عادةً بلا ضرر: Google يجد عناوين URL بطرق أخرى على أي حال. أما في موقع متعدد اللغات، فـ sitemap هو الوثيقة البنيوية الوحيدة التي تقول فيها إن أربع لغات هي أربع مجموعات منفصلة من عناوين URL، وأي عنوان هو النسخة الأساسية لأي لغة، وما الذي لا تريد فهرسته. تصف هذه المقالة كيف نبني بنية sitemap في موقع ينشر بالتركية والإنجليزية والعربية والفارسية، ولماذا اتُّخذ كل قرار.
القواعد أولًا: حدود البروتوكول
يضع بروتوكول sitemap حدين صارمين: يمكن أن يحتوي ملف sitemap الواحد على 50.000 عنوان URL على الأكثر، ولا يجوز أن يتجاوز حجمه 50 ميغابايت غير مضغوط. المواقع التي تتجاوز هذين الحدين مضطرة إلى تقسيم الملف وجمع الأجزاء بملف فهرس sitemap. نادرًا ما يقترب موقع مؤسسي متعدد اللغات من هذه الحدود؛ فموقع من بضع مئات أو بضعة آلاف من عناوين URL يتسع في ملف واحد. ومع ذلك، قرار التقسيم تحدده القابلية للإدارة لا الحجم؛ وسنأتي إلى ذلك أدناه.
القاعدة الثانية من وثائق Google نفسها: يتجاهل Google حقلَي priority وchangefreq في sitemap، ولا يستخدم حقل lastmod إلا حين يكون دقيقًا بشكل متسق. هذا يعني أن كتابة "كل صفحة تتغير كل يوم" في sitemap لا تحقق شيئًا، بينما كتابة التاريخ الذي تغيرت فيه الصفحة فعلًا تحقق ذلك.
ملف واحد، أم ملف لكل لغة
في المواقع الصغيرة والمتوسطة متعددة اللغات نرى ثلاث بنى. الأولى ملف واحد: عناوين URL لكل اللغات في sitemap.xml واحد. بسيط، سهل الإعداد، ولا مشكلة فيه حتى بضعة آلاف من العناوين. نقطة ضعفه أنك لا تستطيع قراءة نسبة الفهرسة لكل لغة في Search Console؛ فالموقع كله يظهر في سطر واحد. الثانية ملف لكل لغة مع فهرس: sitemap-tr.xml وsitemap-en.xml وsitemap-ar.xml وsitemap-fa.xml وملف sitemap.xml يسردها. يقدّم Search Console تقريرًا لكل ملف على حدة؛ فترى أي نسبة من الصفحات العربية مفهرسة مقارنة بالصفحات التركية. الثالثة ملف لكل نوع محتوى: الصفحات ومقالات المدونة والخدمات في ملفات منفصلة. يفيد هذا النموذج حين تريد متابعة سرعة فهرسة مقالات المدونة منفصلة عن الصفحات الثابتة.
تفضيلنا: ملف واحد ما دام الموقع تحت بضع مئات من العناوين، وملف لكل لغة حين يتجاوز ذلك. نقطة القرار ليست الحجم بل الحاجة التشخيصية: في اليوم الذي تبدأ فيه مشكلة فهرسة في لغة ما، ستريد رؤية تلك اللغة في ملف مستقل. شرحنا مسار التشخيص هذا خطوة بخطوة في مقالة مشكلات الفهرسة؛ وتقسيم sitemap هو الأداة الأولى في ذلك المسار.
نقل hreflang إلى sitemap
يقبل Google ثلاث طرق للإعلان عن نسخ اللغة والمنطقة: علامات link في head الصفحة، أو ترويسات HTTP، أو مدخلات xhtml:link داخل sitemap. علامات head شائعة في المواقع متعددة اللغات لكن لها نقطتا ضعف: تنشئ كتلة تتكرر في كل صفحة وتضخّم حجمها، وخطأ القالب ينتشر إلى الموقع كله في وقت واحد. طريقة sitemap تجمع تلك الكتلة في ملف واحد وتسهّل التحقق: يمكنك قراءة الإعلانات المتبادلة للغات الأربع في ملف XML واحد وفحصها بسكربت.
القاعدة بسيطة لكنها كثيرًا ما تُخالف: يجب أن يسرد كل مدخل URL جميع بدائله بما فيها نفسه، ويجب أن تكون البدائل متبادلة. إذا أشارت الصفحة التركية إلى نسختها العربية، فيجب أن تشير الصفحة العربية إلى النسخة التركية أيضًا. للصفحة الموجودة بثلاث لغات فقط، يسرد المدخل النسخ الثلاث الموجودة فقط؛ وhreflang الذي يشير إلى صفحة غير موجودة من أكثر الأخطاء التي نراها. القائمة الكاملة لهذه الأخطاء وما يشبهها في مقالة أخطاء hreflang. إذا استخدمت sitemap وعلامات head في الوقت نفسه، فلا يجب أن يتناقضا؛ وعمليًا، اختيار طريقة واحدة أكثر أمانًا.
عناوين URL العربية والفارسية: الترميز
يطلب sitemap عناوين URL بصيغتها المرمّزة بالنسبة المئوية. عنوان URL بـ slug عربي أو فارسي قد يبدو مقروءًا في المتصفح، لكن في sitemap يظهر كل حرف منه كستة أحرف مرمّزة. لهذا نتيجتان. الأولى أن حجم الملف ينمو أسرع بكثير مما في العناوين اللاتينية؛ لن تقترب من حد 50 ميغابايت، لكن الملف يصبح غير مقروء للعين البشرية، فيجب أن يكون التحقق بسكربت. الثانية أن slugs العربية أو الفارسية الطويلة جدًا تسبب مشكلات خارج sitemap أيضًا: بعض طبقات الخوادم والتخزين المؤقت تحدّ طول URL. في ممارستنا نحافظ على طول slug المرمّز لكل لغة تحت 240 حرفًا ونجري هذا الفحص آليًا قبل النشر.
ما لا يدخل sitemap
sitemap ليس قائمة "كل عناوين URL في الموقع" بل قائمة "العناوين الأساسية التي أريد فهرستها". يبقى خارجه: العناوين التي تعيد التوجيه، والعناوين التي تعيد 404 أو 410، والصفحات المعلَّمة noindex، والصفحات التي تشير علامة canonical فيها إلى عنوان آخر، والنسخ المكررة ذات المعاملات أو فلاتر الترتيب، والصفحات التي تتطلب تسجيل دخول، والصفحات الوسيطة التي تختار اللغة أو تعيد التوجيه تلقائيًا. وجود أي منها في sitemap يضخّم صفوف "تم إرسال عنوان URL ولكن لم تتم فهرسته" في Search Console ويخفي المشكلات الحقيقية. نظافة sitemap هي قابلية قراءة تقرير الفهرسة.
ميزانية الزحف: مشكلة من
وثائق Google عن ميزانية الزحف واضحة: الموضوع مهم أساسًا للمواقع الضخمة جدًا أو التي تتغير بوتيرة عالية جدًا. في موقع عيادة أو وكالة من بضعة آلاف من العناوين، ميزانية الزحف ليست عنق الزجاجة. ومع ذلك نسمع كلمة الميزانية كثيرًا في المواقع متعددة اللغات، لأن الأعراض تبدو متشابهة: الصفحات الجديدة تُفهرس متأخرة، وبعض اللغات تتخلف. السبب الحقيقي عادةً ليس الميزانية بل ارتباك الإشارات: تناقضات hreflang، أخطاء canonical، إعادة التوجيه التلقائية حسب اللغة، أو عناوين URL مهملة في sitemap. نظّف هذه الأربعة قبل الدخول في نقاش الميزانية؛ وفي معظم الحالات ينتهي النقاش هناك.
التحقق والصيانة
بناء sitemap عمل يوم واحد؛ وإبقاؤه صحيحًا عمل مستمر. نُؤتمت ثلاثة فحوص. الأول، سكربت يفحص أسبوعيًا أن كل عنوان في sitemap يعيد 200 ويشير إلى نفسه كـ canonical. الثاني، عدّ يقارن عدد العناوين في اللغات الأربع: إذا ظهرت 60 مقالة بالتركية و40 بالفارسية، فهناك 20 مقالة ترجمتها ناقصة أو غير منشورة؛ وهذا العدّ تدقيق لعملية المحتوى أيضًا. الثالث، فحص شهري أن تقرير sitemap في Search Console يظهر بحالة "ناجح" لكل ملف لغة، وأن عدد العناوين المكتشفة يطابق العدد في الملف. الفحوص الثلاثة كلها في قائمة فحص SEO التقني.
ملاحظة أخيرة: إشعار Google بـ sitemap عبر "ping" لم يعد ضروريًا؛ فقد أُوقفت تلك النقطة. أرسل sitemap إلى Search Console مرة واحدة وأشر إليه بسطر Sitemap في robots.txt؛ وما بعد ذلك يعتمد على انضباط lastmod. كيفية بناء sitemap في المواقع متعددة اللغات من الموضوعات التي نتناولها في الأسبوع الأول من خدمة SEO التقني، لأن كل نقاش فهرسة لاحق يستند إلى صحة هذا الملف.