النطاقات الفرعية: ما هي ومتى وكيف تستخدمها

ما هو النطاق الفرعي ولماذا يهمّك؟

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

هذه النقطة وحدها تغيّر طريقة تفكيرك: شراء نطاق واحد يمنحك عددًا غير محدود عمليًّا من النطاقات الفرعية. أنت لا تشتري blog.example.com ولا shop.example.com — أنت تشتري example.com مرّة واحدة، ثم تُنشئ ما تشاء من الفروع تحته بإضافة سجلّ DNS. هذا يختلف جذريًّا عن النطاقات الجديدة التي تتطلّب تسجيلًا وتجديدًا سنويًّا لكل واحد.

لفهم البنية، لنفكّك العنوان blog.example.com إلى مكوّناته كما يقرؤها نظام DNS:

في هذا المثال example.com هو النطاق الجذر (Root/Apex Domain) — أي النطاق المسجّل بدون أي بادئة. أمّا blog فهو نطاق فرعي يضيف مستوى جديدًا تحته. والمثير أن www نفسه ليس إلّا نطاقًا فرعيًا تقنيًّا، حتى لو اعتدنا اعتباره «الاسم الافتراضي» للموقع — www.example.com وexample.com هما عنوانان منفصلان من ناحية DNS، وكلاهما قد يشير لنفس المكان أو لمكانين مختلفين.

النطاق الفرعي يتيح لك أيضًا التداخل: يمكنك إنشاء نطاق فرعي تحت نطاق فرعي، مثل staging.shop.example.com. هذا «نطاق فرعي من المستوى الثالث»، ويعمل بنفس المنطق تمامًا — مجرّد سجلّ DNS إضافي. عمليًّا يندر أن تتعمّق أكثر من مستويين أو ثلاثة، لأن العناوين تصبح طويلة وصعبة الحفظ.

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

النطاق الفرعي مقابل النطاق الجذر مقابل المجلّد الفرعي

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

النطاق الجذر (example.com) هو موقعك الرئيسي بلا أي بادئة. النطاق الفرعي (blog.example.com) فرع مستقلّ يُدار عبر DNS ويمكن أن يعيش على خادم مختلف تمامًا. المجلّد الفرعي أو الدليل الفرعي (example.com/blog) ليس له علاقة بـDNS إطلاقًا — هو مجرّد مسار داخل نفس الموقع على نفس الخادم، يُدار من برنامج الموقع لا من لوحة النطاق.

القاعدة العملية للاختيار بين النطاق الفرعي والمجلّد الفرعي تتلخّص في سؤال واحد: هل هذا القسم جزء من نفس التجربة التقنية، أم خدمة منفصلة؟ إذا كانت مدوّنتك تعمل على نفس نظام إدارة المحتوى وتشارك التصميم والمستخدمين، فالمجلّد الفرعي أبسط وأقوى. أمّا إذا كان المتجر يعمل على منصّة مختلفة (مثل WooCommerce منفصل أو Shopify)، أو لوحة التحكّم على تطبيق بإطار مختلف، فالنطاق الفرعي هو الحل المنطقي لأنه يفصل البيئتين تمامًا.

جدول القرار التالي يلخّص متى تختار كلًّا:

سجّل نطاقك وأدِر DNS بسهولة

خدمة الدومينات من wpressly: تسجيل وإدارة سجلّات DNS بواجهة عربية واضحة ودعم يساعدك على ضبط كل سجلّ بثقة.

احجز نطاقك الآن

حالات الاستخدام الشائعة للنطاقات الفرعية

النطاقات الفرعية ليست ميزة تقنية مجرّدة — هي أداة تنظيمية قوية تحلّ مشكلات حقيقية. فيما يلي أكثر الاستخدامات شيوعًا، ولكلٍّ منها منطقه الخاص.

المدوّنة والمحتوى

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

المتجر الإلكتروني

shop.example.com أو store.example.com منطقي حين يعمل متجرك على منصّة تجارة مستقلّة. كثير من الأنشطة تبدأ بموقع تعريفي بسيط ثم تضيف متجرًا على فرع منفصل عبر WooCommerce أو منصّة خارجية، فيبقى الموقعان مستقلّين تقنيًّا ويشتركان في الهوية والثقة.

واجهة برمجة التطبيقات (API)

api.example.com هو العُرف القياسي شبه العالمي لفصل واجهة الـAPI عن واجهة الموقع. هذا الفصل يمنحك مرونة في النشر (خادم مختلف، سياسات CORS مستقلّة، توسيع منفصل عند الضغط)، ويبقي الكود والبنية التحتية للخدمة معزولين عن الموقع التسويقي.

