أخطاء البيانات المنظمة الشائعة وكيفية إصلاحها

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

ما خطأ البيانات المنظمة؟

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

تأتي الأخطاء في شكلين:

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

الأخطاء مقابل التحذيرات — هل يجب أن أصلح هذا اليوم؟

يوفر فهم هذا الفرق كثيرًا من القلق:

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

إذًا فالخطأ يقول «أصلح هذا للحصول على الميزة»، بينما يقول التحذير «يمكنك تحسين هذا». وليس كل ما تشير إليه Google عاجلًا.

أين سترى هذه الأخطاء؟

تظهر في ثلاثة أماكن يخلط الناس بينها باستمرار:

• Rich Results Test — تلصق عنوان URL واحدًا أو مقتطفًا من الشيفرة، فتخبرك Google بالنتائج الغنية التي عثرت عليها وبأي أخطاء، كما تعرض معاينة لشكل النتيجة المحتمل.
• تقرير Rich result في Search Console — عرض مستمر على مستوى الموقع يراقب الأخطاء في صفحاتك عبر الزمن.
• Schema Markup Validator — تديره schema.org لا Google، ويتحقق من صحة كتابة الشيفرة لأي نوع من أنواع المخطط، سواء كانت Google تستخدمه لنتيجة غنية أم لا.

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

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

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

هل تريد التصنيف الكامل لأنواع الأخطاء، ومزالق JSON غير الصالح، ووضع FAQ المتقادم، وكيفية تصحيح كل حالة؟ انتقل إلى علامة التبويب Advanced.

الخلاصة — تنقسم أخطاء البيانات المنظمة إلى أخطاء تحليل، أي JSON-LD غير صالح بسبب فواصل زائدة أو علامات اقتباس غير مسبوقة بمحرف هروب أو نقطتين أو أقواس مفقودة، بما يفسد الترميز إلى درجة تعجز معها Google عن تحديد النوع؛ وتظهر هذه في تقرير Unparsable structured data. أما أخطاء الأهلية فيُحلل فيها الترميز بنجاح لكنه يخالف قاعدة للنتائج الغنية، مثل خاصية مطلوبة مفقودة أو نوع قيمة خاطئ أو ترميز يصف محتوى غير ظاهر في الصفحة. قد تمنع الأخطاء الأهلية، أما التحذيرات فغير حرجة: فقد تلغي الخاصية المطلوبة المفقودة الأهلية، بينما تحافظ الخاصية الموصى بها المفقودة عليها عادةً وإن قلّت المعلومات المتاحة. وعدم تطابق المحتوى هو الفئة ذات العواقب الجدية لأنه مخالفة للسياسة قد تؤدي إلى إجراء يدوي بدل فقدان الأهلية بصمت. وهناك حالة مستقلة ليست خطأ أصلًا: نوع متقادم أو غير مدعوم، مثل FAQ الذي اختفى بحلول مايو 2026، قد يكون صالحًا لكنه لا يمنح مظهرًا مرئيًا. صحح باستخدام ثلاث أدوات مختلفة: Rich Results Test لأهلية Google والمعاينة، وSchema Markup Validator لصياغة schema.org لأي نوع، وتقرير Rich result في Search Console للمراقبة بعينة على مستوى الموقع. والبيانات المنظمة ليست عامل ترتيب؛ لذا يعيد الإصلاح مظهر SERP لا ترتيبًا.

الأخطاء مقابل التحذيرات — ما الذي يمنع النتيجة الغنية فعلًا؟

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

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

تميل إرشادات Google نفسها إلى الدقة بدل الحشو: “it is more important to supply fewer but complete and accurate recommended properties rather than trying to provide every possible recommended property with less complete, badly-formed, or inaccurate data.” (ترجمة) «الأهم هو تقديم عدد أقل من الخصائص الموصى بها، على أن تكون كاملة ودقيقة، بدل محاولة تقديم كل خاصية ممكنة ببيانات أقل اكتمالًا أو سيئة الصياغة أو غير دقيقة». وبعبارة أخرى، لا تطارد كل تحذير بحشو بيانات نصف دقيقة، فقد يخلق ذلك مشكلات أسوأ من التحذير الذي تحاول حله.

ومن المفيد معرفة أن تقارير Google نفسها لا تخلو من الخطأ. ففي أكتوبر 2022 واجهت Search Console خللًا أدى إلى تصنيف بعض المشكلات أخطاءً وهي في الحقيقة تحذيرات؛ فنقلها إصلاح Google “from the critical error table to the warning table,” (ترجمة) «من جدول الأخطاء الحرجة إلى جدول التحذيرات»، وأوضح أن ذلك كان “strictly a reporting issue and did not affect whether or not a rich result could be displayed” (ترجمة) «مشكلة في إعداد التقارير حصرًا، ولم تؤثر في إمكان عرض نتيجة غنية من عدمه» (Search Engine Land ، أكتوبر 2022). والدرس هو أن تقارن العنصر المعلَّم باختبار النتائج الغنية عند الشك بدل الثقة العمياء في تقرير واحد.

JSON-LD غير الصالح — أخطاء «غير قابل للتحليل»

هذه أكثر فئات الأخطاء جوهرية: يكون الترميز معطوبًا إلى درجة أن Google لا تستطيع حتى تحديد النوع المقصود. وتضع Google هذه الحالات في تقرير Unparsable structured data المنفصل بدل تقرير خاص بكل نوع، إذ لا يوجد نوع يمكن نسبة العنصر إليه. ووفق وصف Google يقع العنصر هنا بسبب “serious syntax error” (ترجمة) «خطأ جسيم في الصياغة»، ولأن “the intended type of structured data (Job, Event, and so on) could not be determined because of the parsing error.” (ترجمة) «تعذر تحديد النوع المقصود من البيانات المنظمة (Job أو Event وما إلى ذلك) بسبب خطأ التحليل».

أكثر الأسباب شيوعًا:

• الفواصل الزائدة. الفاصلة بعد آخر خاصية في كائن أو مصفوفة صالحة في JavaScript لكنها غير صالحة في JSON، وهي أكثر طرق تعطل JSON-LD المكتوب يدويًا أو المجمّع من القوالب شيوعًا.
• علامات الاقتباس غير المسبوقة بمحرف هروب. تنهي علامة الاقتباس المزدوجة داخل قيمة نصية السلسلة مبكرًا إن لم تسبقها الشرطة المائلة (\"). وتسمي Google هذا الخطأ “Bad escape sequence in string.” (ترجمة) «تسلسل هروب غير صالح في السلسلة». وتعد أسماء المنتجات ونصوص المراجعات والأوصاف التي تحتوي على علامات البوصة أو عبارات مقتبسة حالات شائعة.
• النقطتان أو الأقواس المفقودة. توثق Google هاتين الرسالتين حرفيًا: “Parsing error: Missing ’:’” (ترجمة) «خطأ تحليل: النقطتان ’:’ مفقودتان»، و*“Parsing error: Missing ’,’ or ’}’”* (ترجمة) «خطأ تحليل: الفاصلة ’,’ أو القوس ’}’ مفقود» — وغالبًا ما ينتجان عن النسخ واللصق أو جمع السلاسل.
• نوع قيمة خاطئ داخل JSON صالح بخلاف ذلك. تسميه Google “Incorrect value type” (ترجمة) «نوع قيمة غير صحيح»، مثل وضع حقل رقمي بين علامتي اقتباس عندما يكون الرقم مطلوبًا. وتتداخل هذه الحالة مع أخطاء الأهلية أدناه؛ فإذا أفسدت التحليل بما يكفي ظهرت هنا.

