يمكنك نقل موقع WordPress إلى شركة استضافة جديدة مع الاحتفاظ باسم النطاق نفسه، دون الحاجة إلى تغيير عناوين الموقع أو مطالبة الزوار باستخدام رابط جديد. لكن نجاح العملية يعتمد على نقل ملفات الموقع وقاعدة البيانات بصورة صحيحة، وضبط إعدادات الخادم الجديد، ثم اختبار الموقع قبل توجيه النطاق إليه.
الترتيب مهم هنا فتغيير سجلات DNS قبل التأكد من جاهزية الموقع قد يؤدي إلى ظهور أخطاء لدى الزوار أو تعطل بعض الوظائف. لذلك، يبدأ النقل بإنشاء نسخة احتياطية كاملة، ثم تجهيز الاستضافة الجديدة ونقل البيانات إليها، وبعد ذلك اختبار الموقع وتحديث DNS والتحقق من استقرار التشغيل.
ملخص سريع للمقال: يوضح المقال كيفية نقل موقع ووردبريس إلى استضافة جديدة مع الاحتفاظ باسم النطاق نفسه، دون تغيير عناوين الموقع الأساسية. ويشرح خطوات تجهيز الاستضافة، وإنشاء نسخة احتياطية من الملفات وقاعدة البيانات، ونقل البيانات وضبط الإعدادات، ثم اختبار الموقع قبل تغيير سجلات DNS. كما يوضح كيفية تقليل التوقف وتجنب فقدان البيانات والتحقق من سلامة الموقع قبل إلغاء الاستضافة القديمة.
ما الذي تحتاج إلى معرفته قبل نقل موقع WordPress؟
نقل الموقع إلى استضافة جديدة يعني نقل الملفات والبيانات من الخادم الحالي إلى خادم آخر، مع استمرار استخدام اسم النطاق نفسه، مثل example.com. أما تغيير النطاق فهو إجراء مختلف يتطلب تحديث عناوين الموقع والإشارات المرتبطة به، وقد يستلزم معالجة إضافية للروابط والفهرسة.
في عملية النقل المعتادة ستتعامل مع العناصر التالية:
- ملفات WordPress: تشمل ملفات النظام والقوالب والإضافات والوسائط المرفوعة، إضافة إلى ملفات الإعدادات الخاصة بالموقع.
- قاعدة بيانات ووردبريس: تحتوي على المقالات والصفحات والتعليقات وإعدادات الموقع وبيانات أخرى تختلف بحسب القوالب والإضافات المستخدمة.
- إعدادات الاتصال: تربط ملفات WordPress بقاعدة البيانات الموجودة على الخادم الجديد.
- إعدادات النطاق وDNS: تحدد الخادم الذي يستقبل طلبات الزوار عند فتح الموقع.
- شهادة SSL: تتيح تشغيل الموقع باستخدام HTTPS، ويجب التأكد من صلاحيتها على الاستضافة الجديدة.
احتفظ أيضا بإمكانية الوصول إلى لوحة تحكم الاستضافة القديمة والجديدة، وأداة إدارة الملفات أو اتصال FTP/SFTP، وأداة تصدير واستيراد قاعدة البيانات. وقد تختلف أسماء الأدوات وطريقة الوصول إليها بحسب شركة الاستضافة.
قبل البدء، تأكد من توافق الاستضافة الجديدة مع متطلبات إصدار WordPress الذي تستخدمه، ومن توفر مساحة تخزين وموارد كافية. ومن الأفضل تنفيذ النقل في وقت يقل فيه نشاط الموقع، خاصة إذا كان يستقبل طلبات أو تعليقات أو حجوزات باستمرار.
الخطوة الأولى: تجهيز الاستضافة الجديدة قبل النقل
لا تبدأ بنسخ الملفات مباشرة إلى الخادم الجديد قبل التأكد من جاهزيته. يساعد تجهيز البيئة مسبقًا على اكتشاف المشكلات التي قد تمنع تشغيل الموقع بعد النقل.
التأكد من توافق الاستضافة الجديدة مع WordPress
راجع إصدار PHP الذي يدعمه الخادم الجديد، وإصدار قاعدة البيانات، ومتطلبات WordPress والقوالب والإضافات المثبتة لديك. إذا كان الموقع يعتمد على إضافة تحتاج إلى إصدار معين من PHP أو على إعدادات خاصة بالخادم، فتحقق من إمكانية توفيرها قبل نقل البيانات.
تأكد كذلك من توفر مساحة كافية لملفات الموقع وقاعدة البيانات والنسخ الاحتياطية المؤقتة. وإذا كان الموقع كبيرًا، فتحقق من حدود رفع الملفات واستيراد قواعد البيانات والوقت المسموح به لتنفيذ العمليات الطويلة.
إنشاء قاعدة بيانات جديدة ومستخدم لها
من لوحة تحكم الاستضافة الجديدة، أنشئ قاعدة بيانات مخصصة للموقع، ثم أنشئ مستخدمًا لها وامنحه الصلاحيات اللازمة للعمل عليها.
احتفظ بالبيانات التالية، لأنك ستحتاج إليها عند تعديل إعدادات WordPress:
- اسم قاعدة البيانات.
- اسم مستخدم قاعدة البيانات.
- كلمة مرور المستخدم.
- اسم خادم قاعدة البيانات، والذي قد يكون localhost أو قيمة أخرى تحددها شركة الاستضافة.
لا تفترض أن اسم الخادم أو طريقة الاتصال سيكونان مطابقين للاستضافة القديمة. استخدم القيم التي توفرها الاستضافة الجديدة، وتأكد من أن المستخدم يملك الصلاحيات المطلوبة على قاعدة البيانات الصحيحة.
تجهيز ملفات الموقع على الخادم الجديد
حدد المجلد الذي سيعمل منه الموقع. في كثير من الاستضافات المشتركة يكون public_html هو المجلد الأساسي، لكن قد تستخدم الاستضافة مجلدًا مختلفًا أو إعدادًا مخصصًا للنطاق.
إذا كان النطاق مرتبطًا مسبقا بحساب الاستضافة الجديدة، فتحقق من المجلد الذي يشير إليه. وتجنب تثبيت نسخة WordPress جديدة فوق الملفات التي ستنقلها أو إنشاء مجلد إضافي يؤدي إلى ظهور الموقع من مسار غير مقصود.
الخطوة الثانية: إنشاء نسخة احتياطية كاملة من الموقع القديم
النسخة الاحتياطية هي وسيلة الرجوع الأساسية إذا فشل النقل أو ظهرت مشكلة في الملفات أو قاعدة البيانات. ولا يكفي الاحتفاظ بملفات WordPress وحدها، لأن جزءًا كبيرًا من محتوى الموقع وإعداداته يوجد في قاعدة البيانات.
أخذ نسخة احتياطية من ملفات WordPress
افتح مدير الملفات في الاستضافة القديمة أو اتصل بالخادم باستخدام FTP أو SFTP، ثم نزّل ملفات الموقع كاملة.
تحقق خصوصا من وجود:
- مجلد wp-content، الذي يحتوي عادةً على القوالب والإضافات والوسائط المرفوعة.
- ملفات WordPress الأساسية.
- ملف wp-config.php الذي يتضمن إعدادات الاتصال بقاعدة البيانات وبعض إعدادات الموقع.
- ملف .htaccess إذا كان الموقع يستخدمه.
- أي ملفات أو إعدادات إضافية يحتاج إليها الموقع لتشغيل وظائفه الحالية.
لا تكتف بنسخ المجلدات الظاهرة داخل لوحة التحكم إذا كانت هناك ملفات أخرى يعتمد عليها الموقع. وإذا كانت الاستضافة توفر أداة نسخ احتياطي كاملة، فيمكن استخدامها مع التحقق من أنها تشمل الملفات وقاعدة البيانات معًا.
تصدير قاعدة بيانات ووردبريس
افتح أداة إدارة قاعدة البيانات، مثل phpMyAdmin، وحدد قاعدة البيانات التي يستخدمها الموقع فعلا. بعد ذلك، استخدم وظيفة التصدير لإنشاء ملف يحتوي على الجداول والبيانات، ويفضل استخدام صيغة SQL إذا كانت الأداة تدعمها.
تأكد من اختيار قاعدة البيانات الصحيحة، خاصة إذا كان حساب الاستضافة يستضيف أكثر من موقع. وبعد انتهاء التصدير، تحقق من وجود الملف وإمكانية فتحه واحتفاظه بمحتوى SQL المتوقع.
إذا كانت قاعدة البيانات كبيرة أو كانت عملية التصدير تتجاوز حدود الأداة، فقد تحتاج إلى استخدام أداة التصدير التي توفرها شركة الاستضافة أو وسيلة أخرى مدعومة على الخادم.
التحقق من النسخة الاحتياطية قبل المتابعة
احفظ الملفات ونسخة قاعدة البيانات في مكان منفصل عن الاستضافة القديمة، واحتفظ بنسخة إضافية إذا كانت البيانات مهمة. وتأكد من أن حجم الملفات معقول، وأن ملف قاعدة البيانات موجود، وأنك تعرف أي نسخة تخص الموقع المطلوب نقله.
لا تحذف الموقع القديم ولا تلغِ حساب الاستضافة في هذه المرحلة. ستحتاج إليه إذا ظهرت مشكلة بعد التحويل، وقد يحتوي أيضًا على بيانات جديدة إذا استمر الموقع في استقبال التفاعلات أثناء عملية النقل.
الخطوة الثالثة: نقل ملفات WordPress إلى الاستضافة الجديدة
بعد التأكد من سلامة النسخة الاحتياطية، انقل ملفات الموقع إلى المجلد الذي أعددته على الخادم الجديد.
رفع الملفات إلى المجلد الصحيح
يمكنك رفع الملفات باستخدام مدير الملفات في لوحة الاستضافة، أو عبر FTP/SFTP. وإذا كانت شركة الاستضافة توفر أداة موثوقة لنقل المواقع، فقد تكون خيارًا مناسبا، خصوصًا عندما يكون حجم الموقع كبيرا.
إذا كنت قد نزّلت الملفات في أرشيف مضغوط، يمكنك رفعه ثم فك ضغطه على الخادم الجديد إذا كانت الاستضافة تدعم ذلك. قد تكون هذه الطريقة أسرع من رفع آلاف الملفات بصورة منفصلة.
بعد الرفع، تأكد من أن ملفات WordPress موجودة مباشرة داخل مجلد الموقع المقصود، وليس داخل مجلد فرعي غير مطلوب. على سبيل المثال، إذا كان المجلد الصحيح هو public_html، فلا ينبغي أن ينتهي المسار إلى public_html/backup/wordpress ما لم تكن تريد تشغيل الموقع من ذلك المسار.
التحقق من الملفات والإعدادات المهمة
راجع بنية المجلدات، وتأكد من وجود مجلدات القوالب والإضافات والوسائط داخل wp-content. افحص كذلك وجود ملف wp-config.php والملفات الأخرى التي جرى تضمينها في النسخة الاحتياطية.
احتفظ بملف .htaccess وإعداداته إذا كان الموقع يستخدمه، لكن لا تستبدل إعدادات الخادم الجديد دون التأكد من توافقها معه. وقد تحتاج بعض القواعد إلى مراجعة إذا اختلفت بيئة الاستضافة.
تحقق أيضا من صلاحيات الملفات والمجلدات. ينبغي أن تسمح هذه الصلاحيات لـ WordPress بقراءة الملفات وتنفيذ ما يلزم من العمليات، دون منح صلاحيات أوسع من الضروري. إذا ظهرت مشكلة في الوصول إلى الملفات، فراجع إعدادات الاستضافة بدلًا من تغيير الصلاحيات عشوائيًا.
الخطوة الرابعة: نقل قاعدة بيانات ووردبريس إلى الخادم الجديد
بعد رفع الملفات، انقل قاعدة البيانات إلى الخادم الجديد. تحتوي هذه القاعدة على محتوى الموقع وإعداداته، ولذلك يجب التأكد من اكتمال الاستيراد قبل محاولة تشغيل WordPress.
استيراد قاعدة البيانات
افتح phpMyAdmin أو أداة إدارة قواعد البيانات التي توفرها الاستضافة الجديدة، ثم حدد قاعدة البيانات التي أنشأتها في الخطوة الأولى.
انتقل إلى وظيفة الاستيراد، واختر ملف SQL الذي صدرته من الاستضافة القديمة، ثم ابدأ العملية وانتظر حتى تنتهي. تختلف طريقة تنفيذ الاستيراد وحدود حجم الملفات بحسب الأداة وإعدادات الخادم.
بعد اكتمال العملية، تحقق من ظهور الجداول والبيانات داخل قاعدة البيانات الجديدة. لا يكفي ظهور رسالة نجاح عامة إذا كانت هناك مؤشرات على انقطاع العملية أو عدم استيراد بعض الجداول.
إذا ظهرت رسالة خطأ، فلا تكرر الاستيراد فوق البيانات الموجودة دون فهم سبب المشكلة. راجع رسالة الخطأ أولًا، وتحقق من حجم الملف وصحة صيغة SQL والصلاحيات المتاحة.
مراجعة بادئة جداول WordPress
تستخدم WordPress بادئة محددة لأسماء جداول قاعدة البيانات، وتكون غالبًا wp_، لكنها قد تختلف من موقع إلى آخر.
افتح ملف wp-config.php وقارن القيمة الموجودة في المتغير $table_prefix بأسماء الجداول التي استوردتها. إذا كانت البادئة متطابقة، فلا حاجة إلى تعديلها.
أما إذا كانت مختلفة، فتحقق من مصدر الاختلاف قبل إجراء أي تعديل. تغيير البادئة وحدها لا يكفي دائمًا لحل المشكلة، لأن بعض إعدادات WordPress، مثل الخيارات المخزنة في قاعدة البيانات، قد تتضمن أسماء مرتبطة بالبادئة. لذلك، تجنب إعادة تسمية الجداول عشوائيًا أو تعديل البيانات دون نسخة احتياطية.
معالجة أخطاء استيراد قاعدة البيانات
قد يفشل الاستيراد بسبب تجاوز حجم الملف الحد المسموح به، أو انتهاء المهلة الزمنية، أو نقص الصلاحيات، أو عدم توافق بعض خصائص قاعدة البيانات مع البيئة الجديدة.
ابدأ بتحديد السبب من رسالة الخطأ. إذا كان الملف أكبر من الحد المسموح به، فتحقق من وجود أداة استيراد خاصة لدى شركة الاستضافة أو وسيلة أخرى مدعومة لاستيراد قواعد البيانات الكبيرة. وإذا كانت المشكلة متعلقة بالصلاحيات، فتأكد من أن مستخدم قاعدة البيانات يملك الأذونات اللازمة.
لا تقسم ملف SQL أو تعدّل محتواه إلا عند الحاجة وبطريقة تحافظ على سلامة البيانات وترتيب تنفيذ الأوامر.
الخطوة الخامسة: ربط ملفات الموقع بقاعدة البيانات الجديدة
بعد نقل الملفات واستيراد قاعدة البيانات، يجب التأكد من أن WordPress يستخدم بيانات الاتصال الخاصة بالاستضافة الجديدة، وليس بيانات الخادم القديم.
تعديل إعدادات ملف wp-config.php
افتح ملف wp-config.php الموجود في المجلد الأساسي للموقع، ثم راجع قيم إعدادات قاعدة البيانات التالية:
define( 'DB_NAME', 'new_database_name' ); define( 'DB_USER', 'new_database_user' ); define( 'DB_PASSWORD', 'new_database_password' ); define( 'DB_HOST', 'database_host' );
 |
