نقل الموقع لاستضافة جديدة: الترتيب الذي يمنع الكارثة

• فريق Triple

نقل الموقع لاستضافة جديدة: الترتيب الذي يمنع الكارثة

النقل الخاطئ يعني ساعات من التوقف وبريدًا ضائعًا. النقل الصحيح لا يلاحظه أحد. الفرق في الترتيب.

معظم حوادث النقل التي نُستدعى لإصلاحها سببها ترتيب خاطئ: حوّلوا النطاق أولًا ثم بدأوا يرفعون الملفات. النتيجة ساعات من صفحة فارغة.

القاعدة الحاكمة: لا تلمس النطاق قبل أن يعمل الموقع بالكامل على الخادم الجديد ويُختبر.

متى يستحق النقل؟

• بطء بنيوي لا يُحل بتحسين الصور والتخزين المؤقت.
• انقطاعات متكررة أو دعم لا يرد.
• قيود تقنية — إصدار PHP قديم لا يُحدَّث، أو موارد لا تكفي.
• تكلفة غير مبررة مقابل ما تحصل عليه.

وليس سببًا: «سمعت أن استضافة أخرى أحسن». النقل يحمل مخاطرة، فلا تتحملها بلا سبب محدد.

قبل أن تبدأ

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

النقطة الأخيرة تُغفل دائمًا وهي التي تحدد طول فترة الانتقال.

الترتيب الصحيح

الخطوة الثالثة هي التي تمنع الكارثة: تعديل ملف hosts على جهازك يجعل جهازك وحده يرى الخادم الجديد بينما العالم كله لا يزال على القديم. فتختبر بحرية ولا أحد يتأثر.

البريد: الجزء الأخطر

الموقع المتوقف ساعة مزعج. البريد الضائع مشكلة أكبر، لأن الرسالة التي تُرفض أثناء الانتقال قد لا تُعاد.

• أنشئ الصناديق على الخادم الجديد بنفس الأسماء قبل التحويل.
• انقل الرسائل القديمة قبل التحويل لا بعده.
• بعد التحويل، أرسل واستقبل رسالة اختبار لكل صندوق.
• تأكد من نقل سجلات SPF وDKIM وDMARC — إغفالها يعني ذهاب رسائلك للمزعجات.

وانتبه: سجلات البريد في النطاق منفصلة عن سجل الموقع. من الممكن — وأحيانًا الأفضل — أن تنقل الموقع وتترك البريد في مكانه.

بعد التحويل مباشرة

• افتح عينة من كل نوع صفحة: الرئيسية، وخدمة، ومقالة، والتواصل.
• أرسل نموذج التواصل وتأكد من وصوله فعلًا.
• تأكد أن HTTPS يعمل وأن الشهادة سارية.
• تحقق أن إعادة التوجيه في .htaccess انتقلت — هذا ملف مخفي يُنسى كثيرًا في النسخ.
• راجع Search Console أيامًا بحثًا عن أخطاء زحف جديدة.

لا تلغِ القديم بسرعة

أبقِ الاشتراك القديم أسبوعًا إلى أسبوعين. سيظل بعض الزوار يصلون إليه أثناء انتشار التغيير، والأهم أنك تحتاج مصدرًا للرجوع إليه إن اكتشفت ملفًا لم يُنقل.

تكلفة أسبوع إضافي زهيدة مقابل أن تكتشف بعد يومين أن مجلدًا مهمًا لم يُنسخ ولم يعد له وجود.

ما لا يُنقل تلقائيًا

أدوات النقل التلقائي تنقل الملفات وقاعدة البيانات، وتترك أشياء يكتشف صاحب الموقع غيابها بعد أيام:

• المهام المجدولة (cron) — النسخ الاحتياطي، وتقارير دورية، وأي أتمتة. تتوقف بصمت.
• الملفات المخفية — .htaccess وغيره. كثير من الأدوات تتجاهلها افتراضيًا.
• سجلات البريد — SPF وDKIM وDMARC. إغفالها يعني ذهاب رسائلك للمزعجات.
• الشهادات المخصصة إن لم تكن تلقائية.
• النطاقات الفرعية — لوحة تجريبية أو نطاق للبريد قد يُنسى تمامًا.

اكتب قائمة بهذه قبل النقل وراجعها بندًا بندًا بعده. البند الأول تحديدًا يُكتشف متأخرًا: لا أحد يلاحظ توقف النسخ الاحتياطي حتى يحتاجه.

متى تنقل؟

اختر الوقت بحساب لا بالصدفة:

• أقل أوقات الزيارات — راجع تقاريرك، وغالبًا يكون ليلًا في منتصف الأسبوع.
• لا تنقل يوم خميس أو قبل إجازة — إن ظهرت مشكلة تريد يوم عمل كاملًا لمعالجتها.
• لا تنقل في موسم الذروة — متجر يُنقل في موسم البيع مخاطرة بلا داعٍ.
• تأكد من توفر الجميع — من يملك وصول النطاق يجب أن يكون متاحًا لا مسافرًا.

النقطة الأخيرة أوقفت عمليات نقل أكثر مما تتوقع: كل شيء جاهز وبيانات الدخول للنطاق مع شخص لا يرد.