PhotoPDF
استكشف الأدوات ابدأ مجاناً

ما هو Schema Markup؟ وكيف تنشئ JSON-LD لموقعك بطريقة صحيحة

ما هو Schema Markup؟

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

ما هو Schema Markup وطريقة إنشاء JSON-LD
استخدام Schema Markup وJSON-LD لوصف محتوى الموقع بطريقة منظمة

لكن إضافة أي كود من Schema.org لا تعني تلقائيًا الحصول على نتيجة غنية في Google، كما أن وضع بيانات غير موجودة فعليًا في الصفحة قد يجعل الترميز مخالفًا للإرشادات. في هذا الدليل سنشرح الفرق بين Schema.org وStructured Data وJSON-LD، ثم نبني أمثلة عملية لـArticle وOrganization وWebSite ونتعلم الطريقة الصحيحة لاختبارها.

الإجابة المختصرة

Schema Markup هو استخدام مفردات منظمة، غالبًا من Schema.org، لوصف الأشخاص والمقالات والشركات والمنتجات وأنواع أخرى من المحتوى بطريقة يمكن للأنظمة فهمها آليًا. ومن أسهل طرق إضافته للموقع استخدام JSON-LD داخل <script type="application/ld+json">. اختر نوع Schema الذي يطابق المحتوى الحقيقي، وأضف الخصائص الدقيقة فقط، ثم اختبر الكود قبل النشر وبعده. وجود Schema صحيح لا يضمن ظهور Rich Result في Google.

ما هو Schema Markup ببساطة؟

Schema Markup هو ترميز يصف معنى البيانات الموجودة داخل الصفحة بطريقة موحدة. يعتمد كثير من المواقع على مفردات Schema.org، التي تحتوي أنواعًا مثل Article وOrganization وPerson وProduct وLocalBusiness وغيرها.

Article وصف المقالة

يمكن تحديد عنوان المقالة ومؤلفها وصورتها والجهة الناشرة وغيرها من المعلومات المرتبطة بالمحتوى.

Organization وصف الشركة أو الموقع

يمكن توضيح اسم المؤسسة ورابطها وشعارها وبعض بياناتها الرسمية عندما تكون هذه المعلومات موجودة فعلًا.

Product وصف المنتج

يمكن وصف المنتج والسعر والتوفر والتقييم وغيرها من المعلومات وفق متطلبات النوع والاستخدام.

WebSite وصف الموقع

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

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

ما الفرق بين Schema Markup وStructured Data وSchema.org؟

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

المصطلح معناه
Structured Data البيانات المنظمة هي طريقة قياسية لتقديم معلومات عن الصفحة وتصنيف محتواها بصورة يمكن للأنظمة قراءتها.
Schema.org مفردات مشتركة تحدد أنواعًا وخصائص مثل Article وOrganization وname وlogo وauthor.
Schema Markup الترميز الذي تضيفه إلى موقعك باستخدام أنواع وخصائص Schema لوصف المحتوى.
JSON-LD أحد تنسيقات كتابة البيانات المنظمة، ويستخدم JSON داخل عنصر script منفصل عن النص المرئي.

بمعنى مبسط: Schema.org يوفر المفردات، وJSON-LD هو إحدى طرق كتابة هذه المفردات، والنتيجة النهائية داخل الصفحة تسمى Structured Data أو Schema Markup حسب السياق.

ما هو JSON-LD؟

JSON-LD طريقة لكتابة البيانات المنظمة باستخدام بنية JSON. يوضع الكود عادة داخل عنصر script ويمكن وضعه في head أو body وفق طريقة تنفيذ الموقع.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "WebSite",
  "name": "Example Site",
  "url": "https://example.com/"
}
</script>

Google تدعم JSON-LD وMicrodata وRDFa، لكنها توصي عمومًا بـJSON-LD عندما يسمح إعداد الموقع بذلك لأنه أسهل في التنفيذ والصيانة وأقل اختلاطًا مع عناصر HTML المرئية.

ماذا تعني @context و@type و@id؟

