يستطيع نطاق فرعي (blog.example.com) ودليل فرعي (example.com/blog) عرض المحتوى نفسه تمامًا لزائر، بنفس التصميم والتنقل المحيط به، ما يجعل الاختيار يبدو شكليًا بحتًا — لكنهما يُعدَّان ويُشغَّلان بشكل مختلف تحتهما، ولهذا الفرق عواقب عملية حقيقية بغض النظر عن شكل الرابط.

الفرق البنيوي

الدليل الفرعي ببساطة مسار تحت النطاق الرئيسي، يخدمه أي تطبيق أو خادم يتولى النطاق الجذر بالفعل — يشارك ذلك الخادم، وشهادة SSL تلك، وإعداد ذلك التطبيق افتراضيًا، ومن منظور إعداد خادم الويب نفسه هو عادة مجرد مسار أو مجلد آخر داخل التطبيق نفسه، لا كيانًا منفصلاً يحتاج توجيهًا مختلفًا على مستوى DNS أو الاستضافة. يُعامَل النطاق الفرعي عبر DNS كاسم مضيف منفصل فعليًا، يحتاج سجل DNS خاصًا به (عادة سجل A أو CNAME، مغطى بشكل عام في دليلك العملي إلى DNS)، ويستطيع التوجيه لخادم أو تطبيق أو بيئة استضافة مختلفة تمامًا عن تلك التي يستخدمها النطاق الجذر — أو لنفس البيئة، إن كان ذلك أبسط لإعداد معيّن.

النطاقات الفرعية: فصل أكبر

بما أن النطاق الفرعي إدخال DNS مستقل بذاته، يستطيع العمل على بنية مختلفة تمامًا عن الموقع الرئيسي — حساب استضافة منفصل، تطبيق مختلف تمامًا (أداة قاعدة معرفة بدلاً من نظام إدارة محتوى الموقع الرئيسي، مثلاً)، أو خط أنابيب نشر فريق مختلف — دون الحاجة لدمجه في كود أو خادم الموقع الرئيسي إطلاقًا. هذا الفصل مفيد حقًا حين يكون المحتوى نظامًا منفصلاً فعليًا، لكنه يعني أيضًا تغطية شهادة SSL منفصلة يجب إدارتها (ما لم تُستخدَم شهادة متعددة النطاقات تغطي كل النطاقات الفرعية)، وحسب كيفية ضبط التحليلات وإدارة الجلسات، لا تنتقل ملفات تعريف الارتباط وبعض سلوك التتبع تلقائيًا بين نطاق فرعي والنطاق الجذر بالطريقة التي تنتقل بها ضمن النطاق نفسه.

الأدلة الفرعية: إعداد مشترك

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

فروق إعداد الشهادة وDNS

لا يحتاج الدليل الفرعي أي إعداد SSL أو DNS إضافي — يرث إعداد النطاق الجذر القائم بالكامل. يحتاج النطاق الفرعي سجل DNS خاصًا به يوجَّه لمكان استضافته، وتغطية SSL إما عبر شهادة تتضمن ذلك النطاق الفرعي صراحة أو شهادة منفصلة صادرة له — راجع شهادات SSL: لماذا يهم HTTPS كل موقع؟ لمعرفة كيف تعمل تغطية الشهادة إن لم يكن هذا التمييز مألوفًا بعد. لا شيء من هذا صعب الإعداد الصحيح، لكنهما خطوتان إضافيتان ببساطة لا يحتاجهما دليل فرعي إطلاقًا.

مثال عملي: أين تضع مدونة أو قاعدة معرفة

تقرر شركة أين تضع مدونة جديدة. إن كانت ستعمل على نفس نظام إدارة المحتوى والخادم للموقع الرئيسي بالفعل، فالدليل الفرعي الخيار الأبسط — لا إدخال DNS جديد، لا شهادة منفصلة، ويديره من يدير الموقع الرئيسي بالفعل. إن كانت المدونة بدلاً من ذلك ستعمل على برمجية نشر منفصلة اختيرت خصيصًا لهذا الغرض، مستضافة بشكل مختلف عن الموقع الرئيسي (نمط واقعي شائع، لأن منصات التدوين أو التوثيق المخصَّصة غالبًا ليست نفس النظام الذي يشغّل الموقع الرئيسي لشركة)، فالنطاق الفرعي غالبًا المسار الأكثر عملية، لأنه يتجنب الحاجة لدمج برمجية مختلفة تمامًا في خادم وكود الموقع الرئيسي القائمين. العامل الحاسم عمليًا عادة "أي برمجية تخدم هذا المحتوى فعليًا وأين تعمل"، لا تفضيل أسلوبي بشأن شكل الرابط.

مثال ثانٍ: منطقة تسجيل دخول منتج

يقرر نشاط برمجيات كخدمة (SaaS) أين تعيش منطقة تسجيل دخول ولوحة تحكم عملائه — app.example.com أم example.com/app. هنا نمط النطاق الفرعي أكثر شيوعًا بكثير عمليًا، والمنطق يتبع مباشرة من العوامل أعلاه: لوحة تحكم منتج عادة تطبيق منفصل فعليًا (غالبًا تطبيق صفحة واحدة له عملية بناء ونشر خاصة به) عن الموقع التسويقي، يديره غالبًا جزء مختلف من فريق الهندسة، وأحيانًا يحتاج التوسع بشكل مستقل عن ارتفاعات حركة الموقع التسويقي. وضعه على نطاق فرعي خاص به يعني أن فريق المنتج يستطيع النشر والتوسع بل واستضافته بشكل مستقل تمامًا عما يشغّل الموقع التسويقي، دون أن تخاطر تغييرات أي فريق بتعطيل جاهزية الآخر — بالضبط الفصل الذي تُبنى النطاقات الفرعية بنيويًا لتناسبه، وحالة مختلفة عن مثال المدونة أعلاه، حيث كان المحتوى بسيطًا بما يكفي لمشاركة إعداد الموقع الرئيسي القائم دون مشكلة.

ملاحظة حول نقاش تحسين محركات البحث

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

قائمة تحقق للقرار

  • نفس البرمجية والخادم للموقع الرئيسي؟ الدليل الفرعي أبسط ولا يتطلب إعداد DNS أو SSL إضافيًا.
  • برمجية أو استضافة مختلفة تمامًا؟ يتجنب النطاق الفرعي إجبار ذلك المحتوى في مكدس الموقع الرئيسي القائم.
  • هل يحتاج توسعًا أو بنية تحتية مستقلة — موارد خادمه الخاصة منفصلة عن حركة الموقع الرئيسي؟ يجعل النطاق الفرعي ذلك الفصل مباشرًا؛ يرث الدليل الفرعي ما يعمل عليه الموقع الرئيسي بالفعل.
  • من سيديره فعليًا — نفس الفريق الذي يدير الموقع الرئيسي وخادمه بالفعل، أم فريق أو مزوّد منفصل؟ النطاق الفرعي أسهل في التسليم لفريق منفصل دون منحه وصولاً لبنية الموقع الرئيسي.

ما الذي يحسم الأمر فعليًا

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