كيفية التصحيح: ابدأ بكائن فارغ وأعد البناء جزءًا جزءًا

نصيحة Google لتصحيح الترميز غير القابل للتحليل بسيطة: “If you are having problems finding the error, try starting from an empty object, then add back content from your broken code piece by piece.” (ترجمة) «إذا واجهت صعوبة في العثور على الخطأ، فحاول البدء بكائن فارغ، ثم أعد محتوى الشيفرة المعطوبة جزءًا جزءًا» (وثائق Google). الصق الكائن المختصر في Rich Results Test وتأكد من تحليله، ثم أعد الخصائص حتى يتعطل؛ وآخر ما أضفته هو سبب المشكلة.

وهناك تحذير مباشر من Google: قد يؤدي إصلاح خطأ التحليل إلى “might trigger additional warnings or errors that were hidden because the item could not be parsed at all.” (ترجمة) «إظهار تحذيرات أو أخطاء إضافية كانت مخفية لأن العنصر لم يكن قابلًا للتحليل أصلًا». فقد يكشف إصلاح واحد الطبقة التالية، لذلك أعد الاختبار بعد كل تغيير.

الحقول المطلوبة المفقودة وأنواع القيم الخاطئة

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

المطلوبة مقابل الموصى بها، على مستوى الخاصية

لكل نوع تدعمه Google خصائص مطلوبة — حذف واحدة منها يفقدك الأهلية ويعد خطأً — وخصائص موصى بها — يؤدي حذفها إلى تحذير لكن يمكن أن تظل النتيجة الغنية تظهر. وتوصي Search Console بفتح التقرير ثم “click an issue to see affected pages,” (ترجمة) «النقر على مشكلة لرؤية الصفحات المتأثرة»، واستخدام جدول “Why items are invalid” (ترجمة) «لماذا العناصر غير صالحة» لتحديد الأولويات: الأخطاء أولًا ثم التحذيرات.

عدم تطابق الأنواع — نص حيث يُتوقع رقم أو URL أو تاريخ

هذا خطأ أهلية كلاسيكي: القيمة موجودة لكنها من النوع الخطأ. فقد يحتوي حقل سعر على تاريخ، أو يقدم التقييم بوصفه "five stars" بدل رقم، أو يحتوي حقل URL على نص عادي. وتعلّم Google هذه الحالة باعتبارها نوع قيمة غير صالح أو غير متوقع.

تستحق Bing ملاحظة هنا؛ فوفق وثائقها الخاصة بمساعدة البيانات المنظمة تتصرف بصورة مختلفة: توثق أن زواحف Bing تتجاهل التعليق ذا نوع القيمة الخاطئ — مثل حقل سعر يحمل تاريخًا، أو Event بلا تاريخ، أو Person بلا اسم — بدل إظهار خطأ أحمر. لذلك لا تفترض أن «لا خطأ في Bing» يعني «صحيح». فوثائق Bing العامة أقل تفصيلًا من وثائق Google ولا تنشر تقسيمًا لكل نوع بين المطلوب والموصى به أو تقريرًا بمستوى تقرير Rich result، كما أن تسامحها مع عدم تطابق الأنواع يعني إسقاطًا صامتًا لا فشلًا صريحًا. استخدم Rich Results Test من Google للتصنيف المفصل.

قيم @id المكررة والتباس الكيانات

هناك مشكلة أدق تسببها إضافات CMS كثيرًا: إعادة استخدام @id نفسه لكيانين مختلفين، أو جعل الإضافة تصدر @id جديدًا متصادمًا في كل صفحة بدل قيمة مستقرة. وهذه ليست مشكلة تحليل؛ فـJSON نفسه سليم، ولذلك لا تظهر في تقرير Unparsable structured data. تستخدم عقد JSON-LD قيمة @id للإشارة بعضها إلى بعض داخل @graph، ومن ثم يكون التصادم مشكلة في هوية الكيان لأنه يخلق التباسًا حول العقدة التي يشير إليها المرجع. وتزداد المشكلة في المواقع التي تولّد فيها مصادر متعددة، مثل القالب وإضافة المخطط، عقد Organization وWebSite وWebPage تلقائيًا.

الحل هو @id مستقر وفريد لكل كيان حقيقي — معرّف بجزء URL مثل https://example.com/#organization يُعاد استخدامه باتساق في الموقع، ولا يُنشأ من جديد لكل صفحة. وهذا شبيه بصورة معكوسة بمشكلة تحديد العنوان الأساسي ، إذ تتمثل الفكرة كلها كذلك في معرّف مستقر واحد لكل شيء حقيقي.

أخطاء الخصائص المتداخلة، مثل name مفقود داخل author

توجد بعض الخصائص المطلوبة داخل كائنات أخرى، مثل author.name وaggregateRating.ratingValue. وكان فقدان إحداها ينتج سابقًا رسالة غامضة مثل Missing field "name" يمكن أن تشير إلى أي موضع في الصفحة. وفي مارس 2022 أضافت Google سياق التداخل، فأصبحت الرسالة Missing field "name" (in "author")، وهو تغيير صغير يسهل تحديد الموضع كثيرًا. وكان على كل من لديه طلب «Validate fix» مفتوح حينها إعادة تشغيله لأن معرّفات المشكلات القديمة أُوقفت. وإذا رأيت خطأ خاصية متداخلة فاقرأ ما بين القوسين؛ فهو يسمي الكائن الذي تنقصه الخاصية.

عدم تطابق المحتوى — فئة أخطاء مخالفة السياسة

تستحق هذه الفئة قسمًا مستقلًا لأن عاقبتها أسوأ نوعيًا من «لا نتيجة غنية». فكل ما سبق مشكلة تقنية، أما عدم تطابق المحتوى فهو مشكلة سياسة.

تنص الإرشادات العامة للبيانات المنظمة من Google بوضوح على نقطتين:

• “Don’t mark up content that is not visible to readers of the page.” (ترجمة) «لا ترمّز محتوى غير ظاهر لقراء الصفحة».
• “Your structured data must be a true representation of the page content.” (ترجمة) «يجب أن تكون بياناتك المنظمة تمثيلًا حقيقيًا لمحتوى الصفحة».

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

