هل لديك صفحات للعروض الموسمية؟ إليك كيفية تحسينها لمحركات البحث

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

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

ولموعد نشر الصفحة ولطريقة كتابة موعد التخفيض صلة بما يجده عملاؤك حين يبحثون عن عروضك. فصفحة العروض التي تُنشر قبل الموسم بأيام قليلة قد لا يضيفها Google إلى فهرس بحثه قبل أن يبدأ، فلا تظهر في نتائج البحث لمن يبحث عن عروضك. وإن كنت ترسل منتجاتك إلى Merchant Center، وهو أداة Google التي ترسل إليها المتاجر بيانات منتجاتها لتُستخدم في بحث Google وفي Shopping وغيرهما من خدماته، فقد يبدأ تخفيضك هناك وينتهي متأخرًا عمّا قصدته، إذا كتبت موعده بلا منطقة زمنية.

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

والدليل لأصحاب المتاجر ومسوّقيها على أي منصة، ويقتصر على نتائج بحث Google غير المدفوعة وبيانات المنتجات في Merchant Center. وتذكّر من البداية أن Google لا يضمن طريقة ظهور سعر التخفيض في النتائج في أي بلد، وأن النتائج تختلف بحسب عوامل منها موقع الباحث؛ فالخطوات التالية تجعل بياناتك صحيحة ومؤهلة للظهور، ولا تفرض شكلًا معينًا له. أما التفاصيل البرمجية ففي قسم اختياري للمطوّرين في آخر الدليل.

هل أنشئ صفحة جديدة لكل موسم؟

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

نشر Google في أكتوبر 2020 مقالًا عن أفضل الممارسات لمواسم التخفيضات، أوصى فيه بأن يكون لحدث العروض المتكرر رابط متكرر، لا رابط جديد في كل مرة يُقام فيها، ومثّل لذلك بالمسار /sale/black-friday بدلًا من /sale/2020/black-friday. ثم كرّر في يوليو 2021، في مقال عن أفضل ممارسات العروض، التوصية بإعادة استخدام الرابط نفسه كل عام.

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

ولم يذكر مقال 2020 سببًا لهذه التوصية، ولم يربطها بأي ميزة عرض. لكن يمكن فهمها في ضوء توصيته الأخرى بنشر الصفحة مبكرًا ليكتشفها Google ويفهرسها، أي يضيفها إلى الصفحات التي يمكن أن تظهر في نتائج بحثه. فالرابط المتكرر صفحة واحدة تُكتشف وتُفهرس مرة، أما الرابط الجديد فصفحة جديدة تنتظر الاكتشاف والفهرسة في كل موسم. وهذا فهمٌ للتوصية، لا تعليل نصّ عليه المقال.

والمنطق نفسه يسري على المواسم الهجرية: لا تضع السنة الهجرية في رابط صفحة رمضان، كأن تضيف إليه 1448؛ فهذا رابط سيتغير في الموسم التالي كما يتغير الرابط الذي يحمل سنة ميلادية. وهذا تطبيق لتوصية Google على المواسم الهجرية، لا نص منه؛ فمقالاه لا يتناولان التقويم الهجري.

أما السنة في عنوان الصفحة فخيار لك، لا توصية من Google للأسواق العربية: اكتبها إن رأيتها أوضح للزائر، على أن يبقى الرابط نفسه بلا سنة.

كيف أجهّز صفحة الموسم قبل العروض وبعدها؟

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

متى أنشرها؟

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

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

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

ماذا أكتب فيها؟

وحين تنشر الصفحة، اكتب فيها ما يجعل موضوعها واضحًا لـGoogle وللزائر. والنقاط التالية مأخوذة من مقال Google لعام 2021، الذي كُتب لمساعدة المتاجر على الظهور في «شريط العروض» (deals carousel). وقال المقال إن هذه الميزة كانت حينها مقصورة على الولايات المتحدة، ولا تذكر صفحات Google التي يستند إليها هذا الدليل توفّرها في أي دولة عربية. ولا يذكر المقال أن هذه النقاط تحسّن الظهور في الدول العربية، لكنها تجعل الصفحة مفهومة لـGoogle وللزائر معًا:

• نص ظاهر في الصفحة يسمّي المناسبة ويصفها. ويعلّل المقال هذه النقطة بما لا يرتبط بالشريط: أن هذا النص قد يساعد Google على أن يتبيّن أن الصفحة متعلقة بتخفيض بعينه.
• النص المكتوب على صور البانر يتكرر في نص الصفحة وفي النص البديل للصور (alt)، أي الوصف النصي المرفق بكل صورة، فلا يبقى العرض داخل الصورة وحدها.
• معلومات عامة تُنشر مسبقًا إن كانت التفاصيل لا تُكشف إلا يوم الحدث. بعد أن تحدّث الصفحة بالتفاصيل، اطلب من Google إعادة الزحف إليها. لكن طلب الزحف لا يضمن الإدراج، وتكرار الطلب لا يسرّعه.

ماذا أفعل بها حين تنتهي العروض؟

حين تنتهي عروض الموسم، أبقِ الصفحة منشورة على رابطها، وحدّث محتواها. ولا يتناول مقالا Google ما يُفعل بالصفحة بين موسم وآخر، فما يلي توصية تتفرع من توصيتهما بالرابط المتكرر:

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

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

أين أكتب سعر التخفيض وموعده؟

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

وتستطيع أن تقدّم بيانات منتجاتك، ومنها السعر وموعد التخفيض، إلى بحث Google بطريقتين يوثّقهما. الأولى البيانات المنظمة، أي الترميز الذي يصف المنتج داخل صفحته بلغة تقرؤها محركات البحث، ومنه اسم المنتج وسعره وموعد تخفيضه. والثانية Merchant Center. ولا يُشترط أن تستخدم Merchant Center؛ فلك أن تختار إحدى الطريقتين أو تجمع بينهما، ويذكر Google أن الجمع بينهما يزيد أهلية المنتج لتجارب البحث المختلفة.

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

كيف يعرف Google أن المنتج مخفّض؟

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

مثال توضيحي: عباية سعرها 240 ريالًا، وخفّضتها في الموسم إلى 180 ريالًا. السعر الحالي في بياناتها 180، والسعر الأصلي المشطوب 240.

وإذا كانت المشكلة في أسعار الكتالوج وبياناته كلها، لا في منتج واحد، فهذه مهمة تنظيم بيانات المنتجات قبل أن تكون مهمة ترميز.

كيف أكتب موعد التخفيض؟

بعد السعر، اكتب في البيانات المنظمة لصفحة المنتج متى يبدأ التخفيض ومتى ينتهي. يوصي Google في دليل بطاقات بيانات التاجر بأن تكتب موعد البدء وموعد الانتهاء معًا، حتى يتحدد التخفيض بوضوح، وبأن تضيف إلى كل موعد الوقت والمنطقة الزمنية. والمنطقة الزمنية هنا فرق توقيت مدينتك عن التوقيت العالمي UTC، مثل ‎+03:00 للرياض. ويجب ألا يأتي البدء بعد الانتهاء.

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

وإن كانت منصتك تكتب هذه البيانات عنك، فقسم «كيف أتأكد أن متجري جاهز؟» أدناه يبيّن كيف تتأكد مما تكتبه.

لماذا قد يبدأ تخفيضي متأخرًا في Merchant Center؟

إن كنت ترسل منتجاتك إلى Merchant Center، فاكتب موعد التخفيض هناك أيضًا، وانتبه إلى قاعدة قد تؤخر تخفيضك فيه.

يخصص Merchant Center لموعد التخفيض سمة اختيارية تجمع البدء والانتهاء في قيمة واحدة، ولا معنى لها إلا مع سمة سعر التخفيض، واسمها وصيغة كتابتها في القسم التقني. وتوثّق صفحة مساعدة Merchant Center الخاصة بهذه السمة قاعدتين: إن غاب الوقت، يبدأ التخفيض عند 00:00 من يوم البدء وينتهي عند 23:59 من يوم الانتهاء؛ وإن غابت المنطقة الزمنية، تُحتسب القيمة بتوقيت UTC.

وللقاعدة الثانية أثر مباشر على موعد تخفيضك في Merchant Center. فإذا كتبت الموعد في Merchant Center دون منطقة زمنية، وكان توقيت متجرك متقدمًا على UTC، بدأت فترة التخفيض التي يطبّقها Merchant Center على بيانات منتجاتك متأخرةً عمّا قصدته، وانتهت متأخرةً كذلك. ومقدار التأخر هو فرق توقيت متجرك عن UTC في أيام التخفيض نفسها.

