نقل موقع ووردبريس بدون توقّف

النقل الخاطئ (تحويل الـDNS قبل تجهيز الوجهة) يسبّب رسائل خطأ وفقدان زيارات وتراجعًا في ترتيب محركات البحث. الطريقة الصحيحة منهجية وآمنة وقابلة للتراجع في أي لحظة. السبب أن موقعك في الواقع يعيش في مكانين أثناء النقل: نسخة قديمة كاملة لا تزال تعمل، ونسخة جديدة تُجهّزها بهدوء بعيدًا عن أعين الزوّار. ما دامت النسخة القديمة شغّالة ولم تُحوّل الـDNS، فلا أحد يلاحظ شيئًا — وهذا بالضبط سرّ صفر-توقّف. هذا الدليل يغطّي العملية كاملةً خطوة بخطوة: لماذا تنقل ومتى، أنواع النقل وطرقه، التحضير الصحيح، النقل اليدوي بالتفصيل، استراتيجية تحويل الـDNS، التحقّق بعد النقل، وحلول المشاكل التي قد تواجهك.

لماذا تنقل موقعك أصلًا؟ ومتى يكون النقل قرارًا صحيحًا؟

النقل ليس هواية؛ كل نقل يحمل مخاطرة ولو صغيرة، لذا لا تنقل إلا لسبب واضح يستحق العناء. في الممارسة، الأسباب التي تبرّر النقل تقع في ثلاث عائلات: تغيير الاستضافة، تغيير الدومين، ودمج/تقسيم المواقع.

تغيير الاستضافة (السبب الأشهر)

أغلب عمليات النقل سببها أن الاستضافة الحالية لم تعد تناسب الموقع:

• بطء أو عدم استقرار: صفحات تتأخّر في التحميل، أو انقطاعات متكرّرة (downtime) تظهر في تقارير المراقبة. البطء وحده يكلّفك زوّارًا وترتيبًا في جوجل.
• النمو فوق طاقة الخطة: الموقع الذي بدأ على استضافة مشتركة قد يخنقه ضيق الموارد مع تضاعف الزيارات، فيصبح الانتقال إلى استضافة VPS أو خطة أقوى ضرورة لا رفاهية. لاختيار النوع الأنسب راجع الفرق بين الاستضافة المشتركة والـVPS والمُدارة.
• دعم فني سيّئ: تذاكر تُهمل، أو ردود متأخّرة وقت الأزمة.
• سعر تجديد مرتفع: خصم السنة الأولى ينتهي ويقفز السعر، فتبحث عن قيمة أفضل.
• غياب مزايا حديثة: إصدار PHP قديم، لا كاش على مستوى الخادم، لا بيئة Staging، لا نسخ احتياطية تلقائية، لا CDN مدمج.

تغيير الدومين

أحيانًا لا تتغيّر الاستضافة بل اسم النطاق: إعادة تسمية تجارية (rebranding)، أو الانتقال من نطاق .net إلى .com، أو دمج اسمين في واحد. هذا النوع أعقد قليلًا لأنه يتطلّب تحديث كل الروابط الداخلية المخزّنة في قاعدة البيانات وإعداد تحويلات 301 من الدومين القديم، كما سنفصّل في قسم Search-Replace.

الدمج أو التقسيم

نقل عدة مواقع صغيرة لتُجمَع تحت تثبيت واحد (multisite)، أو فصل قسم من موقع كبير إلى نطاق فرعي مستقل. هذه حالات متقدّمة لكن جوهرها واحد: نقل ملفات + قاعدة بيانات + ضبط الروابط.

متى تؤجّل النقل؟ إن كان موقعك في موسم ذروة (حملة تسويقية، عرض موسمي، إطلاق منتج)، أجّل النقل حتى يهدأ. وإن كان السبب الوحيد «سعر أرخص بقليل»، احسب الكلفة الحقيقية: وقتك، والمخاطرة، وأي توقّف محتمل قد يساوي أضعاف الفرق.

