كيفية ترحيل الخادم (Migration) بدون فقدان بيانات؟ دليل نقل الموقع إلى استضافة جديدة

ترحيل الخادم (Migration) هو عملية نقل ملفات الموقع وقاعدة البيانات وحسابات البريد الإلكتروني وسجلات DNS وإعدادات التطبيقات من الخادم الحالي إلى خادم جديد بطريقة مخططة. لنقل الموقع بدون فقدان بيانات، اتبع الخطوات الأساسية: أخذ نسخة احتياطية كاملة، تجهيز الخادم الجديد بنفس الإصدارات أو إصدارات أحدث من البرمجيات، نقل الملفات وقاعدة البيانات، اختبار الموقع عبر ملف hosts أو رابط مؤقت، تغيير سجلات DNS بقيمة TTL منخفضة، ثم التحقق بعد النقل من السجلات والنماذج وتدفق الدفع وتسليم البريد وإشارات SEO.

عملية ترحيل الخادم ليست مجرد نسخ ولصق بسيط. خاصة لمواقع WordPress أو WooCommerce أو Laravel أو تطبيقات PHP المخصصة أو المواقع الإخبارية ذات الزيارات العالية أو الشركات التي تعتمد على البريد الإلكتروني المؤسسي، قد يؤدي أي خطأ في النقل إلى فقدان الطلبات أو تشوه الحروف العربية أو أخطاء 500 أو تحذيرات SSL أو انقطاع البريد الإلكتروني أو انخفاض ظهور الموقع في محركات البحث. لذلك يجب تنفيذ الترحيل وفق خطة واضحة وقائمة تحقق فنية وسيناريو للرجوع السريع.

في هذا الدليل سنشرح خطوة بخطوة كيفية إجراء تغيير الاستضافة أو الخادم بما يتوافق مع متطلبات SEO والأداء لعام 2026. كما سنتناول سيناريوهات مختلفة مثل cPanel وPlesk وVPS والخوادم السحابية والنقل اليدوي، مع تقديم نصائح عملية حول مدة انتشار DNS ونطاق النسخ الاحتياطي وتوافق قواعد البيانات وتثبيت SSL والتحقق من SEO بعد الترحيل.

متى تحتاج إلى ترحيل الخادم؟

عادةً ما يتم نقل الموقع إلى خادم جديد بسبب الحاجة إلى أداء أفضل أو أمان أعلى أو تكلفة أقل أو إمكانية التوسع. فموقع مؤسسي يستقبل 5 آلاف زائر شهريًا قد يعمل بسلاسة على استضافة مشتركة، بينما متجر إلكتروني يستقبل 20 ألف زائر يوميًا قد يواجه حدود المعالج واستعلامات بطيئة وانتهاء مهلة صفحة الدفع. هنا يُفضل الانتقال إلى باقة استضافة أقوى أو VPS أو بنية سحابية.

إليك أبرز المؤشرات التي تدل على ضرورة ترحيل الخادم:

• زمن تحميل الصفحة يتجاوز 3 ثوانٍ وتدهور مقاييس Core Web Vitals.
• امتلاء حدود CPU أو RAM أو inode أو مساحة القرص بشكل متكرر في لوحة التحكم.
• الحاجة إلى إصدارات أحدث من PHP أو MySQL أو MariaDB أو Node.js أو ionCube.
• مشكلات متكررة في تجديد SSL أو تسليم البريد الإلكتروني أو إدارة DNS.
• انخفاض جودة الدعم أو النسخ الاحتياطي أو مستوى الأمان لدى المزود الحالي.
• ارتفاع مفاجئ في عدد الزوار خلال الحملات أو المواسم.

إذا كان موقعك ينمو ويقترب من حدود الباقة الحالية، فمن الأفضل وضع خطة ترحيل مدروسة بدلًا من الانتظار حتى لحظة الأزمة. يمكنك مقارنة حزم استضافة الويب أو حلول خوادم VPS أو استضافة مؤسسية لاختيار البنية المناسبة.

الاستعداد قبل الترحيل: المرحلة الأهم

معظم حالات فقدان البيانات أثناء الترحيل تحدث بسبب نقص التحضير وليس أثناء النقل نفسه. قبل البدء يجب جرد محتويات الموقع الحالي وتحديد البيانات التي ستُنقل والخدمات الحساسة للانقطاع.

1. أعد جردًا فنيًا للموقع