العواقب: الإجراءات اليدوية مقابل فقدان الأهلية الصامت

يكلفك الخطأ التقني النتيجة الغنية بصمت. أما مخالفة عدم تطابق المحتوى فقد تكلف أكثر: “If your page contains a structured data issue, it can result in a manual action. A structured data manual action means that a page loses eligibility for appearance as a rich result; it doesn’t affect how the page ranks in Google web search.” (ترجمة) «إذا كانت صفحتك تحتوي على مشكلة في البيانات المنظمة فقد يؤدي ذلك إلى إجراء يدوي. ويعني الإجراء اليدوي للبيانات المنظمة أن الصفحة تفقد أهلية الظهور كنتيجة غنية؛ ولا يؤثر في ترتيب الصفحة في بحث Google على الويب». وتظهر الإجراءات اليدوية في تقرير Manual Actions في Search Console، وهو آخر مكان تريد أن ترى فيه إدخالًا للبيانات المنظمة.

وهناك نسخة أهدأ شيوعًا من المشكلة: مخطط قالبي غير فريد. تفيد إرشادات John Mueller المستمرة بأن “the structured data on a website, or on a page, should be specific to that particular page” (ترجمة) «ينبغي أن تكون البيانات المنظمة على موقع أو صفحة خاصة بتلك الصفحة تحديدًا» (نقلًا عن Search Engine Journal). فنسخ كتلة Organization نفسها بعدد المراجعات نفسه في كل صفحة يمثل مشكلة في التمثيل، لا مجرد إهمال.

لماذا لا يكفي التحقق؟ هذا جواب سؤال «ترميزي ينجح في التحقق، فلماذا لا توجد نتيجة غنية؟». تتحقق الأدوات من الصياغة وقواعد الأهلية التقنية لدى Google، لكنها لا تتحقق من طبقة جودة المحتوى وسياسة الرسائل غير المرغوب فيها. وقد يُحرم تطبيق سليم نحويًا لكنه مخالف للسياسة من النتيجة الغنية أو يتعرض لإجراء يدوي. لذلك يكون النجاح في Rich Results Test ضروريًا لكنه غير كافٍ.

استخدام نوع متقادم أو غير مدعوم

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

دراسة حالة: نتائج FAQ الغنية، المتقادمة في 2026

هذا هو المثال الآني. أضافت Google إشعار تقادم إلى وثائق نتيجة FAQ الغنية يفيد بأن الميزة “will no longer appear in Google Search starting May 7, 2026,” (ترجمة) «لن تعود تظهر في بحث Google ابتداءً من 7 مايو 2026»، ثم أزالت في منتصف 2026 وثائق FAQ ودعم Rich Results Test وتقارير Search Console لأن “the FAQ rich result feature is no longer shown in Google Search results.” (ترجمة) «ميزة نتيجة FAQ الغنية لم تعد تظهر في نتائج بحث Google».

والتفصيل المهم أن FAQPage ما يزال نوعًا صالحًا في schema.org، وما تزال Google تحلله. النوع ليس «خاطئًا»، لكنه لم يعد يمنح المظهر المرئي. لذلك فالجواب الصحيح عن «هل مخطط FAQ لدي خطأ الآن؟» هو لا. ولا يضر إبقاء الترميز؛ بل لم يعد يمنحك تحسين SERP. فلا تحذف ترميزًا صالحًا بذعر لمجرد اختفاء المظهر.

أنواع أخرى أُوقفت

ليست FAQ وحدها. فقد أوقفت Google مرارًا أنواعًا من النتائج الغنية بعدما أظهر التحليل أنها غير شائعة الاستخدام أو لا تضيف قيمة: أزيلت نتائج HowTo الغنية من سطح المكتب في 2023؛ وأوقفت دفعة يونيو 2025 سبعة أنواع متخصصة أخرى، منها Claim Review وEstimated Salary وLearning Video وSpecial Announcement وVehicle Listing؛ وبدأ تقادم بيانات Practice Problems المنظمة في يناير 2026. ويظل نوع schema.org صالحًا عادةً في كل حالة، لكنه يتوقف عن الظهور.

كيف تعرف إن كان النوع ما يزال «حيًا»؟

راجع Search Gallery من Google، وهي القائمة المرجعية للأنواع التي تمنح نتائج غنية حاليًا. فإذا لم يكن النوع في المعرض فلن ينتج ترميز صالح له مظهرًا مرئيًا مهما كانت نظافته. وأعد فحص المعرض دوريًا لأن Google تعدله كثيرًا.

كيفية التصحيح فعليًا — ثلاث أدوات مختلفة

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

Rich Results Test — أهلية Google ومعاينة SERP

يأخذ Rich Results Test عنوان URL واحدًا أو مقتطف شيفرة ويفحص المجموعة الفرعية من الترميز الذي تستخدمه Google للنتائج الغنية، ثم يعرض معاينة لشكل النتيجة. وتصفه Google بأنه “an easy and useful tool for validating your structured data, and in some cases, previewing a feature in Google Search.” (ترجمة) «أداة سهلة ومفيدة للتحقق من بياناتك المنظمة، وفي بعض الحالات لمعاينة ميزة في بحث Google». استخدمه أثناء التطوير وللتحقق الموضعي من إصلاح. وهو لا يتحقق من أنواع المخطط التي لا تستخدمها Google للنتائج الغنية.

Schema Markup Validator — صياغة schema.org لأي نوع

تدير schema.org Schema Markup Validator ، لا Google. وهي تتحقق من الصياغة العامة والالتزام بالمفردات لأي نوع من أنواع schema.org، بما في ذلك الأنواع التي لا تحولها Google إلى نتائج غنية مثل مخطط Action. ويعني اجتيازها أن ترميز schema.org سليم البنية، لا أنك مؤهل لنتيجة غنية من Google. وهذه أداة سؤال «هل بنية JSON-LD لدي صحيحة؟» بمعزل عن أي محرك بحث.

فخ الأداتين: هاتان أداتان مختلفتان فعلًا، ولا يعني اجتياز إحداهما اجتياز الأخرى. وللانقسام تاريخ مربك: حاولت Google إيقاف Structured Data Testing Tool القديمة تمامًا في يوليو 2020، ثم تراجعت بعد الاعتراضات في ديسمبر، وبعد ذلك أعادت توجيهها إلى أداة schema.org الحالية بحلول منتصف 2021. وما تزال منشورات قديمة كثيرة تشير إلى الاسم الميت. في 2026 استخدم Rich Results Test لأهلية Google، وSchema Markup Validator لصياغة schema.org.

تقرير Rich result في Search Console — على مستوى الموقع، بعينة، وعبر الزمن

