ترجمة موقع Next.js: مسارات لغوية قابلة للزحف وتحسين محركات البحث

ترجمة موقع Next.js ليست مجرد مهمة تتعلق بمكتبة تدويل (i18n). تحتاج محركات البحث إلى عناوين URL مستقلة وقابلة للزحف لكل نسخة لغوية، مع تضمين البيانات الوصفية ونص الصفحة في استجابة HTML الأولية. أما تبديل اللغة عبر ملفات الارتباط أو عبر عناصر تعمل على جانب العميل فقط ضمن عنوان URL واحد، فلا يوفّر لـGoogle صفحات منفصلة لفهرستها.

الإجابة المختصرة: المسارات اللغوية القابلة للزحف أفضل من التبديل عبر ملفات الارتباط

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

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

اختر نمط عناوين URL للغات في Next.js

تختار فرق Next.js عادةً أحد ثلاثة أنماط قابلة للزحف:

1. المجلدات الفرعية — example.com/en/docs، example.com/fr/docs. يسهل نشرها على مضيف واحد، وتوفّر بنية هرمية واضحة لإشارات hreflang.
2. النطاقات الفرعية — en.example.com، fr.example.com. مفيدة عندما تعمل الفرق الإقليمية باستقلالية جزئية، لكنها تظل بحاجة إلى إشارات hreflang متبادلة.
3. نطاقات المستوى الأعلى لرموز البلدان (ccTLDs) أو النطاقات المخصصة — توفّر أقوى إشارة جغرافية عندما تدير مواقع منفصلة فعلًا، لكنها الأعلى من حيث الأعباء التشغيلية.

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

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

App Router وتصميم مقطع اللغة

في App Router، يُعدّ استخدام مقطع ديناميكي [locale] نمطًا شائعًا، حيث يحتوي app/[locale]/layout.tsx على الصفحات المترجمة. حدّد الإعدادات المحلية المدعومة في كائن إعداد واحد، وتحقّق من صحة params.locale في التخطيطات أو البرمجيات الوسيطة. ينبغي أن تُرجع الإعدادات المحلية غير الصالحة خطأ 404، لا أن تعود إلى الإنجليزية بصمت على عنوان URL نفسه.

يمكن للبرمجيات الوسيطة إعادة توجيه / المجرّد إلى مجلد اللغة الافتراضية، مثل /en/، مع إبقاء النسخ البديلة متاحة عبر روابط. واستخدم generateStaticParams مع البرمجيات الوسيطة عند توليد الصفحات التسويقية توليدًا ثابتًا، بحيث تُبنى كل نسخة لغوية مسبقًا.

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

استخدم next-intl أو next-i18next أو مكتبات مشابهة لتحميل النصوص، لكن اجعل التوجيه، لا ملفات الارتباط وحدها، هو ما يحدّد عناوين URL العامة.

ترجمة البيانات الوصفية وOpen Graph والبيانات المنظّمة

يحتاج كل مسار لغوي إلى <title> ووصف تعريفي ورابط أساسي (canonical) ووسوم Open Graph خاصة به ضمن HTML المعروض من الخادم. في App Router، استخدم generateMetadata لكل صفحة، مع قراءة النصوص المترجمة من ملفات النصوص لديك. وينبغي ألا يعتمد العنوان والوصف التعريفي المترجمان على تبديل اللغة على جانب العميل بعد إتمام التهيئة التفاعلية (hydration).

طبّق النهج نفسه على JSON-LD: ينبغي أن تستخدم كتل WebPage وOrganization وFAQ نصوصًا مترجمة وقيم inLanguage مناسبة للإعداد المحلي. وإذا كنت تُخرج عناصر روابط hreflang، فأنشئ المجموعة الكاملة من الإشارات المتبادلة ضمن التخطيط أو الدالة المساعدة للبيانات الوصفية للصفحة؛ إذ إن غياب الروابط العائدة يعطّل مجموعات hreflang.

Hreflang والروابط الأساسية وخرائط الموقع في Next.js

