السيو التقني لتطبيقات Next.js

السيو التقني في تطبيق Next.js ليس إضافة تُركَّب. إنه خاصيّة من خصائص طريقة عرض التطبيق، وهو يفشل بطرق لا تُرى من المتصفّح: رابط أساسي يشير إلى اللغة الخطأ، وعنقود hreflang يُعلن ترجمات غير موجودة، وخريطة موقع مُولَّدة من قائمة مسارات غير التي يخدمها الموجّه فعليًا.

ولا يظهر شيء من ذلك في صفحة تبدو سليمة حين تفتحونها. يظهر بعد أشهر: رابطان يتقاسمان ترتيب صفحة واحدة، أو لغة لم تُفهرس قطّ.

ما الذي نُدقّقه

• الزحف والعرض. ما الذي يستقبله الزاحف في HTML الأوّلي مقابل ما يظهر بعد الترطيب، وأيّ محتوى لديكم لا يوجد إلا في الحالة الثانية.
• التوحيد القياسي للروابط. الشرطات المائلة الختامية، ومعالجة معاملات الاستعلام، والترقيم، وما إذا كان كل مسار متّفقًا مع نفسه على عنوانه.
• التوجيه الدولي. عنقود hreflang الكامل بما فيه x-default، مُتحقَّقًا منه مقابل الترجمات الموجودة فعلًا لا المخطّط لها.
• البيانات المهيكلة. رسم @graph مترابط بمعرّفات @id ثابتة، لا أربع كتل منفصلة تُعيد كلٌّ منها تعريف المنظّمة.
• خرائط الموقع وملف robots. مُولَّدة من مصدر المسارات نفسه الذي يعرض منه التطبيق، حتى يستحيل أن يفترقا.

الأخطاء الخمسة التي نجدها أكثر من غيرها

رابط أساسي لم يُكتب أصلًا. generateMetadata اختيارية، فالمسار الذي لا يملكها لا يرث شيئًا، وتختار Google عنوانًا نيابةً عنكم - غالبًا العنوان الذي يحمل معامل تتبّع.

رابطان يستجيبان كلاهما. /about و/about/، أو لغة تُقدَّم على /ar/about وعلى /about معًا. كلاهما يعيد 200، وكلاهما يُفهرَس، وتنقسم سلطة الصفحة بينهما. العلاج تحويل دائم لا رابط أساسي، والفرق بينهما جوهري.

hreflang يُعلن ترجمة لم يكتبها أحد. قائمة لغات في ملف إعداد تُولّد البدائل، فتدّعي كل صفحة أربع لغات بينما لا توجد إلا اثنتان. تتبع Google الوسم، فتجد اللغة الخطأ أو 404، فتخصم من العنقود كلّه. القواعد بالتفصيل.

خريطة موقع مبنيّة من قائمة مسارات ثانية. مُحرَّرة يدويًا، أو مُولَّدة من مسح مجلدات لا يعرف مجموعات المسارات. تنحرف خلال دورة عمل واحدة، ثم تُبلّغ عن كل تاريخ خطأً دون أن ينتبه أحد.

بيانات مهيكلة لا تصف شيئًا. أربع كتل JSON-LD منفصلة، كل واحدة تُعلن Organization خاصّة بها، ولا واحدة تشير إلى الأخرى. JSON صالح، وبلا رسم بياني، ولا شيء يستطيع محرك البحث حلّه إلى كيان. كيف يبدو الرسم المترابط.

كيف نُصلحه

بجعل الخطأ مستحيلًا. تُولَّد الروابط الأساسية والبدائل اللغوية والبيانات المهيكلة من دالّة مساعدة واحدة ذات أنواع صريحة يجب أن يستدعيها كل مسار. ولا يمكن لصفحة أن تُنشر بلا رابط أساسي، لأن دالّة البيانات الوصفية لن تجتاز الترجمة بدونه.

هذا الموقع مبنيّ بهذه الطريقة، والتنفيذ علنيّ: فالدالّة buildMetadata ورسم JSON-LD في هذا المستودع هما النمط نفسه الذي ننشره لعملائنا.

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

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

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

تعدّد اللغات، وهو الموضع الذي ينكسر فيه عادةً

الموقع أحادي اللغة أمامه طريقة واحدة ليُخطئ في توحيد الروابط. أما الموقع الرباعي اللغات فأمامه بادئة اللغة، واللغة الافتراضية المُقدَّمة بلا بادئة، وهدف x-default، والترجمة الموجودة بلغتين والمُدّعاة بأربع، ومبدّل لغة مبنيّ على <select> لا يستطيع الزاحف أن يتبعه إلى أيّها.

نتعامل مع قائمة اللغات وقاعدة البادئة وجرد الترجمات بوصفها مصدرًا واحدًا تقرأ منه البيانات الوصفية وخريطة الموقع والمبدّل معًا. المعمارية الناتجة عن ذلك هي الفرق بين موقع بأربع لغات وموقع بلغة واحدة وثلاثة أيتام.

ما الذي لا نفعله

لا استراتيجية محتوى، ولا بحث كلمات مفتاحية، ولا بناء روابط خارجية. هذا هو الأساس الهندسي الذي تقف عليه تلك الأعمال، والفريق الذي يبيعكم الأربعة معًا يكون عادةً قويًا في واحد منها.

وسنقول لكم كذلك متى لا يكون العمل التقني هو قيدكم. إن كانت صفحاتكم مفهرسة بشكل صحيح، وتُحلّ نظيفًا، وتجتاز التحقّق، ومع ذلك لا تأتي الزيارات، فالجواب في المحتوى - وسنقول ذلك بدل أن نُصدر فاتورة تدقيق ثانٍ.

كيف يسير العمل

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

ثم الإصلاحات، على هيئة pull requests في مستودعكم، بهذا الترتيب. ثم الفحوص التي تُبقيها: توليد حيث كان الخلل قيمةً مفقودة، وتأكيدات في التكامل المستمر حيث يتعذّر التوليد.

وإن أردتم الجزء الأول وحده، فوثيقة النتائج قائمة بذاتها، وقد نفّذها عملاء عدّة بأنفسهم. تلك نتيجة معقولة، والتدقيق هو الصيغة المخصّصة لها.

النتيجة القابلة للقياس

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

ما الذي تحصلون عليه

النتائج مرتَّبة بما تكلّفكم، والإصلاحات كطلبات دمج، والفحوص التي تمنع عودتها: الروابط المعيارية وخريطة الموقع مشتقّة من مصدر واحد، وhreflang مقروء من الملفات لا من قائمة، وزحفٌ في التكامل المستمر يفشل عند أي 404 مرتبط.

ومعها صورة ما قبل وما بعد: الصفحات المفهرسة، وتلك التي كانت Search Console ترفضها والسبب الذي ذكرته، وما تغيّر بعدما أُتيح للإصلاح وقتٌ ليُعاد زحفه. هذا الرقم الأخير يصل بعد أسابيع من العمل، ونرسله رغم ذلك.