بهترین پسوند دامنه؛ انتخاب بین .ir، .com و new gTLD

یک دامنه ممکن است در سال اول ارزان و هوشمندانه به نظر برسد، اما از سال دوم با تمدید Premium، محدودیت پرداخت ارزی، خطای فرم‌ها در پذیرش پسوند جدید یا سردرگمی مشتری در شنیدن آدرس ایمیل، به گران‌ترین جزء هویت دیجیتال تبدیل شود. برعکس، یک نام کوتاه روی پسوندی ناآشنا می‌تواند در تست واقعی کاربران بهتر از یک دامنهٔ طولانی با .com عمل کند. بنابراین «بهترین پسوند دامنه» یک پاسخ جهانی ندارد؛ باید آن را با بازار، برند، هزینهٔ مالکیت و ریسک عملیاتی انتخاب کرد.

این راهنما برای مدیر محصول، بنیان‌گذار و مدیر بازاریابی ایرانی نوشته شده است. تفاوت .ir، .com، پسوندهای جدید یا new gTLD و پسوندهای کشوری را روشن می‌کند، اثر واقعی آن‌ها بر سئو را از ادعاهای تبلیغاتی جدا می‌کند و یک روش قابل‌ممیزی برای انتخاب، خرید، آزمایش و مهاجرت دامنه می‌دهد. وضعیت استانداردها و منابع در ۱۵ مرداد ۱۴۰۵ / ۶ اوت ۲۰۲۶ بازبینی شده است؛ قیمت و قرارداد هر پسوند را هنگام خرید دوباره کنترل کنید.

پاسخ کوتاه: .ir، .com یا new gTLD؟

اگر بازار اصلی شما ایران است، .ir می‌تواند نامزد جدی باشد؛ اگر مخاطب بین‌المللی و دامنهٔ مناسب در دسترس دارید، .com معمولاً از نظر آشنایی کاربر نقطهٔ شروع خوبی است؛ و اگر یک پسوند جدید نام برند را کوتاه، دقیق و به‌یادماندنی می‌کند، فقط پس از بررسی هزینهٔ تمدید، Premium بودن، سازگاری ایمیل و فرم‌ها و حقوق علامت آن را انتخاب کنید. هیچ‌کدام به‌تنهایی کیفیت برند، امنیت یا رتبهٔ گوگل را تضمین نمی‌کنند.

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

اصطلاحات را درست تفکیک کنیم

«پسوند جدید» نام همهٔ پسوندهای مدرن یا محبوب نیست. این اشتباه باعث می‌شود سیاست Registry، هدف‌گیری جغرافیایی و ریسک حقوقی را نادرست ارزیابی کنیم.

بر اساس پایگاه Root Zone در IANA، .ai پسوند کشوری آنگویلا و .io پسوند کشوری قلمرو اقیانوس هند بریتانیا هستند؛ پس new gTLD نیستند. بااین‌حال، گوگل در فهرست جاری خود هر دو را برای هدف‌گیری جغرافیایی مانند یک دامنهٔ عمومی می‌بیند. «نوع ثبتی در DNS» و «رفتار فعلی یک موتور جست‌وجو» دو موضوع جدا هستند و ممکن است سیاست‌ها در آینده تغییر کنند.

اثر پسوند دامنه بر سئو؛ ادعا و واقعیت

موضع رسمی گوگل روشن است: سیستم‌های جست‌وجو new gTLD را مانند gTLDهای دیگر می‌بینند و وجود کلمهٔ کلیدی در TLD، مزیت یا جریمهٔ ذاتی رتبه‌بندی نمی‌سازد. در نتیجه brand.shop صرفاً به‌دلیل واژهٔ shop بالاتر از brand.com رتبه نمی‌گیرد. این توضیح در راهنمای رسمی گوگل دربارهٔ TLDهای جدید آمده است.

چه چیزهایی اثر مستقیمِ اثبات‌شده نیستند؟

