قد يحتوي كل جزء من موقعك على schema، لكن محرك الذكاء الاصطناعي قد يقرأها من دون أن يعرف الموقع الذي تنتمي إليه WebPage أو الجهة التي تديره. المشكلة ليست في عدد الوسوم؛ بل في أنها لا تعرف علاقتها ببعضها. فعندما تكتب Organization وWebSite وWebPage ككتل JSON-LD منفصلة، فكأنك تقدّم للآلة ثلاث بطاقات أعمال بلا أي رابط بينها. هنا يأتي دور @graph: يصل هذه البطاقات بخط واضح، ليمنح الذكاء الاصطناعي صورة متكاملة عن البنية الفعلية للموقع.
لماذا تعجز schema المتفرقة عن تقديم صورة متكاملة لموقعك إلى الذكاء الاصطناعي؟
تُنشئ معظم المواقع schema تلقائياً عبر الإضافات أو قوالب CMS: كيان Organization للصفحة الرئيسية، وArticle لصفحة المقال، وProduct لصفحة الأسعار. وعند فحص كل كتلة بمفردها، تبدو صحيحة وتتجاوز اختبار Rich Results. لكن عندما تحاول الآلة الإجابة عن سؤال مثل: «من ناشر هذا المقال، وهل يمكن الوثوق به؟»، فإنها لا ترى سوى مجموعة من الكائنات المعلّقة بلا حقل يوضّح أن ناشر Article هو كيان Organization المعرّف في الصفحة الرئيسية. وتزداد أهمية ذلك في ملخصات الذكاء الاصطناعي ومحركات الإجابة، لأن قرار الاستشهاد بمحتواك يعتمد بدرجة كبيرة على إمكانية ربطه بمؤسسة حقيقية قابلة للتحقق. من دون هذه العلاقة، قد يُعامل المحتوى بوصفه نصاً مجهول المصدر بدلاً من اعتباره معلومة رسمية صادرة عن الشركة.
ما الذي يفعله @graph فعلياً؟
@graph حقل من المستوى الأعلى في JSON-LD، وتكون قيمته مصفوفة يمكن أن تضم عدة كائنات تمثّل كيانات مختلفة. وهو يجمع الكيانات التي كان يمكن توزيعها على عدة وسوم script داخل ملف واحد ونطاق تسمية واحد. لكن القيمة الحقيقية لا تكمن في «وضعها معاً»، بل في تمكين هذه الكائنات من الإشارة إلى بعضها عبر @id: تعرّف @id داخل Organization، ثم تضع القيمة نفسها في حقل publisher ضمن WebSite، فتفهم الآلة أنهما يشيران إلى الكيان ذاته من دون الحاجة إلى نسخ Organization بالكامل مرة أخرى. ويُعد مبدأ التعريف مرة واحدة والإشارة إليه في كل موضع أساسياً في الرسوم البيانية المعرفية؛ لذلك يدعم schema.org حقل @graph كي تعبّر الصفحة عن العلاقات بين الكيانات، لا أن تكتفي بسرد مجموعة من الخصائص.
يكفي وسم script واحد لاحتواء @graph الكامل في الصفحة. وهذا يعالج أيضاً مشكلة قديمة: أن تكتب ثلاث إضافات كيان Organization نفسه كلٌ على حدة، ثم تتعارض خصائصه بينها. مع @graph لا تظهر الشركة إلا مرة واحدة، فتغدو المصدر الوحيد للحقيقة على مستوى الموقع، ولا تحتاج عند الصيانة إلى تعديل بياناتها في أكثر من موضع.
@id: امنح كل كيان عنواناً ثابتاً
@id هو الأساس الذي تقوم عليه هذه الطريقة. إنه معرّف نصي فريد على مستوى النطاق، ويأتي عادةً في صورة URL متبوعاً بعلامة تجزئة، مثل https://example.com/#organization. ولا يشترط أن يؤدي فتح هذه القيمة إلى صفحة؛ فوظيفتها التعريف بالكيان، لا العمل كرابط. ما دام الكيان نفسه يستخدم @id ذاته في جميع أجزاء الموقع، يستطيع الذكاء الاصطناعي جمع المعلومات الموزعة على الصفحات تحت موضوع واحد. وعندما يظهر @id نفسه في الصفحة الرئيسية وصفحة المقال وصفحة الأسعار، تستطيع الآلة ضم أوصاف الشركة الواردة في هذه الصفحات إلى سجل أكثر اكتمالاً وأصعب تزييفاً.
- استخدم مع Organization جذر النطاق مضافاً إليه جزء تعريفي، مثل https://example.com/#organization، ليكون فريداً على مستوى الموقع ويشير دائماً إلى الشركة نفسها.
- استخدم مع WebSite جذر النطاق مضافاً إليه #website لتمثيل كيان الموقع بالكامل.
- استخدم مع WebPage في كل صفحة «URL الصفحة + #webpage»، بحيث تختلف القيمة من صفحة إلى أخرى.
- ثبّت تسمية الأجزاء وفق اتفاق واضح داخل الفريق (#organization و#website و#webpage)؛ فلا تستخدم #org اليوم ثم #company غداً.
- بعد نشر @id، لا تغيّره بلا سبب؛ فتغييره يعادل إنشاء كيان جديد ويقطع جميع العلاقات المتراكمة سابقاً.
كيف تشير الكيانات الثلاثة إلى بعضها؟
يتبع اتجاه الربط منطقاً واضحاً: من الأصغر إلى الأكبر، ومن الصفحة إلى الكيان الرئيسي. يستخدم WebSite حقل publisher للإشارة إلى Organization وإعلان أن هذه الشركة هي الجهة التي تدير الموقع. وتستخدم كل WebPage حقل isPartOf للإشارة إلى WebSite والتصريح بأنها جزء منه. وإذا كانت الصفحة تتناول الشركة نفسها، مثل صفحة «من نحن» أو الأسعار، فاستخدم about أو mainEntity للإشارة مجدداً إلى Organization. وفي صفحة المقال، اجعل publisher داخل Article يشير أيضاً إلى @id الخاص بذلك الكيان Organization، وبذلك تكتمل علاقة الناشر.
مثال متكامل جاهز للتطبيق
ضع @graph التالي داخل <head> في الصفحة؛ إذ يستطيع وسم script واحد احتواء الكيانات الثلاثة. يعرّف كل كيان @id مرة واحدة، ثم تستخدم الكيانات @id للإشارة إلى بعضها بدلاً من نسخ Organization مجدداً. عملياً، يمكن فصل جزأي Organization وWebSite في قالب مشترك على مستوى الموقع وكتابتهما مرة واحدة، بينما تُدرج بيانات WebPage ديناميكياً مع url وname و@id لكل صفحة. { "@context": "https://schema.org", "@graph": [ { "@type": "Organization", "@id": "https://example.com/#organization", "name": "Example company", "url": "https://example.com/", "logo": { "@type": "ImageObject", "url": "https://example.com/logo.png" }, "sameAs": [ "https://www.linkedin.com/company/example", "https://x.com/example" ] }, { "@type": "WebSite", "@id": "https://example.com/#website", "url": "https://example.com/", "name": "Example", "publisher": { "@id": "https://example.com/#organization" } }, { "@type": "WebPage", "@id": "https://example.com/pricing#webpage", "url": "https://example.com/pricing", "name": "Pricing plan", "isPartOf": { "@id": "https://example.com/#website" }, "about": { "@id": "https://example.com/#organization" } } ] }
الأخطاء الأربعة الأكثر شيوعاً
- عدم اتساق @id: تستخدم الصفحة الرئيسية #organization، بينما يضع publisher في صفحة المقال URL كاملاً مختلفاً أو يحذف الجزء الذي يبدأ بعلامة التجزئة، فتتعامل الآلة معهما كشركتين مختلفتين.
- وضع الكائن الكامل في موضع المرجع: إعادة كتابة Organization بالكامل داخل publisher تنشئ نسختين من الكيان نفسه، وقد تتعارض خصائصهما.
- ترك الكيانات بلا روابط: لا تحتوي WebPage على isPartOf، ولا تحتوي Article على publisher. قد يكون الكائن صحيحاً من الناحية التقنية، لكنه يظل منفصلاً عن الكيان الرئيسي.
- استخدام URL متغيّر بوصفه @id: ما إن يتغيّر الرابط بسبب معلمات التتبّع أو الجلسة حتى يُنشأ كيان إضافي وتبدأ جميع العلاقات من جديد.
ثقة الذكاء الاصطناعي بموقعك لا تأتي من كثرة الوسوم، بل من وضوح الكيانات والعلاقات التي تصل بينها.
تحقّق من هذه الأمور الثلاثة قبل الإطلاق
مجرد نشر الكود لا يعني أن التنفيذ صحيح. ابدأ بلصق @graph كاملاً في Rich Results Test أو Schema Markup Validator، وتأكد من خلو الصياغة من رسائل الخطأ الحمراء. بعد ذلك نفّذ خطوة يتجاوزها كثيرون: اجمع كل قيمة @id مشاراً إليها وقارنها واحدة تلو الأخرى للتأكد من أنها معرّفة فعلاً داخل الرسم البياني نفسه، ولا تُشر إلى معرّفات غير موجودة. وأخيراً، افتح الصفحة في المتصفح وافحص HTML بعد التصيير للتأكد من أن script ظهر بالفعل؛ فكثير من أنظمة SSR أو CMS قد تُسقطه بصمت في هذه المرحلة. يُعد ربط الكيانات من الجوانب ذات العائد المرتفع في GEO التقني: لا يتطلب ساعات طويلة من العمل، لكنه يؤثر مباشرةً في استعداد الذكاء الاصطناعي للتعامل معك كمصدر موثوق. وإذا لم تكن متأكداً من أن Organization وWebSite وWebPage مترابطة فعلاً، أو تخشى وجود خلل في علاقة publisher، يمكنك حجز جلسة تشخيص GEO مدتها 30 دقيقة. سنلتقط HTML بعد التصيير ونحدّد الروابط الناقصة واحداً تلو الآخر.