أنواع النقل: نفس الدومين أم دومين جديد؟

قبل اختيار «كيف» تنقل، حدّد «ماذا» تنقل بالضبط، لأن النوع يغيّر بعض الخطوات جذريًا.

القاعدة الذهبية لتغيير الدومين: لا تغيّر الاستضافة والدومين في نفس اللحظة. لو فعلت وحدث خطأ، لن تعرف هل المشكلة من الخادم أم من الروابط. انقل الموقع كما هو إلى الخادم الجديد على نفس الدومين أولًا، تأكّد أنه يعمل، ثم نفّذ تغيير الدومين كعملية منفصلة. أما تغيير الاستضافة فقط مع بقاء الدومين كما هو، فهو أبسط الأنواع لأن قاعدة البيانات لا تحتاج تعديل روابط إطلاقًا — كل ما يتغيّر هو سجلّ A.

سبب آخر يجعل فصل المرحلتين حكمةً: تغيير الدومين يمسّ سمعتك في محركات البحث مباشرةً، إذ ينقل سلطة الروابط (link equity) من النطاق القديم إلى الجديد عبر تحويلات 301 دائمة. لو خلطته بتغيير الاستضافة وحدث تعطّل، فقد تزحف جوجل لموقع معطّل أثناء أحسّاس مرحلة انتقال السلطة، وهذا أسوأ توقيت ممكن. بفصل العمليتين تبقى كل مخاطرة معزولة وقابلة للتراجع وحدها. ولو كان موقعك متجرًا أو يعتمد على نطاقات فرعية متعددة، فكّر في رسم خريطة كاملة لكل النطاقات والمسارات قبل البدء حتى لا تنسى تحويل أيٍّ منها.

طرق النقل الأربع: أيّها يناسبك؟

هناك أربع طرق رئيسية لنقل ووردبريس، وكل واحدة لها موضعها. الجدول التالي يلخّص المقارنة، ثم نشرح كلًّا منها.

النقل بالإضافات

إضافات مثل All-in-One WP Migration وDuplicator وMigrate Guru تحزّم الموقع كاملًا (الملفات + قاعدة البيانات) في حزمة واحدة. تثبّت الإضافة على الموقع القديم، تصدّر الحزمة، ثم تثبّتها على الموقع الجديد. هذه أسهل طريقة لغير التقنيين، وتحلّ مشكلة الروابط (Search-Replace) تلقائيًا في الغالب. عيبها الأساسي حدّ حجم الرفع في النسخ المجانية (مثلًا 512MB في All-in-One)، وقد تستهلك ذاكرة كبيرة على المواقع الضخمة.

النقل اليدوي

أنت تنقل الملفات بنفسك عبر FTP/SSH وتصدّر/تستورد قاعدة البيانات يدويًا. لا حدود حجم، وتحكّم كامل، وشفافية تامّة في كل خطوة — لكنها أبطأ وتتطلّب إلمامًا بـphpMyAdmin وFTP وتعديل ملفات الإعداد. هذه الطريقة هي الأكثر تعليمًا لأنها تكشف لك كيف يتركّب ووردبريس فعليًا، ولذا نفصّلها بالكامل في القسم التالي.

أداة المضيف أو النقل المجاني

كثير من المزوّدين — خصوصًا خدمات ووردبريس المُدار — ينقلون موقعك مجانًا أو يوفّرون أداة نقل بنقرة. هذا غالبًا أفضل خيار إن كان متاحًا: يُنفّذه خبراء، أقل عرضة للأخطاء، ولا يكلّفك وقتًا. اسأل الدعم قبل أن تبدأ يدويًا — قد توفّر على نفسك ساعات.

WP-CLI عبر SSH

للمطوّرين والمواقع الضخمة، WP-CLI هو أسرع وأنظف طريقة. أمر واحد يصدّر قاعدة البيانات، وآخر ينفّذ Search-Replace آمنًا على البيانات المُسلسلة (serialized) دون أن يكسرها — وهي ميزة حاسمة سنوضّحها لاحقًا. تتطلّب وصول SSH وإلمامًا بالطرفية.