هذه المفاتيح تظهر كثيرًا في أمثلة JSON-LD، وفهمها يجعل قراءة الكود أسهل بكثير من نسخه دون معرفة الوظيفة التي يؤديها كل جزء.

المفتاح وظيفته مثال
@context يحدد المفردات المستخدمة لتفسير الخصائص والأنواع داخل الكود. https://schema.org
@type يحدد نوع الشيء الذي تصفه، مثل Article أو Organization. BlogPosting
@id يعطي الكيان معرفًا يمكن استخدامه لربطه بعناصر Structured Data أخرى داخل الصفحة أو الموقع. https://example.com/#organization
name اسم العنصر الموصوف عندما تكون الخاصية مناسبة لهذا النوع. Example Site
url عنوان URL المرتبط بالعنصر. https://example.com/

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

هل كل أنواع Schema.org تظهر كـRich Results في Google؟

لا. هذه نقطة مهمة جدًا؛ Schema.org يحتوي أنواعًا وخصائص كثيرة، لكن Google تدعم مجموعة محددة من أنواع البيانات المنظمة والميزات في نتائج البحث.

فرق مهم:

يمكن أن يكون JSON-LD صحيحًا وفق Schema.org، لكن ذلك لا يعني أن Google ستعرض Rich Result خاصًا به. يجب مراجعة قائمة أنواع Structured Data التي تدعمها Google لكل ميزة بحث.

على سبيل المثال، Google لديها وثائق لأنواع مثل Article وBreadcrumb وOrganization وProduct وRecipe وVideo وغيرها، ولكل نوع متطلبات وإرشادات خاصة يجب اتباعها عندما تريد التأهل لميزة بحث مرتبطة به.

هل Schema Markup يرفع ترتيب الموقع مباشرة؟

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

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

قيمة Structured Data الأساسية هي الوضوح والفهم وإمكانية التأهل لبعض ميزات البحث، وليس التلاعب بالترتيب.

ما هو Article Schema؟

Article Schema مخصص لوصف المقالات، وتدعم Google أنواعًا مثل Article وNewsArticle وBlogPosting. ويمكن لهذه البيانات أن تساعد Google على فهم عنوان المقالة والصور والمؤلف وبعض معلومات النشر بصورة أوضح.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "ما هو Schema Markup؟ وكيف تنشئ JSON-LD لموقعك بطريقة صحيحة",
  "description": "دليل عملي لفهم Schema Markup وإنشاء JSON-LD.",
  "image": [
    "https://example.com/images/schema-markup.jpg"
  ],
  "author": {
    "@type": "Person",
    "name": "اسم الكاتب",
    "url": "https://example.com/author/"
  },
  "publisher": {
    "@type": "Organization",
    "name": "Example Site",
    "logo": {
      "@type": "ImageObject",
      "url": "https://example.com/logo.png"
    }
  },
  "mainEntityOfPage": {
    "@type": "WebPage",
    "@id": "https://example.com/schema-markup-json-ld"
  }
}
</script>

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

Article أم BlogPosting أم NewsArticle؟

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

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

لا تستخدم NewsArticle لمقال تعليمي عادي فقط لأنك تعتقد أن النوع سيعطي ظهورًا أفضل. اختر Schema الذي يعكس طبيعة المحتوى الحقيقي.

ما هو Organization Schema؟

Organization Schema يصف الجهة أو الشركة أو المؤسسة المرتبطة بالموقع. يمكن أن يساعد Google على فهم هوية المؤسسة وبعض بياناتها مثل الاسم والشعار وعنوان الموقع.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://example.com/#organization",
  "name": "Example Site",
  "url": "https://example.com/",
  "logo": {
    "@type": "ImageObject",
    "url": "https://example.com/logo.png"
  },
  "sameAs": [
    "https://www.example-social-profile.com/example"
  ]
}
</script>

Google توصي بوضع معلومات Organization على الصفحة الرئيسية أو صفحة واحدة تصف المؤسسة مثل «من نحن»، ولا تحتاج إلى تكرار وصف كامل ومستقل للمؤسسة في كل صفحة من الموقع.

هل يجب استخدام Organization لكل موقع؟

