مخطط التجارة

الخلاصة — «مخطط التجارة» هو اختصار أستخدمه لأنواع schema.org التي تُرمِّز الأشياء التي يمكن للناس البحث عنها واتخاذ إجراء بشأنها — منتجات يشترونها ووظائف يتقدمون إليها. وهي ثلاثة: Product (عنصر واحد للبيع)، وProductGroup (مجموعة من تنويعات عنصر، مثل قميص بعدة مقاسات وألوان)، وJobPosting (وظيفة شاغرة واحدة). أضف النوع الصحيح فتصبح صفحتك مؤهلة لقائمة بحث أغنى — نتائج منتجات على نمط Shopping أو بطاقة Google for Jobs. لا يرفع ذلك ترتيبك، ولا يضمن ظهور النتيجة فعلاً أو حصولها على نقرات أكثر، وليس وسيلة للاستشهاد بك في إجابات الذكاء الاصطناعي. يوجّهك هذا الدليل إلى النوع الصحيح؛ أما جداول الخصائص الكاملة فتوجد في مقالة كل نوع.

ما المقصود بـ«مخطط التجارة»؟

«مخطط التجارة» تجميع عملي، وليس نوعاً واحداً في Schema.org أو ميزة واحدة من Google. Evidence for this claim Commerce schema is an editorial grouping rather than a single Schema.org type or Google feature. Scope: This article's taxonomy; Schema.org and Google document individual types and search experiences. Confidence: high · Verified: 2026-07-14 Schema.org: Product توثّق Google متطلبات وأهلية مختلفة لترميز المنتجات وقوائم التجار والمؤسسات. Evidence for this claim Google documents distinct structured-data requirements for product snippets and merchant listings, and valid markup does not guarantee display. Scope: Google Product structured data and merchant-listing experiences. Confidence: high · Verified: 2026-07-14 Google: Product structured data

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

«مخطط التجارة» ليس مصطلحاً رسمياً. إنه مظلة أستخدمها لأنواع schema.org التي تصف القوائم التجارية أو المعاملاتية — عناصر منفردة يستطيع الشخص البحث عنها وتصفيتها واتخاذ إجراء بشأنها:

• Product — عنصر واحد معروض للبيع.
• ProductGroup — كيان أب يربط تنويعات عنصر واحد، مثل المقاسات والألوان، كي تعرف محركات البحث أنها خيارات للشيء نفسه وليست منتجات منفصلة.
• JobPosting — وظيفة شاغرة واحدة في صفحة وظائف.

أجمع هذه الأنواع الثلاثة لأنها تؤدي وظيفة واحدة في SEO: تضيفها كي تستطيع Google تحويل قائمتك إلى نتيجة بحث متخصصة. لكن للتوضيح، لا تضع Google ولا schema.org هذه الأنواع في عائلة واحدة. وسأعود إلى هذه الدقة في علامة التبويب Advanced لأنها مهمة.

تتبع وظيفة هذا الدليل من ذلك: إنه موجّه لا دليل تنفيذ. حدّد أدناه أي الأنواع الثلاثة يناسب صفحتك، ثم اقرأ الشرح المتعمق لذلك النوع؛ وعندما تدخل المراجعات أو المرتجعات أو الشحن في الصورة، راجع أيضاً سجلات Review وMerchantReturnPolicy وOfferShippingDetails المجاورة للحصول على جداول الخصائص الفعلية.

لماذا يستحق الأمر العناء: النتائج الغنية

العائد هو النتائج الغنية — القوائم المحسّنة التي تبرز في البحث:

• 🛍️ منتج يظهر معه السعر وعبارة «متوفر في المخزون» ونجوم المراجعات
• 👕 منتج يعرض خيارات المقاس واللون
• 💼 وظيفة تظهر في مربع الوظائف لدى Google مع الشركة والموقع والراتب

أضف نوع schema المطابق بكل تفاصيله المطلوبة فتصبح صفحتك مؤهلة لهذه المعالجة. مؤهلة وليست مضمونة أبداً؛ فما زالت Google تقرر هل تعرضها فعلاً.

الخطأ الذي يقع فيه معظم الناس

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

هناك فخ آخر للمبتدئين: هذه الأنواع ليست قابلة للتبادل. استخدم Product لعنصر واحد، وProductGroup عندما يأتي العنصر بتنويعات، وJobPosting لوظيفة واحدة — ولا تستخدمه أبداً في صفحة تسرد عدة وظائف معاً. والقاعدة الأخيرة أشد مما يتوقعه معظم الناس.

هل تريد النسخة الكاملة — موضع هذه الأنواع في تسلسل schema.org، وكيف يتصل كل منها بـMerchant Center وGoogle for Jobs، وأي مقالة تقرأ بعدها؟ انتقل إلى علامة التبويب Advanced.

الخلاصة — «مخطط التجارة» تجميع أضعه أنا بصفتي ممارساً، وليس فئة لدى Google أو schema.org، لأنواع القوائم التي تكسب نتائج غنية معاملاتية: Product وProductGroup وJobPosting. تفصلها Google فعلياً: يقع Product/Variants تحت «Shopping»، بينما يقع Job posting في قائمة أدلة الميزات العامة. ولا توحّدها schema.org أيضاً؛ فعلاقة Product ← ProductGroup أب/ابن حقيقية (Thing > Product > ProductGroup)، بينما يقع JobPosting في فرع Intangible (Thing > Intangible > JobPosting) ولا يرتبط بـProduct. الرابط الوحيد بين الأنواع الثلاثة هو حالة استخدام SEO: قوائم منظمة تحولها Google إلى معاملة متخصصة في SERP، مثل قوائم التجار وGoogle for Jobs. لا يُعد أي منها عامل ترتيب؛ بل يشتري الأهلية، لا عرضاً مضموناً ولا زيادة في CTR ولا استشهاداً بالذكاء الاصطناعي، وهي ثلاث نتائج منفصلة وغير مضمونة. تعمل أهلية Review/AggregateRating وفق ملف مستقل، وتنقسم بيانات المرتجعات والشحن إلى سياسة على مستوى Organization واستثناءات على مستوى Offer — وهما عقدان إضافيان يكتفي هذا الدليل بالتوجيه إليهما. كما تختلف مخاطر دورة الحياة: يفقد Product القديم الأهلية غالباً، لكن JobPosting القديم الذي لم تنتهِ صلاحيته قد يؤدي إلى إجراء يدوي.