ووردبريس أسرع وأكثر أمانًا بلا إعدادات

ووردبريس المُدار من wpressly: سرعة وكاش وحماية وتحديثات تلقائية مع دعم عربي — ركّز على محتواك لا على السيرفر.

جرّب ووردبريس المُدار

التحضير: النصف الذي يضمن نجاح النصف الآخر

النقل الناجح يُكسب قبل أن تنقل أول ملف. قائمة التحضير التالية ليست شكليّة؛ كل بند فيها يمنع كارثة محتملة.

النسخة الاحتياطية: التأمين الحقيقي

أنشئ نسخة احتياطية كاملة تشمل ملفات الموقع وقاعدة البيانات معًا، واحتفظ بها محليًا على جهازك لا على الخادم فقط. النسخة التي تعيش على الخادم الذي تنقله ليست تأمينًا حقيقيًا — لو فُقد الخادم فُقدت معه. إضافات مثل UpdraftPlus تؤتمت العملية وترفع النسخة لتخزين سحابي خارجي، وهو الأمثل.

بيئة Staging: اختبر قبل أن تُطلق

بيئة الـStaging نسخة مطابقة من موقعك تعمل في معزل عن النسخة الحيّة، وتتيح لك تجربة النقل والتعديلات دون أي خطر على الزوّار. الفكرة أن تبني الموقع كاملًا على الخادم الجديد كبيئة Staging، تختبره حتى تطمئن، ثم «ترقّيه» ليصبح الحيّ بمجرّد تحويل الـDNS. هذه هي الفلسفة التي يقوم عليها صفر-توقّف بأكمله.

نصيحة خبير: قبل النقل بأسبوع، حدّث ووردبريس والقالب والإضافات إلى آخر إصدار على الموقع القديم، وأصلح أي تعارضات. النقل ينقل المشاكل كما هي؛ لا تنقل موقعًا مكسورًا وتتوقّع أن يُصلحه الخادم الجديد.

النقل اليدوي خطوة بخطوة

هذه أكثر الطرق تفصيلًا، وفهمها يجعلك قادرًا على تشخيص أي مشكلة في أي طريقة أخرى. سنمرّ على كل خطوة بدقّة.

1. انقل الملفات (FTP أو SSH)

اضغط مجلد ووردبريس كاملًا — wp-content (الأهم، فيه القوالب والإضافات والوسائط)، وwp-admin، وwp-includes، وملفات الجذر مثل wp-config.php و.htaccess — ثم انقله إلى الخادم الجديد. عبر FTP استخدم عميلًا مثل FileZilla. عبر SSH، الطريقة الأسرع نسخ أرشيف مضغوط مباشرة بين الخادمين أو بـ scp:

# اضغط الموقع على الخادم القديم
tar -czf site-backup.tar.gz /home/user/public_html

# انسخه إلى الخادم الجديد عبر SCP
scp site-backup.tar.gz user@new-server-ip:/home/user/

# على الخادم الجديد: فك الضغط
tar -xzf site-backup.tar.gz

نقل الأرشيف المضغوط أسرع بكثير من نقل آلاف الملفات الصغيرة عبر FTP، خصوصًا مع wp-content/uploads المليء بالصور.

2. صدّر قاعدة البيانات

من phpMyAdmin على الخادم القديم: اختر قاعدة بيانات الموقع، ثم بطاقة Export، واختر صيغة SQL والطريقة Quick (أو Custom لو أردت ضغط الناتج لملف كبير). احفظ الملف الناتج محليًا.

للمواقع الكبيرة، phpMyAdmin قد يفشل بسبب حدود الحجم أو المهلة الزمنية. الحل الأنظف هو mysqldump عبر SSH، وهو لا يكترث للحجم:

# تصدير قاعدة البيانات كاملة إلى ملف
mysqldump -u db_user -p old_database > backup.sql

