اللغات

تداخل ترميز Schema ‏(@id و@graph)

دليل متعمق لربط كيانات JSON-LD بواسطة @id و@graph: المعرّفات الثابتة، ونمطا العقد القياسيان WebSite→Article→Author وProduct→Offer→Organization، والأخطاء الثلاثة التي تكسر الرسم البياني، والحدود الصريحة لما تؤكده وثائق Google.

نُشر أول مرة: 2 يوليو 2026 · آخر تحديث: 22 أغسطس 2026 · Advanced
اللغات
AIمن تأليفAI v2

يربط التداخل كيانات JSON-LD بدلاً من تركها كتلًا منفصلة. ‏@id معرّف URI ثابت وفريد — عادةً عنوان URL أساسي مع ‎#fragment — يسمّي الكيان كي تشير إليه كيانات أخرى، مثل إشارة مؤلف Article إلى عقدة Person أو إشارة Offer في Product إلى Organization البائعة، بدلاً من إعادة تعريف الكيان كاملاً في كل موضع. وتجمع @graph تلك الكيانات في كتلة script واحدة. تؤكد وثائق Google عمل التداخل والعناصر المنفردة وأن @id يربط العناصر، لكنها لا تؤكد حل @id عبر الصفحات؛ لذا فالخيار الآمن هو قيم @id متسقة مع الرسم الكامل في كل صفحة تحتاج إليه. النمطان الرئيسيان هما WebSite → WebPage → Article → Author للنشر، وProduct → Offer → Organization للتجارة الإلكترونية. أما الإخفاقات فهي قيم @id غير المتسقة أو غير الفريدة، والمراجع اليتيمة، والتعريفات الكاملة المكررة. إنها أداة لفهم الكيانات، لا رافعة ترتيب أو نتائج غنية بذاتها.

