كيفية ترجمة موقع Astro: توجيه i18n وتحسين محركات البحث

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

يشرح هذا الدليل كيفية ترجمة موقع Astro باستخدام صفحات HTML قابلة للزحف لكل لغة، ومجموعات محتوى منظّمة، وتخطيطات ووسوم SEO موطّنة، وخرائط مواقع تدعم hreflang. ويتناول أيضًا محاذير العرض الهجين وسير العمل التحريري لمحتوى Markdown وMDX، وكل ذلك استنادًا إلى متطلبات Google للمواقع متعددة اللغات، دون اختلاق عوامل تؤثر في الترتيب.

أسئلة يجيب عنها هذا الدليل

• كيف يدعم توجيه i18n في Astro إصدارات لغوية قابلة للزحف؟
• كيف ينبغي تنظيم مجموعات المحتوى لكل لغة؟
• كيف تُوطّن عناصر واجهة التخطيط ووسوم SEO في Astro؟
• كيف ينبغي توليد hreflang لمخرجات Astro الثابتة؟
• متى تحتاج مواقع Astro متعددة اللغات إلى العرض الهجين؟
• كيف ينبغي دمج سير عمل الترجمة مع محتوى Markdown/MDX؟
• ما الأخطاء الشائعة في مواقع Astro متعددة اللغات؟
• متى ينبغي لفرق Astro اعتماد منصة ترجمة؟

إجابة سريعة: صفحات HTML الثابتة لكل لغة هي ميزة Astro في تحسين محركات البحث

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

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

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

توجيه i18n في Astro وتصميم عناوين URL

اضبط إعدادات Astro بتحديد اللغات المدعومة واللغة الافتراضية بوضوح. من أنماط عناوين URL الشائعة:

• إظهار بادئة اللغة الافتراضية (/en/about، /fr/about) — نمط واضح يسهل إضافة الوسوم إليه.
• إخفاء بادئة اللغة الافتراضية (/about للإنجليزية، و/fr/about للفرنسية) — يمنح عناوين URL للسوق الرئيسية صيغة أبسط؛ وثّق الربط بين الإصدارات باستخدام hreflang.

في astro.config.mjs، اضبط i18n.locales وi18n.defaultLocale وi18n.routing لتتوافق مع مصفوفة اللغات لديك. ينبغي أن يتلقى كل ملف مسار اللغة النشطة عبر واجهات API الخاصة بـ Astro، حتى تعرض القوالب اللغة الصحيحة.

تحدد Google لغة الصفحة أساسًا من محتواها الظاهر؛ لذا ينبغي أن يكون معظم المحتوى وعناصر التنقّل في كل إصدار لغوي بلغة واحدة. اربط مكوّنات التنقّل بقواميس ترجمة تراعي اللغة النشطة، لتتوافق ترويسات الصفحات وتذييلاتها مع لغة المحتوى الرئيسي.

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

لفهم الجوانب الاستراتيجية لاستهداف اللغات مقابل استهداف البلدان، اقرأ تحسين محركات البحث الدولي مقابل تحسين محركات البحث متعدد اللغات.

مجموعات المحتوى لكل لغة

تُستخدم مجموعات المحتوى في Astro لإدارة محتوى المدونات والوثائق وصفحات الهبوط. نظّم المحتوى متعدد اللغات وفق خطة واضحة:

• مجلدات منفصلة للمجموعات بحسب اللغة (src/content/blog/en/، src/content/blog/fr/) مع مخططات بيانات مشتركة.
• حقل للغة في البيانات التمهيدية (frontmatter) لتصفية مجموعة واحدة عندما يكون حجم المحتوى صغيرًا.
• فهارس مرتبطة بروابط رمزية أو مولّدة آليًا تسرد العناصر المتاحة فقط في كل لغة؛ تجنّب نشر صفحات لغوية فارغة.

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

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

توطين التخطيطات ووسوم SEO وOpen Graph

اجمع عناصر واجهة التخطيط المشتركة في مكوّنات تراعي اللغة النشطة:

• يقرأ BaseLayout.astro قيمة Astro.currentLocale، أو يستخدم دالة i18n المساعدة لديك، ويختار النصوص من قواميس JSON أو TS.
• <title> والوصف التعريفي يُستمدّان من البيانات التمهيدية أو حقول نظام إدارة المحتوى لكل صفحة، لا من نصوص إنجليزية ثابتة في الشيفرة.
• وسوم Open Graph وTwitter تعكس العنوان والوصف الموطّنين.
• تتطابق السمة html lang مع اللغة النشطة، لدعم إمكانية الوصول والوضوح؛ ومع ذلك، تظل Google تعتمد على المحتوى الظاهر لتحديد اللغة.

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

توليد hreflang وخرائط المواقع

ينبغي لمواقع Astro أيضًا تضمين إشارات hreflang متبادلة بين عناوين URL اللغوية عند وجود إصدارات بديلة، سواء في HTML أو الترويسات أو خرائط المواقع. أثناء البناء، أنشئ مصفوفة لغات من شبكة العلاقات بين محتوياتك:

