ساب دامنه یا پوشه؟ کدام برای وبلاگ و بخش های سایت بهتر است

اگه وبلاگ یا بخش جدیدت از نظر فنی و تیمی همون سایت اصلیه (مثلاً هر دو وردپرس هستن و یه نفر اداره شون می کنه)، پوشه مثل example.ir/blog معمولاً ساده تر و منطقی تره. اگه اون بخش فناوری، سرور یا تیم جدا داره (اپلیکیشن، API، پنل کاربری، مستندات)، ساب دامنه مثل blog.example.ir انتخاب بهتریه. جواب ساب دامنه یا پوشه همیشه یکی نیست، ولی با چند سوال مشخص می شه سریع و بدون پشیمونی تصمیم گرفت. پایین تر همون سوال ها رو یکی یکی از نگاه مدیریت، امنیت، سئو و پیچیدگی فنی می بینیم.

ساب دامنه یا پوشه؛ تفاوت واقعی از نظر فنی چیه؟

خیلی ها فکر می کنن فرقشون فقط توی شکل آدرسه. ولی پشت این دو شکل، دو مدل کاملاً متفاوت از چیدمان سایت قرار داره.

ساب دامنه یه اسم جداست، نه یه شاخه

ساب دامنه یعنی یه نام تازه زیر دامنه اصلی تو. با یه رکورد DNS ساخته می شه و می تونه به هر سرور و هر کشوری اشاره کنه. مثلاً:

blog    A    203.0.113.10

اینجا blog.example.ir می ره سمت یه سرور، و example.ir ممکنه جای کاملاً دیگه ای باشه. اگه تفاوت رکوردهای A و CNAME برات مبهمه، رکورد DNS چیست؟ تفاوت A، CNAME، MX و TXT با مثال رو بخون، چون ساخت ساب دامنه عملاً با همین رکوردها انجام می شه.

مرورگر ساب دامنه رو یه میزبان (host) جدا حساب می کنه. معمولاً گواهی SSL خودش (یا یه گواهی wildcard)، فایل robots.txt خودش، نقشه سایت خودش و تنظیمات کش خودش رو داره.

پوشه یعنی همه چی زیر یه سقف

آدرس example.ir/blog یعنی همون میزبان، فقط با یه مسیر دیگه. این مسیر دو جور می تونه پیاده بشه: یا واقعاً یه پوشه روی همون هاست، یا یه reverse proxy که درخواست های /blog رو به یه برنامه دیگه می فرسته.

پوشه بودن آدرس به این معنی نیست که سرور هم یکیه. تو می تونی وبلاگ وردپرسی رو روی یه سرور جدا نگه داری و با یه تنظیم ساده به کاربر نشون بدی که زیر همون دامنه ست:

location /blog/ {
    proxy_pass http://10.0.0.5:8080;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-Proto $scheme;
}

عیبش اینه که برنامه مقصد باید بدونه زیر پیشوند /blog کار می کنه. توی وردپرس یعنی نشانی سایت و لینک ها باید درست تنظیم بشن، وگرنه تصویرها و فایل های استایل لینک شکسته می گیرن. پوشه با اینکه ساده به نظر می رسه، از همین جا می تونه دردسر بسازه.

اول سئو؛ واقعاً فرق می کنه؟

بذار صادق باشم: اینجا کسی جواب قطعی نداره. گوگل می گه هر دو ساختار قابل قبوله. چیزی که توی عمل دیده می شه اینه که پوشه تجمیع اعتبار و لینک سازی داخلی رو ساده تر می کنه، و ساب دامنه بیشتر شبیه یه سایت جداست که باید جدا براش کار کرد.

دلیلش منطقیه. وقتی وبلاگ توی پوشه ست، هر لینکی که از مقاله ها به صفحه محصول می ره یه لینک داخلی ساده ست. هر لینک خارجی که به مقاله ات برسه هم روی همون دامنه می شینه. با ساب دامنه هم این اتفاق ها می افته، ولی نمی تونم تضمین کنم موتور جستجو دقیقاً با همون وزن ببینه، و باید جدا پیگیری کنی.

