الكود المستخدم متجر — أفضل الخيارات وطرق التوفير مع WC4

Worked for 45s

المرحلة 18 من 30: مراجعة التحويلات وCRO وزيادة استخدام الكود

نطاق المرحلة: أول شاشة، وضوح العرض، زر نسخ الكود، الانتقال للمتجر، اختيار الدولة، إشارات الثقة، التشتت، الإلحاح، رحلة المستخدم، وقياس التحويلات.

تقييم التحويل الحالي: 3.5/10

الموقع يملك هدفًا بسيطًا وقابلًا للتحسين:

المستخدم يجد الكود ← ينسخه ← يختار دولته ← ينتقل إلى المتجر ← يجرب الكود.

لكن الصفحة الرئيسية تضع حول هذا الهدف عددًا كبيرًا من الادعاءات والعناصر المتنافسة، مثل:

• «الموقع الرسمي».
• «كود مضمون التطبيق».
• +50K عميل سعيد.
• 100% كود مفعّل.
• متابعة 24/7.
• عداد انتهاء متوقف عند الصفر.
• «تم التحقق اليوم».
• شحن وإرجاع ودعم.
• مقالات ومتاجر نون وروابط عديدة.

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

ملخص المرحلة

أولًا: المشكلات الحرجة

1. العداد والإلحاح الحاليان يضران الثقة

الخطورة: حرجة

الصفحة تقول:

عرض اليوم ينتهي خلال

ثم تعرض:

00 ساعة

00 دقيقة

00 ثانية

وتضيف:

سارع بنسخ كود wc4 قبل انتهاء الخصم اليومي.

لكن الصفحة نفسها تقول أيضًا إن الكود «ساري طوال 2026».

هذه رسائل متعارضة:

• هل العرض ينتهي اليوم؟
• هل انتهى بالفعل؟
• هل هو متاح طوال 2026؟
• هل العداد يعاد تشغيله يوميًا؟

الـFTC تعتبر العدادات الوهمية التي تنتهي ثم تعود أو لا ترتبط بانتهاء حقيقي مثالًا على أنماط التصميم المضللة التي تضغط على المستخدم لاتخاذ قرار سريع.

المطلوب فورًا

حذف:

• العداد.
• «ينتهي اليوم».
• «سارع قبل انتهاء الخصم».
• «حتى نفاد الكمية» ما لم توجد بيانات حقيقية.
• أي تاريخ أو وقت انتهاء غير مستمد من مصدر رسمي.

البديل

آخر اختبار مسجل: 14 يوليو 2026

مع حالة واقعية:

تم قبول الكود في آخر اختبار

أو:

يحتاج إلى إعادة اختبار

هذا يحفز المستخدم بالمعلومة، لا بالضغط المصطنع.

2. كثرة الادعاءات غير المثبتة تعطل التحويل بدل دعمه

الخطورة: حرجة

الصفحة تعرض:

• +50K عميل سعيد.
• 100% كود مفعّل.
• متابعة 24/7.
• كود رسمي وموثوق.
• مضمون التطبيق.
• بدون حد أدنى.
• يعمل على كافة المنتجات.
• دعم على مدار اليوم.
• إرجاع خلال 14 يومًا.

لا توجد بجوار هذه الأرقام أو الادعاءات:

• بيانات مصدر.
• عدد مرات استخدام.
• سجل اختبارات.
• روابط سياسات.
• منهجية قياس.
• جهة مسؤولة.
• إثبات شراكة رسمية.

تأثير CRO

المستخدم لا يحتاج عشرة ادعاءات ثقة؛ يحتاج إجابة واضحة عن ثلاثة أسئلة:

1. ما الكود؟
2. هل جُرّب مؤخرًا؟
3. كيف أستخدمه في دولتي؟

المطلوب

حذف جميع الأرقام غير الموثقة، واستبدالها بمربع واحد:

الثقة المبنية على الشفافية أقوى من الشارات الدعائية.

3. يوجد أكثر من CTA لنفس الوظيفة بصياغات مختلفة

تظهر في الرئيسية عبارات مثل:

• «احصل على الكود».
• «إظهار الكود ونسخه».
• «نسخ الكود».
• «احصل على الكود الآن».
• «زيارة متجر الدخيل للعود».

وفي الوقت نفسه، الكود wc4 ظاهر فعليًا داخل الصفحة، لذلك عبارة «إظهار الكود» لا تطابق الحالة الحالية.

المشكلة

لا يعرف المستخدم هل:

• سيظهر الكود بعد الضغط؟
• سينسخ الكود؟
• سيفتح المتجر؟
• سيقوم بالوظيفتين معًا؟
• هل الكود مخفي أم ظاهر؟

تصميم الواجهة الجيد يجب أن يوضح حالة النظام، ويقدم Feedback مباشرًا بعد الإجراء، كما ينبغي إبراز المهمة الأساسية بتسلسل بصري واضح.

القرار المقترح

استخدام زرين فقط:

الزر الأساسي

نسخ الكود wc4

الزر الثانوي

فتح متجر السعودية

أو:

فتح متجر الإمارات

وحذف:

• إظهار الكود.
• احصل على الكود.
• احصل على الكود الآن.
• زيارة المتجر دون تحديد الدولة.

4. اختيار الدولة يجب أن يسبق فتح المتجر

الخطورة: حرجة

الصفحة العامة تقول إن الكود يدعم السعودية والإمارات والكويت وقطر والبحرين وعُمان، بينما صفحة الإمارات تعرض تفاصيل محلية مثل الدرهم ومدن التوصيل ووسائل الدفع.

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

• يفتح متجر دولة خاطئة.
• تظهر عملة مختلفة.
• لا يجد الشحن لدولته.
• يعتقد أن الكود لا يعمل.
• يضطر للرجوع وإعادة الرحلة.

التدفق الصحيح

نسخ الكود

↓

اختيار الدولة

↓

فتح متجر الدولة

التصميم المقترح

اختر دولة التسوق:

[ السعودية ▼ ]

الكود: wc4

[ نسخ الكود ]

[ فتح متجر السعودية ]

بعد النسخ

تم نسخ wc4 بنجاح.

الخطوة التالية:

افتح متجر السعودية والصق الكود في صفحة الدفع.

[ فتح متجر السعودية ]

لا تجعل المستخدم يختار الدولة مرتين: مرة في موقع الكوبون ومرة في المتجر، إن كان من الممكن توجيهه مباشرة إلى النسخة الصحيحة.

5. رسالة نجاح النسخ لا تقود المستخدم للخطوة التالية

زر نسخ الكود ليس التحويل النهائي. النجاح الحقيقي للموقع هو أن ينسخ المستخدم الكود ثم يفتح المتجر.

إذا اكتفى التصميم بتغيير النص إلى:

تم النسخ

فقد يتوقف المستخدم أو يبحث عن الخطوة التالية.

الرسالة المطلوبة

تم نسخ الكود wc4 بنجاح.

افتح متجر السعودية، أضف المنتجات للسلة، ثم ألصق الكود في خانة الخصم قبل الدفع.

مع زر:

فتح متجر السعودية

لا تفعل

• فتح المتجر تلقائيًا بمجرد النسخ دون إخبار المستخدم.
• فتح أكثر من نافذة.
• إخفاء الكود بعد النسخ.
• نقل المستخدم فورًا قبل أن يعرف أن النسخ نجح.
• عرض رسالة تختفي في أقل من ثانية.

ثانيًا: مشكلات مرتفعة الخطورة

6. أول شاشة مزدحمة أكثر من اللازم

أول جزء من الصفحة يحتوي على:

• وصف العلامة.
• ادعاء الموقع الرسمي.
• عنوان رئيسي.
• وصف.
• CTA.
• إحصاءات.
• شارات.
• بطاقة أخرى للكوبون.
• زر متجر.

هذه العناصر تكرر المعنى نفسه قبل أن يصل المستخدم إلى قرار بسيط.

أول شاشة مقترحة

موقع كوبونات مستقل

كود خصم الدخيل للعود

wc4

آخر اختبار: [التاريخ]

الدولة المختبرة: [الدولة]

النتيجة: [مقبول/غير مؤكد]

[ نسخ الكود wc4 ]

اختر دولتك:

[ السعودية ▼ ]

[ فتح متجر السعودية ]

قد تختلف أهلية المنتجات والحسابات. تحقق من ظهور الخصم قبل الدفع.

بعد ذلك فقط:

• الشروط.
• خطوات الاستخدام.
• المنتجات المختبرة.
• حل مشكلة عدم عمل الكود.
• المقالات.

7. ترتيب المعلومات لا يجيب عن اعتراضات المستخدم قبل CTA

الصفحة تعرض وصفًا دعائيًا ثم زرًا، لكنها لا توضح قرب الزر:

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

بدلًا من ذلك، تظهر معلومات قطعية مثل «كل المنتجات» و«بدون حد أدنى» دون إثبات.

