تفاوت دامنه و ساب‌دامین چیست؟

در جلسه‌های راه‌اندازی پروژه، یکی از پرتکرارترین سؤال‌هایی که می‌شنوم این است که «فروشگاه را روی ساب‌دامین بزنم یا دامنه اصلی؟» و در نود درصد موارد، وقتی از سؤال‌کننده می‌پرسم چه چیزی از ساب‌دامین می‌داند، پاسخ به همان سطحی می‌رسد که «فقط می‌دانم زیرشاخه‌ای از دامنه است». تجربه‌ام می‌گوید تفاوت دامنه و ساب‌دامین، در ساختار فنی ساده است، اما در پیامدهای سئو، معماری و مدیریت، به همان سادگی نیست. همین تفاوت کوچک، در سه سال، تصمیم‌های عملیاتی بسیار متفاوتی می‌سازد. این نوشته، همان تفکیک لایه‌ای است که در پروژه‌های واقعی استفاده می‌کنم.

دامنه و ساب‌دامین: دو تعریف دقیق

دامنه (Domain) یا نام دامنه، همان نشانی اصلی سایت شماست که از دو بخش ساخته می‌شود: نام انتخابی و پسوند (TLD یا Top-Level Domain). مثلاً در example.com، بخش example نام و .com پسوند است. این ترکیب، هویت اینترنتی سایت شماست و در دنیای واقعی، معادل آدرس پستی یا شماره تلفن یک کسب‌وکار محسوب می‌شود. مفهوم کامل دامنه و نحوه ثبت آن در دامنه چیست و چگونه ثبت می‌شود آمده است.

ساب‌دامین (Subdomain)، یک شاخه از همان دامنه اصلی است که پیش از نام دامنه قرار می‌گیرد. مثلاً shop.example.com یا blog.example.com. ساب‌دامین، از نظر فنی یک نشانی مستقل محسوب می‌شود، اما در دنیای DNS (Domain Name System)، همچنان به همان دامنه اصلی وابسته است. تفاوت بین دامنه و ساب‌دامین، در یک جمله: دامنه ریشه هویت است و ساب‌دامین، زیرمجموعه‌ای از آن. اگر با مفهوم کلی DNS آشنا نیستید، DNS چیست و چگونه کار می‌کند پیش‌نیاز این بحث است.

ساب‌دامین، شاخه‌ای از یک درخت است که ریشه‌اش همان دامنه اصلی است؛ مستقل به‌نظر می‌رسد اما در سایه همان هویت رشد می‌کند.

آناتومی یک نشانی: کدام بخش کدام است؟

برای رفع سردرگمی، یک نشانی اینترنتی را از راست به چپ می‌شکنیم:

نکته مهم در این جدول: ساب‌دامین از سمت چپ به دامنه اضافه می‌شود، ولی در ذهن کاربر، به‌عنوان بخشی از همان سایت اصلی دیده می‌شود. همین دوگانگی، منشأ اصلی ابهام در تصمیم‌گیری است. اگر در انتخاب پسوند دامنه هم تردید دارید، دامنه‌های معتبر کدامند راهنمای خوبی است. همچنین تفاوت دامنه بین‌المللی و ملی در دامنه بین‌المللی یا ملی آمده است.

ساب‌دامین در DNS چطور تعریف می‌شود؟

در DNS، هر ساب‌دامین به‌عنوان یک رکورد مستقل تعریف می‌شود. معمولاً با یک رکورد A یا CNAME در پنل DNS دامنه‌تان اضافه می‌شود:

; رکورد A برای ساب‌دامین shop
shop    IN  A     192.0.2.10

; رکورد CNAME برای ساب‌دامین blog که به دامنه اصلی اشاره می‌کند
blog    IN  CNAME example.com.