تأطير صريح أولاً: هذا تجميعي أنا، لا تجميع Google

يجمع هذا المقال عدة مفردات وميزات بحث مترابطة تسهيلاً للاستخدام. Evidence for this claim Commerce schema is an editorial grouping rather than a single Schema.org type or Google feature. Scope: This article's taxonomy; Schema.org and Google document individual types and search experiences. Confidence: high · Verified: 2026-07-14 Schema.org: Product ولكل تجربة لدى Google خصائصها المطلوبة والموصى بها، ولا يضمن الترميز الصحيح ظهور النتيجة. Evidence for this claim Google documents distinct structured-data requirements for product snippets and merchant listings, and valid markup does not guarantee display. Scope: Google Product structured data and merchant-listing experiences. Confidence: high · Verified: 2026-07-14 Google: Product structured data

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

• تفصلها وثائق Google نفسها. في معرض البيانات المنظمة، يقع «Job posting» في قائمة أدلة الميزات العامة المسطحة، بجانب أنواع لا ترتبط به مثل Article وLocal business وOrganization. وفي المقابل تقع «Product snippet» و«Merchant listing» و«Variants» تحت عنوان فرعي منفصل هو Shopping. إنهما عائلتان توثيقيتان مختلفتان.
• لا توحّدها schema.org. يحتوي تسلسل الأنواع لديها على مجموعة مخصصة باسم «Product وOffer وAggregateOffer»، ولا يظهر JobPosting معها في أي مجموعة عليا.

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

الأنواع الثلاثة بنظرة سريعة

• Product (schema.org/Product) — عنصر واحد قابل للبيع. تحوّل Google ترميز Product الصحيح إلى تجربتين: مقتطفات المنتجات، التي تعرض نجوم المراجعات والسعر في الصفحات غير الشرائية، وقوائم التجار، وهي نتائج أغنى على نمط Shopping في الصفحات التي يمكن شراء العنصر منها. الحد الأدنى لنتيجة غنية هو name مع واحدة على الأقل من offers أو review أو aggregateRating؛ لكن مسار review/aggregateRating يخضع لقواعد مقتطف المراجعة المنفصلة لدى Google، بما فيها قيد المراجعات ذاتية الخدمة، وليس لقاعدة شاملة تقول إن «أي صفحة منتج يمكنها عرض النجوم». لا يتأهل كل Product أو صفحة تاجر تلقائياً لنجوم المراجعات؛ راجع الشرح المتعمق لـReview schema لهذا الملف.
• ProductGroup (schema.org/ProductGroup) — كيان أب يجمع تنويعات عنصر مفاهيمي واحد، مثل قميص بعدة مقاسات وألوان، كي تفهم Google أنها خيارات للمنتج نفسه وليست قوائم غير مترابطة. يربط التنويعات باستخدام hasVariant وvariesBy وproductGroupID. والمهم أنه لا يستبدل Product؛ فكل تنويع يظل Product كاملاً مستقلاً، وتقع ProductGroup فوقها.
• JobPosting (schema.org/JobPosting) — وظيفة شاغرة واحدة مرمّزة لتصبح مؤهلة لتجربة Google for Jobs، أي بطاقة أو شريط قوائم الوظائف في البحث. الخصائص الأساسية المطلوبة هي title وdescription وdatePosted وhiringOrganization وjobLocation، أو applicantLocationRequirements للوظائف البعيدة بالكامل.

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

موضعها في تسلسل schema.org

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

• Product — Thing > Product.
• ProductGroup — Thing > Product > ProductGroup. وهي نوع فرعي حقيقي من Product، ترث كل خصائص Product وتضيف hasVariant وproductGroupID وvariesBy. لذلك ليست «Product أم ProductGroup» مفاضلة حقيقية؛ فـProductGroup هي Product متخصصة صُممت لحالة التنويعات.
• JobPosting — Thing > Intangible > JobPosting. فرع منفصل تماماً، ولا يشير تعريف JobPosting إلى Product أو Offer أو أي نوع تجاري.

الخلاصة: يرتبط Product وProductGroup تصنيفياً بعلاقة أب/ابن يمكن التحقق منها والاستشهاد بها؛ أما JobPosting فلا يرتبط بهما تصنيفياً. النسيج الرابط بين الأنواع الثلاثة هو حالة استخدام SEO، لا وراثة النوع. قل ذلك وستقف على أرض صلبة.

Product أم ProductGroup: متى تستخدم كلاً منهما؟

القاعدة بسيطة:

• تهيئة واحدة قابلة للشراء ← Product عادية: SKU واحد وسعر واحد وصفحة واحدة يمكن الشراء منها.
• عنصر مفاهيمي واحد بعدة تنويعات قابلة للشراء ← ProductGroup تضم أعضاء Product. مثال القميص بخمسة ألوان. لا تُعرض ProductGroup نفسها للبيع؛ بل تُعرض أعضاء hasVariant، ولكل منها sku/gtin وسعر وتوفر خاص بها.