# لقواعد ضخمة: اضغط الناتج فورًا لتوفير المساحة والوقت
mysqldump -u db_user -p old_database | gzip > backup.sql.gz

3. أنشئ قاعدة بيانات ومستخدمًا جديدين

على الخادم الجديد، من لوحة الاستضافة (قسم MySQL Databases في cPanel مثلًا): أنشئ قاعدة بيانات جديدة، ثم مستخدمًا جديدًا بكلمة مرور قوية، ثم اربط المستخدم بالقاعدة وامنحه كل الصلاحيات (ALL PRIVILEGES). دوّن الاسم الثلاثي بدقّة: اسم القاعدة، اسم المستخدم، كلمة المرور — ستحتاجها في الخطوة 6.

4. استورد قاعدة البيانات

عبر phpMyAdmin: اختر القاعدة الجديدة (الفارغة)، ثم بطاقة Import، وارفع ملف .sql. للملفات الكبيرة استخدم سطر الأوامر الذي يتجاوز حدود الويب:

# استيراد ملف SQL إلى القاعدة الجديدة
mysql -u new_db_user -p new_database < backup.sql

# لو كان الملف مضغوطًا
gunzip < backup.sql.gz | mysql -u new_db_user -p new_database

5. عدّل wp-config.php

هذا الملف هو حلقة الوصل بين الملفات وقاعدة البيانات. افتحه على الخادم الجديد وعدّل أربع قيم لتطابق ما أنشأته في الخطوة 3:

define( 'DB_NAME', 'new_database' );      // اسم القاعدة الجديدة
define( 'DB_USER', 'new_db_user' );       // المستخدم الجديد
define( 'DB_PASSWORD', 'strong_password' ); // كلمة المرور
define( 'DB_HOST', 'localhost' );         // غالبًا localhost، وقد يختلف لدى بعض المزوّدين

DB_HOST خصوصًا مصدر أخطاء متكرّر: بعض المزوّدين لا يستخدمون localhost بل عنوانًا خاصًا — راجع وثائق المضيف الجديد إن ظهر خطأ اتصال بقاعدة البيانات.

6. حدّث الروابط بـ Search-Replace (الخطوة التي يخطئ فيها الجميع)

إن تغيّر الدومين أو المسار، فإن قاعدة البيانات تحتوي آلاف الروابط القديمة المخزّنة داخلها (روابط الصور، الروابط الداخلية، إعدادات القالب). لا تستخدم بحثًا/استبدالًا عاديًا في SQL لأن ووردبريس يخزّن بعض البيانات بصيغة مُسلسلة (serialized) تتضمّن طول كل نص؛ تغيير النص دون تحديث الطول يكسر البيانات ويعطّل القالب أو الإضافات.

الحل الصحيح أداة تتعامل مع التسلسل بأمان. الأفضل WP-CLI:

# استبدال آمن يحترم البيانات المُسلسلة (جرّب أولًا بـ --dry-run)
wp search-replace 'https://old-domain.com' 'https://new-domain.com' --dry-run
wp search-replace 'https://old-domain.com' 'https://new-domain.com' --all-tables

بديلًا عن WP-CLI، تؤدّي إضافة Better Search Replace أو سكربت Search Replace DB نفس المهمة بأمان من المتصفّح. تذكّر: إن لم يتغيّر الدومين (نقل استضافة فقط على نفس النطاق) فلا حاجة لهذه الخطوة إطلاقًا.

7. اختبر عبر رابط مؤقّت قبل لمس الـDNS

هذا ما يجعل النقل آمنًا: تختبر الموقع الجديد كاملًا قبل أن يصل إليه أي زائر حقيقي. طريقتان:

• رابط مؤقّت من المضيف: كثير من لوحات الاستضافة توفّر دومينًا مؤقّتًا (مثل temp-url.host/~username) يفتح موقعك الجديد فورًا.
• ملف hosts المحلي: أضف على جهازك سطرًا يربط دومينك بالـIP الجديد، فيرى متصفّحك أنت فقط النسخة الجديدة بينما يرى العالم القديمة:

# في ملف hosts (Windows: C:\Windows\System32\drivers\etc\hosts)
203.0.113.45    example.com www.example.com

تصفّح الموقع كأنك زائر: الصفحات، الصور، لوحة wp-admin، النماذج، المتجر. لا تنتقل للخطوة التالية حتى يعمل كل شيء. إن بدت هذه الخطوات اليدوية مرهقة، فاستضافة ووردبريس المُدارة تتولّى النقل بالكامل نيابةً عنك وتختبره قبل الإطلاق.

ووردبريس أسرع وأكثر أمانًا بلا إعدادات

ووردبريس المُدار من wpressly: سرعة وكاش وحماية وتحديثات تلقائية مع دعم عربي — ركّز على محتواك لا على السيرفر.

جرّب ووردبريس المُدار

استراتيجية صفر-توقّف: تحويل الـDNS بذكاء

هنا يُكسب «صفر توقّف» أو يُخسر. كل ما سبق كان تجهيزًا؛ هذه اللحظة هي التبديل الفعلي، وترتيبها الدقيق هو الفارق بين انتقال لا يلحظه أحد وموقع يظهر «خطأ في الاتصال».

لماذا نخفّض TTL أولًا؟

TTL (Time To Live) هو المدّة التي تحتفظ فيها الخوادم الوسيطة وأجهزة الزوّار بنسخة مخزّنة (cached) من سجلّ الـDNS قبل أن تسأل من جديد. لو كانت قيمته 86400 ثانية (يوم كامل)، فبعض الزوّار سيظلّون يُوجّهون للخادم القديم يومًا كاملًا بعد تحويلك. بخفض TTL إلى 300 ثانية قبل النقل بيوم، تضمن أن التحويل سينتشر خلال دقائق لا ساعات. المهم أن الخفض نفسه يحتاج وقتًا لينتشر، لذا نفعله مبكّرًا: لو خفّضت TTL ثم حوّلت سجلّ A فورًا في نفس الدقيقة، فلن يفيدك الخفض لأن الخوادم الوسيطة لا تزال تحمل القيمة القديمة الطويلة. أعطِ الخفض يومًا كاملًا لينتشر قبل التحويل الفعلي. لفهم سجلّ A وTTL والانتشار بالتفصيل راجع سجلّات DNS ببساطة.

نقطة عملية تخلط على كثيرين: انتشار الـDNS لا يحدث «دفعة واحدة» في كل العالم، بل تدريجيًا حسب موقع كل خادم وسيط ومتى انتهت صلاحية الكاش لديه. لهذا قد ترى أنت الموقع الجديد بينما يرى صديق في بلد آخر القديم — وهذا طبيعي تمامًا خلال النافذة الانتقالية، وليس عطلًا. استخدم أدوات فحص DNS العالمية (التي تستعلم من عشرات المواقع حول العالم في آن) لتتابع تقدّم الانتشار بدل الاعتماد على جهازك وحده، فجهازك قد يحمل كاشًا قديمًا يضلّلك.

خطوات التحويل

1. قبل النقل بـ24 ساعة: خفّض TTL لسجلّ A إلى 300 ثانية. هذا يجعل التغيير ينتشر بسرعة لاحقًا.
2. بعد تأكّدك أن الموقع الجديد يعمل: حدّث سجلّ A ليشير إلى IP الخادم الجديد.
3. أبقِ الخادم القديم عاملًا 24–48 ساعة، لأن بعض الزوّار قد يصلون النسخة القديمة حتى يكتمل الانتشار.

لماذا نُبقي الخادم القديم عاملًا؟

أثناء فترة الانتشار، الزوّار منقسمون: بعضهم يصل الخادم الجديد، وبعضهم لا يزال يُوجّه للقديم بسبب الكاش. ما دام الخادمان يعرضان موقعًا سليمًا، لن يلاحظ أحد فرقًا. لا تحذف الموقع القديم ولا توقف خادمه حتى تتأكّد أن كل الزوّار يصلون الجديد (24–48 ساعة كافية عادةً). نقطة دقيقة: أي تعليق أو طلب شراء يتلقّاه الخادم القديم خلال هذه النافذة لن يظهر على الجديد — لهذا اخترنا توقيت زيارات منخفض وجمّدنا النشر.