نکته مهم در اینجا: هر ساب‌دامین، به‌طور مستقل در DNS تعریف می‌شود و می‌تواند به سرور متفاوتی اشاره کند. یعنی اگر ساب‌دامینی از سایت شما حذف شد، به‌طور خودکار روی دامنه اصلی تأثیر نمی‌گذارد. برعکس، اگر دامنه اصلی مشکل داشته باشد، تمام ساب‌دامین‌ها هم از دسترس خارج می‌شوند. تفاوت DNS و Nameserver و نقش هر کدام در تفاوت DNS و Nameserver آمده و انواع رکوردها در رکوردهای DNS کدامند بررسی شده است.

تفاوت در سئو: دامنه و ساب‌دامین

این بخش، پرتکرارترین دلیل تردید در انتخاب بین دامنه و ساب‌دامین است. در سئو، سه تفاوت کلیدی وجود دارد:

• انتقال اعتبار (Link Juice): گوگل، ساب‌دامین را به‌عنوان یک سایت مستقل می‌بیند. یعنی اعتبار بک‌لینک‌های دامنه اصلی، به‌طور کامل به ساب‌دامین منتقل نمی‌شود. در تجربه من، زیرپوشه (example.com/shop/) اعتبار بیشتری از دامنه اصلی می‌گیرد تا ساب‌دامین (shop.example.com).
• مدیریت جداگانه: در Search Console، ساب‌دامین باید به‌عنوان یک property جداگانه ثبت شود. یعنی مدیریت سئو، دو نسخه مستقل دارد که باید جداگانه پایش شوند. راهنمای کامل Search Console در سئو تکنیکال از خزش تا ایندکس آمده است.
• خزش و ایندکس: هر دو در ایندکس گوگل ظاهر می‌شوند، اما چون جدا از هم مدیریت می‌شوند، بودجه خزش هم بین دو دامنه تقسیم می‌شود. برای سایت‌های کوچک، این تقسیم می‌تواند به نفع دامنه اصلی نباشد.

در تجربه من، اگر سایت شما تازه‌کار است و اعتبار دامنه محدودی دارد، استفاده از زیرپوشه به‌جای ساب‌دامین، انتخاب کم‌ریسک‌تری است. اما اگر پروژه‌ای با ماهیت متفاوت دارید (مثل یک فروشگاه کاملاً مستقل از وبلاگ)، ساب‌دامین منطق خودش را دارد. اگر با مفاهیم کلی سئو آشنا نیستید، سئو چیست و چگونه به رشد سایت کمک می‌کند پیش‌نیاز این تصمیم است.

تفاوت در معماری سایت

از نظر معماری، ساب‌دامین مزایای خاص خود را دارد:

• جداسازی محیط‌ها: می‌توانید محیط تست را روی test.example.com راه بیندازید و از محیط production جدا نگه دارید. این جداسازی در پروژه‌های سازمانی ضروری است.
• جداسازی سرویس‌ها: فروشگاه را روی ساب‌دامین و وبلاگ را روی دامنه اصلی، با دو نصب وردپرس مستقل. این جداسازی، اجازه می‌دهد هر کدام روی زیرساخت متفاوتی اجرا شوند.
• استقلال در آپدیت و بکاپ: تغییرات در یکی، بر دیگری اثر ندارد. مخصوصاً در سناریوهای پرخطر مثل آپدیت یک افزونه سنگین، این استقلال ارزش دارد.

در مقابل، معماری زیرپوشه (Path) مزایای دیگری دارد: دامنه واحد، مدیریت یکپارچه، پشتیبانی ساده‌تر از SSL (Secure Sockets Layer)، و انتقال اعتبار سئویی بین بخش‌ها. در تجربه من، انتخاب معماری، باید بر اساس سناریوی واقعی کسب‌وکار انجام شود، نه بر اساس توصیه عمومی. اگر فروشگاه ماهیت کاملاً جدا از سایت اصلی دارد، ساب‌دامین منطقی است؛ اگر هر دو بخشی از یک برند واحد هستند، زیرپوشه انتخاب بهتر است.