توثّق Google ProductGroup بطريقة مختلفة أيضاً: فهي تقع في صفحة Variants لا في دليل ميزة مستقل من المستوى الأعلى، مما يؤكد أن Google تتعامل معها كامتداد لـProduct لا كنوع مستقل تماماً من النتائج الغنية. أما جداول الخصائص الكاملة، ومشكلة عنوان URL الكامل في variesBy، والمطابقة مع item_group_id في Merchant Center فمكانها الشرح المتعمق لـProductGroup لا هنا.

JobPosting: النوع الشاذ

لا يشترك JobPosting مع Product في أي صلة تصنيفية، لكنه يمثل شكل المشكلة نفسه ولذلك يستحق مكانه في هذا الدليل. ويميزه تشغيلياً أمران:

1. وظيفة واحدة في كل صفحة، دائماً. قاعدة Google: “The JobPosting markup must only be used on pages that contain a single job posting.” (ترجمة) «يجب ألا يُستخدم ترميز JobPosting إلا في الصفحات التي تحتوي على إعلان وظيفة واحد». ولا يُستخدم أبداً في صفحة قوائم أو نتائج بحث. لا يوجد لدى Product/ProductGroup قيد مماثل يفرض عنصراً واحداً في الصفحة؛ بل إن ProductGroup موجودة تحديداً لمعالجة عدة تنويعات في صفحة واحدة.
2. الإعلانات المنتهية التزام امتثال، وليست شيئاً تضبطه ثم تنساه. سنفصل المخاطر أدناه؛ ففي هذه النقطة تختلف العواقب عن Product بأكبر قدر.

القواعد الأساسية المشتركة بين الأنواع الثلاثة

رغم أن الأنواع لا تتشارك تصنيفاً واحداً، فإنها تخضع جميعاً لـإرشادات Google العامة للبيانات المنظمة، ومن المفيد ذكر القواعد مرة واحدة:

• الخصائص المطلوبة هي بوابة الأهلية. إذا غابت خاصية مطلوبة فلن تتأهل الصفحة لتلك النتيجة الغنية. وترفع الخصائص الموصى بها الجودة؛ إذ تستخدم Google راتب الوظيفة مثالاً صريحاً: يفضل المستخدمون الإعلانات التي تذكر الراتب على التي لا تذكره. وينطبق منطق «الأكمل أفضل» نفسه على Product.
• الأهلية ≠ العرض المضمون. يدخلك الترميز الصحيح في مجموعة المرشحين، لكن أنظمة Google تقرر بصورة مستقلة هل تعرض التحسين.
• رمّز المحتوى المرئي والدقيق فقط. لا ترميز مخفياً ولا مراجعات زائفة ولا بيانات مضللة؛ تنطبق سياسات Google للرسائل غير المرغوب فيها وجودة المحتوى على الأنواع الثلاثة، ولكل نوع أيضاً سياسة خاصة بالميزة، مثل سياسة محتوى JobPosting.
• JSON-LD هو التنسيق الموصى به للأنواع كلها، وهو أسهل صيانةً على نطاق واسع من Microdata/RDFa المضمّنة.

اتصالات كل نوع خارج ترميز الصفحة

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

• Product / ProductGroup ↔ Google Merchant Center. يمكنك تقديم بيانات المنتج بوصفها بيانات منظمة في الصفحة أو خلاصة Merchant Center أو كليهما. توصي Google بالاثنين لتعظيم الأهلية، ثم تطابق بينهما؛ فهما نظامان منفصلان يُتحقق من كل منهما مستقلاً وليسا عملية إرسال واحدة. اجتياز Rich Results Test لا يعني أن خلاصتك صحيحة، والعكس صحيح. ويجب أن يتطابق السعر والتوفر بين ترميز الصفحة والخلاصة وإتمام الشراء.
• JobPosting ↔ Google for Jobs. يجعل ترميز JobPosting الصحيح صفحة وظيفة واحدة مؤهلة لتجربة Jobs، وهي قطاع مستقل لا سطح Shopping.
• تنقسم المرتجعات والشحن بالطريقة نفسها ولكن بدقة أكبر. تقع MerchantReturnPolicy عادةً على مستوى Organization، أي نافذة وشروط الإرجاع القياسية للموقع كله. وتعمل OfferShippingDetails على مستوى Offer، وقد وُجدت تحديداً لتجاوز القيمة الافتراضية على مستوى المؤسسة لعنصر واحد، كمنتج أثقل أو منطقة ذات أسعار مختلفة. تعامل معهما كسجلين منفصلين قد يصبح كل منهما قديماً بمفرده، لا ككتلة تضبطها مرة واحدة؛ إذ تحتاج سياسة المؤسسة وأي استثناءات على مستوى العرض إلى صيانة مستقلة. وتوجد قواعد الأولوية الكاملة في الشرحين المتعمقين لـMerchantReturnPolicy وOfferShippingDetails.
• البيانات المنظمة في الصفحة وخلاصة Merchant Center وما تعرضه فعلياً ميزات بحث Google أو إجابة ذكاء اصطناعي هي ثلاثة عقود منفصلة لا مساراً واحداً؛ فالترميز الصحيح يكسب الأهلية في الأول، ولا يملأ الثاني تلقائياً، ولا يضمن شيئاً في الثالث. واجتياز أحدها لا يثبت التكافؤ مع البقية.

