ماذا تفعل إذا لم تتمكن أداة Google Schema Testing Tool من اكتشاف البيانات؟

تمت إضافة كود JSON-LD إلى الصفحة، ولكن عند فتح google schema testing tool تظهر رسالة «لم يتم اكتشاف بيانات منظَّمة». لا تتسرع في إعادة كتابة مجموعة العلامات بالكامل. لا تعني هذه النتيجة عادةً أن Schema غير صالح بالضرورة؛ والأكثر شيوعًا هو أن محتوى الصفحة الذي تحصل عليه أداة الاختبار لا يتطابق مع ما يظهر في المتصفح، أو أن هناك مشكلة في موضع العلامات أو صياغة الكود أو حالة الوصول إلى الصفحة.

في التطبيق العملي، أكثر السيناريوهات التي تسبب أحكامًا خاطئة هي: يرى المطورون أن الكود يعمل بشكل طبيعي في بيئة الاختبار، لكن الأداة لا تتمكن من زحفه بعد النشر؛ أو أن خلفية الموقع حفظت بالفعل حقول المنتج وفتات التنقل والمقال وغيرها، لكن صفحة الواجهة الأمامية لا تُخرج البيانات المنظَّمة فعليًا. عند المعالجة، يجب أولًا التأكد مما إذا كانت «علامات البيانات موجودة في HTML الذي التقطته الأداة»، ثم التحقق من قابلية تحليل العلامات، وأخيرًا تحديد ما إذا كانت الأنواع والخصائص تستوفي المتطلبات.

ميّز أولًا: هل لم يتم الاكتشاف، أم تم الاكتشاف لكنه لا يفي بمتطلبات النتائج المنسقة؟

«لم يتم اكتشاف بيانات» و«تم اكتشاف بيانات مع وجود تحذيرات» هما نوعان مختلفان من المشكلات. تشير الأولى إلى أن الأداة لم تحلل من الصفحة الحالية أي Microdata أو RDFa أو JSON-LD يمكن التعرف عليه؛ بينما تشير الثانية إلى أن العلامات موجودة، لكنها تفتقد بعض الحقول الموصى بها، وقد لا يؤثر ذلك في التعرف الأساسي.

تم إيقاف صيانة Structured Data Testing Tool الأصلي من Google. عند استكشاف المشكلات الآن، يمكن استخدام أداة اختبار النتائج المنسقة للتحقق مما إذا كانت الصفحة تستوفي شروط العرض للنتائج المنسقة التي يدعمها Google، أو استخدام Schema Markup Validator لفحص صياغة وبنية Schema.org. لا تحكم مباشرةً بأن جميع البيانات المنسَّقة في الصفحة أصبحت غير صالحة لمجرد أن أداة واحدة لا تعرض نتائج؛ إذ تختلف الأدوات في تركيزها على الأنواع المدعومة وعرض JavaScript وقواعد التحقق.

الخطوة الأولى: تأكد من أنك أرسلت الصفحة النهائية القابلة للوصول

افتح عنوان URL المراد اختباره في نافذة التصفح المتخفي أولًا، وتأكد من إمكانية الوصول إليه مباشرةً، وأنه يعيد الصفحة بشكل طبيعي، ولا يتطلب تسجيل الدخول أو رمز تحقق أو قيودًا جغرافية أو ملفات Cookie خاصة. لا تستطيع أداة الاختبار قراءة المحتوى المحظور أو الذي يعاني من إعادة توجيه غير طبيعية أو وصول مقيّد.

• تحقق مما إذا كان URL ينتقل تلقائيًا من http إلى https، أو من غير www إلى www؛ ويجب اختبار عنوان الوصول النهائي.
• تأكد من أن الصفحة ليست مسودة أو رابط معاينة أو صفحة تحرير في الخلفية أو عنوان اختبار مرئي داخل الشبكة فقط.
• تحقق مما إذا كانت هناك عمليات إعادة توجيه متعددة. عندما تكون سلسلة التحويل طويلة جدًا أو تنتقل إلى صفحة اختيار اللغة أو صفحة خطأ، فإن ما تكتشفه الأداة ليس صفحة المحتوى المستهدفة.
• تحقق مما إذا كان الخادم يعيد محتوى مختلفًا لبرامج الزحف، مثل الحماية الأمنية أو تحديد معدل الطلبات أو 403 أو 503 أو صفحة فارغة.