المطلوب قرب CTA

ما نعرفه:

• تم قبول الكود في آخر اختبار بالسعودية.

• اختُبر على منتج بسعر كامل.

• قد لا يعمل مع عروض أخرى.

ما لم نتحقق منه:

• المنتجات المخفضة.

• جميع الحسابات.

• جميع دول الخليج.

الاعتراف بالحدود أفضل من وعد لا يستطيع الموقع ضمانه.

8. صفحة الإمارات تحمل ادعاءات كثيرة قبل الإثبات

صفحة الإمارات تقول إن الكود يعمل على كل أقسام المتجر، وإن الشحن يتم خلال 1–4 أيام، وإن الدفع يدعم عدة وسائل، وإن البيانات «تم التحقق اليوم». لكن لا تظهر مصادر أو تفاصيل اختبار مباشرة بجوارها.

تحسين CRO

بدل TL;DR دعائي، استخدم:

ملخص الاستخدام في الإمارات

الكود: wc4

العملة: AED

رابط المتجر: نسخة الإمارات

آخر اختبار للكود: التاريخ

المنتج المختبر: اسم أو فئة المنتج

نتيجة الاختبار: تم القبول / غير مؤكد

مع رابط صغير:

اطّلع على تفاصيل الاختبار

9. صفحة العروض تخلط النشط بالموسمي

صفحة العروض تعرض في الوقت نفسه:

• عرض اليوم.
• رمضان والعيد.
• اليوم الوطني.
• الجمعة البيضاء.

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

تأثير التحويل

المستخدم قد:

• يضغط على عرض منتهي.
• يتوقع خصمًا غير موجود.
• يفقد الثقة في جميع العروض.
• يغادر دون تجربة الكود الحقيقي.

المطلوب

تقسيمها إلى:

نشط الآن

يعرض فقط العروض المثبتة حاليًا.

مواسم قادمة

متوقع في سبتمبر — لم يبدأ بعد

عروض منتهية

انتهى في التاريخ المحدد

كل بطاقة تحمل:

• الحالة.
• تاريخ البدء.
• تاريخ الانتهاء.
• الدولة.
• المصدر.
• هل يمكن الجمع مع wc4.

10. المقالات تقطع نية المستخدم ببطاقة تجارية مبكرة

مقال دهن العود ومقال البخور يضعان بطاقة الكوبون وزر المتجر مباشرة بعد المقدمة، قبل تقديم القيمة الأساسية للمقال.

المشكلة

الزائر الذي يبحث عن:

• الفرق بين أنواع دهن العود.
• طريقة استخدام البخور.

ليس بالضرورة جاهزًا للانتقال للمتجر فورًا.

التدفق الأفضل

1. إجابة مباشرة عن السؤال.
2. معلومات أو مقارنة مفيدة.
3. توصية ذات صلة.
4. بطاقة كوبون صغيرة مرتبطة بالسياق.
5. CTA نهائية بعد تقديم القيمة.

مثال

بعد شرح الأنواع:

اخترت النوع المناسب؟

يمكنك مراجعة حالة كود دهن العود wc4 قبل الانتقال للمتجر.

ثم بطاقة صغيرة، وليس Hero تجاريًا كاملًا.

11. صفحة المقارنة منحازة بصورة تقلل الثقة

صفحة مقارنة الدخيل والعربية للعود تصف نفسها بأنها «موضوعية»، لكنها تضع بطاقة كوبون الدخيل قبل جدول المقارنة، ثم تعلن أن الدخيل هو الخيار الأوفر دون عرض أسعار أو مصادر كافية.

التأثير

حتى إذا كان الهدف هو تحويل المستخدم للدخيل، فإن الانحياز الواضح دون أدلة يقلل الثقة في التوصية.

المطلوب

• وضع منهجية المقارنة أولًا.
• عرض أسعار وأحجام وتواريخ.
• توضيح العلاقة التجارية.
• إظهار نقاط تفوق ونقاط ضعف لكل متجر.
• وضع CTA بعد الخلاصة.
• عدم استخدام كلمة «موضوعية» دون معايير موثقة.

12. روابط نون المتكررة تشتت التحويل الرئيسي

المقالات وصفحة العروض والمقارنة تعرض روابط نون السعودية والإمارات إلى جانب رابط متجر الدخيل.

يجب حسم الهدف

هل الكود wc4 يعمل على:

• متجر الدخيل؟
• نون؟
• كليهما؟
• تختلف الأكواد حسب المتجر؟

إذا كان الكود مخصصًا لمتجر الدخيل، لا تضع روابط نون مباشرة بجوار CTA الخاصة بالكود دون شرح.

التصميم الأفضل

الكود wc4 مخصص لـ: متجر الدخيل للعود

ثم قسم منفصل:

خيارات شراء أخرى

قد تختلف الأسعار والأكواد على نون.

ثالثًا: مشكلات متوسطة

13. CTA لا تذكر النتيجة التالية بدقة

بدل:

زيارة متجر الدخيل للعود

استخدم:

فتح متجر السعودية لتطبيق الكود

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

14. يجب إبراز CTA واحدة بلون أساسي

زر النسخ هو الإجراء الأساسي، وزر المتجر هو الإجراء التالي.

التسلسل البصري

1. نسخ الكود — لون Accent الأساسي.
2. فتح المتجر — زر ثانوي.
3. عرض الشروط — رابط نصي.
4. بقية الروابط — أقل بروزًا.

ينبغي الاحتفاظ بلون التمييز للعنصر الأهم بدل استخدامه في عدد كبير من الشارات والأزرار المتنافسة.

15. يجب إبقاء الكود ظاهرًا وقابلًا للنسخ اليدوي

لا تخفِ wc4 بالكامل بهدف إجبار المستخدم على الضغط؛ لأن بعض المتصفحات قد تمنع Clipboard API.

التصميم

wc4 [ نسخ ]

بعد النسخ:

wc4 [ تم النسخ ✓ ]

مع إمكانية تحديد النص يدويًا.

16. الأداء جزء مباشر من CRO

أي Sticky CTA أو صور أو Scripts تحليل إضافية يجب ألا تؤخر ظهور بطاقة الكود أو استجابتها.

الأهداف الفنية المقترحة:

• LCP ≤ 2.5s
• INP ≤ 200ms
• CLS ≤ 0.1

وهي حدود Core Web Vitals الموصى بها لتجربة جيدة. كما توضح دراسات وأمثلة منشورة على web.dev أن تحسين الأداء يمكن أن يرتبط بتحسن التحويلات، لكن التأثير الفعلي يجب قياسه على هذا الموقع من خلال بياناته وتجارب A/B الخاصة به.

رحلة المستخدم المقترحة

الصفحة العامة

دخول الصفحة

↓

فهم أن الموقع مستقل

↓

رؤية الكود وحالة اختباره

↓

اختيار الدولة

↓

نسخ الكود

↓

رسالة نجاح واضحة

↓

فتح متجر الدولة

صفحة دولة

دخول صفحة الإمارات

↓

رؤية wc4 ونتيجة اختبار الإمارات

↓

نسخ الكود

↓

فتح متجر الإمارات مباشرة

المقال

الحصول على الإجابة

↓

الاطلاع على توصية مرتبطة

↓

مشاهدة حالة الكود

↓

نسخ الكود

↓

فتح المتجر المناسب

تصميم بطاقة الكود المقترحة

كود خصم الدخيل للعود

wc4

آخر اختبار: 14 يوليو 2026

الدولة: السعودية

الحالة: تم قبول الكود في آخر اختبار

[ نسخ الكود wc4 ]

اختر المتجر:

[ السعودية ▼ ]

[ فتح متجر السعودية ]

قد تختلف أهلية المنتجات والحسابات. تحقق من الخصم في السلة قبل الدفع.

عرض تفاصيل الاختبار والشروط

رسالة نجاح النسخ

✓ تم نسخ الكود wc4

افتح متجر السعودية وألصق الكود في خانة الخصم أثناء الدفع.

[ فتح متجر السعودية ]

رسالة فشل النسخ

تعذر النسخ التلقائي.

حدد الكود wc4 وانسخه يدويًا، ثم افتح متجر السعودية.

خطة اختبارات A/B

لا يتم تغيير عشرة عناصر في تجربة واحدة؛ وإلا لن تعرف ما الذي سبب النتيجة.

الاختبار 1: إزالة الادعاءات والعداد

النسخة A

الصفحة الحالية.

النسخة B

• بلا عداد.
• بلا 50K.
• بلا 100%.
• بلا «رسمي».
• نتيجة اختبار موثقة بدلًا منها.

المقياس الأساسي

store_outbound_click ÷ sessions

المقاييس المساعدة

• coupon_copy_success.
• معدل الانتقال بعد النسخ.
• معدل الرجوع.
• وقت الوصول إلى أول CTA.

