لست راضياً عن الاستضافة الحالية؛ الموقع بطيء، أو الدعم الفني لا يرد، أو وصلت إلى طريق مسدود مع المصمم السابق. لكن معظم متاعب نقل الموقع إلى استضافة جديدة لا تأتي من عملية النقل نفسها، بل من أن صاحب الموقع لا يملك قبل البدء مفاتيح كل الأبواب.
يتكون هذا الدليل من ثلاثة أجزاء: استعادة السيطرة، ثم النقل نفسه بأقل توقف ممكن، ثم الحفاظ على SEO والمتابعة بعد النقل. سواء نفذت العمل بنفسك أو أسندته إلى شركة دعم جديدة، عليك أن تعرف ماذا تطلب وماذا تتحقق منه.
قبل أي خطوة: ما الذي يجب أن يكون ملكك أنت؟
الموقع ليس مجرد ملفات على خادم؛ إنه مجموعة من الحسابات، وإذا بقي أحدها في يد شخص آخر، يبقى النقل ناقصاً أو يتوقف شيء ما عن العمل بصمت. قبل تغيير شركة دعم موقعك، أكمل هذه القائمة:
- حساب مسجّل النطاق (Domain Registrar) والبريد الإلكتروني المرتبط بهذا الحساب. إذا كان بريد الاسترداد ملكاً للمصمم السابق، فالنطاق عملياً ما زال في يده.
- لوحة الاستضافة (cPanel أو DirectAdmin أو لوحة شركة الاستضافة) وحساب المستخدم لدى شركة الاستضافة نفسها.
- إدارة DNS؛ أحياناً تكون إعدادات DNS على خدمة مثل Cloudflare ضمن حساب شخص آخر.
- قاعدة البيانات وبيانات الدخول إليها.
- الشيفرة المصدرية أو مستودع الشيفرة للموقع المبني ببرمجة مخصصة؛ وفي ووردبريس (WordPress): تراخيص القوالب والإضافات المدفوعة والحساب الذي اشتُريت به.
- حساب المدير العام للموقع ببريدك الإلكتروني أنت.
- Google Search Console وGoogle Analytics بصلاحية المالك (Owner)، لا مجرد مستخدم.
- حسابات البريد الإلكتروني الخاصة بالشركة وكلمات مرورها.
- حساب بوابة الدفع؛ تحقّق لمن يعود البريد الإلكتروني ورقم الجوال المسجلان فيه.
- حساب مزوّد الرسائل النصية (SMS) ومفتاح API الخاص به.
قاعدة بسيطة: أينما كان تسجيل الدخول يتم ببريد المصمم أو رقم جواله، فهذا الأصل لم يصبح ملكك بالكامل بعد.
استلام الموقع من المصمم السابق بأسلوب مهذب وكتابياً
حتى لو كنت غير راضٍ، ابدأ بنبرة هادئة؛ فالخلاف لا يفعل سوى إبطاء العمل. أرسل الطلب كتابياً (بريد إلكتروني أو تطبيق مراسلة يحتفظ بالسجل) وضمّنه ما يلي:
- قائمة دقيقة بالصلاحيات المطلوبة، وفق القسم السابق.
- تغيير بريد الاسترداد في الحسابات إلى بريدك أنت.
- نسخة احتياطية كاملة حالية (الملفات وقاعدة البيانات) مؤرخة.
- التفاصيل الفنية التي لا يعرفها سواه: مهام Cron، وإعدادات الخادم الخاصة، والخدمات الخارجية المرتبطة بالموقع.
- مهلة معقولة وشكراً على التعاون.
إذا كان عليك مبلغ مستحق، فسوِّه أولاً؛ من الطبيعي ألا يسلّم المصمم الشيفرة قبل التسوية. وبعد الاستلام، غيّر جميع كلمات المرور بنفسك، واحذف المستخدمين الزائدين من الموقع والاستضافة، وأنشئ مفاتيح API جديدة.
إذا كان النطاق مسجلاً باسم المصمم السابق
هذه أخطر حالة. فمن وجهة نظر جهة التسجيل، مالك النطاق هو من سُجّل النطاق باسمه، لا من دفع تكلفته. الخطوة الأولى طلب كتابي لنقل ملكية النطاق؛ وإذا لم يتعاون، فستفيدك مستندات الدفع والعقد. تجد التفاصيل والبنود التي يجب أن يتضمنها العقد منذ البداية في مقال عقد تصميم الموقع. لا تبدأ النقل قبل أن تتضح ملكية النطاق.
نسخة احتياطية كاملة، واستعادة تجريبية، واختيار الاستضافة
النسخة الاحتياطية التي لم تُستعد قط مجرد أمل. تحتاج إلى شيئين: نسخة كاملة من الملفات (بما فيها مجلد الرفع، وملفات الإعدادات مثل wp-config.php أو .env، وملف .htaccess) وتصدير كامل لقاعدة البيانات. احتفظ بالنسخة خارج الاستضافة الحالية، واستعدها مرة واحدة في بيئة منفصلة لتتأكد من سلامتها. اطّلع على روتين النسخ الاحتياطي المنتظم في قائمة صيانة ووردبريس. وإذا كنت تشك في أن الموقع مصاب، فنظّفه قبل النقل، وإلا ستنقل الإصابة معه (استعادة الموقع المخترق).
شرحنا اختيار الاستضافة بشكل منفصل في دليل النطاق والاستضافة. وهذه ثلاث نقاط خاصة بالنقل:
- يجب أن يتوافق إصدار PHP وقاعدة البيانات في الاستضافة الجديدة مع موقعك الحالي؛ دوّن الإصدارات الحالية من الاستضافة القديمة.
- إذا كانت بوابة الدفع لديك لا تقبل الطلبات إلا من عناوين IP أو مواقع خوادم معتمدة، فاسأل مزود الدفع قبل اختيار الاستضافة الجديدة هل يقبل الطلبات القادمة منها.
- لا تلغِ الاستضافة القديمة في الوقت نفسه الذي تشتري فيه الجديدة؛ ستحتاج إلى الاثنتين لبضعة أيام.
نسخ الملفات وقاعدة البيانات، ثم الاختبار قبل تغيير DNS
انقل الملفات إلى الاستضافة الجديدة، وأنشئ قاعدة بيانات فارغة، واستورد فيها النسخة المصدّرة، وحدّث بيانات الاتصال في ملف الإعدادات. هناك نقطتان تُنسيان كثيراً: يجب أن يكون مجلد الرفع قابلاً للكتابة، ويجب الحفاظ على ترميز قاعدة البيانات (utf8mb4)، وإلا تحوّل النص العربي إلى علامات استفهام.
قبل أن يصل زائر واحد إلى الاستضافة الجديدة، شاهد الموقع هناك بنفسك. أفضل طريقة هي ملف hosts: على حاسوبك تطلب من النظام أن يوجّه النطاق إلى عنوان IP الخاص بالاستضافة الجديدة. بهذه الطريقة ترى أنت وحدك الموقع من الخادم الجديد وبنطاقه الحقيقي. العنوان المؤقت الذي تقدمه بعض الاستضافات يعمل أيضاً، لكن ووردبريس يعيدك عادةً إلى النطاق الأصلي.
اختبر كل شيء فعلياً: الصفحات الداخلية، والبحث، ونموذج التواصل، وتسجيل الدخول، وسلة الشراء، ولوحة التحكم. أصلح كل خطأ هنا، لا بعد تغيير DNS.
خفّض قيمة TTL مسبقاً، ثم غيّر DNS
تحدد قيمة TTL المدة التي تحتفظ فيها خوادم DNS حول العالم بالإجابة السابقة. إذا كانت قيمة TTL لديك عدة ساعات، فبعد تغيير عنوان IP سيستمر بعض المستخدمين في الذهاب إلى الخادم القديم طوال تلك المدة. لذلك قبل النقل بيوم أو يومين، خفّض TTL لسجلَّي A وwww إلى قيمة قصيرة مثل 300 ثانية، ثم ارفعها مجدداً بعد الاستقرار.
نفّذ التغيير في ساعة قليلة الزيارات. وإذا كنت ستغيّر خوادم الأسماء (Nameservers) بدلاً من سجل A، فإن هذا التغيير ينتشر عادةً بشكل أبطأ؛ وقبل تنفيذه أعد إنشاء جميع السجلات في DNS الجديد.
أبقِ الاستضافة القديمة تعمل لبضعة أيام
بعد تغيير DNS، أبقِ الاستضافة القديمة فعّالة لبضعة أيام على الأقل: فبعض المستخدمين وخوادم البريد ما زالوا يذهبون إلى العنوان القديم، وإذا حدثت مشكلة، فالعودة لا تتطلب سوى تغيير واحد في DNS. وإذا كان الموقع يستقبل طلبات شراء، فأغلق تسجيل الطلبات على النسخة القديمة، وإلا سيُسجَّل جزء من الطلبات في قاعدة البيانات القديمة ويضيع.
ما الذي يُنسى عادةً
عندما يعمل الموقع على الاستضافة الجديدة، لا يكون العمل قد انتهى. هذه البنود الخمسة تسبب معظم المشكلات.
شهادة SSL
تُثبَّت شهادة SSL على الخادم، ويجب إصدارها أو تثبيتها على الاستضافة الجديدة أيضاً. الشهادة المجانية التلقائية لا تصدر عادةً إلا بعد توجيه DNS إلى الخادم الجديد، لذلك قد يعرض المتصفح تحذيراً لفترة قصيرة. إذا كانت لديك شهادة مدفوعة، فخذ ملفاتها من الاستضافة القديمة؛ وإلا فاسأل الاستضافة الجديدة كيف يمكن الحصول على شهادة قبل تغيير DNS.
البريد الإلكتروني وسجلات MX: القطعة المنسية الكلاسيكية
إذا كان بريد الشركة على الاستضافة القديمة، فإن تغيير خوادم الأسماء قد يوقف البريد بصمت، وأحياناً لا ينتبه أحد إلا بعد أيام. قبل النقل، حدّد أين يُستضاف بريدك؛ أنشئ صناديق البريد في الوجهة الجديدة وانقل الرسائل القديمة عبر IMAP. أعد إنشاء سجلات MX وSPF وDKIM وDMARC بدقة في DNS الجديد؛ فسجل SPF الناقص يعني أن رسائلك ستصل إلى مجلد البريد المزعج لدى عميلك. ثم اختبر الاستقبال والإرسال كليهما.
مهام Cron (Cron Jobs)
المهام المجدولة جزء من إعدادات الخادم ولا تنتقل بنسخ الملفات: النشرة البريدية، والنسخ الاحتياطي التلقائي، وإلغاء الطلبات غير المدفوعة، ومزامنة المخزون. دوّن قائمتها من الاستضافة القديمة وأنشئها في الاستضافة الجديدة.
بوابة الدفع: رابط العودة وعنوان IP للخادم
قد يكون هذا حاسماً للمتاجر الإلكترونية. بعض بوابات الدفع لا تقبل طلبات تأكيد المعاملات إلا من عنوان IP المسجّل لخادمك. وعند تغيير الاستضافة يتغير عنوان IP، وقد يدفع العميل بينما يُسجَّل طلبه «فاشلاً».
قبل النقل، أرسل عنوان IP الخاص بالاستضافة الجديدة إلى الدعم الفني لبوابة الدفع لإضافته إلى القائمة المسموح بها. وإذا تغيّر عنوان الموقع، فحدّث أيضاً رابط العودة (Callback URL) في لوحة البوابة. ثم نفّذ عملية شراء حقيقية بمبلغ صغير. تجد تفاصيل البوابات في دليل بوابات الدفع. كما أن بعض مزودي الرسائل النصية يقصرون الإرسال على عناوين IP محددة.
رسائل البريد التي يرسلها الموقع نفسه (SMTP)
رسائل تأكيد الطلب واستعادة كلمة المرور ونموذج التواصل تُرسَل غالباً عبر دالة البريد في الخادم نفسه، وقد تكون معطلة على الخادم الجديد. الأفضل أن يرسل الموقع عبر SMTP من صندوق بريد حقيقي؛ وبعد النقل اختبر نموذج التواصل واستعادة كلمة المرور.
SEO: إذا لم تتغير الروابط فلا حاجة إلى إعادة التوجيه
القلق الأكبر لدى معظم أصحاب المواقع هو فقدان الترتيب. تغيير الاستضافة وحده لا يغيّر شيئاً بالنسبة إلى جوجل: النطاق نفسه، والروابط نفسها، والمحتوى نفسه. في هذه الحالة يعتمد نقل الموقع دون خسارة SEO في الغالب على بقاء الموقع سليماً خلال فترة الانتقال:
- قلّل التوقف الطويل وأخطاء سلسلة 500 إلى الحد الأدنى؛ فالأخطاء المتكررة تقلل زحف جوجل.
- تأكد من أن ملف
robots.txtهو النسخة السابقة نفسها، وأن خيار «منع محركات البحث من أرشفة هذا الموقع» في ووردبريس معطَّل. - قِس سرعة الخادم الجديد وقارن مؤشرات Core Web Vitals (مثل LCP خلال 2.5 ثانية) قبل النقل وبعده.
إذا تغيّر النطاق أو روابط الصفحات
إذا كنت تغيّر النطاق أو بنية الروابط في الوقت نفسه، فكل رابط قديم يحتاج إلى إعادة توجيه 301 إلى ما يقابله في الموقع الجديد؛ وقد شرحنا إعداد هذه الخريطة في مقال إعادة تصميم الموقع. وإذا تغيّر النطاق، فبعد تفعيل إعادة التوجيه استخدم أداة Change of Address في Search Console (دليل جوجل الرسمي لنقل المواقع) وأبقِ إعادة التوجيه لفترة طويلة. وتغيير النطاق يعني أيضاً تحديث تسجيل بوابة الدفع، ومتطلبات الثقة والمتطلبات القانونية في سوقك، للنطاق الجديد.
نصيحتنا: إن استطعت، فلا تغيّر الاستضافة والنطاق في الوقت نفسه؛ وإلا فإذا حدث تراجع، فلن تعرف أيهما كان السبب.
المتابعة بعد النقل
خلال الأسبوعين الأولين، راقب هذه البنود بانتظام:
- Search Console: تقرير الصفحات بحثاً عن أخطاء الخادم أو «لم يتم العثور عليها»، وإحصاءات الزحف.
- Analytics: أي تراجع مفاجئ في الزيارات أو الطلبات أو النماذج، وهل ما زالت شيفرة التحليلات تُحمَّل.
- الطلبات والمدفوعات: طابقها مع تقرير البوابة؛ فالدفع الناجح بلا طلب يعني مشكلة في عنوان IP أو رابط العودة.
- البريد الإلكتروني والنسخ الاحتياطي التلقائي في الاستضافة الجديدة: هل يعملان فعلاً؟
عندما تبقى كل هذه البنود سليمة لعدة أيام متتالية، خذ نسخة احتياطية نهائية من الاستضافة القديمة ثم ألغِها.
قائمة التحقق لنقل الموقع إلى استضافة جديدة
حدّد مسؤولاً لكل صف، ولا تضع علامة في العمود الأخير إلا بعد الاختبار الفعلي.
| المرحلة | المسؤول | تم التحقق؟ |
|---|---|---|
| صلاحية المالك على لوحة النطاق وبريد الاسترداد الخاص بها | صاحب العمل | ☐ |
| استلام الاستضافة وDNS والشيفرة والتراخيص وSearch Console وAnalytics | صاحب العمل + المصمم السابق | ☐ |
| تغيير جميع كلمات المرور وحذف المستخدمين الزائدين | صاحب العمل | ☐ |
| نسخة احتياطية كاملة خارج الاستضافة + استعادة تجريبية | الفريق الفني | ☐ |
| تدوين إصدار PHP ومهام Cron وسجلات DNS | الفريق الفني | ☐ |
| تسجيل عنوان IP الجديد لدى بوابة الدفع ومزوّد الرسائل النصية | صاحب العمل + الفريق الفني | ☐ |
| خفض TTL قبل النقل بيوم أو يومين | الفريق الفني | ☐ |
| اختبار كامل على الاستضافة الجديدة عبر ملف hosts | الفريق الفني + صاحب العمل | ☐ |
| تجهيز SSL وسجلات MX وSPF وDKIM وDMARC | الفريق الفني | ☐ |
| تغيير DNS وإغلاق تسجيل الطلبات على الاستضافة القديمة | الفريق الفني | ☐ |
| شراء تجريبي، واختبار نموذج التواصل والبريد، ومراجعة robots.txt | صاحب العمل + الفريق الفني | ☐ |
| متابعة الأسبوعين الأولين، ونسخة احتياطية نهائية، وإلغاء الاستضافة القديمة | كلاهما | ☐ |
هل تنفذ النقل بنفسك أم تسنده إلى غيرك؟
بالنسبة إلى موقع تعريفي بسيط بلا بريد شركة ولا بوابة دفع، يمكن تنفيذ النقل بهذا الدليل وبمساعدة الدعم الفني للاستضافة الجديدة. أما عندما يكون هناك متجر وبوابة دفع ومزوّد رسائل نصية وبريد شركة، فكل قطعة تُنسى لها تكلفة حقيقية: طلب ضائع أو رسالة لم تصل.
إذا أردت إسناد هذا العمل، فنطاقه وتكلفته يعتمدان على حجم الموقع وتعقيده، ويجب تحديدهما كتابياً قبل البدء. وبعد النقل يحتاج الموقع أيضاً إلى صيانة منتظمة؛ يبدأ الدعم في MyTarh بمراجعة فنية وأمنية أولية، وتجد التفاصيل في صفحة خدمات صيانة المواقع ورعايتها. لا نعد بـ«صفر ثانية من التوقف» أو «ضمان الحفاظ على الترتيب»، لأن أحداً لا يستطيع أن يعد بذلك بصدق؛ ما نقدمه هو إجراء منظم يقلل المخاطر.
الخلاصة
نقل الموقع لا يبدأ من لوحة الاستضافة، بل من استعادة السيطرة على النطاق والحسابات والشيفرة. بعد ذلك، تغطي معظمَ المخاطر نسخةٌ احتياطية جرت استعادتها فعلاً، والاختبار عبر ملف hosts، وقيمة TTL قصيرة، وإبقاء الاستضافة القديمة تعمل، والانتباه إلى البريد وبوابة الدفع ومهام Cron. وإذا بقيت الروابط ثابتة، فإن SEO لا يتضرر عادةً.
الخطوة التالية: املأ اليوم قائمة القسم الأول، وانظر أي صلاحية ما زالت ليست في يدك. وإذا لم تكن تعرف من أين تبدأ، فاحجز مكالمة تعارف مجانية مدتها 30 دقيقة لنراجع وضع موقعك معاً.
الأسئلة الشائعة
كم يستغرق توقف الموقع عند نقله إلى استضافة جديدة؟
إذا كان الموقع قد اختُبر مسبقاً على الاستضافة الجديدة، وخُفّضت قيمة TTL، وبقيت الاستضافة القديمة تعمل حتى يكتمل انتشار DNS، فلن يلاحظ معظم المستخدمين أي توقف ملموس. وقد يرى جزء من الزوار النسخة القديمة خلال الساعات الأولى. لا أحد يستطيع ضمان انعدام التوقف تماماً، لكن هذا الإجراء يقلله إلى الحد الأدنى.
هل يؤثر تغيير الاستضافة على SEO وترتيب الموقع في جوجل؟
إذا بقي النطاق وروابط الصفحات كما هي، فإن تغيير الاستضافة وحده لا يترك عادةً أثراً سلبياً. ما يسبب الضرر هو التوقف الطويل، وأخطاء الخادم، وتباطؤ الموقع، أو منع الأرشفة دون قصد في ملف robots.txt. بعد النقل تابع تقارير Search Console لمدة أسبوعين حتى تكتشف أي خطأ مبكراً.
المصمم السابق لا يسلّم الصلاحيات؛ ماذا أفعل؟
سوِّ أولاً أي مبلغ مستحق محتمل، ثم أرسل طلباً كتابياً مهذباً يتضمن قائمة دقيقة بالصلاحيات. إذا كان النطاق باسمك أنت، فيمكنك من لوحة النطاق توجيه DNS إلى الاستضافة الجديدة وإعادة بناء الموقع من نسخة احتياطية. أما إذا كان النطاق باسمه، فملكية النطاق هي الأولوية، وستفيدك مستندات الدفع والعقد.
لماذا يتم الدفع بعد النقل لكن الطلب يُسجَّل فاشلاً؟
السبب الأكثر شيوعاً أن بوابة الدفع لا تقبل طلبات تأكيد المعاملات إلا من عنوان IP السابق للخادم. أبلغ الدعم الفني للبوابة بعنوان IP الخاص بالاستضافة الجديدة لإضافته إلى القائمة المسموح بها، وإذا تغيّر عنوان الموقع فصحّح رابط العودة في لوحة البوابة. ثم نفّذ عملية شراء تجريبية بمبلغ صغير.
متى ألغي الاستضافة القديمة؟
عندما يعمل الموقع على الاستضافة الجديدة دون أخطاء لعدة أيام متتالية، وتصل رسائل البريد في الاتجاهين، وتنجح عملية الدفع التجريبية، ويُنفَّذ النسخ الاحتياطي التلقائي في الاستضافة الجديدة مرة واحدة على الأقل. قبل الإلغاء، خذ نسخة احتياطية نهائية كاملة من الاستضافة القديمة واحفظها في مكان آمن.