الخلاصة — يربط التداخل كيانات JSON-LD عبر @id (معرّف URI ثابت وفريد، يكون عادةً عنوان URL أساسياً مع #fragment)، فتشير إلى الكيان بدلاً من إعادة تعريفه، ويجمع @graph الكيانات المترابطة في كتلة script واحدة. تؤكد وثائق Google عمل التداخل والعناصر المنفردة، وأن @id يربط العناصر ذات الصلة، لكنها لا تؤكد حل @id عبر الصفحات. لذلك فالخيار الآمن هو قيم @id متسقة مع الرسم البياني الكامل في كل صفحة تحتاج إليه. تعلّم نمطين: WebSite → WebPage → Article → Author للنشر، و Product → Offer → Organization/seller للتجارة الإلكترونية. وراقب ثلاثة إخفاقات: قيم @id غير المتسقة أو غير الفريدة، والمراجع اليتيمة (الإشارة إلى @id غير معرّف — نقص دلالي لا صياغة JSON-LD غير صالحة)، والتعريفات الكاملة المكررة للكيان نفسه (فخ صيانة؛ تدمج قواعد العقد في JSON-LD تكرارات الكيان نفسه، لكن إعادة استخدام @id واحد لكيانات مختلفة فعلاً تعارض حقيقي). إنها أداة لفهم الكيانات وإزالة الالتباس والتكرار، لا رافعة ترتيب أو نتائج غنية بذاتها.

Evidence for this claim JSON-LD supports connected nodes via nesting or @id references, allowing multiple related entities to form one graph. Scope: JSON-LD graph model. Confidence: high · Verified: W3C JSON-LD 1.1 Evidence for this claim Google requires structured data to represent visible page content and follow each feature's specific nesting and property guidelines; extra valid nodes do not create eligibility by themselves. Scope: Current Google structured-data general guidelines. Confidence: high · Verified: Google Search Central: Structured data general guidelines

النطاق: هذا تعمق لا مقدمة

تفترض هذه المقالة أنك تعرف JSON-LD ولماذا هي التنسيق الموصى به؛ وتغطي صفحة ترميز schema ذلك وتقدم @id و@graph سريعاً. أما هنا فالتعمق المؤجل: الآليات الفعلية وأنماط العقد القياسية والأخطاء المحددة التي تكسر الرسم بصمت. وإذا أردت أساسيات التنسيق أو موضع كتلة <script>، فراجع JSON-LD.

@id — معرّف ثابت، لا عنوان URL قابل للجلب

يسند @id معرّف URI فريداً إلى كيان JSON-LD كي تشير إليه كيانات أخرى. والعرف المتسق بين المصادر الموثوقة التي راجعتها هو عنوان URL أساسي مطلق مع fragment وصفي:

"@id": "https://example.com/#organization"
"@id": "https://example.com/#website"
"@id": "https://example.com/team/jane-doe/#person"

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

  • لا يلزم أن يُحل. وفق مواصفة JSON-LD، تتمثل وظيفة @id في تعريف العقدة — اسم فريد وثابت للكيان — لا في قابلية الجلب. واستخدام fragment على نطاقك ممارسة معتادة لا تتطلب تحميل عنوانه مستقلاً كصفحة. ويلخص دليل معرّفات العقد لدى Sitebulb الأمر جيداً: “a unique ‘name’ for an entity, which is publicly accessible and can be looked up or linked to.” (ترجمة) «اسم فريد لكيان، متاح علناً ويمكن البحث عنه أو الربط إليه».
  • @id ليست url. فهما خاصيتان بوظيفتين مختلفتين. تعرّف @id العقدة داخل الرسم البياني، بينما تصف url صفحة حقيقية قابلة للجلب عن الكيان. ويمكن لـOrganization، وغالباً ينبغي لها، امتلاكهما معاً: @id بقيمة https://example.com/#organization وurl بقيمة https://example.com/.

وقيم @id حساسة لحالة الأحرف؛ فـ#Organization و#organization كيانان مختلفان. اختر عرفاً ولا تنحرف عنه.

@graph — جمع الكيانات المترابطة في كتلة واحدة

@graph كلمة مفتاحية في JSON-LD تتيح وضع عدة كيانات عليا في مصفوفة واحدة داخل كتلة <script type="application/ld+json"> واحدة، مع إحالات متبادلة بين الكيانات بواسطة @id:

{
  "@context": "https://schema.org",
  "@graph": [
    { "@type": "Organization", "@id": "https://example.com/#organization", "...": "..." },
    { "@type": "WebSite", "@id": "https://example.com/#website", "...": "..." },
    { "@type": "WebPage", "@id": "https://example.com/post/#webpage", "...": "..." }
  ]
}

@graph حاوية وليست متطلباً. يمكنك استخدام كتل <script> منفصلة للعناصر المنفردة؛ وتؤكد وثائق Google عمل النهجين. سبب استخدام @graph هو سهولة الصيانة: عند وجود ثلاثة كيانات أو أكثر تحيل بعضها إلى بعض، تكتب @context مرة واحدة في الأعلى بدلاً من تكراره في كل كتلة، وتجتمع كل العلاقات في موضع واحد. وهذا هو النمط الذي تستخدمه Yoast في الإنتاج؛ إذ تشرح وثائق بنية schema أن الرسم المشترك يتيح لهم “avoid having to duplicate or repeat shared properties, and to reduce the amount of code/processing/overhead required.” (ترجمة) «تجنب تكرار الخصائص المشتركة وتقليل الشيفرة والمعالجة والأعباء المطلوبة».

لماذا نستخدم التداخل، وماذا تقول Google فعلاً؟

Declare each entity once and connect the graph with stable `@id` references instead of repeating full blocks.

One Organization identified as hash 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 at-id string is reused for every reference.

توثق Google خيارين بنيويين وتؤكد أنها تفهم كليهما. تقول في الإرشادات العامة للبيانات المنظمة: “Google Search understands multiple items on a page, whether you nest the items or specify each item individually.” (ترجمة) «يفهم بحث Google عناصر متعددة في الصفحة، سواء أدخلت العناصر بعضها تحت بعض أو حددت كل عنصر على حدة». وتعرّفهما بوضوح: التداخل هو “when there is one main item, and additional items are grouped under the main item” (ترجمة) «أن يوجد عنصر رئيسي واحد وتُجمع العناصر الإضافية تحته»، والعناصر المنفردة هي “when each item is a separate block on the same page” (ترجمة) «أن يكون كل عنصر كتلة مستقلة في الصفحة نفسها».

أقرب فقرة إلى تعليل رسمي لاستخدام @id تقول: ““If there are items that are more helpful when they are linked together (for example, a recipe and a video), use @id in both the recipe and the video items to specify that the video is about the recipe on the page. If you didn’t link the items together, Google Search may not know that it can show the video as a Recipe rich result.”” (ترجمة) «إذا كانت هناك عناصر تصبح أكثر فائدة عند ربطها، مثل وصفة وفيديو، فاستخدم @id في كليهما لتحديد أن الفيديو عن وصفة الصفحة؛ وإن لم تربط العناصر فقد لا يعرف بحث Google أنه يستطيع عرض الفيديو كنتيجة غنية لوصفة». هذه هي الآلية بكلمات Google: تخبر @id Google أن عنصرين ينتميان معاً.

ملاحظة صريحة: تذكر وثائق Google هذا المبدأ نثراً، لكنها لا تقدم مثال شيفرة عملياً يجمع @graph و@id؛ إذ تعرض أمثلتها Recipe متداخلة وعنصرين علويين منفردين، ولا يحيل أي منهما فعلياً بواسطة @id. وتسد الأمثلة أدناه هذه الفجوة.

يتصل ذلك مباشرةً بوظيفتي schema كما تعرضهما صفحة ترميز schema: فالتداخل الجيد حركة تخص فهم الكيانات — إزالة الالتباس وتجنب البيانات المتناقضة أو المكررة — وليس مشغلاً لنتيجة غنية بمفرده. وربط Article بمؤلفه Author بوضوح لا يفتح ميزة SERP جديدة؛ بل يزيل الغموض عن العلاقة.

النمط 1 — WebSite → WebPage → Article → Author

هذا نمط النشر القياسي: Organization واحدة (الناشر) وWebSite واحد، ثم WebPage لكل صفحة وArticle عليها، مع حل author وpublisher بواسطة @id بدلاً من إعادة تعريفهما:

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://example.com/#organization",
      "name": "Example Media",
      "url": "https://example.com/",
      "logo": "https://example.com/logo.png",
      "sameAs": [
        "https://www.linkedin.com/company/example-media/",
        "https://en.wikipedia.org/wiki/Example_Media"
      ]
    },
    {
      "@type": "WebSite",
      "@id": "https://example.com/#website",
      "url": "https://example.com/",
      "name": "Example Media",
      "publisher": { "@id": "https://example.com/#organization" }
    },
    {
      "@type": "WebPage",
      "@id": "https://example.com/nesting-schema/#webpage",
      "url": "https://example.com/nesting-schema/",
      "name": "Nesting Schema Markup",
      "isPartOf": { "@id": "https://example.com/#website" }
    },
    {
      "@type": "Person",
      "@id": "https://example.com/team/jane-doe/#person",
      "name": "Jane Doe",
      "url": "https://example.com/team/jane-doe/",
      "sameAs": ["https://www.linkedin.com/in/jane-doe/"]
    },
    {
      "@type": "Article",
      "@id": "https://example.com/nesting-schema/#article",
      "mainEntityOfPage": { "@id": "https://example.com/nesting-schema/#webpage" },
      "headline": "Nesting Schema Markup",
      "author": { "@id": "https://example.com/team/jane-doe/#person" },
      "publisher": { "@id": "https://example.com/#organization" }
    }
  ]
}

