مخطط AggregateRating

الخلاصة — AggregateRating هو ترميز تضيفه إلى الصفحة ليقول إن متوسط تقييم هذا العنصر هو ٤٫٦ نجمة من بين عدد محدد من التقييمات. وهو ما يفعّل مقتطف النجوم ⭐ الذي يظهر أسفل بعض نتائج البحث. غالباً ما تُدخله داخل ترميز العنصر المقيَّم (منتج أو وصفة أو نشاط تجاري)، لكن Google تسمح أيضاً بصيغة مستقلة تسمي العنصر المقيَّم مباشرة؛ يظل التداخل هو النمط المعتاد. ولا يمكنك تقييم نشاطك التجاري بنفسك ثم توقع ظهور النجوم، لأن Google تحظر ذلك.

ما هو مخطط AggregateRating

عندما تعرض الصفحة شيئاً مثل “٤٫٦ ★ (218 تقييماً)” يقرأه الإنسان في لمح البصر، بينما ترى محركات البحث نصاً عادياً وتحاول تخمين معنى الأرقام. يوضح AggregateRating ذلك في الشيفرة باستخدام مفردات schema.org المشتركة: فهو يحدد المتوسط وعدد التقييمات التي بُني عليها والمقياس.

الكلمة المفتاحية هي aggregate؛ أي متوسط تقييمات كثيرة. وهذا يختلف عن Review schema الذي يرمّز رأي شخص واحد المكتوب. تستخدم الصفحات التي تجمع النوعين كليهما عادةً: AggregateRating واحد للمتوسط العام، وعدداً من Reviews الفردية.

يُكتب هذا الترميز تقريباً دائماً بصيغة JSON-LD، وهي كتلة شيفرة صغيرة توضع في الصفحة من دون أن تغيّر شكلها الظاهر.

لماذا يستحق التطبيق

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

• ratingValue — متوسط الدرجة، مثل 4.6.
• عدد واحد على الأقل — إما ratingCount (إجمالي التقييمات) أو reviewCount (عدد من تركوا مراجعة، مع تقييم نجمي أو بدونه). يكفي توفير أحدهما.
• itemReviewed — العنصر المقيَّم. إذا أدخلت AggregateRating داخل المنتج أو الوصفة أو غيرهما، يغطي التداخل هذا الحقل ويمكن حذفه؛ لكن اسم العنصر المقيَّم مطلوب في كلتا الحالتين. Evidence for this claim Google supports aggregate ratings in review snippets only for eligible item types and qualifying content. Scope: Google Search review snippet requirements; stars are not guaranteed. Confidence: high · Verified: 2026-07-14 Google: Review snippet structured data

يمكنك اختيارياً استخدام bestRating وworstRating لوصف المقياس (تفترض Google مقياس 1–5 عند حذفهما).

أكثر ما يخطئ فيه الناس

لا يمكنك إضافة AggregateRating إلى نشاطك التجاري والحصول على نجوم. إذا كنت تدير نشاطاً محلياً أو موقع شركة ووسمت عبارة مثل «عملاؤنا يقيموننا بـ4.9 نجمة»، فلن تعرض Google تلك النجوم. تسمي ذلك تقييماً ذاتياً؛ أي أن النشاط يقيّم نفسه، وتحظره Google تحديداً في ترميز LocalBusiness وOrganization.

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

فخّان آخران للمبتدئين:

• تحتاج دائماً إلى عدد، لا إلى متوسط فقط. عبارة «٤٫٦ نجمة» بلا عدد للتقييمات التي تقف خلفها لا تكفي.
• يجب أن تكون التقييمات حقيقية. تزويرها أو شراؤها لا يخالف القواعد فحسب، بل قد يؤدي إلى إجراء يدوي على صفحتك يزيل النتائج الغنية.

هل تريد الخصائص المطلوبة بدقة، والفرق بين ratingCount وreviewCount، ونطاق قاعدة التقييمات الذاتية كاملاً، وطريقة إصلاح أخطاء Search Console الشائعة؟ انتقل إلى علامة Advanced.

الخلاصة — يُوضَع AggregateRating عادةً داخل خاصية aggregateRating لنوع أب مثل (Product وLocalBusiness وRecipe وBook وCourse وEvent وMovie وSoftwareApplication وغيرها)، ولذلك تحذف الأمثلة المتداخلة itemReviewed. لكن مواصفة Google تدعم أيضاً AggregateRating مستقلاً يسمي itemReviewed مباشرة؛ وفي الحالتين يحتاج العنصر المقيَّم إلى اسم. الخصائص المطلوبة لنتيجة النجوم الغنية هي ratingValue وواحد على الأقل من ratingCount/reviewCount وitemReviewed عند عدم التداخل؛ أما bestRating/worstRating فموصى بهما (وهما أساسيان للمقاييس غير 1–5). وللدقة: التقييمات الذاتية غير مؤهلة لميزة النجوم تحديداً في LocalBusiness/Organization عندما يقيّم النشاط نفسه، بينما تبقى Product وRecipe وMovie ومعظم الأنواع المدعومة مؤهلة للتقييمات الحقيقية. ratingCount (كل التقييمات، ومنها النجوم فقط) وreviewCount (الأشخاص الذين تركوا مراجعة، مع تقييم أو بدونه) رقمان مختلفان. الترميز الصحيح يمنح الأهلية للنجوم لا ترتيباً أعلى، والتقييمات المصطنعة قد تؤدي إلى إجراء يدوي للبيانات المنظمة. وتظهر هذه الصفحة أيضاً ضمن البيانات المنظمة وSEO للتجارة الإلكترونية لأن ترميز التقييمات بند متكرر في تدقيق المتاجر.

