في الصفحة دي
البيانات المنظمة للمنتجات من المجالات القليلة في السيو اللي قواعدها مكتوبة، يا تمشي عليها يا لأ. للمتاجر في منطقتنا، المهم مش الكود الأساسي. المهم تلات حاجات القواعد بتفترضها وهي مش صح عندنا: عملة واحدة، ودولة واحدة، وباركود من المصنّع على كل منتج.
نتايج المنتجات المنسّقة محتاجة إيه
علشان صفحة منتج تبقى مؤهلة لنتايج المنتجات المنسّقة، محتاجة Product فيه اسم وصورة وجزء offers فيه السعر والعملة والتوفر. أي حاجة زيادة على كده بتحسّن فرصتك، بس مش شرط علشان تبقى مؤهل.
{
"@context": "https://schema.org",
"@type": "Product",
"name": "...",
"image": ["https://.../product-1x1.jpg"],
"description": "...",
"sku": "SKU-1234",
"brand": {"@type": "Brand", "name": "..."},
"offers": {
"@type": "Offer",
"url": "https://.../product/",
"price": "249.00",
"priceCurrency": "SAR",
"availability": "https://schema.org/InStock",
"itemCondition": "https://schema.org/NewCondition",
"priceValidUntil": "2026-12-31",
"shippingDetails": {"@type": "OfferShippingDetails"},
"hasMerchantReturnPolicy": {"@type": "MerchantReturnPolicy"}
}
}
قاعدتين بيوقّعوا الناس. الأولى، السعر في الكود لازم يطابق السعر اللي الزائر شايفه، بالضريبة أو من غيرها بنفس طريقة الصفحة. الاختلاف ده أشهر سبب لشيل المنتج من النتايج. التانية، لو الصفحة ما بتعرضش السعر غير بعد ما تختار نوع، الكود لازم يبيّن اختيار افتراضي حقيقي تقدر تشتريه، مش أقل سعر في الأنواع كلها كأنه سعر كل حاجة.
كذا عملة وكذا دولة
متاجر المنطقة كتير بتبيع نفس الكتالوج بالريال السعودي والدرهم والجنيه. الحل الغلط إنك تبدّل العملة على حسب الـIP بتاع الزائر على نفس الرابط، لأن أداة الزحف بتشوف عملة والزائر بيشوف عملة تانية، ومحدش يقدر يتأكد من الكود.

- لو عندك رابط لكل دولة (
/sa/و/ae/و/eg/)، ادّي كل رابط عملته وسعره وتوفره. ده الحل النضيف، وبيمشي مع hreflang ومع الشحن والاسترجاع الخاص بكل دولة. - لو عندك رابط واحد بكذا عرض، استخدم قايمة
offers، كل عنصر فيها ليهpriceCurrencyوpriceوeligibleRegionوتوفر خاص بيه. الطريقة دي صح، بس أصعب إنك تحافظ على دقتها لما الأسعار بتتغير. - عمرك ما تبدّل السعر في المتصفح حسب المكان وتسيب سعر ثابت واحد في الكود. ودي الطريقة اللي جوجل بيعلّم عليها كمشكلة.
- مصر محتاجة اهتمام زيادة، لأن الأسعار بتتغير هناك أكتر. لو مش قادر تخلي
priceValidUntilوالسعر نفسه محدّثين، الكود اللي ما بيتحدّثش أسوأ من كود بسيط.
التوفر، وتحدّثه كل قد إيه
القيم اللي بتفرق عمليًا هي InStock وOutOfStock وPreOrder وBackOrder وLimitedAvailability. الغلط المعتاد مش إنك تختار الغلط، الغلط إنك تسيبها من غير تحديث. كود بيقول «متوفر» على منتج مش متاح من تلات أسابيع مشكلة دقة ممكن تأثر على أهلية الدومين كله، مش الصفحة دي بس.
طلّع التوفر من نفس المصدر اللي زرار «أضف للسلة» بيستخدمه، كل مرة الصفحة بتتبني. لو متجرك بيعمل كاش للصفحات جامد، استبعد جزء التوفر من الكاش أو امسح الكاش لما المخزون يتغير. وتعمل إيه في الصفحة نفسها لما منتج يختفي قرار أكبر، شرحته في تعمل إيه في المنتجات اللي خلصت.
مشكلة الباركود (GTIN) في منتجات البراند الخاص
متاجر كتير في المنطقة في الوضع ده: بيصنّعوا منتجاتهم أو بيحطوا عليها اسمهم، والمنتجات دي مالهاش باركود من المصنّع، وكل دليل بيقولك إن الـGTIN مهم لقوائم المنتجات.