لاحظ ما يحدث: author وpublisher مرجعان من سطر واحد. ويُعرّف كل من Person وOrganization مرة واحدة. وتتبع Article صفحة WebPage عبر mainEntityOfPage، وهي isPartOf موقع WebSite الذي تنشره Organization. هذا رسم مترابط، لا خمس جزر منفصلة.

النمط 2 — Product → Offer → Organization (البائع)

هذا هو النظير في التجارة الإلكترونية، وهنا تظهر قيمة التداخل على نطاق واسع: بدلاً من إعادة تعريف Organization التجارية في كل صفحة من آلاف صفحات المنتجات، عرّفها مرة واحدة وأشر إليها بصفتها seller:

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://shop.example.com/#organization",
      "name": "Example Shop",
      "url": "https://shop.example.com/",
      "logo": "https://shop.example.com/logo.png"
    },
    {
      "@type": "Product",
      "@id": "https://shop.example.com/widget/#product",
      "name": "Deluxe Widget",
      "sku": "WIDGET-001",
      "brand": { "@type": "Brand", "name": "Example" },
      "offers": {
        "@type": "Offer",
        "price": "29.99",
        "priceCurrency": "USD",
        "availability": "https://schema.org/InStock",
        "seller": { "@id": "https://shop.example.com/#organization" }
      }
    }
  ]
}

