اللغات

JSON-LD: تنسيق البيانات المنظمة المترابطة

JSON-LD هي تنسيق البيانات المنظمة القائم على النصوص البرمجية الذي توصي به Google؛ فهي الأسهل في التنفيذ، ولا تمس HTML المرئي، وتقترن عادةً بـschema.org لأغراض SEO.

نُشر أول مرة: 26 يونيو 2026 · آخر تحديث: 13 أغسطس 2026 · Advanced
اللغات
AIمن تأليفAI v2
دليل واحد في هذه الصفحة

JSON-LD (ترميز كائنات JavaScript للبيانات المترابطة) تنسيق للبيانات المنظمة يوجد داخل وسم <script type="application/ld+json">؛ ويُقرن عادةً في SEO بمفردات schema.org لوصف محتوى الصفحة، مع أن JSON-LD نفسها تستطيع حمل مفردات أخرى. وهي معيار من W3C منذ 2014، وتوصي بها Google بدلاً من Microdata وRDFa لسبب واحد: إنها الأسهل في التنفيذ والصيانة على نطاق واسع لأنها تقع في كتلة مستقلة ولا تمس HTML المرئي. وتعمل التنسيقات الثلاثة بالقدر نفسه عند تنفيذها بصورة صحيحة. يتألف عمود الصياغة من @context (المفردات؛ schema.org لمعظم ترميز SEO، لكنها ليست القيمة الصالحة الوحيدة)، و@type (الكيان)، و@id (عنوان URI ثابت مفيد لكنه اختياري لربط الكيانات؛ وهو أساس نمط @graph، الذي يمثل بدوره طريقة صالحة لتنظيم كيانات متعددة لا متطلباً). التفصيل الذي تفوّته معظم الأدلة: يعرض Googlebot JavaScript، لذلك تعمل JSON-LD المحقونة ديناميكياً لدى Google؛ لكن عدة زواحف للذكاء الاصطناعي — منها GPTBot وClaudeBot وفق الاختبارات — لا تنفذ JavaScript. وهذا خاص بالمزوّد والتاريخ لا قاعدة عامة، لذا تحقّق مباشرة إن كان زاحف معين يهمك، واعرض الترميز من الخادم حين لا تستطيع التأكد. البيانات المنظمة ليست إشارة ترتيب؛ بل تتحكم في أهلية النتائج الغنية وتساعد على فهم الكيانات، ويجب أن تصف محتوى ظاهراً فعلاً في الصفحة.

الخلاصة — JSON-LD (ترميز كائنات JavaScript للبيانات المترابطة) توصية من W3C منذ 2014. وهي مبنية على JSON، لكن @context هو ما يجعلها بيانات مترابطة لا مجرد JSON. إنها تنسيق البيانات المنظمة الذي توصي به Google لأنه الأسهل في التنفيذ والصيانة على نطاق واسع، ولا يلمس HTML المرئي؛ ومع ذلك يظل Microdata وRDFa صالحين بالقدر نفسه عند تنفيذهما بصورة صحيحة. يتألف عمود الصياغة من @context (المفردات — schema.org لمعظم ترميز SEO، مع سماح المواصفة بسياقات أخرى)، و@type (الكيان)، و@id (عنوان URI ثابت مفيد لكنه اختياري للإحالة المتبادلة بين الكيانات — وهو أساس @graph، الذي يمثل بدوره نمطاً صالحاً من أنماط عدة لا متطلباً). ضعه في <head> أو <body>؛ تقبل Google كليهما. يعرض Googlebot JavaScript، لذلك تعمل JSON-LD المحقونة ديناميكياً لدى Google؛ لكن عدة زواحف للذكاء الاصطناعي — منها GPTBot وClaudeBot وفق الاختبارات — لا تنفذ JavaScript. وهذا سلوك خاص بالمزوّد والتاريخ، لذا تحقّق مباشرة بدلاً من افتراضه لكل زاحف، واعرض من الخادم ما لا يمكنك تأكيده. البيانات المنظمة ليست إشارة ترتيب؛ بل تدعم أهلية النتائج الغنية وفهم الكيانات، ويجب أن تصف محتوى ظاهراً في الصفحة.