تعيد بعض المواقع إصدارات مختلفة استنادًا إلى لغة الزائر أو IP أو User-Agent. لا يعني الوصول الطبيعي عبر المتصفح أن HTML الذي تحصل عليه أداة الزحف طبيعي. في هذه الحالة، ينبغي التأكد من سجلات الخادم أو قواعد حماية CDN أو نتائج زحف الصفحة مما إذا كان الطلب قد تم حظره.

الخطوة الثانية: ابحث عن البيانات المنسقة في شفرة مصدر الصفحة

لا تكتفِ بالبحث في «فحص العنصر» بالمتصفح. ما تعرضه أدوات المطورين هو DOM بعد تشغيل JavaScript في الصفحة، وقد لا تنفذ أداة الاختبار البرامج النصية بالطريقة نفسها. استخدم «عرض مصدر الصفحة»، وابحث عن application/ld+json أو schema.org أو itemtype أو itemscope.

بالنسبة إلى JSON-LD، تتمثل الصياغة الشائعة في وضع المحتوى داخل وسم <script type="application/ld+json">. إذا لم يكن هذا الجزء موجودًا في الشفرة المصدرية وظهر فقط في DOM الديناميكي، فغالبًا ما تكون المشكلة ناتجة عن الإدراج غير المتزامن في الواجهة الأمامية. لا سيما في تطبيقات الصفحة الواحدة وصفحات التصفية وصفحات تفاصيل المنتجات المنبثقة، قد لا يتم إنشاء البيانات المنسقة إلا بعد أن تعيد الواجهة بياناتها؛ واختلاف توقيت الزحف قد يؤدي إلى عدم تمكن google schema testing tool من اكتشافها.

المعالجة الأكثر موثوقية هي إخراج JSON-LD للصفحات الأساسية مع HTML الأولي، أو اعتماد حل موثوق للعرض من جانب الخادم أو العرض المسبق. يجب أن تكون المعلومات الرئيسية في تفاصيل المنتج وتفاصيل المقال وصفحات الفئات قابلة للقراءة بالأولوية في الاستجابة الأولية، وألا تعتمد بالكامل على التحميل بعد تفاعل المستخدم.

الخطوة الثالثة: افحص صياغة JSON-LD، وليس محتوى الحقول فقط

عند نسخ الكود، يسهل إدخال علامات اقتباس بعرض كامل أو فاصلة لاحقة أو علامات اقتباس مزدوجة غير مهروبة أو أقواس غير مكتملة. ما إن يفشل تحليل JSON، تتجاهل الأداة عادةً كتلة البيانات بأكملها مباشرةً. كون الكود يبدو كأنه Schema لا يعني أنه JSON صالح.

تحقق أيضًا مما إذا كان @context هو https://schema.org، وما إذا كانت كتابة @type صحيحة. يجب أن تتوافق قيم الخصائص مع المحتوى المرئي في الصفحة. على سبيل المثال، لا يجوز الاحتفاظ على المدى الطويل في العلامات بمعلومات منتهية الصلاحية أو غير موجودة على الصفحة، مثل سعر المنتج والمخزون والتقييم وتاريخ النشر. قابلية الأداة للتحليل لا تعني أن محرك البحث سيستخدم هذه المعلومات في العرض.

المشكلات الناتجة عن القوالب والإضافات والتخزين المؤقت أكثر خفاءً

عند استخدام نظام إنشاء مواقع أو CMS، قد لا يتم الاكتشاف حتى بعد تحديد «تمكين البيانات المنسقة» في الخلفية؛ وغالبًا لا يكون السبب اختيار نوع Schema خاطئًا، بل عدم استدعاء القالب للمكوّن المقابل. فعلى سبيل المثال، قد يُخرج قالب المقال العنوان والنص، لكنه يهمل وحدة Schema الخاصة بالمقال؛ أو تُملأ بيانات المنتج في نظام المتجر، لكن صفحة التفاصيل الحالية تستخدم قالبًا مخصصًا لا تُمرر إليه الحقول ذات الصلة.