• کلمهٔ صنعت در پسوند، جای محتوای مفید، لینک داخلی و اعتبار موضوعی را نمی‌گیرد.
• نمی‌توان گفت پسوند .store به‌طور عمومی نرخ کلیک را بالا می‌برد؛ این یک فرضیهٔ رفتاری است و باید برای مخاطب همان برند آزمایش شود.
• ترافیک مستقیم یا «مدرن به نظر رسیدن» مجوز ادعای بهبود رتبه نیست.
• استفادهٔ یک شرکت بزرگ از یک پسوند، موفقیت پسوند را ثابت نمی‌کند؛ برند، بودجه، توزیع و سابقهٔ آن شرکت متغیرهای مخدوش‌کننده‌اند.

پسوند کجا به‌طور غیرمستقیم مهم می‌شود؟

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

ccTLDها موضوع دیگری‌اند. طبق مستند جاری گوگل برای سایت‌های چندمنطقه‌ای، یک ccTLD معمولاً سیگنال قویِ هدف‌گیری یک کشور است؛ در مقابل، gTLD عمومی به کشور خاصی وابسته نیست. گوگل بعضی ccTLDهای موسوم به Vanity، از جمله .ai و .io، را فعلاً عمومی می‌بیند. بنابراین برای بازار ایران، .ir می‌تواند سیگنال مکانی باشد، اما کیفیت محتوا و تجربهٔ کاربر را تضمین نمی‌کند.

حداقل سئوی دامنهٔ انتخاب‌شده

1. یک نسخهٔ Canonical از دامنه و پروتکل انتخاب کنید و تمام نسخه‌های دیگر را مستقیم به آن ۳۰۱ کنید.
2. URL کوتاه و پایدار بسازید؛ کلمهٔ کلیدی را با زور در نام دامنه تکرار نکنید.
3. Title، H1، محتوا و لینک داخلی را بر پایهٔ نیت کاربر بهینه کنید؛ چک‌لیست سئوی داخلی هر صفحه برای همین کار است.
4. برای بازارهای زبانی/کشوری متفاوت، URL مستقل، hreflang و Canonical هماهنگ داشته باشید.
5. پس از راه‌اندازی، Coverage، Query، CTR، خطای Crawl و ایندکس را پایش کنید و با ممیزی کامل سئو شاهد بسازید.

اول بازار را انتخاب کنید، بعد پسوند را

دامنه باید با «بازار واقعی سه سال آینده» سازگار باشد، نه صرفاً پرسونای امروز. یک فروشگاه فارسی که پرداخت، ارسال و پشتیبانی آن فقط در ایران است، مسئله‌ای متفاوت از SaaS فارسی با مشتریان منطقه یا شرکت صادراتی با چند زبان دارد.

برای یک کمپین، لندینگ یا محصول فرعی فوراً دامنهٔ تازه نسازید. زیرپوشهٔ example.com/product/ یا زیردامنه می‌تواند مالکیت، Analytics، امنیت و اعتبار را متمرکز نگه دارد. دامنهٔ مستقل زمانی توجیه دارد که مخاطب، برند، ریسک یا مسیر خروج واقعاً مستقل باشد.

آزمون برند: دامنه را ببینید، بشنوید و تایپ کنید

تست لوگو کافی نیست. نام را در شرایطی بسنجید که مشتری آن را در تماس تلفنی، پیام‌رسان، فاکتور، رادیو، QR، ایمیل و صفحهٔ ورود می‌بیند.

تست پنج‌ثانیه‌ای با کاربر واقعی

1. دامنه را پنج ثانیه نشان دهید و پنهان کنید؛ از کاربر بخواهید آن را بنویسد.
2. فقط نام را بلند بخوانید؛ ببینید نقطه، خط تیره و پسوند را درست تشخیص می‌دهد یا نه.
3. یک ایمیل نمونه مانند support@brand.tld را نشان دهید و بپرسید واقعی به نظر می‌رسد یا فیشینگ.
4. دامنه را روی موبایل فارسی و انگلیسی، کیبوردهای مختلف و حالت RTL آزمایش کنید.
5. پس از یک روز، Recall بدون کمک را اندازه بگیرید.

نمونهٔ حداقل ۱۰ تا ۱۵ نفر برای تصمیم آماری قطعی کافی نیست، اما خطاهای شدید تلفظ و املاء را آشکار می‌کند. اگر دو گزینه نزدیک‌اند، یک تست بزرگ‌تر با مخاطبان واجدشرایط اجرا کنید و معیارهایی مانند Recall، خطای تایپ، اعتماد و تکمیل فرم را از پیش تعریف کنید.