خطة التراجع: ماذا لو ساء شيء؟

أجمل ما في هذه الطريقة أنها قابلة للتراجع بالكامل حتى آخر لحظة. ما دمت لم تحذف الخادم القديم، فإن أيّ مشكلة خطيرة تظهر بعد التحويل تُحلّ بإجراء واحد بسيط: أعد سجلّ A إلى IP الخادم القديم. لأنك خفّضت TTL مسبقًا، سيعود الزوّار إلى النسخة القديمة السليمة خلال دقائق، فتشتري لنفسك وقتًا لتشخيص الخلل على الخادم الجديد بهدوء دون ضغط. هذا «زرّ الرجوع» هو ما يحوّل النقل من قفزة مرعبة إلى خطوة محسوبة. لذا اجعل قاعدة عملك صارمة: لا تلمس الخادم القديم — لا حذفًا ولا إلغاء اشتراك — قبل أن تمرّ 48 ساعة على الأقل وتتأكّد عبر أدوات الفحص العالمية أن الانتشار اكتمل وأن الموقع الجديد يعمل بلا أعطال. احتفظ كذلك بنسخة احتياطية محلية حديثة طوال الفترة، فهي خط دفاعك الأخير لو فشل كل ما سبق.

بعد النقل: قائمة التحقّق الشاملة

بمجرّد اكتمال الانتشار، راجع الموقع بنّ منهجي. الجدول يلخّص ما تتحقّق منه ولماذا.

تفصيل البنود الحرجة:

• أعد إصدار شهادة SSL على الخادم الجديد وفعّل HTTPS — الشهادة مرتبطة بالخادم لا بالدومين، وغالبًا تُصدر تلقائيًا (AutoSSL)، لكن تأكّد. التفاصيل في تركيب SSL وتفعيل HTTPS.
• حدّث الروابط الدائمة: ادخل Settings → Permalinks واضغط Save دون تغيير شيء؛ هذا يعيد توليد قواعد .htaccess ويمنع أخطاء 404 في الروابط الداخلية.
• البريد: كثير من المواقع تفقد قدرتها على إرسال البريد بعد النقل لأن إعداد SMTP يختلف بين الخوادم. اختبر بريد استعادة كلمة المرور أو رسائل النماذج، واضبط إضافة SMTP إن لزم.
• الأداء: بعد التأكّد من سلامة كل شيء، راقب السرعة، وإن لزم حسّنها عبر تسريع ووردبريس. لمراجعة شاملة لإعدادات ووردبريس بعد الاستقرار، عُد إلى دليل ووردبريس الكامل.

حلّ المشاكل: أكثر الأعطال شيوعًا بعد النقل

حتى مع تنفيذ كل شيء بدقّة، قد تصادفك مشكلة. الجدول التالي يربط العَرَض بالسبب والحل، ثم نفصّل الأهم.

الشاشة البيضاء (White Screen of Death)

أشهر الأعطال وأكثرها إخافة لأنه لا يعطي رسالة. فعّل وضع التصحيح بإضافة هذه الأسطر إلى wp-config.php لترى الخطأ الحقيقي:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );   // يكتب الأخطاء إلى wp-content/debug.log
define( 'WP_DEBUG_DISPLAY', false );

غالبًا السبب تعارض إضافة (عطّلها بإعادة تسمية مجلد plugins مؤقّتًا) أو نفاد ذاكرة PHP (ارفع memory_limit إلى 256M).

خطأ الاتصال بقاعدة البيانات