يجدر توضيح عدم التناظر مع Bing: يتحقق Bing من الأنواع الثلاثة بصورة عامة وفق بنية schema.org، لكنه لا ينشر أي جداول مخصصة للخصائص المطلوبة والموصى بها أو سياسات محتوى لأي منها، ولا يملك ما يكافئ قوائم التجار أو Google for Jobs. وبشأن ProductGroup تحديداً، قال Fabrice Canel من Bing في سبتمبر 2024 إن Bing لا يستهلك ترميز ProductGroup بعد في تسميات التسوق، وإن كان «ضمن ما يراقبونه». إذن المفردات الأساسية واحدة، لكن Google وحدها بنت فوقها تجارب مخصصة وموثقة للنتائج الغنية.

اختلافات المخاطر ودورة الحياة

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

• يفقد Product القديم أو غير المتوفر غالباً أهلية النتيجة الغنية فحسب، أو يعرض عبارة «نفد» أو «غير متوفر». أمر مزعج لا كارثي.
• أما JobPosting القديم الذي لم يُحذف فحالة مختلفة. تقول Google: “We don’t allow expired job postings,” (ترجمة) «لا نسمح بإعلانات الوظائف المنتهية». وإن عدم إنهاء الإعلان أو حذف الوظائف المغلقة “may result in a manual action.” (ترجمة) «قد يؤدي إلى إجراء يدوي». وهذه نتيجة أسوأ جوهرياً من فقد الأهلية العادي. توجد ثلاث طرق مقبولة لإنهاء الوظيفة: تعيين validThrough إلى تاريخ ماضٍ، أو إعادة 404/410، أو إزالة الترميز.

الدرس واحد: تحتاج القوائم المنظمة إلى عملية لإدارة دورة حياتها. لكن إذا كنت ستبني مسار تنظيف واحداً فقط، فابنه للوظائف.

هل يساعد مخطط التجارة في SEO؟

لا، ليس في الترتيب. قال John Mueller بوضوح: “Structured data won’t make your site rank better.” (ترجمة) «لن تجعل البيانات المنظمة موقعك يحقق ترتيباً أفضل». ما تفعله هو كسب الأهلية للنتائج الغنية والتجارب المتخصصة، ومساعدة Google بصورة مستقلة على فهم صفحاتك. والخلط بين «أضفت schema» و«سأرتب أفضل» هو الخرافة الأكثر شيوعاً في الأنواع الثلاثة.

ولا يقتصر الأمر على الترتيب. فالأهلية، وظهور نتيجة غنية فعلياً، وارتفاع CTR، والإيراد أربعة ادعاءات منفصلة؛ لا تدمجها في ادعاء واحد. لا يضمن الترميز الصحيح ظهور قائمتك في Shopping أو تجربة Jobs، لأن الأهلية ليست عرضاً، ولا يضمن نقرات أكثر. ولأن أياً من أنواع schema في هذا الدليل ليس إشارة موثقة للظهور في الذكاء الاصطناعي، فهو ليس رافعة للظهور أو الاستشهاد في AI Overviews أو AI Mode أيضاً. قِس كل نتيجة مستقلة؛ يستحق طرح schema التنفيذ من أجل ميزة البحث التي يمكنه كسبها، لا بصفته بديلاً عن بقية النتائج.

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

إلى أين تذهب بعد ذلك

هذا الدليل هو الخريطة، ولكل نوع مقالة تفصيلية تحته:

• Product schema — تجربتا Google، مقتطفات المنتجات مقابل قوائم التجار، وتقسيم الخصائص المطلوبة والموصى بها، وقيم availability، وفك الالتباس بين الخلاصة والترميز. ابدأ هنا إذا كانت صفحتك تبيع عنصراً واحداً.
• ProductGroup schema — تجميع التنويعات باستخدام hasVariant/variesBy/productGroupID، وأنماط الصفحة الواحدة مقابل الصفحات المتعددة، ومشكلة عنوان schema.org الكامل، والمطابقة مع item_group_id في Merchant Center. ابدأ هنا إذا كان العنصر يأتي بمقاسات أو ألوان أو مواد مختلفة.
• JobPosting schema — الخصائص المطلوبة والموصى بها، والتعامل مع الوظائف البعيدة والهجينة، وقاعدة وظيفة واحدة في كل صفحة، وانضباط انتهاء الصلاحية، وتغييرات الوصول إلى Indexing API في 2024–2025 لمواقع الوظائف. ابدأ هنا لصفحة وظائف أو لوحة وظائف.
• MerchantReturnPolicy schema — النوع المتداخل على مستوى الخصائص لسياسة الإرجاع، وترتيب الأولوية بين الترميز وإعدادات Merchant Center، والخلط بين applicableCountry وreturnPolicyCountry.
• OfferShippingDetails schema — الخاصية المصاحبة لسعر الشحن ووجهته ووقت التسليم، ومتى تطلبها Google فعلياً للقوائم المجانية.
• Review schema — ملف الأهلية المنفصل وراء مسار review/aggregateRating إلى نتيجة Product الغنية: قواعد المراجعة الفردية مقابل المجمعة، وقيد المراجعات ذاتية الخدمة، ولماذا لا تتأهل كل صفحة منتج تلقائياً للنجوم. ابدأ هنا بعد تجاوز سؤال «أي الأنواع الثلاثة أستخدم؟» والوصول إلى «هل تستطيع هذه الصفحة عرض نجوم المراجعات فعلاً؟».

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

ملخص الذكاء الاصطناعي

خلاصة مكثفة للنسخة المتقدمة:

• ما هو: «مخطط التجارة» تجميع عملي يضعه Patrick، وليس فئة لدى Google أو schema.org، لأنواع القوائم في schema.org التي تكسب نتائج غنية معاملاتية: Product وProductGroup وJobPosting.
• ليست عائلة رسمية: يضع معرض Google قوائم Product/Merchant/Variants تحت «Shopping»، ويضع Job posting في قائمة أدلة الميزات العامة. وتجمع schema.org «Product وOffer وAggregateOffer»، ولا تضع JobPosting معها في أي مجموعة عليا.
• التسلسل: Product = Thing > Product؛ وProductGroup = Thing > Product > ProductGroup، وهي نوع فرعي حقيقي من Product للتنويعات؛ وJobPosting = Thing > Intangible > JobPosting في فرع غير مرتبط. Product وProductGroup أب/ابن، أما JobPosting فمنفصل تصنيفياً.
• متى تستخدم كل نوع: تهيئة واحدة قابلة للشراء ← Product؛ عنصر واحد بتنويعات ← ProductGroup تضم أعضاء Product، ولا تُباع ProductGroup نفسها؛ وظيفة شاغرة واحدة ← JobPosting، وظيفة واحدة في كل صفحة لا صفحة قوائم.
• النتائج الغنية: Product ← مقتطفات المنتجات وقوائم التجار؛ ProductGroup ← قوائم تجار واعية بالتنويعات؛ JobPosting ← Google for Jobs.
• القواعد المشتركة: الخصائص المطلوبة بوابة الأهلية؛ الأهلية لا تضمن العرض؛ رمّز المحتوى المرئي والدقيق فقط؛ ويوصى بـJSON-LD.
• خارج الترميز: Product/ProductGroup ↔ Google Merchant Center، وهما نظامان منفصلان لكن تجري مطابقتهما؛ قدم الاثنين وحافظ على تطابق السعر والتوفر بين الترميز والخلاصة وإتمام الشراء. JobPosting ↔ Google for Jobs. وتنقسم المرتجعات والشحن بدقة أكبر: تقع MerchantReturnPolicy عادةً على مستوى Organization، بينما تتجاوزها OfferShippingDetails على مستوى Offer للاستثناءات؛ سجلان وجدولا صيانة.
• نجوم المراجعات ملف مستقل: يخضع مسار review/aggregateRating إلى نتيجة Product الغنية لقواعد أهلية مقتطف المراجعة المنفصلة لدى Google، وليس لقاعدة «كل صفحة منتج مؤهلة»؛ راجع مقالة Review schema.
• Bing: يتحقق من الأنواع الثلاثة بصورة عامة بلا مواصفات أو سياسات مخصصة ولا مكافئ لقوائم التجار أو Jobs؛ ووفق Fabrice Canel في سبتمبر 2024 لم يكن Bing يستخدم ترميز ProductGroup بعد في تسميات التسوق.
• ملف المخاطر: يفقد Product القديم الأهلية غالباً؛ أما JobPosting القديم غير المحذوف فقد يؤدي إلى إجراء يدوي — أنهِه عبر validThrough في الماضي أو 404/410 أو إزالة الترميز.
• أثر SEO: ليس عامل ترتيب. قال Mueller: “Structured data won’t make your site rank better” (ترجمة) «لن تجعل البيانات المنظمة موقعك يحقق ترتيباً أفضل». إنه يكسب الأهلية ويساعد الفهم، لكن ذلك منفصل عن العرض الفعلي أو زيادة CTR أو الاستشهاد في إجابة ذكاء اصطناعي؛ ولا يُوثق أي من أنواع هذا الدليل بوصفه إشارة للظهور في الذكاء الاصطناعي.
• هذا الدليل يوجّه ولا ينفذ: توجد جداول الخصائص الكاملة في الشروح المتعمقة لـProduct وProductGroup وJobPosting وReview وMerchantReturnPolicy وOfferShippingDetails.

الوثائق الرسمية

وثائق المصادر الأولية للأنواع الثلاثة في مخطط التجارة وللقواعد التي تشترك فيها.

Google — القواعد المشتركة

• الإرشادات العامة للبيانات المنظمة — مبدأ الأهلية وسياسات جودة المحتوى والرسائل غير المرغوب فيها التي تنطبق على الأنواع الثلاثة.
• معرض البيانات المنظمة للبحث — المصدر المرجعي لما ينتج نتائج غنية حالياً، وفيه أيضاً يظهر الفصل بين «Shopping» و«أدلة الميزات».

Google — Product وProductGroup («Shopping»)

• مقدمة إلى البيانات المنظمة لـProduct — الفصل بين مقتطف المنتج وقائمة التاجر، والعلاقة بين البيانات المنظمة والخلاصة.
• البيانات المنظمة لمقتطف المنتج — الخصائص المطلوبة والموصى بها لتجربة المقتطف الأخف.
• البيانات المنظمة لقائمة التاجر — متطلبات «اشتره هنا» الأكثر صرامة.
• البيانات المنظمة لتنويعات المنتج (ProductGroup) — الموضع الذي توثَّق فيه ProductGroup بوصفها امتداداً لـProduct.
• Merchant Center — مواصفات بيانات المنتجات — مواصفات الخلاصة التي تجري مطابقتها مع ترميز الصفحة.

Google — JobPosting («أدلة الميزات»)

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

Schema.org (التصنيف)

• schema.org/Product · schema.org/ProductGroup · schema.org/JobPosting · نظرة عامة على تسلسل الأنواع

Bing / Microsoft

• Bing Webmaster Tools — ترميز موقعك بالبيانات المنظمة — دعم عام لـschema.org من دون مواصفات أهلية خاصة بكل نوع.

اقتباسات من المصدر

تصريحات مسجلة. حين تتيح الصفحة النص، ينتقل الرابط مباشرةً إلى المقطع المقتبس.