AggregateRating مقابل Review — الفرق الذي يتوقف عليه كل شيء

تخلط أدلة المنافسين غالباً النوعين في قائمة متطلبات واحدة، لكنهما مختلفان:

• Review يرمّز رأي مراجع واحد في عنصر ما: شخصاً واحداً وreviewRating واحداً ونص المراجعة.
• AggregateRating يرمّز المتوسط الإحصائي لتقييمات كثيرة: ratingValue مع عدد.

تستخدم تطبيقات كثيرة النوعين معاً داخل النوع الأب نفسه: aggregateRating للدرجة الكلية ومصفوفة من كائنات review للآراء الفردية. توجيه Google يسير في اتجاه واحد: إذا كنت ترمّز عدة مراجعات فردية فأضف AggregateRating بجانبها. هذا لا يعني أن AggregateRating المستقل يحتاج إلى كائنات Review مختلقة؛ فالصفحة التي تحمل المجمع وحده، بلا مراجعات فردية، تطبيق طبيعي مكتمل. احفظ الجملة التالية: Review = رأي واحد، وAggregateRating = متوسط آراء كثيرة. ولجانب المراجع الواحد راجع الشقيق Review schema.

متداخل أم مستقل — طريقتان صحيحتان لربطه

لا يحمل AggregateRating معنى مستقلاً على صفحته وحدها، لكنه ليس محصوراً بقاعدة «إما التداخل أو لا شيء». تدعم Google شكلين:

• متداخل (النمط الشائع): يقع AggregateRating داخل خاصية aggregateRating لنوع آخر (Product وLocalBusiness وRecipe وبقية القائمة المدعومة أدناه). ولأن النوع الأب يحدد العنصر أصلاً، يحذف AggregateRating المتداخل itemReviewed، لكن يجب أن يظل للعنصر الأب name.
• مستقل: يمكن لـAggregateRating أن يقف وحده بشرط أن يوفّر itemReviewed الذي يسمي العنصر المقيَّم. هذا أقل شيوعاً عملياً، لكنه مسار موثق وصحيح وليس حيلة التفاف.

يحتاج كلا الشكلين إلى اسم العنصر المراجع في مكان ما: في النوع الأب عند التداخل، وداخل itemReviewed عند الاستقلال. وأنواع المضيف التي تدعمها Google لنتيجة المراجعة والنجوم قائمة محدودة: Book وCourse وEvent وLocalBusiness وMovie وProduct وRecipe وSoftware App، إضافة إلى أنواع التداخل CreativeWorkSeason وCreativeWorkSeries وEpisode وGame وMediaObject وMusicPlaylist وMusicRecording وOrganization.

النتيجة العملية: وضع aggregateRating على نوع غير مدعوم لن يعرض النجوم حتى لو اجتاز الترميز التحقق. فالتحقق من الصحة وأهلية النتيجة الغنية حاجزان مختلفان.

الخصائص المطلوبة والموصى بها

هذه مواصفة Google لنتيجة النجوم الغنية، وهي أشد من schema.org المجردة. يعتمد صف itemReviewed على الشكل الذي تستخدمه:

تتسبب قاعدتان من ملاحظات استعمال schema.org في أخطاء تحقق يمكن تجنبها: استخدم أرقاماً حقيقية (0–9) لا رموز Unicode شبيهة بها، واستخدم نقطة للفاصل العشري لا فاصلة. القيمة "4,6" خطأ شائع في اللغات التي تستخدم الفاصلة العشرية.

ratingCount مقابل reviewCount — فرق حقيقي

تستخدم أدلة كثيرة المصطلحين بالتبادل أو تختزل reviewCount إلى «المراجعات المكتوبة». لكن تعريفات الخصائص الحالية في Google أدق:

• ratingCount — العدد الإجمالي للتقييمات، بما فيها الإرسالات ذات النجوم فقط بلا نص مراجعة مرافق.
• reviewCount — عدد الأشخاص الذين قدموا مراجعة، مع تقييم مرافق أو بدونه. لا يقتصر على «المراجعات المكتوبة»؛ فالمعيار هو الأشخاص الذين راجعوا، سواء أتركوا رقماً أم لا.

عملياً، تختلف القيمتان في معظم منصات التقييم والمراجعة، لأن من يترك نجمة لا يكتب دائماً مراجعة، ومن يكتب مراجعة لا يرفق دائماً نجمة. قد يعرض متجر ٤٫٦ نجمة من ratingCount قدره ١٬٢٠٠، بينما ترك ٣٤٠ شخصاً (reviewCount) نص مراجعة فعلياً. طبّق التعريفين على طريقة منصتك في فصل «المقيَّمين» عن «المراجعين»، ولا تفترض أن تقسيمها يطابق المثال حرفياً. تطلب Google واحداً على الأقل من الخاصيتين؛ فزوّدها بما تتتبعه منصتك فعلاً، ولا تضخّم أياً منهما إلى رقم لا تسنده الصفحة.

bestRating / worstRating — أدرجهما خارج المقياس الافتراضي

تفترض Google مقياس 1–5 عند غياب هاتين الخاصيتين. إذا كان تقييمك من 1–10 أو من 100 أو من أي نطاق غير افتراضي، يجب تعيين bestRating/worstRating وإلا فسرت Google المقياس خطأً؛ فالدرجة 9.2 من عشرة، إذا تُركت بلا وصف، ستُفهم كـ٩٫٢ من خمسة، وهو معنى غير منطقي.

قاعدة التقييمات الذاتية — نطاقها بدقة

هذه أكثر نقطة جرى تشويهها في الموضوع، لذلك سأذكرها كما هي.