JSON-LD تنسيق وليست مفردات

أولاً، تمييز يزيل قدراً كبيراً من الالتباس: JSON-LD هي التنسيق، وschema.org هي المفردات. JSON-LD هي كيفية كتابة الترميز؛ أما أنواع Article وProduct وOrganization في schema.org فهي ما تقوله. والنتائج الغنية هي طبقة الميزات المبنية فوق الاثنين. تتناول هذه الصفحة التنسيق. (أما زاوية المفردات الخاصة بالذكاء الاصطناعي فتوجد في ترميز Schema للذكاء الاصطناعي.)

JSON-LD هي توصية من W3C نُشرت أول مرة في 2014؛ أي إنها سبقت اعتمادها في SEO، وصُممت لتحقيق قابلية التشغيل البيني العامة للبيانات المترابطة عبر الويب، لا للبحث تحديداً. ويشرح هذا التاريخ سبب وجود خاصية مثل @id أصلاً، كما يوضح نقطة على مستوى المواصفة تتجاوزها معظم أدلة SEO: JSON-LD ليست مجرد JSON. فهي مبنية على صياغة JSON، لكن تصريح @context هو ما يجعل البيانات مترابطة، أي قابلة للتعريف والربط عبر الويب. أزل @context، وستبقى لديك بيانات لا يستطيع المحلل تفسيرها.

كذلك لا ترتبط JSON-LD بـschema.org وحدها. تسمح المواصفة لـ@context بالإشارة إلى أي مفردات منشورة — بل تربط أمثلتها بسياقات ليست من schema.org — لذلك تكون JSON-LD الإجابة الصحيحة عن سؤال «ما التنسيق؟»، بينما تمثل schema.org إجابة واحدة، وهي الشائعة في ترميز البحث والبحث بالذكاء الاصطناعي، عن سؤال «ما المفردات؟». يمكن لصفحة أن تستخدم JSON-LD بصورة صالحة مع مفردات أخرى؛ لكنها لن تكون عندئذٍ ترميز schema.org.

JSON-LD مقارنةً بـMicrodata وRDFa

توجد ثلاث طرق للتعبير عن البيانات المنظمة، وتدعمها Google كلها:

JSON-LDMicrodataRDFa
أين توجد؟كتلة <script> مستقلةسمات itemprop ضمن HTMLسمات property ضمن HTML
هل تمس HTML المرئي؟لانعمنعم
هل يمكن حقنها عبر JS أو مدير وسوم؟نعم (بنظافة)بصعوبةبصعوبة
موقف Googleموصى بهامدعومةمدعومة
قابلية الوقوع في الأخطاءالأدنىأعلى (لتشابكها مع الترميز)أعلى (لتشابكها مع الترميز)

توصية Google صريحة لكنها محدودة النطاق: “In general, Google recommends using JSON-LD for structured data if your site’s setup allows it, as it’s the easiest solution for website owners to implement and maintain at scale (in other words, less prone to user errors).” (ترجمة) «بوجه عام، توصي Google باستخدام JSON-LD للبيانات المنظمة إذا كان إعداد موقعك يسمح بذلك، لأنها أسهل حل يمكن لمالكي المواقع تنفيذه وصيانته على نطاق واسع (أي إنها أقل عرضة لأخطاء المستخدمين).»

أما التفصيل الذي يسقطه المنافسون عادةً — ويستحق الاحتفاظ به — فيرد في صفحة Google نفسها: “All 3 formats are equally fine for Google, as long as the markup is valid and properly implemented per the feature’s documentation.” (ترجمة) «التنسيقات الثلاثة كلها ملائمة لـGoogle بالقدر نفسه، ما دام الترميز صالحاً ومنفذاً كما ينبغي وفق وثائق الميزة.» لذا تتعلق التوصية بسهولة التنفيذ ومعدل الأخطاء، لا بسرعة التحليل أو أفضلية في الترتيب. استخدام Microdata ليس عقوبة؛ وإنما تفوز JSON-LD عملياً لأنها لا تشابك البيانات المنظمة مع الترميز الذي قد يعدّله المصمم غداً.