لنفترض أن متجرك للعبايات في الرياض، وتوقيتها UTC+03:00، وأنك أردت أن يبدأ تخفيض الجمعة البيضاء عند منتصف الليل، وكتبت الموعد في Merchant Center بلا منطقة زمنية. عندها يحتسب Google الموعد في Merchant Center منتصف الليل بتوقيت UTC، أي الثالثة فجرًا بتوقيت الرياض. فيتأخر البدء في Merchant Center ثلاث ساعات، ويتأخر الانتهاء مثله.

مثال توضيحي بثلاث مدن، لا على سبيل الحصر، لموعد مكتوب في Merchant Center بلا منطقة زمنية:

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

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

وقاعدة UTC هذه خاصة بـMerchant Center. أما البيانات المنظمة في صفحة المنتج، فلا يذكر دليل بطاقات بيانات التاجر التوقيت الذي يُفترض لتاريخ لا يحمل منطقة زمنية، ولا تذكره صفحتا Google عن ترميز المنتجات وسياسات البيانات المنظمة. وإنما يوصي الدليل بكتابة المنطقة الزمنية. لذلك لا تفترض أن هذا التوقيت هو UTC ولا أنه توقيت متجرك، واكتب فرق التوقيت صراحة في البيانات المنظمة وفي Merchant Center.

ما الأخطاء التي أتجنبها؟

وقبل أن تفحص متجرك، راجع هذه الأخطاء الخمسة في صفحة الموسم وصفحات المنتجات:

1. بيانات منظمة لمنتج أو تخفيض على صفحة الموسم. لا تضف إلى صفحة الموسم بيانات منظمة لمنتج أو لعرض سعر، ولا بيانات منظمة من نوع «حدث» أو «تخفيض» أملًا في ميزة خاصة؛ فالتوثيق الذي يتناول أسعار التخفيض ومواعيدها يربطها بصفحة المنتج.
2. سعر أو تخفيض في البيانات المنظمة لا يراه الزائر. ما في البيانات المنظمة يطابق ما في الصفحة، فلا تكتب فيها سعرًا أو تخفيضًا لا يراه الزائر.
3. تاريخ انتهاء مضى على عرض ما زال قائمًا. يذكر توثيق Google أن بطاقة المنتج قد لا تظهر إذا كان تاريخ انتهاء صلاحية السعر في البيانات المنظمة تاريخًا مضى، واسم هذه الخاصية في القسم التقني. ولا تنسخ التواريخ من أمثلة التوثيق كما هي، لأن بعضها صار في الماضي.
4. بيانات منظمة تُولَّد بـJavaScript. يوصي Google بوضع البيانات المنظمة للمنتج في HTML الأولي للصفحة، أي في الصفحة كما يرسلها خادم متجرك قبل أن تعمل فيها السكربتات. ويذكر أن البيانات المنظمة التي تُولَّد بـJavaScript قد تجعل زحف Shopping أقل تكرارًا وأقل موثوقية مع الأسعار والتوفر سريعَي التغير.
5. انتظار شكل معيّن لظهور السعر. البيانات المنظمة تجعل المنتج مؤهلًا، ولا تضمن شكل العرض.

كيف أتأكد أن متجري جاهز؟

كل ما سبق يفترض أن صفحات منتجاتك تكتب التخفيض وموعده كما تريد، فتحقق من ذلك قبل الموسم. فإن كانت البيانات المنظمة تأتي من المنصة أو القالب أو إضافة، فما يقرؤه Google هو ما تكتبه تلك الأداة في الصفحة، لا ما أدخلته في لوحة التحكم.

ماذا تكتب منصة متجري؟

ابدأ بما تكتبه منصتك أو توثّقه، وهذا ما يتبيّن من مصادر ثلاث منصات:

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

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

شوبيفاي. يصف مركز مساعدة شوبيفاي إعداد التخفيض بإدخال «سعر المقارنة» (Compare-at price) أعلى من السعر الحالي، في صفحة المنتج داخل لوحة التحكم. ولا تتناول صفحة المساعدة البيانات المنظمة، فافحص ما يكتبه قالبك.

كيف أفحص صفحة منتج؟

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