تقول صياغة Google: “If the entity that’s being reviewed controls the reviews about itself, their pages that use LocalBusiness or any other type of Organization structured data are ineligible for star review feature.” (ترجمة) «إذا كان الكيان المراجَع يسيطر على المراجعات المتعلقة به، فصفحاته التي تستخدم LocalBusiness أو أي نوع Organization غير مؤهلة لميزة مراجعة النجوم.» اقرأ النطاق بعناية؛ فهي تسمي LocalBusiness و**Organization** (والأنواع الفرعية لهما). المقصود نشاط يقيّم نفسه بوصفه نشاطاً. Evidence for this claim Google requires ratings represented in structured data to be visible to users and prohibits misleading or fabricated review markup. Scope: Google Search structured-data and review snippet policies; violations can remove feature eligibility. Confidence: high · Verified: 2026-07-14 Google: Review snippet structured data

لا تنطبق القاعدة على Product. يستطيع متجر إلكتروني عرض نجوم بصورة مشروعة في صفحات منتجاته؛ فهذه متوسطات تقييمات حقيقية لمنتج يبيعه، وليست تقييماً للنشاط نفسه. وتبقى Recipe وMovie وBook وSoftwareApplication وبقية القائمة المدعومة مؤهلة أيضاً، ما دامت التقييمات حقيقية.

تعود هذه القاعدة إلى تغيير في سياسة Google في سبتمبر 2019 بعنوان “Making Review Rich Results more helpful”، وقد قدم إطار «التقييم الذاتي»؛ ويشمل ذلك مراجعات نشاطك المضمنة مباشرة أو المسحوبة عبر أداة خارجية. (أعيد هنا صياغة سبب الإعلان لا اقتباسه؛ أما العبارة الحالية القابلة للاستشهاد فهي توثيق Review snippet المقتبس أعلاه.) والخلاصة أن أداة مراجعات خارجية في صفحة LocalBusiness/Organization الخاصة بك تظل تقييماً ذاتياً وغير مؤهلة للنجوم.

ولهذا تحديداً يكون الشقيق Organization schema ذا صلة: Organization أحد نوعي المضيف اللذين لا تكسب فيهما التقييمات التي يستضيفها النشاط نفسه نجومًا.

التقييمات الحقيقية فقط — سياسة الرسائل المزعجة والإجراء اليدوي

تضع إرشادات Google قاعدتين واضحتين:

• لا تجمع التقييمات من مواقع أخرى. تقول Google: “Don’t aggregate reviews or ratings from other websites.” لذا فإن كشط تقييمات من مصدر آخر وإدخالها في ترميزك مرفوض.
• يجب أن تأتي التقييمات من مستخدمين حقيقيين. تصوغ سياسات البيانات المنظمة التقييمات الحقيقية بوصفها شرطاً مُطبَّقاً لا أملاً؛ ويذكر مثال الوصفات أن “reviews or ratings not by actual users may result in manual action.” وينطبق المبدأ نفسه على سياسة المراجعات في الأنواع المختلفة.

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

موضع AggregateRating في الصورة الأوسع

مثل كل البيانات المنظمة، يؤثر AggregateRating في أهلية النتيجة الغنية لا في الترتيب؛ وتشرح محاور Schema Markup وStructured Data ذلك بالتفصيل، فلا أعيده هنا. خاصية aggregateRating موصى بها في Product (أكثر المضيفين شيوعاً عملياً) وفي ProductGroup لتجميع تقييمات المتغيرات، وهما قراءتان تاليتان طبيعيتان. استخدم JSON-LD؛ فهو الصيغة التي توصي بها Google والتي تستخدمها كل أمثلة هذه المقالة.

Bing ومحركات أخرى: schema.org مفردات مشتركة بين Google وMicrosoft وYahoo وYandex، وتؤكد وثائق Bing العامة للبيانات المنظمة أنها تقرأ ترميز schema.org/JSON-LD. لكن لا يمكن حالياً التحقق من وثائق Microsoft الأولية من ادعاء أن متطلبات Bing النوعية لـAggregateRating تطابق Google؛ فلا تنشر Bing جدولاً مماثلاً للخصائص المطلوبة والموصى بها لكل نوع، ولا سياسة موثقة للتقييمات الذاتية كما تفعل Google، كما أن سطح النتائج الغنية للتقييمات لديها أضيق وأقل توثيقاً. لا تفترض تطابق أهلية Bing مع Google نقطة بنقطة؛ تعامل مع الأمر كسؤال مفتوح حتى تنشر Bing إرشادات خاصة بـAggregateRating.

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

خلاصة مركزة للنسخة المتقدمة:

• ما هو: ترميز schema.org/AggregateRating (غالباً بصيغة JSON-LD) لمتوسط تقييمات أو مراجعات كثيرة لعنصر، في مقابل Review الذي يمثل رأي مراجع واحد. تستخدم صفحات كثيرة النوعين معاً؛ وتطلب Google المجمع عندما تكون قد وسمت عدة مراجعات فردية، لا العكس.
• متداخل أم مستقل: يُوضَع AggregateRating عادةً داخل خاصية aggregateRating لنوع أب (Product وLocalBusiness وRecipe وBook وCourse وEvent وMovie وSoftwareApplication وغيرها)، ولذلك تحذف الأمثلة المتداخلة itemReviewed؛ لكن Google تدعم أيضاً AggregateRating مستقلاً يسمي itemReviewed مباشرة، وفي كلتا الحالتين يحتاج العنصر إلى اسم.
• المطلوب لنتيجة النجوم: ratingValue وواحد على الأقل من ratingCount/reviewCount وitemReviewed عند عدم التداخل. والموصى به bestRating/worstRating، وهما أساسيان خارج مقياس 1–5 الافتراضي.
• ratingCount مقابل reviewCount: ratingCount = كل التقييمات، بما فيها النجوم فقط؛ وreviewCount = الأشخاص الذين تركوا مراجعة مع تقييم أو بدونه. الرقمان مختلفان، وتحتاج إلى أحدهما.
• قاعدة التقييمات الذاتية، بنطاقها الدقيق: التقييمات الذاتية غير مؤهلة للنجوم فقط في LocalBusiness/Organization عندما يقيّم النشاط نفسه، وهي قاعدة ظهرت في سبتمبر 2019. تبقى Product وRecipe وMovie وغيرها مؤهلة للتقييمات الحقيقية، وتظل أداة خارجية لمراجعات نشاطك تقييماً ذاتياً.
• أنواع المضيف المدعومة محدودة: Book وCourse وEvent وLocalBusiness وMovie وProduct وRecipe وSoftware App، مع أنواع تداخل إضافية. على النوع غير المدعوم لن تظهر النجوم حتى لو اجتاز الترميز التحقق.
• التقييمات الحقيقية فقط: “Don’t aggregate reviews or ratings from other websites,” وقد تؤدي التقييمات المزيفة أو المحفَّزة إلى إجراء يدوي على البيانات المنظمة يزيل أهلية النتيجة الغنية.
• التنسيق: أرقام حقيقية (0–9) وفاصل عشري نقطة لا فاصلة.
• الأهلية ≠ الترتيب: الترميز الصحيح يجعل الصفحة مؤهلة للنجوم فقط، وليس عامل ترتيب. تقرأ Bing المفردات نفسها، لكن لا تملك توثيق أهلية مماثلاً.

التوثيق الرسمي

مراجع المصدر الأول الخاصة بـAggregateRating.

schema.org (المفردات)

• نوع AggregateRating — تعريف النوع الأساسي وقائمة الخصائص (itemReviewed وratingCount وreviewCount وratingValue/bestRating/worstRating الموروثة)، وملاحظات استعمال الأرقام والفاصل العشري.

Google — جانب الأهلية والمتطلبات

• بيانات Review snippet (Review وAggregateRating) المنظمة — المواصفة المرجعية للخصائص المطلوبة وقائمة أنواع المضيف ونطاق التقييمات الذاتية (LocalBusiness/Organization) وقاعدة «لا تجمع من مواقع أخرى».
• الإرشادات العامة للبيانات المنظمة — سياسات الرسائل المزعجة ولغة الإجراء اليدوي وشرط التقييمات الحقيقية.
• Making Review Rich Results more helpful (سبتمبر 2019) — أصل سياسة التقييمات الذاتية، ويُستشهد به لسياق متى ولماذا تغيرت.
• Rich Results Test — للتحقق من الترميز وفحص أهلية تقييم النجوم.

Bing / Microsoft

• ترميز موقعك بالبيانات المنظمة — دعم Bing العام للبيانات المنظمة (schema.org وJSON-LD).

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

تصريحات مسجلة من schema.org وGoogle. وحيث تعرض صفحة المصدر النص، يأخذ الرابط القارئ إلى الموضع المقتبس مباشرة.

schema.org — تعريف النوع

• “The average rating based on multiple ratings or reviews.” (ترجمة) «متوسط التقييم المبني على تقييمات أو مراجعات متعددة.» انتقل إلى الاقتباس

وثائق Google — ترميز التقييم المجمع

• “Make sure to mark up an aggregate evaluation of an item by many people with schema.org/AggregateRating.” (ترجمة) «احرص على ترميز تقييم مجمع لعنصر من أشخاص كثيرين باستخدام schema.org/AggregateRating.» انتقل إلى الاقتباس

وثائق Google — قاعدة التقييمات الذاتية (بنطاق LocalBusiness/Organization)

• “If the entity that’s being reviewed controls the reviews about itself, their pages that use LocalBusiness or any other type of Organization structured data are ineligible for star review feature.” (ترجمة) «إذا كان الكيان المراجَع يسيطر على المراجعات المتعلقة به، فإن صفحاته التي تستخدم LocalBusiness أو أي نوع آخر من بيانات Organization المنظمة غير مؤهلة لميزة مراجعة النجوم.» انتقل إلى الاقتباس

وثائق Google — لا تجمع من مواقع أخرى

• “Don’t aggregate reviews or ratings from other websites.” (ترجمة) «لا تجمع المراجعات أو التقييمات من مواقع ويب أخرى.» انتقل إلى الاقتباس

Google — سياسات البيانات المنظمة (الخداع أو التضليل والإجراء اليدوي)

• “Don’t use structured data to deceive or mislead users. Don’t impersonate any person or organization.” (ترجمة) «لا تستخدم البيانات المنظمة لخداع المستخدمين أو تضليلهم، ولا تنتحل شخصية أي شخص أو منظمة.» انتقل إلى الاقتباس
• بشأن التقييمات الحقيقية (مثال خاص بالوصفات وقابل للتعميم على سياسة المراجعات): “reviews or ratings not by actual users may result in manual action.” (ترجمة) «قد تؤدي المراجعات أو التقييمات التي لا يقدمها مستخدمون حقيقيون إلى إجراء يدوي.» الإرشادات العامة للبيانات المنظمة

AggregateRating أم Review — أيهما أحتاج؟

أجب عن الأسئلة بالترتيب:

1. هل ترمّز رأي شخص واحد أم متوسط آراء كثيرة؟