Domain hack و نام‌های خلاقانه

ترکیب واژه با پسوند—به‌طوری که نقطه داخل کلمه قرار گیرد—می‌تواند کوتاه باشد، اما هزینهٔ شناختی دارد. کاربران ممکن است نقطه را حذف کنند، موتورهای اعتبارسنجی قدیمی آن را نپذیرند یا پسوند متعلق به یک قلمرو با سیاست متفاوت باشد. دامنهٔ خلاقانه را فقط وقتی اصلی کنید که در تست شنیداری، تایپ و ایمیل بهتر از گزینهٔ معمولی باشد.

پسوندهای موضوعی را چگونه ارزیابی کنیم؟

فهرست «بهترین پسوندهای امسال» عمر کوتاهی دارد. به‌جای رتبه‌بندی ترندها، خانوادهٔ پسوند را بر اساس کارکرد بررسی کنید:

• حوزهٔ تخصص: مانند .tech، .design یا .law. محدودیت صلاحیت و انتظار کاربر را بررسی کنید.
• تجارت: مانند .shop و .store. وضوح نیت خوب است، اما اعتماد و تبدیل باید در بازار خودتان آزموده شود.
• محصول نرم‌افزاری: مانند .app و .dev. سیاست فنی، الزام HTTPS یا محدودیت‌های Registry را پیش از انتخاب بخوانید.
• اجتماع و مکان: پسوندهای شهری یا منطقه‌ای ممکن است از نظر گوگل gTLD باشند، حتی اگر ظاهری جغرافیایی داشته باشند.
• ccTLD بازاریابی‌شده به‌شکل عمومی: مانند .ai و .io. محبوبیت فنی، ماهیت کشوری و ریسک سیاست Registry را حذف نمی‌کند.

هیچ پسوندی «ضرورت» یک صنعت نیست. یک شرکت هوش مصنوعی برای معتبر بودن به .ai نیاز ندارد و یک فروشگاه با .shop خودبه‌خود قابل‌اعتماد نمی‌شود. بهترین نام، نامی است که در تمام معیارهای برند، عملیات و حقوق امتیاز کافی بگیرد.

قیمت واقعی: TCO پنج‌ساله، نه تخفیف سال اول

قیمت صفحهٔ خرید ممکن است فقط هزینهٔ ثبت اولیه باشد. از Registrar بخواهید تمام نرخ‌ها را برای نام دقیق شما نشان دهد؛ زیرا یک نام Premium می‌تواند قیمت ثبت، انتقال یا تمدید متفاوت داشته باشد.

فرمول سادهٔ تصمیم:

TCO پنج‌ساله = ثبت + چهار تمدید + انتقال/بازیابی احتمالی + ثبت‌های دفاعی + DNS و ایمیل + زمان عملیات + ذخیرهٔ ریسک ارزی

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

Registry و Registrar را با هم اشتباه نگیرید

Registry اپراتور پایگاه و سیاست یک TLD است؛ Registrar فروشنده و مدیر رابط ثبت دامنه برای شماست. قیمت عمده، نام‌های Premium و برخی سیاست‌ها می‌توانند از Registry بیایند؛ اما کیفیت پنل، پشتیبانی، احراز هویت، Lock، صورتحساب و تجربهٔ انتقال به Registrar مربوط است.

چک‌لیست ارزیابی Registrar

• مالک ثبتی سازمان باشد، نه کارمند، آژانس یا توسعه‌دهنده.
• ورود دومرحله‌ای مقاوم، نقش‌های جدا و تاریخچهٔ تغییر داشته باشد.
• Domain/Transfer Lock، مسیر بازیابی حساب و تأیید تغییرهای حساس روشن باشد.
• AuthInfo و امکان انتقال در قرارداد پنهان نشده باشد. راهنمای انتقال ICANN محدودیت‌های متداول و نیاز به AuthInfo را توضیح می‌دهد.
• قیمت ثبت، تمدید، انتقال، Redemption و Premium شفاف باشد.
• کانال پرداخت جایگزین و هشدار تمدید برای چند مالک وجود داشته باشد.
• امکان خروج را با یک دامنهٔ کم‌ریسک یا پرسش کتبی از پشتیبانی آزمایش کنید.

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

