المجلدات الفرعية تهزم النطاقات: خدعة برمجية لانتزاع صدارة محركات البحث

يواجه أصحاب المواقع جداراً تقنياً غير مرئي حين يتعلق الأمر بتوزيع المحتوى؛ فبينما يسهل تقنياً وضع المدونة على نطاق فرعي (Subdomain)، تظهر النتائج غالباً كرسالة «Access Denied» معنوية أمام زحف محركات البحث التي تتعامل مع النطاقات الفرعية ككيانات منفصلة. هذا التشتت في «سلطة النطاق» دفع المطورين للبحث عن حلول بديلة تدمج المحتوى داخل المجلدات الفرعية (Subdirectory) لتركيز قوة الأرشفة في مكان واحد.

تاريخياً، ساد اعتقاد بأن جوجل لا تفرق بين الصيغتين، لكن البيانات التجريبية التي نشرتها منصة «ButterCMS» تشير إلى أن المجلدات الفرعية تتفوق بنسبة تصل إلى 40% في تحسين نتائج البحث. الأمر لا يتعلق فقط بالترتيب، بل بكيفية تدفق «عصير السيو» (Link Juice) من الموقع الرئيسي إلى المدونة وبالعكس. الانتقال من (blog.example.com) إلى (example.com/blog) ليس مجرد تغيير في شكل الرابط، بل هو إعادة هيكلة كاملة لطريقة رؤية العناكب البرمجية للموقع.

العملية معقدة. تتطلب التلاعب بحركة المرور عبر «الخوادم الطرفية» (Edge Computing). باستخدام خدمات مثل «Cloudflare Workers»، يمكن للمبرمجين اعتراض الطلبات القادمة للمجلد الفرعي وتوجيهها برمجياً لجلب المحتوى من خادم آخر دون أن يشعر المستخدم أو محرك البحث بهذا الانتقال. يتطلب هذا ضبط سجلات DNS بدقة متناهية، مع تفعيل خاصية «Proxy» لضمان مرور البيانات عبر شبكة الوسيط.

في بيئة العمل باستخدام إطار «Next.js»، تبرز الحاجة لتعديل ملف الإعدادات الأساسي (next.config.js) وإضافة قيمة «basePath». الهدف هنا هو إقناع التطبيق بأنه يعمل داخل مسار محدد سلفاً. لكن الفخ الحقيقي يكمن في المحتوى المكرر؛ فإذا ظل النطاق الفرعي القديم متاحاً للأرشفة، ستعاقب محركات البحث الموقع. الحل الجذري يكمن في إرسال ترويسة برمجية «X-Robots-Tag» تحمل قيمة «noindex» للنطاق القديم، مع السماح للمجلد الجديد بالظهور.

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