خرید دامنه .app

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

.app یک پسوند عمومی است و Google Registry آن را اداره می‌کند. داشتن نام در این پسوند به معنی تأیید اپلیکیشن توسط Google یا پذیرش در فروشگاه‌های برنامه نیست. نام دامنه مجوز انتشار، گواهی سلامت فایل یا تضمین حفظ داده کاربر صادر نمی‌کند. اگر برنامه نیاز به مجوز یا شرایط استفاده ویژه دارد، آن را جدا بررسی کنید. برای معرفی محصولی که اپلیکیشن بخش اصلی آن است، .app ارزش مقایسه دارد؛ برای مجموعه‌ای با چند نوع خدمت، نام شرکت در یک پسوند عمومی دیگر و آدرس جدا برای برنامه هم می‌تواند مناسب باشد.

ثبت دامنه و تهیه گواهی دو کار جدا هستند. گواهی باید نامی را که کاربر باز می‌کند پوشش دهد و روی سرویس درست نصب شود. اگر نشانی اصلی و نسخه دارای www یا زیر دامنه ورود دارید، پوشش نام‌ها را بررسی کنید. روش صدور، نصب، تمدید و هزینه گواهی را از ارائه‌دهنده میزبانی بپرسید؛ ثبت .app این کارها را خودکار انجام نمی‌دهد. راهنمای تنظیم HTTPS و دریافت گواهی کنار اعلان خرید قرار دارد تا پیش از خرید بتوانید نیاز میزبانی را بشناسید.

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

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

در استفاده از .app باید قوانین قابل اعمال به فعالیت خود را رعایت کنید؛ از جمله قواعد حریم خصوصی، جمع‌آوری و افشای داده، حمایت از مصرف‌کننده و جلوگیری از معرفی گمراه‌کنندهٔ خدمات. برای فعالیت‌هایی مانند خدمات مالی، الزامات قانونی همان فعالیت نیز برقرار است. اگر در برنامه اطلاعات حساس سلامت یا مالی جمع‌آوری و نگهداری می‌کنید، اقدامات امنیتی معقول و متناسب با آن خدمت و قوانین مربوط لازم است. داشتن نام .app یا اتصال HTTPS به‌تنهایی این مسئولیت‌ها را انجام نمی‌دهد. در زمان ثبت .app نیز این شرایط بخشی از تعهدات متقاضی است.

دوره ثبت را از گزینه‌های معتبر سفارش انتخاب کنید. در مسیر فعلی Joker، حداقل دوره .app یک سال است و قرارداد رجیستری ثبت‌های اولیه را در گام‌های یک‌ساله تا سقف ده سال تعریف می‌کند. موجود بودن یک مدت در شرایط بالادستی به معنی عرضه همه مدت‌ها در هر سفارش نیست؛ گزینه و قیمت روز ارائه‌شده را ببینید. مبلغ ثبت، تمدید و انتقال در بخش‌های جدا نشان داده می‌شوند. برای مقایسه واقعی، مبلغ کامل دوره انتخابی و هزینه ادامه استفاده را در نظر بگیرید، نه فقط عدد اول معرفی.

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

اعلان HTTPS را قبل از پرداخت بخوانید و مطمئن شوید میزبانی انتخابی شما امکان اجرای آن را دارد. سپس نام کامل، صاحب امتیاز، ایمیل، دوره و جمع سفارش را مرور کنید. نتیجه آزاد بودن برای شما نام را نگه نمی‌دارد؛ ثبت زمانی کامل است که تأیید آن را دریافت کنید. پس از موفقیت، تاریخ انقضا و اطلاعات حساب را نگه دارید. اگر هنوز برنامه را عمومی نکرده‌اید، اول اتصال دامنه و HTTPS را آزمایش کنید و بعد آدرس را در توضیح فروشگاه، تبلیغ و کدهای QR قرار دهید.

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