لوحة التحكّم وتطبيق المستخدم

app.example.com أو dashboard.example.com نمط شائع في منتجات SaaS: الموقع التسويقي على الجذر، وتطبيق المستخدم بعد تسجيل الدخول على فرع منفصل. هذا يسمح ببناء التطبيق بإطار عمل مختلف (مثل تطبيق صفحة واحدة SPA) دون أن يصطدم بتوجيه الموقع الرئيسي.

البريد الإلكتروني والخدمات

mail.example.com وwebmail.example.com وsmtp.example.com فروع تخصّ خدمات البريد. لاحظ تمييزًا مهمًّا: استقبال البريد يُدار عبر سجلّ MX لا عبر النطاق الفرعي نفسه، لكن الوصول إلى واجهة البريد عبر المتصفّح أو ضبط الخادم يتمّ غالبًا عبر نطاق فرعي مخصّص.

البيئة التجريبية (Staging)

staging.example.com أو dev.example.com أو test.example.com فروع لاختبار التغييرات قبل دفعها للإنتاج. عزل البيئة التجريبية على نطاق فرعي ضروري، ويُفضَّل دائمًا منع محرّكات البحث من فهرسته (عبر robots.txt أو حماية بكلمة مرور) حتى لا يظهر في النتائج ويسبب محتوى مكرّرًا.

التوطين واللغات وأصول CDN والدعم

تشمل الاستخدامات الأخرى: التوطين (ar.example.com لنسخة عربية بنظام منفصل)، وأصول الموقع الثابتة عبر CDN (cdn.example.com أو static.example.com لتسريع تحميل الصور والملفات)، ومركز الدعم (help.example.com أو support.example.com لقاعدة معرفة على منصّة مثل Zendesk).

الجدول التالي يجمع الحالات مع البادئة الشائعة ونوع سجلّ DNS الذي تحتاجه غالبًا:

كيف تنشئ نطاقًا فرعيًا عبر DNS

إنشاء نطاق فرعي يتلخّص في إضافة سجلّ DNS واحد في لوحة إدارة نطاقك. السؤال الوحيد المهم: هل تستخدم سجلّ A أم CNAME؟ الإجابة تعتمد على إلى أين تريد توجيه الفرع.

سجلّ A مقابل سجلّ CNAME

سجلّ A يربط النطاق الفرعي بعنوان IP رقمي مباشرة. تستخدمه حين تعرف عنوان IP للخادم الذي سيستضيف الفرع — مثل خادم VPS خاص بك. أمّا سجلّ CNAME فيجعل النطاق الفرعي اسمًا مستعارًا لاسم آخر (وليس لعنوان IP). تستخدمه حين توجّه الفرع إلى خدمة خارجية تعطيك اسمًا لا عنوانًا، مثل منصّة استضافة تطبيقات أو CDN، لأنها قد تغيّر عناوين IP خلفيًّا دون أن تتأثّر أنت.

نقطة جوهرية يخطئ فيها كثيرون: لا يمكنك وضع CNAME على النطاق الجذر @ لأنه يتعارض مع سجلّات NS وSOA الإلزامية للجذر. لهذا تستخدم بعض المزوّدات سجلًّا خاصًّا اسمه ALIAS أو ANAME لمحاكاة CNAME على الجذر. أمّا على النطاقات الفرعية فالـCNAME مسموح تمامًا وهو الخيار الأنظف للخدمات الخارجية.

أمثلة سجلّات عملية

لنفترض أن نطاقك example.com، وخادمك على عنوان 192.0.2.10. إليك أمثلة سجلّات لأشهر الفروع:

; نطاق فرعي للمدوّنة على خادمك الخاص (A)
blog    IN  A      192.0.2.10

; نطاق فرعي للـAPI على خادم آخر (A)
api     IN  A      198.51.100.20

; نطاق فرعي للمتجر على منصّة خارجية (CNAME)
shop    IN  CNAME  shops.myplatform.com.

; لوحة تحكّم على خدمة استضافة تطبيقات (CNAME)
app     IN  CNAME  myapp.vercel-dns.com.

; أصول عبر CDN (CNAME)
cdn     IN  CNAME  d111abc.cloudfront.net.