وثائق Google — مبدأ الأهلية المشترك

• “Specify all required properties listed in the documentation for your specific rich result type. Items that are missing required properties are not eligible for rich results. The more recommended properties that you provide, the higher quality the result is to users. For example: users prefer job postings with explicitly stated salaries than those without…” (ترجمة) «حدّد جميع الخصائص المطلوبة المدرجة في توثيق نوع النتيجة الغنية المحدد. العناصر التي تفتقد خصائص مطلوبة غير مؤهلة للنتائج الغنية. وكلما قدمت خصائص موصى بها أكثر ارتفعت جودة النتيجة للمستخدمين؛ فمثلاً يفضل المستخدمون إعلانات الوظائف التي تذكر الرواتب صراحةً على التي لا تذكرها…». الانتقال إلى الاقتباس
• “Content in structured data must also follow the additional content guidelines or policies, as documented in the specific feature guide. For example, content in JobPosting structured data must follow the job posting content policies.” (ترجمة) «يجب أن يتبع المحتوى في البيانات المنظمة أيضاً إرشادات أو سياسات المحتوى الإضافية الموثقة في دليل الميزة المحدد. فمثلاً يجب أن يتبع المحتوى في بيانات JobPosting المنظمة سياسات محتوى إعلانات الوظائف». الانتقال إلى الاقتباس

وثائق Google — العلاقة بين Product وMerchant Center

• “Two markup types exist: Product snippets for non-purchase pages, emphasizing reviews, and Merchant listings for purchase pages, highlighting product details like sizing and shipping.” (ترجمة) «يوجد نوعان من الترميز: مقتطفات Product للصفحات غير الشرائية التي تركز على المراجعات، وقوائم التجار لصفحات الشراء التي تبرز تفاصيل المنتج مثل المقاس والشحن». الانتقال إلى الاقتباس
• “To provide rich product data to Google Search you can add Product structured data to your web pages, upload data feeds with Google Merchant Center and opt into free listings within the Merchant Center console, or both.” (ترجمة) «لتقديم بيانات غنية عن المنتجات إلى بحث Google، يمكنك إضافة بيانات Product المنظمة إلى صفحاتك، أو تحميل خلاصات بيانات عبر Google Merchant Center والاشتراك في القوائم المجانية داخل لوحة Merchant Center، أو استخدام الاثنين». الانتقال إلى الاقتباس

وثائق Google — القواعد المميزة لـJobPosting

• “The JobPosting markup must only be used on pages that contain a single job posting. We don’t allow the use of JobPosting markup in any other page, including pages that do not list any job.” (ترجمة) «يجب ألا يُستخدم ترميز JobPosting إلا في الصفحات التي تحتوي على إعلان وظيفة واحد. ولا نسمح باستخدامه في أي صفحة أخرى، بما فيها الصفحات التي لا تسرد أي وظيفة». الانتقال إلى الاقتباس
• “We don’t allow expired job postings. Ideally you should remove expired job postings from your website. If you prefer to not remove them, then you need to ensure the validThrough property is populated and in the past.” (ترجمة) «لا نسمح بإعلانات الوظائف المنتهية. والأفضل إزالة الإعلانات المنتهية من موقعك. وإذا فضلت عدم إزالتها، فعليك التأكد من ملء خاصية validThrough بتاريخ ماضٍ». الانتقال إلى الاقتباس
• “Jobs that are no longer open for applications must be expired in one of the following ways. Failure to take timely action on expired jobs may result in a manual action.” (ترجمة) «يجب إنهاء الوظائف التي لم تعد تقبل الطلبات بإحدى الطرق التالية. وقد يؤدي عدم اتخاذ إجراء في الوقت المناسب بشأن الوظائف المنتهية إلى إجراء يدوي». الانتقال إلى الاقتباس

John Mueller من Google — schema ليس عامل ترتيب

• “Structured data won’t make your site rank better.” (ترجمة) «لن تجعل البيانات المنظمة موقعك يحقق ترتيباً أفضل». و: “It’s fine to use it for other things in schema.org, that won’t cause problems, but you’re unlikely to see any visible change from it in Google Search.” (ترجمة) «لا بأس باستخدامها لأشياء أخرى في schema.org، ولن يسبب ذلك مشكلات، لكن من غير المرجح أن ترى بسببها تغيراً ظاهراً في بحث Google». التغطية نُقل عبر تغطية Search Engine Roundtable لمنشورات Mueller على Bluesky في أبريل 2025؛ تعامل مع الصياغة بوصفها نقلاً ثانوياً مكتوباً.
• “In order to be eligible to be shown as a rich result, you need to make sure that the page uses the right structured data and that it complies with the appropriate policies on our side.” (ترجمة) «لكي تكون الصفحة مؤهلة للظهور كنتيجة غنية، عليك التأكد من أنها تستخدم البيانات المنظمة الصحيحة وتمتثل للسياسات المناسبة لدينا». التغطية نُقل عبر تغطية Search Engine Land لإجابة #AskGoogleWebmasters عام 2019.
• “Exactly. Understand that markup types come and go, but a precious few you should hold on to (like title, and meta robots).” (ترجمة) «بالضبط. افهم أن أنواع الترميز تظهر وتختفي، لكن هناك عدداً قليلاً ثميناً ينبغي التمسك به، مثل title وmeta robots». التغطية نُقل عبر تغطية Search Engine Roundtable لرد على Reddit في نوفمبر 2025.

Fabrice Canel من Microsoft Bing — عن ProductGroup