در سیاست .app، رجیستری پس از حذف ثبت واجد شرایط، دوره بازیابی سی‌روزه را تعریف کرده است. این دوره از حذف شروع می‌شود و با سی روز فرصت قطعی پس از انقضای مشتری یکسان نیست؛ حذف در بازه آغاز ثبت نیز استثنا دارد. سیاست‌های ارائه‌دهنده و وضعیت نام بر مسیر اقدام اثر دارند. اگر انقضا رخ داد، وضعیت همان نام و هزینه عملیات موجود را سریع بررسی کنید. در شرح وضعیت EPPِ ICANN، دامنه بازیابی‌نشده پنج روز تقویمی پس از پایان دوره بازیابی حذف می‌شود؛ این زمان از انقضا آغاز نمی‌شود. درخواست بازگردانی یا وضعیت‌های دیگر دامنه، مسیر متفاوتی دارند. پس از پایان دورهٔ بازیابی بدون بازگرداندن دامنه، در مرحلهٔ حذف نهایی امکان معمول تمدید یا بازیابی ندارید.

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

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

در راهنمای Joker، انتقال موفق بسیاری از پسوندهای عمومی معمولاً با افزودن یک سال همراه است، اما نتیجه نهایی به وضعیت ثبت و محدودیت اعتبار بستگی دارد. این موضوع وعده یکسان برای هر سفارش نیست و هزینه انتقال را باید برای همان عملیات ببینید. درباره دامنه نزدیک انقضا یا دامنه‌ای که به تازگی تمدید شده، اثر بر تاریخ را قبل از پرداخت بررسی کنید. پس از انتقال موفق، تاریخ تازه و دامنه در حساب جدید را کنترل کنید. پیام شروع انتقال با تکمیل آن یکی نیست.

انتقال مدیریت ثبت، فایل‌های برنامه، پایگاه داده، ایمیل یا گواهی را جابه‌جا نمی‌کند. پیش از کار، رکوردهای DNS و مسیر نگهداری گواهی را ثبت کنید. اگر API، ورود کاربر یا لینک بازگشت پرداخت روی این نام قرار دارد، آنها را در فهرست بررسی محصول بیاورید. هنگام تغییر میزبانی، گواهی معتبر و تنظیم HTTPS باید روی مقصد آماده باشد. بعد از تغییر، روی گوشی و مرورگر واقعی ورود، صفحه دریافت برنامه و ارتباط سرویس‌های لازم را امتحان کنید. دامنه .app بدون آماده بودن اتصال امن وب، مسیر مناسبی برای معرفی نسخه تازه نخواهد بود.

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

در مقایسه با .com، .dev یا پسوندهای دیگر، تناسب موضوع، مدت ثبت، قیمت روز و آمادگی میزبانی را کنار هم بگذارید. اگر تیم برای HTTPS هنوز برنامه‌ای ندارد، ابتدا نیاز فنی استفاده از .app را حل کند. اگر محصول یک سایت محتوایی بدون اپلیکیشن است، شاید نام در پسوند دیگری بهتر به مخاطب توضیح دهد چه می‌بیند. انتخاب پسوند، تضمین رتبه در Google یا افزایش نصب برنامه نیست. صفحه معرفی خوب، مسیر دریافت معتبر و پاسخ‌گویی تیم، بخش جدا از کیفیت ارائه محصول هستند.

برای تصمیم نهایی از جستجوی همین صفحه آغاز کنید و اگر نام دلخواه آزاد نبود، پسوندهای دیگر را در صفحه ثبت دامنه ببینید. بعد از ثبت، یک مسیر آزمایشی ساده بسازید: باز شدن صفحه با HTTPS، ورود به راهنما، پیوند نسخه معتبر و راه تماس با تیم. نتیجه را پیش از معرفی عمومی بررسی کنید. نام دامنه، میزبانی، گواهی و انتشار برنامه هر کدام کار مشخص خود را دارند؛ هماهنگ بودن آنها کمک می‌کند آدرسی که روی محصول نوشته‌اید برای کاربر واقعاً قابل استفاده باشد.