«Error establishing a database connection» يعني أن wp-config.php لا يصل للقاعدة. راجع الأربعة بالترتيب: هل اسم القاعدة صحيح؟ هل المستخدم صحيح وله صلاحيات؟ هل كلمة المرور دقيقة (انتبه للمسافات)؟ وأهمّها: هل DB_HOST صحيح (قد لا يكون localhost لدى مضيفك الجديد)؟ تأكّد أيضًا أن الاستيراد في الخطوة 4 نجح فعلًا وأن الجداول موجودة.

Mixed Content وحلقة إعادة التوجيه

Mixed content يظهر حين تُحمّل صفحة HTTPS مواردَ عبر http:// (صور أو سكربتات)؛ يحلّه Search-Replace من http:// إلى https:// أو إضافة مثل Really Simple SSL. أما حلقة إعادة التوجيه فسببها غالبًا تعارض بين إعدادات HTTPS في .htaccess وقيمتَي siteurl/home؛ تحقّق من تطابقهما (كلاهما https:// بنفس صيغة www أو بدونها) وراجع قواعد إعادة التوجيه.

أخطاء شائعة يجب تجنّبها

• تحويل الـDNS قبل تجهيز الوجهة — السبب الأول للتوقّف على الإطلاق. لا تلمس الـDNS قبل اختبار الموقع الجديد.
• نسيان تحديث wp-config.php فلا يتّصل بقاعدة البيانات على الخادم الجديد.
• عدم خفض TTL مسبقًا فيتأخّر الانتشار ساعات ويرى بعض الزوّار نسخة قديمة.
• استبدال الروابط بـ SQL عادي فيكسر البيانات المُسلسلة — استخدم WP-CLI أو أداة آمنة دائمًا.
• حذف الخادم القديم فورًا قبل اكتمال الانتشار، ففقدان الزوّار خلال النافذة الانتقالية مضمون.
• إهمال إعادة إصدار SSL على الخادم الجديد فتظهر تحذيرات «غير آمن».
• النقل في موسم ذروة أو دون نسخة احتياطية محلية.

الخلاصة

النقل بدون توقّف ليس حظًا بل ترتيبًا منهجيًا: جهّز الوجهة بالكامل (ملفات + قاعدة بيانات)، عدّل wp-config وشغّل Search-Replace إن لزم، اختبر عبر رابط مؤقّت، خفّض TTL، ثم حوّل سجلّ A، وأبقِ المصدر احتياطيًا 24–48 ساعة. اتبع هذا التسلسل وسينتقل موقعك بسلاسة لا يلحظها زوّارك. وإذا كان النقل بسبب بطء استضافتك الحالية، فاختيار استضافة أسرع هو نصف الحل — والنصف الآخر هو هذا الترتيب الذي تعلّمته للتوّ.

جاهز لإطلاق موقعك على استضافة سريعة؟

خطط استضافة wpressly على أقراص NVMe مع SSL مجاني ودعم عربي — اختر الخطة المناسبة لحجمك وانطلق اليوم.

اكتشف خطط الاستضافة

الأسئلة الشائعة

هل يتوقّف موقعي أثناء النقل؟ لا، إن اتبعت الترتيب الصحيح: جهّز الخادم الجديد كاملًا واختبره قبل لمس الـDNS، ثم حوّل سجلّ A بعد خفض TTL، وأبقِ الخادم القديم عاملًا حتى يكتمل الانتشار. النسخة القديمة تظلّ تخدم الزوّار طوال فترة التجهيز، فلا أحد يرى انقطاعًا.

كم يستغرق انتشار الـDNS بعد النقل؟ من دقائق إلى ساعات حسب قيمة TTL وذاكرة الخوادم الوسيطة. خفض TTL إلى 300 ثانية قبل النقل بيوم يجعل الانتشار أسرع بكثير. نظريًا قد يصل الانتشار الكامل لكل العالم إلى 24–48 ساعة، لكن أغلب الزوّار يرون الخادم الجديد خلال دقائق إن خفّضت TTL مسبقًا.