برای gTLDها، از ۲۸ ژانویهٔ ۲۰۲۵ RDAP منبع قطعی ارائهٔ دادهٔ ثبت عمومی به‌جای WHOIS قدیمی شده است. ICANN Lookup مبتنی بر RDAP را برای Registrar، وضعیت‌ها و تاریخ‌ها بررسی کنید. اطلاعات شخصی ممکن است به‌دلایل حریم خصوصی عمومی نباشد؛ نبود نام مالک در خروجی، به‌تنهایی نشانهٔ مشکل نیست.

1. نوع TLD و مدیر آن را در Root Zone IANA کنترل کنید.
2. Registrar، وضعیت Lock، تاریخ ایجاد و انقضا و Name Serverها را در RDAP ببینید.
3. نسخه‌های تاریخی سایت، عنوان‌ها و نوع محتوای قبلی را بررسی کنید.
4. Backlinkها را از نظر ارتباط، Spam و Anchorهای نامعمول تحلیل کنید؛ برچسب مبهم «لیست سیاه گوگل» کافی نیست.
5. نام را در پایگاه‌های علامت تجاری و جست‌وجوی وب برای شباهت گیج‌کننده بررسی کنید.
6. شواهد و تاریخ بررسی را در پروندهٔ خرید نگه دارید.

سابقهٔ قدیمی لزوماً بد نیست و دامنهٔ تازه هم پاک‌بودن آینده را تضمین نمی‌کند. تصمیم را بر شواهد قابل مشاهده بگذارید و اگر مسئلهٔ حقوقی یا مالکیت مبهم است، پیش از پرداخت از متخصص حقوقی حوزهٔ مربوط مشورت بگیرید.

علامت تجاری و ثبت دفاعی

آزاد بودن یک دامنه به معنای آزاد بودن حق استفاده از نام نیست. شباهت گیج‌کننده به علامت دیگری می‌تواند اختلاف، هزینهٔ تغییر برند یا انتقال دامنه ایجاد کند. راهنمای UDRP در WIPO توضیح می‌دهد که این سازوکار برای اختلاف‌های ثبت و استفادهٔ سوء از دامنه در gTLDها و ccTLDهای پذیرفته‌شده کاربرد دارد؛ برخی ccTLDها نسخهٔ محلی سیاست را دارند.

همهٔ صدها TLD و غلط املایی را نخرید. ثبت دفاعی را با مدل تهدید محدود کنید:

• دامنهٔ اصلی و چند خطای تایپی پرتکرار که واقعاً می‌تواند برای فیشینگ استفاده شود؛
• پسوند بازارهای فعال یا برنامه‌ریزی‌شده، نه همهٔ کشورها؛
• نام‌های کمپین مهم با تاریخ انقضا و مالک مشخص؛
• پایش سوءاستفاده و Runbook پاسخ، چون خرید همهٔ ترکیب‌ها ممکن نیست.

Universal Acceptance؛ دامنه معتبر است، اما فرم آن را رد می‌کند

اعتبار در DNS تضمین نمی‌کند که همهٔ نرم‌افزارها دامنه یا ایمیل را بپذیرند. ICANN، Universal Acceptance را توان پذیرش، ذخیره، پردازش و نمایش همهٔ نام‌های معتبر—از جمله TLDهای جدید و بلند، IDN و نشانی‌های ایمیل—تعریف می‌کند. اعتبارسنجی‌های قدیمی ممکن است فقط پسوندهای دو یا سه‌حرفی را مجاز بدانند یا نام Unicode را خراب کنند.

ماتریس تست پذیرش

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

ایمیل و تحویل‌پذیری؛ پسوند فقط یکی از متغیرهاست

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

