دليل Schema.org و JSON-LD للبيانات المنظمة

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

Schema.org و JSON-LD والنتيجة المنسقة أشياء مختلفة

Schema.org

هذا قاموس مشترك للأنواع والخصائص: Article، Product، Organization، Event، name، image، offers وغيرها الكثير. يصف الكيانات والعلاقات التي يمكن تمثيلها بشكل منظم.

JSON-LD

هذا أحد تنسيقات كتابة البيانات المنظمة. يوضع الكود داخل:

<script type="application/ld+json"> { "@context": "https://schema.org", "@type": "Article", "headline": "عنوان المقال" } </script>

توصي جوجل بـ JSON-LD عندما يكون مناسبًا للتنفيذ، ولكن يمكن أيضًا كتابة Schema.org باستخدام Microdata أو RDFa.

النتيجة المنسقة من جوجل

هذا عرض خاص في نتائج البحث يدعم فقط مجموعة محدودة من الأنواع ويتطلب الالتزام بقواعد محددة من جوجل. لا يضمن ترميز Schema.org الصحيح نتيجة منسقة، أو ترتيبًا مرتفعًا، أو حتى استخدام جميع الخصائص المرسلة. لذلك، لا ينبغي تقييم الترميز فقط بسؤال "هل سيعرض مقتطفًا جميلًا؟". يجب أن يصف بشكل صحيح الكيان الحقيقي للصفحة أولاً.

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

اختر النوع بناءً على الكائن الرئيسي للصفحة، وليس على المظهر المطلوب في البحث.

النوع	متى يتم تطبيقه	ما الذي يجب التحقق منه بشكل خاص
Article	مقال، خبر، مراجعة، منشور	العنوان، المؤلف أو الناشر، التواريخ، الصورة، الصلة بالصفحة الحالية
BreadcrumbList	سلسلة التنقل المرئية أو المنطقية	الترتيب الصحيح للمواضع وعناوين URL لكل خطوة
Event	حدث محدد بتاريخ وشكل	التاريخ والمنطقة الزمنية، المكان أو عنوان URL عبر الإنترنت، الحالة والحداثة
FAQPage	صفحة تحتوي على إجابة رسمية واحدة من الموقع لكل سؤال	جميع الأسئلة والأجوبة مرئية للمستخدم؛ وليست للمنتديات أو إجابات المستخدمين
HowTo	تعليمات خطوة بخطوة حقيقية	تتوافق الخطوات مع المادة المرئية؛ لا تعتمد على نتيجة HowTo المنسقة من جوجل
JobPosting	وظيفة شاغرة فردية متاحة	صاحب العمل، الموقع أو الشكل عن بعد، تاريخ النشر، المدة، الوصف
LocalBusiness	نقطة مادية محددة أو منظمة محلية	النوع الفرعي الأكثر دقة، العنوان، الهاتف، ساعات العمل وعنوان URL لهذه النقطة
Organization	شركة، مؤسسة، علامة تجارية أو جمعية	الاسم الرسمي، عنوان URL، الشعار، جهات الاتصال و @id ثابت
Person	ملف شخص معين	الاسم، الدور، الانتماء إلى منظمة، الملفات الشخصية الرسمية؛ لا تقدم الافتراضات كحقائق
Product	منتج معين أو متغير منتج	المنتج موجود في الصفحة؛ السعر، العملة، التوفر، العرض والمراجعات محدثة
Recipe	وصفة طهي	المكونات، الخطوات، الوقت، الحصص والصورة متاحة للمستخدم
VideoObject	فيديو فردي في الصفحة	العنوان، الوصف، المعاينة، تاريخ التحميل وعنوان URL للفيديو أو المشغل
WebSite	الموقع ككائن واحد	عنوان URL الأساسي الرئيسي، الاسم والعلاقة بالمنظمة؛ هذا النوع عادة لا يكون ضروريًا في كل صفحة ككيان مستقل

يُسمح بوجود عدة كائنات مرتبطة في صفحة واحدة. على سبيل المثال، يمكن أن تحتوي المقالة على مؤلف Person، وناشر Organization، وفتات خبز BreadcrumbList، وفيديو مضمن VideoObject. من الأفضل ربطها عبر @id بدلاً من إنشاء نسخ متضاربة.

قيود جوجل الهامة والحالية

FAQPage

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

HowTo

توقفت جوجل عن عرض نتائج HowTo المنسقة. لا يزال نوع HowTo موجودًا في قاموس Schema.org ويمكن استخدامه من قبل مستهلكين آخرين، ولكن إضافته فقط من أجل نتيجة جوجل المنسقة السابقة لم يعد له معنى.

