تعلم السكيما والبيانات المنظمة

ماذا يفعل غوغل بهذا الكود؟

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

وثلاث صيغ مدعومة: JSON-LD وMicrodata وRDFa. ويكتب غوغل أن الثلاث سواء عنده ما دام الترميز صحيحاً ومنفذاً كما ينبغي، ويوصي في معظم الحالات بـJSON-LD، لأنه يجلس في كتلة script مستقلة بدل أن يتداخل مع HTML الصفحة. وعملياً هذا ما يكتبه الناس.

وتوقع ينبغي تقصيره: كتابة هذا الكود لا تعني الحصول على نتيجة غنية. فالترميز الصحيح يجعل الصفحة مؤهلة لعرض غني، وقرار العرض يبقى لغوغل. والصفحة التي لا شيء لديها لتقوله تبقى كذلك ولو وضعت عليها سكيما.

وخطوة أبعد: العروض نفسها تُسحب. فقد كتب غوغل في تحديثات وثائقه أن نتيجة الأسئلة الشائعة الغنية لن تظهر في البحث اعتباراً من ٧ مايو ٢٠٢٦، ثم حذف تلك الوثيقة كلياً؛ وكان قد فعل الشيء نفسه بنتيجة «كيفية العمل» الغنية. أي أن ترميزاً كان يستحق الكتابة سنة ٢٠٢٣ هو اليوم الكود نفسه وبالصلاحية نفسها ولا يعرض شيئاً في النتائج. وهذا الموقع يطبع FAQPage على الصفحات التي فيها أسئلة وأجوبة، ومنذ ذلك التاريخ لا تخرج منه نتيجة غنية؛ وبقاؤه لا بأس به لأنه يصف محتوى مرئياً فعلاً، أما انتظار شيء منه فخطأ.

أي نوع سكيما يخص صفحتك؟

الجواب قصير: النوع الذي هي عليه الصفحة فعلاً. فصفحة بيع استضافة هي Product. وتدوينة هي Article. وصفحة اتصال هي Organization أو LocalBusiness. وصفحة خدمة هي Service. أما اختيار النوع بحسب أي نتيجة غنية أجمل فهو الخطأ الذي ينتهي لاحقاً بإجراء يدوي.

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

ووجود أكثر من نوع على صفحة واحدة أمر طبيعي: فالتدوينة Article، ومسارها BreadcrumbList، وناشرها Organization. والطريقة النظيفة لكتابة عدة أنواع هي الغراف: كتلة JSON-LD واحدة فيها عدة عقد تشير إحداها إلى الأخرى بمعرّف. حينها تُعرَّف «المؤسسة» مرة واحدة وتشير إليها بقية العقد.

مثال صغير يجمع الأفكار الثلاث معاً: النوع الصحيح، وخاصية إلزامية، وإحالة بمعرّف.

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://example.com/#org",
      "name": "اسم النشاط التجاري",
      "url": "https://example.com/"
    },
    {
      "@type": "Article",
      "@id": "https://example.com/post/#article",
      "headline": "العنوان نفسه المطبوع على الصفحة",
      "datePublished": "2026-09-05",
      "publisher": { "@id": "https://example.com/#org" }
    }
  ]
}

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

لماذا لا ترمّز ما ليس على الصفحة؟

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

وهذه الكلمات الأخيرة موضع انتهاء النقاش. وأكثر مبرر نسمعه: «لكن الرقم صحيح فعلاً، غاية الأمر أننا لم نكتبه على الصفحة». وهذا لا يغير شيئاً بحسب السياسة.

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

والترتيب الصحيح بسيط وأحادي الاتجاه دائماً: ضع المعلومة على الصفحة أولاً ثم رمّزها. ولا تعكس أبداً.

لماذا لا يمنح التقييم الذي جمعته بنفسك نجوماً؟

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

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

ولاحظ أن القيد مرتبط بنوعين لا بكل الأنواع. فعرض التقييم على أنواع مثل Product وSoftware App ما زال مدعوماً؛ والذي أغلقه غوغل هو التقييم المجموع ذاتياً على نوعي النشاط والمؤسسة. وفي LocalBusiness يقول منفصلاً إن خاصية التقييم موصى بها فقط للمواقع التي تجمع مراجعات عن أنشطة أخرى.

وقاعدة أخرى أقل انتباهاً إليها: المراجعة التي ترمّزها يجب أن تكون متاحة للزائر من الصفحة نفسها، ويجب أن يتضح له فوراً أن في الصفحة محتوى مراجعات. فإن كتبت تقييماً إجمالياً في الترميز وجب أن يُرى ذلك التقييم نفسه على الصفحة.

كيف تختبر وكم كتلة تحمل الصفحة؟

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

والآن الفخ الذي لا تريكه الأدوات: قد تحمل الصفحة أكثر من كتلة JSON-LD، وهي تحمل ذلك عادةً، لأن القالب يطبع واحدة وكل إضافة تطبع أخرى. على إحدى صفحاتنا يوم ٥ سبتمبر ٢٠٢٦ عددنا أربع كتل منفصلة: غراف من خمس عقد من القالب، وثلاث كتل مستقلة تطبعها الإضافات. عُدّها بأمر واحد:

curl -s -A "Mozilla/5.0" "https://example.com/page/" \
| grep -c 'application/ld+json'

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