العودة إلى المقالات

كيف تغيّر شركة الاستضافة دون فقدان بياناتك أو ترتيبك في محركات البحث (دليل دون انقطاع)

آخر تحديث:

موقع يُنقل بأمان من خادم استضافة إلى آخر بينما يظل خط ترتيبه متصلًا دون انقطاع

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

كيف تغيّر شركة الاستضافة دون فقدان البيانات أو الترتيب؟

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

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

ماذا تحتاج أن تنسخ احتياطيًا وتتحقّق منه قبل نقل أي شيء؟

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

غالبًا ما يحوي «الموقع» أجزاءً متحرّكة أكثر مما يتوقّع الناس، والأجزاء التي تُنسى هي بالذات التي تتعطّل بعد النقل. إليك القائمة التي يجدر إتمامها قبل أن يحدث أي شيء آخر:

  • كل ملفات الموقع. المجلد العام كاملًا، لا القالب أو الصفحات التي تتذكّر أنك حرّرتها فقط.
  • قاعدة البيانات. معظم المواقع المُدارة بنظام محتوى (ووردبريس وما شابهه) تحفظ محتواها وإعداداتها ومستخدميها في قاعدة بيانات، لا في الملفات. ونسخة الملفات وحدها ستستعيد هيكلًا فارغًا.
  • حسابات البريد. صناديق البريد المستضافة لدى مزوّدك الحالي لا تنتقل مع الموقع تلقائيًا. صدّر البريد ودوّن كل عنوان، وإلا فقد تفقد رسائل حين ينتقل النطاق.
  • سجلّات DNS. التقط صورة أو صدّر منطقة DNS الحالية: سجلّات A، وسجلّات MX للبريد، وأي سجلّات TXT لـ SPF و DKIM والتحقّق من النطاق. فهي سهلة النسيان وهي ما يُبقي البريد جاريًا.
  • ملاحظات البرمجيات والإصدارات. إصدار PHP، وإصدار قاعدة البيانات، وأي إعدادات خادم يعتمد عليها الموقع. ومطابقتها على الاستضافة الجديدة يجنّبك المفاجآت.
  • سجلّ بقيمة TTL الحالية لديك. أعود إليها أدناه، لأنها تقرّر سرعة التحويل النهائي.
  • نسخة احتياطية طازجة اليوم. إن كانت استضافتك الحالية تأخذ نسخًا احتياطية يومية، فخذ الأحدث كنسخة ثانية، لكن خذ أيضًا نسخة طازجة بنفسك يوم النقل. فنسخة الأسبوع الماضي لا تتضمّن طلبات هذا الأسبوع أو تعليقاته.

ما خطوات نقل موقع إلى استضافة جديدة، بالترتيب؟

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

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

  • ١. أنشئ الحساب وبيئة مطابقة على الاستضافة الجديدة. إصدارات PHP وقاعدة البيانات نفسها أو أحدث، ونفس نوع الخادم حيث يهمّ ذلك. لا توجّه نطاقك إليها بعد.
  • ٢. انسخ الملفات واستورد قاعدة البيانات إلى الخادم الجديد. أبقِ بنية الملفات متطابقة حتى لا يُضطر شيء إلى إعادة الكتابة.
  • ٣. اجعل الموقع يجيب على عنوان مؤقّت توفّره الاستضافة الجديدة، أو بتحرير ملف hosts على حاسوبك، لتحمّل الموقع الحقيقي من الخادم الجديد بينما لا يزال الجمهور يرى القديم.
  • ٤. اختبر كل شيء على الخادم الجديد. افتح الصفحات الرئيسية، وأرسل نموذجًا، وسجّل الدخول، وتحقّق من تحميل الصور والتنزيلات، وأكّد أن الأجزاء المعتمدة على قاعدة البيانات تعمل. أصلِح المشكلات هنا، على انفراد، حيث لا يراها أي زائر.
  • ٥. اخفض قيمة TTL في DNS على النطاق إلى قيمة قصيرة (٣٠٠ ثانية شائعة) قبل التحويل بيوم على الأقل، لينتشر التغيير النهائي في دقائق بدل ساعات.
  • ٦. قلّل عمليات الكتابة قبيل التحويل مباشرة. على موقع نشط، أوقِف مؤقتًا لوقت قصير كل ما يعدّل قاعدة البيانات (طلبات جديدة، تعليقات) وأجرِ مزامنة نهائية للملفات والبيانات حتى لا يبقى شيء أُنشئ في الساعة الأخيرة عالقًا على الخادم القديم.
  • ٧. حدّث سجلّات DNS لتوجّه النطاق إلى عنوان IP للاستضافة الجديدة، ولا تحدّث سجلّات MX إلا إن كان بريدك ينتقل أيضًا.
  • ٨. راقب الخادمين بينما ينتشر DNS. ينتقل المرور تدريجيًّا من القديم إلى الجديد كلما انتهت صلاحية الذاكرات المؤقتة. ولأن الاثنين يقدّمان الموقع نفسه، يحصل الزوّار على صفحة عاملة أيًّا كان الخادم الذي يصلون إليه.

