كيفية نقل موقع ووردبريس إلى استضافة جديدة دون توقف

لا يقتصر نقل موقع ووردبريس على نسخ الملفات واستيراد قاعدة البيانات. فعملية النقل المنضبطة يجب أن تحافظ على إتاحة الموقع، واتصال HTTPS، وتسليم البريد، وإعدادات تحسين الظهور في البحث، والبيانات الجديدة التي تصل أثناء الانتقال. والمقصود بالنقل «دون توقف» هو تجهيز الخادمين ليظل الموقع قابلاً للاستخدام بينما تنتقل الزيارات تدريجياً إلى الوجهة الجديدة.

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

1. تدقيق بيئة ووردبريس الحالية

وثّق إصدار ووردبريس وPHP، والقالب، والإضافات النشطة، والمهام المجدولة، وحجم قاعدة البيانات، والمساحة المستخدمة، ومنطقة DNS، وشهادة SSL، وخدمة البريد. سجّل كذلك بوابات الدفع وشبكات CDN وأدوات التحليلات وخطافات الويب وواجهات API وخدمات SMTP.

• اكتشف الإضافات القديمة أو غير المتوافقة مع الخادم الجديد.
• احتفظ بالقواعد المخصصة في .htaccess أو Nginx أو لوحة الاستضافة.
• دوّن حدود PHP والوحدات والإعدادات اللازمة للتشغيل.
• صدّر منطقة DNS واحتفظ بنسخة من قيمها الحالية.
• حدّد البيانات المتغيرة مثل الطلبات والنماذج والحجوزات وحسابات المستخدمين.

اختر فترة تنخفض فيها الزيارات، لكن لا تفترض غيابها بالكامل. قد يحتاج المتجر أو موقع العضويات إلى فترة قصيرة من وضع الصيانة أو القراءة فقط لإجراء المزامنة النهائية دون فقدان معاملات جديدة.

2. إعداد نسخ احتياطية وخطة تراجع

أنشئ نسخاً مستقلة من ملفات ووردبريس وقاعدة البيانات. لا تعتمد حصراً على إضافة للنقل أو على نسخة محفوظة داخل الخادم القديم. انقل النسخ إلى مساحة منفصلة، وتحقق من أحجامها، واختبر إمكانية فتح ملف قاعدة البيانات واستعادته.

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

3. خفض مدة TTL قبل موعد النقل

تحدد قيمة TTL مدة احتفاظ محللات DNS بالسجل داخل الذاكرة المؤقتة. اخفضها مسبقاً لسجلات A وAAAA التي ستتغير. لا يؤدي خفضها قبل التحويل مباشرة إلى حذف القيم المخزنة سابقاً؛ إذ تظل تلك القيم صالحة حتى انتهاء مدتها القديمة.

لا تعدّل سجلات MX أو SPF أو DKIM أو DMARC لمجرد نقل الموقع. غالباً ما تكون استضافة الويب منفصلة عن خدمة البريد. احتفظ بجميع سجلات البريد كما هي ما لم يكن نقل صناديق البريد مشروعاً مستقلاً ضمن الخطة.

4. تجهيز ووردبريس واختباره على الخادم الجديد

انسخ ملفات ووردبريس والوسائط والقوالب والإضافات إلى الوجهة. صدّر قاعدة البيانات من المصدر واستوردها على الخادم الجديد، ثم حدّث بيانات الاتصال في wp-config.php. إذا لم يتغير النطاق، فلا تستبدل عناوين الموقع الفعلية داخل ووردبريس.

اختبر الوجهة قبل تعديل DNS العام. يمكن استخدام ملف hosts على جهازك لربط النطاق بعنوان IP الجديد محلياً. بهذه الطريقة يطلب المتصفح اسم النطاق الحقيقي، لكن جهاز الاختبار وحده يتصل بالخادم الجديد.

اختبارات أساسية قبل التحويل