ابدأ برسم خريطة تقنية للموقع: نوع نظام إدارة المحتوى أو الإطار البرمجي، إصدار PHP، نوع قاعدة البيانات، حجم القرص، حسابات البريد، مهام cron، سجلات DNS، شهادة SSL، إعادة التوجيه المخصصة، والتكاملات الخارجية. في موقع WordPress على سبيل المثال، لا يكفي نقل مجلد wp-content فقط؛ بل يجب فحص قواعد .htaccess وإعدادات wp-config.php والبادئات الخاصة بجداول قاعدة البيانات وإضافات التخزين المؤقت وملفات الوسائط.

أما في المتاجر الإلكترونية فيجب فحص بوابات الدفع وتكامل الشحن ومزامنة المخزون وارتباط ERP وخدمة SMTP وعناوين webhook. إذا توقفت الطلبات بعد النقل، فغالباً ما يكون السبب قاعدة أمان IP قديمة أو قيد نسيتَ تحديثه وليس مشكلة في نقل الملفات.

2. خذ نسخة احتياطية كاملة وتحقق منها

مجرد أخذ نسخة احتياطية لا يكفي؛ يجب التأكد من إمكانية استعادتها. يجب أن تغطي النسخة الاحتياطية الكاملة العناصر التالية:

• ملفات الموقع: مجلد public_html ومجلدات التطبيق ومجلدات التحميل وملفات القوالب والإضافات.
• قواعد البيانات: MySQL أو MariaDB أو PostgreSQL أو أي قاعدة بيانات أخرى يستخدمها التطبيق.
• بيانات البريد الإلكتروني: صناديق البريد وإعادة التوجيه والفلاتر وإعدادات الرد الآلي.
• سجلات DNS: A وAAAA وCNAME وMX وTXT وSPF وDKIM وDMARC.
• ملفات الإعدادات: .htaccess وnginx.conf وphp.ini ومهام cron وملفات البيئة.
• شهادات SSL وقواعد الأمان المخصصة.

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

3. خفض قيمة TTL لسجلات DNS مسبقًا

لتسريع انتشار تغييرات DNS، قم بخفض قيمة TTL قبل 24 ساعة من بدء الترحيل. إذا كانت القيمة 14400 ثانية فقد يستمر بعض الزوار في الوصول إلى الخادم القديم لساعات. خفض القيمة إلى 300 ثانية يجعل الانتقال أكثر تحكمًا. بعد اكتمال الترحيل والتحقق يمكنك إعادة القيمة إلى 3600 أو 14400 ثانية.

إدارة DNS بشكل منتظم تؤثر مباشرة على نجاح الترحيل. يمكنك الاطلاع على استعلام عن النطاق وإدارة اسم المجال لمعرفة المزيد.

مقارنة طرق ترحيل الخادم

لا توجد طريقة واحدة تناسب جميع المواقع. موقع مؤسسي صغير يمكن نقله بسهولة عبر لوحة التحكم، بينما المتاجر الإلكترونية ذات الزيارات العالية تحتاج إلى مزامنة تدريجية ووضع صيانة.

عند اختيار البنية الجديدة لا تنظر إلى مساحة القرص فقط. عدد عمليات PHP وعدد أنوية المعالج وحجم الذاكرة ونوع القرص NVMe وتكرار النسخ الاحتياطي وموقع مركز البيانات ودعم LiteSpeed أو Nginx وجدار الحماية WAF وحماية DDoS كلها عوامل تحدد الأداء. لذلك تجنب الانتقال إلى أرخص باقة دون تحليل احتياجاتك حتى لا تضطر للترحيل مرة أخرى قريبًا.

كيفية ترحيل الخادم خطوة بخطوة

الخطوة 1: تجهيز الخادم الجديد

يجب تثبيت نظام التشغيل وخادم الويب وإصدار PHP وخدمة قاعدة البيانات والوحدات المطلوبة على الخادم الجديد. لمواقع WordPress يُفضل PHP 8.2 أو 8.3 مع MariaDB حديث وOPcache وقيمة memory_limit مناسبة. أما لإطارات مثل Laravel فيجب إعداد Composer ومهام cron وqueue worker وصلاحيات مجلد storage. إذا كانت إضافات PHP التي تعمل على الخادم القديم غير متوفرة على الجديد، قد تظهر شاشة بيضاء أو خطأ 500 بعد النقل.

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

