انتقال وردپرس به دامنه جدید؛ تغییر URL، Redirect و کنترل کامل مهاجرت

انتقال وردپرس به دامنه جدید هویت عمومی همه صفحات را تغییر می‌دهد، نه فقط آدرس سرور را. تنظیمات WordPress، مقادیر دیتابیس، Media، Cookie، TLS، Redirect، احراز هویت ایمیل، Callback API، Analytics و سیگنال‌های جست‌وجو ممکن است Host قبلی را نگه داشته باشند. مهاجرت زمانی کامل است که کاربر و سیستم بیرونی بدون گم‌شدن داده یا Redirect Loop به URL صحیح برسند.

پاسخ سریع: همه URLها و Integrationهای وابسته به دامنه را فهرست، دامنه و TLS جدید را آماده و سایت را خصوصی تست کنید. سپس URL ذخیره‌شده را با ابزار آگاه به serialization تغییر دهید. در Cutover، آخرین writeها را Sync، Redirect دائمی یک‌به‌یک از هر URL قدیمی به معادل جدید فعال، Canonical و Internal Link را اصلاح، Sitemap تمیز منتشر و دو دامنه را مانیتور کنید. مالکیت، DNS، TLS و Redirect دامنه قدیمی را بلندمدت حفظ کنید.

تغییر دامنه را از تصمیم هاست جدا کنید

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

اگر ترکیب اجتناب‌ناپذیر است، دو چک‌لیست مستقل برای زیرساخت و هویت URL داشته باشید. راهنمای انتقال وردپرس به هاست جدید فایل، دیتابیس، DNS و Rollback زیرساخت را پوشش می‌دهد.

همه وابستگی‌های دامنه قدیمی را فهرست کنید

• WordPress Address و Site Address
• محتوای نوشته، Widget، Menu، Option و داده Page Builder
• Media، CSS، JavaScript، Font و CDN Origin
• Canonical، Hreflang، Open Graph، Feed و Structured Data
• دامنه فرستنده ایمیل، SPF، DKIM و DMARC
• OAuth، پرداخت، Webhook، Storage و Callbackهای API
• Analytics، Tag Manager، تبلیغ و Consent
• Search Console، Business Profile، شبکه اجتماعی و Backlink

Source Code، Config، گزارش دیتابیس، DNS و Dashboard بیرونی را جست‌وجو کنید. Database Replace تنظیم Callback در پنل درگاه یا رکورد DNS ایمیل را تغییر نمی‌دهد.

نقشه کامل URL قدیم به جدید بسازید

در تغییر صرف دامنه، Path معمولاً باید ثابت بماند. هر صفحه قدیمی را به همان Path روی Host جدید map کنید. نوشته، صفحه، دسته، محصول، نسخه زبان، Media Page قابل‌ایندکس، Feed و URL تاریخی مهم را پوشش دهید.

اگر Path هم تغییر می‌کند، نزدیک‌ترین مقصد هر صفحه را جدا ثبت کنید. URL نامرتبط را به Home نفرستید. چک‌لیست سئو مهاجرت وردپرس ارتباط Redirect، Canonical و Crawl Verification را توضیح می‌دهد.

دامنه جدید را پیش از کپی Production آماده کنید

دسترسی Registrar، DNS authoritative، مالک تمدید و اثر DNSSEC را تأیید کنید. رکوردهای لازم را بسازید و پاسخ‌گویی مقصد به hostname جدید را بسنجید. اگر ایمیل به دامنه جدید منتقل می‌شود، احراز هویت و Provider آن را جدا آماده کنید.

دامنه قدیمی را رها نکنید. از دست‌دادن آن Redirect، پیوستگی ایمیل، بازیابی امنیتی و لینک‌هایی را که هنوز استفاده می‌شوند می‌شکند.

برای هر دو دامنه TLS معتبر نگه دارید

دامنه جدید پیش از Redirect کاربر باید Certificate معتبر و Chain کامل داشته باشد. دامنه قدیمی نیز به HTTPS معتبر نیاز دارد، چون TLS پیش از دریافت HTTP Redirect برقرار می‌شود. Certificate منقضی روی Host قدیمی مسیر Redirect را خراب می‌کند.

Apex، www، زیردامنه زبان و هر hostname عمومی را تست کنید. تمدید خودکار و TLS میان CDN و Origin را نیز کنترل کنید.

کپی آزمایشی خصوصی بسازید

فایل و دیتابیس را به مقصد کپی و با Host Resolution کنترل‌شده یا دسترسی محدود تست کنید. Preview نباید ایندکس شود یا ایمیل، پرداخت و Webhook واقعی بفرستد.

