قبل از تغییر DNS چگونه سایت منتقل‌شده را تست کنیم؟
چک‌لیست تست سایت روی هاست مقصد پیش از تغییر DNS: اتصال آزمایشی، SSL، صفحات و فرمها، تازگی داده‌ها و تصمیم انتقال یا توقف؛ بدون دست‌کاری عجولانه سایت زنده.
هاستلینو۵ دقیقه مطالعه
فهرست مطالب
قبل از تغییر DNS، نسخه منتقل‌شده را با همان نام دامنه روی هاست مقصد بررسی کنید؛ دیدن صفحه اصلی از یک IP یا آدرس موقت برای تصمیم نهایی کافی نیست. هدف این آزمون آن است که خطاهای انتقال را پیش از هدایت کاربران پیدا کنید و مشخص باشد کدام داده‌ها، اتصال‌ها و مسیرها هنوز نیاز به هماهنگی دارند.
این راهنما برای جابه‌جایی هاست با حفظ دامنه است. اگر نام دامنه نیز عوض می‌شود، برنامه ریدایرکت، URLهای داخلی و canonical جداگانه لازم است. برای ترتیب کامل کار، چک‌لیست انتقال وردپرس را کنار این مرحله نگه دارید.
۱. پیش از تست، نسخه مقصد را از محیط واقعی جدا کنید
نام هاست، IP مقصد، زمان آخرین کپی فایل و دیتابیس و نام مسئول انتقال را ثبت کنید. صرف بالا آمدن سایت مشخص نمی‌کند به کدام سرور وصل شده‌اید. از میزبان بخواهید یک نشانه موقت و غیرحساس برای تشخیص مقصد فراهم کند؛ اطلاعات اتصال و رمزها را در صفحه عمومی قرار ندهید.
نسخه آزمایشی می‌تواند به درگاه، پیامک، ایمیل یا webhook واقعی وصل باشد. پیش از آزمایش فرم و خرید، خروجی این اتصال‌ها را در محیط تست مهار کنید تا پیام، سفارش یا برداشت واقعی ایجاد نشود. تنظیمات مقصد را بدون بررسی روی مبدأ اعمال نکنید. وضعیت بکاپ و روش بازگردانی را هم طبق چک‌لیست بکاپ و بازیابی مشخص کنید.
۲. دامنه را فقط برای آزمون به IP جدید متصل کنید
یکی از راه‌ها نگاشت موقت دامنه به IP مقصد در فایل hosts دستگاه آزمایش است. این تغییر DNS عمومی کاربران را جابه‌جا نمی‌کند. دامنه اصلی و www را، اگر هر دو استفاده می‌شوند، جداگانه در نظر بگیرید. نام دقیق، IP و روش بازگرداندن تغییر را از میزبان بگیرید؛ آدرس نمونه را روی دستگاه خود کپی نکنید.
راه دیگر برای یک درخواست، گزینه resolve در curl است. مثال زیر فقط الگوست؛ IP مستنداتی 192.0.2.10 مقصد واقعی نیست:
curl --resolve example.com:443:192.0.2.10 https://example.com/
این روش اتصال را به IP مشخص می‌برد و نام دامنه را برای HTTPS نگه می‌دارد. تست curl جای بررسی تعاملی مرورگر را نمی‌گیرد. اگر سایت به دامنه دیگری ریدایرکت می‌شود، مقصد ریدایرکت را هم بررسی کنید؛ ممکن است ادامه مسیر دوباره به سرور قدیمی برسد. خطای گواهی را با نادیده‌گرفتن اعتبار SSL پنهان نکنید.
۳. چک‌لیست کنترل نسخه منتقل‌شده
| بخش | چه چیزی بررسی شود؟ | معیار تصمیم |
|---|---|---|
| اتصال و SSL | دامنه درست، مقصد واقعی و اعتبار گواهی | بدون هشدار گواهی یا برگشت ناخواسته به مبدأ |
| صفحات داخلی | چند نوشته، دسته، محصول و مسیر فارسی | مسیرهای مهم محتوای درست نشان دهند؛ فقط خانه کافی نیست |
| رسانه و فایل | تصویر قدیمی و جدید، فایل قابل دانلود و فونت | فایل مفقود و اتصال اشتباه به آدرس موقت مشخص و رفع شود |
| ورود و نشست | ورود و خروج حساب مجاز در محیط تست | نشست و مجوزها مطابق انتظار باشند؛ داده حساب دیگر نمایش داده نشود |
| فرم و فروشگاه | اعتبارسنجی، سبد و نتیجه backend در محیط تست | ثبت تکراری یا ارسال پیام و پرداخت واقعی رخ ندهد |
| SEO و پاسخ خطا | canonical، robots، سایت‌مپ و یک مسیر ناموجود | آدرس موقت وارد خروجی نشود؛ صفحه ناموجود پاسخ مناسب داشته باشد |
برای هر مورد نتیجه، زمان، تصویر یا لاگ غیرحساس و اقدام بعدی را بنویسید. برچسب «کار می‌کند» بدون اشاره به صفحه و سناریو، برای پیگیری خطا کافی نیست. اگر خطای داخلی دیدید، ابتدا مسیر بررسی خطای ۵۰۰ وردپرس را دنبال کنید؛ چند تنظیم نامرتبط را هم‌زمان تغییر ندهید.
۴. داده تازه و سرویسهای وابسته را فراموش نکنید
سفارشی که پس از تهیه کپی در سایت زنده ثبت شده، لزوماً در مقصد نیست. زمان آخرین همگام‌سازی، مهلت توقف نوشتن و مرجع نهایی داده باید قبل از انتقال روشن باشند. در فروشگاه، فقط شمار محصولات را مقایسه نکنید؛ سفارش‌ها، موجودی، کاربران و فایل‌های تازه نیز مهم‌اند. دو نسخه فعال با امکان نوشتن مستقل می‌توانند داده متفاوت تولید کنند.
ایمیل دامنه، رکوردهای MX و TXT، سرویسهای بیرونی و کارهای زمان‌بندی‌شده فهرست جدا می‌خواهند. تغییر رکورد وب به معنی انتقال ایمیل نیست. اگر DNS را پشت CDN یا پراکسی مدیریت می‌کنید، مسیر آزمون مستقیم سرور و رفتار مسیر عمومی را جدا ثبت کنید؛ نتیجه یکی، تأیید همه مسیرها نیست.
۵. چه زمانی DNS را تغییر بدهیم؟
| وضعیت | تصمیم پیشنهادی |
|---|---|
| SSL، مسیرهای اصلی و داده نهایی تأیید شده‌اند | انتقال در بازه هماهنگ، با مسئول مشخص و امکان پایش انجام شود |
| فرم، ورود یا مسیر مهم خطا دارد | تغییر DNS متوقف بماند تا خطا رفع و همان سناریو دوباره بررسی شود |
| تازگی داده یا برنامه بازگشت نامشخص است | انتقال نهایی انجام نشود؛ مسئول داده و روش بازگشت تعیین شوند |
برنامه بازگشت فقط بازگرداندن یک IP نیست: اگر مقصد داده تازه گرفته باشد، بازگشت می‌تواند آن داده را جا بگذارد. معیار توقف و روش نگهداری یا انتقال داده تازه را از قبل تعیین کنید. بعد از جابه‌جایی عمومی، نگاشت آزمایشی دستگاه را حذف کنید و از مسیر عادی دوباره بررسی کنید؛ اثر کش DNS ممکن است مشاهده دستگاه‌ها را متفاوت کند.
برای کمک در تست و انتقال از کجا شروع کنیم؟
نوع سایت، دامنه، محل هاست فعلی، زمان آخرین کپی و خطای مشاهده‌شده را آماده کنید. در درخواست پشتیبانی سایت، ابتدا محدوده بررسی و دسترسی لازم روشن می‌شود؛ رمز و اطلاعات حساس را در فرم عمومی ننویسید. اگر مقصد را هنوز انتخاب نکرده‌اید، صفحه هاست وردپرس را برای بررسی منابع و شرایط سرویس ببینید؛ انتخاب پلن جای آزمون انتقال را نمی‌گیرد.
منابع فنی
پیش از تغییر DNS، خطاهای انتقال را بررسی کنید
شرح وضعیت، هاست مبدأ و مقصد و نتیجه آزمون را آماده کنید؛ محدوده بررسی و هزینه پیش از اقدام مشخص می‌شود.
پرسش‌های متداول
آیا دیدن صفحه اصلی روی IP جدید برای انتقال کافی است؟
خیر. دامنه و SSL، صفحات داخلی، ورود، فرمها و داده تازه باید بررسی شوند. دسترسی با IP ممکن است همان رفتار دامنه واقعی و سرویسهای وابسته را نشان ندهد.