معماری درست، معماری‌ای است که با سناریوی کسب‌وکار شما هم‌خوانی داشته باشد، نه معماری‌ای که توصیه‌های عمومی پیشنهاد می‌کنند.

کوکی، نشست و دامنه‌های متقاطع

یکی از پرتکرارترین مشکلاتی که در ساب‌دامین‌ها می‌بینم، رفتار کوکی‌هاست. کوکی‌ها به‌طور پیش‌فرض، برای دامنه‌ای که آن‌ها را صادر کرده، محدود می‌شوند. یعنی کوکی که از shop.example.com صادر شده، در example.com قابل دسترسی نیست، مگر آنکه صریحاً با دامنه والد (Parent Domain) تعریف شده باشد:

// کوکی معتبر برای همه ساب‌دامین‌ها
Set-Cookie: session=abc; Domain=.example.com; Secure; HttpOnly

نقطه پیش از دامنه (.example.com)، دقیقاً همان چیزی است که کوکی را بین ساب‌دامین‌ها به اشتراک می‌گذارد. در تجربه من، نداشتن این تنظیم، باعث می‌شود که ورود کاربر در ساب‌دامین، در دامنه اصلی شناسایی نشود و برعکس. مسئله کوکی در سبد خرید فروشگاه‌ها حیاتی‌تر است؛ چرا که اگر سبد خرید بین دامنه و ساب‌دامین جابه‌جا شود، ممکن است کاربر با سبد خالی مواجه شود. مسائل مشابه در امن‌سازی نشست‌های کاربری آمده است.

چه زمانی ساب‌دامین انتخاب درست است؟

در تجربه من، ساب‌دامین در چهار سناریو انتخاب درست است:

1. محیط تست و استجینگ: برای جداسازی محیط توسعه از production، ساب‌دامینی مثل staging.example.com کاملاً منطقی است. این جداسازی، در راه‌اندازی سایت وردپرسی هم توصیه شده است.
2. سرویس کاملاً مستقل: اگر روی همان دامنه، یک سرویس کاملاً متفاوت (مثل یک اپلیکیشن SaaS یا فروشگاه کاملاً مستقل) راه می‌اندازید، ساب‌دامین منطقی است؛ چون هرکدام هویت خودش را دارد.
3. چند‌زبانه با مخاطب متفاوت: برای سایت‌های چندزبانه با مخاطب جغرافیایی متفاوت، ساب‌دامین می‌تواند انتخاب خوبی باشد؛ چون هر ساب‌دامین می‌تواند روی سرور منطقه‌ای خودش اجرا شود.
4. پروژه‌های آژانسی: اگر تیم شما مدیریت چند پروژه مستقل را از یک دامنه والد انجام می‌دهد، ساب‌دامین‌ها امکان جداسازی و مدیریت مستقل را می‌دهند.

چه زمانی دامنه اصلی یا زیرپوشه؟

در سه سناریو، زیرپوشه روی دامنه اصلی بهتر است:

1. سایت تازه‌کار با اعتبار محدود: چون اعتبار بک‌لینک‌ها به ساب‌دامین منتقل نمی‌شود، در پروژه‌های تازه‌کار، استفاده از زیرپوشه انتخاب کم‌ریسک‌تری است.
2. هویت واحد: اگر همه بخش‌های سایت (فروشگاه، وبلاگ، بخش آموزشی) بخشی از یک برند واحد هستند، دامنه واحد با زیرپوشه، ساده‌تر و هویت قوی‌تر می‌سازد.
3. مدیریت ساده‌تر: اگر بودجه یا زمان نگهداری محدود است، داشتن یک دامنه واحد با چند زیرپوشه، هزینه نگهداری را کاهش می‌دهد.

