تغییر هاست وردپرس فقط به معنی کپی کردن چند فایل از یک سرور به سرور دیگر نیست. اگر فایل‌ها و دیتابیس منتقل شوند اما DNS، SSL، کش، تنظیمات PHP یا دسترسی Googlebot درست بررسی نشوند، سایت ممکن است بعد از انتقال با خطای 500، کندی، صفحه سفید یا اختلال در Crawl روبه‌رو شود.
در این راهنما، فرایند تغییر هاست WordPress را از ابتدا تا انتها بررسی می‌کنیم؛ از بکاپ و انتخاب روش انتقال گرفته تا تست هاست جدید، DNS Cutover و کنترل وضعیت سئو. اگر دامنه و URLهای سایت ثابت بمانند و انتقال با تست کافی انجام شود، می‌توان ریسک قطعی و نوسان سئو را تا حد زیادی کاهش داد.
قبل از تغییر هاست وردپرس چه کارهایی انجام دهیم؟
مهم‌ترین کار قبل از تغییر هاست وردپرس این است که نسخه سالمی از سایت داشته باشید. از تمام فایل‌های وردپرس و دیتابیس بکاپ بگیرید و مطمئن شوید Backup قابل دانلود و بازیابی است. اگر فقط از فایل‌ها نسخه پشتیبان داشته باشید اما دیتابیس را از دست بدهید، نوشته‌ها، تنظیمات، سفارش‌ها و بخش بزرگی از اطلاعات سایت منتقل نخواهند شد.
همزمان مشخصات فنی هاست جدید را نیز بررسی کنید. نسخه PHP، Extension موردنیاز، فضای دیسک، دیتابیس، SSL و منابع سرور باید با سایت سازگار باشند. برای یک سایت فروشگاهی یا پرترافیک، بهتر است قبل از Cutover مشخص کنید در فاصله بین بکاپ اولیه و انتقال نهایی با سفارش‌ها، فرم‌ها و اطلاعات تازه چه می‌کنید تا داده جدید روی هاست قدیمی جا نماند. قبل از شروع این موارد را آماده کنید:
- بکاپ کامل فایل‌ها و دیتابیس
- اطلاعات ورود به هاست قدیمی و هاست جدید
- دسترسی به DNS دامنه یا پنل ثبت دامنه
- اطلاعات دیتابیس مقصد
- نسخه PHP و نیازمندی‌های اصلی قالب و افزونه‌ها
- SSL معتبر روی سرور جدید
- یک بازه کم‌ترافیک برای Cutover نهایی، به‌خصوص در سایت‌های فروشگاهی
اگر امکان تغییر TTL رکوردهای DNS را دارید، بهتر است چند روز قبل از انتقال و ترجیحاً حدود یک هفته زودتر مقدار آن را کاهش دهید. این کار کمک می‌کند هنگام تغییر IP، کش DNS سریع‌تر منقضی شود و کاربران زودتر به سرور جدید هدایت شوند. بعد از پایدار شدن انتقال می‌توانید TTL را به مقدار معمول برگردانید.
آموزش انتقال وردپرس از یک هاست به هاست دیگر
برای انتقال وردپرس سه مسیر رایج وجود دارد. افزونههای Migration برای سایت‌های معمولی ساده‌تر هستند، انتقال دستی کنترل بیشتری به شما میدهد و انتقال Server-to-Server با SSH برای سایت‌های حجیم می‌تواند زمان جابه‌جایی فایل‌ها را کاهش دهد.
|
روش انتقال |
مناسب برای | مزیت اصلی | محدودیت اصلی |
|
افزونه Migration |
سایت‌های کوچک و متوسط |
اجرای ساده و سریع |
وابستگی بیشتر به منابع و محدودیت‌های هاست |
|
انتقال دستی |
بیشتر سایت‌های وردپرسی |
کنترل کامل روی فایل و دیتابیس |
نیاز به دقت بیشتر |
| SSH و rsync | سایت‌های حجیم و سرورهای دارای SSH | انتقال مستقیم و مناسب فایل‌های زیاد |
نیاز به دسترسی و تجربه خط فرمان |
روش اول: انتقال با افزونههای وردپرس
افزونه‌هایی مانند افزونه Duplicator و All-in-One WP Migration می‌توانند فایل‌ها و دیتابیس سایت را در یک بسته Migration قرار دهند و فرایند انتقال را ساده‌تر کنند. اگر سایت حجم معقولی دارد و با خط فرمان یا دیتابیس راحت نیستید، این روش نقطه شروع خوبی است.
در Duplicator معمولاً از سایت Backup می‌سازید، فایل بسته و Installer را به مقصد منتقل می‌کنید و مراحل بازیابی را روی هاست جدید انجام می‌دهید. در All-in-One WP Migration نیز می‌توانید از سایت Export بگیرید و فایل خروجی را در نصب وردپرس مقصد Import کنید. فرایند کلی در هر دو روش شبیه این است:
- از سایت فعلی Backup یا Export بگیرید
- فایل خروجی را در یک محل امن نگه دارید
- هاست و دیتابیس مقصد را آماده کنید
- Backup را روی مقصد Import یا Restore کنید
- بعد از انتقال، ورود به پیشخوان، صفحات، تصاویر و فرم‌ها را تست کنید
این روش برای سایت‌های کوچک و متوسط راحت است، اما روی هاست‌های محدود ممکن است با Timeout، کمبود Memory یا محدودیت Upload روبه‌رو شوید. در All-in-One WP Migration، اندازه Import می‌تواند تحت تأثیر محدودیت‌های PHP و وب‌سرور هاست باشد؛ بنابراین یک عدد ثابت را برای تمام سرویس‌ها در نظر نگیرید. Duplicator نیز برای Backupهای سنگین ممکن است به تنظیم منابع، حذف فایل‌های غیرضروری یا روش‌های جایگزین Extract نیاز داشته باشد.
برای سایت‌های بزرگ، فروشگاه‌های پرترافیک یا سرورهایی که محدودیت زیادی دارند، انتقال دستی یا Server-to-Server معمولاً کنترل بیشتری در اختیار شما قرار میدهد.
روش دوم: انتقال دستی از طریق cPanel یا DirectAdmin
در روش دستی، فایل‌ها و دیتابیس را جداگانه منتقل می‌کنید. این روش چند مرحله بیشتر دارد، اما دقیقاً می‌دانید چه چیزی روی هاست جدید قرار گرفته و اگر مشکلی پیش بیاید، پیدا کردن علت ساده‌تر است.
ابتدا File Manager هاست قدیمی را باز کنید و تمام فایل‌های وردپرس را از Document Root سایت فشرده کنید. فایل ZIP را دانلود کنید یا در صورت امکان مستقیماً به سرور جدید انتقال دهید. سپس از دیتابیس سایت با phpMyAdmin یا ابزار مدیریت دیتابیس هاست یک خروجی SQL بگیرید.
روی هاست جدید، فایل‌ها را در Document Root صحیح دامنه Upload و Extract کنید. بعد یک دیتابیس و Database User جدید بسازید، دسترسی لازم را به User بدهید و فایل SQL را Import کنید. در مرحله بعد فایل wp-config.php را باز کنید و اطلاعات دیتابیس مقصد را وارد کنید:
- DB_NAME: نام دیتابیس جدید
- DB_USER: نام کاربری دیتابیس
- DB_PASSWORD: رمز عبور دیتابیس
- DB_HOST: آدرس سرور دیتابیس که در بسیاری از هاست‌ها localhost است، اما می‌تواند متفاوت باشد
- پیشوند جداول دیتابیس باید با Prefix جداول Importشده هماهنگ باشد
اگر دامنه و URLهای سایت تغییر نمی‌کنند، نیازی نیست صرفاً به دلیل تغییر هاست تمام URLهای دیتابیس را Search & Replace کنید. هدف این انتقال حفظ همان دامنه و همان ساختار URL است.
بعد از اتصال دیتابیس، سایت را باز کنید و چند صفحه داخلی را تست کنید. اگر Permalinkها خطای 404 دارند، در پیشخوان به تنظیمات و سپس به بخش پیوندهای یکتا بروید و بدون تغییر ساختار، یک بار تنظیمات را ذخیره کنید تا Rewrite Rules بازسازی شوند.
روش سوم: انتقال سرور به سرور با SSH و rsync
برای سایتی که چندین گیگابایت فایل یا پوشه uploads بزرگی دارد، دانلود فایل‌ها روی کامپیوتر و Upload دوباره آن‌ها می‌تواند زمان‌بر باشد. اگر روی سرور قدیمی و جدید SSH دارید، rsync می‌تواند فایل‌ها را مستقیماً بین دو سیستم منتقل کند و در اجرای مجدد فقط تفاوت‌ها را همگام کند.
یک نمونه ساده از ساختار دستور به این شکل است و باید مسیرها، نام کاربری و Host را با اطلاعات واقعی سرور خود جایگزین کنید:
rsync -avz /path/to/site/ user@new-server:/path/to/site/
قبل از اجرای دستور روی سایت واقعی، مسیر مبدأ و مقصد را دقیق بررسی کنید. انتقال فایل‌ها با rsync جای انتقال دیتابیس را نمی‌گیرد؛ دیتابیس همچنان باید Dump و روی سرور جدید Import شود. برای سایت‌هایی که در زمان Migration تغییرات زیادی دارند، می‌توان یک Sync اولیه انجام داد و نزدیک Cutover فایل‌های تغییرکرده را دوباره همگام کرد.
تست و دیباگ هاست جدید قبل از انتقال ترافیک
بعد از کپی فایل و دیتابیس، DNS را بلافاصله تغییر ندهید. اول نسخه موجود روی سرور جدید را تست کنید تا کاربران واقعی وارد محیطی نشوند که هنوز مشکل دارد.
برای تست می‌توانید از Temporary URL، یک Hostname آزمایشی یا در صورت آشنایی فنی از Hosts File سیستم خود استفاده کنید تا دامنه برای کامپیوتر شما به IP جدید Resolve شود، در حالی که کاربران عادی هنوز سایت را از سرور قدیمی می‌بینند. در این مرحله موارد زیر را بررسی کنید:
- صفحه اصلی و چند صفحه داخلی مهم
- ورود و خروج کاربران و پیشخوان وردپرس
- فرم تماس، فرم ثبت‌نام و جستجوی سایت
- تصاویر، فایل‌های دانلودی و Media Library
- سبد خرید، Checkout و درگاه پرداخت در فروشگاه‌ها
- ایمیل‌های ارسالی وردپرس و WooCommerce
- SSL و باز شدن سایت با HTTPS
- Cron Jobها و پردازش‌های زمان‌بندی‌شده
بررسی افزونههای کش و فایل .htaccess روی هاست جدید
یکی از خطاهای رایج بعد از تغییر هاست، انتقال تنظیماتی است که برای سرور قبلی نوشته شده‌اند. کش سمت سرور، Object Cache، Redis، CDN یا Ruleهای سفارشی ممکن است روی زیرساخت جدید رفتار دیگری داشته باشند.
اگر سایت روی Apache یا وب‌سروری سازگار با .htaccess اجرا میشود، Rewriteها و Ruleهای امنیتی این فایل را بررسی کنید. روی Nginx، فایل .htaccess مبنای تنظیم Rewrite نیست و باید تنظیمات در سطح خود وب‌سرور انجام شوند. بعد از انتقال نیز Cache افزونه‌ها، Cache سمت سرور و CDN را پاک کنید تا نسخه قدیمی فایل‌ها نمایش داده نشود.
بررسی Error Log برای پیدا کردن خطاهای PHP
اینکه سایت ظاهراً باز میشود به معنی سالم بودن کامل Migration نیست. Error Log سرور را بررسی کنید تا مشکلات پنهانی مثل Fatal Error، Warningهای مهم PHP، خطای Permission یا خطای اتصال به سرویس‌های جانبی مشخص شوند.
اگر بعد از انتقال فقط یک افزونه یا بخش خاص مشکل دارد، نسخه PHP،Extensionهای فعال، Permission فایل‌ها و تنظیمات همان افزونه را با هاست قبلی مقایسه کنید. این بررسی قبل از DNS Cutover بسیار کم‌هزینه‌تر از دیباگ کردن سایت در زمان حضور کاربران واقعی است.
سوییچ نهایی و انتقال ترافیک به هاست جدید
وقتی نسخه جدید کامل تست شد، زمان DNS Cutover است، یعنی DNS دامنه را طوری تغییر دهید که درخواست‌های جدید به زیرساخت تازه برسند.
اگر سایت فروشگاهی یا پویا است، درست قبل از Cutover یک Backup نهایی از دیتابیس بگیرید یا تغییرات جدید را با مقصد همگام کنید. این کار از جا ماندن سفارش، کامنت یا ثبت‌نامی که بعد از Backup اولیه ایجاد شده جلوگیری می‌کند.
تغییر DNS یا Name Server به هاست جدید
برای انتقال هاست الزاماً نباید Name Server دامنه را تغییر دهید. اگر DNS روی سرویس مستقلی مثل یک DNS Provider مدیریت میشود، ممکن است فقط کافی باشد رکورد A دامنه را به IPv4 جدید و در صورت استفاده، رکورد AAAA را به IPv6 جدید تغییر دهید.
اگر قرار است مدیریت DNS نیز به شرکت هاست جدید منتقل شود، ممکن است Name Serverهای دامنه تغییر کنند. قبل از این کار تمام رکوردهای ضروری را بررسی کنید؛ به‌خصوص MX، TXT، SPF، DKIM، DMARC و رکوردهای Subdomain. حذف ناخواسته این رکوردها می‌تواند ایمیل یا سرویس‌های جانبی را مختل کند، حتی اگر خود سایت بدون مشکل باز شود.
چگونه وضعیت انتشار DNS را بررسی کنیم؟
با ابزارهایی مثل dig، nslookup یا DNS Checkerهای آنلاین، دامنه را از چند Resolver مختلف بررسی کنید و مطمئن شوید IP جدید برگردانده میشود. در کنار آن، Access Log هاست قدیمی را نیز کنترل کنید؛ با کامل‌تر شدن انتقال، تعداد درخواست‌های سرور قدیمی باید به‌تدریج کاهش پیدا کند.
بررسی سایت بعد از انتقال ترافیک
بعد از Cutover همان تست‌های قبل را دوباره روی دامنه اصلی انجام دهید. تفاوت این مرحله در این است که اکنون کاربران و Botها نیز به سرور جدید می‌رسند و مشکلات مربوط به DNS، SSL، Firewall و Cache بهتر مشخص می‌شوند. این موارد را دوباره کنترل کنید:
- صفحه اصلی و Landing Pageهای مهم با Status Code صحیح باز شوند
- ورود کاربران، فرم‌ها و عملیات مهم سایت کار کنند
- تصاویر و فایل‌های استاتیک 404 نداشته باشند
- HTTPS و Certificate برای دامنه درست باشند
- Redirectهای قدیمی همچنان فعال باشند
- ایمیل‌های تراکنشی ارسال شوند
- روی فروشگاه، یک سفارش آزمایشی تا حد ممکن تست شود
چک‌لیست سئو تکنیکال پس از تغییر هاست
اگر در این Migration فقط Hosting تغییر کرده و دامنه، پروتکل و URLها ثابت مانده‌اند، معمولاً نیازی به Redirect جدید یا Change of Address نیست. با این حال باید مطمئن شوید زیرساخت جدید همان محتوای قبلی را با پاسخ‌های صحیح و بدون محدودیت Crawl ارائه میدهد.
بعد از انتقال موارد زیر را بررسی کنید:
- URLهای مهم همان آدرس قبلی را داشته باشند
- Canonicalها به URL صحیح اشاره کنند
- robots.txt به اشتباه Googlebot را Block نکند
- Meta Robots صفحات مهم روی noindex باقی نمانده باشد
- Sitemap با Status Code صحیح در دسترس باشد
- HTTP به HTTPS و Redirectهای قدیمی به‌درستی کار کنند
- خطاهای 404 و 5xx افزایش غیرعادی نداشته باشند
- Search Console Verification بعد از انتقال همچنان معتبر باشد
بررسی خطاهای Crawl و 5xx بعد از انتقال
برای خطاهای فوری سرور، اول از همه Error Log و Access Log هاست جدید را بررسی کنید. Search Console برای مشاهده روند Crawl و مشکلات ایندکس مفید است، اما ابزار Real-Time Monitoring سرور نیست و ممکن است داده‌ها با فاصله زمانی نمایش داده شوند.
در روزهای بعد از Migration، گزارش‌های Search Console را بررسی کنید و به افزایش خطاهای 5xx مثل 500، 502، 503 یا 504 حساس باشید. اگر چنین خطاهایی ظاهر شدند، منابع سرور، PHP-FPM، دیتابیس، Cache و Ruleهای امنیتی را بررسی کنید.
بررسی TTFB و مقایسه با هاست قدیمی
TTFB یا Time to First Byte مدت زمانی است که از شروع درخواست تا رسیدن اولین بایت پاسخ از سمت هاست طول می‌کشد. این معیار می‌تواند برای مقایسه واکنش زیرساخت قبلی و جدید مفید باشد، اما فقط به قدرت هاست وابسته نیست؛ DNS، شبکه، Cache، CDN و پردازش Backend نیز روی آن اثر دارند.
برای مقایسه درست، چند URL یکسان را قبل و بعد از انتقال در شرایط مشابه تست کنید. اگر TTFB بعد از انتقال به‌طور محسوسی بدتر شده است، تنظیمات Cache، PHP، دیتابیس، Location سرور و منابع CPU/RAM را بررسی کنید. هدف این مرحله پیدا کردن Regression است، نه رسیدن به یک عدد ثابت برای همه سایت‌ها.
تست دسترسی Googlebot به هاست جدید
بعد از Cutover چند URL مهم را در URL Inspection سرچ کنسول بررسی کنید و در صورت نیاز Test Live URL را اجرا کنید. این تست کمک می‌کند مطمئن شوید Google می‌تواند نسخه زنده صفحه را Fetch کند و Firewall یا تنظیمات امنیتی مانع دسترسی نشده‌اند.
اگر Live Test با خطا روبه‌رو شد اما سایت برای شما باز میشود، Firewall، WAF، Security Plugin، محدودیت جغرافیایی و Ruleهای Block IP را بررسی کنید. همچنین robots.txt و Meta Robots را کنترل کنید تا نسخه آزمایشی که قبل از Migration روی noindex یا Block بوده، با همان تنظیمات وارد Production نشده باشد.
چه زمانی هاست قبلی را حذف کنیم؟
خاموش کردن هاست قبلی باید آخرین مرحله باشد، نه بخشی از Cutover اولیه. ابتدا مطمئن شوید کاربران و Botها به سرور جدید می‌رسند و هیچ سرویس مهمی به IP یا فایل‌های هاست قدیمی وابسته نیست. پیش از لغو سرویس قدیمی این موارد را بررسی کنید:
- DNS از Resolverهای مختلف به IP جدید Resolve میشود؟
- ترافیک در Access Log هاست قدیمی به صفر یا نزدیک صفر رسیده است؟
- فرم‌ها، پرداخت و ایمیل روی سرور جدید سالم هستند؟
- آیا Googlebot به زیرساخت جدید دسترسی دارد؟
- یک Backup مستقل و قابل بازیابی از سایت دارید؟
بعد از اطمینان از این موارد می‌توانید هاست قبلی را غیرفعال کنید. بهتر است Backup نهایی آن را برای مدتی در فضایی جدا از هاست جدید نگه دارید.
جمع‌بندی
تغییر هاست وردپرس زمانی امن‌تر انجام میشود که آن را به سه مرحله جدا تقسیم کنید: انتقال اطلاعات، تست کامل سرور جدید و سپس DNS Cutover. بزرگ‌ترین اشتباه این است که بلافاصله بعد از کپی فایل‌ها DNS را تغییر دهید و تازه روی سایت زنده شروع به پیدا کردن خطاها کنید.
اگر دامنه و URLها ثابت بمانند، سرور جدید قبل از انتقال ترافیک تست شود و بعد از Cutover وضعیت 5xx، TTFB و دسترسی Googlebot را بررسی کنید، احتمال ایجاد اختلال جدی برای کاربران و سئو بسیار کمتر خواهد شد.