با hostname نهایی جدید تست کنید. Preview hostname موقت ممکن است مشکل Cookie، Redirect، CORS، Canonical و Mixed Content را پنهان کند.

home و siteurl را آگاهانه تغییر دهید

home آدرس عمومی سایت و siteurl محل دسترسی Core وردپرس است. اغلب برابرند، اما در layoutهای خاص می‌توانند تفاوت داشته باشند. آن‌ها را روی HTTPS مقصد تنظیم و بررسی کنید آیا WP_HOME یا WP_SITEURL مقدار دیتابیس را Override کرده است.

wp option update home 'https://new.example'
wp option update siteurl 'https://new.example'

دامنه‌ها نمونه‌اند. پیش از تغییر Production از دیتابیس Backup بگیرید و Layout مسیر را تأیید کنید.

URL ذخیره‌شده را بدون خرابی Serialized Data تغییر دهید

افزونه، قالب و Page Builder ممکن است داده PHP serialized داشته باشند که طول رشته بخشی از ساختار آن است. SQL یا Text Replace خام می‌تواند داده را خراب کند. راهنمای رسمی مهاجرت WordPress روش آگاه به serialization را توصیه می‌کند.

wp search-replace 'https://old.example' 'https://new.example' --all-tables-with-prefix --dry-run
wp search-replace 'https://old.example' 'https://new.example' --all-tables-with-prefix

پیش از Write، جدول و تعداد تغییر را بررسی کنید. HTTP، www، URL escaped، CDN و Email را جدا جست‌وجو کنید؛ Fragment گسترده دامنه را که ممکن است بخشی از ایمیل یا سرویس بیرونی باشد کورکورانه Replace نکنید.

هر Identifier را خودکار بازنویسی نکنید

GUID، License، امضای رمزنگاری، Object Key و Log تاریخی لزوماً Display URL نیستند. طبق مستند سیستم مالک رفتار کنید و فرض نکنید هر ظهور دامنه قدیمی باید تغییر کند.

پس از Replace، Host قدیمی را جست‌وجو و نتیجه را طبقه‌بندی کنید: Bug، تاریخچه قابل‌قبول یا Endpoint بیرونی نیازمند تغییر دستی.

Cookie، CORS و Security Policy را به‌روز کنید

Cookie domain، Secure setting، Allowed Origin، Content Security Policy، Firewall، OAuth Redirect URI، REST Authentication و CORS رسانه را مرور کنید. Session وابسته به دامنه ممکن است کاربران را Logout کند؛ این رفتار را پیشاپیش مشخص کنید.

برای رفع سریع، CORS را * یا کنترل امنیتی را خاموش نکنید. Origin دقیق جدید را اضافه و Rule قدیمی را پس از Verification حذف کنید.

Redirect دائمی یک‌به‌یک بسازید

هر URL قدیمی را با Redirect دائمی سمت سرور، معمولاً 301 یا 308، مستقیم به معادل جدید ببرید. Path و Query را فقط وقتی حفظ کنید که مقصد آن‌ها را می‌فهمد. Chain مانند old HTTP → old HTTPS → new HTTP → new HTTPS نسازید.

راهنمای رسمی Site Move گوگل Redirect دائمی مستقیم را توصیه و درباره مقصد نامرتبط هشدار می‌دهد. از هر Template و صفحات ارزشمند نمونه تولیدشده تست کنید.

سیگنال داخلی و Discovery را اصلاح کنید

Internal Link، Canonical، Hreflang، URL در Structured Data، Open Graph، Feed، Sitemap، Image و Form Action باید مستقیم دامنه جدید را داشته باشند. noindex و Robots مربوط به Staging را از Production حذف و Preview را محافظت‌شده نگه دارید.

Canonical باید با Redirect نهایی و Sitemap هم‌راستا باشد. HTML Renderشده و HTTP Header را ببینید، نه فقط Setting افزونه.

ایمیل و Integration بیرونی را به‌روز کنید

Sender، SMTP، SPF، DKIM، DMARC، Bounce، Webhook، OAuth Callback، Return URL درگاه، CORS Storage، Captcha، Map، Analytics، Tag Manager و API allowlist را متناسب تغییر دهید.

در صورت امکان از Sandbox استفاده کنید. موفقیت Home Page چیزی درباره Reconciliation پرداخت یا Email Authentication ثابت نمی‌کند.

همگام‌سازی نهایی کنترل‌شده اجرا کنید