يشير seller في Offer إلى عقدة Organization المشتركة. إنه البائع نفسه بتعريف واحد يُشار إليه من كل منتج. (وفي مجموعات المتغيرات الكبيرة يمتد مبدأ @id المشترك نفسه إلى ProductGroup مع منتجات Product متغيرة؛ وهذا تخصص للنمط نفسه لا آلية مختلفة.)

الأخطاء الثلاثة التي تكسر الرسم البياني

هذا هو لب التدقيق العملي. فعندما «لا يعمل» التداخل، يكون السبب في الغالب واحداً من هذه الثلاثة.

1. قيم @id غير المتسقة أو غير الفريدة

قد يُمنح الكيان نفسه سلاسل @id مختلفة عبر الصفحات أو أثناء إعادة بناء المنصة أو ترحيلها، فترى محركات البحث والمدققات كيانات غير مترابطة بدلاً من كيان واحد. أو يحدث العكس: يُعاد استخدام @id واحد لكيانين مختلفين فعلاً. والحل عرف صارم وموثق، مثل {base-url}/#organization و{page-url}/#webpage و {profile-url}/#person، يطبق آلياً. حالة الأحرف مهمة: #author ≠ #Author.

2. المراجع اليتيمة

يُشار إلى @id من دون أن يُعرّف. فقد تكتب "author": {"@id": "https://example.com/#person-jane"}، لكن لا توجد عقدة في المستند المختبر تعرّف ذلك @id مع @type وخصائصه. وللدقة، فإن كائن {"@id": "..."} المجرد — الذي تسميه مواصفة JSON-LD مرجع عقدة: “a node object used to reference a node having only the @id key” (ترجمة) «كائن عقدة يُستخدم للإشارة إلى عقدة ولا يحتوي إلا مفتاح @id» — صياغة JSON-LD صالحة بذاتها، وليست خطأ تحليل. المشكلة دلالية وخاصة بالمستهلك: فالعلاقة المقصودة — «مؤلف هذه Article هو ذلك Person» — لا تُحل إلى شيء مفيد، فتفقد أي ميزة أو قارئ يحتاج اسم المؤلف أو عنوانه أو بيانات sameAs. وهذه الحالة خادعة لأن المدققات غالباً تظل تحلل كل عنصر معلن بلا خطأ؛ فتنشر رسماً ناقصاً ولا تلاحظ. ويسجل دليل @id لدى Momentic ذلك ضمن أكثر إخفاقات التداخل شيوعاً.

3. التعريفات الكاملة المكررة للكيان نفسه