• “ProductGroup markup isn’t used in our captions yet, but it’s on our radar. Our team is closely monitoring its adoption. Stay tuned!” (ترجمة) «لا نستخدم ترميز ProductGroup في تسمياتنا بعد، لكنه ضمن ما نراقبه. يتابع فريقنا اعتماده عن كثب. ترقبوا الجديد». التغطية نُقل عبر تغطية Search Engine Roundtable لتصريح على X في سبتمبر 2024؛ وهو مؤرخ، لذا أعد التحقق من دعم Bing الحالي لـProductGroup قبل الاعتماد عليه.

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

مقارنة الأنواع الثلاثة

حقائق سريعة

• «مخطط التجارة» تجميع يضعه ممارس، وليس فئة لدى Google أو schema.org؛ فالأنواع الثلاثة تشترك في حالة استخدام SEO لا في تصنيف.
• Product وProductGroup أب/ابن؛ أما JobPosting فهو فرع غير مرتبط.
• الأهلية ≠ العرض؛ يدخلك الترميز الصحيح في مجموعة المرشحين، وما زالت Google تقرر هل تعرض التحسين.
• ليس عامل ترتيب، ولا ضماناً لـCTR أو العرض أو الاستشهاد بالذكاء الاصطناعي. يكسب schema أهلية النتيجة الغنية ويساعد الفهم. أما ظهور النتيجة فعلاً، وكسب نقرات أكثر، والظهور في إجابة ذكاء اصطناعي فهي ثلاث نتائج منفصلة وغير مضمونة.
• أهلية Review/AggregateRating لها ملف مستقل. لا تتأهل كل صفحة منتج أو تاجر تلقائياً لتقييمات النجوم؛ فهذا المسار يخضع لقواعد مقتطف Review المنفصلة لدى Google. راجع الشرح المتعمق لـReview schema.
• تنقسم المرتجعات والشحن أيضاً بدقة أكبر. تقع MerchantReturnPolicy عادةً على مستوى Organization، أي سياستك الافتراضية، وتتجاوزها OfferShippingDetails لكل Offer في حالات الاستثناء. سجلان وجدولا صيانة.
• JSON-LD هو تنسيق Google الموصى به للأنواع الثلاثة.
• خلاصة Merchant Center وترميز Product في الصفحة نظامان منفصلان تجري Google مطابقة بينهما؛ قدم الاثنين وحافظ على اتساق السعر والتوفر بين الترميز والخلاصة وإتمام الشراء.
• انضباط الوظائف هو الأعلى خطراً: أنهِ الوظائف المغلقة عبر validThrough في الماضي أو 404/410 أو إزالة الترميز، وإلا فقد تتعرض لإجراء يدوي.

أي نوع من مخطط التجارة أحتاج؟

أجب بحسب الصفحة التي ترمّزها لتصل إلى النوع الصحيح والمقالة التفصيلية المناسبة.

أخطاء أراها فعلياً في مخطط التجارة

هذه أخطاء ملموسة يرتكبها الناس في ترميز Product وProductGroup وJobPosting، وليست افتراضات. ولكل منها إصلاح.

وضع ترميز JobPosting في صفحة تسرد عدة وظائف

قاعدة Google صريحة: يجب ألا يُستخدم ترميز JobPosting «إلا في الصفحات التي تحتوي على إعلان وظيفة واحد»، ويُحظر في أي صفحة أخرى، بما فيها الصفحة التي لا تسرد وظيفة أصلاً. لا تكسبك إضافته إلى فهرس الوظائف أو صفحة نتائج البحث عدة قوائم في Jobs؛ بل يجعل الترميز غير ممتثل وغير مؤهل.

افعل بدلاً من ذلك: امنح كل وظيفة شاغرة عنوان URL خاصاً بصفحة وظيفة واحدة، ورمّز تلك الصفحة وحدها. استخدم صفحة القوائم أو الفهرس للتنقل لا لترميز JobPosting.

ترك إعلان وظيفة مغلقة منشوراً من دون إنهائه

غالباً لا يفعل Product القديم سوى فقد الأهلية أو عرض «غير متوفر»، وهو أمر مزعج قليلاً. أما JobPosting القديم ففئة مخاطر مختلفة؛ تقول Google إنها لا تسمح بإعلانات الوظائف المنتهية، وإن عدم إنهاء إعلان مغلق أو حذفه “may result in a manual action.” (ترجمة) «قد يؤدي إلى إجراء يدوي». وهذه عقوبة على مستوى الموقع، لا مجرد فقد مقتطف نتيجة غنية.

افعل بدلاً من ذلك: بمجرد إغلاق الوظيفة، نفّذ أحد الأمور الثلاثة التي تقبلها Google: عيّن validThrough إلى تاريخ ماضٍ، أو أعد 404/410 لعنوان URL، أو أزل ترميز JobPosting كلياً. اجعل ذلك جزءاً من خطوة إنهاء الوظيفة في نظام التوظيف، لا عملاً يدوياً لاحقاً.

معاملة ProductGroup بديلاً عن ترميز كل تنويع

ProductGroup كيان أب يربط التنويعات باستخدام hasVariant وvariesBy وproductGroupID، لكنه لا يستبدل Product. ما زال كل تنويع، أي كل تركيبة مقاس أو لون أو مادة، يحتاج إلى ترميز Product كامل خاص به مع sku/gtin وسعر وتوفر مستقل. نشر ProductGroup وحدها وتجاوز سجلات Product الفردية يترك التنويعات من دون البيانات التي تحتاج إليها Google فعلياً لبيعها.

افعل بدلاً من ذلك: رمّز كل تنويع قابل للشراء بوصفه Product مستقلاً، ثم ضع المجموعة في ProductGroup تشير إليها.