استخدم النوع الذي يصف الجهة بأكبر دقة ممكنة. فقد يكون LocalBusiness أو OnlineStore أو نوعًا أكثر تحديدًا أفضل من Organization العام عندما ينطبق على نشاطك فعلًا.

  • استخدم اسم المؤسسة الحقيقي والمتسق مع الاسم الظاهر للمستخدمين على الموقع.
  • استخدم رابط الشعار الحقيقي الذي يستطيع محرك البحث الوصول إليه بدل صورة محمية أو رابط مؤقت.
  • أضف خصائص مثل العنوان أو الهاتف فقط عندما تكون مناسبة ومعلوماتها صحيحة ومستخدمة فعلًا من المؤسسة.
  • استخدم subtype أكثر تحديدًا عندما يصف نشاطك بصورة أفضل بدل اختيار Organization العام دائمًا.

كثرة الخصائص ليست الهدف؛ بيانات قليلة لكنها صحيحة وكاملة أفضل من إدخال كل خاصية ممكنة بقيم غير دقيقة.

ما هو WebSite Schema؟

WebSite Structured Data يصف الموقع نفسه، وتستخدمه Google خصوصًا ضمن الإشارات المتعلقة باسم الموقع. بالنسبة لهذا الاستخدام، يجب وضعه على الصفحة الرئيسية للموقع وليس في كل مقالة.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "WebSite",
  "@id": "https://example.com/#website",
  "name": "Example Site",
  "alternateName": "Example",
  "url": "https://example.com/"
}
</script>

بالنسبة إلى اسم الموقع في Google، الخصائص الأساسية هي name وurl، ويمكن إضافة alternateName عندما يوجد اسم مختصر أو بديل معروف للموقع.

هل أضع WebSite Schema في جميع الصفحات؟

إذا كان الهدف تحديد اسم الموقع لـGoogle، توصي الوثائق بوضع WebSite Structured Data على الصفحة الرئيسية للنطاق أو النطاق الفرعي، وليس نسخ كتلة مستقلة على كل URL.

مثال:

ضع WebSite Schema الخاص بـhttps://example.com/ على الصفحة الرئيسية. أما المقالة https://example.com/article فيمكن وصفها بـBlogPosting أو Article وربطها بالموقع عند الحاجة.

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

ربط Article وOrganization وWebSite باستخدام @id

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

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://example.com/#organization",
      "name": "Example Site",
      "url": "https://example.com/",
      "logo": {
        "@type": "ImageObject",
        "url": "https://example.com/logo.png"
      }
    },
    {
      "@type": "WebSite",
      "@id": "https://example.com/#website",
      "name": "Example Site",
      "url": "https://example.com/",
      "publisher": {
        "@id": "https://example.com/#organization"
      }
    },
    {
      "@type": "BlogPosting",
      "@id": "https://example.com/schema-markup-json-ld#article",
      "headline": "ما هو Schema Markup؟ وكيف تنشئ JSON-LD لموقعك بطريقة صحيحة",
      "mainEntityOfPage": {
        "@type": "WebPage",
        "@id": "https://example.com/schema-markup-json-ld"
      },
      "publisher": {
        "@id": "https://example.com/#organization"
      },
      "isPartOf": {
        "@id": "https://example.com/#website"
      }
    }
  ]
}
</script>

استخدام @graph ليس شرطًا للحصول على Structured Data صحيحة، لكنه قد يكون طريقة منظمة لإدارة عدة كيانات مرتبطة عندما يصبح الموقع أكثر تعقيدًا.

هل يجب أن تطابق بيانات Schema المحتوى الظاهر؟

نعم، وهذه واحدة من أهم قواعد التنفيذ. لا تستخدم Structured Data لوصف شيء غير موجود أو غير متاح للمستخدم في الصفحة عندما يفترض أن الترميز يمثل محتواها.

مثال صحيح أم خطأ؟ السبب
وضع عنوان المقالة الحقيقي في headline. صحيح. البيانات المنظمة تصف المحتوى الظاهر فعلًا.
إضافة تقييم 5 نجوم لا يظهر في الصفحة ولم يقدمه مستخدمون. خطأ. الترميز يقدم معلومات مضللة وغير ممثلة للمحتوى.
استخدام صورة المقالة في image. صحيح. الصورة مرتبطة بالمحتوى الذي تصفه البيانات المنظمة.
استخدام Product Schema لمقال لا يبيع أو يصف منتجًا. خطأ. نوع Schema لا يتطابق مع التركيز الحقيقي للصفحة.

