حين تطلب شركة كويتية موقعا جديدا، يأتي المزود الجديد عادة باستضافته الخاصة، فيصل التصميم الجديد والانتقال إلى خادم جديد مشروعا واحدا بموعد إطلاق واحد. هكذا تكتب معظم العروض، وهكذا تقدمها معظم المقترحات. وهي أيضا أضمن طريقة أعرفها لخسارة زيارات البحث دون أن تعرفوا السبب أبدا.
نصيحتي أن يبقى الاثنان في عقد واحد، وأن ينقسما إلى إطلاقين. هذا هو المنطق، وهذا هو الترتيب الذي أعمل به.
لماذا يأتي الاثنان معا
الجمع بينهما نادرا ما يكون قرارا. الاستضافة القديمة تتجدد في الشهر الذي يسلم فيه الموقع الجديد، أو الوكالة الجديدة لا تدعم إلا المواقع على خوادمها، أو المزود القديم يستبدل ولا أحد يريد التعامل معه مرتين. كلها أسباب معقولة، ولا واحد منها سبب لتغيير كل شيء في الليلة نفسها.
ويبدو الجمع كفاءة على الورق: إطلاق واحد، وعطلة واحدة من المخاطرة، وإعلان واحد. المشكلة أن المخاطر لا تجمع بل تتضاعف، لأن أي خلل بعد ذلك لا يمكن معرفة أي التغييرين سببه.
غيروا شيئا واحدا في كل مرة
هذا ليس تفضيلي وحدي. إرشادات جوجل نفسها حول نقل الموقع تقول أن تخطط التغييرات واحدا بعد الآخر لا في الوقت نفسه، وتضرب هذا المثال تحديدا: إن كنتم تغيرون النطاق والنظام والتصميم فافعلوها واحدا تلو الآخر.
والمنطق تشخيصي. التصميم الجديد يغير الروابط، ومحتوى الصفحات، والروابط الداخلية، والقوالب. ونقل الاستضافة يغير الخادم، وسرعته، وإعداداته، وكل سجل في نظام أسماء النطاقات. فإن انخفضت الزيارات بمقدار الثلث بعد ثلاثة أسابيع من فعل الاثنين معا، فقائمة المشتبه بهم هي كل ما سبق. وإن فعلتموهما بفارق أسبوعين، فأنتم تعرفون الجواب مسبقا.
انقلوا الاستضافة أولا، بالموقع القديم
الترتيب الذي أتبعه: انقلوا الموقع الحالي كما هو، دون أي تغيير، إلى الاستضافة الجديدة. راقبوه أسبوعا أو اثنين. ثم أطلقوا التصميم الجديد على استضافة أثبتت نفسها.
نقل الاستضافة دون تغيير ظاهر هو الأبسط بين الاثنين، وجوجل تعامله على هذا الأساس. دليلها حول تغيير الاستضافة أربع خطوات: جهزوا البنية الجديدة، وحولوا سجلات النطاق، وراقبوا الاثنين، وأغلقوا القديمة حين لا يستخدمها أحد. وحين ينفذ وحده يكون قابلا للقياس، فالصفحات متطابقة، وأي تغير في السرعة أو الأخطاء أو الزيارات سببه الخادم.
ثم ينزل التصميم الجديد على خادم تعرفون سلوكه، وأي تغير بعد ذلك الإطلاق يعود إلى التصميم أو المحتوى أو الروابط. حدثان صغيران واضحان بدل حدث كبير محير.
كل ما يفعله النطاق غير الموقع
قبل أن تنتقل الاستضافة، اكتبوا قائمة بكل سجل في إعدادات النطاق ووظيفته. الموقع عادة سجل أو اثنان، والباقي بريد، وسجلات تحقق تستخدمها جوجل ومايكروسوفت، ونطاقات فرعية لا يتذكر أحد إنشاءها، وما يشير إليه مزود دفع أو نظام حجوزات.
البريد هو ما يوقف الشركة. حين تتولى الاستضافة الجديدة إعدادات النطاق ولا تنقل سجلات البريد كما هي تماما، يبدأ البريد بالضياع، وغالبا بصمت. وتعليمات جوجل لسجلات البريد نفسها تحذر من أن البريد قد لا يعمل بشكل صحيح إن بقيت سجلات قديمة أو خاطئة. انسخوها، ثم أرسلوا رسالة تجريبية من خارج الشركة قبل اعتبار النقل منتهيا. وتسليم الموقع السليم من المزود كان يجب أن يعطيكم هذه القائمة، فإن لم يفعل فهنا تظهر الثغرة.
وافحصوا كل ما يعود إلى الموقع كذلك: بوابة دفع تعيد العميل إلى صفحة النجاح، وإعداد كي نت الذي وافق عليه البنك، ونموذج يرسل إلى نظام العملاء. كل منها مضبوط في مكان ما على عنوان أو خادم، وكل منها يحتاج اختبارا على الاستضافة الجديدة قبل أن يكتشف العملاء المشكلة.
والنطاقات الفرعية تستحق سطرا خاصا في القائمة. متجر على نطاق فرعي، أو بوابة للموظفين، أو صفحة حجز يديرها مزود آخر، كلها تعيش على سجلات في النطاق نفسه، ولا يلاحظ غيابها أحد حتى يتصل عميل ليقول إن الرابط لا يفتح.
خفضوا مدة التخزين المؤقت قبل أيام
كل سجل في إعدادات النطاق يحمل مدة صلاحية تخبر الخوادم الوسيطة كم تحتفظ به. فإن كانت يوما كاملا، فبعض زواركم سيظلون يصلون إلى الخادم القديم حتى يوم بعد التحويل. ودليل جوجل للاستضافة يوصي بخفض هذه المدة قبل النقل، وشرح Cloudflare لمدة الصلاحية يوضح المقايضة ببساطة: المدة الأطول تسرع البحث، لكنها تبطئ التغيير.
اخفضوها إلى دقائق قبل النقل بيومين أو ثلاثة، حتى تنتهي القيمة القديمة الطويلة في كل مكان. وأبقوا الاستضافة القديمة تعمل حتى تتوقف الزيارات إليها فعلا، فإلغاؤها في اليوم نفسه هو ما يجعل الموقع يعمل لنصف العملاء فقط.
خريطة التحويلات هي المخرج الحقيقي للتصميم الجديد
حين يطلق التصميم الجديد، كل رابط قديم لا يحتفظ به الموقع الجديد يحتاج تحويلا دائما إلى الصفحة التي تحل محله. ودليل جوجل يسميها خريطة الروابط ويضعها قبل بدء النقل لا بعده. وهو المبدأ نفسه في عدم تغيير رابط يكسب شيئا، مطبقا على الموقع كله دفعة واحدة.
واجعلوها مملة. التحويل يذهب إلى الصفحة الواحدة التي تجيب عن السؤال نفسه، لا إلى الصفحة الرئيسية. تحويل كل رابط متقاعد إلى الرئيسية يبدو مرتبا، ودليل جوجل يقول إنه قد يعامل كخطأ 404 مخفف، أي صفحة مفقودة باسم آخر، فيضيع التاريخ المرتبط بتلك الروابط.
ابنوا الخريطة من قائمة الصفحات الحقيقية للموقع القديم: خريطة الموقع، وتقرير الصفحات في Search Console، والتحليلات، لا من قائمة الموقع الجديد. الصفحات التي تجلب الزيارات كثيرا ما تكون صفحات لم يكن أحد ليضعها في القائمة. اطلبوا الخريطة ملفا مكتوبا قبل الإطلاق، واختبروها بعده: افتحوا كل رابط قديم وتأكدوا أنه يصل إلى مكان منطقي بخطوة واحدة.
اختاروا موعد الإطلاق بحسب زياراتكم لا بحسب جدول المزود
إرشادات جوجل أن يتزامن النقل مع فترة زيارات أقل قدر الإمكان. ولمعظم الشركات الكويتية يستبعد هذا تواريخ كثيرة: الأسابيع التي تسبق رمضان والعيد للتجزئة، ونهاية الشهر لكل ما يستقبل مدفوعات، وبداية العام الدراسي لكل ما تشتريه العائلات. افتحوا التحليلات، وجدوا أهدأ فترة متكررة، وضعوا الإطلاقين داخلها.
ثم اختاروا اليوم. الإطلاق عصر الخميس يعني أن المشكلات تظهر الجمعة والسبت، حين لا يكون فريقكم ولا المزود على مكتبه. وصباح الأحد أو الاثنين يعطيكم أسبوع عمل كاملا من المراقبة.
وأعطوا نقل الاستضافة والتصميم الجديد تاريخين منفصلين في خطة المشروع من البداية. حين يكونان سطرين في الجدول لا يغري أحدا دمجهما لتوفير أسبوع في النهاية، وحين يكونان سطرا واحدا يصبح فصلهما لاحقا تأخيرا يجب تبريره.
الموقع التجريبي لا يجب أن يلحقكم إلى الإطلاق
الموقع الجديد يبنى على نسخة تجريبية، والنسخة التجريبية يجب أن تخفى عن محركات البحث بقاعدة منع الفهرسة. هذا صحيح. الخطأ هو الإطلاق وهي ما زالت مفعلة. وتوثيق جوجل حول منع الفهرسة صريح في أثرها: حين تجدها جوجل تسقط الصفحة من النتائج كليا، وعلى موقع كامل يعني ذلك كل صفحة.
في ووردبريس هي خانة واحدة، «منع محركات البحث من أرشفة هذا الموقع»، وهي أكثر أخطاء إعادة الإطلاق التي أراها شيوعا. افحصوا مصدر الصفحة الرئيسية الحية يوم الإطلاق، ثم صباح اليوم التالي، لأن ذاكرة مؤقتة أو سكربت نشر قد يعيدها.
وتأكدوا كذلك من ملف robots.txt على الموقع الجديد. بعض قوالب النسخ التجريبية تمنع الزحف كله من هذا الملف، وإن بقي المنع هناك فلن ترى جوجل حتى قاعدة الفهرسة الصحيحة على الصفحات، لأنها لا تصل إليها أصلا.
الأسبوعان الأولان بعد الإطلاق
تقول جوجل إن موقعا متوسط الحجم قد يحتاج أسابيع أو أكثر قبل أن تحل الروابط الجديدة محل القديمة، فالتذبذب في الأيام الأولى طبيعي. غير الطبيعي هو ازدياد أخطاء 404، أو خروج صفحات من الفهرس، أو نماذج توقفت عن الوصول. راجعوا تقرير الصفحات في Search Console كل يومين، وأرسلوا خريطة الموقع الجديدة يوم الإطلاق، واجعلوا أحدا يرسل استفسارا حقيقيا عبر كل نموذج.
واكتبوا قبل الإطلاق من المسؤول عن هذين الأسبوعين. إن انتهى العقد عند «تسليم الموقع» فلا أحد مسؤول. وهذا الجزء هو أكثر ما يغيب عن عرض سعر الموقع، ويستحق سطرا في النطاق بدل أن يطلب معروفا بعد ذلك. وإن كنتم تفكرون في إعادة البناء أصلا، فمقالي عن لماذا تعيد الشركات الكويتية بناء موقعها كل ثلاث سنوات يسبق هذا المقال بخطوة.
وإن أردتم مزودا واحدا يخطط إعادة البناء ونقل الاستضافة والأسبوعين بعدهما وينفذها، فخدمة تصميم وتطوير المواقع لدى توثيق تتولاها مشروعا واحدا بإطلاقين منفصلين.
أسئلة شائعة
هل تنفيذ التصميم ونقل الاستضافة معا أرخص؟
أرخص قليلا في وقت المزود، لأن هناك نافذة إطلاق واحدة بدل اثنتين. لكنه أغلى كثيرا إن تعطل شيء، لأن أحدا لا يستطيع معرفة أي التغييرين السبب. الإطلاق الثاني يكلف ساعات، وانخفاض الزيارات غير المفسر قد يكلف شهورا.
كم ننتظر بين نقل الاستضافة وإطلاق التصميم؟
أسبوع أو أسبوعان يكفيان عادة لرؤية أن الاستضافة الجديدة مستقرة: الأخطاء والسرعة والزيارات عادت إلى نمطها المعتاد. والأطول لا بأس به. المهم أن يطلق التصميم على خادم تثقون به.
هل يتوقف بريدنا حين نغير الاستضافة؟
فقط إن لم تنقل سجلات البريد. اكتبوا كل سجل في إعدادات النطاق قبل النقل، وانسخوها كما هي، وأرسلوا رسالة تجريبية من عنوان خارجي بعده. وإن كان البريد لدى جوجل أو مايكروسوفت لا لدى مزود الاستضافة فلا يجب أن يتغير شيء.
هل نخسر ترتيبنا في جوجل مع التصميم الجديد؟
لا، إن بقيت الروابط التي تجلب الزيارات أو حولت تحويلا دائما إلى الصفحات التي تحل محلها، ولم يمنع الموقع الجديد من الفهرسة. توقعوا حركة لأسابيع، أما الخسارة الدائمة فتعني غالبا تحويلا ناقصا أو منع فهرسة نسي مفعلا.
هل نبقي الاستضافة القديمة بعد النقل؟
نعم، حتى تتوقف الزيارات إليها، وهذا يحدث عادة بعد أيام من تحويل سجلات النطاق. إلغاؤها يوم الإطلاق يعني أن من ما زال يصل إليها عبر سجل قديم مخزن لن يجد شيئا.