الصياغة: @context و@type و@id والخصائص والتداخل

إليك كتلة Article مشروحة:

<script type="application/ld+json">
{
  "@context": "https://schema.org",          // the vocabulary — the common value for SEO
  "@type": "Article",                          // the entity type
  "@id": "https://example.com/post#article",   // a stable URI for this entity
  "headline": "How JSON-LD Works",            // a property (key/value)
  "datePublished": "2026-06-26",
  "author": {                                  // a nested entity
    "@type": "Person",
    "name": "Patrick Stox",
    "url": "https://patrickstox.com/"
  }
}
</script>
  • @context — يحدد الإطار الدلالي (المفردات). تكون قيمته عادةً "https://schema.org" في ترميز schema.org الخاص بـSEO، لكن ذلك عرف لا قاعدة: يربط @context المصطلحات بالمعرّفات، وتسمح له المواصفة بالإشارة إلى مفردات أخرى. وهو يخبر المحلل بكيفية تفسير كل اسم خاصية يليه. هذا هو الجزء الذي يجعلها بيانات مترابطة.
  • @type — يعلن الكيان، مثل Article وProduct وOrganization وBreadcrumbList. ويرتبط بنوع في schema.org. استخدم أكثر الأنواع المحددة انطباقاً؛ مثلاً NewsArticle بدلاً من Article إن كان مناسباً.
  • @id — عنوان URI فريد يعرّف المورد. وهو الآلية التي تتيح الإشارة إلى كيان من كيان آخر (انظر @graph أدناه)، ويستحسن تعيينه لأي شيء ستحيل إليه؛ لكنه ليس مطلوباً دائماً. تسمح مواصفة JSON-LD بعُقد فارغة غير معرّفة، لذلك يمكن لـJSON-LD الصالحة أن تحذف @id من الكيانات التي لن تحتاج إلى الإشارة إليها في موضع آخر.
  • الخصائص — أزواج مفاتيح وقيم عادية في JSON تستخدم مصطلحات المفردات المحددة في @context.
  • التداخل — تُمثل الكيانات الفرعية بكائنات JSON متداخلة (مثل كائن author أعلاه) أو بمصفوفات من الكائنات.

نمط @graph (النهج القابل للتوسع)

تحتاج معظم الصفحات إلى أكثر من كيان: Organization وWebSite وBreadcrumbList، إضافة إلى Article أو WebPage نفسها. يتمثل النهج الساذج في أربع كتل <script> مستقلة تكرر البيانات. والبديل القابل للتوسع هو كتلة واحدة تحتوي على @graph — مصفوفة كيانات تُحال إلى بعضها بواسطة @id. لا تفرض مواصفة JSON-LD ولا Google استخدام @graph بوصفه النمط الوحيد؛ فهو صياغة للتعبير عن رسم بياني، وتوجد تخطيطات صالحة أخرى (كتل مكتوبة الأنواع منفصلة، وكائنات متداخلة بلا @graph في المستوى الأعلى، وعُقد فارغة بلا @id أصلاً). لكن في موقع يضم عدة كيانات مترابطة، يمنع هذا النمط تكرار بيانات Organization أو WebSite نفسها في كل صفحة:

Declare each entity once and connect the graph with stable `@id` references instead of repeating full objects. المصدر: Nested Schema

One Organization is referenced as publisher by the WebSite and Article. The WebPage belongs to the WebSite and is connected to the Article. Each entity is declared once, and the same stable ID string is reused for every reference.

© Patrick Stox LLC · CC BY 4.0 · 

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://example.com/#org",
      "name": "Example Co",
      "url": "https://example.com/"
    },
    {
      "@type": "WebSite",
      "@id": "https://example.com/#website",
      "url": "https://example.com/",
      "publisher": { "@id": "https://example.com/#org" }   // reference, not a copy
    },
    {
      "@type": "WebPage",
      "@id": "https://example.com/post#webpage",
      "isPartOf": { "@id": "https://example.com/#website" },
      "breadcrumb": { "@id": "https://example.com/post#breadcrumb" }
    }
  ]
}
</script>

