إذا أردت الاحتفاظ بخلاصة واحدة فقط، فهي: استخدم JSON-LD عندما تريد من محركات الذكاء الاصطناعي قراءة بياناتك بوضوح والاستشهاد بها. لن ترفض Google ترميز schema.org نفسه إذا كُتب بصيغة Microdata أو RDFa، لكن برنامج زحف الذكاء الاصطناعي سيضطر حينها إلى إعادة تجميع السمات الموزعة في HTML لتكوين كيان واحد. وكل خطوة إضافية تفتح مجالاً لإغفال المعلومة أو تفسيرها على نحو خاطئ.
التنسيقات الثلاثة تصف مجموعة المفردات نفسها
لنبدأ بتوضيح نقطة يكثر الالتباس حولها: JSON-LD وMicrodata وRDFa ليست مواد متنافسة، بل صيغ مختلفة لكتابة مفردات schema.org داخل صفحات الويب. الكيانات التي تريد ترميزها لا تتغير؛ فـ Organization وProduct وArticle وFAQPage وHowTo تظل المفردات نفسها. الاختلاف الوحيد هو موضع السمات وطريقة تمثيلها. تدعم schema.org الصيغ الثلاث رسمياً، كما تستطيع Google تحليلها جميعاً. لذلك لا تسأل هذه المقارنة: أيها صالح للاستخدام؟ بل: أيها يجعل قراءة البيانات أسهل على الآلة؟
الاختلاف الجوهري: كيف ترتبط البيانات المنظَّمة بـ HTML؟
يكمن الفارق الأهم بين الصيغ الثلاث في مدى التصاق البيانات المنظَّمة بـ HTML. تضع Microdata الترميز مباشرة داخل عناصر HTML، مستخدمةً السمات itemscope وitemtype وitemprop لربطه تدريجياً بعناصر مثل div وspan وh1. تتبع RDFa الفكرة نفسها، لكنها تستخدم مجموعة من السمات مثل vocab وtypeof وproperty لإضافة الدلالات إلى الوسوم القائمة، فتقدم تعبيراً دلالياً أشمل مقابل بنية أكثر إسهاباً. أما JSON-LD فتسلك نهجاً معاكساً تماماً: تمثّل الكيان كاملاً في JSON مستقل داخل وسم script من النوع application/ld+json، بعيداً عن HTML الظاهر على الشاشة.
- JSON-LD: كائن JSON مكتمل بذاته ومجمّع داخل وسم script. انفصاله عن تخطيط الصفحة يجعله الأسهل في الصيانة والبرمجة، وهو أيضاً الخيار الأول الواضح لدى Google.
- Microdata: تستخدم سمات مثل itemscope وitemprop لتضمين البيانات في HTML المرئي. ولأن الترميز مرتبط بعناصر المحتوى، قد يتضرر بسهولة عند تعديل تخطيط الصفحة.
- RDFa: تُضمَّن باستخدام سمات vocab وtypeof وproperty. وهي الأقوى في التعبير الدلالي والأقرب إلى تصور W3C للبيانات المترابطة، لكن بنيتها هي الأثقل والأكثر عرضة للأخطاء.
لماذا تفضّل برامج زحف الذكاء الاصطناعي JSON-LD؟
السبب مباشر: يظهر الكيان في JSON-LD ككائن JSON متكامل، تتجاور فيه الحقول والقيم والعلاقات المتداخلة داخل كتلة واحدة. وبمجرد أن يقرأه المحلّل، يتحول إلى شجرة كائنات نظيفة من دون الحاجة إلى العودة ومسح بنية DOM كاملة. أما Microdata وRDFa فتجبران الآلة أولاً على المرور عبر HTML بأكمله، وجمع السمات الموزعة بين الوسوم، ثم إعادة تركيبها في كيان واحد وفق علاقات التداخل. وكلما ازدادت الصفحة تعقيداً وعمقاً في طبقات التخطيط، ارتفع احتمال الخطأ أثناء إعادة التجميع.
هناك عاملان عمليان يوسّعان هذا الفارق. أولهما عرض المحتوى بواسطة JavaScript؛ فكثير من برامج زحف الذكاء الاصطناعي تنفّذ JS بتحفّظ أكبر من Googlebot. وإذا كان إطار الواجهة الأمامية يضيف Microdata ديناميكياً إلى DOM، فقد لا تكون قد ظهرت عند لحظة الزحف. أما النهج الشائع مع JSON-LD فهو إخراج السلسلة كاملةً من جهة الخادم، لتكون جاهزة فور جلب الصفحة. والعامل الثاني هو تكلفة الصيانة: تحتفظ JSON-LD بالبيانات في موضع واحد. فإذا أردت إضافة FAQPage جديدة أو تعديل سعر منتج، يكفي تغيير جزء من JSON من دون المساس بالتخطيط. أما الترميز المضمّن داخل العناصر، فيلزمك بعد كل تعديل التأكد مجدداً من أن السمات لم تُنقل أو تُحذف.
هل ما زالت Microdata وRDFa مستخدمتين؟
لا يعني ذلك أن Microdata وRDFa خاطئتان. فإذا كنت تستخدم نظام CMS قديماً أو قالباً لمتجر إلكتروني، فمن المرجح أن يكون الترميز المنظَّم المدمج فيه بصيغة Microdata، ولا حاجة إلى تغييره ما دام يعمل بصورة صحيحة. وما زالت RDFa مفيدة حين يلزم التعبير عن بيانات مترابطة ومعقدة عبر مفردات متعددة، كما في البيانات الحكومية المفتوحة أو النشر الأكاديمي. لكن عند حصر الهدف في الاستشهاد بالمحتوى داخل محركات الذكاء الاصطناعي، تكاد مزايا الصيغتين لا تضيف قيمة، بينما تصبح أوجه القصور فيهما أكثر وضوحاً.
قبل الانتقال إلى JSON-LD، تجنّب هذه الأخطاء
- عدم تطابق الترميز مع المحتوى الظاهر: يجب أن تتطابق التقييمات والأسعار وأسماء المؤلفين في JSON-LD مع ما يراه المستخدم فعلياً، وإلا فقد يُصنَّف الترميز على أنه محتوى مزعج.
- وجود script مع غياب الحقول المطلوبة: إذا افتقد Product مثلاً إلى name أو offers، أو لم تتضمن أسئلة FAQPage إجابات مقابلة، فقد تتجاوز الآلة الكيان بالكامل.
- نسيان استخدام @id لربط الكيانات: عندما ترتبط Organization وWebSite وArticle بعضها ببعض، يتيح إنشاء المراجع باستخدام @id للذكاء الاصطناعي بناء خريطة أكثر اكتمالاً لمعرفة العلامة التجارية.
- إطلاق الترميز من دون التحقق منه: تمريره عبر أداة Rich Results Test من Google أو أداة التحقق التابعة لـ schema.org أسرع بكثير من اكتشاف الأخطاء لاحقاً عبر Search Console.
ثمة نقطة مهمة يسهل إغفالها: الغرض من البيانات المنظَّمة ليس خداع الآلة، بل مساعدتها على تأكيد ما قرأته من المحتوى الظاهر. لذلك يتمثل النهج الأكثر موثوقية في جعل JSON-LD مرآةً للمحتوى المرئي؛ فلا يُدرج في الترميز إلا ما يظهر على الشاشة، ويكون لكل معلومة معلنة فيه مقابل يمكن العثور عليه في الصفحة. هذا الاتساق هو الأساس الذي تعتمد عليه محركات الذكاء الاصطناعي لتقدير موثوقية الصفحة وجدارتها بالاستشهاد.
لن تجعل البيانات المنظَّمة صفحةً فارغة المحتوى جديرةً بالاستشهاد. دورها الحقيقي هو منع تجاوز صفحة تستحق الاستشهاد لمجرد أن الآلة لم تستطع فهمها.— Tenten GEO Technical Audit Team
كيف تراجع موقعك؟
عند مراجعة موقعك، ابدأ بثلاثة أسئلة: ما التنسيق المستخدم في الصفحة الرئيسية؟ هل جرى ترميز الكيان نفسه أكثر من مرة؟ وهل تتطابق حقول JSON-LD مع المحتوى الظاهر؟ غالباً ما تتراكم البيانات المنظَّمة في مواقع B2B SaaS عبر مراحل مختلفة وجهات تنفيذ خارجية، لذلك يشيع اختلاط التنسيقات ونقص الحقول. ومن منظور محركات الذكاء الاصطناعي، تكفي هذه الثغرات لتجاوز موقعك. وإذا أردت معرفة كيف يبدو موقعك لبرامج زحف الذكاء الاصطناعي وما الكيانات التي لا تلتقطها، يمكنك حجز جلسة تشخيص GEO مدتها 30 دقيقة، نراجع خلالها صفحتك الفعلية معك مباشرةً.