لاحظ النقطة في نهاية قيم CNAME (shops.myplatform.com.) — هي تدلّ على اسم مطلق (FQDN). في لوحات التحكّم الرسومية غالبًا لا تكتب هذه النقطة؛ الأداة تتولّاها. أمّا حقل «Name» أو «Host» فتكتب فيه البادئة فقط (blog) لا العنوان الكامل، لأن اللوحة تُلحق اسم نطاقك تلقائيًّا.

النطاق الفرعي الشامل (Wildcard)

إذا أردت أن كل نطاق فرعي غير معرّف يشير لمكان واحد، تستخدم سجلّ wildcard بالرمز *:

; أي فرع غير معرّف يشير للخادم (مفيد للمنصّات متعدّدة المستأجرين)
*       IN  A      192.0.2.10

هذا مفيد جدًّا في تطبيقات SaaS حيث يحصل كل عميل على فرع خاص (client1.example.com، client2.example.com) دون إنشاء سجلّ لكل واحد. لكن احذر: الـwildcard يلتقط كل ما لم تعرّفه صراحةً، وقد يسبّب سلوكًا غير متوقّع، كما أن تأمينه بشهادة SSL يحتاج شهادة wildcard كما سنرى.

عبر لوحة الاستضافة

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

ملاحظة مهمّة: لوحة الاستضافة تنشئ سجلّ DNS فقط إن كانت خوادم الأسماء (Nameservers) لنطاقك تشير إليها. إذا كنت تدير DNS من مكان آخر (مثل Cloudflare)، فعليك إضافة السجلّ هناك لا في لوحة الاستضافة. هذه نقطة تربك كثيرين عند فصل إدارة DNS عن الاستضافة. راجع ربط الدومين بالاستضافة لفهم العلاقة بين خوادم الأسماء ولوحة الاستضافة بالتفصيل.

استضافة النطاق الفرعي على خادم أو مزوّد منفصل

من أقوى ميزات النطاقات الفرعية أن كلًّا منها يمكن أن يعيش على بنية تحتية مختلفة تمامًا. هذا الفصل المعماري يفتح خيارات عملية كثيرة.

تخيّل هذا السيناريو الواقعي: موقعك الرئيسي example.com على استضافة مشتركة، ومدوّنتك blog.example.com على ووردبريس في خادم آخر، وapi.example.com على خادم VPS قوي، وcdn.example.com على شبكة توصيل محتوى عالمية. أربع خدمات، أربع بيئات، نطاق واحد، تجربة موحّدة للمستخدم. المستخدم لا يلاحظ أي انتقال؛ بالنسبة له كل شيء «داخل نفس الموقع»، بينما خلف الكواليس تتوزّع الأحمال على بنى تحتية مستقلّة تمامًا، لكلٍّ منها موارده وأمنه وحدوده.

الآلية بسيطة: كل سجلّ DNS يوجّه فرعه إلى الوجهة المناسبة. الجذر يشير لخادم الاستضافة المشتركة عبر سجلّ A، والمدوّنة لخادمها عبر A آخر، والـAPI لعنوان VPS، والـCDN لاسم الشبكة عبر CNAME. الجدول التالي يوضّح هذا التوزيع:

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

هناك فائدة ثانية أقلّ وضوحًا لكنها مهمّة: الفصل في المسؤولية والصلاحيات. حين يعيش الـAPI على خادم منفصل، يمكن لفريق التطوير أن يملك صلاحية كاملة عليه دون أن يلمس خادم الموقع التسويقي الذي يديره فريق التسويق. هذا الفصل الإداري يقلّل المخاطر: خطأ في نشر تحديث للتطبيق لن يُسقط الصفحة الرئيسية، وثغرة في إضافة ووردبريس بالمدوّنة لن تصل إلى بيانات الـAPI الحسّاسة. كل فرع يصبح «منطقة احتواء» مستقلّة.

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

سجّل نطاقك وأدِر DNS بسهولة

خدمة الدومينات من wpressly: تسجيل وإدارة سجلّات DNS بواجهة عربية واضحة ودعم يساعدك على ضبط كل سجلّ بثقة.

احجز نطاقك الآن

إصدار شهادة SSL للنطاقات الفرعية

هذه واحدة من أكثر النقاط التي تسبّب أخطاءً صامتة. كثيرون ينشئون نطاقًا فرعيًا، يوجّهونه بشكل صحيح، ثم يتفاجؤون برسالة «الاتصال غير آمن» لأن شهادة SSL الخاصّة بالموقع لا تغطّي الفرع الجديد.

القاعدة الحاسمة: شهادة SSL تُصدَر لأسماء محدّدة. شهادة صادرة لـexample.com وwww.example.com لا تغطّي تلقائيًّا blog.example.com. أمامك خياران لتأمين الفروع:

الشهادة المجانية من Let's Encrypt تدعم النوعين: شهادة عادية تضيف فيها كل اسم فرعي صراحةً، أو شهادة wildcard لكل الفروع من مستوى واحد. لاحظ قيدًا مهمًّا: شهادة wildcard لـ*.example.com تغطّي blog.example.com وshop.example.com، لكنها لا تغطّي staging.shop.example.com (مستوى أعمق) ولا example.com نفسه (الجذر). لذا الشهادة الشاملة عمليًّا تكون لـexample.com و*.example.com معًا.

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

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

أثر النطاقات الفرعية على SEO

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

الجدل التاريخي هو: هل يُعامِل محرّك البحث النطاق الفرعي كموقع مستقلّ أم كجزء من الموقع الأمّ؟ الموقف العملي اليوم: محرّكات البحث تستطيع فهم العلاقة بين الفرع والجذر، لكنها في كثير من الحالات تعامل النطاق الفرعي كـكيان منفصل نسبيًّا من ناحية تجميع سلطة الموقع (Domain Authority). أمّا المجلّد الفرعي فيرث سلطة الموقع الأمّ مباشرةً وبشكل أوضح.

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

القاعدة الذهبية إذًا: اختر المجلّد الفرعي للمحتوى المرتبط، والنطاق الفرعي للفصل التقني. لا تضع مدوّنتك على فرع منفصل لمجرّد أنه «يبدو أنظف» إن كانت ستعمل على نفس النظام — ستخسر تركيز السلطة دون مقابل. وفي كل الأحوال، تأكّد من ربط hreflang وcanonical بشكل صحيح إن وزّعت المحتوى، وامنع فهرسة بيئات staging تمامًا.

الانتشار وTTL

بعد إضافة سجلّ النطاق الفرعي، لا يظهر فورًا في كل مكان. السبب هو التخزين المؤقّت (Caching) المنتشر عبر خوادم DNS حول العالم.

كل سجلّ DNS له قيمة TTL (Time To Live) بالثواني، تحدّد كم من الوقت يحتفظ المحلِّلون بنسخة من السجلّ قبل إعادة الاستعلام. إذا كان TTL يساوي 3600، فقد يحتفظ محلِّل ما بالنسخة القديمة لساعة كاملة. هذا يفسّر لماذا يعمل فرعك الجديد عندك بينما لا يصل إليه صديقك بعد، أو لماذا تأخّر ظهور تعديل عنوان IP لفرع موجود.

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

للتحقّق من انتشار فرعك واكتشاف القيمة الفعلية التي تراها خوادم DNS، استخدم أدوات سطر الأوامر:

# التحقّق من سجلّ النطاق الفرعي بأداة dig
dig blog.example.com +short
# المتوقّع: 192.0.2.10

# عرض نوع السجلّ والـTTL الفعلي
dig blog.example.com

# التحقّق من CNAME
dig shop.example.com CNAME +short

# الاستعلام من خادم DNS عام محدّد (Cloudflare)
dig @1.1.1.1 api.example.com +short

وعلى أنظمة ويندوز، أو كبديل سريع:

# على ويندوز / لينكس / ماك
nslookup blog.example.com

# تحديد خادم DNS معيّن للاستعلام
nslookup blog.example.com 8.8.8.8

إذا أعطتك dig العنوان الصحيح من خادم عام مثل 1.1.1.1، فالسجلّ منتشر على المستوى العالمي حتى لو لم يظهر بعد في شبكتك المحلّية بسبب cache جهازك أو مزوّدك.

الأخطاء الشائعة وحلّها

أغلب مشاكل النطاقات الفرعية تتكرّر بأنماط معروفة. الجدول التالي يربط كل عَرَض بسببه الجذري وحلّه المباشر:

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

نصيحة خبير أخيرة: احتفظ بسجلّ موثّق لكل النطاقات الفرعية التي أنشأتها ووجهة كل واحدة. مع نموّ المشروع، تتراكم الفروع، وتصبح الفروع «اليتيمة» (تشير لخدمات ألغيت) ثغرة أمنية محتملة عبر ما يُعرف بـ«استيلاء النطاق الفرعي» (Subdomain Takeover)، حيث يستولي مهاجم على خدمة مهجورة لا يزال فرعك يشير إليها.

الأسئلة الشائعة

هل النطاق الفرعي مجاني أم يحتاج شراءً منفصلًا؟

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

كم نطاقًا فرعيًا يمكنني إنشاؤه؟

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