عرّف Organization مرة واحدة، ثم أشر إليه باستخدام { "@id": "...#org" } في كل موضع آخر بدلاً من تكرار الاسم والشعار وعنوان URL. هكذا تبني إضافات schema الكبرى لأنظمة إدارة المحتوى مخرجاتها، ولهذا يوجد @id. وتقدم Bing الحجة نفسها بشأن التداخل في JSON-LD: إذ إنها “makes defining links and relationships between data and entities… easy because it supports nested data.” (ترجمة) «تجعل تعريف الروابط والعلاقات بين البيانات والكيانات سهلاً لأنها تدعم البيانات المتداخلة.»

أين توضع: في <head> أم <body>؟

تؤكد Google أن كليهما يعمل: “You can put the JSON-LD data in the <head> or the <body> of the page.” (ترجمة) «يمكنك وضع بيانات JSON-LD في <head> أو <body> من الصفحة.» الموضع <head> هو المتعارف عليه، لكن إضافات كثيرة لأنظمة إدارة المحتوى تحقنها قرب نهاية <body>، ولا مشكلة في ذلك. وتوافق Bing على إمكان وضعها “in the header, body or foot of the page.” (ترجمة) «في رأس الصفحة أو متنها أو تذييلها.» لا تهدر الوقت في نقل كتلة صالحة من المتن إلى الرأس؛ فلن يغيّر ذلك شيئاً. Evidence for this claim Google permits JSON-LD in either the head or body of an HTML document for supported structured-data features. Scope: Google Search JSON-LD guidance; markup must still match visible page content. Confidence: high · Verified: Google: Structured data introduction

إنشاء JSON-LD ديناميكياً — ومأزق زواحف الذكاء الاصطناعي

يمكنك إنشاء JSON-LD آنياً باستخدام JavaScript، وتوثق Google طريقتين لذلك:

Evidence for this claim Dynamically generated structured data is acceptable to Google when it is rendered and complies with content and quality guidelines. Scope: Google Search JavaScript and structured-data guidance; crawlability and rendering remain prerequisites. Confidence: high · Verified: Google: Generate structured data with JavaScript
  1. Google Tag Manager — وسم Custom HTML يحتوي على JSON-LD ويسحب القيم من متغيرات GTM. (تجنب تكرار البيانات بين الصفحة والوسم.)
  2. JavaScript مخصص — أنشئ عنصر script برمجياً: 
    const script = document.createElement('script');
script.setAttribute('type', 'application/ld+json');
script.textContent = structuredDataText;
document.head.appendChild(script);

يعمل هذا لدى Googlebot لأن Google تعرض الصفحة: “Google Search can understand and process structured data that’s available in the DOM when it renders the page.” (ترجمة) «يمكن لبحث Google فهم البيانات المنظمة المتاحة في DOM ومعالجتها عندما يعرض الصفحة.» لا مشكلة حتى هنا.

وهنا المأزق الذي تفوّته معظم الأدلة، بصياغة دقيقة: لم تنفذ عدة زواحف للذكاء الاصطناعي — ومنها GPTBot وClaudeBot وفق الاختبارات الشائعة — JavaScript. إذا لم توجد JSON-LD إلا بعد تشغيل نص برمجي من جهة العميل، فلن يراها زاحف يتجاوز JavaScript؛ فهي غير مرئية لذلك الروبوت، مع أن Googlebot يقرؤها بصورة سليمة لأن Google توثق عرض DOM قبل البحث عن البيانات المنظمة.

