ماذا تفحص بعد إطلاق الموقع قبل طلب تطوير جديد؟

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

هذه طريقة تشخيص لصاحب مشروع صغير أو مشغل موقع. لا تحدد سبب موقع لم يُفحص، ولا تضمن تحسن الترتيب، ولا تستبدل مراجعة الدفع أو الحماية أو المتطلبات القانونية. هدفها جعل قرار التطوير التالي قابلًا للاختبار.

افتح حادثة لا طلب إعادة بناء

أنشئ سجلًا مستقلًا لكل عرض. لا تجمع «الهاتف بطيء» و«النموذج لا يرسل» و«Google لا يعرض الصفحة» تحت عبارة «الموقع سيئ». لكل حادثة سجل:

عبارة «الموقع بطيء» ليست جاهزة. أما «صفحة المنتج العربية استغرقت 8 ثوانٍ على هاتف 4G الساعة 10:20 وكانت صورة البطل آخر مورد» فهي جاهزة لاختبار أضيق.

مسار الفرز الأول: هل الخلل ظاهر للزائر؟

ابدأ بنافذة خاصة وأعد المسار نفسه. استخدم اللغة والجهاز وحالة الحساب والرابط نفسه. لا تمسح كل المتغيرات مرة واحدة حتى لا تمحو الدليل.

افصل النتيجة إلى أربع ملاحظات:

1. التنقل: هل يعيد الرابط الصفحة المطلوبة أم تحويلًا أو حلقة أو 404؟
2. المحتوى: هل النص أو الصورة أو السعر أو اتجاه اللغة أو الدعوة ناقص أو خاطئ؟
3. التفاعل: هل يفشل الضغط أو النموذج أو الفلتر أو السلة أو التحويل إلى واتساب؟
4. الأداء: هل يصبح المحتوى قابلًا للاستخدام متأخرًا أو يتحرك أثناء التحميل أو يحجبه سكربت؟

التقط الحالة قبل التحديث. إذا نجحت المحاولة الثانية، احتفظ بالمحاولتين؛ النجاح المتقطع دليل وليس إغلاقًا.

مسار الفرز الثاني: افصل الفهرسة عن الشكل

إذا كانت الشكوى «Google لا يجد الصفحة»، فلا تستنتج أن التصميم أو المحتوى هو السبب. توفر Search Console تقارير الأداء وURL Inspection والفهرسة وCore Web Vitals؛ استخدم التقرير المطابق للعرض.

تسلسل فحص آمن:

• تأكد أن الرابط يعيد كود HTTP الصحيح.
• افحص الرابط نفسه لا نسخة لغوية مشابهة.
• راجع robots وnoindex والـcanonical.
• افتح إدخال Sitemap وقارن الرابط بالـcanonical.
• افحص العربية والإنجليزية منفصلتين؛ لا ينبغي أن تشير لغة إلى الأخرى بصمت.
• سجل سبب الاستبعاد قبل تعديل البيانات.

دليل Search Console يوضح ما يبلغه Google عن الوصول والفهرسة. لا يثبت أن إعادة كتابة الصفحة ستحسن الترتيب. احتفظ بهذا الفصل داخل سجل الحادثة.

مسار الفرز الثالث: افصل السرعة عن طلب التصميم

تجمع PageSpeed Insights بين تشخيصات المختبر وبيانات المستخدمين وتعرض إشارات مثل Core Web Vitals. استخدمها لتحديد المسار البطيء والمورد أو سلوك التحميل المحتمل، ولا تحول درجة واحدة إلى طلب إعادة تصميم.

شغّل الرابط نفسه على الهاتف والديسكتوب وسجل:

• الرابط واللغة.
• وقت الاختبار وسياق الاتصال.
• LCP وCLS وINP إن ظهرت.
• TTFB وحجم الصفحة إن ظهرا.
• أكبر صورة أو سكربت أو خط أو طلب خارجي.
• هل يظهر الخلل في بيانات المستخدمين أم المختبر أم الاثنين.

بعدها غيّر متغيرًا واحدًا: ضغط صورة البطل، أو تأجيل سكربت غير أساسي، أو حذف وزن خط غير مستخدم، أو تجربة قاعدة كاش واحدة. أعد الاختبار نفسه. إذا تغيرت النتيجة فسجل التغيير، ولا تقل إن الموقع كله «اتصلح».