• رأي مراجع واحد (تقييم منفرد مع نص مراجعة) ← تحتاج Review schema لا AggregateRating.
• المتوسط عبر تقييمات كثيرة ← تحتاج AggregateRating. تابع.
• كلاهما (درجة عامة وآراء فردية) ← استخدم كليهما متداخلين في النوع الأب نفسه: aggregateRating واحد ومصفوفة كائنات review.

2. هل ستضعه متداخلاً أم مستقلاً؟

• التداخل داخل Product (أو ProductGroup) أو Recipe أو Movie أو Book أو Course أو Event أو SoftwareApplication ← مضيف مدعوم؛ التقييمات الحقيقية مؤهلة عادةً للنجوم، ويمكن حذف itemReviewed لأن النوع الأب يسمي العنصر. تابع.
• تقييم LocalBusiness أو Organization لنفسه ← توقف. التقييم الذاتي هنا غير مؤهل لميزة النجوم، حتى لو اجتاز الترميز التحقق.
• عدم التداخل إطلاقاً ← لا مشكلة، ما دام AggregateRating يوفّر itemReviewed الذي يسمي العنصر المقيَّم مباشرة.
• نوع أب آخر غير موجود في قائمة Google المدعومة ← قد يجتاز الترميز التحقق، لكن النجوم لن تظهر لأنه مضيف غير مدعوم.

3. هل لديك الخصائص المطلوبة؟

• أكد وجود ratingValue وواحد على الأقل من ratingCount/reviewCount. وإذا لم يكن الترميز متداخلاً فأضف itemReviewed أيضاً؛ ففي كل الحالات يحتاج العنصر المقيَّم إلى اسم. غياب العدد هو الفشل رقم واحد.
• هل المقياس خارج 1–5؟ أضف bestRating/worstRating وإلا قد تسيء Google قراءته.

4. هل التقييمات حقيقية وموجودة في الصفحة؟

• تقييمات حقيقية من المستخدمين، تخص هذا العنصر المحدد، وتظهر في الصفحة نفسها ← جيد.
• مجمعة من مواقع أخرى أو مصطنعة أو محفَّزة ← لا تفعل ذلك؛ فأنت تخاطر بإجراء يدوي على البيانات المنظمة، لا بمجرد غياب المقتطف.

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

خرافات وأخطاء AggregateRating التي يجب تجنبها

الخرافة: «أستطيع إضافة AggregateRating إلى Organization/LocalBusiness والحصول على نجوم مثل المنتج». لا. تستبعد Google صراحةً التقييمات الذاتية على LocalBusiness/Organization من ميزة مراجعة النجوم؛ فـ*“pages that use LocalBusiness or any other type of Organization structured data are ineligible for star review feature”* (ترجمة) «الصفحات التي تستخدم LocalBusiness أو أي نوع من بيانات Organization غير مؤهلة لميزة مراجعة النجوم» عندما يسيطر الكيان على مراجعاته. وهذه القاعدة قائمة منذ تغيير سياسة سبتمبر 2019. لا يحصل النشاط على نجوم عندما يقيّم نفسه، بينما يستطيع المتجر الحصول عليها عند تقييم منتجاته بتقييمات حقيقية.

الخرافة: «AggregateRating وReview الشيء نفسه». يرمّز Review رأي مراجع واحد، بينما يرمّز AggregateRating متوسط آراء كثيرة. النوعان والخصائص المطلوبة مختلفان. قد تستخدم الصفحة النوعين متداخلين، لكنهما غير قابلين للاستبدال، واستخدام المجمع لا يلزمك باختلاق كائنات Review فردية.

الخرافة: «أحتاج ratingValue فقط؛ العدد لا يهم». تطلب Google واحداً على الأقل من ratingCount أو reviewCount إلى جانب ratingValue. متوسط مجرد بلا حجم عينة خلفه غير مؤهل.

الخرافة: «ratingCount وreviewCount العدد نفسه». هما مختلفان. يشمل ratingCount الإرسالات ذات النجوم فقط بلا نص مراجعة، بينما يمثل reviewCount عدد الأشخاص الذين تركوا مراجعة مع تقييم أو بدونه؛ ولا يقتصر على «المراجعات المكتوبة». قد تحتوي الصفحة على ١٬٢٠٠ تقييم، لكن ٣٤٠ شخصاً فقط تركوا مراجعة. زوّد Google بالقيمة التي تتتبعها منصتك فعلاً، ولا تضخّم أياً منهما.

الخرافة: «أداة مراجعات خارجية في صفحة نشاطي تؤهلني تلقائياً للنجوم». إذا كانت الأداة تعرض مراجعات عن نشاطك أو منظمتك، حتى لو جاءت من منصة خارجية، فهي تظل تقييماً ذاتياً وغير مؤهلة لعرض نجوم LocalBusiness/Organization.

الخرافة: «تقييمات الخمس نجوم المزيفة أو المحفَّزة تخاطر فقط بعدم ظهور المقتطف». تتعامل Google مع شرط التقييمات الحقيقية باعتباره مُطبَّقاً؛ فقد تؤدي التقييمات المصطنعة إلى إجراء يدوي على البيانات المنظمة يزيل أهلية النتيجة الغنية للصفحة، لا إلى إخفاء مقتطف فحسب.

الخرافة: «مخطط AggregateRating يحسن الترتيب». مثل كل ترميز schema، يؤثر في أهلية النتيجة الغنية لا الترتيب؛ فهو يمنح أهلية نجوم لا موضعاً أعلى. ويشرح محور Structured Data هذه النقطة بالتفصيل.

الخطأ: تجميع التقييمات من مواقع أخرى. تقول إرشادات Google بوضوح: “Don’t aggregate reviews or ratings from other websites.” استخدم فقط التقييمات التي جمعتها صفحتك فعلياً.