ما الفرق بين النطاق الفرعي والمجلّد الفرعي بكلمات بسيطة؟

النطاق الفرعي (blog.example.com) عنوان مستقلّ يُدار عبر DNS ويمكن أن يعيش على خادم مختلف، بينما المجلّد الفرعي (example.com/blog) مجرّد مسار داخل نفس الموقع على نفس الخادم. الأول يفصل تقنيًّا، والثاني يبقي كل شيء موحّدًا. للمحتوى المرتبط بالموقع غالبًا المجلّد أفضل لـSEO.

هل يضرّ النطاق الفرعي بترتيبي في محرّكات البحث؟

لا يضرّ بحدّ ذاته، لكنه قد لا يستفيد من سلطة موقعك الأمّ بنفس قوّة المجلّد الفرعي. إذا كان القسم محتوى تريد له أن يرث ويدعم قوة موقعك، فالمجلّد الفرعي عادةً أفضل. أمّا الخدمات المنفصلة تقنيًّا (API، تطبيق) فالنطاق الفرعي مبرّر دون قلق على SEO المحتوى.

أستخدم سجلّ A أم CNAME لإنشاء الفرع؟

استخدم سجلّ A حين توجّه الفرع إلى خادم تعرف عنوان IP الخاص به (مثل VPS). واستخدم CNAME حين توجّهه إلى خدمة خارجية تعطيك اسمًا لا عنوانًا (مثل منصّة تطبيقات أو CDN)، لأنها قد تغيّر عناوينها خلفيًّا دون أن تتأثّر.

هل تغطّي شهادة SSL الخاصّة بموقعي النطاقات الفرعية تلقائيًّا؟

لا. الشهادة العادية لـexample.com وwww.example.com لا تغطّي blog.example.com. تحتاج إمّا شهادة منفصلة لكل فرع، أو شهادة wildcard (*.example.com) تغطّي كل الفروع من مستوى واحد. معظم لوحات الاستضافة تُصدر شهادات الفروع تلقائيًّا بعد انتشارها.

كم يستغرق ظهور النطاق الفرعي الجديد؟

الفرع الجديد كليًّا يظهر عادةً خلال دقائق إلى ساعة، لأن المحلِّلين لا يملكون نسخة قديمة منه. أمّا تغيير وجهة فرع موجود فقد يستغرق حتى انتهاء قيمة TTL القديمة (حتى 24 ساعة أحيانًا). تحقّق من الانتشار بأداة dig أو nslookup.

هل يمكنني وضع CNAME على النطاق الجذر؟

لا، تقنيًّا لا يمكن وضع CNAME على الجذر @ لأنه يتعارض مع سجلّات NS وSOA الإلزامية. بعض المزوّدات توفّر سجلّ ALIAS أو ANAME لمحاكاة هذا السلوك على الجذر. أمّا على النطاقات الفرعية فالـCNAME مسموح تمامًا.

ما هو النطاق الفرعي الشامل (Wildcard)؟

هو سجلّ بالرمز * يجعل أي فرع غير معرّف صراحةً يشير لوجهة واحدة، مثل * IN A 192.0.2.10. مفيد جدًّا لتطبيقات SaaS التي تمنح كل عميل فرعًا خاصًّا. تذكّر أن أي سجلّ صريح يتجاوز الـwildcard، وأن تأمينه يحتاج شهادة wildcard.

هل يؤثّر النطاق الفرعي على البريد الإلكتروني الخاص بنطاقي؟

لا يؤثّر إنشاء فرع للموقع على بريدك، لأن البريد يُدار عبر سجلّ MX منفصل تمامًا. يمكنك إنشاء فرع mail.example.com للوصول إلى واجهة البريد دون أن يمسّ ذلك توجيه استقبال الرسائل المحدّد بسجلّ MX.

كيف أتأكّد أن النطاق الفرعي يعمل بشكل صحيح؟

استخدم dig blog.example.com +short للتحقّق من عنوان IP، أو nslookup على ويندوز. تأكّد من فتح الفرع عبر https:// لا http:// فقط للتحقّق من الشهادة، واستعلم من خادم عام مثل 1.1.1.1 للتأكّد من الانتشار العالمي وليس فقط شبكتك المحلّية.

الخلاصة

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

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

سجّل نطاقك وأدِر DNS بسهولة

خدمة الدومينات من wpressly: تسجيل وإدارة سجلّات DNS بواجهة عربية واضحة ودعم يساعدك على ضبط كل سجلّ بثقة.

احجز نطاقك الآن