چند نکته عملی:

• هر ساب دامنه robots.txt و نقشه سایت خودش رو می خواد. توی پوشه یکی کافیه.
• اگه توی Search Console ویژگی از نوع دامنه (Domain property) تعریف کنی، هر دو حالت رو پوشش می ده، ولی گزارش های ساب دامنه ها شلوغ تر می شن.
• سرعت و بهبود LCP سایت به شکل آدرس ربطی نداره و به سرور، تصویر و کش وابسته ست. پس نگو «ساب دامنه سرعت رو بالا می بره»، مگه اینکه واقعاً وبلاگ رو روی سرور سبک تر گذاشته باشی.
• کیفیت محتوا و پوشش موضوعی از این انتخاب خیلی مهم تره. یه وبلاگ ضعیف زیر پوشه، بهتر از یه ساب دامنه ضعیف نیست.

اگه از قبل یه سایت قدیمی و اعتبار دار داری، جابه جایی بین این دو حالت بدون ریدایرکت 301 دقیق مثل اسباب کشی بدون خبر دادن آدرس جدیده. بعد از جابه جایی هم نوسان رتبه تا چند هفته عادیه.

دوم، مدیریت و تجربه کاربر

از نگاه محصول، سوال اصلی اینه: کاربر باید حس کنه توی یه سایت واحده یا بین دو تا محصول جدا می چرخه؟

یکپارچگی ظاهر و ورود کاربر

با پوشه، هدر، فوتر، جستجو و سبد خرید معمولاً بدون زحمت یکپارچه می مونن. ورود کاربر هم خودبه خود مشترکه، چون کوکی ها روی همون میزبانن.

با ساب دامنه باید برای اشتراک ورود، کوکی رو روی .example.ir تنظیم کنی. این کار شدنیه، ولی هر ساب دامنه ای که بسازی به اون کوکی دسترسی پیدا می کنه. این رو توی بخش امنیت بازتر می کنم. ظاهر دو بخش هم دیر یا زود از هم فاصله می گیره، مگه اینکه یه سیستم طراحی مشترک داشته باشی.

تیم، استقرار و مالکیت

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

آمار و ردیابی

با پوشه، یه ابزار تحلیل ساده همه چیز رو یکجا می بینه. با ساب دامنه باید ردیابی بین میزبان ها رو درست تنظیم کنی. وگرنه کاربری که از وبلاگ وارد فروشگاه می شه ممکنه یه بازدیدکننده جدید حساب بشه و مسیر خریدش رو نتونی دنبال کنی.

سوم، امنیت

اینجا بده بستان واقعی شروع می شه.

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

مرورگر دو آدرس رو وقتی هم ریشه (same origin) می دونه که پروتکل، میزبان و پورتشون یکی باشه. example.ir/blog و example.ir/panel هم ریشه ان. پس اگه توی صفحه های وبلاگ یه حفره XSS باشه (مثلاً از یه افزونه قدیمی)، مرورگر اسکریپت مهاجم رو هم سطح بخش پنل کاربر می بینه و اون اسکریپت می تونه به داده های همون میزبان دست بزنه.

ساب دامنه این مرز رو مشخص تر می کنه. ولی مجانی نیست:

• اگه کوکی ورود رو برای کل دامنه (.example.ir) تنظیم کنی، یه ساب دامنه ضعیف می تونه راه نفوذ بشه.
• رکورد CNAME یتیم مشکل می سازه. فرض کن یه ساب دامنه به سرویسی اشاره می کرد که بعداً حذفش کردی ولی رکورد DNS موند. یه نفر دیگه می تونه اون سرویس رو بگیره و محتوای خودش رو زیر دامنه تو نشون بده. به این حمله subdomain takeover می گن.
• هر ساب دامنه یه سطح حمله جدیده. اگه پنج تا بسازی، پنج تا برنامه برای وصله کردن داری.