هل أنقل يدويًا أم بإضافة؟ الإضافات أسهل لمعظم المواقع الصغيرة والمتوسطة لأنها تحزّم كل شيء وتعالج الروابط تلقائيًا، والطريقة اليدوية أنسب للمواقع الكبيرة أو حين تريد تحكّمًا كاملًا أو حين تتجاوز حدود حجم الإضافات المجانية. وكثير من المزوّدين ينقل موقعك مجانًا، فاسأل الدعم أولًا.

ما الفرق بين النقل على نفس الدومين والنقل لدومين جديد؟ على نفس الدومين يتغيّر الـIP فقط (سجلّ A) ولا تحتاج تعديل أي روابط في قاعدة البيانات. أما لدومين جديد فتحتاج تشغيل Search-Replace لتحديث آلاف الروابط المخزّنة وإعداد تحويلات 301 من الدومين القديم للحفاظ على ترتيب محركات البحث.

هل أحتاج إعادة تركيب SSL بعد النقل؟ نعم. الشهادة مرتبطة بالخادم لا بالدومين؛ أعد إصدارها على الخادم الجديد (AutoSSL غالبًا تلقائية) وفعّل فرض HTTPS بعد اكتمال النقل. أهمل هذه الخطوة وستظهر للزوّار تحذيرات «الموقع غير آمن».

لماذا تظهر صور مكسورة بعد النقل؟ غالبًا بسبب اختلاف مسارات الروابط القديمة المخزّنة في قاعدة البيانات، أو لأن مجلد wp-content/uploads لم يُرفع كاملًا. تأكّد أولًا من اكتمال رفع الملفات، ثم شغّل أداة Search-Replace آمنة لتحديث الروابط من النطاق/المسار القديم إلى الجديد.

لماذا يجب استخدام أداة Search-Replace بدل البحث والاستبدال العادي في SQL؟ لأن ووردبريس يخزّن بعض الإعدادات بصيغة مُسلسلة (serialized) تتضمّن طول كل نص. البحث والاستبدال العادي يغيّر النص دون تحديث الطول المسجّل، فينكسر التسلسل وتتعطّل القوالب والإضافات. أدوات مثل WP-CLI أو Better Search Replace تعيد حساب الأطوال تلقائيًا.

ماذا أفعل إن ظهرت شاشة بيضاء بعد النقل؟ فعّل وضع التصحيح في wp-config.php عبر WP_DEBUG لترى رسالة الخطأ الحقيقية بدل الشاشة الفارغة. السبب غالبًا تعارض إضافة (عطّل الإضافات بإعادة تسمية مجلدها) أو نفاد ذاكرة PHP (ارفع memory_limit). راجع أيضًا debug.log في wp-content.

هل يؤثّر النقل على ترتيبي في جوجل؟ إن تمّ النقل بشكل صحيح على نفس الدومين دون توقّف، فالتأثير معدوم تقريبًا. التراجع يحدث حين يطول التوقّف فتزحف جوجل لموقع معطّل، أو حين تنقل لدومين جديد دون تحويلات 301 صحيحة تنقل سلطة الروابط. خفض TTL والإبقاء على الخادم القديم يحميان ترتيبك.

متى أحذف الموقع القديم بأمان؟ بعد 24–48 ساعة من تحويل الـDNS والتأكّد عبر أدوات فحص DNS العالمية أن كل المناطق تشير للخادم الجديد. تحقّق أيضًا أن أي تعليقات أو طلبات وصلت للخادم القديم خلال الفترة الانتقالية قد نُقلت أو عُولجت. لا تتعجّل الحذف؛ احتفظ بنسخة احتياطية حتى بعد التأكّد.

هل أستطيع نقل موقع WooCommerce بنفس الطريقة؟ نعم، لكن انتبه أكثر: جمّد الطلبات الجديدة أثناء النافذة الانتقالية لأن أي طلب يصل للخادم القديم لن يظهر على الجديد. اختر أهدأ وقت ممكن، وبعد التحويل راجع آخر الطلبات على الخادمين للتأكّد من عدم ضياع أيٍّ منها، واختبر بوابة الدفع فورًا.