أنواع أخرى

تساعد Organization و Person و WebSite في وصف الكيانات، ولكن ليس كل منها ينشئ نتيجة منسقة مرئية منفصلة. يتغير الدعم والمظهر الخارجي لميزات البحث، لذا قبل التنفيذ، تحقق من معرض Google Search Central الحالي.

القاعدة الرئيسية: يجب أن يتطابق الترميز مع المحتوى المرئي

لا تُضف في JSON-LD معلومات غير موجودة في الصفحة أو تتعارض معها. ينطبق هذا بشكل خاص على:

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

الترميز ليس مكانًا لنص إعلاني مخفي أو كلمات مفتاحية إضافية. يجب أن يحصل المستخدم ومحرك البحث على معلومات متسقة.

تعتمد الحقول الإلزامية على من يقرأ الترميز

يحدد Schema.org قاموسًا، ولكن ليس قائمة عالمية موحدة من "الحقول الإلزامية" لجميع الأنظمة. يضع مستهلك معين، مثل Google Search، خصائصه الإلزامية والموصى بها لوظيفة بحث معينة. لذلك، هناك ثلاث نتائج تحقق مختلفة محتملة:

1. JSON صحيح نحويًا.
2. الأنواع والخصائص موجودة في Schema.org.
3. يلبي الترميز متطلبات النتيجة المنسقة المحددة من جوجل.

اجتياز المرحلة الأولى أو الثانية لا يضمن الثالثة.

كيفية ملء عناوين URL والتواريخ والمعرفات

استخدم عناوين URL مطلقة

يفضل:

https://example.com/catalog/product-1

بدلاً من:

/catalog/product-1

يجب أن تكون الروابط قابلة للوصول من قبل روبوت البحث، ولا تتطلب مصادقة، وتؤدي إلى مورد مستقر.

حدد التواريخ بتنسيق ISO 8601

التاريخ:

2026-08-04

التاريخ والوقت مع المنطقة الزمنية:

2026-08-04T18:30:00+03:00

بالنسبة للأحداث، من المهم بشكل خاص عدم فقدان المنطقة الزمنية. وإلا، قد يتم تفسير الوقت بشكل غير صحيح.

أنشئ @id ثابتًا

@id هو معرف الكيان، غالبًا على شكل عنوان URL مع جزء:

https://example.com/#organization https://example.com/article/#webpage https://example.com/article/#author

يجب أن تشير نفس المؤسسة في الصفحات المختلفة إلى معرف واحد ثابت، وليس أن تبدو كشركات متعددة مستقلة.

كيفية وصف كيانات متعددة باستخدام @graph

بالنسبة للكائنات المرتبطة، من الملائم استخدام كتلة واحدة:

{ "@context": "https://schema.org", "@graph": [ { "@type": "Organization", "@id": "https://example.com/#organization", "name": "شركة مثال", "url": "https://example.com/" }, { "@type": "Article", "@id": "https://example.com/blog/article/#article", "headline": "عنوان المقال", "publisher": { "@id": "https://example.com/#organization" } } ] }

وبذلك تكون الكائنات مرتبطة بشكل واضح ولا يلزم تكرار جميع المعلومات حول المنظمة داخل كل مقال.

أين يتم إدراج JSON-LD

يمكن وضع كتلة <script type="application/ld+json"> في <head> أو <body> لصفحة HTML. الأهم هو أن:

• الكود موجود في HTML النهائي أو يمكن الوصول إليه بعد العرض الصحيح؛
• يتعلق تحديدًا بالصفحة الحالية؛
• يقوم نظام إدارة المحتوى بترميزه بدون إتلاف علامات الاقتباس والرموز؛
• لا يقوم قالب واحد بإدراج نفس البيانات في صفحات مختلفة؛
• يتم تحديث السعر الديناميكي والتوفر والتواريخ مع المحتوى المرئي.

بعد التنفيذ، تحقق ليس فقط من الكود من المولد، ولكن أيضًا من عنوان URL المنشور: قد يغير القالب أو الإضافة أو JavaScript الترميز النهائي.

مستويان مختلفان للتحقق من الصحة

Schema Markup Validator

يتحقق من التركيب واستخدام قاموس Schema.org. مناسب لرؤية الأنواع الموجودة والخصائص والمشاكل العامة للترميز.

Google Rich Results Test

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

الخطأ والتحذير ليسا فئتين عالميتين

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

1. هل تركيب JSON معطل؟
2. هل النوع والخاصية موجودان في Schema.org؟
3. هل الخاصية متداخلة بشكل صحيح ولها قيمة صالحة؟
4. هل هي مطلوبة بواسطة وظيفة البحث المختارة أو تكامل آخر؟