الاختبار 2: زر واحد واضح للنسخ

A

«احصل على الكود» و«إظهار الكود ونسخه».

B

نسخ الكود wc4

المقياس

coupon_copy_success ÷ coupon_view

الاختبار 3: اختيار الدولة قبل المتجر

A

زر متجر عام.

B

Country Selector ثم زر متجر يحمل اسم الدولة.

المقياس

store_outbound_click ÷ coupon_copy_success

مؤشر الحماية

• عدم زيادة رجوع المستخدم من رابط المتجر.
• عدم ارتفاع أخطاء الروابط.
• عدم انخفاض سرعة الصفحة.

الاختبار 4: رسالة ما بعد النسخ

A

«تم النسخ».

B

«تم النسخ» مع زر متجر الدولة وتعليمات قصيرة.

المقياس

store_outbound_click

بعد coupon_copy_success

الاختبار 5: موضع بطاقة المقال

A

البطاقة بعد المقدمة مباشرة.

B

البطاقة بعد الإجابة الأساسية أو المقارنة.

المقاييس

• إكمال قراءة المقال.
• نسخ الكود.
• زيارة المتجر.
• معدل الخروج.

قواعد التجارب

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

Checklist المرحلة 18 للمبرمج والمصمم

أول شاشة

• حذف عبارة الموقع الرسمي.
• حذف الإحصاءات غير المثبتة.
• حذف العداد.
• حذف الإلحاح الوهمي.
• إظهار الكود مباشرة.
• عرض تاريخ اختبار حقيقي.
• عرض الدولة المختبرة.
• عرض حالة واضحة.
• CTA أساسية واحدة.
• CTA ثانوية واحدة.
• وضع Disclaimer قريب.
• اختبارها على 320px.

CTA

• استخدام «نسخ الكود wc4».
• استخدام زر <button>.
• استخدام «فتح متجر السعودية».
• استخدام رابط <a>.
• عدم استخدام «اضغط هنا».
• عدم استخدام «احصل عليه» دون توضيح.
• جعل زر النسخ الأبرز.
• عدم فتح المتجر تلقائيًا.
• دعم النسخ اليدوي.
• عرض حالة النجاح والفشل.
• منع Double Click.
• تتبع كل موضع.

اختيار الدولة

• طلب الدولة قبل رابط المتجر.
• عرض الدولة الحالية.
• حفظ الاختيار.
• عدم فرض التحويل.
• استخدام رابط متجر صحيح.
• تسجيل country_selected.
• اختبار الدول الست.
• عدم عرض دولة غير مدعومة.
• توضيح العملة.
• منع انتقال المستخدم لمتجر دولة خاطئة.

الثقة

• إضافة منهجية الاختبار.
• عرض آخر نتيجة حقيقية.
• ذكر حدود الاختبار.
• حذف «مضمون».
• حذف «يعمل على الجميع».
• حذف 4.9/5.
• حذف 50K.
• إضافة إفصاح أفلييت.
• توضيح استقلال الموقع.
• توفير زر الإبلاغ عن كود لا يعمل.

المحتوى

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

الموبايل

• زر بارتفاع مناسب.
• عدم تغطية المحتوى بـSticky CTA.
• عدم ظهور زرين متنافسين في المساحة الصغيرة.
• إظهار الكود كاملًا.
• عدم تحرك البطاقة بعد التحميل.
• دعم مشاركة الكود.
• اختبار لوحة المفاتيح.
• اختبار النسخ في Safari وAndroid.

اختبارات القبول النهائية

• يفهم المستخدم العرض خلال خمس ثوانٍ.
• يرى الكود دون تمرير طويل.
• يعرف أن الموقع مستقل.
• يعرف متى اختُبر الكود.
• يعرف الدولة التي اختُبر فيها.
• يستطيع تحديد دولته.
• ينجح النسخ من أول محاولة.
• تظهر رسالة نجاح واضحة.
• يعرف الخطوة التالية.
• يفتح متجر الدولة الصحيح.
• لا يظهر عداد وهمي.
• لا توجد أرقام ثقة غير مثبتة.
• لا يوجد أكثر من CTA أساسية في الجزء نفسه.
• لا تفتح نوافذ دون طلب.
• لا تختلط روابط نون برابط الكود.
• يتم تسجيل رحلة التحويل كاملة.
• يتم قياس الهاتف منفصلًا.
• لا تسبب التعديلات تراجع Core Web Vitals.
• يتم اختبار النسخة الجديدة مقابل الحالية.
• لا يُعتمد أي تعديل بلا بيانات.

الحكم النهائي للمرحلة 18

الموقع لا يحتاج ضغطًا دعائيًا إضافيًا؛ بل يحتاج تقليل الشك وتقليل عدد القرارات.

ترتيب الإصلاح

1. حذف العداد فورًا.
2. حذف كل الأرقام والادعاءات غير المثبتة.
3. استخدام زر واحد واضح: «نسخ الكود wc4».
4. طلب الدولة قبل فتح المتجر.
5. عرض نتيجة اختبار حقيقية.
6. إضافة رسالة ما بعد النسخ مع زر متجر الدولة.
7. توضيح أن الموقع مستقل.
8. إزالة «الرسمي» و«المضمون».
9. فصل العروض النشطة عن الموسمية.
10. تأخير بطاقات الكوبون داخل المقالات حتى تقديم القيمة.
11. فصل روابط نون عن رحلة الكود الأساسية.
12. قياس coupon_copy_success ثم store_outbound_click.
13. تنفيذ التغييرات من خلال اختبارات A/B، وليس التخمين.

اكتب كمل للانتقال إلى المرحلة 19: مراجعة رحلة الخروج للمتجر والروابط الخارجية والأفلييت واختيار رابط الدولة الصحيح ومنع فقدان المستخدم بعد النسخ.

Worked for 1m 9s

المرحلة 23 من 30: الاستضافة وCDN والـCaching وضغط Brotli/Gzip وثبات النشر

نطاق المرحلة: الاستضافة، شبكة توزيع المحتوى، سرعة الخادم، Cache-Control، ETag، ضغط الملفات، تحديث الكاش، أسماء ملفات الإصدارات، Service Worker، التراجع عن الإصدارات، مراقبة التوقف، وثبات النسخة المنشورة.

تقييم البنية والاستضافة المبدئي: 4/10

الموقع متاح حاليًا عبر HTTPS، وصفحاته العامة قابلة للفتح والقراءة. لكن لم أتمكن من استخراج Response Headers الكاملة من بيئة الفحص الحالية، ولذلك لا يمكنني تأكيد:

• اسم مزود الاستضافة أو الـCDN.
• هل HTML تُخزن في CDN.
• هل Brotli أو Gzip مفعّلان.
• سياسة Cache-Control.
• وجود ETag أو Last-Modified.
• دعم HTTP/2 أو HTTP/3.
• مدة Cache الصور وCSS وJavaScript.
• وجود آلية Purge بعد تحديث الكوبون.
• وجود نسخة Rollback جاهزة.

هذه البنود يجب فحصها مباشرة من Network وcurl قبل اعتماد الموقع تقنيًا. (aldakheeloudcoupon.online)

ملخص المرحلة

أولًا: أخطر مشكلة — Cache المحتوى المتغير

1. يجب ألا تُخزّن صفحات الكوبون عامًا كاملًا

الخطورة: حرجة

الموقع يعرض معلومات حساسة للوقت، مثل:

• ساري الآن.
• تم التحقق اليوم.
• آخر تحديث.
• عروض اليوم.
• عروض موسمية.
• حالة كود wc4.
• الدول والمتاجر المتاحة.

صفحة الشروط وسياسة الخصوصية تعرضان تاريخ تحديث بتاريخ 14 يوليو 2026، كما تعرض صفحة العروض حالات موسمية وحالية؛ لذلك أي Cache طويلة للـHTML قد تجعل المستخدم يرى حالة قديمة بعد تعديل الموقع. (aldakheeloudcoupon.online) (aldakheeloudcoupon.online)

الخطأ الخطير

Cache-Control: public, max-age=31536000, immutable

على صفحات HTML مثل:

/

/sa

/ae

/offers

/coupons

هذا قد يحتفظ بالصفحة سنة كاملة في المتصفح.

المقترح للـHTML

Cache-Control: public, max-age=0, must-revalidate

أو إذا كانت CDN تدعم Edge Caching:

Cache-Control:

public,

max-age=0,

s-maxage=300,

stale-while-revalidate=60,

stale-if-error=86400

المعنى:

• المتصفح يعيد التحقق من الصفحة.
• CDN يمكنها حفظ النسخة خمس دقائق.
• يمكن تقديم نسخة قديمة لفترة قصيرة أثناء إعادة التحقق.
• يمكن تقديم نسخة قديمة عند سقوط الخادم بدل توقف الموقع بالكامل.