ثمة تحفظان صريحان على سلوك زواحف الذكاء الاصطناعي هذا. توثيق Google نفسه هو ما يثبت جانب Googlebot؛ أما جانب زواحف الذكاء الاصطناعي فيأتي من اختبارات وتقارير تخص مزوّدين منفردين، لا من مواصفة ينشرها أي منهم. لذلك فهو خاص بالمزوّد والتاريخ: قد يتغير دعم الزاحف لـJavaScript، ولم أتحقق مباشرة من كل مزوّد. لا تتعامل مع عبارة «زواحف الذكاء الاصطناعي تتجاوز JS» كقاعدة عامة تبني عليها؛ بل اجعلها سبباً للتحقق من الزاحف الذي يهمك فعلاً (أو اعتمد العرض من الخادم حين لا تستطيع التحقق). إذا لم تكن البيانات في HTML المعروض من الخادم ولم تؤكد أن الزاحف ينفذ JS، فافترض أنه لا يراها. لتحقيق الظهور في بحث الذكاء الاصطناعي، اعرض JSON-LD من الخادم داخل HTML الثابت ما لم تتحقق من خلاف ذلك. (هذه مشكلة عرض JavaScript من زاوية البيانات المنظمة؛ انظر JavaScript SEO.)

هناك تحفظ ثانٍ للتجارة الإلكترونية: تحذر Google من أن ترميز Product المنشأ ديناميكياً “can make Shopping crawls less frequent and less reliable,” (ترجمة) «قد يجعل عمليات زحف Shopping أقل تكراراً وأقل موثوقية»، وهي مشكلة حقيقية للأسعار والتوافر سريعي التغير. بالنسبة إلى المنتجات، فضّل العرض من الخادم بصرف النظر عن الذكاء الاصطناعي.

السياسات (لها تبعات حقيقية الآن)

إرشادات Google للبيانات المنظمة قصيرة لكنها أساسية:

  • “Don’t mark up content that is not visible to readers of the page.” (ترجمة) «لا تضع علامات على محتوى غير مرئي لقراء الصفحة.»
  • “Don’t mark up irrelevant or misleading content, such as fake reviews.” (ترجمة) «لا تضع علامات على محتوى غير ذي صلة أو مضلل، مثل المراجعات الزائفة.»
  • “Put the structured data on the page that it describes.” (ترجمة) «ضع البيانات المنظمة في الصفحة التي تصفها.»
  • “Use the most specific applicable type and property names defined by schema.org.” (ترجمة) «استخدم أكثر أسماء الأنواع والخصائص المحددة انطباقاً من الأسماء التي تعرّفها schema.org.»
  • لا تحجب صفحات البيانات المنظمة عن Googlebot بواسطة robots.txt أو noindex.

قاعدة المحتوى المرئي هي التي ينبغي ترسيخها. لطالما كان استخدام schema لوصف محتوى غير ظاهر في الصفحة مخالفة، وقد تشدد تطبيق القواعد على schema «غير المرئية». وتقدم Bing التحذير بوضوح: “even though the markup is not visible on your page, it is still read by the search engines, and putting spam data in the markup can hamper your presence.” (ترجمة) «مع أن الترميز غير مرئي في صفحتك، فإن محركات البحث تقرؤه، وقد يضر وضع بيانات مزعجة في الترميز بحضورك.»

أخطاء JSON-LD الشائعة

  • ترميز لا يطابق الصفحة المرئية — مشكلة السياسة الأولى (مثل تقييم في JSON-LD لا يراه أي زائر).
  • JSON مشوه — فاصلة لاحقة، أو علامة اقتباس غير مهروبة، أو علامات الاقتباس الذكية في Word (" بدلاً من ") التي تكسر الكتلة كلها بصمت. JSON-LD صارمة.
  • أسماء خصائص خاطئة — ابتكار خصائص غير موجودة في schema.org أو كتابة الخصائص الحقيقية بخطأ، فيتجاهلها المحلل.
  • نوع عام مع وجود نوع محدد — استخدام Thing أو Article حين يلزم Recipe أو NewsArticle.
  • كتل Organization مكررة وغير متسقة عبر الصفحات بأسماء أو شعارات متعارضة.
  • خصائص مطلوبة مفقودة للنتيجة الغنية التي تستهدفها (لكل ميزة حقولها المطلوبة).
  • افتراض أن الترميز المحقون بـJS مرئي لكل زاحف — تعرضه Google، لكن بعض زواحف الذكاء الاصطناعي لم تعرضه، ويستحق ذلك التحقق لكل زاحف على حدة (المأزق أعلاه).

التحقق من JSON-LD