| تحدد هذه القيم قاعدة البيانات التي يتصل بها WordPress على الخادم الجديد؛ لذلك يجب استبدال القيم التوضيحية ببيانات الاتصال الفعلية التي توفرها شركة الاستضافة. |
استبدل القيم التوضيحية ببيانات الاتصال الفعلية التي وفرتها الاستضافة الجديدة. قد تكون قيمة DB_HOST هي localhost، لكن يجب استخدام القيمة الصحيحة لحسابك بدلًا من افتراض ذلك.
احفظ نسخة من الملف قبل تعديله، وتأكد من عدم تغيير بقية إعداداته دون ضرورة. وينبغي كذلك الحفاظ على مفاتيح الأمان والإعدادات الأخرى، ما لم تتطلب عملية النقل تعديلًا محددًا.
تعامل مع بيانات الاتصال باعتبارها معلومات حساسة. لا تضعها في ملفات عامة أو تشاركها في أماكن غير آمنة، ولا تمنح أشخاصًا غير مخولين إمكانية الوصول إليها.
التأكد من إعداد اسم النطاق ومسار الموقع
بما أنك تريد نقل الموقع دون تغيير اسم النطاق، فينبغي أن يظل عنوان الموقع الأساسي هو نفسه المستخدم قبل النقل.
راجع إعدادات home وsiteurl في قاعدة البيانات عند الحاجة، وتأكد من أنها تشير إلى عنوان الموقع الصحيح، بما في ذلك استخدام HTTPS إذا كان ذلك هو الإعداد المعتمد.
يمكنك مراجعة القيم عبر لوحة تحكم WordPress إذا كان تسجيل الدخول متاحًا، أو من خلال جدول wp_options في قاعدة البيانات، مع مراعاة أن اسم الجدول قد يختلف إذا كانت بادئته مختلفة.
لا تنفذ عملية استبدال شاملة لعناوين الموقع داخل قاعدة البيانات لمجرد أنك نقلته إلى خادم جديد. إذا بقي اسم النطاق كما هو، فلا تكون هذه العملية مطلوبة عادةً. كما أن الاستبدال النصي المباشر قد يفسد البيانات المتسلسلة التي تستخدمها WordPress وبعض الإضافات لتخزين الإعدادات.
الخطوة السادسة: اختبار الموقع على الاستضافة الجديدة قبل تغيير DNS
هذه من أهم مراحل النقل؛ إذ تتيح لك اكتشاف المشكلات قبل توجيه الزوار إلى الخادم الجديد. لا تنتظر تغيير DNS حتى تبدأ الاختبار، لأن معالجة الأخطاء قبل التحويل تقلل احتمال تأثر الزوار بها.
 |