• رکوردهای MX، SPF، DKIM و DMARC را طراحی و صحت‌سنجی کنید.
• از صندوق‌های سازمانی به ارائه‌دهندگان اصلی و سرویس‌های مورد استفادهٔ مشتریان ایرانی پیام آزمایشی بفرستید.
• Reply، Forward، Reset password، دعوت تیم و رسید تراکنش را انتهابه‌انتها تست کنید.
• دامنهٔ ایمیل را ناگهانی عوض نکنید؛ آدرس‌های قدیمی را برای دوره‌ای بلند فعال نگه دارید.
• برای تحلیل DNS و ایمیل به راهنمای مدیریت DNS، DNSSEC، TTL و مهاجرت رجوع کنید.

امنیت و حاکمیت دامنه

ربوده‌شدن حساب Registrar می‌تواند وب، ایمیل و احراز هویت همهٔ سرویس‌ها را هم‌زمان مختل کند. دامنه را یک دارایی Tier-۰ در نظر بگیرید.

نسخهٔ پشتیبان Zone، فهرست رکوردها و دسترسی‌ها را خارج از همان حساب نگه دارید. برای طراحی RPO، RTO و آزمون بازگردانی، Runbook بازیابی فاجعه و Backup سایت را به برنامهٔ دامنه متصل کنید.

ملاحظات ویژهٔ انتخاب دامنه برای کسب‌وکار ایرانی

برای تیم ایرانی، انتخاب فنی خوب اگر تمدید و کنترل حساب پایدار نباشد، خوب نیست. این ریسک‌ها را در جلسهٔ تصمیم ثبت کنید:

• پرداخت و تحریم: وابستگی به یک کارت، واسطه یا هویت شخصی می‌تواند تمدید و بازیابی را متوقف کند. شرایط خدمت و حوزهٔ قضایی Registrar را بخوانید و از اطلاعات نادرست استفاده نکنید.
• نوسان ارز: بودجه را با نرخ بدبینانه و تمدید Premium بسنجید، نه فقط قیمت تبلیغاتی امروز.
• مالکیت: شناسه، ایمیل، شمارهٔ بازیابی و اسناد باید تحت کنترل سازمان و قابل تحویل به مدیر بعدی باشد.
• شبکه: Resolve، TLS، سایت و ایمیل را از چند اپراتور داخل ایران و یک نقطهٔ خارج آزمایش کنید؛ نتیجهٔ یک VPN نمایندهٔ همهٔ کاربران نیست.
• پشتیبانی: زمان پاسخ در تعطیلات، زبان پشتیبانی و مسیر Escalation برای حادثهٔ DNS/Transfer را بسنجید.
• .ir: قواعد ثبت، مدارک، حل اختلاف و مالکیت را در منبع رسمی و برای نوع شناسهٔ خود کنترل کنید. شرایط یک دامنهٔ عمومی را به آن تعمیم ندهید.
• بازار بین‌المللی: فقط به‌خاطر امکان ثبت یک gTLD، دسترسی پایدار مشتری، درگاه، ایمیل و سرویس‌های ثالث تضمین نمی‌شود.

یک الگوی مقاوم، جداسازی Registrar از DNS Authoritative، نگهداری مالکیت سازمانی، چند مسیر بازیابی و مستندسازی خروج است. این معماری وابستگی را صفر نمی‌کند، اما شعاع خرابی یک حساب یا واسطه را کاهش می‌دهد.

ماتریس امتیازدهی انتخاب پسوند دامنه

برای جلوگیری از تصمیم سلیقه‌ای، هر گزینه را از ۱ تا ۵ امتیاز دهید و وزن‌ها را پیش از دیدن قیمت نهایی تصویب کنید.

امتیاز نهایی = مجموع (امتیاز ۱ تا ۵ × وزن معیار)

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

آزمایشگاه دامنه پیش از تغییر برند

پیش از چاپ بسته‌بندی، ساخت کمپین یا انتقال سایت، دامنهٔ نامزد را در یک Pilot محدود فعال کنید:

1. DNS، TLS، Redirect و یک صفحهٔ آزمایشی راه‌اندازی کنید.
2. ایمیل‌های تراکنشی و انسانی را روی یک گروه داخلی اجرا کنید.
3. نام را در فرم‌ها، CRM، SSO، Analytics، تبلیغات، شبکه‌های اجتماعی و ابزار پشتیبانی ثبت کنید.
4. تست کاربرِ Recall، تایپ، اعتماد و فیشینگ را با مخاطب ایرانی انجام دهید.
5. از چند ISP و دستگاه داخل و خارج ایران Resolve و Load را بسنجید.
6. قیمت و قرارداد را Snapshot بگیرید و یک نفر مستقل مسیر Transfer/Recovery را مرور کند.
7. نتایج را در Scorecard ثبت و فقط پس از عبور از Gateها خرید بلندمدت یا مهاجرت را تصویب کنید.