الأخطاء الشائعة

• نوع غير مناسب: تم ترميز صفحة فئة المنتجات كـ Product واحد، على الرغم من عدم وجود منتج فردي أو عرض موحد. أو تحصل مقالة عادية على FAQPage فقط لأن هناك كتلة صغيرة من الأسئلة في الأسفل.
• الترميز لا يتطابق مع الصفحة: يحدد الكود سعرًا قديمًا، أو تقييمًا غير موجود، أو أسئلة مخفية، أو مؤلفًا مختلفًا.
• كيانات متضاربة: تنشئ إضافات متعددة كتل Organization مختلفة بأسماء وشعارات وعناوين URL متباينة. الكائنات غير مرتبطة عبر @id مشترك.
• تداخل غير صحيح: على سبيل المثال، يتم كتابة price مباشرة في Product، على الرغم من أن العرض يوصف عادةً عبر كائن Offer في خاصية offers.
• نوع قيمة غير صحيح: التاريخ مكتوب كنص عشوائي، السعر يحتوي على العملة في نفس السلسلة، يتم تمرير القيمة المنطقية كعبارة، والحقل الذي يتوقع عنوان URL يحتوي على مسار نسبي.
• صور وصفحات غير قابلة للوصول: يعيد عنوان URL خطأ، أو محظور بواسطة المصادقة أو robots.txt، أو يشير إلى رابط مؤقت غير مستقر، أو إلى صورة لا يستطيع محرك البحث جلبها.
• بيانات ديناميكية قديمة: انتهى الحدث، أغلقت الوظيفة، المنتج غير متوفر، لكن الترميز يواصل نقل الحالة القديمة.
• أخطاء JSON: علامات اقتباس مفردة أو مطبعية؛ فاصلة إضافية بعد الخاصية الأخيرة؛ قوس غير مغلق؛ تعليقات داخل JSON؛ سطر جديد غير معالج داخل قيمة سلسلة؛ مفتاح مكرر في نفس الكائن.

سير عمل التنفيذ

1. حدد الكائن الرئيسي والغرض من الترميز.
2. تحقق من المتطلبات الحالية لـ Schema.org ومستهلك البيانات المطلوب.
3. اختر النوع الأكثر دقة.
4. املأ فقط الخصائص الموثوقة الموجودة في الصفحة.
5. أنشئ JSON-LD.
6. تحقق من الكود في Schema Markup Validator.
7. إذا كانت هناك حاجة إلى نتيجة منسقة مدعومة من جوجل، تحقق من Rich Results Test.
8. أدخل الكود في نسخة اختبارية من الصفحة.
9. تحقق مرة أخرى من عنوان URL المنشور، وليس فقط الجزء المعزول.
10. قم بتكوين تحديث القيم الديناميكية وإعادة التحقق بعد تغييرات القالب.

قائمة مراجعة سريعة قبل النشر

• تم اختيار نوع الكائن الحقيقي للصفحة؛
• تتطابق البيانات مع المحتوى المرئي؛
• لا توجد تقييمات أو مراجعات أو خصائص مختلقة؛
• عناوين URL مطلقة ويمكن الوصول إليها ومتسقة قانونيًا؛
• التواريخ بتنسيق واضح ومع المنطقة الزمنية عند الحاجة؛
• السعر والعملة في حقول منفصلة؛
• الكيانات نفسها مرتبطة عبر @id ثابت؛
• لا يوجد ترميز متضارب من وحدة أخرى؛
• اجتاز الكود عمليات التحقق المناسبة؛
• يحتوي عنوان URL المنشور على نفس JSON-LD الصحيح؛
• سيتم تحديث البيانات الديناميكية.

الأسئلة المتكررة

هل يضمن Schema.org مقتطفًا غنيًا؟

لا. الترميز الصحيح يجعل الصفحة قابلة للمعالجة، لكن محرك البحث يقرر بشكل مستقل ما إذا كان سيستخدمها وكيفية عرض النتيجة.

هل أحتاج إلى إضافة Schema.org في كل صفحة؟

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

هل يمكنني ترك خصائص لا يراها المستخدم؟

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

أين أضع الكود – في head أم body؟

يمكن أن يكون JSON-LD في كلا المكانين. المهم هو HTML النهائي الصحيح، وإمكانية وصول المعالج إلى الترميز، واتساقه مع الصفحة الحالية.

لماذا لا يُظهر Schema Markup Validator خطأ بينما تظهره جوجل؟

تتحقق الأداة الأولى من قاموس Schema.org وبنية الترميز، بينما تطبق جوجل بالإضافة إلى ذلك متطلبات وظيفة البحث المحددة.