| يمنح الاختبار المسبق فرصة لمعالجة أخطاء الملفات وقاعدة البيانات والروابط والوظائف قبل توجيه الزوار إلى الاستضافة الجديدة. |
معاينة الموقع باستخدام وسيلة اختبار مناسبة
تختلف طريقة اختبار الموقع باختلاف الأدوات التي توفرها شركة الاستضافة. ويمكنك استخدام إحدى الوسائل التالية بحسب حالتك:
- عنوان مؤقت: إذا كانت الاستضافة توفر عنوانًا مؤقتًا يسمح بمعاينة الموقع، فاستخدمه للتحقق من عمل الملفات وقاعدة البيانات. لكن انتبه إلى أن بعض المواقع لا تعمل بصورة كاملة عبر العناوين المؤقتة بسبب إعدادات النطاق أو HTTPS.
- تعديل ملف hosts: يمكنك تعديل ملف hosts على جهازك لتوجيه اسم النطاق إلى عنوان IP الخاص بالخادم الجديد محليًا. يتيح ذلك اختبار الموقع باستخدام اسمه الأصلي قبل تغيير سجلات DNS العامة.
عند استخدام ملف hosts، يجب إدخال عنوان IP الصحيح للخادم الجديد واسم النطاق المطلوب، وقد تحتاج إلى إضافة نسخة www أيضا إذا كنت تختبرها بصورة منفصلة. احفظ نسخة من الملف الأصلي، وأزل التعديل بعد الانتهاء من الاختبار حتى يعود جهازك إلى استخدام نظام DNS المعتاد.
إذا كان الخادم الجديد يحتاج إلى إعدادات خاصة لتشغيل HTTPS، فتحقق من جاهزيتها أيضًا. ولا تعتبر نجاح فتح الصفحة الرئيسية وحده دليلًا كافيًا على أن الموقع جاهز للتحويل.
اختبار الصفحات والوظائف الأساسية
اختبر الموقع بصورة منظمة، وابدأ بالصفحة الرئيسية، ثم انتقل إلى الصفحات الداخلية والمقالات وصفحات التصنيفات والملفات المرفوعة.
ركز على الجوانب التالية:
- المحتوى: تأكد من ظهور المقالات والصفحات والتعليقات والبيانات المتوقعة.
- الصور والوسائط: افتح عددًا من الصور والملفات المرفوعة وتحقق من تحميلها دون أخطاء.
- لوحة التحكم: اختبر تسجيل الدخول إلى /wp-admin، وتأكد من إمكانية الوصول إلى أدوات الإدارة.
- القوالب والإضافات: راجع تصميم الصفحات والوظائف التي يعتمد عليها الموقع.
- الروابط الدائمة: افتح عدة روابط داخلية وتأكد من أنها تعمل دون أخطاء 404.
- النماذج والتفاعلات: اختبر النماذج والتعليقات ووظائف البحث أو غيرها من الميزات المهمة للموقع.
إذا كان الموقع متجرا إلكترونيًا أو منصة حجوزات، فاختبر الوظائف التي تتعامل مع الطلبات والمدفوعات أو الحجوزات بعناية، باستخدام بيئة اختبار أو إجراء لا ينشئ معاملات حقيقية غير مقصودة.
معالجة الأخطاء قبل تغيير DNS
إذا ظهرت مشكلة، فحدد أولًا الجزء المسؤول عنها بدلًا من تعديل عدة إعدادات في الوقت نفسه.
عند ظهور خطأ في الاتصال بقاعدة البيانات، راجع بيانات wp-config.php وصلاحيات المستخدم واسم خادم قاعدة البيانات. وإذا ظهرت صفحة فارغة أو خطأ 500، فتحقق من سجلات أخطاء الخادم، وتوافق PHP، وسلامة الملفات، وأي تغييرات لازمة في إعدادات الخادم.
أما إذا كانت الصفحة الرئيسية تعمل بينما تفشل الصفحات الداخلية، فراجع إعدادات الروابط الدائمة وقواعد إعادة الكتابة. ويمكنك إعادة حفظ إعدادات الروابط الدائمة من لوحة التحكم بعد أن يصبح الموقع قابلًا للإدارة، إذا كان ذلك مناسبًا للمشكلة.
لا تنتقل إلى تغيير DNS حتى تتمكن من تشغيل الوظائف الأساسية ومعالجة المشكلات التي تؤثر في الزوار.
الخطوة السابعة: تغيير سجلات DNS لتوجيه النطاق إلى الاستضافة الجديدة
بعد التأكد من أن الموقع يعمل على الخادم الجديد، حان وقت توجيه اسم النطاق إليه. لا يتطلب ذلك شراء نطاق جديد أو تغيير اسم النطاق الحالي؛ المطلوب هو تعديل إعدادات التوجيه المناسبة.
تحديد سجلات DNS التي تحتاج إلى التعديل
يعتمد نوع التعديل على طريقة إدارة النطاق وDNS.
إذا كنت ستحتفظ بإدارة DNS لدى الجهة الحالية، فقد تحتاج إلى تعديل سجل A ليوجه النطاق إلى عنوان IPv4 الخاص بالخادم الجديد. وإذا كان النطاق يستخدم IPv6 وكان الخادم الجديد يدعمه، فقد تحتاج إلى مراجعة سجل AAAA أيضًا.
أما إذا قررت تغيير خوادم الأسماء Nameservers لتصبح تابعة لشركة الاستضافة الجديدة، فستحتاج إلى التأكد من إعداد جميع سجلات DNS المطلوبة لدى الجهة الجديدة قبل إجراء التغيير.
الفرق المهم: تغيير سجل A لا يعني بالضرورة تغيير خوادم الأسماء. لكل منهما وظيفة مختلفة، ويعتمد الاختيار الصحيح على المكان الذي تريد إدارة سجلات DNS من خلاله.
 |
