كل كام شهر صاحب شركة بيسأل نفس السؤال بصيغة مختلفة: نغير شكل الموقع بس، ولا نهده ونبنيه من الأول؟ السؤال ده مهم لأن الاختيارين بينهم فرق كبير في التكلفة والمخاطرة والوقت، والغلط في الاختيار بيكلف في الاتجاهين. لو عملت ريديزاين على أساس مهزوز، هتطلع بموقع شكله أحلى لكن بنفس الصفحات البطيئة ونفس الثغرات ونفس العجز عن إضافة اللي شغلك محتاجه بعد كده. ولو بنيت الموقع من الصفر وهو كل مشكلته إن شكله قديم، تبقى رميت هيكل شغال وترتيب في جوجل وفلوس.
المقال ده بيساعدك تقرر بناء على دليل مش على الذوق. هنفرق بين المصطلحين بوضوح، وهنشرح خمس علامات بتقول إن موقعك محتاج إعادة بناء، وإزاي تختبر كل علامة في يوم واحد، وإزاي تبني من جديد من غير ما تخسر ظهورك في جوجل.
إعادة التصميم وإعادة البناء شغلتين مختلفتين
إعادة التصميم معناها تغيير شكل الموقع وطريقة تنقل الزائر فيه: التخطيط، الخطوط، الألوان، الصور، قوالب الصفحات، القوائم، النصوص. المحرك اللي تحت بيفضل زي ما هو. الصفحات بتحتفظ بروابطها، ونظام إدارة المحتوى هو هو، وقاعدة البيانات والاستضافة زي ما هما. لو اتعملت صح، بتبقى شغلانة محدودة نسبيا، أغلبها تصميم وتنفيذ قوالب ومراجعة محتوى.
إعادة البناء معناها تغيير المحرك نفسه. ممكن تنقل من منصة لمنصة، أو من قالب وإضافات لكود مخصص، أو تعيد تصميم هيكل البيانات، أو تغير طريقة تقديم الموقع للزائر. التصميم الظاهر ممكن يتغير كمان، لكن العلامة الأساسية إن الأساس هو اللي اتغير. إعادة البناء مشروع برمجي مش مشروع تصميم، ولازم يتحدد نطاقه ويتختبر ويتطلق على الأساس ده.
وفي حاجة تالتة بتتنسي كتير، هي التنضيف الداخلي (refactor)، يعني تفضل على نفس المنصة لكن تنضف طريقة التنفيذ. مسح عشرين إضافة، وتبديل قالب تقيل مبني على بيلدر بقالب خفيف، وإصلاح قاعدة البيانات، وترقية نسخة PHP، كلها تنضيف داخلي. كتير منها بيجيب أغلب فايدة إعادة البناء بجزء صغير من المخاطرة، ولازم تدخل في حساباتك قبل ما حد يكتب لك عرض إعادة بناء.
العلامات الخمسة تحت مترتبة من الأشهر للأحسم. ولا واحدة فيهم عن إن الصفحة الرئيسية شكلها قديم. الشكل القديم سبب للريديزاين. إعادة البناء لازم يكون سببها مشكلة تحت السطح وملهاش حل على السطح.
العلامة الأولى: المنصة وصلت لسقفها
كل منصة ليها طبيعة: حاجات بتعملها بسهولة، وحاجات بتعملها بمجهود، وحاجات بتعملها وحش. موقع ووردبريس للتعريف بالشركة مع مدونة ونموذج تواصل ده مكانه الطبيعي. نفس المنصة لما تشغل نظام حجز متعدد الفروع وقوائم أسعار لكل عميل ودورة موافقات، يبقى بتتشد في التلات اتجاهات مرة واحدة.
علامات السقف عملية جدا. كل ميزة جديدة محتاجة إضافة جديدة، والإضافات بتتخانق مع بعض. المبرمج بيقولك إن التعديل المطلوب خطر لأنه بيلمس حاجة هشة. الإجابة الصريحة على طلبات كتير بقت: “ممكن، بس هيبوظ حاجة تانية”. التعديلات الصغيرة بتاخد أسابيع لأن كل تعديل لازم يتراجع كله من الأول. والحلول الترقيعية اتراكمت: حقول مخصصة بتحاكي قاعدة بيانات، وشورت كود جوه شورت كود، ونماذج بتمثل إنها نظام سير عمل.
اختبرها كده: اكتب أهم خمس قدرات الشركة عايزاها في الاتنا عشر شهر الجايين، زي عربون أونلاين، أو بوابة عملاء، أو ربط مع الـ ERP، أو إدارة المواعيد بواسطة الموظفين، أو منطقة للأعضاء. اسأل المبرمج اللي عارف الموقع أكتر واحد: كل قدرة منهم تتضاف بشكل نضيف على الأساس الحالي، ولا بحل ترقيعي، ولا مش هتتضاف غير بتغيير جزء من الأساس؟ لو تلاتة أو أكتر وقعوا في الاختيار التالت، يبقى المنصة وصلت لسقفها. مقالنا عن ووردبريس ولا لارافيل بيشرح الفرق بين مشاريع المحتوى ومشاريع العمليات، وليه كتير من شركات الـ B2B بتنتهي بواجهة ووردبريس ومحرك مبني خصيصا وراها.
السقف مش حكم ضد المنصة. ووردبريس لسه أساس ممتاز لمواقع المحتوى، وإعادة بناء نضيفة على ووردبريس كتير بتكون هي الحل الصح. المقصود إن إعادة البناء ممكن تفضل على نفس المنصة وتغير المعمارية: قالب خفيف، وإضافات قليلة ومختارة بعناية، وأنواع محتوى وحقول متصممة على بيانات الشغل الحقيقية، وكود مخصص بس في الأماكن اللي منطق الشغل محتاجه فعلا.
العلامة التانية: السرعة مش بتتصلح من المصدر
المواقع البطيئة كتير، وأغلبها بيتصلح من غير إعادة بناء. ضغط الصور، وتفعيل كاش للصفحات والكائنات، وتأجيل السكربتات، والانتقال لسيرفر أحسن، ومسح الإضافات اللي مش مستخدمة، كل ده ممكن يحول موقع فاشل لموقع مقبول. عشان كده السرعة لوحدها سبب ضعيف لإعادة البناء. بتبقى سبب قوي لما تكون خلصت الحلول الأرخص والأرقام لسه مش بتتحرك.
جوجل بتنشر حدود واضحة لمؤشرات Core Web Vitals: أكبر عنصر ظاهر في الصفحة (LCP) خلال 2.5 ثانية، والاستجابة للتفاعل (INP) خلال 200 ملي ثانية، وثبات التخطيط (CLS) أقل من 0.1. تقدر ترجع لإرشادات Google Search Central الرسمية لمعرفة طريقة قياس المؤشرات دي والأدوات الموصى باستخدامها. شغّل أهم قوالب موقعك على PageSpeed Insights وتقرير Core Web Vitals في Search Console، وبعدها شوف نوع المشكلة اللي عندك.
العلامة التالتة: ديون الصيانة والأمان بقت أكبر من اللي ينفع تتحمله
أي موقع بيتراكم عليه اعتماديات: نواة نظام إدارة المحتوى، والقالب، والإضافات، والمكتبات، ونسخة PHP، ومحرك قاعدة البيانات. كل واحدة محتاجة تحديثات، وكل تحديث ممكن يبوظ التانية. الموقع السليم بيتحدث بشكل روتيني والروتين ده ممل. الموقع المريض هو اللي محدش بيجرؤ يحدثه.
العلامات التحذيرية واضحة. الموقع شغال على نسخة PHP مبقاش بيطلع لها تحديثات أمان لأن إضافة بتقع على النسخ الأحدث. القالب اتعدل مباشرة بدل ما يتعمل قالب فرعي، فأي تحديث هيمسح التعديلات. إضافة المطور سابها ومبقاش بيحدثها، ولسه بتتعامل مع الدفع أو النماذج. الموقع اتهكر قبل كده واتنضف بدل ما يتبني من جديد، فمحدش يقدر يقول بثقة إن كل الأبواب الخلفية اتقفلت. ومحدش يعرف مين المسؤول عن التحديثات، أو آخر مرة نسخة احتياطية اتسترجعت فيها بنجاح.
اسأل اللي بيصون الموقع الأسئلة دي:
- أنهي إضافات مطوريها مأحدثوهاش في آخر اتنا عشر شهر، وكل واحدة بتعمل إيه؟
- إيه أقدم مكون في المنظومة، وإيه اللي مانع ترقيته؟
- لو حدثنا كل حاجة النهارده على نسخة تجريبية، كام حاجة هتبوظ؟
- آخر مرة استرجعنا نسخة احتياطية في بيئة نضيفة وتأكدنا إنها شغالة كانت امتى؟
ديون الصيانة بتتعالج لحد معين. تنضيف مخطط بيستبدل الإضافات المهجورة وينقل التعديلات لكود سليم ويرقي بيئة التشغيل ممكن يرجع الموقع لحالة قابلة للصيانة. لكن لو التمرين ده كشف إن الموقع مينفعش يتحدث من غير ما تتكتب أغلب وظايفه من الأول، يبقى التنضيف بقى إعادة بناء بس باسم تاني، وأرخص تعترف بكده وتخطط له صح. اقرا كمان تكلفة صيانة المواقع في مصر عشان تعرف الصيانة السليمة بتشمل إيه، وتقارن بيها وضعك الحالي.
الأمان محتاج صراحة خاصة لأن الخسارة فيه غير متوازنة. موقع بيجمع بيانات عملاء أو بياخد مدفوعات أو بيحتفظ بسجلات حجز عليه التزامات بموجب قانون حماية البيانات الشخصية في مصر، واختراق على منظومة مينفعش تتحدث مشكلة تجارية قبل ما تكون تقنية. لو المنصة مستحيل ترجع لحالة مدعومة، ده لوحده ممكن يبرر إعادة البناء، مهما كان شكل الموقع.
العلامة الرابعة: هيكل البيانات مبقاش بيناسب الشغل
دي أهدى علامة وغالبا أغلاهم. الموقع من تحت مجموعة حاجات منظمة: منتجات، غرف، رحلات، فروع، دكاترة، مشاريع، أسعار، لغات، عملاء. لو الموقع بيخزن الحاجات دي كصفحات نص وصور سايبة، كل تعديل بقى شغل يدوي، وكل قناة جديدة (أبلكيشن، أو خلاصة لشريك، أو فلتر بحث، أو لغة تانية) لازم تدخل نفس المعلومات من الأول.
دور على الأنماط دي:
- نفس المعلومة بتتحدث باليد في أكتر من مكان: الموقع، وشيت إكسل، وأداة الحجز، وصفحة السوشيال ميديا. التحديثات مش متسقة لأنها معتمدة على إن حد يفتكر.
- صفحات المفروض تتولد من بيانات منظمة اتبنت واحدة واحدة، فتغيير سعر معناه تعديل أربعين صفحة.
- المحتوى متعدد اللغات متخزن في شجرتين صفحات متكررتين من غير ربط موثوق بين الصفحة وترجمتها. تعديل في لغة بيسيب اللغة التانية متأخرة من غير ما حد يحس. دليلنا عن سيو المواقع السياحية متعددة اللغات بيشرح شكل الروابط وhreflang اللي البناء ثنائي اللغة الصح محتاجه، وليه إضافتهم بعد كده مؤلمة.
- البحث والفلترة ضعيفين أو مش موجودين، لأن البيانات ورا الصفحات مينفعش تتسأل عنها: نثر مش حقول.
- التقارير مستحيلة. مش قادر تجاوب على أسئلة بسيطة زي أنهي رحلات بتتباع أكتر، أو أنهي فرع بيجيله استفسارات أكتر، أو أنهي لغة بتحول أحسن، لأن الموقع مبيسجلش حاجة من ده بشكل ينفع.
العلاج هو هيكل بيانات متصمم للشغل: أنواع محتوى محددة بحقول واضحة، وعلاقات بينها (الرحلة ليها مواعيد انطلاق، والفرع ليه مواعيد عمل وموظفين)، ومصدر واحد للحقيقة للأسعار والتوافر، وقوالب بتتولد من البيانات دي. إضافة ده على موقع قديم معناه غالبا إعادة بناء طبقة المحتوى، ونقل المحتوى لشكل منظم، وإعادة كتابة القوالب. في اللحظة دي إنت بتعمل أغلب إعادة بناء أصلا، فالأحسن تعملها بقصد.
الاختبار هنا اختبار التغيير الواحد. اختار تغيير الشركة بتعمله كتير، زي تغيير سعر، أو إضافة لغة، أو فتح فرع جديد، أو نشر عرض موسمي. احسب كام مكان لازم يتعدل وكام شخص لازم يشترك. لو الإجابة أكتر من مكان أو أكتر من شخص لتغيير روتيني، يبقى هيكل البيانات بيكلفك فلوس كل أسبوع.
العلامة الخامسة: الربط والتحويل متعطلين
موقع الشركة النهارده نادرا ما بيكون كتالوج منعزل. بيبعت الاستفسارات لنظام CRM، وبيبعت الحجوزات لنظام التشغيل، وبياخد الدفع من بوابة محلية، وبيبلغ أداة التحليلات بالتحويلات، وبيشارك بياناته مع أبلكيشن أو شريك. الموقع اللي مش قادر يعمل ده كويس بيبقى عنق زجاجة لعمليات الشركة كلها.
شكل التعطل ليه أكتر من صورة. الطلبات والاستفسارات بتوصل في إيميل وبتتكتب من جديد في نظام تاني. الدفع مقتصر على اللي الإضافة بتدعمه، فبوابة معينة أو وسيلة دفع معينة مستحيلة. مفيش طريقة موثوقة لتقديم بيانات لشريك لأن الموقع ملوش API. التتبع ناقص: تسجيل النماذج وضغطات واتساب والحجوزات مش بيتحسب تحويلات، فمصاريف التسويق مش بتتربط بنتيجة. نظرتنا على ربط CRM وERP بتوضح أنهي عمليات تستاهل تبدأ بأتمتتها، وأغلبها بيفترض إن الموقع شريك في المنظومة مش نهاية ميتة.
عوائق التحويل بتدخل هنا كمان. صفحة الدفع مينفعش تتبسط من غير ما تخترق قوالب إضافة. رحلة الحجز بتاخد ست ضغطات لأن أداة الحجز هي اللي بتحدد المسار. تجربة الموبايل ضعيفة لأن التخطيط تصميم ديسكتوب اتضغط. أغلب ده ممكن يتحل في ريديزاين، لكن لما السبب إن المنصة هي اللي بتفرض المسار وطبقة التصميم مش قادرة تغيره، الحل بيتطلب تغيير المنصة.
الاختبار هو عدد التسليمات اليدوية. تابع رحلة عميل حقيقي واحد من أول زيارة لحد الخدمة المسلمة. عد التسليمات اليدوية: شخص بينقل بيانات بين أنظمة، وموظف بيراجع حاجة المفروض الموقع يعرفها، وعميل بيتطلب منه يعيد معلومات اتقالت قبل كده. كل تسليم يدوي تأخير واحتمال خطأ وتكلفة عمالة. لو فيه أكتر من اتنين في رحلة الإيراد الرئيسية والموقع مش قادر يشيلهم، يبقى المعمارية هي المشكلة.
إزاي تقيم العلامات الخمسة
حط العلامات الخمسة في صفحة واحدة وادي كل واحدة درجة من 0 لـ 3 باستخدام الاختبارات اللي فاتت:
- 0 يعني العلامة مش موجودة.
- 1 يعني موجودة بس ليها حل رخيص وموثوق.
- 2 يعني موجودة والحل ممكن لكنه غالي أو هش.
- 3 يعني موجودة ومستحيل تتحل جوه الأساس الحالي.
اقرا النتيجة كنمط مش كمجموع. الموقع اللي درجته 1 أو أقل في كل علامة مرشح لريديزاين، أو حتى تجديد بسيط، وإعادة البناء هتبقى إهدار. الموقع اللي فيه درجة أو درجتين 2 مرشح للتنضيف الداخلي: صلح نقاط الضعف المحددة في مكانها وراجع بعد سنة. الموقع اللي فيه 3 في أي علامة، أو 2 في تلات علامات أو أكتر، مرشح لإعادة البناء، لأن المشاكل هيكلية وهتفضل بتكلف فلوس طول ما الأساس زي ما هو.
التقييم عامل بسيط عن قصد. هو بيمنع أشهر غلطتين: فريق وقع في حب تحديث الشكل وبيتجاهل أساس بيفشل، ومبرمج شايف كل مشكلة سبب إنه يبدأ من الصفر. اللي بيقيم لازم يكون معاه حد من الجانب التجاري للشركة، لأن العلامة الرابعة والخامسة بتبان في التشغيل قبل ما تبان في الكود بكتير.
اللي مفيش ريديزاين هيصلحه
مفيد نكون صريحين في اللي التصميم المرئي مش قادر يعمله، لأن مشاريع كتير بتتبرر بوعود الريديزاين مش شايلها. الريديزاين مش هيخلي القوالب البطيئة سريعة، لأن السرعة موجودة في الكود والسكربتات وشغل السيرفر. ومش هيخلي إضافة مهجورة آمنة. ومش هيديك بيانات منظمة أو ربط شغال أو روابط بين الصفحات وترجماتها. ومش هيحسن الترتيب لوحده، لأن الأداء في البحث بيعتمد على المحتوى والهيكل والروابط والصحة التقنية، والريديزاين ممكن يضر الأربعة بسهولة.
اللي الريديزاين يقدر يعمله كتير لو الأساس سليم: رسالة أوضح، وهوية بصرية أقوى، وتخطيط موبايل أحسن، وفهم أسرع لما بتبيعه، وخطوات أقل بين الزائر والاستفسار. لو تقييمك أثبت إن الأساس سليم، فالريديزاين هو الاستثمار الصح ولازم تتعامل معاه كمشروع تحويل بقياسات قبل وبعد واضحة: معدل الاستفسارات، وإتمام الحجز، ومعدل الارتداد في الصفحات المهمة. دليل تكلفة تصميم المواقع بيشرح إزاي النطاق بيحدد السعر في المشاريع دي.
إعادة البناء من غير خسارة الترتيب
إعادة البناء خطيرة على ظهورك في البحث لأنها بتغير بالظبط اللي جوجل بتستخدمه عشان تفهم موقعك: الروابط، والروابط الداخلية، وقوالب الصفحات، والبيانات الوصفية، والسرعة. الخطر ممكن يتحكم فيه بالانضباط، والانضباط بيبدأ قبل التصميم.
الجرد الأول
اعمل قائمة بكل رابط بيجيله زيارات أو ظهور أو روابط خارجية. اجمعها من التحليلات وSearch Console والـ sitemap وسجلات السيرفر وزحف كامل للموقع. علم الصفحات اللي بتجيب قيمة فعلية: صفحات الهبوط من البحث، والصفحات اللي ليها روابط واردة، والصفحات اللي بتجيب استفسارات. دي الصفحات اللي إعادة البناء لازم تحافظ عليها أو تحولها بعناية.
خلي الروابط زي ما هي لو تقدر، وحول لو مش تقدر
أأمن إعادة بناء هي اللي الروابط المهمة فيها مبتتغيرش. لو الهيكل الجديد فرض روابط جديدة، كل رابط قديم محتاج تحويل 301 على مستوى السيرفر لأقرب مقابل ليه، ومش تحويل شامل للصفحة الرئيسية أبدا. شرحنا الآليات بالتفصيل في قائمة مراجعة نقل الموقع، وفيها خرائط التحويل واختبارات البيئة التجريبية وترتيب يوم الإطلاق ومراقبة أول 30 يوم. اعتبر القائمة دي جزء من بريف إعادة البناء مش حاجة بتتفتكر في الآخر.
حافظ على اللي بيترتب
الصفحات اللي بتترتب شايلة وزن لأسباب يمكن متفهمهاش بالكامل: عناوينها، ونصوصها، وروابطها الداخلية، وسرعتها. إعادة البناء لازم تنقل المحتوى ده بهيكله، وتحسنه بعد الإطلاق بدل ما تعيد كتابته كله مرة واحدة. تغيير متغيرات كتير في نفس الوقت بيخلي من المستحيل تشخص سبب هبوط الترتيب. إرشادات جوجل نفسها بخصوص نقل المواقع بتقول نفس الكلام: غير حاجة واحدة في المرة لو تقدر.
اختبر على البيئة التجريبية بقواعد الإنتاج
النسخة التجريبية لازم تطابق الإنتاج في التحويلات والـ canonical وhreflang والبيانات المنظمة وقواعد robots والـ sitemap. ولازم تتمنع من الفهرسة لحد الإطلاق، والمنع ده يتشال يوم الإطلاق، لأن نسيان الخطوة دي من أشهر أسباب اختفاء المواقع الجديدة من البحث.
تقليل المخاطرة بإعادة البناء على مراحل
فكرة إعادة البناء كإطلاق واحد كبير هي خيار واحد بس. النهج المرحلي غالبا بيقلل المخاطرة وبيوزع التكلفة. في إعادة البناء المرحلية بتستبدل الموقع قسم قسم: أولا صفحات جذب العملاء، بعدها محرك الحجز أو الطلبات، بعدها البوابة أو منطقة الحسابات. النظام القديم والجديد بيشتغلوا جنب بعض ورا نفس الدومين، مع توجيه بيحدد أنهي نظام يخدم أنهي رابط. كل قسم بيتطلق ويتقاس ويتصلح قبل ما اللي بعده يبدأ.
للمراحل تلات مميزات. بتحصر أثر الأخطاء، لأن قسم واحد بس بيتغير في المرة. وبتخلي الشركة تشوف قيمة بدري، غالبا من أهم قسم تجاريا. وبتخلي التدفق النقدي أهدى من فاتورة كبيرة واحدة. العيب تعقيد مؤقت: لفترة لازم يتصان نظامين ويتحافظ على تناسقهم البصري. في المواقع اللي فيها وظائف تشغيلية جدية، المقايضة دي غالبا تستاهل.
القرار بين إطلاق واحد ومراحل بيعتمد على مدى تشابك النظام الحالي. موقع محتوى بروابط نضيفة يتعاد بناؤه عادة في إصدار واحد. موقع منطق الحجز والتسعير والمحتوى فيه متداخلين في نفس الإضافات مرشح قوي للمراحل، لأن مفيش طريقة آمنة لاستبدال كل حاجة مرة واحدة.
التكلفة والجدول الزمني وتكلفة الانتظار
أصحاب الشغل كتير بيقارنوا عرض إعادة البناء بعرض الريديزاين ويستنتجوا إن إعادة البناء غالية. المقارنة دي بتتجاهل تكلفة إنك متعملش حاجة. الموقع اللي فيه مشكلة هيكلية ليه تكاليف متكررة: ساعات ضايعة في التسليمات اليدوية، وإيراد ضايع في رحلات بطيئة أو مربكة، وفواتير إصلاح طارئة، وتكلفة الفرصة الضايعة في ميزات الشركة مش قادرة تطلقها. اجمعهم على اتنا عشر لست وتلاتين شهر قبل ما تحكم على السعر.
إطار بسيط مفيد هو مقارنة تلات سنين. لكل خيار، اكتب تكلفة المشروع لمرة واحدة، وتكلفة الصيانة السنوية، والتكلفة السنوية التقديرية للمشاكل اللي بيسيبها، وقيمة القدرات اللي بيفتحها. استخدم أرقامك أنت، واكتب الافتراضات، وقارن الإجماليات مش الأسعار المعلنة. الخيارات الرخيصة اللي بتسيب مشاكل هيكلية غالبا بتخسر في الحساب ده، والخيارات الغالية اللي مبتصلحش حاجة هيكلية بتخسر كمان. لمحركات التكلفة في الأنظمة الأعقد، مقالنا عن تكلفة بوابات العملاء والأنظمة المخصصة بيشرح إيه اللي بيرفع الميزانية أو بينزلها.
بالنسبة للجدول الزمني، خد حذرك من أي خطة من غير مرحلة اكتشاف. عرض إعادة البناء لازم يبدأ بتدقيق للموقع الحالي، وجرد للمحتوى والروابط، وتحديد للميزات المطلوبة، وتصميم تقني متفق عليه قبل ما يتكتب أول قالب. تخطي الاكتشاف هو سبب تأخر المشاريع، لأن المجاهيل بتظهر بعد ما الفلوس اتصرفت.
إزاي تكتب بريف إعادة البناء
البريف الكويس قصير ومحدد. لازم فيه أهداف الشغل اللي الموقع يخدمها مترتبة، وتقييم العلامات الخمسة والدليل وراه، وقائمة الروابط والمحتوى اللي لازم يتحافظ عليه، والربط المطلوب دلوقتي والمتوقع في سنتين، واللغات والأسواق، وأهداف الأداء للقوالب الأساسية، ومين هيمتلك الموقع بعد الإطلاق. ولازم يقول كمان إيه خارج النطاق، عشان إعادة البناء متتحولش بهدوء لريديزاين وإعادة كتابة محتوى وتمرين هوية بصرية في نفس الوقت.
اسأل كل مورد نفس الأسئلة وقارن الإجابات:
- إيه اللي هتحافظ عليه من الموقع الحالي، وليه؟
- هتحمي الترتيب الحالي إزاي، وإيه اللي هتسلمه في ده؟
- إيه اللي بيحصل لمحتوانا وبياناتنا لو سبناكم؟
- الأداء هيتتحقق منه إزاي، وعلى أنهي حدود؟
- مين هيصون الموقع بعد الإطلاق، والصيانة بتشمل إيه؟
الموردين اللي بيجاوبوا بتفاصيل بيوروك طريقة شغلهم. والإجابات الضبابية معلومة هي كمان.
خطة 30 يوم للقرار
مش لازم تلتزم بإعادة بناء عشان تعرف لو محتاجها. شهر كفاية تقرر بالدليل.
- الأسبوع الأول: شغل PageSpeed Insights على أهم خمس قوالب، وصدر تقارير Core Web Vitals والفهرسة من Search Console، واعمل قائمة بكل إضافة وتاريخ آخر تحديث لها.
- الأسبوع التاني: اعمل اختبار التغيير الواحد وعد التسليمات اليدوية مع الناس اللي بتشتغل. اكتب الخمس قدرات اللي الشركة عايزاها السنة الجاية وصنف كل واحدة: نضيفة ولا ترقيعية ولا متعطلة.
- الأسبوع التالت: قيم العلامات الخمسة. اطلب من مبرمج يقدر ميزانية الإصلاح لأسوأ علامة، مع إعادة بناء وبدونها.
- الأسبوع الرابع: قرر بين الريديزاين والتنضيف الداخلي وإعادة البناء، واكتب البريف للمسار اللي اخترته.
لو النتيجة إعادة بناء، هتدخل مناقشات الموردين ومعاك تشخيص متقيم وقائمة روابط محفوظة وتعريف واضح للنجاح. ده لوحده بيغير جودة العروض اللي هتوصلك، وبيحميك من إنك تدفع في ريديزاين والأساس هو اللي بيفشل، أو تدفع في إعادة بناء وتنضيف بسيط كان يكفي. المشاريع اللي بتنجح مش اللي ميزانيتها أكبر، دي اللي قرارها اتاخد على تشخيص مقاس، وخريطة التحويلات اتكتبت قبل أول صفحة تتبني، والأساس الجديد اتصمم على الطريقة اللي الشركة بتبيع بيها فعلا.