توقع أن يرفع مخطط التجارة ترتيبك

هذه الخرافة الأكثر شيوعاً في الأنواع الثلاثة، وقد قالت Google ذلك بوضوح وتكرار. قال John Mueller: “Structured data won’t make your site rank better.” (ترجمة) «لن تجعل البيانات المنظمة موقعك يحقق ترتيباً أفضل». ومعاملة طرح schema كتكتيك ترتيب تضع توقعاً خاطئاً لدى أصحاب المصلحة، وقد تؤدي إلى اختصار أعمال أخرى لصالح ترميز لم يكن سيحرك الترتيب أصلاً.

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

ترك ترميز الصفحة وخلاصة Merchant Center وإتمام الشراء تخرج عن التزامن

قد تأتي بيانات المنتج من البيانات المنظمة في الصفحة أو خلاصة Merchant Center أو كليهما، وتجري Google مطابقة بينهما بوصفهما نظامين منفصلين بدلاً من معاملة أحدهما نسخة من الآخر. ولا يثبت نجاح Rich Results Test سلامة الخلاصة، كما أن سلامة الخلاصة لا تعني اجتياز الاختبار. وإذا اختلف السعر أو التوفر بين الترميز والخلاصة وما يفرضه إتمام الشراء فعلياً، فإن هذا التعارض يقوّض الأهلية وثقة المستخدم معاً.

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

أدوات لبناء مخطط التجارة وفحصه

أداة Schema Markup Validator لدي هي المحطة الأولى بعد كتابة JSON-LD لأي من الأنواع الثلاثة. الصق كتلة Product أو ProductGroup أو JobPosting، أو صفحة كاملة، فتجري الأداة فحوصاً موزعة حسب الشدة وفق مفردات schema.org ومتطلبات Google للنتائج الغنية. وهذا مفيد لاكتشاف خاصية مطلوبة مفقودة قبل النشر، أياً كان النوع الذي تعمل عليه.

تجيب أداة Rich-Result Eligibility Checker لدي عن السؤال الأكثر تحديداً الذي يعود إليه هذا الدليل: ليس «هل JSON-LD صحيح؟» بل «هل تتأهل هذه الصفحة فعلاً لنتيجة غنية؟». الصق JSON-LD أو صفحة HTML أو اجلب عنوان URL حياً، فتعرض الخصائص المطلوبة الموجودة والمفقودة لـProduct (offers/review/aggregateRating) أو JobPosting (title وdescription وdatePosted وhiringOrganization وjobLocation) — وهي بوابة الأهلية نفسها التي تصفها المقالة.

صُممت أداة PDP SEO Checker لدي خصيصاً لجانب صفحات تفاصيل المنتجات في هذا الدليل. فهي تفحص صفحة منتج حية بما يتجاوز schema وحده، وتغطي إشارات الصفحة التي ترافق ترميز Product/ProductGroup عند تحديد ما إذا كانت صفحة SKU واحد أو صفحة تنويعات مجمعة مهيأة بصورة صحيحة.

بعد اجتياز الترميز لهذه الفحوص، مرّر الصفحة عبر Rich Results Test الخاص بـGoogle. فهو الأداة التي تستخدمها Google فعلياً لتحديد الأهلية، ولذلك يمثل الحكم الأخير قبل النشر لأي من الأنواع الثلاثة في هذا الدليل.

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

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

موارد تستحق وقتك

كتاباتي عن ترميز schema

• Schema Markup — رؤيتي الأوسع للمفردات والتنسيقات وفهم الكيانات ودورة الإهمال. ومخطط التجارة جزء من ذلك.
• دليل المبتدئين إلى SEO التقني — حيث أصف schema بأنه شيفرة تساعد المحركات على فهم المحتوى وتشغّل الميزات التي تجعل القائمة بارزة.
• Enterprise SEO — قاعدتي العملية التي تنطبق هنا أيضاً: “I’m a fan of schema markup as long as it gets you a search feature.” (ترجمة) «أنا مؤيد لترميز schema ما دام يكسبك ميزة في البحث».

محاضراتي

• How Search Works (SlideShare) — شرحي للزحف والعرض والفهرسة والترتيب، وهو خلفية مفيدة لموضع البيانات المنظمة. وينطبق إخلاء المسؤولية الدائم لدي: “This is my understanding of systems… not going to be 100% complete or accurate.” (ترجمة) «هذا فهمي للأنظمة… ولن يكون كاملاً أو دقيقاً بنسبة 100%».

من أنحاء القطاع

• Google تؤكد مجدداً أن البيانات المنظمة لا تجعل موقعك يحقق ترتيباً أفضل (Search Engine Roundtable) — تصريح Mueller في أبريل 2025 الذي يفند الخرافة وراء هذا الدليل كله.
• Google لا تقتل Schema — قد تظهر أنواع الترميز وتختفي (Search Engine Roundtable) — تأطير «أنواع الترميز تظهر وتختفي، لكن هناك عدداً قليلاً ثميناً ينبغي التمسك به».
• قد يستخدم Bing ترميز ProductGroup في المستقبل (Search Engine Roundtable) — تصريح Fabrice Canel في سبتمبر 2024 عن عدم دعم Bing لـProductGroup.
• التزم بإرشادات البيانات المنظمة إذا أردت النتيجة الغنية (Search Engine Land) — Mueller عن أن الأهلية تتطلب الترميز الصحيح والامتثال للسياسات.
• تسلسل أنواع schema.org — المفردات نفسها مباشرةً من المصدر؛ راجع مجموعة «Product وOffer وAggregateOffer» وموضع JobPosting، وموضعه غير الموجود معها.

سجل التغييرات