كل أسبوع يظهر شخص يرغب في نقل موقع حقيقي — موقع له زيارات، وروابط خلفية، وسنوات من ثقة جوجل خلفه — إلى أداة بناء بالذكاء الاصطناعي. ليس فكرة جديدة، وليس نموذجًا أوليًا. بل عمل تجاري قائم لديه ما يخسره. هذه مهمة مختلفة عن البدء من موجّه فارغ، ومعظم الألم الذي رأيته ينشأ من التعامل معها وكأنها المهمة نفسها رغم ذلك.
هناك ثلاث طرق يفشل بها هذا الأمر بشكل متكرر لدرجة أنني أستطيع التنبؤ بتذكرة الدعم قبل أن أقرأ ما بعد سطر الموضوع. الطريقة الصحيحة ليست معقدة. إنها ببساطة ما تصل إليه بمجرد التوقف عن هذه الأخطاء الثلاثة.
الخطأ الأول: تفريغ المحتوى القديم والأمل بأن يُرتّب نفسه بنفسه
الغريزة منطقية. لديك موقع، وفيه كلمات، فتلصق الكلمات في المحادثة وتطلب من أداة البناء أن "تحسّن هذا". ما ينتج غالبًا موقع يبدو جديدًا لكنه يُقرأ قديمًا — نفس فقرات الخدمة الطويلة المترابطة، نفس العناوين الثلاثة التي تؤدي عمل خمسة عشر عنوانًا، ملفوفة الآن بقالب أجمل. الأداة فعلت ما طلبته منها. طلبت منها إعادة الديكور، لا إعادة التفكير.
يظهر الحطام بعد نحو ستة أسابيع، حين يستقر ترتيب الموقع الجديد في نفس مكان الموقع القديم بالضبط، أو أدنى قليلًا. لم يتحسّن شيء لأن لا شيء تغيّر فعليًا في بنية المعلومات الفعلية — نفس الصفحة المسطّحة لخدمة كان يجب أن تكون ثلاث صفحات، ونفس محتوى الأسئلة الشائعة المفقود الذي يحقق به موقع منافس ترتيبًا جيدًا منذ عام. طبقة طلاء جديدة على بيت بعدد غرف خاطئ يظل بيتًا بعدد غرف خاطئ.
كان لديّ عميلة لديها صفحة "خدمات" من 4,000 كلمة تغطي إحدى عشرة خدمة مختلفة. أرادت نقلها كما هي لأنها "نجحت دائمًا". لم تنجح — لم تحقق ترتيبًا لأي شيء محدد لأنها كانت تتحدث عن كل شيء دفعة واحدة. نقلها بأمانة كان سيُنتج فقط نسخة أجمل من نفس الصفحة غير المُصنَّفة.
ما ينجح فعليًا هنا هو التعامل مع النقل كتدقيق قبل أن يكون بناءً. أدخل المحتوى القديم، لكن اطلب أولًا قائمة جرد للمحتوى: ما الصفحات الموجودة، وما الذي تحاول كل واحدة منها فعليًا الترتيب من أجله، وأين تُحشر موضوعان في رابط واحد، وأين يكون موضوع واحد ضحلًا موزّعًا عبر خمسة روابط. تصبح هذه القائمة هي الخطة. الموقع القديم مصدر، لا قالب.
الخطأ الثاني: نسيان أن الروابط هي الشيء الذي تثق به جوجل فعليًا
هذا هو الخطأ المكلف. نقل موقع يغيّر بنية الروابط دون تخطيط المسارات القديمة إلى الجديدة — حتى عندما يكون المحتوى الجديد أفضل فعلًا — يهدر سنوات من الإشارات المتراكمة. الروابط الخلفية تشير إلى صفحة خطأ 404. يتعيّن على جوجل إعادة زحف وإعادة اكتساب الثقة في صفحات كانت تثق بها بالفعل تحت عنوان مختلف. حركة المرور المباشرة من الإشارات المرجعية القديمة والتوقيعات البريدية تصل إلى طريق مسدود.
لاحظت أشخاصًا ينتبهون لهذا فقط بعد الإطلاق، عندما تُظهر لوحة التحليلات هبوطًا حادًا بدلًا من ارتفاع. عندها يكون الحل هو إضافة إعادة التوجيهات بأثر رجعي، وهو ما يستعيد جزءًا من الخسارة لا كلها — الفجوة بين "انتقل الرابط" و"لاحظ أحدهم ذلك وأصلحه" تُقاس بأسابيع من القيمة المفقودة التي لا تستعيدها أبدًا.
| الأسلوب القديم | ما الذي يتعطل | ما يجب فعله بدلًا من ذلك |
|---|---|---|
| ترك أداة البناء تُنشئ أي هيكل روابط يتناسب مع التصميم الجديد | كل رابط خلفي وارد وإشارة مرجعية يشير الآن إلى صفحة 404 | تصدير خريطة الموقع القديمة أولًا، ومطابقة كل رابط قائم بمكافئه الجديد قبل بدء البناء |
| إعادة توجيه الصفحة الرئيسية فقط، وترك الصفحات الداخلية تُعرض كخطأ 404 | الصفحات العميقة تحمل قيمة روابط خاصة بها — فقدانها واحدة تلو الأخرى يتراكم | إعادة توجيه 301 لكل رابط قديم ذي أهمية، حتى تلك التي تم دمجها ضمن صفحة أوسع |
| إضافة إعادة التوجيهات "لاحقًا، بعد الإطلاق" | تصطدم برامج الزحف والمستخدمون بصفحات مُغلقة تمامًا خلال الفترة الأكثر تقلبًا للزيارات | إعادة التوجيهات تُفعَّل في اللحظة ذاتها التي يُطلق فيها الموقع الجديد، لا بعدها |
لا شيء من هذا معقد. إنه جدول بيانات من عمودين، يُعد قبل أن يلمس أحد أداة البناء. إنها فقط الخطوة التي يتخطاها الناس لأنها مملة، بينما البناء نفسه هو الجزء الممتع.
الخطأ الثالث: الانتقال الكبير دفعة واحدة دون طريقة للرجوع
نمط الفشل الثالث لا علاقة له بالمحتوى أو الروابط على الإطلاق — بل بكيفية حدوث التبديل فعليًا. يبني شخص ما الموقع الجديد، يعجبه ما يراه في المعاينة، ويوجّه النطاق إليه في نفس بعد الظهيرة. لا فترة اختبار، لا مقارنة جنبًا إلى جنب تحت زيارات حقيقية، ولا خطة لما يحدث إن كان هناك عطل لم تكشفه المعاينة — نموذج تواصل يفشل بصمت، أو مسار دفع يعمل في الاختبار لكنه يتعثر تحت حجم مدفوعات حقيقي، أو صفحة تظهر بشكل جيد على سطح المكتب وتنهار على نفس الهاتف الذي يستخدمه نصف عملائك.
الأضرار هنا هي الأعلى صوتًا لأنها فورية. صناديق الدعم تمتلئ. شخص ما يحدّث لوحة التحليلات كل عشر دقائق ويرى المنحنى يتجه في الاتجاه الخاطئ، والتراجع يعني إعادة توجيه DNS مجددًا، وهو ما يستغرق وقتًا للانتشار، ما يعني استمرار التجربة السيئة حتى بعد اتخاذ قرار العكس.
الحل غير لافت: خفض مدة صلاحية DNS (TTL) بيوم أو يومين قبل التبديل حتى ينتشر أي تراجع بسرعة إن احتجت إليه، وتشغيل الموقع الجديد على نطاق فرعي للمعاينة أو الاختبار أولًا واستخدامه فعليًا كما سيفعل العميل، والإبقاء على استضافة الموقع القديم قائمة وبدون تغيير لأسبوعين على الأقل بعد التبديل بدلًا من إلغائها فور تشغيل الجديد. هذه الخطوة الأخيرة تكلف بضعة دولارات من الاستضافة كتأمين حقيقي. يتجاهلها الناس لأن إلغاء الخطة القديمة يشعرهم بإغلاق الحلقة، وإغلاق الحلقات يبدو تقدمًا.
كيف يبدو الأسلوب الصحيح فعليًا
في المحصلة، لا شيء من هذا عمل أكثر من الطرق الخاطئة — إنه نفس القدر من العمل بترتيب مختلف. راجع قبل أن تعيد البناء. اربط الروابط قبل الإطلاق. اختبر قبل التبديل، واحتفظ بطريقة للرجوع لبضعة أسابيع بعده. الموقع الذي ينتج في النهاية لا يبدو أحدث فحسب. بل يحتفظ بكل ما اكتسبه الموقع القديم فعلًا، وهو بالضبط الهدف من الترحيل بدلًا من البدء من الصفر.