الخطأ: تنسيق ratingValue بصورة غير صحيحة. استخدم أرقاماً حقيقية وفاصلة عشرية نقطية (4.6 لا 4,6 ولا رمز Unicode شبيه). الفاصلة العشرية خطأ تحقق شائع يمكن تجنبه.

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

JSON-LD نظيف مقابل JSON-LD معطّل في AggregateRating

تقييم مجمع متداخل ونظيف

AggregateRating متداخل بصورة صحيحة داخل Product، مع متوسط وعدد صحيحين وتحديد للمقياس، ومعه review واحد (وهو النمط الشائع عملياً):

{
  "@context": "https://schema.org/",
  "@type": "Product",
  "name": "Trailhead 30L Hiking Backpack",
  "image": "https://example.com/img/backpack.jpg",
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.6",
    "bestRating": "5",
    "worstRating": "1",
    "ratingCount": "1200",
    "reviewCount": "340"
  },
  "review": [
    {
      "@type": "Review",
      "author": { "@type": "Person", "name": "James Smith" },
      "reviewRating": {
        "@type": "Rating",
        "ratingValue": "5",
        "bestRating": "5"
      },
      "reviewBody": "Comfortable on long days, great ventilation."
    }
  ]
}

لاحظ أن ratingCount (١٬٢٠٠ تقييم إجمالاً) وreviewCount (٣٤٠ شخصاً تركوا مراجعة) رقمان مختلفان، كما يحدث عادةً في الواقع.

الصيغة المستقلة

التداخل هو النمط الشائع، لكن لا يلزم أن يقع AggregateRating داخل Product أو أي مضيف آخر. يمكنه الوقوف وحده بشرط توفير itemReviewed الذي يسمي العنصر المقيَّم؛ فهذا شكل موثق وصحيح، وليس حيلة التفاف:

{
  "@context": "https://schema.org/",
  "@type": "AggregateRating",
  "itemReviewed": {
    "@type": "Product",
    "name": "Trailhead 30L Hiking Backpack"
  },
  "ratingValue": "4.6",
  "bestRating": "5",
  "worstRating": "1",
  "ratingCount": "1200",
  "reviewCount": "340"
}

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

المجمع نفسه ولكنه معطّل

كل سطر مشار إليه أدناه يمثل فشل تحقق حقيقياً وشائعاً:

{
  "@context": "https://schema.org/",
  "@type": "Product",
  "name": "Trailhead 30L Hiking Backpack",
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4,6"
  }
}

ما الخطأ؟

• لا يوجد ratingCount أو reviewCount — فينتج الخطأ المعتاد “Either ‘ratingCount’ or ‘reviewCount’ should be specified”. يحتاج المجمع إلى حجم عينة.
• ratingValue: "4,6" — فاصل عشري بفاصلة؛ استخدم نقطة: "4.6".
• لا يوجد bestRating/worstRating — يمكن التسامح مع ذلك في مقياس 1–5، لكن حذفهما خارج المقياس الافتراضي يجعل Google تسيء قراءة المقياس.

والخطأ الذي ينجح في التحقق لكنه لا يعرض النجوم: وضع aggregateRating نفسه على LocalBusiness أو Organization يقيّم نفسه؛ فهذا تقييّم ذاتي غير مؤهل لميزة النجوم مهما كان الترميز نظيفاً.

أخطاء Search Console / Rich Results Test الشائعة ← الإصلاحات

أدوات إنشاء ترميز AggregateRating وفحصه

أبدأ عادةً بأداة Schema Markup Validator بعد كتابة JSON-LD. ألصق الكتلة (أو الصفحة كاملة) فتشغّل فحوصاً بدرجات خطورة على مفردات AggregateRating في schema.org ومتطلبات Google للنتائج الغنية. تلتقط خطأ غياب العدد، وخطأ الفاصلة العشرية، ومشكلات مقياس bestRating/worstRating المذكورة أعلاه، ثم تعيد كتلة JSON-LD مصححة قابلة للنسخ واللصق.

تجيب أداة Rich-Result Eligibility Checker عن سؤال مختلف: ليس «هل JSON-LD صالح؟» بل «هل هذه الصفحة المحددة مؤهلة لنتيجة Google الغنية بالنجوم؟». ألصق JSON-LD أو صفحة HTML أو اجلب عنواناً حياً، وستعرض الأداة لكل نوع الخصائص المطلوبة (itemReviewed وratingValue وratingCount/reviewCount) الموجودة والمفقودة، وكذلك الخصائص الموصى بها (bestRating وworstRating) التي تركتها خارج المقياس الافتراضي.

إذا كنت تبدأ من صفحة فارغة لا تصلح ترميزاً قائماً، فتوفر Schema Markup Generator نموذجاً مركزاً لبناء aggregateRating متداخلاً داخل Product أو أي نوع مضيف مدعوم آخر، من دون كتابة JSON-LD يدوياً. وتوضح الأداة أثناء الملء ما إذا كانت كل خاصية مطلوبة من Google أو موصى بها منها أو خاصة بـschema.org فقط.

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

مشكلات AggregateRating الشائعة وكيفية إصلاحها

الترميز صالح، لكن النجوم لا تظهر أبداً في نتائج البحث

