في موسم الجمعة البيضاء، قد يغير المتجر السعودي أسعار مئات المنتجات خلال ساعات قليلة. تظهر التخفيضات للزائر بصورة صحيحة، لكن Google يقرأ سعرًا قديمًا من البيانات المنظمة، أو يجد منتجًا معلنًا أنه متوفر رغم نفاد مخزونه. عندها تصبح المشكلة أكبر من مجرد كود، لأنها تمس دقة المعلومات التي يقدمها المتجر لمحركات البحث.
تعتمد Schema الجمعة البيضاء الجيدة على وصف المنتج الحقيقي وسعره النشط وتوفره، دون مبالغة في التقييمات أو وعود بنتائج غنية مضمونة. نشرح هنا الفرق بين Product وOffer، وطريقة توثيق السعر المخفض داخل JSON-LD، وأخطاء الصفحات الموسمية. وسنوضح كذلك لماذا لا ينبغي التعامل مع FAQ كما كانت تُعامل في أدلة SEO القديمة.
ما وظيفة البيانات المنظمة في صفحات عروض الجمعة البيضاء؟
البيانات المنظمة أو Structured Data معلومات مكتوبة بتنسيق تفهمه الأنظمة الآلية، وغالبًا بصيغة JSON-LD. تساعد محرك البحث على معرفة أن الصفحة تتحدث عن منتج معين، وما اسمه وسعره وحالته. وقد تجعل صفحة المنتج مؤهلة لبعض تجارب النتائج الغنية، لكن ظهور تلك العناصر يخضع لقرار Google ولا يضمنه اجتياز الاختبار التقني.
لا تعوض Schema وصف المنتج الضعيف أو السعر الخاطئ. فإذا لم يتمكن العميل من شراء السلعة بالقيمة المكتوبة، فإن إضافة مزيد من الحقول لن تحل المشكلة. ولهذا ينبغي ربط البيانات المنظمة بمصدر بيانات المتجر نفسه، وليس بنص ترويجي يكتبه محرر المحتوى يدويًا عند كل موسم.
اختر نوع Schema وفق الصفحة وليس وفق اسم المناسبة
صفحة العروض المركزية ليست صفحة منتج واحد. قد تجمع أجهزة وعطورًا وملابس بأسعار مختلفة، ولذلك لا يصح نسخ Product واحد عليها ووضع أقل سعر بين جميع المنتجات. الأفضل أن يكون لكل منتج مؤهل ترميزه الصحيح داخل صفحته، وأن تخدم صفحة التجميع الزائر بعناوين وروابط وفئات واضحة.
| نوع الصفحة | الترميز الأنسب غالبًا | الخطأ الذي يجب تجنبه |
|---|---|---|
| منتج قابل للشراء | Product يتضمن Offer | سعر أو مخزون غير مطابق |
| منتج بمتغيرات | ProductGroup مع Product للمتغيرات عند الحاجة | اعتبار كل المقاسات عرضًا واحدًا |
| صفحة عروض تجمع منتجات | بيانات الصفحة والتنقل المناسبة | اختراع منتج يمثل جميع العروض |
| مقال أو دليل شراء | ترميز يتناسب مع محتوى المقال | إضافة بيانات بيع لا تظهر للزائر |
تشرح مقالة الصقر عن الصفحة المركزية للجمعة البيضاء دور صفحة التجميع وروابط الفئات. أما بيانات السعر الدقيق فيجب أن ترتبط بالمنتج الذي يستطيع العميل شراؤه بالفعل.
ما الحقول المهمة في Product Schema؟
ابدأ باسم المنتج name وصورته image ووصفه description، ثم أضف المعرفات الصحيحة مثل SKU أو GTIN إن كانت موجودة فعلًا. ويمكن تحديد العلامة التجارية عبر brand عندما تنطبق. لا تخترع معرفًا عالميًا أو علامة تجارية لمجرد التخلص من تحذير أداة الفحص.
إذا كانت الصفحة تبيع المنتج مباشرة، فإن معلومات offers ضرورية لتجارب بيانات التاجر التي تدعمها Google. ويجب إرسال السعر الحالي والعملة، مع استحسان وصف التوفر وحالة المنتج. للمزيد عن أنواع البيانات المنظمة واستخداماتها في المواقع السعودية، راجع دليل الصقر العام لـSchema Markup.
Offer Schema: ما السعر الذي يجب تسجيله أثناء التخفيض؟
يمثل Offer عرض بيع مرتبطًا بمنتج. وخلال الجمعة البيضاء ينبغي أن يعبر price عن السعر النشط الذي يستطيع المستهلك دفعه، لا السعر السابق المشطوب. وفي متجر سعودي يعرض الأسعار بالريال يمكن استخدام priceCurrency بقيمة SAR. ويجب أن تكون القيمة متسقة مع ما يظهر للعميل ومع طريقة عرض الضريبة في المتجر.
إذا كان السعر العادي 300 ريال، وأصبح السعر الترويجي 240 ريالًا، تستطيع تحديد 240 في offers.price، وإضافة السعر الأصلي ضمن UnitPriceSpecification مع priceType بقيمة StrikethroughPrice. لا تضع السعرين باعتبارهما سعرين نشطين متنافسين، ولا تستخدم سعرًا أصليًا غير حقيقي لصناعة نسبة خصم أكبر.
مثال JSON-LD لمنتج مخفض في الجمعة البيضاء
المثال التالي توضيحي، ويصف متجرًا ومنتجًا افتراضيين خلال فترة تشغيل العرض. يعرض المقال الشيفرة للقارئ، ولا يضيفها تلقائيًا إلى موقعه. يجب على المطور توليد القيم من قاعدة بيانات المنتجات واستبدال روابط المثال قبل اعتمادها.
{
"@context": "https://schema.org",
"@type": "Product",
"name": "ماكينة قهوة منزلية - مثال تجريبي",
"description": "ماكينة قهوة منزلية بمواصفات تجريبية",
"image": "https://example.com/images/coffee.jpg",
"sku": "COF-100",
"offers": {
"@type": "Offer",
"url": "https://example.com/products/coffee",
"priceCurrency": "SAR",
"price": 240,
"availability": "https://schema.org/InStock",
"itemCondition": "https://schema.org/NewCondition",
"validFrom": "2026-11-27T00:00:00+03:00",
"priceValidUntil": "2026-11-30T23:59:59+03:00",
"priceSpecification": {
"@type": "UnitPriceSpecification",
"priceType": "https://schema.org/StrikethroughPrice",
"price": 300,
"priceCurrency": "SAR"
}
}
}
عند التنفيذ الحقيقي، يوضع كائن JSON-LD داخل عنصر script من النوع application/ld+json بواسطة القالب أو تكامل موثوق. والأهم ألا ينشر المتجر السعر الترويجي في Schema قبل بدء البيع به، وألا يتركه بعد انتهاء العرض. توضح وثائق Google لبيانات التاجر مواصفات الأسعار النشطة والمشطوبة والتواريخ.
اضبط موعد الخصم والتوقيت السعودي بدقة
توافق الجمعة البيضاء في 2026 يوم 27 نوفمبر. إذا بدأ العرض عند منتصف الليل بتوقيت الرياض، فيجب أن تعكس مواعيد validFrom وpriceValidUntil الفترة الحقيقية. لا تخلط بين توقيت الخادم وتوقيت السعودية، ولا تفترض أن إدخال تاريخ دون ساعة يناسب عروضًا تبدأ في وقت محدد.
اختبر الانتقال بين السعرين قبل الموسم في بيئة تجريبية. ينبغي أن تتغير واجهة المنتج والبيانات المنظمة والخلاصة التجارية معًا أو ضمن دورة تحديث مضبوطة. ويجب مراجعة ذاكرة التخزين المؤقت حتى لا تعرض Google نسخة قديمة بينما يرى العميل سعرًا جديدًا.
كيف تتعامل مع متغيرات المقاس واللون؟
إذا كان المنتج يباع بأحجام وأسعار مختلفة، فلا تستخدم أقل سعر متاح لوصف متغير لا يستطيع العميل اختياره من الصفحة الحالية. تدعم Google استخدام ProductGroup مع hasVariant وvariesBy لتعريف العلاقة بين المتغيرات. ويحتاج كل متغير إلى معرف مناسب وبيانات سعر وتوفر تخصه.
قد تعرض صفحة واحدة جميع المقاسات، أو تقدم رابطًا مستقلًا لكل لون. يجب أن يتفق ترميز المتغيرات مع هذه البنية، بما يشمل الروابط القياسية وإمكانية اختيار المتغير مباشرة. ولا تستخدم AggregateOffer لتجميع مقاسات المنتج؛ فله استخدام مختلف عند تجميع عروض متعددة للمنتج نفسه.
ما العلاقة بين Schema وخلاصة Merchant Center؟
قد يستقبل Google بيانات المنتج من الموقع ومن خلاصة Merchant Center. كل مصدر يقدم معلومات مفيدة، لكن التعارض بينهما يضعف موثوقية السعر والتوفر. لذلك راجع هوية المنتج ومعرفه وحالته والقيمة الظاهرة في الصفحة، خصوصًا عندما تتغير التخفيضات والمخزونات خلال دقائق.
إذا كانت بيانات الكتالوج تُحدث كل عدة ساعات، بينما يتغير السعر فورًا في الموقع، فقد تظهر اختلافات مؤقتة تحتاج معالجة. لا تعتمد على البيانات المنظمة وحدها لإصلاح خلاصة خاطئة، ولا تعتبر اعتماد المنتج في Merchant Center ضمانًا لظهور نتيجة غنية في البحث.
FAQ في 2026: هل ما زالت الأسئلة الشائعة تصنع نتائج غنية؟
هذا من أهم التحديثات التي ينبغي الانتباه إليها. أوقفت Google عرض نتائج FAQ الغنية اعتبارًا من 7 مايو 2026، ثم أزالت وثائق الميزة في يونيو. لذلك فإن إضافة FAQPage إلى صفحة عروض تجارية لا تمنحها الآن صندوق أسئلة موسعًا في نتائج Google، حتى لو كانت الشيفرة صحيحة من ناحية مفردات Schema.org.
مع ذلك، تظل الأسئلة الواضحة مفيدة للمتسوق. اشرح مدة العرض وسياسة الاستبدال والشحن وشروط استخدام الكوبون في محتوى ظاهر. يمكن الاحتفاظ بترميز FAQ لأغراض أخرى عند وجود حاجة محددة، لكن لا تجعل إنتاجه أولوية SEO على حساب تحديث السعر والمخزون. ولا تستبدل FAQPage بترميز QAPage لمجرد استعادة المظهر؛ فهذا النوع مخصص لسياق مختلف.
لا تختلق التقييمات للحصول على النجوم
قد تضيف بعض القوالب aggregateRating تلقائيًا إلى كل منتج. يجب أن تستند التقييمات إلى مراجعات حقيقية للسلعة المعنية، وأن تكون المعلومات متوافقة مع ما يستطيع الزائر الاطلاع عليه. لا تضع خمس نجوم افتراضية أو تنقل متوسط تقييم متجر كامل إلى منتج لم يحصل على مراجعات.
وإذا لم توجد تقييمات حقيقية، يمكن أن تظل معلومات المنتج والسعر صحيحة دون إضافتها. اجتياز الاختبار الفني لا يجعل البيانات المضللة مقبولة؛ إذ تضع Google قواعد جودة تتجاوز مجرد صحة بناء JSON.
WordPress وWooCommerce: امنع تضارب مصادر Schema
قد ينشئ WooCommerce بيانات منتج منظمة، بينما تضيف إضافة SEO أو إضافة مخطط أخرى ترميزًا للمنتج نفسه. قبل إدخال كود يدوي، افحص مصدر الصفحة والبيانات المستخرجة في أداة اختبار النتائج الغنية. لا تحذف أحد المصادر عشوائيًا؛ بل حدد مالك بيانات المنتج وكيف تتحدث الأسعار والمخزونات.
من الأفضل أن تولد البيانات من مصدر موحد، مع اختبار القالب والإضافات عند كل تحديث مؤثر. وينطبق المبدأ على سلة وزد وشوبيفاي، مع اختلاف مستوى التحكم المتاح للمطور. ولرؤية دور Schema ضمن استراتيجية أوسع، اطلع على استراتيجية SEO للمتاجر الإلكترونية الكبيرة لدى الصقر.
اختبر البيانات المنظمة قبل إطلاق إعلانات الجمعة البيضاء
استخدم اختبار النتائج الغنية من Google للتحقق من الأنواع المدعومة والحقول المطلوبة. ثم افحص صفحة منشورة عبر URL Inspection في Search Console، لأن الشيفرة التي تعمل في بيئة المطور قد تختلف عن الصفحة التي يستطيع Google جلبها فعلًا.
راجع التحذيرات والأخطاء كلًا على حدة. فقد يكون الحقل موصى به دون أن يكون إلزاميًا. والأهم مقارنة النص المعروض بالسعر والعملة والتوفر وتاريخ الخصم. اختبر منتجًا مخفضًا وآخر بسعر عادي ومنتجًا نافد المخزون ومتغيرًا بمقاسين مختلفين، بدل فحص صفحة واحدة ثم تعميم النتيجة.
جدول مراجعة مختصر قبل النشر
| الاختبار | ما الذي ينبغي التأكد منه؟ |
|---|---|
| Product | الاسم والصورة والمعرف تخص المنتج المعروض |
| Offer | السعر النشط والعملة يطابقان صفحة الشراء |
| التوفر | حالة InStock أو OutOfStock مطابقة للمخزون |
| التواريخ | بداية العرض ونهايته صحيحتان بتوقيت السعودية |
| المتغيرات | كل لون أو مقاس له بيانات مناسبة |
| FAQ | الأسئلة واضحة للمستخدم دون توقع نتيجة غنية |
| التكرار | لا توجد مخططات متعارضة من إضافات متعددة |
أخطاء شائعة في Schema الجمعة البيضاء
من الأخطاء ترك priceValidUntil بتاريخ منتهٍ، أو إرسال سعر سابق في offers.price بعد بدء الخصم. وقد تظهر مشكلة أخرى عندما يظل المنتج متاحًا في JSON-LD رغم نفاده. وهذه أخطاء تتعلق بالمزامنة، لا بالصياغة البرمجية فحسب.
كذلك تجنب وضع ترميز منتج واحد على صفحة تجمع عشرات السلع، أو استخدام AggregateOffer لمتغيرات المقاس، أو إضافة تقييمات مختلقة. وإذا أظهر اختبار النتائج الغنية أهلية الصفحة، فلا تعتبر ذلك وعدًا بظهورها بالشكل نفسه عند كل مستخدم.
خطة تنفيذ خلال نوفمبر 2026
في الأسبوع الأول، احصر قوالب المنتجات وأنواع البيانات المنظمة الموجودة بالفعل. ثم حدد المنتجات المشاركة في الجمعة البيضاء وأصل أسعارها ومصادر حالة المخزون. في الأسبوع الثاني، اضبط نموذج Product وOffer واختبر المزامنة مع متجر التجربة وخلاصة المنتجات.
خلال الأيام السابقة ليوم 27 نوفمبر، اختبر تفعيل الخصم وانتهاءه في الوقت المقرر، وافحص عينات من المنتجات بعد نشر التغييرات. أثناء الموسم راقب الأسعار والمخزون والتقارير الفنية، ثم أزل البيانات الترويجية المنتهية بعد نهاية العرض دون حذف معلومات المنتج الصحيحة.
أسئلة شائعة عن Schema الجمعة البيضاء
هل أضع Product Schema في صفحة تجمع جميع العروض؟
لا تنسخ بيانات منتج واحد لتصف جميع السلع. اجعل ترميز المنتج المفصل في صفحة المنتج المناسبة، واختر للصفحة المركزية ما يعكس محتواها ووظيفتها الحقيقيين.
هل يؤدي Offer Schema إلى ظهور نسبة الخصم تلقائيًا؟
لا. قد يساعد الترميز Google على فهم السعر النشط والسابق، لكن شكل النتيجة يخضع لشروط عرض أخرى ولا يمكن ضمان ظهور شارة تخفيض.
هل أحتاج FAQPage لكي تظهر الأسئلة في Google؟
لم تعد Google تعرض نتائج FAQ الغنية منذ مايو 2026. يمكنك نشر أسئلة مفيدة للعميل داخل الصفحة دون التعويل على هذا النوع من النتائج.
هل تكفي أداة فحص واحدة لإعلان اكتمال التنفيذ؟
لا. اختبر الشيفرة والصفحة المنشورة، ثم تحقق من السعر الفعلي والمخزون وأثر تغيير العروض. الاختبار الفني خطوة مهمة، لكنه لا يثبت أن البيانات تظل محدثة طوال الموسم.
الخلاصة: البيانات المنظمة الدقيقة أفضل من مخططات كثيرة
تنجح Schema الجمعة البيضاء عندما تصف منتجات يمكن شراؤها فعلًا بالسعر المعلن. استخدم Product لتعريف السلعة وOffer لسعرها وتوفرها، واضبط التوقيت والمتغيرات من مصدر بيانات موثوق. واحتفظ بالأسئلة الشائعة لتوضيح شروط العرض، لا بوصفها حيلة للحصول على نتيجة غنية متوقفة.
إذا كان متجرك يحتاج مراجعة فنية قبل موسم التخفيضات، يمكن الاستفادة من خدمات الصقر لتحسين SEO المتاجر السعودية لتحديد مشكلات البيانات المنظمة والصفحات الموسمية. الهدف أن تقدم Google والمتجر معلومات متسقة تساعد العميل على اتخاذ قرار شراء صحيح.