لایه محافظ باید همه جا باشه

ما فایروال سایت داریم که IP های مشکوک رو پیش از رسیدن به برنامه مسدود می کنه یا کپچا نشون می ده، تا حمله روی سرعت کاربرهای عادی اثر نذاره. نکته برای ساب دامنه ها اینه که اگه این لایه یا CDN فقط جلوی دامنه اصلی باشه، ساب دامنه وبلاگ یا API بی محافظ می مونه و حمله از همون در وارد می شه. پس هر ساختاری که انتخاب کردی، مطمئن شو همه میزبان ها پشت همون لایه ان. اگه می خوای این بخش رو به متخصص بسپاری، مدیریت و امن سازی سرور دقیقاً برای همین کاره.

چهارم، کار فنی و هزینه نگه داری

پوشه روی کاغذ ساده تره، ولی فقط وقتی همه چیز یه جاست. اگه وبلاگ روی سرور دیگه ای باشه، باید reverse proxy بنویسی، هدرها رو درست رد کنی، کش رو مدیریت کنی و بعد از هر تغییر آدرس، لینک ها رو دوباره چک کنی.

ساب دامنه برعکسه. راه اندازی اولیه اش آسونه: یه رکورد DNS، یه گواهی SSL و تمام. ولی نگه داری اش زحمت بیشتری داره: گواهی های جدا یا wildcard، تنظیم کوکی، ردیابی آمار و لایه محافظ مشترک.

یه نکته درباره DNS: بعد از ساخت ساب دامنه یا عوض کردن رکوردها، ممکنه برای بعضی کاربرها تا چند ساعت باز نشه. دلیلش و راه کنترلش رو توی تغییر DNS؛ چرا سایت برای بعضی کاربران باز نمی شود؟ نوشتیم. اگه CDN هم داری، CDN برای سایت؛ آیا جای هاست قوی را می گیرد؟ کمک می کنه بفهمی کدوم حالت با کش و مسیردهی راحت تره.

شرایط ایران که توی مقایسه های خارجی نمی بینی

بیشتر مقاله های انگلیسی این بحث رو فقط از دید سئو می بینن. اینجا چند چیز محلی هم هست:

• محل میزبانی: اگه مخاطبت ایرانیه و پهنای باند بین الملل توی ساعت های شلوغ کند می شه، ممکنه بخوای وبلاگ رو روی میزبانی ایران بذاری و اپلیکیشن رو جای دیگه. با ساب دامنه این کار خیلی ساده ست. با پوشه هم شدنیه، ولی reverse proxy و تنظیم دقیق می خواد.
• درگاه پرداخت و اینماد: درگاه های متصل به شاپرک و نماد اعتماد معمولاً به آدرس ثبت شده سایت حساسن. اگه صفحه پرداخت یا سبد خرید رو می بری روی ساب دامنه، قبلش از ارائه دهنده درگاه و اینماد بپرس آدرس و شرایط چیه. قوانینشون ممکنه عوض شده باشه، پس خودت چک کن.
• دامنه .ir: ساخت ساب دامنه ثبت جدا نمی خواد و فقط یه رکورد DNS لازمه. ولی خود دامنه اصلی باید ثبت و تمدید بشه. مراحلش توی ثبت دامنه ir قدم به قدم؛ از انتخاب نام تا فعال شدن هست. اگه از قبل دامنه ای داری، همون رو نگه دار و ساختار رو روش بساز.
• نسخه زبان دیگه: اگه محصولت فقط برای ایرانیه، دلیل چندانی برای ساختن ساب دامنه زبان نداری. اگه نسخه انگلیسی هم داری، /en/ معمولاً راحت تر از en.example.ir مدیریت می شه.

جدول تصمیم سریع

برای هر کسی چی بهتره؟

صاحب کسب و کار کوچک با یک سایت: پوشه. وقت و پولت رو خرج ساختار پیچیده نکن. وبلاگ رو زیر /blog بذار و روی تولید محتوا تمرکز کن.

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

