بيانات المنتجات المنظمة: السعر والتوفر من مصدر واحد

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

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

ابدأ بمصدر كل حقل

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

الجدول إطار لتنظيم العمل؛ اسم الحقل داخل منصتك ممكن يختلف. ما تفترضش إن وجود إضافة SEO يعني إنها تقرأ مصدر المخزون الصح تلقائيًا.

اختار التنفيذ المناسب للصفحة

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

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

تطبيق على تغيير عرض

نفترض متجرًا تدريبيًا غيّر سعر مصباح وانتهى مخزون اللون الأبيض. الاختبار يبدأ بلون متوفر: الواجهة والسلة والبيانات المنظمة تعرض نفس العرض. بعدها نفتح الأبيض برابط مباشر، ونراجع الصورة والاختيار وحالة التوفر.

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

ثلاث طبقات للفحص

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

2. فحص الصفحة: المراجع يقرأ النص ويختبر اختيار المنتج كما يراه الزائر.

3. فحص البيانات: أداة النتائج المنسقة تقرأ الخصائص، ثم نقارنها بالحقيقة والصفحة.

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

جهز اختبار قبول قبل التعميم

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

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