تقرير Rich result ، الذي ما تزال الواجهة القديمة وكثير من الممارسين يسمونه تقارير Enhancements، هو الوحيد المستمر وعلى مستوى الموقع، لا فحصًا موضعيًا لعنوان URL واحد. تقول Google: “a valid item is an item that doesn’t have any critical issues and can appear on Google as a rich result. An invalid item has at least one critical issue preventing it from appearing as a rich result.” (ترجمة) «العنصر الصالح لا يحتوي على أي مشكلات حرجة ويمكن أن يظهر في Google كنتيجة غنية، أما العنصر غير الصالح ففيه مشكلة حرجة واحدة على الأقل تمنعه من الظهور كنتيجة غنية». وهناك قيدان: لا تظهر التقارير الخاصة بالنوع إلا بعد أن تعثر Google على ترميز صالح من ذلك النوع، كما أن “the reports aren’t a comprehensive list of all detected items. They show a sample of detected items to help assess the quality of your structured data.” (ترجمة) «التقارير ليست قائمة شاملة بكل العناصر المكتشفة؛ بل تعرض عينة منها للمساعدة في تقييم جودة بياناتك المنظمة». فهي سطح مراقبة لا تدقيق شامل.

اجتياز الأداة يجيب عن طبقتها وحدها. يفحص Rich Results Test وSchema Markup Validator وتقرير Rich result أسئلة مختلفة، ولذلك لا يخبرك النجاح في إحداها بشيء حاسم عن الأخريين. فاجتياز Schema Markup Validator لا يعني اجتياز Rich Results Test، ولا يثبت أي منهما ما سيظهر في تقرير Rich result بعد أن تزحف Google إلى الصفحة المنشورة.

التحقق من الإصلاح، ولماذا يستغرق وقتًا

تتمثل آلية Google الموثقة بعد إصلاح المشكلة في: الإصلاح على الموقع، والتأكد من إمكان الزحف إلى الصفحة ومن أنها غير محظورة في robots.txt ولا تحمل noindex، والفحص الموضعي باستخدام URL Inspection، ثم “click Validate fix on the issue’s details page to start Google’s validation process.” (ترجمة) «انقر على Validate fix في صفحة تفاصيل المشكلة لبدء عملية التحقق لدى Google». واضبط توقعات الوقت؛ فتقول Google إن التحقق “can take two weeks or more, depending on crawl frequency.” (ترجمة) «قد يستغرق أسبوعين أو أكثر، بحسب وتيرة الزحف». فهو ليس فوريًا، إذ يجب أن تعيد Google الزحف إلى الصفحات المتأثرة.

الإطار الذهني الذي يحافظ على وضوح الأولويات

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

موضع هذا الدليل

هذا دليل متعمق شقيق ضمن مركز البيانات المنظمة لتحسين محركات البحث، وفي المجموعة الفرعية نفسها التي تضم أدلة ترميز المخطط وJSON-LD والنتائج الغنية. وتصنيف الأخطاء هنا هو النظير التشخيصي لتلك الأدلة: فهي تشرح ما ينبغي بناؤه، وهذا يشرح ما يتعطل وكيف تراه. وللصورة الأوسع لإشارات الصفحة التي يجاورها — وسوم meta ووسوم العناوين وSEO الصور — راجع مجموعة تحسين محركات البحث على الصفحة.

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

خلاصة مكثفة لنسخة Advanced:

• فئتان من الأخطاء. أخطاء التحليل هي JSON-LD غير الصالح — فواصل زائدة، أو علامات اقتباس غير مسبوقة بمحرف هروب، أو نقطتان/أقواس مفقودة — الذي يفسد الترميز إلى درجة تعجز معها Google عن تحديد النوع؛ وتذهب هذه إلى تقرير Unparsable structured data. أما أخطاء الأهلية فيُحلل فيها الترميز بنجاح لكنه يخالف قاعدة للنتائج الغنية: خاصية مطلوبة مفقودة، أو نوع قيمة خاطئ، أو @id متصادم/مكرر (التباس في هوية الكيان، لا فشل تحليل)، أو ترميز يصف محتوى غير ظاهر في الصفحة.
• الأخطاء تمنع، والتحذيرات تقلل التفاصيل. تقضي الخاصية المطلوبة المفقودة أو JSON غير القابل للتحليل على أهلية النتيجة الغنية. أما الخاصية الموصى بها المفقودة فهي تحذير فقط، وتظل النتيجة تظهر عادةً لكن بتفاصيل أقل. وتفضّل Google عددًا أقل دقيقًا على حشو غير منضبط.
• عدم تطابق المحتوى هو الفئة ذات العواقب الجدية. ترميز محتوى غير ظاهر أو بيانات ليست “a true representation of the page content” (ترجمة) «تمثيلًا حقيقيًا لمحتوى الصفحة» مخالفة للسياسة قد تؤدي إلى إجراء يدوي، وهي أسوأ من فقدان الأهلية بصمت. ولهذا قد يفشل ترميز يجتاز التحقق: فأدوات التحقق لا تفحص طبقة سياسة المحتوى والرسائل غير المرغوب فيها.
• الأنواع المتقادمة ليست أخطاء. FAQ، الذي اختفى بحلول مايو 2026، وHowTo على سطح المكتب منذ 2023، ودفعة يونيو 2025 كلها ترميزات صالحة لم تعد تمنح مظهرًا مرئيًا. لا تحذف FAQPage بذعر؛ فما يزال يُحلل، لكنه بلا عائد في SERP. راجع Search Gallery لمعرفة ما يزال مدعومًا.
• ثلاث أدوات مختلفة. Rich Results Test لأهلية Google ومعاينة SERP لعنوان URL أو مقتطف واحد؛ وSchema Markup Validator من schema.org للصياغة والمفردات لأي نوع، لا لأنواع Google وحدها؛ وتقرير Rich result في Search Console للمراقبة بعينة على مستوى الموقع وعبر الزمن. لا يعني اجتياز إحداها اجتياز الأخرى.
• نصيحة تصحيح من Google: اختصر الترميز إلى كائن فارغ ثم أعد الشيفرة جزءًا جزءًا؛ وقد يكشف الإصلاح أخطاء مخفية، لذلك أعد الاختبار كل مرة.
• قد يستغرق التحقق من الإصلاح “two weeks or more, depending on crawl frequency.” (ترجمة) «أسبوعين أو أكثر، بحسب وتيرة الزحف».
• ليس عامل ترتيب. يستعيد إصلاح الأخطاء مظهر SERP لا ترتيبًا (Mueller، 2025).

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

وثائق المصدر الأولي من Google وschema.org.

Google — السياسات وكيف يعمل الترميز

• General Structured Data Guidelines — قواعد عدم تطابق المحتوى والمحتوى المخفي، وعاقبة الإجراء اليدوي.
• Intro to How Structured Data Markup Works — توصية Rich Results Test وإرشاد «عدد أقل لكنه مكتمل» للخصائص المطلوبة والموصى بها.
• ترميز البيانات المنظمة الذي يدعمه بحث Google (Search Gallery) — القائمة المرجعية للأنواع التي تمنح نتائج غنية حاليًا؛ راجعها قبل افتراض أن النوع ما يزال مدعومًا.