Gate پیشنهادی: صفر شکست در مسیرهای حیاتی، مالکیت و بازیابی اثبات‌شده، TCO مصوب و امتیاز اعتماد/Recall بهتر یا دست‌کم هم‌سطح گزینهٔ فعلی. «زیبا به نظر رسیدن» معیار انتشار نیست.

اگر دامنه را عوض می‌کنیم، چه کنیم؟

تغییر .com به یک new gTLD یا برعکس، تغییر سادهٔ لوگو نیست؛ Site move است. گوگل نیز تغییر پسوند را مانند سایر مهاجرت‌های دامنه می‌بیند و پردازش آن زمان می‌برد.

پیش از مهاجرت

• تمام URLهای قابل ایندکس، فایل‌ها، Canonical، Sitemap، Redirect و Backlinkهای مهم را Inventory کنید.
• مالکیت هر دو دامنه را در Search Console و ابزارهای دیگر تأیید کنید.
• نقشهٔ یک‌به‌یک URL قدیم به معادل جدید بسازید؛ همه را به صفحهٔ اصلی نفرستید.
• DNS، گواهی، CDN، Email و Rollback را پیش‌تولید آزمایش کنید.
• Baseline رتبه، Query، Click، Index، Crawl، Conversion و خطای ۴۰۴ بگیرید.

روز انتشار و پس از آن

1. Redirect ۳۰۱ مستقیمِ هر URL را فعال کنید و زنجیره نسازید.
2. Canonical، لینک داخلی، Sitemap، hreflang، Structured Data و Feed را به دامنهٔ جدید تغییر دهید.
3. خطاهای ۴۰۴/5xx، Loop، Mixed content، DNS و TLS را لحظه‌ای پایش کنید.
4. آدرس‌های ایمیل قدیمی را نگه دارید و تغییر را مرحله‌ای به مشتریان و شرکا اعلام کنید.
5. Backlinkهای حیاتی و پروفایل‌های رسمی را به مقصد جدید اصلاح کنید.
6. دامنهٔ قدیمی و Redirectهای آن را بلندمدت حفظ کنید؛ حذف زودهنگام ریسک ترافیک، ایمیل و سوءاستفاده را بالا می‌برد.

افت کوتاه‌مدت ممکن است رخ دهد و هیچ تیمی نباید «بدون افت قطعی» وعده بدهد. با Baseline، Rollback و پایش می‌توان ریسک را مدیریت کرد. عملکرد صفحهٔ جدید را نیز با Core Web Vitals و دادهٔ واقعی کاربران جدا از اثر مهاجرت کنترل کنید.

حاکمیت Portfolio دامنه

پس از انتخاب، یک دامنهٔ اصلی Canonical داشته باشید. دامنه‌های دفاعی و غلط‌های تایپی فقط Redirect شوند و سایت‌های تکراری نسازند. برای هر دامنه این فیلدها را نگه دارید: هدف، مالک کسب‌وکاری، مالک فنی، Registrar، Registry، تاریخ تمدید، قیمت، وضعیت Premium، روش پرداخت، DNS، ایمیل، Lock، DNSSEC، علامت، مقصد Redirect و تاریخ بازبینی.

هر فصل Portfolio را پاک‌سازی کنید: دامنهٔ کمپین منقضی را بی‌برنامه رها نکنید؛ ابتدا وابستگی ایمیل، لینک، Cookie، OAuth و مشتری را بررسی و سپس دربارهٔ نگهداری یا خروج تصمیم بگیرید. دامنهٔ رهاشده می‌تواند برای جعل برند بازثبت شود.

برنامهٔ ۳۰روزهٔ انتخاب و راه‌اندازی

چک‌لیست نهایی پیش از پرداخت