در تجربه من، اگر شما در انتخاب بین این دو تردید دارید و هیچ‌کدام از چهار سناریوی بالا شامل پروژه شما نیست، انتخاب امن، زیرپوشه روی دامنه اصلی است. در سال دوم کار، اگر کسب‌وکار به سمت جداسازی رفت، می‌توانید با ریدایرکت ۳۰۱، انتقال امن به ساب‌دامین انجام دهید. پروتکل کلی تغییر بدون افت سئو در تغییر دامنه بدون افت سئو آمده است.

SSL و Wildcard در دو حالت

یکی از تفاوت‌های عملی در مدیریت SSL (Secure Sockets Layer)، تعداد گواهی‌های موردنیاز است. برای دامنه واحد با زیرپوشه، یک گواهی SSL کافی است؛ چون همه چیز زیر یک دامنه سرو می‌شود:

certbot --nginx -d example.com -d www.example.com

برای چند ساب‌دامین، دو گزینه دارید: یا برای هر ساب‌دامین یک گواهی جدا بگیرید، یا از Wildcard SSL استفاده کنید که همه ساب‌دامین‌ها را در یک گواهی پوشش می‌دهد:

certbot certonly --manual --preferred-challenges dns 
  -d example.com -d "*.example.com"

نکته: Wildcard SSL، تنها با چالش DNS قابل صدور است، نه با چالش HTTP. تجربه‌ام می‌گوید اگر تنها یک یا دو ساب‌دامین دارید، صدور گواهی جداگانه ساده‌تر است. اما اگر تعداد ساب‌دامین‌ها زیاد است، Wildcard صرفه‌جویی زمانی قابل‌توجهی می‌کند. مراحل کامل SSL در راه‌اندازی SSL و HTTPS در وردپرس و تفاوت گواهی رایگان و پولی در گواهی SSL رایگان و پولی آمده است.

جدول مرجع

پرسش‌های کوتاه

آیا ساب‌دامین، به اندازه دامنه اصلی در سئو مؤثر است؟ خیر. ساب‌دامین، به‌عنوان یک دامنه مستقل دیده می‌شود و اعتبار بک‌لینک‌ها به آن منتقل نمی‌شود. اگر اعتبار دامنه اصلی برایتان مهم است، زیرپوشه انتخاب بهتری است.

آیا تعداد ساب‌دامین‌ها در سئو محدودیت دارد؟ گوگل محدودیت رسمی برای تعداد ساب‌دامین‌ها ندارد، اما هر ساب‌دامین نیازمند مدیریت جداگانه است. تجربه‌ام می‌گوید بیش از سه یا چهار ساب‌دامین برای یک کسب‌وکار، مدیریت را به‌شدت پیچیده می‌کند.

آیا می‌توانم ساب‌دامین را به دامنه اصلی منتقل کنم؟ بله، اما این کار نیازمند ریدایرکت ۳۰۱ است و در سئو، افت موقت ممکن است. پروتکل امن در تغییر دامنه بدون افت سئو آمده است.

آیا استفاده از ساب‌دامین، سرعت سایت را بهتر می‌کند؟ نه به‌تنهایی. ساب‌دامین می‌تواند روی سرور متفاوتی اجرا شود و امکان انتخاب سرور نزدیک‌تر به مخاطب را بدهد، اما اگر روی همان سرور باشد، تفاوت سرعتی ندارد. عوامل سرعت در تأثیر هاست بر سرعت سایت آمده است.

آیا برای فروشگاه اینترنتی، ساب‌دامین بهتر است یا زیرپوشه؟ در تجربه من، اگر فروشگاه بخشی از برند واحد است، زیرپوشه انتخاب بهتری است؛ چون اعتبار دامنه اصلی را به ارث می‌برد. اگر فروشگاه سرویس مستقل با هویت متفاوت است، ساب‌دامین منطقی است. راهنمای فروشگاهی در قالب فروشگاه اینترنتی آمده است.