Cache-Control هو الرأس الأساسي للتحكم في Cache المتصفح والـCaches المشتركة مثل CDNs. وتسمح stale-while-revalidate بتقديم النسخة القديمة مؤقتًا أثناء تحديثها، بينما تسمح stale-if-error باستخدامها عند أخطاء مثل 500 و502 و503 و504. (developer.mozilla.org)

2. تحديث حالة الكوبون يجب أن يمسح CDN Cache فورًا

الخطورة: حرجة

عند تغيير حالة wc4 من:

تم قبوله في آخر اختبار

إلى:

لم يعمل في آخر محاولة

يجب ألا ينتظر المستخدم خمس دقائق أو ساعة أو يومًا حتى يرى التعديل.

المطلوب

بعد تعديل الكوبون:

1. حفظ النسخة الجديدة.
2. نشرها.
3. Purge لمسارات الكوبون.
4. فحص الصفحة من منطقة مختلفة.
5. مقارنة Build ID.
6. تأكيد أن CDN لا تقدم النسخة القديمة.

المسارات التي يجب مسحها

/

/sa

/ae

/om

/coupons

/coupons/*

/offers

/en

/en/sa

/en/ae

الأفضل

استخدام Purge انتقائي للمسارات المتأثرة، لا مسح الـCDN بالكامل عند كل تعديل.

بعض شبكات CDN تسمح بالجمع بين Cache طويلة وتفريغها لحظة النشر، ما يساعد على تقديم المحتوى سريعًا مع تحديثه فورًا عند الحاجة. (web.dev)

ثانيًا: ملفات JavaScript وCSS

3. الملفات الثابتة يجب أن تحمل أسماء Content-Hashed

الخطورة: حرجة

الملفات المبنية يجب أن تكون مثل:

/assets/app.a8f14d2c.js

/assets/styles.71c29f80.css

وليس:

/assets/app.js

/assets/styles.css

السبب

إذا كان الملف اسمه ثابتًا مع Cache طويلة:

1. يُنشر HTML جديد.
2. المتصفح يحتفظ بـapp.js القديم.
3. HTML الجديد يطلب Components أو Chunks جديدة.
4. تظهر شاشة بيضاء أو أخطاء JavaScript.
5. المستخدم لا يحصل على الإصلاح إلا بعد مسح الكاش يدويًا.

Headers المناسبة للملفات ذات Hash

Cache-Control: public, max-age=31536000, immutable

Chrome توصي بحفظ Static Assets غير القابلة للتغيير لمدة طويلة، مثل سنة، واستخدام Hash داخل اسم الملف حتى يطلب المتصفح النسخة الجديدة عند كل Build. (developer.chrome.com)

قاعدة النشر

• HTML: Cache قصيرة أو Revalidation.
• JS/CSS ذات Hash: سنة وimmutable.
• لا تعدل ملفًا منشورًا يحمل Hash قديمًا.
• كل تغيير ينتج اسمًا جديدًا.
• الاحتفاظ بالملفات القديمة لفترة حتى لا تنكسر جلسات مفتوحة.

4. لا تحذف Chunks القديمة فور نشر الإصدار الجديد

الخطورة: حرجة

سيناريو محتمل:

1. المستخدم يفتح الصفحة قبل النشر.
2. يحتفظ بـHTML للإصدار A.
3. يتم نشر الإصدار B.
4. تُحذف ملفات الإصدار A.
5. المستخدم يفتح Route مؤجلة Lazy-loaded.
6. المتصفح يطلب Chunk قديمة.
7. يحصل على 404.
8. تنهار الصفحة.

المطلوب

• الاحتفاظ بأصول الإصدار السابق.
• عدم حذفها لحظة النشر.
• استخدام Atomic Deployment.
• دعم Rollback.
• اكتشاف ChunkLoadError.
• إظهار زر تحديث الصفحة.

معالجة ChunkLoadError

function handleChunkLoadError(error) {

const message =

error instanceof Error ? error.message : "";

if (

message.includes("ChunkLoadError") ||

message.includes("Failed to fetch dynamically imported module")

) {

showUpdateAvailableMessage();

}

}

الرسالة:

تم نشر تحديث جديد للموقع.

أعد تحميل الصفحة للحصول على النسخة الأحدث.

[ تحديث الصفحة ]

ثالثًا: الضغط Brotli وGzip

5. يجب ضغط الملفات النصية

الخطورة: مرتفعة حتى التحقق

الأنواع التالية يجب أن تُضغط:

• HTML.
• CSS.
• JavaScript.
• JSON.
• XML.
• SVG.
• ملفات Manifest.
• النصوص.

الاستجابة المفضلة

للمتصفح الذي يدعم Brotli:

Content-Encoding: br

Vary: Accept-Encoding

وللمتصفح الذي لا يدعمه:

Content-Encoding: gzip

Vary: Accept-Encoding

Brotli وGzip يقللان حجم المحتوى النصي المنقول، ويفضل Brotli عند توفره مع Gzip كحل بديل. كما يجب استخدام Vary: Accept-Encoding حتى تخزن الـCache نسخة منفصلة لكل نوع Encoding. (web.dev) (developer.mozilla.org)

لا تُضغط مجددًا

• JPEG.
• WebP.
• AVIF.
• MP4.
• ZIP.
• WOFF2 غالبًا.

ضغط الملفات المضغوطة أصلًا قد لا يقلل حجمها، بل قد يزيده أو يستهلك CPU بلا فائدة. (developer.mozilla.org)

6. Pre-compression أفضل للملفات الثابتة الكبيرة

يمكن أثناء Build إنتاج:

app.js

app.js.br

app.js.gz

ثم تقدم CDN أو الخادم النسخة المناسبة.

الفائدة

• لا يتم ضغط الملف عند كل Request.
• يمكن استخدام مستوى ضغط Brotli أعلى أثناء Build.
• تقليل CPU على Origin.
• استجابة أسرع أثناء ارتفاع الزيارات.

بالنسبة للضغط الديناميكي، يجب استخدام مستوى متوسط يوازن بين وقت CPU وحجم الملف، بينما يسمح الضغط المسبق باستخدام مستويات أقوى. (web.dev)

رابعًا: سياسة Cache حسب نوع الملف

المصفوفة المقترحة

7. API حالة الكوبون لا يجب أن تُخزن طويلًا

إذا أصبحت حالة wc4 تُجلب من API:

/api/coupon-status?country=sa

لا تُستخدم:

Cache-Control: public, max-age=86400

لأن فشل الكود قد يظل مخفيًا يومًا كاملًا.

خيار مناسب للبيانات العامة

Cache-Control:

public,

max-age=0,

s-maxage=300,

stale-while-revalidate=60,

stale-if-error=3600

إذا كانت الاستجابة شخصية أو مرتبطة بحساب

Cache-Control: private, no-store

خامسًا: ETag وLast-Modified

8. يجب دعم Revalidation بدل تنزيل الصفحة كاملة

عند عدم تغير الصفحة، يستطيع المتصفح إرسال:

If-None-Match: "version-123"

ويعيد الخادم:

304 Not Modified

دون إعادة إرسال الصفحة كاملة.

ETag يمثل إصدارًا محددًا من المورد، ويسمح للمتصفح وCache بإعادة التحقق بكفاءة وتوفير Bandwidth. ويمكن استخدام Last-Modified كـValidator أبسط، رغم أنه أقل دقة من ETag. (developer.mozilla.org) (developer.mozilla.org)

المطلوب

• ETag تتغير عند تغير محتوى الملف.
• عدم توليد ETag عشوائية في كل Request.
• عدم اختلاف ETag لنفس الملف بين Edge Servers.
• التحقق من استجابة 304.
• عدم استخدام ETag ضعيفة بصورة تكسر Range Requests للملفات الكبيرة.
• عدم الجمع بين Validators غير متوافقة.

سادسًا: CDN والاستهداف الجغرافي

9. وجود CDN فعالة غير مؤكد

الخطورة: مرتفعة

الجمهور المستهدف للموقع يشمل مصر ودول الخليج، وبالتالي يجب قياس الاستجابة من:

• القاهرة.
• الرياض.
• جدة.
• دبي.
• أبوظبي.
• الكويت.
• الدوحة.
• مسقط.
• أوروبا أو أمريكا لزوار البحث العالمي.

CDN تخزن أو توزع المحتوى من Edge Servers أقرب للمستخدم، ما يقلل زمن الرحلة للشبكة، ويمكنها أيضًا تقديم تحسينات مثل HTTP/2 أو HTTP/3 والضغط. (web.dev)

لا يكفي

أن يكون الدومين خلف CDN اسميًا.

يجب إثبات:

• Cache HIT بعد الطلب الأول.
• انخفاض TTFB من الخليج.
• عدم رجوع كل طلب إلى Origin.
• عمل Purge.
• ضغط الملفات.
• استمرار الموقع عند ضغط مفاجئ.
• توافر SSL عند جميع الـEdges.

10. رؤوس CDN التي يجب فحصها

قد يظهر أحد هذه الرؤوس حسب المزود:

Age

X-Cache

CF-Cache-Status

X-CDN

Server-Timing

Via

X-Served-By

الاختبار

الطلب الأول:

MISS

الطلب الثاني:

HIT

لكن لا يجب افتراض اسم المزود من Header واحدة، كما لا ينبغي إخفاء المشاكل وراء HIT إذا كانت النسخة المخزنة قديمة.

سابعًا: Cache Key وQuery Parameters

11. UTM Parameters قد تصنع آلاف نسخ Cache

قد يدخل المستخدم عبر:

/sa?utm_source=facebook

/sa?utm_source=instagram

/sa?utm_source=tiktok

إذا كانت CDN تعتبر كل Query String نسخة مستقلة، فستنشأ نسخ كثيرة من الصفحة نفسها، وينخفض Cache Hit Ratio.

المطلوب

تجاهل Parameters التسويقية داخل Cache Key:

utm_source

utm_medium

utm_campaign

utm_content

utm_term

fbclid

gclid

مع الاحتفاظ بها للتحليلات في المتصفح عند الحاجة.

لا تتجاهل

Parameters تغيّر المحتوى فعلًا، إلا بعد مراجعة دقيقة.

12. لا تستخدم Vary: Accept-Language دون داعٍ

الموقع لديه URLs مستقلة للغات:

/sa

/en/sa

لذلك لا ينبغي تقديم HTML عربية وإنجليزية من URL نفسها اعتمادًا على Accept-Language.

استخدام Vary: Accept-Language يمكن أن يصنع نسخ Cache متعددة ويعقد الفهرسة والـCDN دون حاجة. الأفضل أن تحدد URL اللغة بصورة صريحة.

Vary يجعل الـCache تفصل الاستجابات حسب Headers المذكورة فيه، ولذلك يجب استخدامه فقط عندما تؤثر Header فعلًا في الاستجابة. (developer.mozilla.org)

ثامنًا: الصور والخطوط

13. الصور تحتاج Cache طويلة مع Versioning

Cache-Control: public, max-age=31536000, immutable

بشرط أن تحمل اسمًا مثل:

bakhoor-guide.274ba9.webp

عند تعديل الصورة يُنتج اسم جديد، بدل استبدال الملف نفسه مع الاحتفاظ باسم قديم.

لا تستخدم

hero.webp

ثم تغير محتواه باستمرار بينما يحمل Cache سنة.

14. الخطوط يجب أن تكون قليلة ومستضافة بكفاءة

• استخدام WOFF2.
• Preload للخط الأساسي فقط.
• Cache طويلة.
• عدم تحميل أوزان غير مستخدمة.
• استخدام font-display: swap.
• عدم تحميل خط عربي وإنجليزي كاملًا إذا كانت الصفحة تستخدم جزءًا محدودًا.
• تجنب أكثر من مزود خطوط.

تاسعًا: Service Worker وPWA

15. لا تضف Service Worker قبل وضع سياسة تحديث واضحة

الخطورة: مرتفعة

Service Worker يمكنها جعل الموقع سريعًا أو Offline، لكنها قد تُبقي نسخة قديمة من:

• الكود.
• حالة الكوبون.
• رابط المتجر.
• شروط الدولة.
• صفحة العروض.
• JavaScript.

لا تستخدم Cache First للـHTML الحساس

Cache First

ليس مناسبًا لصفحة تقول «تم التحقق اليوم».

الاستراتيجية الأنسب

• Static Assets: Cache First.
• HTML: Network First أو Stale While Revalidate بحذر.
• حالة الكوبون: Network First.
• Offline Fallback: صفحة واضحة.
• Service Worker نفسها: no-cache.

عند إصدار جديد

• تغيير Cache Version.
• حذف Caches القديمة.
• إظهار إشعار تحديث.
• عدم إجبار المستخدم على تحديث وسط نسخ الكود.
• اختبار Offline وعودة الشبكة.

عاشرًا: Back/Forward Cache

16. يجب الحفاظ على bfcache

المستخدم قد:

1. ينسخ الكود.
2. يفتح المتجر.
3. يعود للموقع.
4. يريد رؤية الشروط مرة أخرى.

Back/Forward Cache يمكن أن يعيد الصفحة فورًا من الذاكرة، لكن بعض استخدامات unload أو سلوكيات أخرى قد تمنعها. Chrome توضح أن bfcache تحتفظ بلقطة من الصفحة لتسريع الرجوع والتنقل عبر سجل المتصفح. (developer.chrome.com)

المطلوب

• تجنب unload.
• استخدام pagehide عند الضرورة.
• عدم إغلاق Connections بصورة تمنع bfcache بلا داعٍ.
• اختبار Back من المتجر.
• التأكد أن رسالة النسخ لا تتحول إلى حالة مضللة.
• تحديث البيانات الحساسة عند pageshow إذا كانت الصفحة عادت من Cache.

الحادي عشر: ثبات النشر

17. النشر يجب أن يكون Atomic

الخطورة: مرتفعة

لا يجب رفع الملفات واحدًا واحدًا إلى Production؛ لأن الزائر قد يحصل أثناء الرفع على:

• HTML جديدة.
• JavaScript قديمة.
• CSS مفقودة.
• Chunks غير مكتملة.
• صفحة بيضاء.

التدفق الصحيح

Build كامل

↓

اختبارات تلقائية

↓

رفع إلى إصدار جديد منفصل

↓

Smoke Test

↓

تبديل Production للإصدار الجديد دفعة واحدة

↓

Purge Cache

↓

فحص

18. يجب وجود Build ID ظاهر داخليًا

مثال:

2026.07.14.3

يُعرض في:

• Footer داخلي أو Comment.
• Response Header.
• Error Logs.
• Analytics Debug.
• لوحة الإدارة.

مثال Header:

X-App-Version: 2026.07.14.3

الفائدة:

• معرفة النسخة التي شاهدها المستخدم.
• معرفة هل CDN تقدم نسخة قديمة.
• ربط الخطأ بالإصدار.
• التأكد من نجاح Rollback.

لا تعرض Commit Hash سريًا إذا كان المستودع خاصًا بطريقة قد تكشف معلومات غير لازمة؛ يمكن استخدام Build ID عام.

19. Rollback يجب أن يكون بضغطة واحدة

عند نشر إصدار يكسر:

• نسخ الكود.
• روابط المتاجر.
• القائمة.
• الصفحات الإنجليزية.
• Analytics.
• Routing.

يجب إعادة الإصدار السابق فورًا دون Build جديد.

المطلوب

• الاحتفاظ بثلاثة إصدارات سابقة على الأقل.
• Rollback موثق.
• اختبار Rollback ربع سنوي.
• Purge Cache بعد التراجع.
• فحص النسخة القديمة بعد التراجع.
• عدم إعادة قاعدة بيانات غير متوافقة دون خطة Migration.

الثاني عشر: Staging وPreview

20. يجب فصل Production عن Staging

بيئة Staging:

staging.example.com

يجب أن تكون:

• محمية بكلمة مرور أو Access Control.
• noindex.
• غير موجودة في Sitemap.
• لا ترسل بيانات إلى GA4 Production.
• لا تستخدم روابط أفلييت حقيقية دون Test Mode.
• لا ترسل رسائل تواصل حقيقية.
• لا تظهر للمستخدمين.
• لا تحتوي Secrets داخل Frontend.

مشكلة Lovable

أي Preview أو رابط تحرير يجب ألا يظهر داخل النسخة العامة، ويجب أن تكون الصلاحيات والإصدارات منفصلة.

الثالث عشر: Uptime ومراقبة الاستضافة

21. يجب مراقبة أكثر من الصفحة الرئيسية

المسارات

/

/sa

/ae

/om

/coupons

/blog/bakhoor-guide

/robots.txt

/sitemap.xml

ما يتم قياسه

• Status Code.
• زمن الاستجابة.
• Content Check.
• SSL Expiry.
• Final URL.
• DNS.
• وجود الكود.
• وجود Build ID.
• رابط المتجر الصحيح.
• نسبة أخطاء 5xx.

فترات التنبيه المقترحة

• فحص كل دقيقة أو خمس دقائق للرئيسية.
• فحص كل 15 دقيقة للصفحات المهمة.
• فحص يومي لكل الروابط.
• تنبيه بعد فشلين متتاليين لتقليل الإنذارات الوهمية.
• تصعيد إذا استمر التوقف.

الرابع عشر: Headers المقترحة

HTML

Content-Type: text/html; charset=utf-8

Cache-Control: public, max-age=0, must-revalidate

ETag: "BUILD-CONTENT-HASH"

Content-Encoding: br

Vary: Accept-Encoding

Static Assets ذات Hash

Cache-Control: public, max-age=31536000, immutable

Content-Encoding: br

Vary: Accept-Encoding

الصور الحديثة

Cache-Control: public, max-age=31536000, immutable

Content-Type: image/webp

Service Worker

Cache-Control: no-cache

Service-Worker-Allowed: /

API شخصية

Cache-Control: private, no-store

أوامر الفحص المطلوبة

الصفحة الرئيسية

curl -I https://aldakheeloudcoupon.online/

مع Brotli

curl -I \

-H "Accept-Encoding: br" \

https://aldakheeloudcoupon.online/

مع Gzip

curl -I \

-H "Accept-Encoding: gzip" \

https://aldakheeloudcoupon.online/

فحص Revalidation

curl -I https://aldakheeloudcoupon.online/

curl -I \

-H 'If-None-Match: "ETAG_VALUE"' \

https://aldakheeloudcoupon.online/

النتيجة المتوقعة عند عدم تغير المحتوى:

304 Not Modified

فحص Assets

curl -I \

https://aldakheeloudcoupon.online/assets/FILE-HASH.js

فحص Cache عبر طلبين

curl -I https://aldakheeloudcoupon.online/

curl -I https://aldakheeloudcoupon.online/

ثم مقارنة:

• Age.
• X-Cache.
• CF-Cache-Status.
• ETag.
• X-App-Version.

Checklist المرحلة 23 للمبرمج

الاستضافة وCDN

• تحديد مزود الاستضافة.
• تحديد مزود CDN.
• توثيق Origin.
• توثيق Edge Locations.
• قياس TTFB من مصر والخليج.
• التأكد من Cache HIT.
• منع رجوع كل طلب إلى Origin.
• تفعيل Origin Shield إن توفر.
• إعداد Purge.
• اختبار Purge.
• حماية Origin من الوصول المباشر عند الحاجة.
• إعداد Rate Limits معقولة.

Cache HTML

• عدم استخدام Cache سنة.
• استخدام Revalidation.
• تحديد s-maxage.
• إضافة stale-while-revalidate.
• إضافة stale-if-error عند الملاءمة.
• تحديث الكاش بعد تعديل الكوبون.
• عدم Cache صفحات شخصية.
• عدم Cache نتائج Form.
• منع اختلاف الدولة داخل Cache.
• اختبار نسخة العربية والإنجليزية.

Assets

• Content Hash لأسماء JS.
• Content Hash لأسماء CSS.
• Content Hash للصور عند Cache طويلة.
• Cache سنة للملفات غير المتغيرة.
• استخدام immutable.
• عدم تعديل ملف بالاسم القديم.
• الاحتفاظ بـChunks السابقة.
• منع 404 بعد النشر.
• تصغير CSS وJS.
• حذف Source Maps العامة غير المطلوبة.
• مراجعة حجم Bundle.
• تقسيم Chunks منطقيًا.

الضغط

• تفعيل Brotli.
• تفعيل Gzip كبديل.
• إضافة Vary: Accept-Encoding.
• ضغط HTML.
• ضغط CSS.
• ضغط JS.
• ضغط JSON.
• ضغط SVG.
• عدم ضغط WebP وAVIF مجددًا.
• فحص Content-Length.
• اختبار Safari وChrome.
• استخدام Pre-compression عند الإمكان.

Validators

• إضافة ETag مستقرة.
• اختبار 304.
• إضافة Last-Modified عند الحاجة.
• عدم تغيير ETag بلا تغير المحتوى.
• مطابقة ETag بين Edges.
• عدم إعادة Body مع 304.
• فحص Conditional Requests.
• مراقبة نسبة 304.

النشر

• Build منفصل.
• اختبارات قبل النشر.
• Atomic Deployment.
• Smoke Test.
• Build ID.
• نشر Staging أولًا.
• Approval قبل Production.
• Purge بعد النشر.
• فحص Links بعد النشر.
• الاحتفاظ بالإصدارات القديمة.
• Rollback سريع.
• اختبار Rollback.

Service Worker

• التأكد هل توجد Service Worker.
• مراجعة Cache Names.
• عدم Cache First للـHTML الحساس.
• عدم Cache حالة الكوبون طويلًا.
• حذف Caches القديمة.
• Service Worker نفسها no-cache.
• إضافة Offline Fallback.
• اختبار إصدار جديد.
• اختبار تحديث مفتوح في تبويب قديم.
• منع Loop في Reload.

المراقبة

• Uptime Monitor.
• مراقبة الصفحة الرئيسية.
• مراقبة صفحات الدول.
• مراقبة robots وSitemap.
• مراقبة SSL.
• مراقبة DNS.
• مراقبة TTFB.
• مراقبة 5xx.
• مراقبة Cache Hit Ratio.
• مراقبة Bandwidth.
• تنبيه عند إصدار قديم.
• تنبيه عند فشل Purge.

اختبارات القبول النهائية

• الصفحة تعمل عبر HTTPS.
• HTML لا تحمل Cache سنة.
• الملفات ذات Hash تحمل Cache طويلة.
• تعديل CSS ينتج اسم ملف جديدًا.
• تعديل JS ينتج اسم ملف جديدًا.
• الإصدار السابق لا يفقد Chunks الخاصة به مباشرة.
• Brotli يعمل.
• Gzip يعمل كبديل.
• Vary: Accept-Encoding موجود.
• الصور المضغوطة لا تُضغط مجددًا.
• ETag تعمل.
• إعادة الطلب تعيد 304 عند عدم التغيير.
• CDN تعيد HIT بعد الطلب الأول.
• تعديل حالة الكوبون يظهر فور Purge.
• UTM لا تنشئ Cache منفصلة بلا داعٍ.
• /sa و/en/sa لا تختلطان في Cache.
• Service Worker لا تعرض حالة قديمة.
• Back من المتجر يعيد الصفحة بسرعة.
• النشر Atomic.
• Rollback ناجح.
• Staging غير مفهرسة.
• Production لا تعرض Preview Badge.
• Uptime Monitoring ترسل تنبيهًا.
• Build ID يطابق الإصدار الحالي.

الحكم النهائي للمرحلة 23

المشكلة الأساسية ليست إثبات أن الموقع بطيء، بل أنه لا توجد أمامنا حتى الآن سياسة Cache ونشر قابلة للتدقيق.

ترتيب التنفيذ

1. استخراج جميع Response Headers.
2. منع Cache الطويلة عن HTML وحالة الكوبون.
3. استخدام ملفات JS وCSS تحمل Content Hash.
4. تطبيق Cache سنة وimmutable على Assets فقط.
5. تفعيل Brotli مع Gzip بديلًا.
6. إضافة Vary: Accept-Encoding.
7. دعم ETag و304.
8. تحديد مزود CDN وقياسه من مصر والخليج.
9. إنشاء Purge تلقائي عند تحديث الكود.
10. منع Query Parameters التسويقية من تفتيت Cache.
11. مراجعة أي Service Worker وإلغاء تخزين المحتوى الحساس طويلًا.
12. تطبيق Atomic Deployment.
13. الاحتفاظ بإصدارات سابقة ودعم Rollback.
14. وضع Build ID داخل الاستجابة.
15. تفعيل Uptime وSSL وCache Monitoring.

اكتب كمل للانتقال إلى المرحلة 24: مراجعة البريد الإلكتروني والدومين وDNS وSPF وDKIM وDMARC وتسليم رسائل التواصل ومنع الانتحال والرسائل المزعجة.

Worked for 1m 3s

المرحلة 30 من 30: التقييم النهائي الشامل وخطة الإصلاح

النتيجة النهائية

34 من 100

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

المشكلة ليست في شكل الموقع فقط؛ بل في أن أهم وعد يقدمه للمستخدم — أن wc4 رسمي ومضمون ويعمل على كل المنتجات والدول — غير مدعوم بسجل اختبار واضح.

توزيع الدرجة

لماذا حصل الموقع على 34 وليس صفرًا؟

توجد نقاط يمكن البناء عليها:

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

لكن هذه النقاط لا تعوض مشكلات الثقة، الروابط، الادعاءات، التحقق، وإدارة الموقع.

لماذا لم يحصل الموقع على درجة أعلى؟

1. تناقض قانوني وثقة واضح

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

هذا هو أخطر تناقض في الموقع كله.

2. ادعاءات كبيرة بلا إثبات ظاهر

الصفحة الرئيسية تعرض:

• أكثر من 50 ألف عميل سعيد.
• تفعيل بنسبة 100%.
• متابعة على مدار الساعة.
• صالح طوال 2026.
• بلا حد أدنى.
• يعمل على كل المنتجات.
• تم التحقق اليوم.
• كود مضمون ورسمي.

ولا تعرض:

• قيمة الخصم الفعلية.
• نتيجة سلة قبل وبعد.
• المنتج المختبر.
• نوع الحساب.
• الدولة التي تم فيها الاختبار.
• وقت الاختبار.
• رسالة نجاح المتجر.
• دليل أو Screenshot منقح.

3. روابط الدول لا تخضع لنظام موثوق

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

4. الصفحة الإنجليزية غير مكتملة فعليًا

صفحة الإمارات الإنجليزية تعرض قائمتين عربيتين متكررتين، مع أزرار وشارات عربية داخل المحتوى الإنجليزي. كما تصف الكوبون بأنه Official وتقول إنه يعمل في السعودية والإمارات ومصر والخليج.

5. الموقع ما زال يحمل علامات نسخة بناء غير نهائية

يظهر Edit with Lovable في الصفحة الرئيسية، والخصوصية، والشروط، وصفحة من نحن، وصفحة التواصل. كما تعرض صفحة من نحن رقم هاتف تجريبيًا +20 100 000 0000.

6. العروض الموسمية تُعرض بلا إدارة زمنية دقيقة

صفحة العروض تجمع «عرض اليوم» مع رمضان والعيد واليوم الوطني والجمعة البيضاء، وتقول إن القائمة محدثة وإن wc4 يمنح خصمًا إضافيًا، دون توثيق الحالة الحالية لكل عرض.

7. المقارنات تبدو تسويقية أكثر من كونها موضوعية

صفحة المقارنة مع العربية للعود تصف المقارنة بأنها موضوعية، ثم تنتهي بأن الدخيل هو الخيار الأوفر بسبب wc4، دون عرض مصادر أسعار أو منهجية اختبار أو إفصاح واضح عن العلاقة المالية.

الحكم التنفيذي النهائي

هل الموقع صالح للنشر؟

صالح كنسخة تجريبية فقط.

هل يصلح لجلب زيارات SEO الآن؟

يمكن أن يحصل على زيارات، لكن توسيع المحتوى قبل معالجة الأساس سيزيد:

• الصفحات المتعارضة.
• الادعاءات غير الموثقة.
• الروابط المكسورة.
• Cannibalization.
• المخاطر القانونية.
• صعوبة تحديث حالة الكوبون.

هل يصلح لإعلانات مدفوعة؟

لا أنصح بذلك حاليًا.

إرسال زيارات مدفوعة قبل إصلاح رابط الدولة، وتأكيد الكود، وإزالة الادعاءات المضللة سيؤدي إلى تكلفة دون تحويلات موثوقة وقد يسبب بلاغات أو فقدان ثقة.

هل يجب حذف الموقع وإعادة بنائه من الصفر؟

لا يلزم حذف المشروع بالكامل، لكن يجب إعادة بناء قلب الموقع:

• بيانات الكوبون.
• الروابط.
• الصفحة الرئيسية.
• صفحات الدول.
• الهوية القانونية.
• نظام التحقق.
• إدارة المحتوى.
• الاختبارات والمراقبة.

الأخطاء الحرجة P0 — تُصلح قبل أي توسع

ما يجب حذفه فورًا من الموقع

• «الموقع الرسمي لكوبونات Al Dakheel Oud».
• «كود رسمي».
• «مضمون التطبيق».
• «100% كود مفعّل».
• «+50K عميل سعيد».
• «متابعة الصلاحية 24/7» دون نظام موثق.
• «تم التحقق اليوم» إذا لم يُنفذ اختبار اليوم.
• «ساري طوال 2026».
• «بدون حد أدنى».
• «يعمل على كل المنتجات».
• «كل دول الخليج».
• تقييم 4.9/5 بلا مصدر.
• «الأشهر» و«الأكثر مبيعًا» بلا بيانات.
• العداد 00:00:00.
• Edit with Lovable.
• رقم الهاتف التجريبي.
• «متاجر شريكة» إذا لا توجد شراكة تعاقدية.
• المقارنات السعرية غير الموثقة.
• صفحات الدول غير المكتملة.
• FAQ بلا إجابات كاملة.

ما يمكن الاحتفاظ به بعد المراجعة

• الدومين، بشرط مراجعة استخدام العلامة قانونيًا.
• التصميم العام البسيط.
• بطاقة الكود بعد إعادة صياغتها.
• صفحات السعودية والإمارات وعُمان بعد ربطها بالمتاجر الصحيحة.
• المقالات التعليمية الأصلية بعد مراجعة المصادر والسلامة.
• صفحة الخصوصية والشروط كأساس لإعادة الكتابة.
• بريد info@wemarketing4u.com إذا كان يعمل ومصادقًا.
• هيكل الفئات والروابط الداخلية بعد إزالة التكرار.
• فكرة وجود نسخة عربية وإنجليزية بعد ترجمة القالب بالكامل.

نموذج بطاقة الكوبون النهائية

كوبون الدخيل للعود

wc4

الحالة:

يحتاج إلى إعادة اختبار

آخر اختبار ناجح:

غير متوفر حاليًا

الدول التي تم التحقق منها:

لم تُنشر نتائج موثقة بعد

قيمة الخصم:

تظهر داخل السلة حسب المنتج والحساب

مهم:

تأكد من ظهور الخصم قبل الدفع، فقد تختلف الشروط حسب الدولة والمنتجات والعروض.

[ نسخ الكود ]

[ فتح متجر الدولة ]

[ الإبلاغ عن مشكلة ]

بعد تنفيذ اختبار حقيقي يمكن استبدال البيانات بالقيم الدقيقة.

الهيكل المقترح للموقع

الصفحات الأساسية

/

/sa

/ae

/om

/en

/en/sa

/en/ae

/coupon/wc4

/offers

/blog

/about

/contact

/privacy

/terms

/affiliate-disclosure

لا تُنشأ صفحة دولة جديدة إلا بعد:

• توثيق المتجر المحلي.
• توثيق العملة.
• اختبار رابط المتجر.
• اختبار الكوبون.
• كتابة محتوى محلي.
• إضافة Canonical وHreflang.
• نجاح الاختبارات الآلية.

خطة الإصلاح خلال 7 أيام

اليوم الأول: إيقاف المخاطر

• حذف «رسمي» و«مضمون» وكل الإحصاءات غير الموثقة.
• حذف العداد.
• حذف Edit with Lovable.
• إزالة رقم الهاتف التجريبي.
• إخفاء الدول غير المكتملة.
• وضع Disclaimer ظاهر في أول الشاشة.
• تجميد نشر مقالات جديدة.

معيار القبول

لا يبقى في Production أي ادعاء غير قابل للإثبات.

اليوم الثاني: إصلاح روابط الدول

• إنشاء خريطة Store Domains مركزية.
• السعودية → المتجر السعودي.
• الإمارات → المتجر الإماراتي.
• عُمان → المتجر العُماني.
• تعطيل CTA لأي دولة غير موثقة.
• فحص Final URL.
• إضافة اختبار آلي لكل دولة.

معيار القبول

لا يمكن لصفحة دولة أن تفتح متجر دولة أخرى.

اليوم الثالث: اختبار wc4

إجراء اختبار يدوي موثق دون إكمال شراء:

• السعودية.
• الإمارات.
• عُمان.
• مستخدم Guest.
• مستخدم جديد وحالي إن كان ذلك مسموحًا.
• منتج كامل السعر.
• منتج مخفض.
• سلة منخفضة ومتوسطة.
• تسجيل رسالة المتجر.
• تسجيل قيمة الخصم.
• حفظ دليل منقح.

معيار القبول

لا تظهر حالة Verified إلا إذا وُجد Evidence ID.

اليوم الرابع: إعادة بناء الصفحة الرئيسية

• H1 واضح.
• Disclaimer واضح.
• بطاقة كوبون واحدة.
• عرض الدولة قبل فتح المتجر.
• آخر اختبار حقيقي.
• شروط معروفة وغير معروفة.
• إزالة التكرار والإلحاح المصطنع.
• FAQ كاملة.
• CTA واحدة رئيسية.

معيار القبول

يستطيع المستخدم فهم استقلال الموقع وشروط الكود قبل الضغط على الرابط.

اليوم الخامس: Technical SEO

• فحص Robots.
• Sitemap صحيحة.
• Canonical لكل صفحة.
• Hreflang متبادل.
• حذف URLs المكسورة.
• Titles وDescriptions فريدة.
• Schema صادقة.
• 404 مخصصة.
• Redirects سليمة.
• حذف الصفحات غير المكتملة من Sitemap.

معيار القبول

لا توجد URL داخل Sitemap تعيد 404 أو تحمل noindex.

اليوم السادس: الخصوصية والأمان وإمكانية الوصول

• إعادة كتابة الخصوصية.
• إضافة Affiliate Disclosure عند الحاجة.
• إضافة Cookie Consent حقيقية عند وجوبها.
• إنشاء نموذج تواصل آمن أو حذف ذكره من السياسة.
• إصلاح Keyboard Navigation.
• Labels وFocus.
• تحسين التباين.
• إضافة Error Boundary.
• تفعيل MFA للحسابات.

معيار القبول

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

اليوم السابع: الاختبار وإعادة الإطلاق

• Playwright على Chromium وFirefox وWebKit.
• اختبار الهاتف.
• اختبار النسخ.
• اختبار الروابط.
• Link Checker.
• Accessibility Scan.
• Lighthouse.
• فحص Console.
• فحص Analytics.
• Smoke Test على Production.
• إعداد Rollback.

معيار القبول

كل الاختبارات الحرجة خضراء قبل إعادة فتح التوسع أو الإعلانات.

خطة 30 يومًا

الأسبوع الأول

تنفيذ خطة الأيام السبعة السابقة وإطلاق نسخة نظيفة ومحدودة الدول.

الأسبوع الثاني

• بناء قاعدة بيانات مركزية للكوبون.
• فصل حالة كل دولة.
• إنشاء سجل اختبارات.
• إنشاء مصدر واحد للروابط.
• إضافة حالات:
  • Verified.
  • Limited.
  • Needs Retest.
  • Failed.
  • Unknown.
• إنشاء Version History.
• إنشاء Audit Log.

الأسبوع الثالث

• إنشاء لوحة إدارة بصلاحيات.
• فصل المحرر عن المختبر والناشر.
• Soft Delete.
• موافقات قبل النشر.
• Translation Status.
• إنشاء Staging.
• حماية فرع Production.
• CI/CD واختبارات Regression.

الأسبوع الرابع

• تركيب Uptime Monitoring.
• Error Tracking.
• Source Maps.
• Dashboard.
• Alerts.
• قياس Funnel:
  • عرض الكود.
  • محاولة النسخ.
  • نجاح النسخ.
  • اختيار الدولة.
  • فتح المتجر.
  • بلاغ فشل.
• مراجعة قانونية للعلامة والأفلييت والخصوصية.
• مراجعة تراخيص الصور.

خطة 90 يومًا

الشهر الأول: تأسيس الثقة

• إزالة الادعاءات المضللة.
• اختبار الكوبون.
• توثيق الدول.
• إصلاح Technical SEO.
• إطلاق لوحة إدارة.
• تطبيق Analytics وMonitoring.

الشهر الثاني: تحسين الجودة والنمو

• كتابة محتوى أصلي لكل دولة.
• تحديث المقالات التعليمية.
• بناء Topic Clusters حقيقية.
• إضافة خبرات ومصادر ومراجعين.
• تحسين Core Web Vitals.
• تحسين Accessibility.
• إعداد تقارير أداء أسبوعية.
• بدء Outreach قانوني للحصول على علاقة أو تصريح رسمي إن كان ممكنًا.

الشهر الثالث: التوسع المنضبط

• إضافة دولة جديدة فقط بعد التحقق.
• تجربة A/B للبطاقة والعناوين دون ادعاءات مصطنعة.
• بناء صفحات عروض مرتبطة بتواريخ فعلية.
• إضافة سجل حالة عام للكوبون.
• بناء نظام بلاغات المستخدمين.
• تحليل Conversion حسب الدولة.
• تحسين المحتوى بناءً على Search Console.
• إجراء Disaster Recovery وRollback Drill.
• مراجعة أمنية وقانونية نهائية.

الأولويات حسب المسؤول

المبرمج

• إصلاح الروابط.
• إزالة التكرار.
• إزالة Lovable Badge.
• بناء مصدر بيانات مركزي.
• Error Handling.
• CI/CD.
• الاختبارات.
• Monitoring.
• Cache وCDN.
• قاعدة البيانات والصلاحيات.

مسؤول المحتوى وSEO

• حذف الادعاءات غير الموثقة.
• مراجعة Titles وDescriptions.
• توحيد الصفحات والدول.
• إصلاح FAQ.
• إعادة كتابة المقارنات.
• إضافة مصادر.
• التخلص من المحتوى المتكرر والضعيف.
• بناء خطة تحديث فعلية.

مختبر الكوبون

• اختبار كل دولة منفصلة.
• تسجيل المنتجات والحساب والسلة.
• تسجيل قيمة الخصم.
• حفظ رسالة المتجر.
• تصنيف الفشل.
• إعادة الاختبار دوريًا.
• عدم تعميم النتائج.

المسؤول القانوني

• مراجعة اسم الدومين والعلامة.
• مراجعة الصور والشعارات.
• تأكيد علاقة الأفلييت.
• صياغة الإفصاح.
• إعادة كتابة الخصوصية والشروط.
• تحديد الجهة القانونية.
• مراجعة قوانين الدول المستهدفة.

إدارة المشروع

• تحديد Owner لكل خطأ.
• تحديد موعد نهائي.
• منع النشر المباشر.
• تفعيل MFA.
• مراجعة الصلاحيات.
• اعتماد خطة Rollback.
• متابعة مؤشرات الأداء.

KPIs بعد الإصلاح

الثقة

• صفر ادعاءات غير موثقة.
• صفر صفحات تصف الموقع بأنه رسمي.
• 100% من الكوبونات النشطة لها دليل حديث.
• 100% من الدول المنشورة لها متجر محلي موثق.

التقنية

• صفر روابط داخلية 404.
• صفر اختلاف بين دولة الصفحة ودولة المتجر.
• صفر أخطاء Console حرجة.
• Zero duplicated primary navigation.
• نجاح E2E على المتصفحات الثلاثة.

SEO

• 100% من الصفحات القابلة للفهرسة لها Canonical.
• 100% من Hreflang متبادلة وصحيحة.
• Sitemap بلا صفحات خطأ.
• عناوين ووصف فريدان.
• إزالة المحتوى الضعيف والمتكرر.

التحويل

• قياس coupon_copy_attempt.
• قياس coupon_copy_success.
• قياس store_outbound_click.
• قياس country_selected.
• قياس coupon_failure_report.
• خفض Store Country Mismatch إلى صفر.

التشغيل

• توفر لا يقل عن 99.9% للصفحات الأساسية.
• تنبيه خلال دقائق عند تعطل الصفحة.
• اكتشاف الخطأ قبل بلاغ المستخدم.
• Rollback مجربة.
• Backup قابلة للاستعادة.

Checklist الإطلاق النهائي

لا تعِد فتح التوسع قبل نجاح جميع النقاط التالية

• حذف جميع الادعاءات الرسمية غير المثبتة.
• حذف الإحصاءات الوهمية.
• حذف العداد.
• إزالة Edit with Lovable.
• إزالة رقم الهاتف التجريبي.
• Disclaimer ظاهرة.
• Affiliate Disclosure واضحة عند الحاجة.
• اختبار wc4 موثق.
• قيمة الخصم أو حالة عدم معرفتها ظاهرة.
• السعودية مرتبطة بالسعودية.
• الإمارات مرتبطة بالإمارات.
• عُمان مرتبطة بعُمان.
• إخفاء الدول غير المكتملة.
• القائمة غير مكررة.
• الإنجليزية كاملة.
• 404 مخصصة.
• Sitemap نظيفة.
• Canonical صحيحة.
• Hreflang صحيحة.
• Schema غير مضللة.
• الخصوصية تطابق الأدوات.
• نموذج التواصل يعمل أو تمت إزالة ذكره.
• Cookie Consent صحيحة.
• الصور لها تراخيص.
• الحسابات محمية بـMFA.
• Staging منفصلة.
• Branch Protection مفعلة.
• Playwright تنجح.
• Link Checker تنجح.
• Accessibility Gate تنجح.
• Error Tracking تعمل.
• Uptime Monitoring تعمل.
• Rollback مجربة.
• مراجعة قانونية مكتملة.

التقييم المتوقع بعد الإصلاح

الوصول إلى أكثر من 90 يتطلب:

• توثيقًا حقيقيًا للكوبون.
• تجربة دولة دقيقة.
• بنية بيانات واختبارات قوية.
• محتوى أصلي بخبرة واضحة.
• سرعة وإمكانية وصول ممتازتين.
• مراجعة قانونية وعلاقة أفلييت شفافة.
• تشغيل ومراقبة مستمرين.

الخلاصة النهائية بعد 30 مرحلة

الموقع لديه فكرة قابلة للنجاح، لكنه يحاول حاليًا تعويض غياب الإثبات بكثرة العبارات التسويقية.

أكبر ثلاثة أخطاء هي:

1. تقديم موقع مستقل وكود غير موثق على أنهما رسميان ومضمونان.
2. تعميم الكود والروابط على دول ومنتجات وحسابات دون اختبارات منفصلة.
3. غياب منظومة احترافية لإدارة البيانات والمراجعة والاختبار والمراقبة.

القرار الصحيح ليس إضافة مقالات أكثر الآن، بل:

إيقاف التوسع، تنظيف الادعاءات، إصلاح رحلة الدولة والمتجر، اختبار wc4 فعليًا، ثم إعادة إطلاق نسخة محدودة وصادقة وقابلة للقياس.

انتهت المراجعة الكاملة للموقع على 30 مرحلة.