تُطرح أربعة أسئلة مختلفة تحت عنوان «هل JSON-LD الخاصة بي صالحة؟»، وليست هي السؤال نفسه؛ فالنجاح في أحدها لا يعني النجاح في البقية:

الاختبارما يثبتهما لا يثبته
تحليل JSON (أي مدقق JSON، أو خطوة التحليل في Rich Results Test)أن الصياغة JSON قانونية — بلا فواصل لاحقة أو علامات اقتباس غير مهروبة أو أعطال بسبب علامات الاقتباس الذكيةأن أي اسم خاصية ينتمي فعلاً إلى مفردات schema.org، أو أن Google ستعرض أي شيء
Schema.org Validatorأن الخصائص والأنواع موجودة في مفردات schema.orgأن Google تدعم النوع كنتيجة غنية، أو أن الحقول المطلوبة لميزة محددة موجودة
Rich Results Testأن الترميز يلبي متطلبات Google لنوع محدد من النتائج الغنية المدعومة في الصفحة المعروضة التي اختبرتهاأن Google ستعرض النتيجة الغنية فعلاً — فالأهلية ليست ضماناً — أو أن أنظمة البحث والذكاء الاصطناعي الأخرى تحللها بالطريقة نفسها
Google Search Console — تقارير Enhancements / النتائج الغنيةما حللته Google فعلاً في صفحات حية جرى الزحف إليها، على نطاق واسع، مع الأخطاء الحقيقيةالحالة الآنية — تتأخر التقارير إلى ما بعد إعادة الزحف
  • اختبر باستخدام عنوان URL لا شيفرة ملصقة في الصفحات المعروضة عبر JS. لا يشغّل وضع إدخال الشيفرة في Rich Results Test نصوصك البرمجية ولا يحل المراجع النسبية كما يفعل اختبار عنوان URL حي؛ لذلك لا يستطيع إخبارك بشكل الكتلة المحقونة من جهة العميل بعد العرض.
  • Bing Webmaster Tools — Markup Validator — تدعم Bing التحقق من JSON-LD منذ أغسطس 2018.
  • لا يتحدث أي من هذه الاختبارات باسم الزواحف التي لا تعرض JavaScript (انظر تحفظ زواحف الذكاء الاصطناعي أعلاه)؛ فتجربة عنوان URL المعروض تؤكد ما تراه Google، لا ما يتلقاه روبوت يتجاوز JS.

هل تساعد JSON-LD في SEO؟

ضع توقعات صريحة:

  • ليست إشارة ترتيب. قال John Mueller إن البيانات المنظمة لن تجعل الموقع يحقق ترتيباً أفضل. انتهى الأمر.
  • أهلية النتائج الغنية. هي ما يجعلك مؤهلاً لميزات SERP المحسّنة (النجوم والأسعار والأسئلة الشائعة ومسارات التنقل) — أهلية لا ضماناً.
  • CTR بصورة غير مباشرة. قد تكسب النتائج الأثرى مظهراً نقرات أكثر، وهذه هي الفائدة الحقيقية لمعظم المواقع.
  • فهم الكيانات. تساعد المحركات على ربط صفحتك بالكيانات المعروفة وKnowledge Graph.
  • بحث الذكاء الاصطناعي. أكد Fabrice Canel من Bing في 2025 أن ترميز schema يساعد نماذج Microsoft اللغوية الكبيرة على فهم المحتوى؛ لكن لاحظ تحفظ الدراسة المنضبطة في ترميز Schema للذكاء الاصطناعي: فهو بنية تحتية لإزالة الالتباس، لا رافعة مباشرة للاستشهاد.

الخلاصة: نفّذ JSON-LD من أجل أهلية النتائج الغنية ووضوح الكيانات وفهم الذكاء الاصطناعي والنماذج اللغوية الكبيرة، لا بوصفها حيلة للترتيب.

تقع هذه المقالة ضمن محور البيانات المنظمة. وللتناول الخاص بالذكاء الاصطناعي لمفردات schema.org، راجع ترميز Schema للذكاء الاصطناعي؛ ولميكانيكا العرض وراء الحقن الديناميكي، راجع JavaScript SEO.

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.