مسار الفرز الرابع: أعد إنتاج النموذج والسلة واللغات

النموذج الذي يفشل بعد تغيير اللغة يحتاج إعادة إنتاج واعية باللغة. والسلة التي تفقد العنصر على الهاتف تحتاج سجلًا واعيًا بالجهاز. استخدم الخطوات التالية:

1. افتح رابط اللغة المحدد.
2. سجل هل الاتجاه RTL أم LTR.
3. نفذ فعلًا واحدًا في كل مرة.
4. سجل الطلب والرد والرسالة الظاهرة عندما تسمح الأدوات.
5. أعد المحاولة مرة من دون تغيير الكاش أو الحساب أو المدخل.
6. جرّب اللغة أو الجهاز الآخر بعد تسجيل النتيجة الأولى.
7. توقف قبل دفع حقيقي أو حذف مدمر أو كشف بيانات عميل.

في خدمة تنتهي بواتساب، سجل بقاء المنتج واللغة وسياق العميل بعد التحويل. وفي WooCommerce استخدم staging أو مسار اختبار معتمدًا واعزل الطلب الناتج.

مسار الفرز الخامس: صنّف الطبقة المحتملة

بعد إعادة الإنتاج صنف الحادثة دون ادعاء اليقين:

• المحتوى: نص أو ترجمة أو سعر أو صورة أو CTA ناقص.
• القالب/CSS: خروج أو مسافات أو تباين أو اتجاه أو استجابة.
• JavaScript: ضغط أو فلتر أو نموذج أو سلة تفشل بعد التحميل.
• البيانات/الإضافة: منتج أو طلب أو تصنيف أو لغة أو تكامل ناقص.
• الخادم/الكاش: كود متقطع أو مخرجات قديمة أو طلب محجوب.
• البحث: فهرسة أو canonical أو Sitemap أو robots.

الطبقة فرضية عمل وليست حكمًا. اكتب الاختبار الذي يؤكدها أو يضيقها. اللقطة وحدها نادرًا ما تحدد الطبقة.

سجل الحادثة

استخدم صفًا لكل اختبار:

اترك الملاحظة والفرضية والنتيجة في أعمدة منفصلة. هذا هو الفرق بين التشخيص وقائمة الآراء.

متى تصلح ومتى تراقب ومتى تصعّد؟

اختر الإصلاح الآن عندما يكون الخلل قابلًا للتكرار والتغيير الآمن معروفًا والمالك موافقًا على النطاق. اختر المراقبة عندما تكون النتيجة متقطعة أو ما زالت بيانات المستخدمين تتجمع. اختر التصعيد عندما يحتاج الاختبار دفعًا حيًا أو صلاحيات خاصة أو DNS أو هجرة مدمرة أو بيانات عميل.

يجب أن يملك تغيير الإنتاج نقطة تراجع ومسؤولًا واحدًا وخطوة تحقق. إذا لم تستطع حفظ الدليل، أوقف التغيير وانقل التكرار إلى staging. أحيانًا يكون توثيق المجهول أكثر أمانًا من تعديل الموقع.

تشخيص افتراضي

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

أغلق الحادثة قبل فتح تطوير جديد

أغلق السجل فقط عندما ينطبق أحد الآتي:

• الخلل القابل للتكرار أُصلح ونجحت الخطوات نفسها مرة أخرى.
• الخلل تحت المراقبة وله مسؤول ومدة متابعة وشرط تصعيد.
• الدليل يثبت أن الاعتماد عند المالك، مثل صلاحية أو محتوى أو إصلاح طرف ثالث.
• اتضح أن الشكوى الأصلية لم تتكرر، وحددتم ملاحظة تالية واضحة.

لا تستبدل الحادثة المغلقة بمهمة غامضة اسمها «حسّن الموقع». افتح سجلًا جديدًا إذا قاد الدليل إلى طبقة أو نطاق مختلف.

إذا احتجت تحويل السجل إلى تدقيق محدد، راجع خدمة التدقيق التسويقي في MartGain. يظل القرار مشروطًا بالعرض القابل للتكرار، والوصول المتاح، واللغات، وحدود الاختبار المعتمدة.

استخدم سجل الحادثة القابل للتعبئة داخل الحزمة.