كيف تُبقي الموقع متصلًا أثناء النقل، دون أي انقطاع؟

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

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

كيف تتجنّب فقدان ترتيبك في محركات البحث عند تغيير الاستضافة؟

إن أبقيت النطاق نفسه وعناوين الصفحات نفسها، فتغيير الاستضافة وحده لا يكلّفك ترتيبًا، لأن Google يفهرس عناوين URL لديك، لا خادمك. إنما تفقد الترتيب حين يكسر النقل شيئًا: يتعطّل الموقع أثناء التحويل، أو تتغيّر العناوين، أو يتوقّف HTTPS عن العمل، أو يُنقل حظر زحف من نسخة الاختبار. احمِ هذه الأمور الأربعة وينتقل ترتيبك معك.

هنا تُجنّبك التوقّعات الصادقة قلقًا كثيرًا. فنقلة استضافة خالصة، بالنطاق نفسه وعناوين URL نفسها والمحتوى نفسه، تكاد تكون غير مرئية لمحركات البحث. لا يوجد «تغيير استضافة» عليك أن تبلّغ به Google، ولا سبب لأن يهبط الترتيب. تظهر المشكلات حين يُخلَط النقل بتغييرات أخرى أو يُنفَّذ دون عناية. راقب هذه تحديدًا:

  • لا تغيّر عناوين URL إلا مضطرًّا. أبقِ كل صفحة على العنوان نفسه. وإن كان النقل إعادة تصميم أيضًا وتغيّرت العناوين فعلًا، فضع تحويلًا دائمًا 301 من كل عنوان قديم إلى مكافئه، واحدًا لواحد، لا كل شيء مكبوبًا على الصفحة الرئيسية.
  • تجنّب الانقطاع أثناء الزحف. انقطاع قصير نادرًا ما يضرّ، أما الأخطاء المتكرّرة بينما زاحف Google يمرّ فقد تضرّ. وطريقة اللاانقطاع أعلاه هي حمايتك هنا.
  • انقل HTTPS بشكل صحيح. تأكّد من أن الاستضافة الجديدة تقدّم موقعك عبر HTTPS بشهادة صالحة قبل التحويل، وأن التحويل من http إلى https لا يزال يعمل. استضافتنا تتضمّن شهادة SSL مجانية، فتظل النسخة الآمنة تجيب دون فجوة.
  • افحص وجود زحف محظور على النسخة الجديدة. مواقع الاختبار والتهيئة تكون عادةً محظورة عن البحث بوسم noindex أو منع في robots.txt. وهذا الحظر كثيرًا ما ينجو من النسخ إلى الاستضافة الجديدة. أكّد أن الموقع الحيّ قابل للزحف قبل التحويل وبعده.
  • أبقِ المحتوى متطابقًا. الترتيب مرتبط بالصفحات التي يعرفها Google بالفعل. فإن تغيّر النص والعناوين والترويسات أثناء النقل، تكون قد غيّرت الشيء المُرتَّب نفسه، لا مكان استضافته فقط.
  • افحص الفهرسة. بعد التحويل، افتح Google Search Console واستخدم فحص عناوين URL على بضع صفحات مهمّة للتأكيد أنها لا تزال قابلة للزحف ومفهرَسة. لست بحاجة إلى أداة تغيير العنوان من أجل تغيير استضافة: تلك الأداة للانتقال إلى نطاق مختلف فقط.

كيف تتحقّق أن عملية النقل نجحت فعلًا؟

تصفّح الموقع الجديد كما يفعل زائر حقيقي ومحرّك بحث: حمّل الصفحات الرئيسية، واختبر نموذجًا وتسجيل دخول، وأرسِل بريد اختبار داخلًا وخارجًا، وافحص عنوانين أو ثلاثة في Search Console. تكتمل عملية النقل حين يجتاز الخادم الجديد كل هذا ولا يعود القديم يستقبل مرورًا.

