اجتياز Schema لأداة Google للتحقق لا يعني أن محرك AI سيتمكن من التقاط بياناتك المنظَّمة؛ فلكل منهما مسار تحليل مختلف. لا يفحص Rich Results Test سوى أهلية الصفحة للأنواع المحدودة من النتائج المنسّقة التي تدعمها Google، بينما يقتصر Schema.org Validator على التحقق من توافق الصياغة مع مواصفات المفردات. ولا تخبرك أي من الأداتين بما تقرؤه فعليًا زواحف ChatGPT أو Perplexity أو Google AI Overviews في صفحتك. ثمة صفحات تحصل على نتائج خضراء بالكامل في الاختبارات، لكنها تظل غائبة تمامًا عن إجابات AI. هنا تكمن الفجوة.
لماذا لا يعني «اجتياز التحقق» أن AI يستطيع القراءة؟
مهمة أداة التحقق هي «فحص الامتثال»، لا «فحص قابلية القراءة». يقارن Schema.org Validator ملف JSON-LD بمفردات schema.org للتأكد من صحة كتابة الأنواع والخصائص وسلامة البنية المتداخلة؛ أما Rich Results Test فيحاكي عرض Googlebot للصفحة لتحديد ما إذا كانت مؤهلة لتشغيل نوع معيّن من النتائج المنسّقة. بعد الاختبارين، لا تعرف سوى أن «الصياغة صحيحة» و«ما إذا كانت Google مستعدة لمنحك نتيجة منسّقة». أما زواحف AI، فمعظمها يجلب مباشرةً HTML الأصلي الذي يعيده الخادم، ولا يشغّل JavaScript، ولا يعنيه استيفاؤك شروط النتائج المنسّقة. العامل الحاسم في قدرة AI على القراءة هو ظهور JSON-LD داخل HTML الأصلي وترابط الكيانات فيما بينها.
أداتان أساسيتان، ولكل منهما مواطن قصور مختلفة
قبل تحديد ما يفوت كل أداة، يجب أولًا فهم الدور الذي صُممت لأدائه.
- Rich Results Test (search.google.com/test/rich-results): يستخدم Googlebot لعرض الصفحة فعليًا وتشغيل JS، ثم يسرد أنواع النتائج المنسّقة المكتشفة والأخطاء والتحذيرات بندًا بندًا. أما موطن القصور، فهو اقتصاره على نحو ثلاثين نوعًا تدعمها Google؛ فإذا استخدمت أنواعًا مثل Organization وPerson لا تؤدي إلى نتائج منسّقة، فقد يعرض «Item not detected»، لكن ذلك لا يعني أن Schema غير صالحة.
- Schema.org Validator (validator.schema.org): يعرض شجرة الكيانات الكاملة لجميع الأنواع، سواء كانت Google تدعمها أم لا، لذا فهو مثالي لفحص الصياغة والمفردات. لكنه لا يشغّل JS نيابةً عنك افتراضيًا؛ وعند لصق الشفرة المصدرية أو إدخال URL، ستحصل غالبًا على نسخة غير معروضة. كما أنه لا يحدد أهلية النتائج المنسّقة، وقد يتساهل أكثر من اللازم مع بعض الأخطاء الدلالية.
الخلاصة واضحة: استخدم الأداتين معًا، وحدد بدقة ما الذي تفحصه في كل مرحلة. استخدم Schema.org Validator لمراجعة الصياغة وبنية الكيانات، وRich Results Test للتحقق من أهلية النتائج المنسّقة لدى Google ومخرجات العرض. لكن أيًا منهما لن يجيب عن سؤال: «هل يستطيع زاحف لا يشغّل JS رؤيتها؟». وللإجابة، انتقل إلى الخطوة التالية وافحص الشفرة المصدرية.
منهجية قابلة للتكرار للتحقق من Schema
حوّل التحقق إلى تسلسل ثابت، وطبّق قائمة الفحص نفسها على كل صفحة وكل مراجعة. بهذه الطريقة، لن تعتمد في كل مرة على الانطباع وتفوتك ثغرات مختلفة.
- الصق HTML «المعروض» في Schema.org Validator، وتأكد من صحة الصياغة والمفردات، ثم وسّع شجرة الكيانات كاملةً وراجع الأنواع والخصائص المطلوبة واحدًا تلو الآخر.
- أدخل URL الرسمي في Rich Results Test، وتأكد من أن Google تلتقط النسخة المعروضة، وأن نوع النتيجة المنسّقة المطلوب معروف ولا توجد أخطاء حمراء.
- استخدم curl أو view-source لجلب HTML الأصلي «من دون تشغيل JS»، وابحث عن application/ld+json، ثم تأكد من وجود JSON-LD فعليًا ضمن المحتوى الذي يعيده الخادم. تحاكي هذه الخطوة سلوك معظم زواحف AI.
- راجع الإحالات المتبادلة بين @id و@type في Organization وWebSite وArticle وPerson. تأكد من استخدام @id متسق لربط الصورة الكاملة، حتى يستطيع المحرك تحديد المؤسسة التي ينتمي إليها المؤلف والموقع الذي تنتمي إليه المقالة.
- قارن قيم Schema بالمحتوى الظاهر في الصفحة بندًا بندًا. يجب أن تتطابق الأسعار والعناوين والتقييمات والتواريخ؛ فعند التعارض قد تتجاهلها Google مباشرةً، كما تتراجع ثقة AI بها.
- احفظ لقطة مرجعية، ثم أعد تشغيل القائمة كاملةً بعد كل تعديل، وراجع الفروق بوصفها حالات تراجع محتملة.