| يغير سجل A عنوان IPv4 الذي يشير إليه النطاق، بينما يؤدي تغيير خوادم الأسماء إلى نقل إدارة سجلات DNS إلى الجهة المحددة في إعدادات النطاق. |
قبل تعديل خوادم الأسماء، راجع سجلات البريد الإلكتروني، مثل MX والسجلات المرتبطة بها، إضافة إلى سجلات التحقق والخدمات الخارجية. قد يؤدي نقل إدارة DNS دون إعادة إنشاء هذه السجلات إلى تعطيل البريد الإلكتروني أو خدمات أخرى مرتبطة بالنطاق.
تحديث السجلات بعد نجاح الاختبار
افتح لوحة التحكم لدى الجهة التي تدير DNS، ثم عدّل السجلات المطلوبة وفقًا لإعدادات الاستضافة الجديدة.
قبل التغيير، دوّن القيم الحالية أو احتفظ بنسخة من إعدادات DNS حتى تتمكن من مراجعتها أو استعادتها عند الحاجة.
راجع قيمة TTL للسجلات ذات الصلة. تحدد هذه القيمة المدة التي يمكن خلالها الاحتفاظ بإجابة DNS في الذاكرة المؤقتة، ولذلك تؤثر في سرعة ملاحظة بعض المستخدمين للتغيير. لكن خفض TTL قبل النقل لا يلغي بالضرورة كل التأخيرات، خصوصًا إذا كانت هناك إجابات مخزنة مسبقًا أو إعدادات مختلفة لدى مزودي الخدمة.
بعد حفظ التغييرات، قد يصل بعض الزوار إلى الخادم الجديد بينما يستمر آخرون مؤقتًا في الوصول إلى الخادم القديم. تختلف المدة بحسب إعدادات DNS والتخزين المؤقت لدى الشبكات والأجهزة.
تقليل توقف الموقع أثناء انتقال DNS
لتقليل احتمالات التوقف، نفّذ تجهيز الموقع واختباره قبل تغيير السجلات، وحدد وقتًا مناسبًا للتحويل. وإذا كان الموقع يستقبل بيانات جديدة باستمرار، فخطط لكيفية الحفاظ على اتساقها بين الخادمين.
على سبيل المثال، قد يتلقى متجر إلكتروني طلبات جديدة على الخادم القديم بعد بدء انتشار DNS، بينما يسجل الخادم الجديد طلبات أخرى. إذا لم تُنقل البيانات الأخيرة بطريقة مناسبة، فقد تظهر سجلات ناقصة أو متضاربة.
يمكن تقليل هذا الخطر بإيقاف التعديلات التي تغيّر البيانات مؤقتًا، أو وضع الموقع في وضع الصيانة لفترة مناسبة، أو تنفيذ مزامنة أخيرة للبيانات وفقًا لطبيعة الموقع وأدوات النقل المتاحة.
لا توجد مدة توقف واحدة مضمونة لجميع المواقع؛ فهي تعتمد على حجم الموقع، وطبيعة البيانات المتغيرة، وإعدادات الاستضافة، وطريقة نقلها وانتشار DNS.
الخطوة الثامنة: تفعيل HTTPS والتحقق من شهادة SSL
بعد توجيه النطاق إلى الاستضافة الجديدة، تأكد من أن الموقع يستخدم اتصال HTTPS بصورة صحيحة. قد تكون الملفات وقاعدة البيانات قد نُقلت بنجاح، لكن غياب شهادة SSL صالحة أو وجود إعدادات غير متوافقة قد يؤدي إلى ظهور تحذيرات أمنية للزوار.
تحقق من النقاط التالية:
- تأكد من شهادة SSL صالحة لاسم النطاق على الخادم الجديد، وتشمل www إذا كان الموقع يستخدمه.
- إمكانية فتح الموقع باستخدام HTTPS دون ظهور تحذيرات متعلقة بالشهادة.
- عمل التحويل من HTTP إلى HTTPS بصورة صحيحة، دون حلقات إعادة توجيه.
- عدم تحميل الصور أو ملفات القوالب أو الإضافات عبر HTTP بطريقة تسبب تحذيرات المحتوى المختلط.
إذا كانت الشهادة غير جاهزة، فتحقق من إعداد النطاق لدى شركة الاستضافة وإمكانية إصدار الشهادة أو تثبيتها. وقد تحتاج عملية الإصدار أو التحقق إلى اكتمال توجيه DNS أو استيفاء شروط أخرى لدى مزود الشهادة.
بعد تفعيل HTTPS، اختبر الصفحة الرئيسية والصفحات الداخلية ولوحة التحكم. ولا تضف قواعد تحويل جديدة قبل مراجعة القواعد الموجودة، حتى لا تتعارض إعدادات الخادم مع إعدادات WordPress أو الإضافات.
الخطوة التاسعة: فحص الموقع بعد اكتمال النقل
لا تنهِ عملية النقل بمجرد ظهور الصفحة الرئيسية على الاستضافة الجديدة. أجرِ فحصًا نهائيًا للتأكد من أن الموقع يعمل بصورة سليمة، وأن المحتوى والوظائف وإعدادات الفهرسة لم تتأثر.
التحقق من سلامة الصفحات والروابط
افتح مجموعة من الصفحات المهمة، بما في ذلك المقالات والتصنيفات والصفحات التي تستقبل زيارات أو تحقق أهدافًا أساسية للموقع. تأكد من أن الروابط الدائمة تعمل، وأن الصور والملفات المرفوعة تظهر بصورة صحيحة.
إذا ظهرت أخطاء 404، فحدد ما إذا كانت مرتبطة بقواعد إعادة الكتابة أو بمسارات الملفات أو بإعدادات الموقع. لا تفترض أن المشكلة ناتجة عن DNS وحده؛ فقد يكون سببها إعدادًا مختلفًا على الخادم الجديد.
التحقق من لوحة التحكم والوظائف التشغيلية
سجل الدخول إلى لوحة تحكم WordPress، وراجع القوالب والإضافات وإمكانية تحرير المحتوى ونشره. اختبر كذلك النماذج والبحث والوظائف الأساسية التي يعتمد عليها المستخدمون.
إذا كان الموقع يعتمد على المهام المجدولة، أو إرسال البريد الإلكتروني، أو تكاملات مع خدمات خارجية، فتحقق من استمرار عملها. فقد تتأثر بعض هذه الوظائف بتغيير إعدادات PHP أو البريد أو الصلاحيات أو متغيرات البيئة.
بعد التأكد من عمل الوظائف الأساسية، يمكنك إجراء فحص سرعة الموقع للتحقق من أدائه بعد الانتقال إلى الاستضافة الجديدة.
راجع أيضا إعدادات النسخ الاحتياطي على الاستضافة الجديدة، وتأكد من أن النسخ الاحتياطية المستقبلية ستُحفظ في المكان المتوقع وأنه يمكن استعادتها عند الحاجة.
التحقق من الفهرسة وملفات SEO
الحفاظ على اسم النطاق نفسه يساعد على تجنب التغييرات المرتبطة بالانتقال إلى نطاق مختلف، لكنه لا يغني عن مراجعة إعدادات محركات البحث بعد النقل.
تأكد من بقاء عناوين الصفحات الأساسية دون تغييرات غير مقصودة، ومن أن إعدادات WordPress لا تمنع محركات البحث من فهرسة الموقع. راجع ملف robots.txt وخريطة الموقع، وتحقق من عدم وجود إعدادات اختبار تمنع الوصول إلى الصفحات. وإذا لاحظت مشكلات فهرسة الصفحات بعد النقل، فراجع أسباب الاستبعاد وطرق معالجتها.
إذا كان الموقع يستخدم إضافات SEO، فراجع إعداداتها بعد النقل، وتأكد من أن الروابط الأساسية Canonical URLs تشير إلى العناوين الصحيحة. ويمكنك استخدام أدوات مشرفي المواقع لمتابعة الزحف والأخطاء بعد استقرار عملية النقل.
أخطاء شائعة عند نقل موقع ووردبريس إلى استضافة جديدة
قد تنجح عملية نقل الملفات ظاهريًا، بينما تبقى مشكلات تؤثر في المحتوى أو الوصول إلى الموقع. من أبرز الأخطاء التي ينبغي تجنبها:
- نقل الملفات دون قاعدة البيانات: يؤدي ذلك إلى فقدان المحتوى والإعدادات التي لا توجد ضمن الملفات.
- استخدام بيانات اتصال قديمة: قد تمنع WordPress من الاتصال بقاعدة البيانات الجديدة.
- رفع الملفات إلى مجلد غير صحيح: قد يظهر الموقع من مسار مختلف أو لا يعمل النطاق كما هو متوقع.
- تغيير DNS قبل الاختبار: ينقل المشكلة مباشرة إلى بيئة الإنتاج ويزيد احتمال تأثر الزوار.
- إهمال سجلات البريد الإلكتروني: قد يؤدي تغيير خوادم الأسماء دون مراجعة السجلات إلى توقف استقبال البريد أو إرساله.
- حذف الاستضافة القديمة مبكرا: يزيل وسيلة الرجوع إلى الموقع السابق قبل التأكد من اكتمال النقل.
- تجاهل اختلافات بيئة الخادم: قد تؤدي اختلافات PHP أو الصلاحيات أو حدود الموارد إلى تعطل بعض الإضافات والوظائف.
- تعديل عناوين الموقع دون حاجة: قد يسبب استبدال العناوين داخل قاعدة البيانات مشكلات غير ضرورية، خاصة عندما يبقى النطاق نفسه.
لتجنب هذه الأخطاء، تعامل مع النقل باعتباره سلسلة خطوات مترابطة، ولا تنتقل إلى المرحلة التالية إلا بعد التحقق من نجاح المرحلة الحالية.
كيف تنقل موقع WordPress دون فقدان البيانات أو إطالة التوقف؟
تعتمد الطريقة الأكثر أمانًا على طبيعة الموقع، وليس على حجمه وحده. فالموقع التعريفي الذي لا يتغير محتواه كثيرًا يختلف عن متجر إلكتروني يستقبل طلبات طوال اليوم أو منصة تسجل حجوزات وتعليقات باستمرار.
اختيار طريقة النقل بحسب طبيعة الموقع
في المواقع التي لا تتغير بياناتها باستمرار، قد تكفي نسخة احتياطية حديثة من الملفات وقاعدة البيانات، يليها نقل البيانات واختبار الموقع قبل تغيير DNS.
أما المواقع التي تستقبل بيانات جديدة باستمرار، فيجب التخطيط للفترة الفاصلة بين إنشاء النسخة الاحتياطية والتحويل النهائي. فقد يؤدي استمرار استقبال البيانات على الخادم القديم إلى وجود معلومات أحدث من تلك الموجودة على الخادم الجديد.
في هذه الحالة، يمكن تحديد فترة قصيرة لإيقاف العمليات التي تغيّر البيانات، أو استخدام أداة مزامنة أخيرة تدعمها الاستضافة. ويجب اختبار طريقة المزامنة مسبقًا، لأن نسخ قاعدة البيانات بالكامل فوق قاعدة أخرى تحتوي على بيانات جديدة قد يؤدي إلى فقدانها.
تنفيذ النقل مع خطة واضحة للرجوع
احتفظ بالاستضافة القديمة والنسخة الاحتياطية إلى أن تتأكد من نجاح الموقع الجديد. وإذا ظهرت مشكلة مؤثرة بعد التحويل، فيمكنك تقييم إعادة توجيه DNS إلى الخادم القديم مؤقتًا، بشرط أن يكون الموقع القديم ما زال سليمًا وأن تُراعى البيانات الجديدة التي قد تكون سُجلت على الخادم الجديد.
لا تجعل الرجوع مجرد تغيير DNS دون مراجعة؛ فإذا استقبل الخادم الجديد طلبات أو حجوزات بعد التحويل، فقد يؤدي الرجوع إلى القديم إلى إخفاء تلك البيانات عن المستخدمين أو فقدان اتساقها.
كذلك، لا تعتمد على النسخة الاحتياطية وحدها بوصفها دليلًا على إمكانية الاستعادة. احتفظ ببيانات الوصول اللازمة، وتأكد من أن الملفات وقاعدة البيانات متاحتان، وأنك تعرف كيفية استخدامهما إذا لزم الأمر.
متى يمكن إلغاء الاستضافة القديمة؟
لا تلغِ الاستضافة القديمة بمجرد أن يعمل الموقع على النطاق من الخادم الجديد. تأكد أولًا من اكتمال الاختبارات، واستقرار التوجيه، وسلامة البيانات والوظائف الأساسية.
قبل الإلغاء، راجع هذه النقاط:
- أن النطاق يوجّه إلى الاستضافة الجديدة، وأن الموقع يعمل عبر HTTPS.
- أن المقالات والصفحات والصور والملفات وقاعدة البيانات سليمة.
- أن لوحة التحكم والنماذج والبريد والوظائف الأساسية تعمل وفقًا لطبيعة الموقع.
- أن أي بيانات أُضيفت إلى الخادم القديم أثناء الانتقال قد نُقلت أو جرى التعامل معها بصورة صحيحة.
- أن لديك نسخة احتياطية محفوظة خارج الاستضافة القديمة، ويمكن الوصول إليها عند الحاجة.
تحقق كذلك من أن الاستضافة القديمة لا تستضيف البريد الإلكتروني أو قواعد بيانات أو خدمات أخرى ما زلت تحتاج إليها. فقد يكون الموقع قد انتقل، بينما تظل بعض الخدمات مرتبطة بالحساب السابق.
بعد التأكد من هذه الجوانب والاحتفاظ بنسخة احتياطية مناسبة، يمكنك إلغاء الاستضافة القديمة دون الاعتماد على افتراض أن كل شيء يعمل لمجرد ظهور الصفحة الرئيسية.
الخلاصة: نقل الموقع مع الحفاظ على اسم النطاق
يمكن نقل موقع ووردبريس إلى استضافة جديدة دون تغيير اسم النطاق، بشرط نقل الملفات وقاعدة البيانات بصورة سليمة، وتحديث إعدادات الاتصال، واختبار الموقع على الخادم الجديد قبل تغيير DNS.
الترتيب الأكثر أمانًا هو تجهيز الاستضافة، ثم إنشاء نسخة احتياطية، ونقل الملفات وقاعدة البيانات، وضبط الإعدادات، واختبار الوظائف الأساسية، وبعد ذلك توجيه النطاق إلى الخادم الجديد والتحقق من HTTPS والروابط والبيانات. أما إلغاء الاستضافة القديمة، فيأتي بعد التأكد من استقرار الموقع وعدم وجود بيانات أو خدمات متبقية عليها.
بهذا التسلسل، يمكنك تقليل احتمالات التوقف وفقدان البيانات، مع الحفاظ على اسم النطاق وعناوين الموقع الأساسية دون تغييرات غير ضرورية.
أسئلة شائعة حول نقل موقع ووردبريس إلى استضافة جديدة
تثير عملية نقل موقع ووردبريس بعض التساؤلات المتعلقة بالحفاظ على البيانات، واستمرار عمل البريد الإلكتروني، والتعامل مع المشكلات التي قد تظهر بعد تغيير الاستضافة. تساعدك الإجابات التالية على اتخاذ القرارات المناسبة قبل النقل وبعده، وتجنب الإجراءات التي قد تؤثر في استقرار الموقع.
هل يمكن نقل موقع ووردبريس إلى استضافة جديدة دون نقل البريد الإلكتروني؟
نعم، يمكن نقل ملفات الموقع وقاعدة بياناته مع الإبقاء على خدمة البريد الإلكتروني لدى مزودها الحالي. يتطلب ذلك الحفاظ على سجلات DNS الخاصة بالبريد، مثل سجلات MX والسجلات المرتبطة بها، عند تعديل إعدادات النطاق. أما تغيير خوادم الأسماء، فيستلزم التأكد من إعادة إعداد سجلات البريد لدى الجهة الجديدة.
ماذا يحدث إذا استمر الزوار في استخدام الخادم القديم بعد تغيير DNS؟
قد يصل بعض الزوار إلى الخادم الجديد بينما يستمر آخرون مؤقتًا في الوصول إلى الخادم القديم، بسبب اختلاف مدة تحديث سجلات DNS والتخزين المؤقت. إذا كان الموقع يستقبل طلبات أو تعليقات أو حجوزات، فقد تتوزع البيانات بين الخادمين لذلك يلزم التخطيط لمزامنة البيانات أو إيقاف التعديلات مؤقتا.
هل يؤثر نقل الاستضافة في ترتيب الموقع بمحركات البحث؟
الحفاظ على اسم النطاق والعناوين الأساسية يقلل التغييرات المرتبطة بالانتقال إلى نطاق جديد، لكنه لا يضمن عدم تأثر الظهور في نتائج البحث. بعد النقل، تحقق من عمل الروابط الدائمة، وصحة عناوين Canonical URLs، وإمكانية فهرسة الصفحات، وسلامة ملف robots.txt وخريطة الموقع، لتجنب مشكلات الوصول والزحف.
لماذا يعمل الموقع بعد النقل بينما تظهر أخطاء في الصفحات الداخلية؟
قد يرجع ذلك إلى اختلاف إعدادات الروابط الدائمة أو قواعد إعادة الكتابة بين الاستضافتين، أو وجود مشكلة في مسارات الملفات. ابدأ بفحص الروابط التي تعرض الخطأ، ثم راجع إعدادات الروابط الدائمة وملف .htaccess إذا كان مستخدمًا. لا تفترض أن المشكلة مرتبطة بـ DNS وحده.
هل يجب تعديل عناوين الموقع داخل قاعدة البيانات بعد نقل الاستضافة؟
لا، ليس عادةً إذا احتفظت باسم النطاق نفسه ولم تتغير عناوين الموقع الأساسية. قد يكفي التأكد من صحة قيمتي home وsiteurl وإعدادات HTTPS. تجنب استبدال العناوين بصورة شاملة داخل قاعدة البيانات دون حاجة، لأن بعض البيانات المتسلسلة قد تتضرر عند استخدام الاستبدال النصي المباشر.
متى يكون نقل الموقع باستخدام أداة مزامنة أفضل من النسخة الاحتياطية التقليدية؟
تكون المزامنة مفيدة خصوصًا للمواقع التي تستقبل بيانات جديدة باستمرار، مثل الطلبات والحجوزات والتعليقات. فالنسخة الاحتياطية القديمة قد لا تتضمن البيانات التي أُضيفت بعد إنشائها. يعتمد الاختيار على طبيعة الموقع والأدوات المتاحة، ويجب اختبار طريقة المزامنة مسبقًا لتجنب فقدان البيانات أو استبدالها.
ما الذي يجب التحقق منه قبل إلغاء الاستضافة القديمة؟
تأكد من استقرار الموقع على الاستضافة الجديدة، وعمل الصفحات ولوحة التحكم والوظائف الأساسية عبر HTTPS، وسلامة قاعدة البيانات والملفات. تحقق أيضًا من نقل البيانات الحديثة، وحفظ نسخة احتياطية خارج الاستضافة القديمة، وعدم اعتماد البريد الإلكتروني أو خدمات أخرى على الحساب السابق. لا تُلغِ الاستضافة قبل استكمال هذه المراجعات.
اختبر فهمك لنقل موقع ووردبريس إلى استضافة جديدة
تتضمن هذه الاختبارات ثلاثة أسئلة تقيس فهمك لخطوات نقل موقع ووردبريس مع الحفاظ على اسم النطاق، وقدرتك على تطبيق المعلومات في مواقف عملية وتحليل القرارات لتقليل التوقف وتجنب فقدان البيانات.
اختبر فهمك لنقل موقع ووردبريس إلى استضافة جديدة
ما الترتيب الأنسب لنقل موقع ووردبريس إلى استضافة جديدة مع الحفاظ على اسم النطاق؟
نقلت ملفات موقع ووردبريس وقاعدة بياناته إلى الاستضافة الجديدة، لكن الموقع يعرض خطأ في الاتصال بقاعدة البيانات. ما الإجراء الأنسب أولًا؟
يدير موقعك متجرًا إلكترونيًا يستقبل طلبات باستمرار. وبعد بدء تغيير DNS، قد يستمر بعض الزوار في الوصول إلى الخادم القديم بينما يصل آخرون إلى الخادم الجديد. ما القرار الأنسب لتقليل خطر فقدان الطلبات أو تضارب البيانات؟
مساحة للنقاش: يعتمد نجاح نقل موقع ووردبريس إلى استضافة جديدة على التخطيط الجيد، وسلامة النسخ الاحتياطية، واختبار الموقع قبل تغيير DNS، مع الحفاظ على اسم النطاق والبيانات. ويظل الاحتفاظ بالاستضافة القديمة ضروريًا حتى استقرار الموقع. ما الخطوة التي تراها الأكثر حساسية لتجنب تعطل موقعك أثناء النقل؟
👈 رأيك يهمنا شاركه معنا في التعليقات.