قد يظل النقل الذي «يبدو سليمًا» على الصفحة الرئيسية معطّلًا بعد ثلاث نقرات، فافحص الأجزاء التي تفشل بصمت:

  • النماذج والدفع. أرسِل نموذجًا حقيقيًّا وأكمِل معاملة اختبار إن كنت تبيع عبر الإنترنت. فهي تعتمد على إعدادات خادم لا تنتقل دائمًا.
  • البريد في الاتجاهين. أرسِل رسالة إلى حساب على النطاق وأخرى منه. سجلّات MX المكسورة تظهر هنا ولا مكان سواه.
  • الصور والتنزيلات والروابط. حمّل صفحات فيها وسائط وانقر الروابط الداخلية لتلتقط أي شيء لا يزال يشير إلى الخادم القديم أو عنوان مؤقّت.
  • HTTPS والتحويلات. أكّد أن القفل يظهر وأن عناوين http تحوّل إلى https.
  • حالة الفهرسة. فحص عناوين URL في Search Console يخبرك أن الصفحة الحيّة قابلة للوصول وللفهرسة.
  • المرور على الخادم القديم. حين تهدأ سجلّاته، يكون DNS قد أتمّ انتشاره، ويمكنك سحبه بأمان.

ما الأخطاء التي تسبّب الانقطاع أو فقدان البيانات عند تغيير الاستضافة؟

الإخفاقات التي تكلّف الناس فعلًا موقعهم وترتيبهم متوقّعة، وكلٌّ منها ينبع من خرق قاعدة «اختبر أولًا، أبقِ الاستضافة القديمة». ومعرفتها مسبقًا هي معظم الحماية.

  • إلغاء الاستضافة القديمة مبكرًا جدًّا. أغلى الأخطاء. فما إن يزول الخادم القديم حتى تزول معه شبكة أمانك وخطة تراجعك، وأي DNS لا يزال يشير إلى هناك يصطدم بلا شيء.
  • نسيان قاعدة البيانات. نسخ الملفات دون قاعدة البيانات يترك موقع محتوى فارغًا. فالمحتوى يحيا في قاعدة البيانات، لا في الملفات.
  • عدم خفض TTL أولًا. تجاوز هذا فيتمدّد التحويل الذي ينبغي أن يأخذ دقائق إلى ساعات، والزوّار موزّعون بين الخادمين طوال الوقت.
  • فقدان البريد في النقل. صناديق البريد وسجلّات MX يسهل إغفالها لأنها تبدو منفصلة عن الموقع. صدّر البريد وانسخ السجلّات قبل أن تلمس DNS.
  • ترك حظر التهيئة قائمًا. وسم noindex أو منع في robots.txt نُسخ من موقع الاختبار قد يزيل صفحاتك الحيّة بهدوء من Google بعد أيام.
  • تغيير عناوين URL دون تحويلات. إن تغيّرت العناوين ولم يحوّل شيء القديمة، تبقى معك خسارة المرور وتسلّم Google حزمة روابط ميتة.

هل ينبغي أن تنقل الموقع بنفسك أم تكلّف من يفعلها؟

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

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

إن كان موقعك يجني مالًا أو استغرق سنوات ليتصدّر، فعملية النقل ليست وقت المجازفة. أخبرنا بنطاقك وإلى أين تريد الانتقال، ونتولّى نحن التحويل دون انقطاع ودون فقدان بيانات، مع إبقاء استضافتك القديمة كخطة تراجع حتى يُتحقَّق من الجديدة. تحدّث مع Web Roots عن نقل موقعك.

FAQ

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

هل سأفقد ترتيبي في Google إن غيّرت شركة الاستضافة؟

ليس بسبب تغيير الاستضافة نفسه، ما دمت تُبقي النطاق نفسه وعناوين URL نفسها والمحتوى نفسه. فـ Google يفهرس عناوين موقعك، لا خادمك، لذا فإن نقل الملفات إلى استضافة جديدة غير مرئي له. لا يهبط الترتيب إلا حين تسبّب عملية النقل انقطاعًا، أو تغيّر عناوينك دون تحويلات، أو تكسر HTTPS، أو تنقل حظر زحف من نسخة الاختبار.

كيف أنقل موقعي إلى استضافة جديدة دون انقطاع؟

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

هل يلزم أن أُبلغ Google أنني غيّرت الاستضافة؟

لا. تغيير الاستضافة مع إبقاء النطاق نفسه لا يتطلّب أداة تغيير العنوان في Search Console، فهي للانتقال إلى نطاق مختلف فقط. وبعد التحويل يجدر استخدام فحص عناوين URL على بضع صفحات مهمّة للتأكيد أنها لا تزال قابلة للزحف ومفهرَسة، لكن لا يوجد تغيير استضافة تُبلغ عنه.

ما أكثر الأخطاء شيوعًا عند تغيير الاستضافة؟

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

كم تستغرق عملية نقل موقع؟

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