Google — التقارير وآلية التصحيح

• Rich result report overview — تقرير Search Console على مستوى الموقع وبعينة ولكل نوع؛ تعريفات الصالح وغير الصالح والتنبيه إلى أنه عينة لا قائمة شاملة.
• Unparsable structured data report — موضع JSON-LD غير الصالح، ورسائل الخطأ الموثقة، ونصيحة البدء بكائن فارغ.
• Fix structured data issues in Search Console — سير العمل من الإصلاح إلى تأكيد إمكان الزحف ثم URL Inspection ثم Validate fix، ومدة «أسبوعين أو أكثر».

Google — الأداة

• Rich Results Test — فاحص عنوان URL أو المقتطف الواحد مع معاينة SERP، لأهلية Google فقط.

schema.org

• Schema Markup Validator — أداة schema.org للتحقق من الصياغة والمفردات لأي نوع، وهي منفصلة عن Rich Results Test من Google.
• schema.org — المفردات نفسها.

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

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

Google — سياسة عدم تطابق المحتوى، وهي أساس الدقة

• “Don’t mark up content that is not visible to readers of the page.” (ترجمة) «تجنب ترميز أي محتوى لا يراه قراء الصفحة». — وثائق Google Search Central. انتقل إلى الاقتباس
• “Your structured data must be a true representation of the page content.” (ترجمة) «يجب أن تكون بياناتك المنظمة تمثيلًا حقيقيًا لمحتوى الصفحة». انتقل إلى الاقتباس

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

• “it is more important to supply fewer but complete and accurate recommended properties rather than trying to provide every possible recommended property with less complete, badly-formed, or inaccurate data.” (ترجمة) «الأهم هو تقديم عدد أقل من الخصائص الموصى بها، على أن تكون كاملة ودقيقة، بدل محاولة تقديم كل خاصية ممكنة ببيانات أقل اكتمالًا أو سيئة الصياغة أو غير دقيقة». انتقل إلى الاقتباس
• “The Rich Results Test is an easy and useful tool for validating your structured data, and in some cases, previewing a feature in Google Search.” (ترجمة) «Rich Results Test أداة سهلة ومفيدة للتحقق من بياناتك المنظمة، وفي بعض الحالات لمعاينة ميزة في بحث Google». انتقل إلى الاقتباس

Google — تقرير Rich result في Search Console

• “A valid item is an item that doesn’t have any critical issues and can appear on Google as a rich result. An invalid item has at least one critical issue preventing it from appearing as a rich result.” (ترجمة) «العنصر الصالح لا يحتوي على أي مشكلات حرجة ويمكن أن يظهر في Google كنتيجة غنية. أما العنصر غير الصالح ففيه مشكلة حرجة واحدة على الأقل تمنعه من الظهور كنتيجة غنية». انتقل إلى الاقتباس
• “The reports aren’t a comprehensive list of all detected items. They show a sample of detected items to help assess the quality of your structured data.” (ترجمة) «لا تحصي التقارير جميع العناصر المكتشفة؛ وإنما تعرض عينة تساعدك على تقييم جودة البيانات المنظمة». انتقل إلى الاقتباس

Google — الترميز غير القابل للتحليل والتصحيح

• النوع المقصود “could not be determined because of the parsing error.” (ترجمة) «تعذر تحديده بسبب خطأ التحليل». انتقل إلى الاقتباس
• “If you are having problems finding the error, try starting from an empty object, then add back content from your broken code piece by piece.” (ترجمة) «إذا واجهت صعوبة في العثور على الخطأ، فحاول البدء بكائن فارغ، ثم أعد محتوى الشيفرة المعطوبة جزءًا جزءًا». انتقل إلى الاقتباس

Google — التحقق من الإصلاح

• قد يستغرق التحقق “can take two weeks or more, depending on crawl frequency.” (ترجمة) «أسبوعين أو أكثر، بحسب وتيرة الزحف». انتقل إلى الاقتباس

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

• “Structured data won’t make your site rank better.” (ترجمة) «لن تجعل البيانات المنظمة موقعك يحتل ترتيبًا أفضل». اقرأ التغطية

John Mueller من Google — ينبغي أن يكون المخطط خاصًا بالصفحة

• “The structured data on a website, or on a page, should be specific to that particular page.” (ترجمة) «ينبغي أن تكون البيانات المنظمة على موقع أو صفحة خاصة بتلك الصفحة تحديدًا». اقرأ التغطية

خلل تقارير Search Console في أكتوبر 2022 — تصنيف التحذيرات أخطاءً

• “This is strictly a reporting issue and did not affect whether or not a rich result could be displayed in Google Search results.” (ترجمة) «هذه مشكلة في إعداد التقارير حصرًا، ولم تؤثر في إمكان عرض نتيجة غنية في نتائج بحث Google من عدمه». اقرأ التغطية

أي أداة تستخدم، وماذا تعني النتيجة؟

ابدأ من السؤال الذي تطرحه فعلًا؛ فالأدوات تجيب عن أسئلة مختلفة.

«هل JSON-LD لدي مكتوب بصورة صحيحة أصلًا؟» ← Schema Markup Validator على validator.schema.org. تفحص صياغة schema.org ومفرداتها لأي نوع. والاجتياز يعني أن schema.org سليمة البنية، لكنه لا يخبرك عن أهلية النتائج الغنية في Google.

«هل ستكون هذه الصفحة مؤهلة لنتيجة غنية من Google، وكيف قد تبدو؟» ← Rich Results Test على search.google.com/test/rich-results. يفحص عنوان URL واحدًا أو مقتطفًا، وللأنواع المؤهلة لدى Google فقط، مع معاينة SERP.

• إذا كان النوع الذي يهمك غير معروف إطلاقًا، فراجع Search Gallery ؛ فقد يكون النوع متقادمًا مثل FAQ أو HowTo على سطح المكتب، أي ترميز صالح بلا مظهر مرئي.

«أي صفحات موقعي كله تعاني مشكلات عبر الزمن؟» ← Search Console ثم تقرير Rich result، وهو تقرير بعينة على مستوى الموقع. تذكر أنه عينة لا قائمة شاملة، وأن التقارير الخاصة بالنوع لا تظهر إلا بعد أن تعثر Google على ترميز صالح من ذلك النوع.

ماذا يعني الخطأ فعلًا؟

العنصر موجود في تقرير Unparsable structured data ← JSON غير صالح: فاصلة زائدة، أو علامة اقتباس غير مسبوقة بمحرف هروب، أو نقطتان/قوس مفقودان. اختصره إلى كائن فارغ وأعد الشيفرة جزءًا جزءًا. فلم تستطع Google حتى تحديد النوع.

