انتقال سایت از لوکال هاست به هاست اصلی فقط به آپلود فایلهای وردپرس محدود نمیشود. برای یک انتقال اصولی باید دیتابیس، آدرسهای داخلی، نسخه PHP، تنظیمات سرور، SSL و وضعیت ایندکس سایت نیز بهدرستی بررسی شوند.
در این آموزش، انتقال از لوکال هاست به هاست را با دو روش افزونه Duplicator و انتقال دستی بررسی میکنیم. در پایان نیز یک چکلیست سئو تکنیکال داریم تا بعد از انتقال، مشکلاتی مانند URLهای قدیمی، خطاهای 404 یا باقی ماندن noindex مانع عملکرد صحیح سایت نشوند.
پیشنیازهای حیاتی قبل از انتقال وردپرس از لوکال به هاست
قبل از شروع انتقال، مطمئن شوید هاست اصلی با نیازهای فنی سایت سازگار است. تفاوت نسخه PHP، Extensionهای فعال یا تنظیمات سرور میتواند باعث شود سایتی که روی لوکال بدون مشکل اجرا میشود، پس از انتقال با خطا مواجه شود.
تطابق نسخه PHP لوکال با هاست اصلی
ابتدا نسخه PHP محیط لوکال و هاست اصلی را بررسی کنید. لازم نیست این نسخهها همیشه دقیقاً یکسان باشند، اما بهتر است سایت را قبل از انتقال با همان نسخهای تست کنید که قرار است روی سرور اصلی استفاده شود.
این موضوع بهخصوص برای سایتهایی که از قالب یا افزونههای قدیمی، کدهای سفارشی یا توابع وابسته به نسخه مشخصی از PHP استفاده میکنند اهمیت بیشتری دارد. ناسازگاری PHP میتواند باعث Warningهای Deprecated، Fatal Error یا در برخی شرایط خطای 500 شود.
بنابراین قبل از انتقال، سازگاری وردپرس، قالب و افزونههای اصلی سایت را با نسخه PHP هاست بررسی کنید و در صورت امکان، سایت را روی همان نسخه PHP سرور مقصد تست کنید.
بررسی PHP Extensionهای موردنیاز
فقط نسخه PHP مهم نیست؛ قالب و افزونههای سایت ممکن است برای اجرای صحیح به Extensionهای مشخصی نیاز داشته باشند. مهمترین مواردی که بهتر است بررسی کنید عبارتاند از:
- mysqli: برای ارتباط وردپرس با دیتابیس MySQL یا MariaDB استفاده میشود.
- cURL: برای ارتباط سایت با APIها و سرویسهای خارجی کاربرد دارد.
- mbstring: پردازش صحیح متنهای UTF-8 و رشتههای چندبایتی را امکانپذیر میکند.
- ZIP: برای استخراج بستههای فشرده مانند قالبها، افزونهها و بهروزرسانیها کاربرد دارد.
- Imagick یا GD: برای پردازش و تغییر اندازه تصاویر استفاده میشوند؛ Imagick گزینه پیشنهادی WordPress است و GD میتواند جایگزین آن باشد.
اگر قالب یا افزونهای از فایلهای PHP رمزگذاریشده با ionCube استفاده میکند، باید ionCube Loader سازگار با نسخه PHP هاست نیز فعال باشد. برای یک سایت وردپرسی معمولی که چنین محصولی ندارد، ionCube الزامی نیست.
بکاپ و آمادهسازی انتقال نهایی
قبل از شروع انتقال، یک بکاپ کامل از فایلهای وردپرس و دیتابیس تهیه کنید تا در صورت بروز مشکل بتوانید سایت را به وضعیت قبلی برگردانید.
اگر نسخه جدید قرار است جایگزین یک سایت فعال شود، بهتر است ابتدا آن را روی Staging یا یک آدرس موقت روی هاست تست کنید. صفحات، فرمها، تصاویر، ورود کاربران و عملکرد بخشهای اصلی را بررسی کنید و فقط بعد از اطمینان از سلامت سایت، Cutover نهایی را انجام دهید.
با این روش، تغییر نسخه سایت در مرحله آخر انجام میشود و مدت اختلال برای کاربران به حداقل میرسد.
روش اول: انتقال وردپرس با Duplicator
Duplicator یکی از روشهای ساده برای انتقال وردپرس از لوکال هاست به هاست اصلی است. این افزونه فایلهای سایت و دیتابیس را در قالب یک Backup آماده میکند و سپس آنها را روی سرور مقصد بازسازی میکند.
در روش Classic، معمولاً دو فایل در اختیار شما قرار میگیرد: فایل Archive با فرمت ZIP یا DAF و فایل installer.php که مراحل انتقال را اجرا میکند. بهتر است این فایلها را در یک مسیر خالی روی سرور مقصد قرار دهید.
برای انتقال سایت مراحل زیر را انجام دهید:
- افزونه Duplicator را روی سایت لوکال نصب کنید.
- از سایت یک Backup جدید بسازید.
- فایل Archive و installer.php را دانلود کنید.
- روی هاست مقصد یک دیتابیس جدید بسازید و یک Database User با دسترسی لازم به آن اختصاص دهید.
- فایل Archive و installer.php را در مسیر خالی و قابل دسترسی از طریق وب روی هاست آپلود کنید.
- فایل Installer را از طریق مرورگر اجرا کنید. برای مثال: https://example.com/installer.php
- اطلاعات دیتابیس مقصد را وارد کنید و مراحل Installer را تا پایان ادامه دهید.
- پس از پایان انتقال، وارد پیشخوان وردپرس شوید و صفحات، تصاویر و عملکرد بخشهای اصلی سایت را بررسی کنید.
اگر قصد دارید یک سایت وردپرسی موجود را جایگزین کنید، قبل از استفاده از روش Classic مطمئن شوید مسیر مقصد برای این نوع نصب مناسب است؛ Duplicator برای سناریوهای جایگزینی سایت موجود، روشهای دیگری نیز دارد.
در پایان، فایلها و پوشههای مربوط به نصب Duplicator مانند installer.php، dup-installer و فایل Archive را از مسیر عمومی سرور حذف کنید. باقی ماندن این فایلها میتواند ریسک امنیتی ایجاد کند.
رفع خطاهای Memory Limit و Timeout در Duplicator
در سایتهای بزرگ ممکن است Duplicator هنگام ساخت Backup، Extract کردن فایلها یا Import دیتابیس با خطای کمبود منابع یا Timeout مواجه شود. تعداد زیاد فایلها، دیتابیس حجیم و محدودیت منابع هاست از دلایل رایج این مشکل هستند.
در چنین شرایطی، این تنظیمات PHP را بررسی کنید:
- memory_limit: میزان حافظهای که PHP میتواند برای اجرای فرایند استفاده کند.
- max_execution_time: حداکثر زمانی که یک پردازش PHP اجازه اجرا دارد.
- upload_max_filesize: حداکثر حجم یک فایل برای آپلود از طریق PHP.
- post_max_size: حداکثر حجم دادهای که در یک درخواست PHP ارسال میشود و باید با محدودیت آپلود هماهنگ باشد.
بسته به نوع هاست، این مقادیر ممکن است از طریق تنظیمات PHP در کنترلپنل، فایل php.ini یا .user.ini قابل تغییر باشند. در بعضی هاستهای اشتراکی نیز ممکن است برای افزایش محدودیتها نیاز به تماس با پشتیبانی داشته باشید.
اگر امکان افزایش منابع وجود ندارد، میتوانید فایلهای غیرضروری را از Backup حذف کنید یا در مشکلات مربوط به Extract از Manual Extraction استفاده کنید. برای سایتهای بسیار بزرگ، انتقال دستی ممکن است کنترل بیشتری روی فرایند مهاجرت در اختیار شما قرار دهد.
روش دوم: انتقال دستی وردپرس از لوکال هاست به هاست
در روش دستی، فایلها و دیتابیس بهصورت جداگانه منتقل میشوند. این روش نسبت به افزونههای Migration مراحل بیشتری دارد، اما کنترل دقیقتری روی دیتابیس، فایلها، Permissionها و تنظیمات سرور در اختیار توسعهدهنده قرار میدهد.
۱. اکسپورت اصولی دیتابیس و مدیریت Collation
ابتدا وارد phpMyAdmin در محیط لوکال شوید و از دیتابیس وردپرس یک خروجی با فرمت SQL بگیرید. اگر حجم دیتابیس زیاد است، میتوانید خروجی را بهصورت فشرده مانند GZIP دریافت کنید تا انتقال و آپلود آن سادهتر شود.
سپس در هاست اصلی یک دیتابیس جدید بسازید و فایل SQL را Import کنید.
در این مرحله ممکن است با خطاهای مربوط به Character Set یا Collation مواجه شوید. Character Set مشخص میکند چه کاراکترهایی در دیتابیس قابل ذخیره هستند و Collation نحوه مقایسه و مرتبسازی آنها را تعیین میکند.
در سرورهای سازگار، WordPress معمولاً از utf8mb4 استفاده میکند که نسبت به utf8 قدیمی MySQL پشتیبانی کاملتری از کاراکترهای Unicode دارد.
اگر هنگام Import با خطای Collation روبهرو شدید، این موارد را بررسی کنید:
- نسخه MySQL یا MariaDB: نسخه دیتابیس روی لوکال و هاست ممکن است متفاوت باشد.
- Collation موجود در فایل SQL: بعضی Collationهای جدید ممکن است روی نسخههای قدیمیتر دیتابیس پشتیبانی نشوند.
- سازگاری سرور مقصد: در صورت نیاز باید از Collation پشتیبانیشده توسط سرور مقصد استفاده شود. برای مثال، اگر فایل SQL از Collationی استفاده کند که Database Server مقصد آن را نمیشناسد، Import ممکن است با خطای Unknown collation متوقف شود.
مقادیر DB_CHARSET و DB_COLLATE را در یک سایت موجود بدون دلیل فنی تغییر ندهید؛ چون تغییر نادرست این تنظیمات میتواند روی نحوه ذخیره و خواندن اطلاعات دیتابیس تأثیر بگذارد.
۲. فشردهسازی و انتقال فایلهای وردپرس
بعد از انتقال دیتابیس، تمام فایلها و پوشههای وردپرس را در محیط لوکال فشرده کنید. سپس فایل ZIP را روی هاست آپلود کرده و در Document Root دامنه Extract کنید.
در هاستهای cPanel، مسیر دامنه اصلی معمولاً public_html است؛ اما برای دامنههای دیگر ممکن است Document Root متفاوتی تعریف شده باشد. بنابراین قبل از Extract کردن فایلها، مسیر صحیح دامنه را بررسی کنید.
همچنین مطمئن شوید فایلهای مخفی موردنیاز مانند .htaccess نیز همراه سایر فایلها منتقل شدهاند.
پس از انتقال، File Permissionها را بررسی کنید. مقادیر متداول در بسیاری از سرورهای لینوکسی عبارتاند از:
- پوشهها: 755
- فایلها: 644
این مقادیر برای همه سرورها یک قانون ثابت نیستند و ممکن است براساس Ownership و تنظیمات هاست متفاوت باشند. فایل حساس wp-config.php نیز بهتر است در صورت پشتیبانی سرور با دسترسی محدودتری محافظت شود.
برای رفع خطاهای دسترسی، Permission فایلها یا پوشهها را بهصورت عمومی روی 777 قرار ندهید؛ این کار میتواند امنیت سایت را کاهش دهد.
۳. اتصال دیتابیس در wp-config.php
بعد از انتقال فایلها و Import دیتابیس، باید وردپرس را به دیتابیس جدید هاست متصل کنید. فایل wp-config.php را باز کرده و اطلاعات دیتابیس مقصد را وارد کنید:
- DB_NAME: نام دیتابیس
- DB_USER: نام کاربری دیتابیس
- DB_PASSWORD: رمز عبور دیتابیس
- DB_HOST: آدرس سرور دیتابیس
مقدار DB_HOST در بسیاری از هاستها localhost است؛ اما بعضی سرویسدهندهها Host، Port یا آدرس دیگری ارائه میکنند. مقدار صحیح را از اطلاعات هاست دریافت کنید.
همچنین مقدار $table_prefix باید با پیشوند جداول Importشده یکسان باشد. برای مثال، اگر جداول دیتابیس با نامهایی مانند wp_posts و wp_options شروع میشوند، Prefix معمولاً wp_ است.
Authentication Keys و Saltهای موجود در wp-config.php را نیز بررسی کنید. تغییر این مقادیر برای انتقال سایت الزامی نیست؛ اما در صورت نیاز میتوانید Saltها را بازتولید کنید. با این کار Sessionهای فعال باطل میشوند و کاربران باید دوباره وارد حساب خود شوند.
در صورت دسترسی به SSH و WP-CLI میتوانید از دستور زیر استفاده کنید:
wp config shuffle-salts
چرا نباید URLهای localhost را دستی در دیتابیس تغییر دهیم؟
بعد از انتقال سایت، آدرسهای لوکال باید با دامنه اصلی جایگزین شوند. برای مثال:
http://localhost/myproject
باید به آدرسی مانند زیر تغییر کند:
https://example.com
اما باز کردن فایل SQL و Replace کردن ساده همه URLها بصورت دستی روش مطمئنی نیست. دلیل اصلی، وجود Serialized Data در دیتابیس وردپرس است.
در WordPress، قالبها و افزونهها ممکن است برخی تنظیمات را بهصورت Serialized ذخیره کنند. در این ساختار، علاوه بر مقدار، طول رشته نیز بخشی از داده است. اگر URL قدیمی با آدرسی با طول متفاوت جایگزین شود، ساختار داده میتواند نامعتبر شود و بعضی تنظیمات قالب یا افزونه دیگر بهدرستی خوانده نشوند.
روش امن تغییر URLها بعد از انتقال از لوکال به هاست اصلی
برای تغییر آدرس لوکال به دامنه اصلی، از ابزاری استفاده کنید که Serialized Data وردپرس را تشخیص دهد. یکی از روشهای ساده، افزونه Better Search Replace است. برای کاربران حرفهایتر، WP-CLI کنترل بیشتری روی فرایند Search & Replace فراهم میکند.
قبل از هر تغییری، از دیتابیس Backup بگیرید. سپس ابتدا دستور را با –dry-run اجرا کنید تا نتیجه جایگزینی بدون اعمال تغییر واقعی بررسی شود:
wp search-replace ‘http://localhost/myproject’ ‘https://example.com’ –all-tables-with-prefix –dry-run
اگر نتیجه صحیح بود، دستور را بدون –dry-run اجرا کنید:
wp search-replace ‘http://localhost/myproject’ ‘https://example.com’ –all-tables-with-prefix
دستور wp search-replace دادههای Serialized را مدیریت میکند و Primary Keyها را تغییر نمیدهد. گزینه –all-tables-with-prefix نیز جدولهایی را بررسی میکند که با Prefix وردپرس مطابقت دارند.
پس از تغییر URLها، کش وردپرس، افزونه Cache و CDN را پاک کنید. در پایان نیز چند صفحه، تصویر و لینک داخلی را باز کنید تا مطمئن شوید URL قدیمی در خروجی سایت باقی نمانده است.
چکلیست سئو تکنیکال بعد از انتقال به هاست اصلی
بعد از اینکه سایت روی دامنه اصلی بدون خطا اجرا شد، چند بررسی سئو باید بلافاصله انجام شود. باقی ماندن noindex، Canonical اشتباه یا URLهای لوکال میتواند باعث شود سایت از نظر کاربر سالم باشد اما موتورهای جستجو نتوانند آن را بهدرستی Crawl و Index کنند.
۱. غیرفعال کردن حالت جلوگیری از ایندکس
اگر هنگام توسعه سایت دسترسی موتورهای جستجو را محدود کردهاید، بعد از انتقال وارد مسیر زیر شوید:
تنظیمات ← خواندن
مطمئن شوید گزینه «از موتورهای جستجو بخواهید محتوای این سایت را بررسی نکنند» غیرفعال است. بعد از غیرفعال کردن آن، چند صفحه مهم را نیز بررسی کنید تا افزونه سئو، قالب یا تنظیمات خود صفحه همچنان Meta Robots را روی noindex قرار نداده باشد.
۲. بازسازی پیوندهای یکتا (URLها)
بعد از انتقال در پیشخوان وردپرس وارد مسیر تنظیمات ← پیوندهای یکتا شوید و بدون تغییر ساختار URLها، یک بار روی ذخیره تغییرات کلیک کنید. این کار Rewrite Rules وردپرس را بازسازی میکند.
اگر سایت روی Apache اجرا میشود و .htaccess قابل نوشتن باشد، وردپرس میتواند قوانین Rewrite آن را نیز بهروزرسانی کند. در Nginx فایل .htaccess وجود ندارد و Rewriteها از طریق تنظیمات خود وبسرور مدیریت میشوند.
در پایان، چند نوشته، برگه، دستهبندی و Custom Post Type را باز کنید و مطمئن شوید خطای 404 ندارند.
۳. یکسانسازی HTTP و HTTPS
بعد از فعال شدن SSL، تمام URLهای HTTP باید با Redirect دائمی به نسخه HTTPS هدایت شوند. برای مثال:
http://example.com/page
باید به آدرس زیر منتقل شود:
https://example.com/page
بهتر است Redirect در سطح Web Server یا تنظیمات هاست انجام شود. همچنین از بین نسخههای www و بدون آن یک نسخه را بهعنوان آدرس اصلی انتخاب کنید و نسخه دیگر را به آن Redirect کنید تا سیگنالهای URL سایت یکدست باشند.
بعد از اطمینان از عملکرد صحیح HTTPS میتوانید HSTS را نیز در سطح سرور فعال کنید. HSTS یک سیاست امنیتی است که به مرورگر اعلام میکند ارتباط با دامنه باید از HTTPS انجام شود و جایگزین Redirect سمت سرور نیست.
اگر قصد دارید includeSubDomains را فعال کنید و برای سایت خود زیردامنه یا همان سابدامین داشته باشید، ابتدا مطمئن شوید تمام زیردامنههای موردنیاز از HTTPS معتبر پشتیبانی میکنند؛ چون این سیاست روی آنها نیز اعمال میشود.
۴. بررسی URLهای باقیمانده از localhost
بعد از انتقال، مطمئن شوید هیچ لینک، تصویر یا فایل داخلی همچنان به آدرس لوکال اشاره نمیکند. برای این کار سایت را با یک Crawler مانند Screaming Frog یا Sitebulb بررسی کنید.
موارد مهمی که باید بررسی شوند عبارتاند از:
- URLهای شامل localhost یا 127.0.0.1
- لینکها و تصاویر 404
- خطاهای 5xx
- Redirect Chainها
- صفحات noindex ناخواسته
- Canonicalهای اشتباه
- Mixed Content یا منابعی که هنوز با HTTP بارگذاری میشوند
در Screaming Frog میتوانید از گزارش Outlinks To Localhost برای پیدا کردن لینکهای باقیمانده به localhost یا 127.0.0.1 استفاده کنید.
در پایان، دیتابیس را نیز برای عباراتی مانند localhost، 127.0.0.1 یا دامنه محلی پروژه جستجو کنید. اگر URL قدیمی پیدا شد، ابتدا مشخص کنید مربوط به چه دادهای است و برای جایگزینی Serialized Data از ابزار سازگار مانند WP-CLI Search Replace استفاده کنید.
۵. بررسی Canonical و Sitemap
چند صفحه مهم سایت را باز کنید و مطمئن شوید Canonical آنها به نسخه صحیح دامنه اصلی اشاره میکند؛ نه localhost، آدرس موقت هاست یا نسخه HTTP.
Sitemap نیز باید فقط URLهای نهایی و موردنظر برای ایندکس را شامل شود. اگر نسخه اصلی سایت روی HTTPS و بدون www اجرا میشود، همان نسخه URLها باید در Sitemap قرار گیرد.
وجود یک URL در Sitemap میتواند به Google در شناسایی نسخه موردنظر کمک کند، اما بهتنهایی تعیینکننده Canonical نیست. Redirectها، rel=”canonical” و Sitemap باید تا حد امکان سیگنال یکسانی بدهند.
۶. اتصال سایت به Google Search Console
پس از اطمینان از سلامت سایت، Property مربوط به دامنه را در Google Search Console بررسی و Sitemap را ثبت کنید.
اگر از Sitemap پیشفرض WordPress استفاده میکنید، آدرس آن معمولاً به این شکل است:
https://example.com/sitemap_index.xml
اگر از افزونه سئو استفاده میکنید، ممکن است آدرس Sitemap متفاوت باشد. ثبت Sitemap به Google برای کشف URLهای سایت کمک میکند، اما تضمینی برای Crawl یا Index شدن تمام صفحات نیست.
برای صفحات مهم مانند صفحه اصلی، صفحات خدمات یا Landing Pageهای اصلی نیز میتوانید از URL Inspection استفاده کنید تا وضعیت Crawl، Index و Canonical انتخابشده توسط Google را بررسی کنید. در صورت نیاز، امکان Request Indexing برای URLهای مهم وجود دارد.
چکلیست نهایی انتقال از لوکال به هاست اصلی
قبل از تحویل پروژه یا باز کردن سایت برای کاربران، این موارد را یک بار بررسی کنید:
- نسخه PHP هاست با وردپرس، قالب و افزونههای سایت سازگار است
- PHP Extensionهای موردنیاز پروژه روی هاست فعال هستند
- از فایلها و دیتابیس Backup سالم دارید
- تمام فایلهای وردپرس و دیتابیس بهدرستی منتقل شدهاند
- اطلاعات wp-config.php مربوط به دیتابیس اصلی است
- $table_prefix با جداول دیتابیس مطابقت دارد
- هیچ URL مهمی به localhost یا 127.0.0.1 اشاره نمیکند
- Search & Replace آدرسها با ابزار سازگار با Serialized Data انجام شده است
- صفحه اصلی، نوشتهها، برگهها و Custom Post Typeها بدون خطای 404 باز میشوند
- تصاویر و فایلهای Media بدون خطا بارگذاری میشوند
- فرمها و عملکردهای اصلی سایت تست شدهاند
- سایت از طریق HTTPS باز میشود و HTTP به نسخه اصلی Redirect میشود
- نسخههای www و non-www یکسانسازی شدهاند
- Canonicalها به URL نهایی دامنه اشاره میکنند
- گزینه جلوگیری از ایندکس WordPress غیرفعال است
- Sitemap فقط URLهای Production را دربر میگیرد
- Sitemap در Search Console ثبت شده است
- سایت از نظر 4xx، 5xx، Redirect Chain و URLهای قدیمی Crawl شده است
- فایلهای موقت Installer و Backup از مسیر عمومی سرور حذف شدهاند
جمعبندی
انتقال وردپرس از لوکال هاست به هاست زمانی کامل است که علاوه بر فایلها و دیتابیس، URLها، تنظیمات سرور و وضعیت سئوی سایت نیز بهدرستی به محیط اصلی منتقل شده باشند.
برای سایتهای کوچک و متوسط، Duplicator فرایند انتقال را سادهتر میکند؛ اما در پروژههای بزرگ یا حساس، انتقال دستی کنترل بیشتری روی فایلها و دیتابیس در اختیار توسعهدهنده قرار میدهد.
در هر دو روش، بعد از انتقال حتماً URLهای قدیمی، پیوندهای یکتا، HTTPS، Canonical، Sitemap و وضعیت Indexing را بررسی کنید. انجام این بررسیها قبل از تحویل نهایی، احتمال خطا و اختلال سایت را به حداقل میرساند.