Google تنص على عدم ترميز محتوى غير مرئي للقراء أو معلومات مضللة وغير مرتبطة بالتركيز الرئيسي للصفحة.

اختيار الصورة المناسبة داخل Article Schema

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

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

وإذا كانت صورة المقالة ضخمة قبل النشر، يمكنك استخدام أداة تغيير حجم الصور من FotoPDF لإنشاء نسخة مناسبة قبل وضع رابطها داخل Article Schema.

أين أضع كود JSON-LD؟

يمكن وضع JSON-LD داخل عنصر script في head أو body. المهم أن يكون موجودًا في الصفحة التي يصفها ويمكن لمحرك البحث الوصول إليه وقراءته.

<head>

  <title>عنوان الصفحة</title>

  <script type="application/ld+json">
  {
    "@context": "https://schema.org",
    "@type": "WebSite",
    "name": "Example Site",
    "url": "https://example.com/"
  }
  </script>

</head>

في أنظمة إدارة المحتوى يمكن أن يتم إنشاء Structured Data تلقائيًا من القالب أو الإضافة، لذلك افحص HTML النهائي للصفحة قبل إضافة كود آخر حتى لا تنشئ Schema مكررة ومتعارضة.

كيف تختبر Schema Markup قبل النشر؟

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

  1. أنشئ Structured Data باستخدام المعلومات الحقيقية للصفحة وليس قيمًا تجريبية ستنسى استبدالها لاحقًا.
  2. استخدم Rich Results Test عندما تريد معرفة ميزات Google التي يمكن أن يكون ترميزك مؤهلًا لها وإصلاح الأخطاء الحرجة.
  3. استخدم Schema Markup Validator عندما تريد التحقق العام من ترميز Schema.org، بما في ذلك الأنواع التي لا تملك Rich Result خاصًا في Google.
  4. انشر الكود على عدد محدود من الصفحات أولًا ثم استخدم URL Inspection للتأكد من أن Google يستطيع الوصول إلى الصفحة النهائية.
  5. راقب تقارير Search Console بعد نشر التغيير على نطاق واسع، خصوصًا إذا عدلت القالب الذي يولد Schema لعدد كبير من الصفحات.

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

Rich Results Test أم Schema Markup Validator؟

الأداتان مفيدتان لكنهما لا تجيبان عن السؤال نفسه، ولذلك من الطبيعي أن ينجح الكود في واحدة ولا يظهر كنوع Rich Result في الأخرى.

الأداة متى تستخدمها؟
Rich Results Test لمعرفة البيانات المنظمة والميزات الغنية التي تدعمها Google واكتشاف الأخطاء المرتبطة بمتطلباتها.
Schema Markup Validator للتحقق من صحة ترميز Schema.org بصورة عامة دون الاقتصار على أنواع Rich Results التي تدعمها Google.
URL Inspection للتأكد بعد النشر من كيفية وصول Google إلى الصفحة ومحتواها النهائي.
Search Console لمراقبة الأخطاء والتحسينات على مستوى الموقع بعد اكتشاف الصفحات وفهرستها.

إذا ظهر WebSite Schema صحيحًا في Schema Validator لكنه لم يظهر كميزة داخل Rich Results Test، فهذا لا يعني بالضرورة أن الكود خاطئ؛ بعض الاستخدامات لا تملك Preview أو Rich Result بالطريقة نفسها.

هل اجتياز Rich Results Test يضمن ظهور النتيجة الغنية؟

لا. اجتياز الاختبار يعني أن Structured Data تلبي المتطلبات التقنية التي يستطيع الاختبار التحقق منها، لكن Google لا تضمن عرض Rich Result حتى عندما يكون الترميز صحيحًا.

لا تخلط بين الأهلية والظهور:

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