1. افتح منتجًا عليه تخفيض قائم الآن. وإن كان التخفيض مجدولًا ولم يبدأ بعد، فأعد الفحص بعد بدئه؛ فقد لا تُكتب بيانات التخفيض في الصفحة قبل ذلك.
2. أدخل رابط الصفحة في اختبار النتائج الغنية (Rich Results Test). والنتائج الغنية نتائج بحث تعرض معلومات إضافية عن الصفحة، كالسعر. ويعرض الاختبار، بحسب توثيقه، أنواع النتائج الغنية التي وجدها في الصفحة مع أي أخطاء أو اقتراحات.
3. راجع القيم بنفسك: سعر التخفيض، والسعر الأصلي المشطوب، وموعدا البدء والانتهاء، وهل يحمل كل موعد وقتًا وفرق توقيت صحيحًا. فلا يذكر توثيق الاختبار أنه يتحقق من صحة التواريخ أو المناطق الزمنية، ولا أنه يعرض شكل النتيجة في بلد بعينه.
4. إن كان موقعك مضافًا إلى Search Console، وهي أداة Google التي تتابع فيها ظهور موقعك في البحث، فافحص الرابط بأداة فحص عنوان URL. ثم اختبره مباشرة (Test live URL) لترى لقطة للصفحة كما يجلبها Google ومعلومات عنها، بحسب صفحة مساعدة أداة فحص عنوان URL.
5. تابع «تقرير بيانات التجار» (Merchant listings) في Search Console بعد أن يزحف Google إلى صفحات منتجاتك.

وإن ظهرت البيانات المنظمة في الاختبار، ولم يجدها مطوّرك حين بحث في مصدر الصفحة (الطريقة في القسم التقني)، فهي على الأرجح تُولَّد بـJavaScript، وهذا هو الخطأ الرابع في قائمة الأخطاء أعلاه. أما إن تبيّن أن متجرك لا يكتب تواريخ التخفيض أصلًا، فخياراتك ثلاثة: إعدادات المنصة نفسها، أو تطبيق أو إضافة تكتب البيانات المنظمة، أو سمة موعد التخفيض في Merchant Center إن كنت ترسل منتجاتك إليه.

هل يضمن ذلك ظهور سعر التخفيض في Google؟

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

ويختلف ما يتيحه Merchant Center من بلد إلى آخر: تحدد صفحة مساعدة Merchant Center للبلدان المدعومة البلدان التي يمكن أن تستهدفها بإعلانات Shopping والقوائم المجانية، وأين يتوفر تبويب «Shopping»، فراجعها لبلدك قبل الموسم. لكن كون البلد مستهدفًا في Merchant Center لا يعني أن سعرًا مشطوبًا أو صيغة عرض معينة ستظهر في نتائج البحث فيه؛ فهذه الصفحة لا تتناول طريقة عرض الأسعار في البحث أصلًا. لذلك لا تبنِ خطتك على ظهور سعر التخفيض في Google بصورة معيّنة في أي سوق.

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

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

ماذا أفعل قبل الموسم وبعده؟

وهذه خطوات الدليل مرتبةً على مواعيدها، لتعود إليها قبل كل موسم:

1. قبل الموسم بأسابيع: انشر صفحة الموسم على رابطها الثابت، غير محظورة عن الزحف ومربوطة من الصفحة الرئيسية، وافحص صفحة منتج عليه تخفيض بالخطوات السابقة.
2. في الفترة نفسها: تأكد أن الموقع يتحمل زيارات الموسم. توصي بذلك قائمة Merchant Center للاستعداد للمناسبات، وتذكر أن المنتجات قد تُرفض في Merchant Center إن تعطّل الموقع أو انتهت مهلة استجابته.
3. قبل الحدث بـ3 إلى 5 أيام عمل، ولا أبكر من 30 يومًا قبله: أرسل بيانات المنتجات الجديدة إلى Merchant Center، إن كنت تستخدمه، بحسب قائمة Merchant Center للاستعداد للمناسبات.
4. قبل بدء العرض الترويجي بـ24 ساعة على الأقل: أرسل العروض الترويجية (Promotions) إلى Merchant Center، إن كانت متاحة في حسابك، بحسب القائمة نفسها، وتذكر أن المراجعة تكتمل في العادة خلال 24 ساعة من موعد بدء العرض الترويجي، لكنها قد تستغرق حتى 72 ساعة.
5. قبيل الحدث: لا تنقل عناصر السعر في صفحة المنتج، ولا تنتقل إلى عرض السعر أو التخفيض بـJavaScript أو بالحركة (animation)؛ فبحسب القائمة نفسها، قد يسبب ذلك رفضًا مؤقتًا للمنتجات في Merchant Center.
6. يوم الإطلاق: راجع فرق التوقيت في البيانات المنظمة وفي Merchant Center، واطلب إعادة الزحف إن كُشفت التفاصيل متأخرًا.
7. بعد الموسم: تأكد أن التخفيضات وتواريخها انتهت على المنتجات، وألا يحمل أي عرض قائم تاريخ انتهاء صلاحية سعر مضى، ثم حدّث صفحة الموسم، أو التصنيف أو المجموعة نفسها، في مكانها.

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