هذا عكس اليتم: إعادة تعريف كائن Organization أو Person كاملاً داخل كل صفحة بدلاً من تعريفه مرة واحدة والإشارة إليه. وقد يحدث أمران مختلفان، ومن المهم التمييز بينهما:

  • تعريفات متكررة للكيان نفسه فعلاً. تقول مواصفة JSON-LD: “the properties of a node in a graph may be spread among different node objects within a document. When that happens, the keys of the different node objects need to be merged to create the properties of the resulting node.” (ترجمة) «قد تتوزع خصائص عقدة في الرسم بين كائنات عقد متعددة داخل مستند؛ وعندها يجب دمج مفاتيح تلك الكائنات لتكوين خصائص العقدة الناتجة». لذلك لا يفشل التحليل عند تكرار @id نفسه ببيانات متطابقة أو متوافقة؛ بل تدمجه المعالجات. ولا يجعل ذلك التكرار فكرة جيدة: فهو ما وُجد التداخل لمنعه، ويضخم الترميز ويصنع فخ صيانة؛ حدّث عنوانك أو شعارك في قالب وانس أربعين قالباً أخرى، فيتناقض الكيان عبر الموقع. وتعرض تغطية Ahrefs وSchema App المستقلة نقطة «غيّر واحداً وانس البقية» نفسها.
  • إعادة استخدام @id نفسه لكيانين مختلفين فعلاً. هذا هو الكسر الحقيقي: يشترك كائنان عقديان في معرّف لكنهما يصفان أشياء متعارضة، كاسم أو شعار أو @type مختلف. هذا تعارض دلالي لا دمج سليم؛ استخدم @id مستقلاً لكل كيان منفصل.

عرّف مرة واحدة وأشر من كل موضع؛ وتظل حجة الصيانة صحيحة في الحالتين، حتى لو لم يكسر تكرار الكيان نفسه الرسم تقنياً كما يفعل مرجع يتيم أو @id متعارض.

السؤال غير المحسوم: هل يُحل @id عبر الصفحات؟

هنا الحد الصريح الذي يفصل الإجابة الحقيقية عن الإجابة الواثقة الخاطئة. لا تذكر وثائق Google صراحةً أبداً ما إذا كانت مراجع @id تُحل عبر الصفحات؛ مثلاً أن يشير Offer.seller في صفحة منتج إلى عقدة Organization لا تُعرّف إلا في الصفحة الرئيسية. ولا تستخدم وثائق Search Central عبارة cross-page أو across pages في سياق @id.

تشير الإشارة القريبة الوحيدة إلى صفحات مكتفية ذاتياً: توصي Google بشأن المحتوى المكرر بـ*“placing the same structured data on all page duplicates, not just on the canonical page”* (ترجمة) «وضع البيانات المنظمة نفسها على كل نسخ الصفحة، لا الصفحة الأساسية وحدها»؛ ما يوحي بأن البيانات المنظمة تُقيّم لكل صفحة ولا تُجلب من موضع آخر. ولم أستطع التحقق من تصريح علني لممثل مسمى من Google أو Bing، مثل Mueller أو Illyes أو Splitt، يحسم سؤال @id عبر الصفحات. ولدى Bing تحقق JSON-LD في Webmaster Tools، لكنها لا تنشر أي إرشاد خاص بـ@id أو @graph؛ وهذه فجوة توثيق حقيقية لا موقف سأختلقه لها.

لذلك، حتى يوليو 2026، تعامل مع عبارة «تتبع Google روابط @id عبر الصفحات» بصفتها استنتاجاً قطاعياً لا سلوكاً مؤكداً. والخيار الآمن الذي تتوافق عليه Yoast وMomentic وSchema App بصورة مستقلة هو: حافظ على اتساق قيم @id للكيان نفسه في كل موضع، لكن أخرج الرسم الكامل في كل صفحة تحتاج إليه. لا تفترض أن Google ستجلب كياناً مرجعياً من عنوان URL آخر. وهذا بالضبط خيار Yoast في الإنتاج؛ إذ تُخرج الرسم الكامل في كل صفحة ولا تعتمد على الحل عبر الصفحات.

كيفية التحقق من schema المتداخلة