ولا تحاول حل عدم ظهور Rich Result بإضافة خصائص مزيفة أو أنواع Schema إضافية غير مرتبطة بالصفحة؛ هذا قد يجعل التنفيذ أسوأ وليس أفضل.

هل FAQ Schema ما زال يعطي FAQ Rich Results؟

FAQPage ما زال نوعًا موجودًا ضمن مفردات Schema.org، لكن يجب التفريق بين وجود النوع وبين دعم Google لميزة بحث مرتبطة به. اعتبارًا من مايو 2026، أوقفت Google ظهور FAQ rich results في نتائج البحث.

  • يمكن أن يبقى قسم الأسئلة الشائعة مفيدًا للمستخدم حتى دون وجود FAQ Rich Result في Google.
  • لا تضف FAQPage فقط لأن دليل SEO قديم وعدك بمساحة أكبر في نتائج Google.
  • ركز على الأنواع والميزات التي تدعمها Google حاليًا عندما يكون هدفك الحصول على Search Feature محددة.
  • راجع التوثيق الحديث لأن دعم Structured Data والميزات يمكن أن يتغير مع الوقت.

هذه النقطة توضح لماذا يجب الرجوع إلى وثائق Google الحالية بدل الاعتماد على قائمة Schema قديمة محفوظة منذ سنوات.

أخطاء شائعة في JSON-LD وSchema Markup

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

الخطأ لماذا يسبب مشكلة؟ التصرف الأفضل
استخدام Schema لا يطابق الصفحة. يصف المحتوى بطريقة مضللة أو غير دقيقة. اختر النوع الأكثر تحديدًا الذي يصف المحتوى الحقيقي.
اختراع بيانات غير موجودة. يخالف مبدأ أن Structured Data يجب أن تمثل المحتوى الحقيقي. أضف فقط المعلومات الصحيحة والقابلة للتأكيد.
ترك example.com داخل الكود. تنتقل روابط تجريبية إلى الصفحة الحقيقية. استبدل جميع الأمثلة بعناوين الموقع الفعلية قبل النشر.
تكرار Organization بعدة قيم مختلفة. قد يصبح تعريف المؤسسة غير متسق. استخدم كيانًا ثابتًا ويمكن ربطه باستخدام @id.
وضع WebSite Schema مختلف في كل صفحة. قد ترسل أسماء وعناوين مختلفة للموقع نفسه. ضع تعريف الموقع الأساسي في الصفحة الرئيسية حسب الاستخدام المقصود.
الاعتقاد أن Schema.org = Google Rich Results. ليس كل نوع في Schema.org مرتبطًا بميزة غنية في Google. راجع وثائق Google للميزة المطلوبة.
عدم اختبار القالب بعد التعديل. خطأ واحد قد ينتشر على مئات أو آلاف الصفحات. اختبر عدة صفحات حقيقية قبل تعميم التغيير.

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

قالب عملي لموقع يحتوي WebSite وOrganization وBlogPosting

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

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://example.com/#organization",
      "name": "Example Site",
      "url": "https://example.com/",
      "logo": {
        "@type": "ImageObject",
        "url": "https://example.com/logo.png"
      }
    },
    {
      "@type": "WebSite",
      "@id": "https://example.com/#website",
      "name": "Example Site",
      "url": "https://example.com/",
      "publisher": {
        "@id": "https://example.com/#organization"
      }
    },
    {
      "@type": "BlogPosting",
      "@id": "https://example.com/article-url#article",
      "headline": "عنوان المقالة الحقيقي",
      "description": "وصف المقالة الحقيقي",
      "image": [
        "https://example.com/images/article-image.jpg"
      ],
      "author": {
        "@type": "Person",
        "name": "اسم الكاتب"
      },
      "publisher": {
        "@id": "https://example.com/#organization"
      },
      "isPartOf": {
        "@id": "https://example.com/#website"
      },
      "mainEntityOfPage": {
        "@type": "WebPage",
        "@id": "https://example.com/article-url"
      }
    }
  ]
}
</script>

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

رأي عملي

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

رأي عملي

للصفحة الرئيسية: سأراجع WebSite وOrganization أو النوع الأكثر تحديدًا المناسب للنشاط.