«Missing field …»، وهو خطأ ← خاصية مطلوبة غائبة. تظل النتيجة الغنية ممنوعة حتى الإصلاح. واقرأ أي قوس توضيحي مثل … (in "author")، فهو يسمي الكائن المتداخل الذي تنقصه الخاصية.

«… should be … / recommended»، وهو تحذير ← خاصية موصى بها مفقودة. وتظل النتيجة الغنية تظهر، لكن بصورة أقل اكتمالًا. أصلحها فقط إن كان الحقل المفقود مفيدًا، ولا تحشُ بيانات غير دقيقة.

«Incorrect value type» أو «invalid value» ← الخاصية صحيحة لكن النوع خطأ: نص حيث يجب أن يوجد رقم أو URL أو تاريخ. صحح النوع.

التحقق ناجح، لكن لا تظهر نتيجة غنية ← إما أن النوع متقادم، فراجع المعرض، وإما أنك تواجه مشكلة محتوى أو سياسة لا تكشفها أدوات التحقق، مثل محتوى غير ظاهر أو تمثيل غير حقيقي. وفي أسوأ الحالات راجع تقرير Manual Actions.

إدخال في تقرير Manual Actions ← مخالفة سياسة عدم تطابق المحتوى. وهذه الحالة الجدية: أصلح عدم التطابق بين الترميز والصفحة ثم اطلب إعادة النظر. فهي تكلف أهلية النتائج الغنية لا الترتيب.

قائمة تحقق لفرز أخطاء البيانات المنظمة

مرور منهجي للعثور على أخطاء المخطط وتحديد أولوياتها وإصلاحها بصورة صحيحة:

• فصلت الأخطاء عن التحذيرات — تمنع الأخطاء، أي الحقول المطلوبة المفقودة أو المحتوى غير القابل للتحليل، النتيجة الغنية؛ أما التحذيرات، أي الحقول الموصى بها المفقودة، فلا تمنعها. أصلح الأخطاء أولًا.
• راجعت تقرير Unparsable structured data — كل ما فيه JSON غير صالح، مثل فاصلة زائدة أو علامة اقتباس غير مسبوقة بمحرف هروب أو نقطتين/قوس مفقودين.
• صححت العناصر غير القابلة للتحليل باختصارها إلى كائن فارغ ثم أعدت الخصائص حتى تعطل، وأعدت الاختبار بعد كل تغيير لأن الإصلاح قد يكشف أخطاء مخفية.
• أكدت وجود كل خاصية مطلوبة لكل نوع وفق Search Gallery، ثم عالجت الموصى به؛ فالدقة أهم من الحشو.
• أنواع القيم صحيحة — الأرقام في مواضع الأرقام، وعناوين URL في مواضعها، والتواريخ تواريخ، ولا سلاسل نصية تحل محلها.
• قرأت الأقواس في أخطاء الخصائص المتداخلة — تخبرك Missing field "name" (in "author") بالكائن الذي تنقصه الخاصية.
• قيم @id مستقرة وفريدة لكل كيان حقيقي — لا @id مكررًا أو متصادمًا، ولا إعادة توليد لكل صفحة، مع الانتباه إلى إصدار القالب والإضافة للعقد معًا.
• كل ما رُمز ظاهر في الصفحة ويمثلها تمثيلًا حقيقيًا — لا محتوى خفيًا ولا تقييمات أو حقائق مصطنعة غير موجودة.
• لا تعتمد على نوع متقادم — FAQ الذي اختفى في مايو 2026، وHowTo على سطح المكتب منذ 2023، ودفعة يونيو 2025. فالترميز صالح لكن عائده في SERP يساوي صفرًا.
• شغّلت الأداة الصحيحة للسؤال — Schema Markup Validator للصياغة، وRich Results Test لأهلية Google والمعاينة، وتقرير Rich result للمراقبة على مستوى الموقع.
• راجعت تقرير Manual Actions — يعني إدخال بيانات منظمة هناك مخالفة لسياسة المحتوى، لا خطأً تقنيًا.
• بعد الإصلاح أكدت إمكان الزحف، أي عدم الحظر في robots.txt وغياب noindex، ثم فحصت باستخدام URL Inspection ونقرت Validate fix، واضبطت التوقعات: فقد يستغرق الأمر أسبوعين أو أكثر.

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

الأدوات الثلاث — لا تخلط بينها

لا يعني اجتياز أداة اجتياز الأخرى.

الخطأ مقابل التحذير

فئات الأخطاء والإصلاح

حقائق سريعة

• ليست عامل ترتيب — يستعيد الإصلاح مظهر SERP لا ترتيبًا (Mueller).
• قد يؤدي عدم تطابق المحتوى إلى إجراء يدوي، وهو الفئة ذات العواقب الجدية.
• نتيجة FAQ الغنية: اختفت بحلول 7 مايو 2026؛ وما يزال نوع FAQPage صالحًا لكن بلا مظهر.
• التحقق من الإصلاح: “two weeks or more, depending on crawl frequency.” (ترجمة) «أسبوعان أو أكثر، بحسب وتيرة الزحف».
• تقرير Rich result عينة لا قائمة شاملة بكل عنصر.

ما ينبغي ألا تفعله

الأخطاء المتكررة التي تحول مشكلة مخطط قابلة للإصلاح إلى مشكلة أكبر:

• معاملة كل تحذير كأنه خطأ. الخاصية الموصى بها المفقودة تحذير، وتظل النتيجة الغنية تظهر. ومطاردة التحذيرات بحشو بيانات نصف صحيحة أسوأ من تركها؛ فـGoogle تفضّل خصائص أقل ودقيقة على خصائص أكثر ورديئة.
• الثقة العمياء في تقرير واحد. سبق أن صنفت Search Console التحذيرات أخطاءً في أكتوبر 2022. قارن العنصر المعلَّم بـRich Results Test بدل التفاعل مع تقرير واحد فقط.
• ترميز محتوى غير ظاهر. هذه الفئة ذات العواقب الحقيقية؛ فهي مخالفة للسياسة قد تؤدي إلى إجراء يدوي، لا مجرد خسارة صامتة للنتيجة الغنية. فإذا لم يظهر تقييم أو سعر أو حقيقة في الصفحة فلا تضعه في المخطط.
• نسخ مخطط مطابق إلى كل صفحة. يبدو الترميز القالبي غير الفريد، مثل عدد المراجعات نفسه في الموقع كله، مشكلة تمثيل. وينبغي أن يكون المخطط خاصًا بالصفحة التي يظهر فيها.
• إعادة توليد @id لكل صفحة أو استخدام @id واحد لكيانين. كلاهما يفسد مراجع الكيانات داخل @graph. استخدم @id واحدًا مستقرًا وفريدًا لكل كيان حقيقي، وانتبه إلى أن يصدر القالب والإضافة عقد Organization أو WebSite معًا.
• حذف ترميز صالح لكنه متقادم بذعر. توقف مخطط FAQ عن منح مظهر مرئي في 2026، لكن FAQPage ما يزال صالحًا وما تزال Google تحلله. لا يفيد حذفه وقد يفسد ترميزًا آخر حوله.
• افتراض أن «التحقق ناجح» يعني «النتيجة الغنية مضمونة». لا تفحص أدوات التحقق طبقة جودة المحتوى وسياسة الرسائل غير المرغوب فيها لدى Google. وقد تظل الصفحة السليمة نحويًا والمخالفة للسياسة محرومة.
• توجيه الناس إلى Structured Data Testing Tool القديمة. أُعيد تركيزها لتصبح Schema Markup Validator من schema.org بحلول 2021. وفي 2026 استخدم Rich Results Test لأهلية Google وSchema Markup Validator لصياغة schema.org.
• توقع إصلاح فوري. تعيد Google الزحف وفق جدولها بعد Validate fix، وقد يستغرق ذلك “two weeks or more, depending on crawl frequency.” (ترجمة) «أسبوعين أو أكثر، بحسب وتيرة الزحف». فلا تعاود تقديم المشكلة نفسها بذعر.

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