الخطوة 2: نقل الملفات

يمكن استخدام FTP أو SFTP أو SSH أو rsync أو أدوات النسخ الاحتياطي في لوحة التحكم حسب حجم الموقع. للمواقع الصغيرة يكفي إنشاء أرشيف مضغوط واستخراجه على الخادم الجديد. أما المواقع الكبيرة فيُفضل أخذ نسخة أولى بـ rsync ثم مزامنة ثانية قبل تغيير DNS مباشرة. هذه الطريقة توفر وقتًا كبيرًا خاصة في المجلدات التي تتغير باستمرار مثل مجلد التحميلات.

بعد نقل الملفات تحقق من الصلاحيات. عادةً تكون صلاحية المجلدات 755 والملفات 644، لكن كل تطبيق له متطلباته الخاصة. ملفات wp-config.php أو .env يجب ألا تكون قابلة للقراءة من الجميع. تأكد أيضًا من نسخ الملفات المخفية مثل .htaccess و.user.ini.

الخطوة 3: نقل قاعدة البيانات

نقل قاعدة البيانات هو الجزء الأكثر حساسية لتجنب فقدان البيانات. خذ نسخة dump من الخادم القديم، ثم أنشئ قاعدة البيانات والمستخدم على الخادم الجديد. يُفضل ضبط مجموعة الأحرف على utf8mb4. للحفاظ على الحروف العربية سليمة يجب الحفاظ على نفس بنية collation أثناء التصدير والاستيراد.

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

الخطوة 4: تحديث ملفات الإعدادات

قم بتعديل اسم قاعدة البيانات واسم المستخدم وكلمة المرور ومعلومات المضيف ومسارات الملفات بما يناسب الخادم الجديد. في WordPress عدّل wp-config.php، وفي Laravel عدّل .env، وفي التطبيقات المخصصة عدّل config.php أو الملفات المماثلة. إذا بقيت مسارات الملفات المطلقة أو عناوين IP أو إعدادات SMTP القديمة، قد يفتح الموقع ظاهريًا لكنه يُنتج أخطاء في الخلفية.

كذلك اضبط قيم PHP memory_limit وupload_max_filesize وpost_max_size وmax_execution_time حسب احتياجات التطبيق. إذا كان هناك لوحة إدارة ترفع صور منتجات بحجم 200 ميجابايت وكان حد الرفع 32 ميجابايت فقط، فلن تكتمل العمليات حتى لو نجح النقل.

الخطوة 5: اختبر الموقع قبل تغيير DNS

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

قائمة الاختبار يجب أن تشمل:

• هل تفتح الصفحة الرئيسية والتصنيفات والمنتجات والمدونة وصفحة الاتصال؟
• هل تعمل إرسال النماذج وتسجيل الدخول وإعادة تعيين كلمة المرور وتدفق الدفع؟
• هل تُحمَّل الصور وملفات CSS وJavaScript بشكل كامل؟
• هل تفتح لوحة الإدارة بدون أخطاء؟
• هل شهادة SSL مثبتة على النطاق الصحيح؟
• هل توجد أخطاء 404 أو 500 أو mixed content أو حلقات إعادة توجيه؟
• هل ملفات robots.txt وsitemap.xml وعلامات canonical صحيحة؟

الخطوة 6: تثبيت شهادة SSL

في المواقع الحديثة لم يعد SSL مجرد أمان بل أصبح ضروريًا لـ SEO وثقة الزوار. إذا غيّرت DNS قبل تثبيت SSL على الخادم الجديد، سيظهر تحذير "غير آمن" للزوار. لذلك جهّز شهادة SSL قبل أو أثناء تغيير DNS. شهادات Let’s Encrypt المجانية تكفي لمعظم المواقع، أما المشاريع المؤسسية التي تتعامل مع مدفوعات فيُفضل شهادات ذات مستوى تحقق أعلى.

بعد تثبيت SSL تأكد من إعادة توجيه عناوين HTTP إلى HTTPS باستخدام 301، وعدم وجود أخطاء mixed content، ووجود عناوين HTTPS في خريطة الموقع. يمكنك الاطلاع على شهادات SSL لمعرفة الخيارات المتاحة.

الخطوة 7: تغيير سجلات DNS