1. لكل صفحة من حيث المحتوى، أدرج جميع عناوين URL المنشورة لإصداراتها اللغوية.
2. أدرج <link rel="alternate" hreflang="..." href="..." /> داخل <head> في كل ملف HTML ثابت، أو
3. أنشئ خريطة موقع XML تتضمن بدائل xhtml:link لكل عنوان URL مُدرج.

تساعد خرائط مواقع XML على اكتشاف الإصدارات اللغوية، ويمكن أن تتضمن وسوم hreflang بصيغة xhtml:link عند اعتمادها وسيلةً لتنفيذ هذه الإشارات.

ينبغي أن يتضمن عنوان URL لكل لغة رابطًا أساسيًا (canonical) واضحًا يشير إلى صفحة باللغة نفسها. وتنطبق إرشادات Google للروابط الأساسية على المواقع الثابتة كما تنطبق على المواقع الديناميكية.

ادمج توليد خريطة الموقع في التكامل المستمر (CI)؛ إذ يعمل @astrojs/sitemap جيدًا مع نقاط ربط مخصّصة للتسلسل، لتبقى إشارات hreflang متزامنة مع تغييرات المحتوى.

راجع أساسيات تحسين محركات البحث للمواقع متعددة اللغات لمعرفة كيف تدير فرق التحرير الوسوم بالتنسيق مع المخرجات الهندسية.

محاذير الجزر الهجينة والمحتوى الديناميكي

تتيح بنية الجزر في Astro تفعيل مكوّنات React أو Vue أو Svelte على جانب العميل بشكل انتقائي. وفيما يلي محاذير تتعلق بتعدد اللغات:

• قد تعرض عناصر الواجهة التي تعمل على جانب العميل فقط المحتوى بالإنجليزية حتى يتم تحميل JavaScript، مما يضر باكتشاف اللغة وتجربة المستخدم.
• اعرض HTML الأولي للجزر على الخادم بالإعداد المحلي الصحيح كلما أمكن.
• تحتاج المسارات الديناميكية (output: 'server' أو hybrid) إلى تمرير الإعداد المحلي عبر البرمجيات الوسيطة، حتى يتطابق HTML المعروض على الخادم (SSR) مع بادئة عنوان URL.

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

سير العمل التحريري لمحتوى MDX وأنظمة إدارة المحتوى

يظل Markdown وMDX الخيار الأسهل صيانةً لطبقة المحتوى في Astro لدى كثير من الفرق:

1. النصوص المصدرية في ملفات الترجمة (src/i18n/fr.json) لعناصر واجهة المستخدم.
2. بيانات Frontmatter في ملف كل إعداد محلي للمحتوى المطوّل.
3. طلبات سحب لكل دفعة من إعداد محلي مع التحقق من الالتزام بمسرد المصطلحات.
4. التصدير إلى أدوات الترجمة بمساعدة الحاسوب (CAT) أو أنظمة إدارة الترجمة (TMS) لمجموعات الوثائق الكبيرة، ثم إعادة الاستيراد إلى src/content.

تعطي إرشادات Google للمحتوى المفيد الأولوية للصفحات التي تضع المستخدم أولًا؛ أما نشر مخرجات آلية دون مراجعة فيؤدي إلى تجارب محلية ضعيفة المحتوى.

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

قائمة التحقق من التنفيذ

• اضبط الإعدادات المحلية في Astro i18n واستراتيجية بادئات المسارات
• أنشئ تخطيطًا وملفات قواميس تراعي الإعداد المحلي
• نظّم مجموعات المحتوى حسب الإعداد المحلي باستخدام مخططات مشتركة
• وطّن العنوان والبيانات الوصفية وبيانات OG وhtml lang في كل قالب
• أنشئ مصفوفة الإعدادات المحلية × عناوين URL أثناء التجميع
• ولّد روابط hreflang متبادلة في HTML أو خريطة الموقع
• عيّن روابط أساسية باللغة نفسها لكل مخرج ثابت
• اعرض الجزر على الخادم أو بصورة ثابتة بالإعداد المحلي النشط
• أضف أداة واضحة لتبديل اللغة دون إعادة توجيه قسرية
• نفّذ زحفًا في بيئة الاختبار بعد إطلاق كل نسخة محلية

أخطاء شائعة

1. هيكل تخطيط بالإنجليزية فقط في المسارات الموطّنة.
2. غياب hreflang بسبب صيانة المسارات الثابتة يدويًا.
3. إخفاء الإعداد المحلي الافتراضي دون توثيق البدائل، مما يخلّ بتبادلية الروابط.
4. أداة تبديل لغة تُعرض على جانب العميل دون عناوين URL مستقلة.
5. محتوى MDX مختلط اللغات نتيجة دمج ترجمات جزئية.
6. نشر نسخ محلية غير مكتملة تتضمن نصوصًا تجريبية من نوع lorem أو نصوصًا مؤقتة بالإنجليزية.
7. إغفال خريطة الموقع في المواقع الثابتة الكبيرة، مما يبطئ اكتشاف الصفحات.
8. توجيه الرابط الأساسي إلى نسخة بلغة أخرى دون تدقيق.