كتاباتي ذات الصلة

• Structured Data: What It Is and How to Use It — دليلي في Ahrefs إلى أنواع المخطط وطرق التنفيذ وأدوات التحقق ومخاطر sameAs، وهو النظير الخاص بالبناء لهذا الدليل التشخيصي.
• Google Uses ~40 Canonicalization Signals — دليلي لتحديد العنوان الأساسي؛ فمنطق المعرّف المستقر لكل شيء حقيقي وراء إصلاح أخطاء @id المكررة يشبه اختيار العنوان الأساسي.
• The Beginner’s Guide to Technical SEO — موضع البيانات المنظمة وأخطائها ضمن الصورة التقنية الأوسع.

المصادر الرسمية

• General Structured Data Guidelines من Google — سياسة عدم تطابق المحتوى والمحتوى المخفي وعاقبة الإجراء اليدوي.
• Unparsable structured data report من Google — رسائل أخطاء JSON غير الصالح ونصيحة البدء بكائن فارغ.
• Fix structured data issues in Search Console من Google — سير العمل من الإصلاح إلى Validate fix ومدة «أسبوعين أو أكثر».
• Rich result report overview من Google — تعريفات الصالح وغير الصالح والتنبيه إلى «عينة لا قائمة شاملة».
• Search Gallery من Google — القائمة الحالية للأنواع التي تمنح نتائج غنية؛ راجعها قبل افتراض أن النوع ما يزال مدعومًا.
• Rich Results Test من Google وSchema Markup Validator من schema.org — أداتان لعنوان URL واحد تجيبان عن سؤالين مختلفين.

من أرجاء المجال

• Google: البيانات المنظمة لا تحسّن ترتيب موقعك (Search Engine Roundtable، أبريل 2025) — قول Mueller إن البيانات المنظمة «لن تجعل موقعك يحتل ترتيبًا أفضل»، وهو الإطار الذي يعيد توجيه سبب إصلاح الأخطاء.
• John Mueller من Google: ينبغي أن تكون البيانات المنظمة فريدة لكل صفحة (Search Engine Journal) — مصدر خطأ المخطط القالبي.
• Google Search Console Mislabeled Structured Data Errors As Errors (Search Engine Land، أكتوبر 2022) — حادثة خلل التقارير وراء نصيحة عدم الثقة العمياء في تقرير واحد.
• Google Search Console Structured Data Error Reporting Gains More Contextual Information (Search Engine Land، مارس 2022) — تغيير سياق الخصائص المتداخلة، مثل … (in "author").
• Google تزيل نتائج FAQ الغنية من البحث (Search Engine Journal) — تغطية إزالة FAQ وما يظل صالحًا.
• r/TechSEO — مجتمع تصحيح أخطاء المخطط والنتائج الغنية.

JSON-LD المعطوب مقابل المصحح

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

فاصلة زائدة

// Broken — trailing comma after "price" breaks JSON parsing entirely
{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Trail Running Shoe",
  "offers": {
    "@type": "Offer",
    "price": "89.99",
  }
}

// Fixed — comma removed after the last property
{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Trail Running Shoe",
  "offers": {
    "@type": "Offer",
    "price": "89.99"
  }
}

المشكلة: الفاصلة بعد آخر خاصية في الكائن صالحة في JavaScript لكنها غير صالحة في JSON. ولذلك يظهر العنصر في تقرير Unparsable structured data لأن Google لا تستطيع تحديد نوعه أصلًا.

علامة اقتباس غير مسبوقة بمحرف هروب

// Broken — the inch mark inside "description" terminates the string early
{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Monitor Stand",
  "description": "Fits a 27" display comfortably"
}

// Fixed — the inner quote is escaped
{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Monitor Stand",
  "description": "Fits a 27\" display comfortably"
}

المشكلة: تنهي علامة " غير المسبوقة بمحرف هروب داخل قيمة نصية السلسلة عند ذلك الموضع، فتفسد كل ما بعدها. وتسمي Google رسالة الخطأ هذه “Bad escape sequence in string.” (ترجمة) «تسلسل هروب غير صالح في السلسلة».

نوع قيمة خاطئ

// Broken — ratingValue is a string, not a number
{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Trail Running Shoe",
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "five stars",
    "reviewCount": "42"
  }
}

// Fixed — ratingValue is a number; reviewCount is a number too
{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Trail Running Shoe",
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": 4.6,
    "reviewCount": 42
  }
}

المشكلة: JSON صالح نحويًا ولذلك يجتاز التحليل الأساسي، لكن Google تسميه “Incorrect value type” (ترجمة) «نوع قيمة غير صحيح» لأن ratingValue يحتاج إلى رقم، لا سلسلة نصية مثل "five stars".

@id مكرر

// Broken — the theme AND a plugin each emit their own "#organization" @id
// with different data, colliding inside the site's @graph
{
  "@context": "https://schema.org",
  "@graph": [
    { "@type": "Organization", "@id": "https://example.com/#organization", "name": "Example Co" },
    { "@type": "Organization", "@id": "https://example.com/#organization", "name": "Example Company Inc." }
  ]
}

// Fixed — one stable, unique @id per real-world entity
{
  "@context": "https://schema.org",
  "@graph": [
    { "@type": "Organization", "@id": "https://example.com/#organization", "name": "Example Company Inc." }
  ]
}

المشكلة: يخلق استخدام @id نفسه لتمثيلين مختلفين للكيان نفسه التباسًا حول التمثيل الذي يشير إليه المرجع. اختر معرّفًا واحدًا مستقرًا، وأعد استخدامه باتساق، ولا تعِد توليده لكل صفحة.

طلبات لتصحيح أخطاء البيانات المنظمة

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

العثور على خطأ التحليل في JSON-LD معطوب