للمطوّرين: التفاصيل التقنية (اختياري)

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

السعر المشطوب في ترميز المنتج

يتعرّف Google على ثلاثة أنواع من الأسعار في ترميز المنتج: السعر النشط (أي السعر الحالي)، والسعر الأصلي المشطوب، وسعر الأعضاء. ولكي يفهم أن المنتج مخفّض، يكفي أن تكتب السعر الحالي سعرًا للعرض كالمعتاد، ثم تضيف سعرًا ثانيًا هو السعر الأصلي، وتعلّمه بالخاصية priceType وقيمتها StrikethroughPrice. عندها يصبح السعر النشط سعر تخفيض تلقائيًا، بحسب توثيق Google. ويقبل Google القيمة ListPrice بدلًا منها لفترة انتقالية، ويطلب ألا تضع priceType على السعر النشط نفسه.

موعد التخفيض في البيانات المنظمة: validFrom وvalidThrough وpriceValidUntil

تحدد الخاصية validFrom اللحظة التي يبدأ فيها سريان سعر العرض، وتحدد validThrough أو priceValidUntil لحظة انتهائه. وأضاف Google إلى دليل بطاقات بيانات التاجر في يوليو 2026 قسمًا بعنوان «مدة البيع بالسعر المُخفَّض» يشرح كتابتها، وهذه خلاصته:

• البدء بالخاصية validFrom، والانتهاء بالخاصية validThrough أو priceValidUntil، وكلاهما بتنسيق ISO 8601.
• اكتب البدء والانتهاء معًا ليتحدد التخفيض بوضوح، ويجب ألا يأتي البدء بعد الانتهاء.
• أضف الوقت والمنطقة الزمنية. نص التوثيق العربي: «ننصحك بتضمين الوقت والمنطقة الزمنية بتنسيق ISO 8601 لضمان الدقة في أنظمة Google».

أين تضع الخصائص؟ في أحد موضعين:

• على عقدة Offer نفسها، إذا كان السعر المكتوب فيها (price) هو سعر التخفيض النشط.
• أو على عقدة PriceSpecification الخاصة بسعر التخفيض، وفي هذا الموضع لا تصلح priceValidUntil، فاستخدم validThrough.

أي خاصية للانتهاء؟ يقبل Google الخاصيتين على Offer، ويستخدم في أحد أمثلته priceValidUntil بتاريخ ووقت. لكن إن كان وقت الانتهاء الدقيق يهمك، فـvalidThrough خيار أوضح: تعرّفها مواصفات schema.org بأنها تقبل التاريخ أو التاريخ مع الوقت، في حين تعرّف priceValidUntil بأنها تاريخ. وتصلح validThrough كذلك في الموضعين كليهما. هذه توصية عملية، لا قاعدة من Google.

مثال توضيحي لمنتج مخفّض في متجر توقيته UTC+03:00 (المنتج والأسعار والرابط افتراضية):

{
  "@context": "https://schema.org/",
  "@type": "Product",
  "name": "مثال توضيحي: عباية كتان",
  "offers": {
    "@type": "Offer",
    "url": "https://example.com/products/linen-abaya",
    "price": 180.00,
    "priceCurrency": "SAR",
    "validFrom": "2027-07-08T00:00:00+03:00",
    "validThrough": "2027-07-11T23:59:59+03:00",
    "availability": "https://schema.org/InStock",
    "priceSpecification": {
      "@type": "UnitPriceSpecification",
      "priceType": "https://schema.org/StrikethroughPrice",
      "price": 240.00,
      "priceCurrency": "SAR"
    }
  }
}