بعد نجاح الاختبارات، وجّه سجل A إلى عنوان IP الخادم الجديد. إذا كان البريد الإلكتروني يُستضاف على نفس الخادم، حدّث أيضًا سجلات MX وSPF وDKIM وDMARC. أما إذا بقي البريد لدى مزود آخر فلا تلمس سجلات MX. من أكثر الأخطاء شيوعًا تغيير سجلات البريد بالخطأ أثناء نقل الموقع فقط، مما يؤدي إلى انقطاع البريد الإلكتروني.

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

الخطوة 8: إجراء المزامنة النهائية والتحقق من السجلات

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

راقب خلال أول 24 ساعة أخطاء 500 وزيادة أخطاء 404 والاستعلامات البطيئة وارتفاعات CPU وطوابير البريد الإلكتروني. إهمال هذه المتابعة قد يجعل الموقع يبدو سليمًا بينما يحدث فقدان في التحويلات خلف الكواليس.

قائمة التحقق الاحترافية لنقل الموقع بدون فقدان بيانات

تغطي القائمة التالية أكثر النقاط التي تسبب مشكلات عملية. استخدامها قبل وبعد الترحيل يقلل من مخاطر الترحيل بشكل كبير.

• تم تخطيط وقت الترحيل خلال ساعات الزيارات المنخفضة.
• تم أخذ نسخ احتياطية كاملة للملفات وقاعدة البيانات والبريد وسجلات DNS.
• تم اختبار إمكانية فتح النسخ الاحتياطية واستعادتها.
• تم خفض قيمة TTL لـ DNS قبل 24 ساعة على الأقل.
• تم تجهيز PHP وقاعدة البيانات والوحدات المطلوبة على الخادم الجديد.
• تم نقل الملفات كاملة وفحص الصلاحيات.
• تم التحقق من توافق مجموعة الأحرف وcollation في قاعدة البيانات.
• تم تحديث ملفات الإعدادات بمعلومات الخادم الجديد.
• تم الاختبار عبر ملف hosts قبل النشر الفعلي.
• تم تثبيت SSL والتحقق من إعادة توجيه HTTPS.
• تم تحديث سجلات A وAAAA وMX وTXT بشكل صحيح.
• تم الاحتفاظ بالخادم القديم نشطًا لمدة 48 ساعة على الأقل.
• تمت متابعة Google Search Console وAnalytics والسجلات.

كيف تتجنب فقدان ترتيب SEO بعد الترحيل

نظريًا لا يؤدي ترحيل الخادم إلى فقدان SEO طالما لم تتغير بنية الروابط. لكن عمليًا قد تؤثر البطء أو أخطاء 404 أو robots.txt خاطئ أو SSL ناقص أو أخطاء إعادة التوجيه على الترتيب. لذلك يُعد التحقق من SEO بعد الترحيل بنفس أهمية الترحيل الفني نفسه.

التحقق من الروابط وإعادة التوجيه

إذا لم تغيّر بنية الروابط أثناء النقل فستكون الحاجة إلى إعادة التوجيه 301 محدودة. أما إذا تغير النطاق أو بنية الروابط الدائمة أو هيكل المجلدات فيجب إعادة توجيه الروابط القديمة إلى الجديدة بـ 301. إعادة التوجيه 302 مؤقتة ولا تنقل إشارات SEO بشكل دائم. على سبيل المثال إذا انتقلت صفحة /urun/abc إلى /magaza/abc فيجب إعادة التوجيه مباشرة وليس إلى الصفحة الرئيسية.

التحقق من robots.txt وخريطة الموقع

إذا استخدمت Disallow في robots.txt أثناء الاختبار لمنع محركات البحث، فأزلها بعد النشر. هذا الخطأ من أكثر أسباب فقدان الفهرسة شيوعًا بعد الترحيل. يجب أن تحتوي خريطة الموقع على عناوين HTTPS الجديدة وإعادة إرسالها عبر Google Search Console.

الأداء وCore Web Vitals

حتى لو كان الخادم الجديد أقوى، قد يؤدي إعداد التخزين المؤقت الخاطئ إلى انخفاض الأداء. تأكد من تكوين LiteSpeed Cache أو Redis أو OPcache أو CDN وتحسين الصور بشكل صحيح. خلال الأسبوع الأول راقب PageSpeed Insights وChrome UX Report وسجلات الخادم للتحقق من عدم تدهور مقاييس LCP وINP وCLS. يمكنك الاستفادة من محتوى تحسين سرعة ووردبريس لتحسين أداء الاستضافة.