توسعه دهنده یا استارتاپ: اپلیکیشن، API و مستندات رو ساب دامنه کن (app.، api.، docs.) و صفحه معرفی و وبلاگ رو روی دامنه اصلی نگه دار. این الگو رایجه، چون هر بخش چرخه انتشار و نیاز امنیتی متفاوتی داره. اگه معماری اولیه رو مطمئن نیستی، مشاوره و معماری می تونه قبل از شروع جلوی تغییرهای پرهزینه رو بگیره.

کسی که سایت قدیمی با اعتبار داره: تا دلیل قوی نداری ساختار رو عوض نکن. اگه مجبوری، نقشه ریدایرکت 301 رو قبل از جابه جایی بنویس و بعدش لینک ها و نقشه سایت رو بررسی کن.

اشتباه های رایجی که زیاد می بینیم

1. انتخاب بر اساس «یه جا شنیدم سئو بهتره». ساختار آدرس جادو نیست. اول ببین تیم، سرور و نیاز امنیتی خودت چیه.
2. رکورد DNS رها شده. وقتی سرویس یه ساب دامنه رو می بندی، رکوردش رو هم حذف کن.
3. کوکی با دامنه خیلی گسترده. مگه اینکه واقعاً لازم باشه، کوکی ورود رو روی کل .example.ir نذار.
4. فراموش کردن نشانی سایت توی وردپرس. با پروکسی روی /blog، اگه تنظیم ها درست نباشن، لینک ها و فایل ها می شکنن.
5. ساخت ساب دامنه بدون لایه محافظ. فایروال و CDN باید روی همه میزبان ها فعال باشن.
6. عوض کردن ساختار بدون ریدایرکت. گران ترین اشتباهه، چون هم ترافیک رو از دست می دی هم اعتماد کاربر رو.

سوالات متداول

ساب دامنه برای سئو بده؟

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

می شه بعداً از ساب دامنه به پوشه تغییر داد؟

بله، ولی ساده نیست. باید همه آدرس های قدیمی رو با ریدایرکت 301 به آدرس جدید ببری، نقشه سایت و لینک های داخلی رو به روز کنی و چند هفته نوسان رتبه رو تحمل کنی. بهتره از اول درست انتخاب کنی.

وبلاگ وردپرسی روی هاست جدا دارم، چی کار کنم؟

ساده ترین راه ساب دامنه ست: یه رکورد DNS به سرور وبلاگ و تمام. اگه حتماً آدرس پوشه ای می خوای، باید روی سرور اصلی reverse proxy تنظیم کنی و نشانی وردپرس رو با پیشوند /blog هماهنگ کنی. این راه شدنیه، ولی نگه داری اش پیچیده تره.

ساب دامنه جدید باید جدا ثبت و تمدید بشه؟

نه. ساب دامنه بخشی از دامنه اصلی توئه و فقط با رکورد DNS ساخته می شه. ثبت یا تمدید جدا نداره، ولی اگه گواهی SSL جدا بگیری یا سرویس میزبانی جدا بخری، هزینه اون ها جداست. تمدید خود دامنه اصلی رو هم فراموش نکن: تمدید دامنه؛ اگر مهلت آن بگذرد چه اتفاقی می افتد؟.

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

برای انتخاب ساب دامنه یا پوشه لازم نیست هر معیار رو صفر تا صد بسنجی. سه تا سوال کافیه:

1. اون بخش سرور، فناوری یا تیم جدا داره؟ اگه آره، ساب دامنه.
2. کاربر باید حس کنه توی یه سایت واحده و ورودش مشترکه؟ اگه آره، پوشه.
3. حاضری هزینه نگه داری DNS، SSL و امنیت چند میزبان رو بدی؟ اگه نه، پوشه ساده تره.

اگه جواب ها با هم نخوندن، سراغ گزینه ساده تر برو. بعداً می شه پیچیده ترش کرد، ولی ساده کردن یه ساختار شلوغ خیلی سخت تره.