السبب الأرجح هو قاعدة التقييمات الذاتية: يقع aggregateRating داخل LocalBusiness أو Organization ويقيّم النشاط نفسه. تستبعد Google هذا الاقتران من ميزة النجوم كلياً مهما كان JSON-LD نظيفاً. افحص النوع الأب أولاً؛ فإذا كان LocalBusiness أو Organization فانقل النقاش إلى مراجعات حقيقية على مستوى المنتج، لأن النشاط لا يكسب نجومًا بتقييم نفسه، بينما يستطيع المتجر تقييم منتجاته. والسبب الثاني المحتمل هو نوع مضيف غير مدعوم: إذا تداخل aggregateRating في نوع خارج قائمة Google (Book وCourse وEvent وLocalBusiness وMovie وProduct وRecipe وSoftwareApplication والقائمة الإضافية الأصغر)، فقد يجتاز التحقق لكنه لن يعرض النجوم.

يعرض Rich Results Test أو Search Console الخطأ «Either ‘ratingCount’ or ‘reviewCount’ should be specified»

يفتقد كائن aggregateRating خاصية حجم العينة. لا يكفي ratingValue وحده؛ فتطلب Google واحداً على الأقل من ratingCount أو reviewCount إلى جانبه. أضف القيمة التي تطابق ما تتتبعه منصتك (إجمالي التقييمات بما فيها النجوم فقط، أو عدد الأشخاص الذين تركوا مراجعة)، ثم أعد الاختبار.

يفشل ratingValue في التحقق رغم أن الرقم يبدو صحيحاً

ابحث عن فاصل عشري بفاصلة ("4,6" بدلاً من "4.6") أو عن رقم Unicode شبيه بدلاً من محرف حقيقي من 0–9. كلاهما سبب شائع في اللغات التي تنسق الكسور بالفواصل، وكلاهما خطأ يبدو غير مرئي حتى يبلّغ عنه المدقق.

خطأ المدقق: «يجب أن تكون قيمة أفضل تقييم أكبر من أسوأ قيمة تقييم»

قد تكون قيمتا bestRating وworstRating معكوستين، أو قد تكون worstRating مفقودة فيُطبَّق افتراض Google من 1–5 خلافاً لمقياسك الفعلي (فالدرجة من 1–10 أو من 100، إذا لم توصف، تُساء قراءتها على مقياس 1–5). عيّن القيمتين صراحةً، مثل worstRating: 1 وbestRating: 5، كلما لم يكن المقياس افتراضياً.

يعرض Search Console عناصر صالحة، لكن النجوم لا تظهر في SERP الحي

لا يعني اجتياز التحقق وظهور حالة «Valid» في Search Console إلا أن الصفحة مؤهلة للنتيجة الغنية بالنجوم؛ ولا يضمن أن تعرضها Google فعلاً. هذا متوقع وليس عطلاً يستحق المطاردة: الأهلية تؤثر في إمكانية النتيجة الغنية، لا في وعد بالعرض أو الترتيب. إذا كان الترميز صالحاً ومؤهلاً حقاً فلا شيء آخر لإصلاحه في جانب الترميز.

اختفت النتائج الغنية بعد أن كانت تظهر

يؤدي الإجراء اليدوي على البيانات المنظمة بسبب تقييمات مصطنعة أو مجمعة من مصادر أخرى إلى إزالة أهلية النتيجة الغنية. افحص تقرير Manual Actions في Search Console أولاً. وإذا لم يوجد إجراء يدوي، فأعد التحقق من الترميز الحالي؛ فقد يكسر تغيير في القالب أو CMS خاصيةً بصمت (عدد مفقود أو مقياس معاد كتابته) كانت صحيحة في السابق.

إثبات نجاح تغيير AggregateRating

الاختبار 1: التحقق من صياغة JSON-LD والخصائص المطلوبة

الاختبار: ألصق JSON-LD المحدث في Schema Markup Validator، أو شغّل الصفحة الحية عبر Rich Results Test. النتيجة المتوقعة: لا أخطاء في كتلة AggregateRating، مع وجود ratingValue بأرقام حقيقية وفاصل عشري بنقطة، ووجود ratingCount أو reviewCount واحد على الأقل. تفسير الفشل: تعني خاصية مفقودة أن الخاصية غير موجودة فعلاً في الترميز الذي نشرته، لا مشكلة تخزين مؤقت أو عرض؛ أعد فحص مصدر JSON-LD. نافذة المراقبة: فورية؛ فكلا الأداتين تقرآن الترميز مباشرة ولا تنتظران الزحف. محفز التراجع: إذا استمر الفشل بعد إصلاح مباشر، فتراجع عن تغيير القالب وقارن من جديد بآخر JSON-LD معروف بصحته.

الاختبار 2: أهلية النتيجة الغنية لنوع المضيف المحدد

الاختبار: شغّل أداة Rich-Result Eligibility Checker على العنوان الحي. النتيجة المتوقعة: يظهر النوع الأب للصفحة (مثل Product) مؤهلاً لنتيجة المراجعة والنجوم، مع حل itemReviewed بصورة صحيحة. تفسير الفشل: إذا كان النوع الأب LocalBusiness أو Organization فحالة «غير مؤهل» سلوك متوقع بسبب قاعدة التقييم الذاتي، لا عطلاً؛ أكد نوع المضيف قبل اعتبارها فشلاً. نافذة المراقبة: فورية. محفز التراجع: إذا ظل نوع مؤهل (Product أو Recipe وغيرهما) يعرض أخطاء خصائص مطلوبة بعد الإصلاح، فالنشر لم يحدّث الترميز الذي تراه Google؛ افحص التخزين المؤقت أو خطوة بناء تستبدل التغيير.

الاختبار 3: يعكس تقرير التحسين في Search Console الإصلاح