ألصق كتلة JSON-LD الخام التي تفشل، وانسخها مباشرةً من مصدر الصفحة أو من عرض الشيفرة في Rich Results Test.

Here is a JSON-LD structured data block that Google's Rich Results Test is
flagging as unparsable. Find the syntax error (trailing comma, unescaped
quote, or missing colon or brace) and tell me the exact line and character
that's wrong. Then give me the corrected JSON. Don't change any property
values, only fix the syntax.

[paste the broken JSON-LD block here]

ما تتوقعه: تسمية مشكلة الصياغة المحددة، لا مجرد قول «هناك خطأ في مكان ما»، مع كتلة مصححة يمكنك مقارنتها بالأصل للتأكد من أن شيئًا آخر لم يتغير. وأعد تشغيل الكتلة المصححة في Rich Results Test بنفسك؛ فقد يكشف الإصلاح خطأً ثانيًا كان مخفيًا، لذلك لا تعامل مرورًا واحدًا من الذكاء الاصطناعي على أنه الكلمة الأخيرة.

فحص الخصائص المطلوبة والموصى بها لنوع

ألصق كتلة JSON-LD مع اسم نوع schema.org المستهدف، مثل Product أو Recipe أو Event.

This is a JSON-LD block using schema.org type [TYPE]. Based on Google's
required and recommended properties for this type in its Search Gallery
documentation, tell me: (1) which required properties are missing —
these block the rich result entirely, (2) which recommended properties
are missing — these only produce warnings, and (3) whether any present
value looks like the wrong type (text where a number, URL, or date is
expected).

[paste the JSON-LD block here]

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

إثبات أن إصلاح المخطط أصبح نافذًا فعلًا

تحويل سير العمل الوارد في المقال — الإصلاح على الموقع، وتأكيد إمكان الزحف، والفحص الموضعي، والنقر على Validate fix، ثم الانتظار — إلى اختبارات نجاح وفشل.

يعرض Rich Results Test النوع بلا أخطاء

الاختبار: الصق عنوان URL للصفحة الحية، أو مقتطف JSON-LD المصحح، في Rich Results Test. النتيجة المتوقعة: يُكتشف النوع المستهدف، مثل Product أو Recipe، مع 0 أخطاء؛ أما تحذيرات الخصائص الموصى بها فمقبولة. تفسير الفشل: إذا ظل النوع يعرض الخطأ نفسه، فإما أن الإصلاح لم يُنشر على الصفحة الحية، وإما أنه لم يعالج الخاصية التي سماها الخطأ فعلًا. أعد قراءة ما بين القوسين في أي خطأ خاصية متداخلة. نافذة المراقبة: فورية؛ فهذا الاختبار يقرأ الترميز الحي الحالي، لا نسخة مخبأة أو سبق الزحف إليها. محفز التراجع: إذا أظهر النوع الذي كان ينجح سابقًا خطأً جديدًا لم يكن موجودًا، فربما أفسد الإصلاح شيئًا آخر في @graph نفسه؛ تراجع عنه وأعد تطبيقه بنطاق أضيق.

تأكيد إمكان الزحف إلى الصفحة قبل طلب إعادة التحقق

الاختبار: استخدم أداة URL Inspection في Search Console على الصفحة المصححة. النتيجة المتوقعة: «URL is on Google» أو «URL is available to Google» بلا حظر في robots.txt وبلا توجيه noindex. تفسير الفشل: إذا كانت الصفحة محظورة أو تحمل noindex فلن تعيد Google الزحف إليها مهما كان المخطط نظيفًا؛ والنقر على Validate fix في صفحة محظورة يهدر دورة تحقق. نافذة المراقبة: فورية؛ يقرأ URL Inspection حالة الزحف والفهرسة الحالية. محفز التراجع: لا ينطبق؛ فهذا فحص شرط مسبق لا تغيير ينبغي التراجع عنه.

تحل عملية Validate fix في Search Console المشكلة

الاختبار: في المشكلة المتأثرة في Search Console انقر Validate fix بعد التأكد من نجاح الاختبارين السابقين. النتيجة المتوقعة: تنتقل حالة المشكلة من «Failed» أو «Not started» إلى «Started» ثم في النهاية إلى «Passed»، وينخفض عدد الصفحات المتأثرة بتلك المشكلة. تفسير الفشل: تعني حالة «Failed» بعد التحقق أن Google أعادت الزحف وما تزال ترى المشكلة. عد إلى Rich Results Test على عنوان URL الحي لمعرفة ما يزال خطأ قبل إعادة الطلب. نافذة المراقبة: وفق إرشاد Google نفسه، “can take two weeks or more, depending on crawl frequency” (ترجمة) «قد يستغرق أسبوعين أو أكثر، بحسب وتيرة الزحف»؛ فلا تعاود تقديم المشكلة قبل انقضاء هذه النافذة. محفز التراجع: إذا كان عدد المشكلات يرتفع بدل الانخفاض بعد نافذة المراقبة، فربما لم يُطبق الإصلاح على مستوى الموقع، كأن يكون قالب واحد فقط قد حُدث لا كل الصفحات التي تستخدم النوع. دقق في الصفحات الأخرى التي ما تزال تصدر الترميز المعطوب.

مؤشر الأداء الدائم: تقرير Rich result عبر الزمن

إصلاح مخطط صفحة واحدة مهمة لمرة واحدة. أما مراقبة صحة البيانات المنظمة على مستوى الموقع فقياس مستمر، وتقرير Rich result في Search Console هو الأداة المبنية لهذا الغرض.

العناصر الصالحة لكل نوع

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

العناصر غير الصالحة لكل نوع

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

عدد البيانات المنظمة غير القابلة للتحليل

المقياس: عدد العناصر في تقرير Unparsable structured data المنفصل، أي JSON-LD غير الصالح الذي أفسد التحليل كله. ما الذي يخبرك به: ما إذا كان خطأ على مستوى الشيفرة، مثل قالب يجمع السلاسل من دون الهروب من علامات الاقتباس، ينتج ترميزًا معطوبًا الآن، بدل فجوة أهلية على مستوى المحتوى. كيفية استخراجه: Search Console ثم تقرير Unparsable structured data. المعيار أو النطاق الواقعي: الهدف الصادق هو صفر، لأن الترميز غير القابل للتحليل خطأ صياغة محض لا قرارًا تقديريًا بشأن الخصائص. ولا يوجد «معدل مقبول» يمكن الدفاع عنه فوق الصفر؛ فقيمة القياس هي مراقبة عودته إلى الصفر بعد الإصلاح، لا مقارنته بمعيار. الوتيرة: تحقق بعد كل نشر يمس الشيفرة المولدة للمخطط أو بعد تحديث إضافة مخطط؛ وإلا فشهريًا مع التقريرين الآخرين.

اختبر نفسك: أخطاء البيانات المنظمة

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

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