ابدأ بالإصلاح عندما تكون المشكلة محددة وقابلة لإعادة الاختبار، وما زال الموقع يخدم أعمالك على أساس يمكن صيانته. ادرس إعادة البناء عندما تمنعك البنية الحالية من أداء المهام المطلوبة أو تجعل كل تغيير سلسلة من الأعطال. لا يكفي عمر الموقع أو مظهره القديم وحده لاتخاذ القرار، ولا يعني تعطل رفع صورة أن الموقع كله يحتاج استبدالًا.
الخطوة المناسبة قبل عرض سعر كبير هي تشخيص يفرّق بين العطل، وصعوبة الاستخدام، وتغيّر احتياجات المنشأة. اطلب نتيجة واضحة من إصلاح المواقع وتحسينها: ما السبب المثبت، وما الذي يمكن الاحتفاظ به، وما البدائل وحدود كل منها؟
1. صف العطل بطريقة قابلة للفحص
عبارة «الموقع سيئ» لا تساعد على تقدير العمل. اكتب بدلًا منها المهمة التي تتعطل، والجهاز والمتصفح، والنتيجة المتوقعة، وما يحدث فعليًا، وآخر وقت كان فيه المسار يعمل.
مثلًا: «موظف المحتوى يستطيع تسجيل الدخول من الجوال، لكن إضافة صورة إلى خبر جديد تتوقف، بينما ينجح رفع ملف آخر من الحاسوب». هذه معلومات تشخيص، وليست دليلًا بعد على أن الاستضافة أو ووردبريس هو السبب.
جهّز طلب الفحص بهذه العناصر:
- رابط الصفحة أو المهمة، وخطوات إعادة المشكلة.
- صورة للرسالة أو تسجيل قصير دون بيانات شخصية.
- هل يتأثر كل المستخدمين أم دور معين؟ وهل العطل مستمر أم متقطع؟
- التغييرات الأخيرة المعروفة: تحديث، إضافة، استضافة، إعداد أو تكامل.
- الأصول التي يجب الحفاظ عليها: محتوى، نماذج، طلبات، روابط، لغات.
- وضع الوصول وملكية الحسابات، دون إرسال كلمات المرور في الطلب العام.
افصل الملاحظة عن التفسير. «لا تصل رسالة النموذج» ملاحظة؛ «الخادم محظور» فرضية تحتاج دليلًا. وإذا ظهرت مؤشرات اختراق أو كشف بيانات، فهذه مسألة أمنية تحتاج احتواءً وتفويضًا متخصصًا، وليست مجرد تجميل واجهة.
2. مصفوفة القرار: إصلاح، تحديث جزئي، أم بناء جديد؟
| الحالة بعد الفحص | الخيار الأقرب | دليل ينبغي طلبه |
|---|---|---|
| خلل محدود في نموذج أو رفع ملفات، وبقية الرحلات سليمة | إصلاح محدد | إعادة إنتاج العطل ثم نجاح الحالة نفسها بعد المعالجة |
| صفحات قليلة غير مناسبة للجوال، والبنية التحريرية جيدة | تعديل القوالب المتأثرة | مراجعة الصفحات والحالات التابعة للقالب |
| المحتوى والخدمات تغيرا، لكن النظام قابل للصيانة | إعادة تنظيم وتصميم جزئي | خريطة المحتوى والصفحات التي ستبقى أو تتغير |
| مكونات أساسية غير مدعومة ولا يوجد مسار تحديث عملي | استبدال مكونات أو إعادة بناء | مقارنة البدائل والتبعيات ومخاطر النقل |
| التغييرات المتكررة تعيد الأعطال وتمنع وظائف مطلوبة | دراسة بناء جديد | سجل أسباب الأعطال وحدود الإصلاح وتكلفة التشغيل |
| الوصول أو الملكية غير واضحين | استعادة وصول رسمية أولًا | إثبات ملكية وحصر الحسابات والصلاحيات |
هذه مؤشرات وليست حكمًا آليًا. قد يكون الأنسب إصلاح استقبال الاستفسارات الآن ثم استبدال قالب واحد لاحقًا. وطلب تصميم موقع إلكتروني يصبح مفيدًا عندما تتغير بنية الصفحات ورسائلها، لا باعتباره علاجًا تلقائيًا لكل خطأ تقني.
3. لا تبدأ التعديل قبل تجهيز مسار الرجوع
توضح وثائق ووردبريس أن استعادة الموقع المعتادة تحتاج قاعدة البيانات والملفات معًا. وجود تصدير للمقالات أو نسخة من الصور لا يعادل نسخة كاملة قابلة للاستعادة. المصدر: دليل النسخ الاحتياطي في ووردبريس.
اتفق مع المنفّذ على مكان النسخة، وتاريخها، وما تشمله، ومَن يستطيع استعادتها. الأفضل أن تتضمن خطة العمل تجربة استعادة في بيئة منفصلة، لا مجرد ظهور رسالة «اكتمل النسخ». احمِ النسخة لأنها قد تحتوي على بيانات عملاء وإعدادات حساسة.
وفي الموقع الذي يستقبل طلبات أو حجوزات، ناقش أثر الرجوع إلى نسخة أقدم: ما البيانات التي وصلت بعد أخذها؟ وكيف ستُحفظ أو تُسوّى؟ العودة إلى نسخة سليمة تقنيًا قد تعني فقدان معاملات حديثة إذا لم تُخطط العملية.
ما وظيفة بيئة الاختبار؟
هي نسخة منفصلة لتجربة التغيير دون تعريض الزوار مباشرة له. اضبط الوصول إليها، وتعامل بحذر مع البيانات المنسوخة، وامنع إرسال إشعارات حقيقية أو تنفيذ معاملات غير مقصودة. حماية الوصول تختلف عن مجرد طلب عدم فهرستها.
تشير وثائق ووردبريس إلى استخدام بيئة اختبار أو نسخة احتياطية مناسبة قبل التعديل، ولا توصي بتشغيل أدوات التصحيح على المواقع الحية. اطلب جمع الأدلة بطريقة لا تعرض تفاصيل الأخطاء للزوار. المصدر: تصحيح الأخطاء في ووردبريس.
4. كيف يبدو التشخيص الجيد؟
يبدأ بإعادة المشكلة في ظروف معروفة، ثم يراجع الأدلة المرتبطة بها: سجل الخطأ، وطلب الشبكة، وصلاحيات المستخدم، وإعدادات المكوّن المعني. بعدها يختبر فرضية محددة في البيئة المناسبة، بدل تغيير القالب والاستضافة والإضافات دفعة واحدة.
في مشكلة رفع الوسائط، قد يراجع المختص نوع الملف وحجمه، وحدود الخادم، والاستجابة الصادرة عن واجهة الرفع، وتعارض الإضافات. هذه قائمة احتمالات وليست تعليمات لإيقاف الحماية أو حذف المكونات عشوائيًا. يجب أن يفسّر تقرير التشخيص لماذا يرجّح السبب المحدد وما الذي استُبعد.
وفي البطء، اطلب قياس صفحات ومهام تمثل استخدام العملاء. تفرّق Google بين الاختبارات المعملية وبيانات تجربة المستخدمين الفعلية؛ وقد تختلف نتائج النوعين. لا تعتمد درجة واحدة بوصفها وصفًا كاملًا لأداء الموقع. المصدر: شرح PageSpeed Insights.
يمكن أن تكون معالجة الأداء وتعزيز الأمان نطاقًا إضافيًا محددًا إذا أثبت الفحص الحاجة إليه. تحسين السرعة لا يعني إجراء مراجعة أمنية شاملة، والعكس صحيح؛ اكتب ما سيُفحص وما لن يُفحص.
5. مثال افتراضي: موقع شركة خدمات هندسية في الرياض
هذا سيناريو توضيحي وليس دراسة حالة من أعمال LAB. للشركة موقع عربي وإنجليزي، وتصل الاستفسارات عبر نموذج. يشتكي الفريق من ثلاثة أمور: رفع الصور من الجوال لا يعمل، ونموذج التواصل لا يؤكد الاستلام بوضوح، وتحديث صفحة الخدمات صعب.
يُقسّم الفحص إلى مسارات مستقلة. في السيناريو المفترض، تكشف تجربة على نسخة اختبار أن مشكلة الرفع مرتبطة بإضافة معينة؛ تُعالج المشكلة ويُعاد اختبارها بالأجهزة والملفات المتفق عليها. يتضح كذلك أن النموذج يحفظ الاستفسار لكن رسالة النجاح غير واضحة، فتُراجع الواجهة ومسار الإشعار. أما صفحة الخدمات فتعتمد على قالب يجعل تعديل المحتوى مرهقًا.
القرار المقترح هنا: إصلاح الرفع والنموذج، ثم استبدال قالب صفحة الخدمات مع الحفاظ على المحتوى والروابط. لا يبرّر ذلك وحده بناء الموقع كله من جديد.
| بند التسليم | قبول عملي |
|---|---|
| رفع الوسائط | يرفع المحرر الملفات المسموح بها من الأجهزة المتفق عليها، وتظهر رسالة واضحة عند الرفض |
| نموذج التواصل | يُحفظ الاستفسار ويصل إلى وجهته المتفق عليها، ويشاهد الزائر تأكيدًا صحيحًا |
| صفحة الخدمات | يعدّل الموظف نصًا وصورة وينشرهما دون تعديل برمجي |
| اللغتان | تُختبر الصفحة العربية والإنجليزية ومسارات الانتقال بينهما |
| سلامة البيانات | لا تختفي الاستفسارات السابقة أو التعديلات المعتمدة |
الفائدة من المثال هي فصل القرارات. سبب واحد مثبت لا يفسّر كل أعراض الموقع، وإصلاح مسار لا يعفي من اختبار ما قد يتأثر به.
6. إذا اخترت إعادة البناء، انقل القيمة الموجودة أيضًا
احصر الصفحات والملفات المهمة، وما يجلب استفسارات فعلية، وروابط الحملات والنماذج والتكاملات. لا تنقل كل شيء بلا مراجعة، ولا تحذف محتوى مفيدًا لمجرد أنه لا يناسب القالب الجديد.
عند تغيير الروابط، توصي Google بإعداد خريطة بين العناوين القديمة والجديدة، واختبار الموقع، وإعداد التحويلات، ثم مراقبة الحركة. كما تنصح بعدم جمع كل التغييرات الكبيرة في خطوة واحدة عندما يمكن فصلها. هذه إجراءات تقليل مخاطر، وليست ضمانًا لثبات الترتيب. المصدر: نقل المواقع مع تغيير الروابط.
اجعل مراجعة الظهور في البحث جزءًا واضحًا من خطة الانتقال إن كان للموقع حضور قائم، مع تحديد الصفحات والقياسات التي ستراجع قبل النقل وبعده.
7. ماذا تستلم قبل إغلاق المهمة؟
- [ ] وصف السبب المثبت والإصلاح المنفّذ، لا قائمة أدوات فقط.
- [ ] نتيجة إعادة الاختبار لكل عطل، مع الأجهزة والأدوار المشمولة.
- [ ] فحص المسارات المتأثرة، مثل النماذج والتحرير واللغات.
- [ ] سجل بالتغييرات والإصدارات والإعدادات اللازمة للصيانة.
- [ ] نسخة احتياطية وخطة نشر ورجوع مع مسؤول محدد.
- [ ] قائمة المشكلات المؤجلة وأسباب تأجيلها.
- [ ] نقل المعرفة وتعديل الصلاحيات المؤقتة بعد انتهاء العمل.
نطاق اختبار وضمان جودة البرمجيات يساعد على تحويل «تم الإصلاح» إلى حالات قبول قابلة للمراجعة. افصل أيضًا إصلاح العطل عن عقد الصيانة اللاحق، وحدّد مسؤولية الأعطال التي قد تظهر بعد تحديثات مستقبلية.
أسئلة شائعة
هل تغيير الاستضافة يحل البطء دائمًا؟
لا. قد يكون السبب في الخادم أو الصور أو الكود أو خدمات خارجية أو أكثر من عامل. انقل الاستضافة عندما يدعم التشخيص ذلك، مع خطة نقل واختبار، لا باعتبار النقل تجربة عشوائية.
هل يجب إعادة بناء موقع قديم بالكامل؟
لا. راجع قابلية صيانة مكوناته، واحتياجات الأعمال، وصعوبة التعديل. قد يكفي إصلاح أو استبدال جزء منه مع الاحتفاظ بالمحتوى والأصول المفيدة.
هل يمكن إصلاح موقع بناه منفّذ آخر؟
يمكن تقييمه إذا توفرت صلاحيات مشروعة ومعلومات كافية. تحدّد حالة الكود والتراخيص والتبعيات ما يمكن إصلاحه، وقد يلزم استرداد الوصول عبر الجهات المالكة للحسابات أولًا.
كيف أقارن عرض إصلاح بعرض إعادة بناء؟
قارن المخرجات نفسها: المهام التي ستعمل، والبيانات التي ستبقى، والاختبارات، ومسؤولية النشر والرجوع والصيانة. رقم أقل دون نطاق مماثل لا يثبت أن العرض أوفر.
الخطوة التالية
اجمع أهم ثلاث مهام متعطلة مع خطوات تكرارها، وما يجب ألا يتغير في الموقع. اطلب تشخيصًا وتوصية مبررة بين الإصلاح والتحديث الجزئي وإعادة البناء، قبل الموافقة على تغيير شامل.
المصادر
رُوجعت في 26 أكتوبر 2026.