أخطاء تجعل Schema غير مقروءة فعليًا لمحركات AI
حتى Schema التي تجتاز الفحص النحوي قد تحتوي على فئة كاملة من الأخطاء التي يمكن تلخيصها بعبارة: «الأداة تقول إنها سليمة، لكن AI لا يستطيع قراءتها». وهذه أكثر الحالات التي نرصدها عند تدقيق مواقع عملائنا:
- يحقن إطار الواجهة الأمامية أو مدير الوسوم JSON-LD داخل المتصفح. فلا يظهر منه سطر واحد في HTML الأصلي الذي يعيده الخادم، وبالتالي لا تستطيع الزواحف التي لا تشغّل JS رؤيته إطلاقًا.
- يكون @id مفقودًا أو غير متسق، فلا تترابط الكيانات ولا يستطيع المحرك جمع المؤلفين والمؤسسات والمقالات ضمن عقدة واحدة في الرسم البياني المعرفي.
- يكون النوع المختار صحيحًا، لكن القيمة موضوعة في الحقل الخطأ: تُدرج العملة في price، أو يوضع الوصف كاملًا داخل name، أو يغيب priceCurrency عن offers.
- تكون الصياغة قانونية، لكن الدلالة ناقصة: لا يتضمن Product قيمة offers، أو تفتقر Article إلى author أو publisher، أو تكون إجابة FAQPage سلسلة نصية فارغة.
- توجد كتل JSON-LD متعارضة في الصفحة نفسها، مثل Organization المضمّنة في قالب الصفحة الرئيسية وOrganization أخرى مضمّنة في الصفحة ذاتها، فلا يستطيع المحرك تحديد المرجع الصحيح.
- لا يتبع التاريخ تنسيق ISO 8601، أو تستخدم الصورة مسارًا نسبيًا بدل URL مطلق. قد تمر هذه الأخطاء عبر أداة تحقق متساهلة، لكنها معرّضة للاستبعاد بسهولة أثناء الاستخراج.
لا تكتفِ بنتائج الأدوات؛ افحص الفجوة بين «DOM المعروض» و«الشفرة المصدرية»
جوهر التحقق المتين هو النظر إلى نسختي الصفحة في الوقت نفسه. افتح لوحة Elements في DevTools لترى DOM الذي عرضه المتصفح، وهي صورة قريبة مما سيراه Googlebot. ثم استخدم view-source أو curl لرؤية HTML الأصلي الذي أعاده الخادم في البداية، وهو ما تراه معظم زواحف AI. إذا كانت بياناتك المنظَّمة موجودة في النسخة الأولى وحدها وغائبة عن الثانية، فهذه الفجوة هي التي تمنع AI من قراءتك. تساعدك أداة التحقق على رؤية النسخة الأولى، لكن عليك فحص الثانية بنفسك.
التحقق من Schema ليس إجراءً يُنفّذ مرة واحدة عند الإطلاق ثم يُطوى ملفه، بل مرحلة يجب تكرارها بعد كل تعديل؛ إذ قد تؤدي ترقية CMS أو إعادة ضبط القالب إلى تفكك شجرة الكيانات بأكملها في صمت.— Tenten GEO Technical Audit Notes
اجعل التحقق بوابة ثابتة قبل الإطلاق
النهج الأكثر عملية هو دمج هذه القائمة في مسار الإطلاق، بدل الاعتماد على الذاكرة لإجراء فحص عابر. يمكنك إضافة نص برمجي إلى CI لجلب HTML الأصلي من URL الرسمي، واستخراج JSON-LD، ومقارنة الخصائص المطلوبة ومراجع @id، ومنع النشر عند فقدان أي منها. أما الفرق التي لا تستخدم CI، فعليها على الأقل إدراج الخطوات الست في قائمة فحص ما قبل الإطلاق، ووضع علامة أمام كل بند بعد كل تعديل. قيمة البيانات المنظَّمة في استقرار قدرة الآلات على استخراجها، وهذا الاستقرار تصنعه العملية لا مصادفة نجاح فحص يدوي. وإذا أردت أن تعرف كيف تبدو صفحتك في نظر زاحف لا يشغّل JS، وأي Schema يعجز AI تمامًا عن قراءتها، يمكنك الانتقال إلى /contact لحجز جلسة تشخيص GEO مدتها 30 دقيقة، وسنطبّق المنهجية على صفحتك الفعلية.