للمقالات: سأستخدم BlogPosting أو Article مع headline والصورة والمؤلف والمعلومات الصحيحة التي تنطبق فعلًا على الصفحة.

للمنتجات أو الأنشطة المحلية: لن أستخدم Article Schema، بل سأراجع التوثيق الخاص بالنوع الذي يمثل الصفحة الفعلية.

للاختبار: سأمرر الكود على Rich Results Test عندما يكون النوع مدعومًا من Google، ثم Schema Markup Validator للتحقق العام.

بعد النشر: سأفحص بعض URLs الحقيقية وأراقب Search Console بدل افتراض أن نجاح الكود داخل المحرر يعني نجاحه في الصفحة النهائية.

أفضل Schema هي التي تستطيع الحفاظ على صحتها بعد ستة أشهر، وليس أكثر Schema تحتوي حقولًا يوم نشرها.

أسئلة شائعة حول Schema Markup وJSON-LD

هذه أبرز الأسئلة التي تظهر عند البدء في إضافة البيانات المنظمة إلى المواقع.

ما هو Schema Markup؟

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

ما هو JSON-LD؟

هو تنسيق يعتمد على JSON لكتابة البيانات المنظمة داخل عنصر script، وتوصي Google باستخدامه عمومًا عندما يسمح إعداد الموقع بذلك.

هل Schema Markup يحسن ترتيب الموقع؟

يساعد محركات البحث على فهم المحتوى ويمكن أن يجعل الصفحة مؤهلة لبعض الميزات الغنية، لكنه لا يضمن رفع الترتيب أو ظهور Rich Result.

ما الفرق بين Article وBlogPosting؟

Article نوع عام للمقالات، بينما BlogPosting نوع أكثر تحديدًا مناسب عادة لمنشورات المدونات.

أين أضع Organization Schema؟

توصي Google بوضع معلومات Organization على الصفحة الرئيسية أو صفحة واحدة تصف المؤسسة مثل صفحة من نحن، ولا يلزم تكرار الكتلة كاملة في كل صفحة.

أين أضع WebSite Schema؟

عند استخدامه لتحديد اسم الموقع لـGoogle، يوضع WebSite Structured Data على الصفحة الرئيسية للنطاق أو النطاق الفرعي.

كيف أختبر JSON-LD؟

استخدم Rich Results Test للميزات التي تدعمها Google، واستخدم Schema Markup Validator للتحقق العام من ترميز Schema.org.

هل نجاح الاختبار يضمن ظهور Rich Result؟

لا، نجاح الاختبار يعني أن الترميز قد يكون مؤهلًا تقنيًا، لكن Google لا تضمن عرض النتيجة الغنية.

هل FAQ Schema ما زال يظهر كـFAQ Rich Result؟

Google أوقفت FAQ rich results في البحث منذ مايو 2026، لذلك لا ينبغي الاعتماد على FAQPage للحصول على هذا الشكل السابق في النتائج.

راجع دائمًا توثيق النوع الذي تستخدمه؛ الخصائص الصحيحة لـArticle ليست بالضرورة الخصائص المناسبة لـProduct أو LocalBusiness أو أي نوع آخر.

الخاتمة

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

خلاصة التنفيذ: اختر نوع Schema الذي يطابق الصفحة الحقيقية، واستخدم JSON-LD بقيم صحيحة بدل البيانات الوهمية. ضع WebSite Schema في الصفحة الرئيسية عند استخدامه لتعريف اسم الموقع، واستخدم Organization أو subtype أدق لوصف المؤسسة، وBlogPosting أو Article للمقالات. اختبر الكود قبل النشر، ثم افحص النسخة الحية في Google. وإذا كنت تستخدم صورة داخل Article Schema، يمكنك تجهيز أبعادها أولًا باستخدام أداة تغيير حجم الصور في FotoPDF.

لا تحاول إضافة كل أنواع Schema.org إلى موقعك؛ ابدأ بالأنواع التي تصف المحتوى فعلًا ويمكنك إبقاء بياناتها دقيقة ومتوافقة مع ما يراه المستخدم داخل الصفحة.

```