تُعرّف إشارات hreflang محرك Google بعناوين URL البديلة للغات أو المناطق. ويجب أن يشير كل عنوان URL في المجموعة إلى جميع أعضائها، بما في ذلك نفسه، باستخدام رموز متطابقة. نفّذ hreflang في <head> أو ترويسات HTTP أو خرائط موقع XML عبر إدخالات xhtml:link، واختر طريقة واحدة متسقة لكل موقع.

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

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

تجنّب هياكل الصفحات التي تبدّل اللغة على جانب العميل فقط

من الأخطاء الشائعة في Next.js عرض هيكل HTML بالإنجليزية، ثم استبدال النصوص في useEffect. فقد لا تنفّذ برامج الزحف هذا الاستبدال بصورة موثوقة، بينما يرى المستخدمون وميضًا بلغة غير المطلوبة. ينبغي أن تعرض مكوّنات الخادم أو التوليد الثابت أو العرض من جانب الخادم (SSR) النصوص المترجمة في الاستجابة الأولى. ويمكن لمكوّنات العميل تهيئة الأجزاء التفاعلية، لكن النصوص التسويقية والعناوين يجب أن تكون ضمن شجرة مكوّنات الخادم.

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

سير عمل المحتوى: مسرد المصطلحات وذاكرة الترجمة والمراجعة

تفشل الخيارات الهندسية في السوق عندما تبتعد الترجمات عن مصطلحات المنتج. أضف مسرد مصطلحات وذاكرة ترجمة (TM) ومراجعة بشرية إلى سير العمل الخاص بملفات التدويل في Next.js. تعطي إرشادات Google للمحتوى المفيد الأولوية للصفحات التي تضع المستخدم أولًا؛ أما النسخ اللغوية محدودة المحتوى أو التي تقتصر على نصوص نمطية، فأداؤها ضعيف في تحسين محركات البحث، كما أنها مصادر ضعيفة للإجابات.

تصوّر موجز لسير العمل:

• استخرج النصوص من ملفات JSON أو PO إلى مسار عمل متوافق مع أدوات الترجمة بمساعدة الحاسوب (CAT).
• ألزِم باستخدام مصطلحات المسرد لأسماء المنتجات وتسميات واجهة المستخدم.
• أجرِ فحوص ضمان الجودة اللغوية على عناوين URL في البيئة التجريبية، ولا تكتفِ بمقارنة ملفات المصدر.
• أعِد المزامنة عند تغيّر المصدر الإنجليزي؛ فالنسخ اللغوية غير المحدّثة تقوّض الثقة.

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

قبل الإطلاق، تحقّق من مسارات الزحف والبيانات الوصفية والإشارات:

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

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

أخطاء شائعة

تحديد اللغة بملفات الارتباط وحدها على عنوان URL واحد — يخفي النسخ البديلة عن برامج الزحف.

غياب روابط hreflang المتبادلة — يخلّ بالربط المتبادل ويضعف تجميع النسخ اللغوية.

تعيين النسخة الإنجليزية عنوانًا أساسيًا (canonical) للصفحات المترجمة — يرسل إشارة خاطئة بشأن دمج الصفحات.

بيانات وصفية تُنشأ على جانب العميل فقط — فلا تظهر العناوين والأوصاف في HTML الأولي.

إعادة التوجيه التلقائية بناءً على عنوان IP أو ترويسة Accept-Language — تعيق برامج الزحف وتتجاهل اختيار المستخدم.

عناصر واجهة غير مترجمة — فالتنقّل المختلط اللغات يربك عملية التعرّف على اللغة.

ترجمة آلية ضعيفة دون مراجعة — لا تلبّي متطلبات المحتوى المفيد.

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

تظل الأسس المشتركة لمسارات النسخ اللغوية في Next.js وHTML المعروض من جهة الخادم مهمة لدى 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

يناسب تنفيذ التدويل (i18n) يدويًا في Next.js المواقع الصغيرة؛ لكن التوسع يتطلب ضبط المسرد، وقوائم انتظار للمراجعة، والتحقق من تحسين محركات البحث عبر النسخ اللغوية. يتكامل GlotEO مع الحِزم التقنية الحديثة ليتمكن المسوّقون من إدارة الترجمات، مع احتفاظ المهندسين ببنية App Router.

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

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