• نوع دقیق TLD و مدیر Registry در IANA بررسی شد.
• بازار هدف و معماری بین‌المللی سه‌ساله نوشته شد.
• نام در تست تلفظ، تایپ، Recall و اعتماد قبول شد.
• جست‌وجوی علامت و اختلاف احتمالی انجام شد.
• ثبت، تمدید، Premium، انتقال، Grace و Redemption مستند شد.
• TCO پنج‌ساله و سناریوی ارز تصویب شد.
• فرم، ایمیل، CRM، SSO، تبلیغات و اپ در تست UA گذشتند.
• مالک سازمانی، ۲FA، Lock، بازیابی و چند هشدار تمدید فعال شد.
• DNSSEC، CAA، ایمیل و مانیتورینگ با Runbook تنظیم شد.
• اگر مهاجرت است، نقشهٔ ۳۰۱ یک‌به‌یک، Baseline و Rollback آماده است.
• دامنهٔ اصلی Canonical و نقش دامنه‌های دفاعی مشخص است.
• مالک بازبینی فصلی Portfolio تعیین شد.

سؤالات متداول دربارهٔ بهترین پسوند دامنه

برای کسب‌وکار ایرانی .ir بهتر است یا .com؟

اگر بازار، پرداخت و پشتیبانی عمدتاً ایران است، .ir نامزد منطقی است و هدف جغرافیایی روشنی دارد. برای برند بین‌المللی، .com یا یک gTLD عمومی ممکن است انعطاف بیشتری بدهد. دسترس‌بودن نام، اعتماد کاربر، مالکیت، تمدید و برنامهٔ بازار را با Scorecard مقایسه کنید؛ هیچ پاسخ مطلقی وجود ندارد.

آیا new gTLD برای سئو بهتر از .com است؟

خیر. گوگل می‌گوید TLD جدید مانند gTLDهای دیگر پردازش می‌شود و کلمهٔ داخل پسوند مزیت رتبه‌بندی ذاتی ندارد. نام می‌تواند بر رفتار انسان اثر بگذارد، اما CTR، Recall و اعتماد باید برای همان مخاطب آزمایش شوند و نباید به‌عنوان سیگنال قطعی رتبه ادعا شوند.

آیا .ai یک پسوند دامنهٔ جدید است؟

نه. طبق IANA، .ai ccTLD آنگویلا است. گوگل آن را فعلاً در فهرست ccTLDهایی قرار می‌دهد که برای هدف‌گیری جغرافیایی مانند gTLD دیده می‌شوند. محبوبیت آن در صنعت هوش مصنوعی، نوع ثبتی و سیاست Registry را تغییر نمی‌دهد.

دامنهٔ Premium فقط هنگام خرید گران است؟

نه همیشه. مدل قیمت به TLD و نام دقیق بستگی دارد و ممکن است ثبت، تمدید یا انتقال نرخ متفاوتی داشته باشد. پیش از خرید، قیمت Renewal همان نام را به‌صورت کتبی بگیرید و در TCO پنج‌ساله ثبت کنید؛ تخفیف سال اول معیار خوبی نیست.

تغییر پسوند دامنه باعث افت سئو می‌شود؟

تغییر دامنه Site move است و پردازش آن زمان می‌برد؛ نوسان کوتاه‌مدت ممکن است رخ دهد. Redirect ۳۰۱ یک‌به‌یک، اصلاح Canonical و لینک داخلی، Sitemap، تأیید هر دو دامنه، حفظ دامنهٔ قدیمی و پایش Search Console ریسک را کاهش می‌دهد، اما هیچ تضمین «بدون افت» وجود ندارد.

جمع‌بندی

بهترین پسوند دامنه، پسوندی نیست که ترندتر یا ارزان‌تر باشد؛ گزینه‌ای است که نام برند را برای مخاطب درست روشن می‌کند، در پنج سال قابل‌پرداخت و قابل‌تمدید است، در ایمیل و نرم‌افزارها کار می‌کند، با حقوق دیگران تعارض ندارد و مالکیت و خروج آن تحت کنترل سازمان است. .ir، .com و new gTLD را با یک Scorecard و Pilot یکسان بسنجید. اگر شواهد برابر بود، گزینهٔ ساده‌تر و کم‌ریسک‌تر معمولاً تصمیم بهتری است.