في المثال يبدأ السعر المخفّض (180 ريالًا) عند الساعة 00:00 من يوم 8 يوليو بتوقيت UTC+03:00، وينتهي في الدقيقة الأخيرة من 11 يوليو، والسعر الأصلي المشطوب 240 ريالًا. ولو استخدمت priceValidUntil مكان validThrough بالقيمة نفسها، لبقي المثال صحيحًا على Offer. والتواريخ هنا للتوضيح فقط: ضع مكانها موعد بدء تخفيضك وانتهائه، ولا تترك تاريخ انتهاء مضى على عرض ما زال قائمًا.

والخاصية priceValidUntil هي المقصودة في الخطأ الثالث من قائمة الأخطاء: يذكر توثيق Google أن بطاقة المنتج قد لا تظهر إذا كانت قيمتها تاريخًا مضى.

ويقتصر المثال على العرض والسعر، أما صفحة المنتج الحقيقية فتحتاج خصائص أخرى يطلبها دليل بطاقات بيانات التاجر، كصورة المنتج، فارجع إليه عند التطبيق. وبعد أن تعدّل قيم الكود، وقبل أن تضعه في صفحتك، يمكنك أن تلصقه في اختبار النتائج الغنية (Rich Results Test) باختيار «Code» بدل الرابط، كما تشرح صفحة مساعدة اختبار النتائج الغنية.

وإذا فحصت صفحة منشورة يدويًا، فابحث في مصدرها عن كتلة <script type="application/ld+json">، ثم عن سعر ثانٍ معلَّم بـStrikethroughPrice (أو ListPrice)، وعن validFrom، وعن validThrough أو priceValidUntil.

صيغة sale_price_effective_date في Merchant Center

تحدد السمة sale_price_effective_date المدة التي يُعرض فيها سعر التخفيض، ولا معنى لها إلا مع سمة سعر التخفيض sale_price. وهذه قواعد كتابتها بحسب صفحة مساعدة Merchant Center الخاصة بهذه السمة:

• البدء والانتهاء في قيمة واحدة، يفصل بينهما الرمز /.
• كل طرف تاريخ ووقت وفرق توقيت، على الصيغة YYYY-MM-DDThh:mm يليها فرق التوقيت بلا نقطتين (+0300)، أو الحرف Z للتوقيت العالمي.
• الطول 51 حرفًا على الأكثر.

مثال توضيحي للفترة نفسها التي في مثال البيانات المنظمة:

2027-07-08T00:00+0300/2027-07-11T23:59+0300

طول القيمة 43 حرفًا، أي ضمن الحد. وتنطبق عليها قاعدة المثال السابق نفسها: ضع تواريخ تخفيضك أنت، ولا تترك تاريخًا منتهيًا على عرض قائم.

وخلاصة الفرق بين الصيغتين: تكتب البيانات المنظمة فرق التوقيت بنقطتين (+03:00) وفي خاصيتين، ويكتبه Merchant Center بلا نقطتين وفي قيمة واحدة.

ما تكتبه ووكومرس 11.2.1 بالتفصيل

للمنتج البسيط المخفّض، تكتب الشيفرة الأساسية سعرَ التخفيض داخل UnitPriceSpecification، وتكتب معه validThrough بتاريخ انتهاء التخفيض تاريخًا فقط (على هيئة 2027-07-11 مثلًا)، وتضع التاريخ نفسه في priceValidUntil. وإن لم يكن للتخفيض تاريخ انتهاء، تضع في priceValidUntil تاريخ 31 ديسمبر من السنة التالية. ولا تكتب validFrom، وتعلّم السعر العادي بالقيمة ListPrice.

أما المنتج المتغيّر الذي تختلف أسعار خياراته، فتكتب له الشيفرة نفسها عرضًا مجمّعًا (AggregateOffer) بأدنى سعر وأعلاه، وتعلّم سعر التخفيض فيه بالقيمة SalePrice، دون سعر عادي معلَّم بـListPrice. وتنطبق ملاحظات التاريخ نفسها على النوعين: الانتهاء تاريخ فقط، ولا validFrom.

تبحث عن شركة سيو لتحسين أداء موقعك؟ تعرّف على خدمات سيو هاوس.