آیا ساب‌دامین روی رتبه‌بندی گوگل اثر مستقیم دارد؟ اثر مستقیم ندارد، اما اثر غیرمستقیم دارد: چون اعتبار کمتری می‌گیرد و مدیریت جداگانه نیاز دارد، در پروژه‌های تازه‌کار می‌تواند رشد را کندتر کند. جزئیات در چگونه رتبه سایت را در گوگل بهبود دهیم آمده است.

از منظر معماری زیرساخت و دیجیتال

برای معماران وب و تیم‌های فنی که با تصمیم‌های بلندمدت دامنه کار می‌کنند، انتخاب بین دامنه اصلی، زیرپوشه و ساب‌دامین را باید در چارچوب «تفکیک هویت از سرویس» دید، نه فقط در چارچوب سئو. سه اصل معماری که در پروژه‌های سازمانی اثر مستقیم داشته‌اند. اول، جداسازی سرویس از هویت: هویت کسب‌وکار باید در دامنه اصلی متمرکز باشد؛ سرویس‌های جانبی می‌توانند در زیرپوشه یا ساب‌دامین مستقل باشند. این تفکیک، به شما اجازه می‌دهد روزی که سرویس جانبی حذف یا بازطراحی شد، هویت اصلی دست‌نخورده بماند. دوم، آمادگی برای مقیاس: اگر پیش‌بینی می‌کنید که یک سرویس (مثلاً فروشگاه) در سه سال آینده به زیرساخت متفاوت یا سرور منطقه‌ای جدا نیاز پیدا کند، از روز اول ساب‌دامین انتخاب کنید تا در آینده مهاجرت پرهزینه نداشته باشید. سوم، پایش پوشش سئو در هر دو حالت: در معماری ساب‌دامین، حتماً Search Console را برای هر ساب‌دامین جداگانه ثبت کنید و در بازه‌های فصلی خزش و ایندکس را پایش کنید. تجربه‌ام می‌گوید تیم‌هایی که این پایش را در هر دو معماری جدی می‌گیرند، در بلندمدت با اعداد قابل‌دفاع تصمیم می‌گیرند و کمتر به «توصیه عمومی» تکیه می‌کنند. یک نکته پایانی که در پروژه‌های سازمانی مهم است: پیش از انتخاب هر معماری، پرسش کلیدی این نیست که «کدام سریع‌تر جواب می‌دهد» بلکه «کدام در سه سال آینده، هزینه نگهداری کمتری می‌سازد». پاسخ این پرسش در بیشتر مواقع، به ترکیبی از زیرپوشه و ساب‌دامین می‌رسد: هویت اصلی روی دامنه با زیرپوشه‌ها، و سرویس‌های کاملاً مستقل روی ساب‌دامین‌های اختصاصی.

جمع این مسیر

دامنه و ساب‌دامین، دو لایه از یک نشانی اینترنتی هستند که در سطح فنی ساده، اما در سطح پیامدها پیچیده‌اند. تجربه‌ام می‌گوید اگر سایت شما هویت واحد دارد و در ابتدای راه است، زیرپوشه روی دامنه اصلی انتخاب کم‌ریسک‌تری است. اگر سرویس شما کاملاً مستقل است یا در پیش‌بینی سه‌ساله، زیرساخت متفاوتی لازم دارد، ساب‌دامین منطق خودش را دارد. اگر امروز فقط یک کار بکنید، در انتخاب هر معماری، دو سؤال را از خود بپرسید: «سه سال آینده، آیا می‌خواهم این سرویس را جدا مدیریت کنم؟» و «آیا اعتبار دامنه اصلی برای این سرویس حیاتی است؟» پاسخ این دو سؤال، معمولاً تصمیم را روشن می‌کند. اگر تجربه‌ای از انتخاب یا مهاجرت بین دامنه و ساب‌دامین دارید که در منابع فارسی کمتر گفته شده، در دیدگاه‌ها بنویسید؛ همان تجربه‌ها، تصویر این بحث را کامل‌تر می‌کنند. 🌐