تؤكد إرشادات مشرفي المواقع من Bing أيضًا أهمية المحتوى المفيد القابل للزحف والبنية الواضحة للموقع لدعم الفهرسة في مختلف الأسواق.

أسس البحث التقليدي ومحركات الإجابات

تظل الأسس المشتركة لملفات HTML الثابتة للنسخ المحلية ومجموعات المحتوى في Astro مهمة لدى Google وBing ومحركات الإجابة: نسخ لغوية قابلة للزحف، وكيانات واضحة، وادعاءات مدعومة بالأدلة، وبيانات منظّمة حيث تعكس الواقع، وتوطين حقيقي لا مجرد هياكل بالإنجليزية فقط. تعامل مع الأدلة أدناه بوصفها رؤى خاصة بكل منصة لتحقيق المعيار نفسه في تقديم المحتوى متعدد اللغات.

دليل المنصة: Google Search

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

دليل المنصة: Bing

يكتشف Bing الصفحات متعددة اللغات القابلة للزحف ويفهرسها عندما تكون بنيتها واضحة، بما يشبه متطلبات Google المتعلقة بوضوح عناوين URL والمحتوى. وتشمل الأسس التقنية عناوين URL لكل لغة ومنطقة يمكن جلبها، ومحتوى مفيدًا، ومراقبة عبر Bing Webmaster Tools. أعطِ الأولوية لتوطين العناوين والادعاءات والأسئلة الشائعة، بدلًا من الاكتفاء بترجمة عناصر الواجهة. وتظل إشارات الموثوقية معتمدة على مصادر جديرة بالثقة وكيانات متسقة. وبالنسبة للمحتوى متعدد اللغات، لا تُخفِ اللغات خلف مفاتيح تبديل تعمل من جهة العميل فقط. قِس الفهرسة وإحصاءات الزحف في Bing Webmaster Tools. المعلوم مقابل غير المؤكد: تؤكد إرشادات Bing أهمية المحتوى المفيد القابل للزحف؛ فلا تختلق عوامل ترتيب حصرية لـBing تتعلق بأدوات الترجمة.

دليل المنصة: ChatGPT

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

دليل المنصة: Gemini

يستفيد Gemini وتجارب الذكاء الاصطناعي المرتبطة به لدى Google من اتساق الكيانات، والبيانات المنظّمة حيث تكون دقيقة، والصفحات الموطّنة القابلة للفهرسة. ويتمثل الظهور في الإشارة إلى المحتوى أو التعرّف عليه، لا في اختلاق عوامل ترتيب لـGemini. وتتقاطع الأسس التقنية مع قابلية الزحف وجودة البيانات الوصفية في بحث Google. وينبغي أن يقدّم المحتوى ادعاءات وتعريفات واضحة في كل لغة. وتعتمد الموثوقية على اتساق معلومات المؤسسة والأدلة المؤيّدة. وبالنسبة للمحتوى متعدد اللغات، تقلّل أسماء المنتجات المضبوطة بالمسرد الالتباس بين نسخ اللغات والمناطق. قِس الأداء بالطرق التقليدية عبر Search Console، وقيّم عيّنات من إجابات الذكاء الاصطناعي نوعيًا. المعلوم مقابل غير المؤكد: سلوك Gemini ليس بديلًا عن إرشادات بحث Google الموثّقة بشأن hreflang والنسخ اللغوية.

دليل المنصة: Google AI Overviews

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

كيف يساعدك GlotEO

متى ينبغي لفرق Astro اعتماد منصة ترجمة؟ عندما يتجاوز تطبيق مسرد المصطلحات، وقوائم انتظار مراجعة النسخ المحلية، ومصفوفات hreflang ما يمكن إدارته يدويًا عبر طلبات سحب JSON وMDX.

يمكن للفريق الهندسي تنفيذ توجيه Astro i18n بإتقان، لكن التوطين يظل بحاجة إلى مسارد مصطلحات، وقوائم انتظار للمراجعة، وانضباط في النشر. استكشف توطين المواقع باستخدام GlotEO لربط موجزات العمل وسير الترجمة ونقاط التحقق من ضمان الجودة بمسارات معالجة محتوى المواقع الثابتة، بحيث تظل تحديثات MDX والقواميس متوافقة مع hreflang والبيانات الوصفية لتحسين محركات البحث التي تنتجها عملية البناء في Astro.

قارن أسعار GlotEO وخططه عندما يتجاوز حجم الترجمة قدرة التعديل اليدوي لملفات JSON، واستخدم أدوات سير عمل تحسين محركات البحث متعدد اللغات لإبقاء مصفوفات الإعدادات المحلية والمتطلبات التحريرية واضحة لكل من المطورين وفرق المحتوى.

استكمل هذا الدليل التعليمي لـAstro بدليل المقارنة بين تحسين محركات البحث الدولي وتحسين محركات البحث متعدد اللغات عندما يسبق تحديد استراتيجية اللغات والبلدان مرحلة التنفيذ.