نقل حسابات البريد الإلكتروني أثناء الترحيل

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

على جانب DNS يحدد سجل MX خادم البريد، وSPF صلاحية الإرسال، وDKIM التوقيع، وDMARC سياسة النطاق. إذا تم تكوين هذه السجلات بشكل خاطئ فقد تذهب الرسائل إلى مجلد الرسائل المزعجة أو تُرفض كليًا. بعد الترحيل أرسل رسائل اختبار إلى حسابات Gmail وOutlook والبريد المؤسسي وتحقق من معلومات رأس الرسالة.

الأخطاء الشائعة في ترحيل الخادم

العامل المشترك في مشاريع الترحيل الناجحة هو تجنب الأخطاء البسيطة مسبقًا. إليك أكثر الأخطاء تكرارًا:

• الترحيل بدون نسخة احتياطية أو بدون اختبار النسخة.
• تغيير IP دون خفض قيمة TTL لـ DNS.
• إغلاق الخادم القديم قبل اكتمال انتشار DNS.
• نقل قاعدة البيانات بمجموعة أحرف خاطئة وتشوه الحروف العربية.
• نسيان قواعد .htaccess أو nginx.
• توجيه حركة HTTPS إلى الخادم الجديد بدون تثبيت SSL.
• تحديث سجلات MX وTXT الخاصة بالبريد بشكل خاطئ.
• ترك إضافة التخزين المؤقت تشير إلى مسارات الخادم القديم.
• عدم متابعة Search Console والسجلات بعد الترحيل.

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

متى يجب الاستعانة بدعم احترافي للترحيل؟

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

عادةً ما تشمل خدمة الترحيل الاحترافي التحليل المسبق والنسخ الاحتياطي وإعداد بيئة اختبار والنقل وتغيير DNS والتحقق والمراقبة. بهذه الطريقة لا تنتقل الملفات فقط بل تستمر العمليات التجارية أيضًا. إذا كنت تخطط للانتقال إلى بنية Hostragons يمكنك مراجعة خيارات الاستضافة والنطاقات وشهادات SSL المناسبة عبر حلول الاستضافة Hostragons.

الخلاصة: الترحيل المخطط يمنع الانقطاع وفقدان البيانات

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

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

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

كم يستغرق ترحيل الخادم؟

تختلف المدة حسب حجم الموقع ودرجة تعقيده. موقع WordPress صغير يمكن نقله في 30-60 دقيقة، بينما المشاريع التجارية الكبيرة أو المواقع ذات البريد الإلكتروني الكثير قد تستغرق التحضير والاختبار وانتشار DNS من يوم إلى ثلاثة أيام.

هل يتعطل الموقع أثناء ترحيل الخادم؟

مع التخطيط الجيد يمكن تقليل مدة الانقطاع إلى دقائق قليلة أو حتى عدم الشعور به. يتطلب ذلك خفض قيمة TTL مسبقًا واختبار الخادم الجديد قبل النشر وإبقاء الخادم القديم مفتوحًا حتى اكتمال انتشار DNS.

ما أهم خطوة لضمان عدم فقدان البيانات؟

أهم خطوة هي النسخة الاحتياطية الكاملة المُتحقق منها. يجب نسخ الملفات وقاعدة البيانات والبريد الإلكتروني وسجلات DNS. في المواقع التي تنتج طلبات أو بيانات عضوية يجب أخذ آخر نسخة من قاعدة البيانات بعد تفعيل وضع الصيانة.

هل يؤثر ترحيل الخادم على ترتيب SEO؟

طالما بقيت بنية الروابط كما هي وعمل الموقع بسرعة وتم تثبيت SSL وإعادة التوجيه بشكل صحيح، فإن ترحيل الخادم وحده لا يسبب فقدانًا في الترتيب. لكن أخطاء 404 أو robots.txt خاطئ أو بطء الخادم أو إعادة توجيه 301 غير صحيحة قد تؤثر سلبًا.

هل تُنقل حسابات البريد الإلكتروني أيضًا مع ترحيل الخادم؟

إذا كانت رسائل البريد مستضافة على الاستضافة القديمة فيجب نقلها بشكل منفصل. يجب نقل صناديق البريد وإعادة التوجيه والفلاتر وفحص سجلات MX وSPF وDKIM وDMARC. إذا بقي البريد لدى مزود آخر فلا تغيّر سجلات MX.