سيو Next.js التقني: proxy وcanonical واللغة
استبدلت Next.js 16 وسيط middleware بـ proxy. فخاخ إعداد proxy وcanonical والنسخ اللغوية في مواقع Next.js متعددة اللغات.
بقلم Roozbeh Nazari · CEO
في المواقع متعددة اللغات المبنية بـ Next.js، تقع أغلب أخطاء السيو التقني لا في الصفحات المفردة بل في الطبقة التي يمر بها الطلب قبل أن يصل إلى الصفحة. عُرفت هذه الطبقة زمنًا طويلًا باسم middleware. ومع Next.js 16 أُوقف العمل باصطلاح الملف وأُعيدت تسميته إلى proxy؛ فصار ملف middleware.ts هو proxy.ts، واسم الدالة المصدَّرة صار proxy. والسبب المعلن لإعادة التسمية أن مصطلح «middleware» كثيرًا ما التبس بـ middleware في Express.js، وهو ما شجّع على استخدام الميزة أكثر مما قُصد لها.
ومن زاوية السيو ليس هذا مجرد تغيير اسم. ففي الفرق التي ترقّي من دون تحديث إعدادها، قد يتوقف ترتيب النسخ اللغوية وcanonical عن العمل بهدوء عند نقطة لا ينتبه إليها أحد. والنقاط أدناه تتناول الأخطاء التي تنتجها هذه الطبقة أكثر من غيرها في إعدادات Next.js متعددة اللغات. ولبقية التدقيق يمكنك الرجوع إلى خدمتنا للسيو التقني وإلى قائمة التدقيق الإنتاجية المكوّنة من عشرين بندًا.
الطبقة التي تختفي أثناء الترقية
في مشروع رُقّي إلى Next.js 16، إذا تُرك ملف middleware.ts في مكانه فلن يعود اصطلاح الملف معترفًا به. والنتيجة ليست رسالة خطأ بل تغيّرًا صامتًا في السلوك: فتوجيهات النسخ اللغوية، وعمليات إعادة الكتابة بحسب كوكي اللغة، وإضافات الترويسات المعرفة في ذلك الملف، تتوقف عن العمل ببساطة. يظل الموقع يفتح، وتعيد الصفحات 200، ولا ينكسر أي اختبار. وحده ترتيب اللغة يزول.
وتوفر Next.js أداة codemod لهذه الترقية؛ تعيد تسمية الملف والدالة معًا. والترتيب الصحيح للفرق المرقّية هو تشغيل الـ codemod ثم التحقق يدويًا من سلوك النسخ اللغوية في بيئة شبيهة بالإنتاج. وينبغي أن يجري التحقق بطلبات ضُبطت فيها ترويسة Accept-Language يدويًا، لا عبر المتصفح؛ فالمتصفح يرسل لغته أصلًا وقد يحجب المشكلة.
الـ matcher: أغلى ثلاثة أسطر
حين لا يُعرَّف matcher، يعمل proxy مع كل طلب. ويشمل ذلك الملفات الساكنة، ومسارات تحسين الصور، والأصول في مجلد public. والخطأ النمطي في الإعدادات متعددة اللغات هو أن تشمل إعادةُ كتابة تضيف بادئة لغوية الأصولَ الساكنة أيضًا؛ والنتيجة تعذّر تحميل ملفات الأنماط والبرامج النصية أو توجيهها إلى مسارات غير متوقعة.
- عند كتابة نمط المطابقة السلبية يجب استثناء مسارَي sitemap.xml وrobots.txt. فعنوان خريطة موقع اكتسب بادئة لغوية ليس العنوان الذي يتوقعه محرك البحث.
- ينبغي استثناء مسارات الـ API؛ فعنوان API أُضيفت إليه بادئة لغوية لن يعمل.
- يجب أن تكون قيم الـ matcher ثوابت. فالـ matcher المولَّد من متغير لا يمكن تحليله وقت البناء ويُتجاهل بصمت؛ ويُظن أن الإعداد يعمل.
وثمة دقيقة أخرى: حتى لو استُثنيت في نمط المطابقة السلبية، يظل proxy يُستدعى لمسارات البيانات. وهذا السلوك مقصود، والغرض منه منع خطأ حماية صفحة مع ترك مسار بياناتها المقابل بلا حماية. ومعناه في ترتيب اللغة أن طلبات البيانات تمر هي الأخرى بمنطق إعادة الكتابة نفسه، وأن هذا المنطق يجب ألا يفسد عنوان مسار البيانات.
الـ canonical: في metadata لا في proxy
من الأخطاء الشائعة في الإعدادات متعددة اللغات إضافةُ عنوان canonical ترويسةً في طبقة proxy. فهذه الطبقة تعمل قبل تصيير الصفحة ولا تعرف دائمًا أي محتوى ستعرضه الصفحة؛ وقد لا يطابق الـ canonical المنتَج العنوان بعد إعادة الكتابة. والمكان الصحيح هو كائن metadata المعرَّف على مستوى الصفحة أو الـ layout.
وعلى جانب metadata يُعرَّف canonical والبدائل اللغوية تحت حقل alternates: يحمل canonical العنوان المفضل للصفحة نفسها، ويحمل languages عناوين النسخ اللغوية. وفي المسارات الديناميكية ينبغي توليد هذه القيم داخل generateMetadata؛ أما canonical المعرَّف بكائن metadata ساكن فيشير بكل الصفحات الديناميكية إلى العنوان نفسه، منتجًا خطأ القالب الكلاسيكي.
والقاعدة في جانب جوجل مستقلة عن ذلك: canonical إشارة قوية لا توجيه ملزم. فإعادة التوجيه هي أقوى أساليب توحيد النسخ، ووسم canonical في المرتبة الثانية. أي أنك حين تنتج إشارات متعارضة — مثل canonical يشير إلى عنوان بينما يشير الإعلان اللغوي إلى عنوان آخر — لست أنت من يحدد النتيجة.
النسخ اللغوية: فخ التوجيه التلقائي
أكثر استخدامات طبقة proxy إغراءً هو توجيه الزائر إلى نسخة لغوية بحسب لغة متصفحه. ويبدو هذا الترتيب منطقيًا من زاوية تجربة المستخدم، وهو مكلف من زاوية السيو. فزاحف محرك البحث يأتي بتفضيل لغوي واحد؛ ومتى أُقيم توجيه إجباري لم تُزحف النسخ اللغوية الأخرى إطلاقًا ولم تُكتشف أعضاء المجموعة اللغوية.
وقد تناولنا هذا الفخ بالتفصيل في مقالنا عن التوجيه التلقائي للغة. والنقطة الخاصة بـ Next.js التي تُضاف هنا هي: حين يُكتب منطق التوجيه داخل proxy، يمر به كل طلب — بما في ذلك طلبات الأصول، تبعًا للـ matcher — فتتكون سلاسل توجيه. ويزداد طول السلسلة بضربه في عدد النسخ اللغوية.
والترتيب الآمن هو اقتراح اللغة بدل فرضها: أن يُترك الزائر في النسخة التي هو فيها مع تقديم خيار ظاهر للغة التي يفضلها. وهذه المقاربة تُبقي كل نسخة لغوية قابلة للزحف على عنوانها الخاص، ولا تنتزع الاختيار من المستخدم.
بيئة التشغيل والتحقق
يستخدم proxy بيئة تشغيل Node.js افتراضيًا، ولا يمكن ضبط خيار runtime داخل الملف؛ وعند محاولة ضبطه يُطلق خطأ. ولهذا ينبغي تنظيف تعريفات runtime المنقولة عن إعدادات قديمة أثناء الترقية.
وعلى جانب التحقق، تتيح أدوات الاختبار التي جاءت مع Next.js 15.1 التأكدَ باختبارات وحدة من العناوين التي يعمل عليها ملف proxy. ومقابل ذلك في الإعدادات متعددة اللغات ملموس: بضعة اختبارات تؤكد أن مسارات خريطة الموقع وrobots والأصول خارج نطاق proxy، وأن المسارات ذات البادئة اللغوية داخله، تلتقط وقت البناء أخطاءً يستغرق تبيّنها في الإنتاج أسابيع.
والقاعدة العملية لهذه الطبقة في مجملها: يُستخدم proxy للتوجيه وإعادة الكتابة، لا للإشارات التي تحدد هوية الصفحة. فـ canonical والإعلانات اللغوية ووسوم العنوان تنتمي إلى طبقة الصفحة. ومتى اختلط الأمران كان الخطأ الناتج لا في صفحة واحدة بل في القالب كله، ويكبر عادةً بضربه في عدد الصفحات.
قائمة فحص بعد الترقية
في مشروع متعدد اللغات ينتقل إلى Next.js 16، ثمة قائمة قصيرة تُشغَّل يدويًا بعد اكتمال الترقية. وهي لا تحل محل الاختبارات الآلية؛ بل توجد لالتقاط صنف «يعمل لكنه يعمل خطأً» من الأخطاء الذي لا تغطيه الاختبارات الآلية.
- هل يوجد proxy.ts في الجذر، وهل اسم الدالة المصدَّرة proxy؟ فالملف المتروك باسمه القديم يُتجاهل بصمت.
- مع ضبط ترويسة Accept-Language يدويًا، هل تعيد كل نسخة لغوية 200 على عنوانها الخاص، أم يجري التوجيه إلى نسخة واحدة؟
- هل يمكن الوصول إلى sitemap.xml وrobots.txt من دون اكتساب بادئة لغوية؟
- في صفحة ديناميكية، هل يشير canonical إلى عنوان تلك الصفحة نفسها، أم إلى عنوان واحد على مستوى القالب كله؟
- هل الإعلانات اللغوية متبادلة، وهل تشير إلى العنوان نفسه الذي يشير إليه canonical؟