1. Write محتوایی و تراکنشی را متوقف یا سایت را موقتاً read-only کنید.
2. آخرین دیتابیس و Upload را Sync کنید.
3. URL Replacement بازبینی‌شده را روی Dataset نهایی اجرا کنید.
4. Config، Cache، Redirect، TLS و Transaction اصلی را بسنجید.
5. ترافیک را منتقل و Worker Production را فقط روی محیط منتخب فعال کنید.

اگر Write پیوسته الزام است، معماری مهاجرت بدون Downtime وردپرس را استفاده کنید.

مهاجرت را از بیرون اعتبارسنجی کنید

URL قدیم و جدید را با HTTP Client و Browser تست کنید. Status، Redirect، Canonical، Robots، Language Alternate، Content، Media و Structured Data را تأیید کنید. هر دو فهرست URL را Crawl کنید تا Loop، Chain، 404، Mixed Content و مرجع Host قبلی پیدا شود.

Login، Password Reset، Form، تحویل ایمیل، Cron، Search، Checkout، Callback و Mobile را تست و Log تازه برنامه و Proxy را بررسی کنید.

Search و پلتفرم‌های بیرونی را مطلع کنید

Propertyهای لازم Search Console را Verify، Sitemap Canonical جدید را ثبت و در صورت کاربرد فرایند جاری Change of Address را دنبال کنید. Analytics، تبلیغ، Business Listing، Social Profile و Backlinkهای ارزشمند را اصلاح کنید.

Sitemap، دامنه یا Redirect قدیمی را زود حذف نکنید. موتور جست‌وجو و کاربر برای کشف دوباره URLها زمان می‌خواهند.

دامنه قدیمی را نگهداری و مانیتور کنید

Crawl Error، Redirect Hit، Indexing، Traffic، Conversion، Server Error و شکست Callback را پایش کنید. Log دامنه قدیمی URLهای ارزشمندی را نشان می‌دهد که در Inventory نبودند.

Google عموماً نگهداری Redirect حداقل یک سال و هرچه طولانی‌تر را توصیه می‌کند؛ برای کاربر نگهداری دائمی اغلب بهتر است. Registration، DNS و TLS را بر همین اساس حفظ کنید.

Rollback را برای دو فضای URL طراحی کنید

پس از عمومی‌شدن دامنه جدید، بازگرداندن کامل URL ممکن است کاربر و Crawler را سردرگم کند. مشخص کنید Rollback فقط Origin برنامه را برمی‌گرداند و URL جدید را حفظ می‌کند یا کل URL Migration را معکوس می‌کند. حالت اول معمولاً ساده‌تر است.

سفارش، Upload، Account، ایمیل و Callback تازه را نیز در نظر بگیرید؛ برگشت DNS داده برنامه را reconcile نمی‌کند.

اشتباه‌های رایج تغییر دامنه

• Replace کردن Fragment دامنه با SQL خام
• فراموش‌کردن Constantهای Overrideکننده URL
• Redirect همه صفحات قدیمی به Home
• منقضی‌شدن Certificate دامنه قدیمی
• باقی‌ماندن Canonical یا noindex مربوط به Staging
• نادیده‌گرفتن Email Authentication و Callback
• ساخت Redirect Chain بین Hostnameها
• رهاکردن دامنه قدیمی

چه زمانی پشتیبانی حرفه‌ای مفید است؟

Inventory بزرگ، مسیر چندزبانه، تراکنش ووکامرس، Callback سفارشی یا سابقه تغییر دامنه، Mapping و Verification را پیچیده می‌کند. سرویس انتقال سایت وردپرس می‌تواند Backup، URL Replacement، Redirect، Cutover و کنترل پس از انتقال را پوشش دهد.

پرسش‌های متداول

می‌توان فقط دامنه را عوض و هاست را ثابت نگه داشت؟

بله؛ اما URL وردپرس، TLS، Redirect، Integration و سیگنال Search همچنان باید مهاجرت کنند.

آیا GUIDهای وردپرس را تغییر دهیم؟

کورکورانه خیر. معنا و استفاده افزونه‌ها متفاوت است؛ بر اساس مدل داده واقعی و مستندات اقدام کنید.

دامنه قدیمی را تا چه مدت نگه داریم؟

مالکیت، DNS، TLS و Redirect را بلندمدت حفظ کنید. Google معمولاً حداقل یک سال را توصیه می‌کند و کاربر ممکن است بسیار طولانی‌تر به لینک قدیمی متکی باشد.

آیا کاربران دوباره Login می‌کنند؟

اغلب بله، چون Cookie به دامنه وابسته است. Cart، Membership و SSO را تست و اثر مورد انتظار را اطلاع‌رسانی کنید.