- الـGTIN معرّف قوي، مش شرط. والمنتج اللي فعلًا مالوش GTIN مش مستبعد من النتايج المنسّقة.
- ما تخترعش واحد. GTIN متألف أو مستعار أسوأ من مافيش، لأنه بيطابق منتجك بمنتج حد تاني وبيعمل بيانات متعارضة.
- استخدم المعرّفات اللي عندك.
skuثابت وmpnوbrandمكتوب صح مع بعض بيعرّفوا منتج البراند الخاص كفاية. - لو بتعيد بيع منتجات ماركات، هات الـGTIN الحقيقي من المورّد. للمنتجات المعاد بيعها ده مهم فعلًا، لأنه الطريقة اللي منتجك بيتطابق بيها مع نفس المنتج في أماكن تانية.
- لو ناوي تبيع من خلال ملفات التسوق (feeds)، قواعد المعرّفات هناك أشد من النتايج المنسّقة، فقرر بدري هتشتري بادئة GS1 ولا لأ. ولو الكتالوج ده هيفضل معاك سنين، غالبًا تستاهل.
كود التقييمات من غير ما تكسر القواعد
كود التقييمات هو المكان اللي المتاجر بتاخد فيه إجراءات يدوية. القواعد بسيطة وبتتكسر طول الوقت:

- علّم بس التقييمات اللي موجودة فعلًا والزائر يقدر يشوفها في الصفحة دي.
aggregateRatingلازم يعكس التقييمات الحقيقية للمنتج ده، مش متوسط الموقع كله.- مافيش تقييمات كاتبها النشاط عن منتجاته.
- ما تعلّمش تقييمات المتجر في صفحة منتج. تقييمات
OrganizationوتقييماتProductحاجتين مختلفين. - لو المنتج مالوش تقييمات، شيل الجزء ده. تقييم فاضي أو عدده صفر خطأ، مش حالة محايدة.
المراجعة والمتابعة
- راجع الـHTML بعد العرض، مش السورس، لأن في متاجر كتير سكريبت هو اللي بيضيف الـJSON-LD.
- راجع منتج من كل نوع: بسيط، وبأنواع، وباقة، وحجز مسبق، ومش متوفر، ورابط عربي واحد.
- تابع تقارير قوائم التاجر ومقتطفات المنتجات في Search Console كل أسبوع لأول شهر بعد أي تغيير في القالب، وبعدين كل شهر.
- اعمل زحف بيطلّع
priceوavailabilityمن الكود ويقارنهم باللي الصفحة الحقيقية بتعرضه. كده هتكتشف مشكلة الكاش القديم قبل ما جوجل يكتشفها. - راجع تاني بعد كل تحديث للقالب أو الإضافات. وأشهر سبب لبوظان الكود تحديث محدش خد باله إن ليه علاقة بيه.
في الجانب العربي، خلّي الاسم والوصف بلغة الصفحة، وخلّي خانات الأرقام بأرقام غربية عادية. price لازم يتقري كرقم، فالأرقام الهندية في الخانة دي هتفشل في المراجعة حتى لو شكلها سليم للزوار.
كود المنتجات بيشتغل أحسن فوق صفحات تصنيفات قوية، وشرحتها في صفحات التصنيفات هي صفحات الفلوس الحقيقية. وتنفيذ ده على كتالوج كبير جزء من شغلي في سيو المتاجر الإلكترونية، وجانب العرض والكاش هو السيو التقني.
أسئلة شائعة
JSON-LD ولا microdata ولا RDFa؟
JSON-LD. ده الشكل المنصوح بيه، وبيبقى منفصل عن كود الصفحة، وبيستحمل تغييرات القالب أحسن.
السكيما المدمجة في الإضافة بتاعتي كفاية؟
غالبًا بتغطي الأساسيات، ونادرًا الشحن والاسترجاع وتعدد العملات. شوف هي بتطلّع إيه قبل ما تضيف مصدر تاني، لأن وجود جزئين Product في نفس الصفحة مشكلة منتشرة وسهل تتجنبها.
محتاج تفاصيل الشحن والاسترجاع في الكود؟
مش شرط، لكنها بتخلي القايمة أكمل، وهي بالظبط الحاجات اللي المشترين في منطقتنا بيترددوا عندها.
والمنتجات اللي سعرها «حسب الطلب»؟
شيل العرض بدل ما تحط سعر مزيف. المنتج اللي مالوش سعر مش مؤهل لقوائم التاجر، ودي الحقيقة.
الأنواع (variants) يبقى ليها روابط وكود خاص؟
بس لما الناس بتدوّر على النوع بالذات، زي لون أو مقاس عليه طلب لوحده. غير كده خلّي رابط واحد بـProductGroup وابعد عن عمل صفحات ضعيفة كتير.
عايز حد يراجع كود منتجاتك ويقارنه باللي صفحاتك بتعرضه فعلًا؟ ابعتلي متجرك.