هناك مشكلة شائعة أخرى وهي التخزين المؤقت. بعد تحديث الصفحة، تكون إعدادات الخلفية قد تغيرت، لكن CDN وذاكرة التخزين المؤقت للصفحة وذاكرة التخزين المؤقت للكائنات لا تزال تعيد HTML القديم. يجب أن يكون ترتيب الاستكشاف: حفظ الإعدادات ونشر الصفحة، ومسح ذاكرة التخزين المؤقت للموقع وCDN، وعرض شفرة المصدر باستخدام URL العام النهائي، ثم إعادة إرسال الاختبار. رؤية الكود الجديد فقط في صفحة المعاينة الخلفية لا تثبت أن الصفحة المنشورة قد تم تحديثها.

لا تُخرج بيانات متناقضة مكررة في الصفحة نفسها

تفعّل بعض المواقع في الوقت نفسه علامات SEO المدمجة في القالب، وعلامات إضافات المتجر، وإضافات SEO من جهات خارجية، فتظهر في صفحة منتج واحدة نسختان من Product ونسختان من Offer، بل وقد يختلف السعر أو المخزون بينهما. قد لا تعرض هذه الصفحات بالضرورة رسالة «لم يتم الاكتشاف»، لكنها تجعل التشخيص اللاحق مربكًا، وقد تقلل أيضًا من موثوقية العلامات.

يوصى بالاحتفاظ بالكيان الرئيسي وفقًا لدور الصفحة: تكون صفحة تفاصيل المقال Article أو BlogPosting أساسًا، وتكون صفحة تفاصيل المنتج Product أساسًا، ويمكن استكمال منطقة التنقل بـ BreadcrumbList. احذف أو عطّل المصادر المكررة أولًا، ثم أعد الاختبار. أما الكيانات الشاملة للموقع مثل Organization وWebSite، فيجب أيضًا الحفاظ على اتساق معلومات الاسم ورابط الموقع وLogo وغيرها، وألا تنشئ إضافات مختلفة إصدارات مختلفة كلٌّ على حدة.

ترتيب التحقق بعد الإصلاح

1. افتح شفرة المصدر للصفحة العامة، وتأكد من أن البيانات المنسقة قد تم إخراجها فعليًا.
2. تحقق من مقطع كود JSON-LD بشكل منفصل لاستبعاد أخطاء الفواصل وعلامات الاقتباس والأقواس والترميز.
3. استخدم أداة التحقق من Schema للتأكد من قابلية تحليل نوع الكيان وتسلسل الخصائص وعلاقات الإحالة.
4. استخدم بعد ذلك أداة اختبار النتائج المنسقة للتحقق من أنواع العرض المحددة التي يدعمها Google والحقول المفقودة.
5. أعد اختبار URL بعد مسح ذاكرة التخزين المؤقت؛ وإذا كانت الصفحة مفهرسة بالفعل، يمكنك طلب إعادة الزحف في أدوات مشرفي المواقع.

وأخيرًا، يجب الحفاظ على حدّ واضح للحكم: اجتياز البيانات المنسقة للتحقق يعني فقط أن الآلة قادرة على فهم جزء من معلومات الصفحة، ولا يضمن بالضرورة الحصول على عرض النتائج المنسقة؛ وبالمقابل، فإن عدم عرض نوع معين من Schema في أداة النتائج المنسقة لا يعني حتمًا أن العلامات بلا قيمة. بالنسبة إلى مشكلة «تعذر اكتشاف البيانات»، فإن التركيز أولًا على إمكانية الوصول إلى الصفحة، وإخراج HTML الأولي، وصياغة JSON، وإصدار التخزين المؤقت، يكون عادةً أكثر فعالية من إضافة الحقول مرارًا وتكرارًا.