أداتان:

  • Rich Results Test — وفق اختبار الممارسين في يوليو 2026، تحلل الأداة مصفوفات @graph وتحل مراجع @id داخل المستند المختبر: عندما يشير الكيان A إلى B بواسطة @id ويُعرّف B في الرسم نفسه، يظهران مترابطين؛ وعندما لا يُعرّف @id المرجعي في الترميز، تظل الأداة تحلل العناصر المعلنة منفردة بلا خطأ، لكنها لا تعرض العلاقة. ولا توثق Google سلوك الواجهة هذا صراحةً، لذلك عامله كسلوك أداة ملحوظ قابل للتكرار، لا كمواصفة رسمية، وأعد اختباره إذا تغيرت الواجهة. ولهذا تمر المراجع اليتيمة: لا خطأ، بل رابط مفقود.
  • Schema Markup Validator — مدقق مفردات schema.org، وهو أقل ارتباطاً بقائمة Google لأنواع النتائج الغنية المدعومة.

اختبر الصفحة المعروضة لا مصدر القالب فقط؛ فإذا حُقنت JSON-LD بواسطة JavaScript، فتحقق من وجودها فعلاً. توثق Google قراءة JSON-LD المحقون ديناميكيًا بواسطة JavaScript، لكن ذلك خاص بـGoogle؛ إذ يختلف تنفيذ JavaScript باختلاف الزاحف والمنتج، ولا توجد قاعدة عامة بأن كل زاحف ذكاء اصطناعي يعرض JS بالطريقة نفسها أو يعرضه أصلاً. الخيار المتحفظ هو شحن JSON-LD في HTML الأولي بدلاً من افتراض تنفيذها؛ وهذه مسألة schema-markup-for-AI.

خرافات تستحق الإنهاء

  • «يجب أن يكون @id عنوان URL حقيقياً حياً قابلاً للجلب». لا؛ فالعرف هو عنوان URL أساسي مع fragment، لكن وظيفته التعريف لا الجلب، ولا يلزم أن يُحل الجزء إلى صفحة مستقلة.
  • «يؤدي @id نفسه في صفحات مختلفة إلى دمج الكيانات تلقائياً في فهرس Google، كما يوحد canonical الصفحات». لا تؤكد ذلك أي وثيقة من Google. اتساق @id ممارسة سليمة، وليس آلية دمج مثبتة عبر الصفحات.
  • «يجب استخدام @graph؛ وكتل script المنفصلة خاطئة». خطأ. تفهم Google الطريقتين، و@graph خيار صيانة.
  • «يزيد التداخل دائماً فهم الكيانات». فقط إذا كانت الكيانات مرتبطة فعلاً. فتداخل عناصر غير مرتبطة، مثل Event لا علاقة له تحت Recipe في مثال Schema App، لا يفيد وقد يشوش الإشارات.
  • «بنية @id و@graph عامل ترتيب أو نتائج غنية». لا. قيمتها إزالة الالتباس وتقليل التكرار، بما يتسق مع أن schema ليست عامل ترتيب أصلاً.
  • «@id غير المعلن غير ضار؛ تتجاهله المحركات فحسب». هذا إخفاق المرجع اليتيم: لا تتكون العلاقة المقصودة بصمت، وغالباً لا تعرض الأدوات خطأ، فتنشره بلا ملاحظة.

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

هذه هي طبقة الكيفية تحت محور البيانات المنظمة، وشقيق أعمق لـ ترميز schema الذي يقدم @id و@graph، ولـJSON-LD بصفتها التنسيق. وتعتمد على تفكير فهم الكيانات نفسه في الكيانات و ترميز schema للذكاء الاصطناعي: فالرسم الجيد بنية تحتية للكيانات، سواء كان المستهلك Knowledge Graph لدى Google أو نموذجاً لغوياً كبيراً. وتقع المجموعة الفرعية كلها داخل SEO داخل الصفحة.

Add an expert note

Pin an expert quote

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