• الصفحة الرئيسية والصفحات المهمة والمقالات والبحث والقوائم.
• دخول لوحة الإدارة ورفع الوسائط ووظائف الإضافات.
• النماذج ورسائل المعاملات ومصادقة SMTP.
• السلة والدفع وحسابات العملاء والضرائب وإشعارات بوابات الدفع.
• إعادة التوجيه والعناوين الأساسية وتعليمات robots وخريطة XML.
• عرض الهاتف والتخزين المؤقت وسجلات الأخطاء وترويسات الأمان.

إذا شمل المشروع تغيير البنية أو التخزين أو الشبكات، تساعد خدمة ترحيل سحابي مدروسة على تنسيق اعتماديات التطبيق وقاعدة البيانات والبنية التحتية.

5. تثبيت شهادة SSL والتحقق منها

يجب أن يقدم الخادم الجديد شهادة صالحة لجميع الأسماء العامة المستخدمة، بما فيها النطاق الأساسي ونسخة www عند اعتمادها. وبحسب المزود، يمكن إصدار الشهادة من خلال تحقق DNS، أو تمرير تحقق مؤقت، أو تثبيت شهادة حالية إذا كانت شروطها تسمح بالنقل.

اختبر HTTPS من خلال إعداد hosts، وتحقق من سلسلة الشهادة وتاريخ انتهائها والأسماء التي تغطيها والتحويل من HTTP إلى HTTPS. ابحث عن المحتوى المختلط الناتج عن روابط موارد ثابتة تبدأ بـHTTP. ومن الأفضل عدم تفعيل HSTS لأول مرة أثناء النقل، لأن المتصفح قد يحتفظ بإعداد خاطئ ويصعب تجاوزه.

6. مزامنة البيانات وتحويل DNS

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

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

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

7. حماية البريد الإلكتروني

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

قائمة تحقق البريد

• الحفاظ على جميع سجلات MX وأولوياتها.
• نسخ سجل SPF كاملاً وعدم نشر أكثر من سجل SPF للاسم نفسه.
• الإبقاء على محددات DKIM ومفاتيحها العامة.
• الحفاظ على سياسة DMARC وعناوين استلام التقارير.
• فحص سجلات الاكتشاف التلقائي وبريد الويب والسجلات الفرعية المرتبطة.
• السماح لخدمة الإرسال الجديدة أو إعداد SMTP موثّق.
• اختبار الإرسال والاستقبال مع مزودين خارجيين وفحص نتائج المصادقة.

لا تعتمد على وظيفة PHP للبريد وحدها في الإشعارات المهمة. يوفر SMTP الموثّق أو مزود البريد المخصص للمعاملات سجلات أوضح وتحكماً أفضل في هوية المرسل.

8. فحوصات ما بعد النقل

افحص الموقع بحثاً عن روابط معطلة وصور مفقودة وحلقات إعادة توجيه وأخطاء خادم. راجع أدوات مشرفي المواقع والتحليلات والتخزين المؤقت والمهام المجدولة والنسخ الآلي ومراقبة الأمان. كما ينبغي أن تستخدم الروابط الأساسية وخريطة الموقع نطاق HTTPS المفضل.

لا تُلغِ الاستضافة القديمة فوراً. احتفظ بها إلى أن تنتهي ذاكرات DNS المؤقتة ويعمل الخادم الجديد بصورة مستقرة خلال دورة نشاط عادية. بعد ذلك أنشئ أرشيفاً نهائياً، وألغِ بيانات الدخول القديمة، وأغلق البيئة السابقة بشكل آمن.

خلاصة عملية

يعتمد نقل ووردبريس بأقل مخاطر على ترتيب الخطوات: التدقيق، والنسخ الاحتياطي، وخفض TTL، والتجهيز والاختبار، وإعداد SSL، ومزامنة البيانات، وتغيير سجلات DNS الضرورية فقط، وحماية البريد، ثم المراقبة. ولمراجعة الاعتماديات أو إدارة تحويل حساس، يمكن التواصل مع فريق developer.ma قبل تعديل DNS الخاص بالموقع الفعلي.