هل يستحق ترميز FAQPage حالياً؟

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

هل HowTo ضروري لجوجل؟

لم تعد جوجل تعرض نتائج HowTo المنسقة. قد يظل النوع مفيدًا كوصف دلالي للأنظمة الأخرى، ولكن لا ينبغي توقع تأثير البحث السابق لجوجل.

الأدوات ذات الصلة

Diffchecker؛ معالج النصوص؛ Base64.

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

• قاموس Schema.org
• Google Search Central — مقدمة إلى البيانات المنظمة
• Google — إرشادات عامة للبيانات المنظمة
• Google — معرض ميزات البيانات المنظمة
• Schema Markup Validator
• Google Rich Results Test

---

توصيات تحريرية عامة للقسم

1. لا تكرر نفس الكتلة التجارية داخل كل نص مفيد

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

• بعد مولد UTM — إلى التقارير حسب القنوات والتحويلات؛
• بعد أداة الدمج — إلى التحقق من التكرار، والتجميع، وتعيين الاستعلامات للصفحات؛
• بعد Schema — إلى تدقيق البيانات المنظمة؛
• بعد Diffchecker — إلى مراقبة تغييرات الصفحة؛
• بعد إزالة المكررات — إلى استيراد الدلالات أو عناوين URL إلى المشروع.

2. لا تقم بإنشاء أقسام متطابقة "المزايا" و "لمن يناسب" كنمط

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

3. مواءمة الوعود مع التنفيذ الفعلي

قبل النشر، يجب على المطورين تأكيد:

• هل تتم المعالجة بالكامل في المتصفح أم يتم إرسال البيانات إلى الخادم؛
• ما هي حدود حجم النص وعدد الأسطر الموجودة؛
• هل يتم حفظ البيانات الأصلية أو النتائج؛
• ما الخوارزمية والمكتبة المستخدمة لتحديد اللغة؛
• كيف يقارن Diffchecker الكلمات والخطوط بالضبط؛
• هل إزالة المكررات حساسة لحالة الأحرف والمسافات وبأي ترتيب يتم تطبيق الإجراءات؛
• هل يستخدم مولد كلمات المرور مصدر عشوائية آمنًا تشفيريًا؛
• ما الترميز الذي يستخدمه محول Base64؛
• هل يدعم Base64url أم Base64 القياسي فقط.

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

4. أظهر القيود بجانب الوظيفة، ولا تخبئها في الأسفل

تحذيرات مهمة بشكل خاص:

• لا توضع معلمات UTM على الروابط الداخلية؛
• لا يتحقق Diffchecker من المعنى والصحة الواقعية؛
• لا تؤكد أداة الدمج الطلب ولا تنشئ هيكل الموقع تلقائيًا؛
• لا يقوم Base64 بتشفير البيانات؛
• لا يجب تحويل عنوان URL بالكامل إلى أحرف صغيرة دون التحقق؛
• لا يمكن اعتبار كلمة المرور آمنة تشفيريًا دون التحقق من المولد؛
• لا يضمن Schema.org الصحيح نتيجة منسقة.

5. أضف روابط داخلية بناءً على الإجراء التالي للمستخدم

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

6. لا ترميز الأسئلة الشائعة فقط للوعد بمقتطف غني

الأسئلة الشائعة في هذه النصوص مفيدة للمستخدم ويمكن أن تبقى في الصفحة. ولكن يجب اتخاذ قرار إضافة FAQPage بشكل منفصل، مع مراعاة قواعد Schema.org والقيود الحالية لمحركات البحث. بالنسبة للمواقع العادية، لا تعرض جوجل عادةً نتائج الأسئلة الشائعة المنسقة.

7. الترتيب الموصى به للتنفيذ

1. Diffchecker، تحديد اللغة و UTM — لديهم حاليًا أقل قدر من المواد المفيدة.
2. إزالة المكررات — قم بتصحيح نصيحة تحويل جميع عناوين URL إلى أحرف صغيرة بشكل عاجل.
3. Base64 — استبدل كلمة "فك التشفير" بـ "فك الترميز" وأضف Base64url.
4. مولد كلمات المرور — قم بتحديث توصيات الطول وتحقق من تنفيذ التوليد العشوائي.
5. Schema.org — استبدل النص الحالي الطويل بشكل مفرط والمتكرر بدليل أكثر إيجازًا ولكن دقيقًا تقنيًا.
6. أداة الدمج ومعالج النصوص — احتفظ بالأجزاء القوية، وأضف القيود وترتيبًا عمليًا للإجراءات.