الاختبار: افتح Search Console ← تقرير Enhancement المناسب (Product snippets أو Merchant listings بحسب نوع المضيف) للعناوين المتأثرة. النتيجة المتوقعة: تنتقل الصفحة من «Invalid» أو «Not eligible» إلى مجموعة «Valid»، وينخفض عدد أخطاء ذلك العنوان إلى الصفر. تفسير الفشل: استمرار الخطأ بعد إعادة زحف Google يعني أن الإصلاح لم يصل إلى الصفحة الحية أو أن خاصية مطلوبة أخرى مفقودة؛ أعد الاختبار الأول على العنوان الحي لا على نسخة staging. نافذة المراقبة: من بضعة أيام إلى نحو أسبوع حتى تعيد Google الزحف وتحدّث التقرير؛ بيانات Search Console تتأخر عن الصفحة الحية. محفز التراجع: إذا ارتفع عدد العناصر غير الصالحة بعد طرح تغيير في القالب بدلاً من انخفاضه، فهذا يدل على كسر الترميز في صفحات أخرى تستخدم القالب نفسه؛ أوقف الطرح.

الاختبار 4: ظهور مقتطف النجوم فعلياً في SERP الحي

الاختبار: أجرِ بحثاً يدوياً عن استعلام تحتل فيه الصفحة ترتيباً، وتحقق من ظهور التقييم النجمي أسفل الإدراج (تجنب نافذة التخصيص باستخدام نافذة خاصة أو متخفية). النتيجة المتوقعة: تظهر النجوم وعدد التقييمات أسفل النتيجة. تفسير الفشل: غياب النجوم مع حالة «Valid» في Search Console ليس فشلاً يحتاج إلى إصلاح؛ فالعرض قرار تقديري من Google وليس مضموناً بمجرد الأهلية. أما الغياب المقترن بحالة «Not eligible» أو إجراء يدوي فيعيدك إلى الاختبار 1 أو 3. نافذة المراقبة: لا تحدد Google زمناً ثابتاً للعرض؛ راقب خلال الأسابيع التالية بدلاً من توقعه فور نجاح التحقق. محفز التراجع: لا يوجد من جانب الترميز؛ فلا شيء للتراجع عنه في قرار عرض تتحكم فيه Google. تراجع فقط إذا أبلغت Manual Actions عن الصفحة.

مؤشرات الأداء المستمرة لترميز AggregateRating

المقياس: عدد العناصر الصالحة (تقرير Enhancement في Search Console) ما الذي يخبرك به: عدد الصفحات المؤهلة التي تحمل حالياً ترميز AggregateRating بلا أخطاء، أي جانب التغطية من المؤشر. طريقة استخراجه: Search Console ← Enhancements ← التقرير المناسب (Product snippets أو Merchant listings) لموقعك. الخط الأساس/النطاق الواقعي: لا هدف موحداً؛ أنشئ خطك الأساس من عدد الصفحات التي ينبغي أن تحمل الترميز (إجمالي صفحات الأنواع المؤهلة)، وتابع اتجاه العناصر الصالحة نحو هذا العدد. الدورية: شهرياً، أو فوراً بعد تغيير في القالب أو CMS يمس ترميز المراجعات.

المقياس: عدد العناصر غير الصالحة/التي بها أخطاء (التقرير نفسه) ما الذي يخبرك به: عدد الصفحات التي تفتقد خصائص مطلوبة أو تكسرها؛ وهو جانب الجودة من المؤشر منفصل عن التغطية. طريقة استخراجه: التقرير نفسه، من مجموعة الخطأ/غير الصالح. الخط الأساس/النطاق الواقعي: الهدف الصادق الوحيد هو الصفر؛ فأي عدد غير صفري صفحة مكسورة حقيقية وليس ضجيجاً إحصائياً. الدورية: شهرياً، ودائماً بعد نشر يلمس قالب الترميز.

المقياس: تغير CTR في الصفحات التي اكتسبت أهلية النجوم ما الذي يخبرك به: هل يحوّل مقتطف النجوم الأهلية إلى نقرات أكثر فعلاً في الصفحات التي بدأت تعرضه، بدلاً من الاكتفاء بقياس الأهلية؟ طريقة استخراجه: تقرير Performance في Search Console، مفلتر على الصفحات المتأثرة، مع مقارنة CTR في الأسابيع السابقة واللاحقة لنشر الترميز (لا يعزل Search Console بسهولة «النقرات الناتجة عن مقتطف النجوم»، لذلك المقارنة قبل/بعد وكيل لا إسناد دقيق). الخط الأساس/النطاق الواقعي: لا يوجد رقم ارتفاع ثابت يمكن الدفاع عنه؛ أنشئ خط أساس CTR قبل الطرح للصفحات نفسها وراقب الفرق، لأنه يتأثر بشدة بالاستعلام والموضع ونتائج المنافسين الغنية. الدورية: شهرياً في الربع الأول بعد الطرح، ثم ربع سنوياً.

المقياس: نمو ratingCount/reviewCount بمرور الوقت ما الذي يخبرك به: هل ينمو حجم العينة خلف المتوسط فعلاً؟ فالعدد الثابت أو المتناقص في صفحة تدعي وجود قاعدة مراجعات نشطة يستحق التحقيق قبل أن يستحق الترميز. طريقة استخراجه: منصة المراجعات أو CMS أو قاعدة بياناتك، أي النظام الذي يمثل مصدر الحقيقة الذي يسحب منه الترميز. الخط الأساس/النطاق الواقعي: تابع النمو الخام مقابل تاريخك أنت؛ لا يوجد معيار خارجي لعدد التقييمات الذي «ينبغي» أن تحويه الصفحة. الدورية: شهرياً.

اختبر نفسك: مخطط AggregateRating

خمسة أسئلة سريعة عن schema.org/AggregateRating وخصائصه المطلوبة وقاعدة التقييمات الذاتية. اختر إجابة لكل سؤال ثم تحقق منها.

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