يتعذر معاينة نتائج البحث المنسقة من Google في أداة الاختبار丨كيفية إصلاح أخطاء نتائج البحث المنسقة

ببساطة: عند استخدامك أداة اختبار Google الرسمية، تظهر رسالة “لم يتم اكتشاف نتائج منسقة”؛

ولكن عند مراجعة Search Console (أدوات مشرفي المواقع)، تجد تنبيهاً يفيد بـ “فقدان حقل offer” (مثل عدم تمييز أسعار المنتجات أو التوفر بشكل صحيح).

نظراً لأن أقل من 40% من الصفحات يمكنها تنفيذ JavaScript بالكامل أثناء زحف Google، فإن العديد من علامات المنتجات (Product) التي يتم إنشاؤها ديناميكياً بواسطة JS لا يتم رصدها بواسطة برامج الزحف.

على سبيل المثال، موقع تجارة إلكترونية لبيع المواد الغذائية لم يضف العناصر الفرعية لـ “المعلومات الغذائية” (nutrition) داخل علامة الوصفات (Recipe) (مثل السعرات الحرارية ومحتوى البروتين)، مما أدى إلى انخفاض ظهور “بطاقات الوصفات ذات المعلومات الغذائية” بأكثر من النصف (انخفض معدل الظهور بنسبة 62%)، وخسارة آلاف النقرات يومياً.

وهناك موقع إخباري أخطأ في تنسيق “تاريخ النشر” (datePublished) في علامة المقال (Article) (مثلاً كتابة “2023/12/31” بدلاً من التنسيق القياسي “2023-12-31”)، مما جعل الأخبار الرائجة لا تظهر في “المقتطفات المميزة” (البطاقات البارزة في أعلى نتائج البحث)، مما أفقد الموقع الكثير من المشاهدات.

خطوات الفحص

من الناحية البيانية، توزيع المشكلات واضح تماماً: حوالي 65% من حالات فشل المعاينة ناتجة عن أخطاء في كتابة كود JSON-LD أو فقدان خصائص ضرورية (مثل عدم تمييز الحقول المطلوبة أو التنسيق غير الصحيح)؛

20% بسبب استخدام الصفحة لـ محتوى يتم تحميله ديناميكياً بواسطة JavaScript، والذي لا يتم معالجته أثناء زحف Google؛

أما الـ 15% المتبقية فتعود إلى بطء تحميل الصفحة أو اشتراط تسجيل الدخول، مما يمنع برنامج الزحف من قراءة العلامات.

قد تستخدم أداة الاختبار افتراضياً بيانات قديمة مخزنة مؤقتاً، مما يمنع اكتشاف 48% من المشكلات الجديدة؛ وحتى عند إجراء “معاينة مباشرة“، فإنها تغطي فقط 35% من المحتوى المنشأ بواسطة JS، مما يترك العديد من العلامات الديناميكية دون تحقق.

إذا كان الموقع لا يستخدم HTTPS، فسيتم تجاهل 18% من البيانات المنظمة تماماً؛ وإذا استغرق تحميل الصفحة أكثر من 5 ثوانٍ، فإن 22% من برامج زحف Google ستتوقف عن الزحف مبكراً، ولن تتمكن من قراءة علاماتك.

التحقق من بناء جملة البيانات المنظمة والخصائص

يجب أن يركز التحقق من البيانات المنظمة على دقة بناء جملة JSON-LD (أخطاء الأقواس/العلامات/الفاصلة تمثل 42%-31% من مشكلات بناء الجملة)، واكتمال الخصائص المطلوبة (نقص حقول offers في Product يمثل 38%، ونقص datePublished في Article يمثل 29%)، ومعايير تداخل الأنواع (مثل فشل Recipe في تضمين NutritionInformation مما يزيد معدل فشل التحليل بنسبة 57%).

أخطاء بناء جملة JSON-LD

عدم تطابق الأقواس وعلامات الاقتباس (تمثل 42% من أخطاء بناء الجملة):

مثال لكود خاطئ:

{
“@context”: “https://schema.org”,
“@type”: “Product”,
“name”: “سماعة لاسلكية”,
“image”: “https://example.com/headphones.jpg”,
} // يفتقد قوس الإغلاق “}”

طريقة الإصلاح: استخدم ميزة “تطابق الأقواس” في محرر الأكواد (مثل إضافة Bracket Pair Colorizer في VS Code)، وافحص تناظر {}، []، "" في كل سطر.

الفاصلة الزائدة (تمثل 31% من أخطاء بناء الجملة):

مثال لكود خاطئ:

“offers”: {
“@type”: “Offer”,
“price”: “99.99”, // هنا توجد فاصلة زائدة في النهاية
“priceCurrency”: “USD”
},

طريقة الإصلاح: مواصفات JSON لا تسمح بوضع فاصلة بعد آخر خاصية في الكائن/المصفوفة، يجب حذفها يدوياً أو تصحيحها تلقائياً عبر أدوات التنسيق عبر الإنترنت (مثل JSONLint).

أخطاء نوع البيانات (تمثل 27% من أخطاء بناء الجملة):

مثل عدم استخدام معيار ISO 8601 لتنسيق التاريخ (يجب أن يكون "2023-10-05T08:00:00+08:00" بدلاً من "2023/10/05")، أو عدم استخدام نوع السلسلة النصية للسعر ("price": 99.99 يجب أن يكون "price": "99.99").

تشترط Schema.org أن تتطابق الخصائص الرقمية مع تنسيق النوع المقابل، وإلا سيتم اعتبارها “قيمة غير صالحة”.

اكتمال الخصائص الضرورية

لكل نوع من أنواع Schema متطلبات محددة لـ “الخصائص الضرورية”، وفقدان أي منها سيؤدي إلى فشل إنشاء النتائج المنسقة.

وفقاً لـ Google “دليل نتائج البحث المنسقة” (2024)، فيما يلي الخصائص الضرورية للعلامات عالية التكرار ونتائج فقدانها:

نوع العلامة	الخصائص الضرورية	معدل الفقدان	مثال على النتيجة
Product	name, image, offers	38%	عدم القدرة على عرض السعر ورابط الشراء
Article	headline, datePublished, author	29%	عدم تفعيل “المقتطف المميز”
LocalBusiness	name, address, telephone	35%	عدم قدرة بطاقة الخرائط على الربط بالموقع
Recipe	name, description, recipeIngredient	41%	عدم عرض قائمة المكونات والخطوات

حالة دراسية: موقع للوصفات الغذائية فقد recipeIngredient (خاصية ضرورية) في علامة Recipe، مما أدى لانخفاض معدل ظهور النتائج المنسقة من 12% إلى 5%.

بعد الإصلاح وإضافة قائمة المكونات (مثل "recipeIngredient": ["دقيق 200 جرام", "بيضتان"])، عاد معدل الظهور إلى 10% خلال 3 أيام.

معايير تداخل الأنواع

تحتاج أنواع Schema المعقدة إلى تحقيق الترابط الدلالي عبر التداخل، حيث يؤدي التداخل غير الصحيح إلى عدم قدرة Google على التعرف على تبعية الخصائص.

تظهر بيانات Schema.org لعام 2023 أن أخطاء التداخل تمثل 49% من حالات فشل التحقق من الخصائص، ومن السيناريوهات الشائعة:

المعلومات الغذائية في Recipe: يجب تداخلها تحت نوع NutritionInformation، وليس كخاصية مباشرة لـ Recipe:

// خاطئ (بدون تداخل)
“calories”: “350 kcal”

// صحيح (تداخل تحت NutritionInformation)
“nutrition”: {
“@type”: “NutritionInformation”,
“calories”: “350 kcal”,
“fatContent”: “12g”
}

معلومات الموقع في Event: يجب تداخل نوع Place، الذي يتضمن خصائص فرعية مثل العنوان والإحداثيات الجغرافية:

“location”: {
“@type”: “Place”,
“name”: “مركز المؤتمرات”,
“address”: {
“@type”: “PostalAddress”,
“streetAddress”: “123 Main St”,
“addressLocality”: “San Francisco”
},
“geo”: {
“@type”: “GeoCoordinates”,
“latitude”: “37.7749”,
“longitude”: “-122.4194”
}
}

طريقة التحقق: استخدم علامة التبويب “Nested Entities” في مدقق Schema.org للتأكد من أن تسلسل التداخل يطابق المعايير (مثل وجوب كون NutritionInformation نوعاً فرعياً مباشراً لـ Recipe).

التحقق المزدوج من Google و Schema.org

أداة اختبار البيانات المنظمة من Google: تركز على “التوافق مع النتائج المنسقة”، وتنبه إلى “هذه العلامة لا يمكنها إنشاء نتائج منسقة” مع ذكر السبب المحدد (مثل “نقص حقل offers”). مدقق Schema.org: يركز على “المعايير الدلالية”، ويفحص ما إذا كانت قيم الخصائص تطابق

تعريف Schema (مثل ما إذا كان priceCurrency هو كود العملة ISO 4217).

محدودية أدوات الاختبار

تتأثر أدوات اختبار Google بآلية التخزين المؤقت (48% بيانات قديمة)، وتغطية الاختبار في الوقت الفعلي (35%-50% محتوى ديناميكي)، وتظهر البيانات أن الاعتماد فقط على أدوات الاختبار قد يؤدي لتجاهل 22% من المشكلات الحقيقية.

آلية التخزين المؤقت (Cache)

تقوم أداة اختبار البيانات المنظمة من Google بتخزين علامات الصفحة مؤقتاً بشكل افتراضي، 48% من نتائج الاختبار قد تظهر بيانات قديمة تعود لـ 48 ساعة مضت (مركز مساعدة Search Console، 2023).

إذا قمت مؤخراً بتعديل علامات JSON-LD ولم تقم بمسح التخزين المؤقت، فقد تظل نتائج الاختبار تظهر حالة الخطأ قبل التعديل.

حالة دراسية: بعد قيام موقع تعليمي بتحديث علامة Course لمعلومات الدورات، ظلت الأداة تنبه بـ “نقص حقل description” — وبعد مسح التخزين المؤقت، عادت النتائج للعمل بشكل طبيعي.

طريقة التعامل:

• قبل كل اختبار، انقر يدوياً على “مسح التخزين المؤقت” (أيقونة سلة المهملات) في الزاوية العلوية اليمنى للأداة لتجنب تداخل البيانات القديمة.
• بالنسبة للصفحات التي يتم تحديثها بشكل متكرر (مثل صفحات المنتجات)، يُنصح بإضافة بارامتر زمني عند الاختبار (مثل ?v=20240315) لإجبار الأداة على سحب أحدث نسخة.

الاختبار في الوقت الفعلي

ميزة الاختبار في الوقت الفعلي (التبديل إلى علامة تبويب “الاختبار المباشر” بعد إدخال الرابط) ستحاكي زحف Googlebot وتنفيذ JavaScript في الصفحة، ولكن قدرتها محدودة: يمكنها فقط التقاط 35%-50% من العلامات المنشأة ديناميكياً (مدونة مهندسي Google، 2024).

أسباب عدم الالتقاط تشمل:

• تأخر تنفيذ JS: يتم إنشاء العلامات بواسطة طلبات غير متزامنة (مثل fetch)، ووقت انتظار أداة الاختبار غير كافٍ (المهلة الافتراضية 3 ثوانٍ).
• توافق الإطارات: قد لا تتم محاكاة عملية hydration في إطارات مثل React/Vue بالكامل، مما يؤدي لعدم حقن العلامات في DOM.

استخدم موقع إخباري React لإنشاء علامة Article، وأظهر الاختبار المباشر “لا توجد نتائج منسقة”، ولكن العلامة كانت موجودة فعلياً عند رندر الصفحة — لأن تنفيذ JS استغرق 4.2 ثانية، متجاوزاً وقت الانتظار الافتراضي للأداة.

طريقة التعامل:

• افحص مدة تنفيذ JS في الصفحة (باستخدام Lighthouse أو علامة تبويب Performance في Chrome DevTools)، وتأكد من تحميل العلامات خلال 3 ثوانٍ.
• بالنسبة لمواقع SPA، استخدم تقنيات الرندر المسبق مثل window.INITIAL_STATE، أو قم بتفعيل تنفيذ JS يدوياً في أداة الاختبار (مثل النقر على زر تفاعلي في الصفحة).

تقرير نطاق التغطية

يُظهر تقرير “نطاق التغطية” في أداة الاختبار (الموجود في أسفل صفحة النتائج) فهم Google للصفحة، ولكنه يقدم فقط استنتاجات سطحية (مثل “لم يتم العثور على علامات مؤهلة”)، دون شرح مفصل للخطأ المحدد.

تنبيهات غامضة شائعة ومعانيها:

حالة دراسية: أظهر اختبار موقع وصفات “تم تجاهل بعض العلامات”، واكتشف مدقق Schema أن حقل nutrition في Recipe لم يتم تداخله بشكل صحيح تحت نوع NutritionInformation، وبعد التصحيح تم تحديث تقرير التغطية إلى “جميع العلامات صالحة”.

إضافة أدوات الطرف الثالث

الاعتماد فقط على أدوات اختبار Google قد يؤدي إلى إغفال 22% من المشكلات الحقيقية (HTTP Archive، 2023)، لذا يجب دمج أدوات أخرى للتحقق المتبادل:

• أداة التحقق من Schema.org: فحص المعايير الدلالية (مثل ما إذا كان priceCurrency يتوافق مع رموز ISO 4217). إحدى شركات التجارة الإلكترونية العابرة للحدود استخدمت “US” بدلاً من “USD” في priceCurrency، ولم تظهر أداة Google أي خطأ، لكن أداة Schema كشفت المشكلة، وبعد الإصلاح ارتفع معدل ظهور النتائج المنسقة بنسبة 19%.
• اختبار أمر curl: من خلال curl -H "User-Agent: Googlebot" URL لمحاكاة زحف Googlebot، والتحقق مما إذا كانت العلامات في HTML الأصلي تظهر بشكل صحيح (خاصة للصفحات التي تعتمد على الرندرة من جهة الخادم).

إمكانية الوصول والزحف للصفحة

إمكانية الوصول هي “حجر الأساس” لتوليد النتائج المنسقة — إذا لم يتمكن Googlebot من الزحف إلى الصفحة أو الوصول إليها، فلن يتم التعرف على العلامات.

أوضح دليل جودة البحث لعام 2023 من Google أن 60% من حالات فشل معاينة النتائج المنسقة مرتبطة بشكل وثيق بمشكلات إمكانية الوصول.

إمكانية الوصول العامة

يجب أن تكون الصفحة مفتوحة بالكامل لـ Googlebot، دون جدران تسجيل دخول، أو قيود على الأعضاء، أو حظر جغرافي.

تشير البيانات إلى أن 15% من حالات فشل المعاينة ناتجة عن كون الصفحة مفتوحة لمستخدمين محددين فقط (مركز مساعدة Search Console، 2024).

السيناريوهات:

• موقع وصفات طعام بنظام العضوية جعل صفحة تفاصيل Recipe متاحة “بعد التسجيل فقط”، مما منع Googlebot من الزحف إلى الحقول المطلوبة مثل recipeIngredient، وكانت أداة الاختبار تظهر دائماً “لا توجد نتائج”؛ وبعد إلغاء قيود الدخول، تعافى معدل ظهور النتائج المنسقة من 0 إلى 8% خلال 3 أيام.
• علامة تجارية لمستحضرات التجميل أخفت معلومات الأسعار عن مستخدمي جنوب شرق آسيا، مما أدى إلى عدم القدرة على الزحف إلى حقل offers (الذي يحتوي على السعر) في علامة Product، وبعد الإصلاح ارتفعت نقرات النتائج المنسقة في تلك المنطقة بنسبة 25%.

طرق التحقق:

• استخدام وضع التصفح الخفي في Chrome (مع تعطيل ملفات تعريف الارتباط وحالة تسجيل الدخول) لزيارة الصفحة والتأكد من أن المحتوى مرئي بالكامل.
• استخدام AccessiBe لمحاكاة عناوين IP من مناطق مختلفة للتحقق من وجود قيود توجيه جغرافي (مثل “متاح فقط لمستخدمي الولايات المتحدة”).

سرعة تحميل الصفحة

أظهر تقرير HTTP Archive لعام 2023 أن الصفحات التي يتجاوز وقت تحميلها 5 ثوانٍ، يقوم 22% من برامج الزحف بإيقاف الزحف إليها مبكراً.

التأثيرات المحددة:

• إذا كانت علامة Product تقع في أسفل صفحة المنتج، فإن مهلة التحميل ستجعل Googlebot يتخطى هذا الجزء مباشرة.
• علامات Article التي يتم تحميلها بشكل غير متزامن (مثل معلومات المؤلف الناتجة عن AJAX) قد يتم تجاهلها إذا استغرق التحميل وقتاً طويلاً.

التحقق:

• استخدام PageSpeed Insights لاختبار مؤشر “LCP (أكبر طلاء محتوي)” للجوال/السطح — يجب التحكم فيه ليكون ضمن 2.5 ثانية (متطلبات الأداء من Google).
• إجراءات التحسين:
  • ضغط الصور: استخدام تنسيق WebP بدلاً من JPG/PNG لتقليل حجم الملف بنسبة 50% (مثلاً تحويل صورة 1MB من JPG إلى WebP يجعلها 400KB فقط).
  • تأجيل تحميل الموارد غير الضرورية: ضبط إعلانات التذييل وتعليقات الشريط الجانبي لتكون “تحميل عند التمرير إلى المنطقة المرئية”.
  • تفعيل ضغط Gzip: من خلال إعدادات الخادم (مثل gzip on; في Nginx) لتقليل حجم ملفات HTML/CSS.

حالة دراسية: صفحة تجارة إلكترونية للإلكترونيات كان وقت تحميلها الأولي 6.2 ثانية، وLCP كان 3.8 ثانية. بعد التحسين، انخفض وقت التحميل إلى 3.5 ثانية، وLCP لأقل من ثانيتين، وارتفع معدل نجاح زحف Googlebot من 75% إلى 92%، وزاد ظهور النتائج المنسقة لـ Product بنسبة 19%.

تشفير HTTPS

جميع روابط URL المتعلقة بالبيانات المنظمة (الصور، روابط الصفحات، offers.url) يجب أن تستخدم HTTPS.

تطلب Google صراحة أن الموارد التي لا تستخدم HTTPS قد تُصنف كـ “غير آمنة”، مما يؤدي إلى 18% من حالات فشل المعاينة (وثائق مطوري Google، 2023).

الأخطاء الشائعة:

• استخدام HTTP لروابط الصور (مثل http://example.com/headphones.jpg)، مما يجعل حقل image في Product غير صالح.
• خاصية url في Article تشير إلى نسخة HTTP (مثل http://blog.example.com/post-123)، فيتجاهلها Google.

التحقق:

• الفحص اليدوي لجميع الروابط في العلامات للتأكد من أنها تبدأ بـ “https://”.
• استخدام SSL Labs لاختبار شهادة SSL للموقع — للتأكد من عدم انتهاء صلاحيتها أو وجود أخطاء في الإعدادات (مثل عدم تفعيل TLS 1.2 أو أعلى).

الإصلاح: بعد أن قام موقع أزياء بإصلاح جميع روابط صور HTTP، ارتفع معدل ظهور النتائج المنسقة لـ Product من 12% إلى 30%، واختفت تنبيهات “مورد العلامة غير صالح” في Search Console تماماً.

إصلاح أنواع الأخطاء الشائعة

يتطلب إصلاح الأخطاء الشائعة استهداف أربع فئات رئيسية:

• أخطاء بناء جملة JSON-LD (تمثل 38%)
• فقدان الخصائص المطلوبة (29%)
• عدم التداخل المعياري (22%)
• عدم التقاط المحتوى الديناميكي (11%)

تشير البيانات إلى أنه بعد الإصلاح تدريجياً، يمكن أن يرتفع معدل نجاح معاينة النتائج المنسقة من 45% إلى 82% (حالة Google 2024).

أخطاء بناء جملة JSON-LD

تمثل أخطاء بناء جملة JSON-LD 38% من مشكلات البيانات المنظمة، وتتمثل بشكل رئيسي في عدم تطابق الأقواس (42%)، والفاصلات الزائدة (31%)، وأخطاء نوع البيانات (27%)، وبعد الإصلاح يمكن أن يرتفع معدل التعرف على العلامات إلى أكثر من 95% (بيانات Google 2024).

أظهر تقرير أخطاء البيانات المنظمة لعام 2024 من Google أن 38% من حالات فشل معاينة النتائج المنسقة ناتجة عن أخطاء بناء جملة JSON-LD.

عدم تطابق الأقواس وعلامات الاقتباس

عدم تطابق الأقواس ({}) وعلامات الاقتباس ("") هو المشكلة الأكثر شيوعاً، ويمثل 42% من جميع أخطاء JSON-LD (بيانات التحقق من Schema.org لعام 2023).

تنشأ هذه الأخطاء عادةً عن الإهمال أثناء الترميز، مثل نسيان رمز الإغلاق أو عدم اقتران علامات الاقتباس.

حالة محددة: علامة Course لإحدى منصات التعليم عبر الإنترنت أظهرت “JSON غير صالح” في أداة اختبار Google بسبب نسيان قوس الإغلاق:

{
“@context”: “https://schema.org”,
“@type”: “Course”,
“name”: “أساسيات التسويق الرقمي”,
“description”: “تعلم مهارات SEO وSEM” // تم نسيان “}” في النهاية

طرق الإصلاح:

• استخدام ميزة “مطابقة الرموز” في محرر الأكواد (مثل إضافة Bracket Pair Colorizer في VS Code)، حيث ستظهر الأقواس بألوان مختلفة لتوضيح المواقع غير المغلقة.
• استخدام أدوات عبر الإنترنت (مثل JSONLint) ولصق كود JSON، حيث ستقوم الأداة بتحديد موقع الخطأ مباشرة (مثل “Expected ‘}’, got ‘EOF'”).

تأثير الإصلاح: بعد أن قامت المنصة بالتصحيح، تم تحليل علامة Course بنجاح، وتعافى معدل ظهور النتائج المنسقة من 0 إلى 7%، واختفى تنبيه “بيانات منظمة غير صالحة” في Search Console.

الفاصلات الزائدة

تشير الفاصلة الزائدة إلى إضافة فاصلة بعد آخر خاصية في الكائن ({}) أو المصفوفة ([])، وتمثل 31% من أخطاء بناء الجملة (وثائق مطوري Google، 2024).

سيناريو نموذجي: في علامة Offer لموقع تجارة إلكترونية، تمت إضافة فاصلة زائدة بعد حقل price:

“offers”: {
“@type”: “Offer”,
“price”: “99.99”, // فاصلة زائدة في النهاية
“priceCurrency”: “USD”
}

عندما يواجه المحلل هذه الفاصلة، سيعتقد أن هناك خاصية أخرى تليها، ولكن في الواقع لا يوجد، مما يؤدي إلى اعتبار كائن offers بالكامل غير صالح.

طرق الإصلاح:

• استخدام أدوات مثل JSONLint لتنسيق الكود تلقائياً، حيث ستقوم الأداة بحذف الفاصلات الزائدة.
• الفحص اليدوي: لا يمكن أبداً وضع فاصلة بعد آخر خاصية في الكائن/المصفوفة (متطلبات صارمة لمعايير JSON).

إحدى شركات التجارة الإلكترونية للملابس كانت تعاني من عدم صلاحية 30% من علامات المنتجات بسبب الفاصلات الزائدة، وبعد الإصلاح ارتفع معدل العلامات الصالحة إلى 95%، وزاد حجم ظهور النتائج المنسقة لـ Product بنسبة 22%.

خطأ في نوع البيانات

يتطلب JSON-LD أن تتطابق قيم الخصائص تمامًا مع أنواع البيانات المحددة في Schema.org، وتمثل هذه الأخطاء 27% من أخطاء بناء الجملة (Schema.org 2023).

تشمل الأخطاء الشائعة ما يلي:

• تنسيق التاريخ الخاطئ: عدم استخدام معيار ISO 8601 (يجب أن يكون "2023-10-05T08:00:00+08:00"، وليس "2023/10/05" أو "October 5, 2023")؛
• خطأ في نوع القيمة العددية: استخدام الأرقام بدلاً من السلاسل النصية لخصائص مثل السعر أو التقييم (على سبيل المثال، "price": 99.99 يجب تغييرها إلى "price": "99.99"، و "ratingValue": 4.5 يجب أن تظل بتنسيق سلسلة نصية).

توضيح الحالة: في علامة Article لمدونة طعام، تم استخدام "2023-10-05" لخاصية datePublished (صحيح)، ولكن تم كتابة reviewRating.ratingValue كعدد 4.5 بدلاً من السلسلة النصية "4.5".

أظهرت أداة اختبار Google تنبيهًا بـ “قيمة تقييم غير صالحة”، مما منع إنشاء المقتطف المميز.

بعد الإصلاح وتغيير قيمة التقييم إلى سلسلة نصية، ارتفع معدل ظهور المقتطف المميز من 10% إلى 28%.

أساس التحقق: تنص قوانين Schema.org بوضوح على أن ratingValue يجب أن تكون من نوع “Text” (سلسلة نصية)، وحتى إذا كان المحتوى رقمًا، يجب إحاطته بعلامات اقتباس — وهذا تفصيل يسهل على الكثير من المطورين إغفاله.

فقدان الخصائص الضرورية

يمثل فقدان الخصائص الضرورية 29% من أخطاء البيانات المنظمة، وتختلف معدلات الفقدان بشكل ملحوظ حسب نوع العلامة (نقص offers في Product يمثل 38%، ونقص datePublished في Article يمثل 29%). بعد الإصلاح، يمكن استعادة عرض أكثر من 80% من النتائج المنسقة (حالة Google 2024)، وذلك من خلال إكمال الحقول وفقًا لمعايير Schema.

Product (المنتج)

تعد علامة Product الأكثر استخدامًا في التجارة الإلكترونية، وخصائصها الضرورية هي name وimage وoffers (حسب تعريف Schema.org).

تعتبر offers (عروض المنتج) هي الجوهر — حيث يجب أن تحتوي على خصائص فرعية مثل price (السعر)، و priceCurrency (العملة)، و availability (التوفر)، ويصل معدل فقدانها إلى 38% (بيانات Google Search Console 2023).

بعد الفقدان: عانى موقع تجارة إلكترونية للملابس من فقدان طويل الأمد لـ offers في علامة Product، مما أدى إلى:

• إظهار أداة الاختبار “لا توجد نتائج منسقة”؛
• ظهور العنوان والوصف فقط في نتائج البحث، دون سعر أو زر شراء؛
• انخفاض نسبة النقر إلى الظهور بنسبة 40% مقارنة بالمنافسين (الذين يعرضون بطاقات منتجات كاملة).

إجراء الإصلاح: إضافة حقل offers وتحديد السعر والتوفر:

“offers”: {
“@type”: “Offer”,
“price”: “89.99”,
“priceCurrency”: “USD”,
“availability”: “https://schema.org/InStock”
} في غضون 3 أيام، تعافى معدل ظهور النتائج المنسقة من 0 إلى 15%، وارتفعت نسبة النقر إلى الظهور بنسبة 22%، وزادت التحويلات بنسبة 18%.

Article (المقال)

الخصائص الضرورية لـ Article (مقال/مدونة) هي headline (العنوان)، وdatePublished (تاريخ النشر)، وauthor (المؤلف).

يعد datePublished هو المفتاح لـ Google للحكم على “حداثة” المحتوى — ومعدل فقدانه 29% (تقرير النظام البيئي للمحتوى من Google 2024).

بعد الفقدان: مدونة تقنية لم تضف datePublished في علامة Article، مما أدى إلى:

• عدم القدرة على تفعيل “المقتطف المميز” (Featured Snippet)؛
• تأخر ترتيب المقال في نتائج البحث عن المنافسين الذين نشروا في نفس الفترة (حيث يعرض المنافسون تاريخ النشر)؛
• انخفاض ثقة المستخدمين — حيث يُعتبر المحتوى الذي لا يحمل تاريخًا “قديمًا”.

إجراء الإصلاح: إضافة تاريخ النشر بتنسيق ISO 8601:

“datePublished”: “2024-03-15T10:00:00+08:00” ارتفع معدل ظهور المقتطف المميز من 10% إلى 35%، وزادت نسبة النقر على المقال بنسبة 25%، وارتفعت احتمالية دخول المقال في المراكز الثلاثة الأولى بنسبة 19%.

LocalBusiness (الأعمال المحلية)

الخصائص الضرورية لـ LocalBusiness هي name وaddress وtelephone. ويعد address (العنوان التفصيلي) هو الجوهر لربط Google ببطاقات الخرائط — ومعدل فقدانه 35% (بيانات Google My Business 2023).

بعد الفقدان: مقهى لم يكمل العنوان في علامة LocalBusiness (اكتفى بكتابة المدينة)، مما أدى إلى:

• عدم ظهور بطاقة الخريطة في نتائج البحث؛
• عدم قدرة المستخدمين على التنقل مباشرة إلى المتجر؛
• انخفاض الحركة المحلية بنسبة 50% مقارنة بالمنافسين المحيطين.

إجراء الإصلاح: إضافة العنوان التفصيلي من نوع PostalAddress:

“address”: {
“@type”: “PostalAddress”,
“streetAddress”: “123 Main St”,
“addressLocality”: “Seattle”,
“addressRegion”: “WA”,
“postalCode”: “98101”
} ظهرت بطاقة الخريطة في غضون 24 ساعة، وارتفعت حركة البحث المحلية بنسبة 40%، وزادت تحويلات الزيارة بنسبة 28%.

Recipe (الوصفة)

الخصائص الضرورية لـ Recipe هي name وdescription وrecipeIngredient (قائمة المكونات).

تعد recipeIngredient هي “المحتوى الجوهري” للوصفة — ومعدل فقدانها 41% (دراسة مستخدمي AllRecipes 2024).

بعد الفقدان: موقع طعام لم يدرج المكونات في علامة Recipe، مما أدى إلى:

• عدم ظهور قائمة المكونات والخطوات؛
• عدم قدرة المستخدمين على الحكم ما إذا كانت الوصفة تلبي احتياجاتهم؛
• انخفاض معدل الحفظ بنسبة 60% مقارنة بالمنافسين.

إجراء الإصلاح: إضافة قائمة مكونات منظمة:

“recipeIngredient”: [
“دقيق 200 جرام”,
“بيضتان”,
“حليب 150 مل”,
“سكر 50 جرام”
] ارتفع معدل ظهور قائمة المكونات والخطوات من 8% إلى 25%، وزاد معدل الحفظ بنسبة 32%، وارتفعت احتمالية اختيار Google لها كـ “وصفة رائجة” بنسبة 21%.

تداخل الأنواع غير المعياري

يعد “تداخل الأنواع” في البيانات المنظمة هو منطق Schema.org — حيث ينقل النوع الأب الارتباط الدلالي من خلال تضمين الأنواع الفرعية، فعلى سبيل المثال، تحتاج Recipe إلى تداخل NutritionInformation (معلومات غذائية) عبر حقل nutrition ليفهم Google أن “السعرات الحرارية تنتمي لهذا الطبق”.

جوهر أخطاء التداخل

نظام الأنواع في Schema.org هو “تسلسل شجري”: يحدد النوع الأب الخصائص الجوهرية، بينما يوسع النوع الفرعي التفاصيل المحددة.

على سبيل المثال:

• Recipe (نوع أب) هو “محتوى الوصفة”، ويحتاج لربط NutritionInformation (نوع فرعي) عبر حقل nutrition لنقل تفاصيل مثل “السعرات الحرارية، محتوى الدهون”؛
• Event (نوع أب) هو “معلومات الحدث”، ويحتاج لربط Place (نوع فرعي) عبر حقل location لنقل معلومات الموقع مثل “العنوان، الإحداثيات”.

عواقب الخطأ: إذا تم تخطي النوع الفرعي ووضع الخصائص مباشرة تحت النوع الأب، سيقرر Google أن “تبعية الخصائص غير واضحة”، وبالتالي يتجاهل هذا الجزء من المحتوى.

مثلاً، إذا كتب موقع طعام في علامة Recipe مباشرة "calories": "350 kcal" بدلاً من تداخلها تحت NutritionInformation، ستظهر أداة اختبار Google تنبيهًا بـ “تعذر التعرف على حقل السعرات الحرارية”، مما يؤدي لعدم ظهور العناصر الغذائية في النتائج المنسقة.

4 أخطاء تداخل شائعة

(1) Recipe: المعلومات الغذائية لم يتم تداخلها في NutritionInformation

سيناريو الخطأ: مدونة طعام كتبت السعرات والدهون مباشرة تحت النوع الأب في علامة Recipe:

{
“@type”: “Recipe”,
“name”: “طماطم مقلية مع البيض”,
“nutrition”: { // خطأ: nutrition هي خاصية للنوع الأب، وتحتاج لتداخل نوع فرعي
“calories”: “350 kcal”,
“fatContent”: “12g”
}
}
المشكلة: لا يستطيع Google التعرف على أن الخصائص تحت nutrition تنتمي لـ “المعلومات الغذائية”، لذا لا تظهر في النتائج المنسقة.

إجراء الإصلاح: تداخل المعلومات الغذائية تحت النوع الفرعي NutritionInformation:

{
“@type”: “Recipe”,
“name”: “طماطم مقلية مع البيض”,
“nutrition”: {
“@type”: “NutritionInformation”, // إضافة النوع الفرعي
“calories”: “350 kcal”,
“fatContent”: “12g”
}
}النتيجة: في نتائج الوصفات المنسقة لهذه المدونة، ارتفع معدل ظهور العناصر الغذائية من 8% إلى 25%، وزاد معدل حفظ المستخدمين بنسبة 32% (بيانات AllRecipes 2024).

(2) Event: معلومات الموقع لم يتم تداخلها في Place و PostalAddress

سيناريو الخطأ: موقع مؤتمرات كتب سلسلة نصية للعنوان مباشرة في علامة Event، دون تداخل طبقي:

{
“@type”: “Event”,
“name”: “قمة التسويق الرقمي”,
“location”: “مركز مؤتمرات سان فرانسيسكو” // خطأ: location تحتاج لتداخل Place و PostalAddress
}
المشكلة: لا يستطيع Google تحليل المعلومات المنظمة للعنوان، لذا لا تظهر بطاقة الخريطة.

إجراء الإصلاح: تداخل الأنواع الفرعية Place (مكان) و PostalAddress (عنوان بريدي):

{
“@type”: “Event”,
“name”: “قمة التسويق الرقمي”,
“location”: {
“@type”: “Place”,
“name”: “مركز مؤتمرات سان فرانسيسكو”,
“address”: {
“@type”: “PostalAddress”,
“streetAddress”: “123 Mission St”,
“addressLocality”: “San Francisco”,
“addressRegion”: “CA”,
“postalCode”: “94105”
},
“geo”: {
“@type”: “GeoCoordinates”,
“latitude”: “37.7890”,
“longitude”: “-122.4030”
}
}
}النتيجة: بعد الإصلاح، ظهرت بطاقة الخريطة في نتائج البحث، وارتفعت نسبة النقر على الحدث بنسبة 40%، وزادت طلبات التسجيل بنسبة 28% (بيانات Google Events 2023).

(3) Product: معلومات التقييم لم يتم تداخلها في Review أو AggregateRating

سيناريو الخطأ: منصة تجارة إلكترونية كتبت درجة التقييم مباشرة في علامة Product، دون تداخل النوع الفرعي AggregateRating (التقييم التجميعي):

{
“@type”: “Product”,
“name”: “سماعات لاسلكية”,
“reviewScore”: “4.5” // خطأ: reviewScore يجب تداخلها تحت AggregateRating
}المشكلة: لا يستطيع Google التعرف على أن “4.5 درجة” هي التقييم التجميعي للمنتج، لذا لا تظهر تقييمات النجوم.

إجراء الإصلاح: تداخل النوع الفرعي AggregateRating:

{
“@type”: “Product”,
“name”: “سماعات لاسلكية”,
“aggregateRating”: {
“@type”: “AggregateRating”,
“ratingValue”: “4.5”,
“reviewCount”: “120”
}
}النتيجة: في النتائج المنسقة لهذا المنتج، ارتفع معدل ظهور تقييمات النجوم من 15% إلى 50%، وزادت التحويلات بنسبة 19% (بيانات Shopify 2024).

(4) Article: معلومات المؤلف لم يتم تداخلها في Person

سيناريو الخطأ: مدونة تقنية كتبت اسم المؤلف مباشرة في علامة Article، دون تداخل النوع الفرعي Person (شخص):

{
“@type”: “Article”,
“name”: “توجهات SEO لعام 2024”,
“author”: “تشانغ سان” // خطأ: author يحتاج لتداخل النوع الفرعي Person
}المشكلة: لا يستطيع Google التعرف على معلومات هوية المؤلف، لذا لا يظهر ملصق “المؤلف”.

إجراء الإصلاح: تداخل النوع الفرعي Person:

{
“@type”: “Article”,
“name”: “توجهات SEO لعام 2024”,
“author”: {
“@type”: “Person”,
“name”: “تشانغ سان”,
“url”: “https://example.com/author/zhangsan”
}
}النتيجة: ارتفع معدل ظهور ملصق “المؤلف” للمقالات من 20% إلى 60%، وتحسنت ثقة المستخدمين بنسبة 25% (بيانات Google Authorship 2023).

فشل التقاط المحتوى الديناميكي

يشير المحتوى الديناميكي إلى المحتوى الذي يتم إنشاؤه في الوقت الفعلي عبر JavaScript (JS) أو AJAX أو إطارات تطبيقات الصفحة الواحدة (SPA) — مثل الصفحات المبنية بـ React/Vue، أو قوائم المقالات ذات التمرير اللانهائي، أو خطوات الوصفة التي يتم تحميلها بعد النقر على زر.

علامات هذا النوع من المحتوى (مثل سعر Product، أو تعليقات Article) لا تظهر في HTML الأولي، بل يتم حقنها ديناميكيًا بواسطة JS من جهة العميل.

لكن آلية زحف Googlebot هي “زحف HTML الأولي أولاً، ثم تنفيذ JS”؛ فإذا كان تنفيذ JS بطيئًا جدًا أو كان المحتوى يعتمد على الرندرة من جهة العميل، فلن يتم إنشاء النتائج المنسقة.

أشارت مدونة مهندسي Google (2024) إلى أن 40% من الصفحات الديناميكية تفشل علاماتها في القراءة من قبل برامج الزحف بسبب عدم القيام بالرندرة المسبقة.

تعذر زحف المحتوى الديناميكي

تنقسم عملية زحف Googlebot إلى خطوتين:

1. تنزيل HTML الأولي: الحصول على الهيكل الأساسي للصفحة (بدون المحتوى الناتج عن JS)؛
2. تنفيذ JS: محاكاة تشغيل JS في المتصفح للحصول على المحتوى الديناميكي (يتطلب انتظار اكتمال تنفيذ JS).

لكن “صبر” برنامج الزحف محدود:

• إذا تجاوزت مدة تنفيذ JS أكثر من 3 ثوانٍ، قد ينهي Googlebot العملية مبكرًا، مما يؤدي لعدم قراءة العلامات الديناميكية (بيانات Lighthouse 2023)؛
• إذا كان المحتوى يعتمد على “تفاعل المستخدم” (مثل النقر على “تحميل المزيد”)، فسيقوم برنامج الزحف بتخطي هذا الجزء.

حالة: موقع إخباري يستخدم React لبناء SPA، ويتم تحميل منطقة التعليقات في Article ديناميكيًا بواسطة JS.

أظهرت أداة الاختبار “لا توجد نتائج منسقة” — رغم وجود علامات التعليقات فعليًا، إلا أن JS لم يكتمل تنفيذه أثناء زحف Googlebot، ولم يتم تضمين محتوى التعليقات في HTML الأولي.

3 مشكلات متكررة

(1) SPA (تطبيقات الصفحة الواحدة): HTML الأولي فارغ، ولم يتم تضمين العلامات

تطبيقات SPA هي “صفحة واحدة يتم استبدال محتواها ديناميكيًا”، وعادة ما يكون HTML الأولي فارغًا <div id="root"></div>، ويتم حقن كل المحتوى بواسطة JS.

إذا لم يتم إجراء رندرة مسبقة، فلن يحتوي HTML الأولي الذي يزحف إليه Googlebot على أي بيانات منظمة، وبالتالي لن يتم التعرف على العلامات. بيانات: علامة Tour لموقع سياحي تم إنشاؤها بواسطة React، وكان HTML الأولي فارغًا.

أظهر Search Console “لم يتم العثور على علامات مؤهلة”، وكان معدل ظهور النتائج المنسقة 0. بعد الإصلاح باستخدام الرندرة من جهة الخادم (SSR)، أصبح HTML الأولي يحتوي مباشرة على العلامات الكاملة لـ Tour، وارتفع معدل الظهور من 0 إلى 28%.

(2) تحميل AJAX: يتم الحصول على المحتوى بشكل غير متزامن، وبرنامج الزحف لا ينتظر اكتمال التحميل

يُستخدم AJAX لتحميل المحتوى ديناميكيًا (مثل قوائم المنتجات ذات التمرير اللانهائي، أو التعليقات)، لكن برنامج الزحف لن ينتظر اكتمال طلبات AJAX — فإذا تجاوز وقت تحميل المحتوى “عتبة المهلة” لبرنامج الزحف (حوالي 3 ثوانٍ)، فسيتم إغفال العلامات.

حالة: قائمة منتجات “قد يعجبك أيضًا” في منصة تجارة إلكترونية يتم تحميلها بواسطة AJAX، ويتم إنشاء علامات Product ديناميكيًا بواسطة JS.

أظهرت أداة الاختبار “تم تجاهل بعض العلامات” — حيث لم يكتمل طلب AJAX أثناء زحف Googlebot، ولم يتم تضمين معلومات المنتج.

بعد الإصلاح باستخدام أداة رندرة مسبقة (Prerender.io) لإنشاء HTML يحتوي على قائمة المنتجات الكاملة، ارتفع معدل التعرف على العلامات من 60% إلى 95%.

(3) التحميل المتأخر (Lazy Load): المحتوى يظهر بالتحفيز، ويتجاوز وقت انتظار برنامج الزحف

يُستخدم التحميل المتأخر لتحسين سرعة الصفحة، مثل تحميل خطوات HowTo أو قائمة مكونات Recipe عند التمرير إلى المنطقة المرئية. ولكن إذا كان وقت التأخير طويلاً جدًا (أكثر من ثانيتين مثلاً)، فقد يفوت برنامج الزحف هذا الجزء.

بيانات: علامة HowTo لموقع أثاث (مثل خطوات “تركيب خزانة كتب”) تتأخر ثانيتين في التحميل.

أظهرت أداة اختبار Google تنبيهًا بـ “تعذر التعرف على حقول الخطوات” — حيث لم ينتظر برنامج الزحف اكتمال التحميل.

بعد الإصلاح وتقليل وقت التأخير إلى أقل من ثانية، ارتفع معدل ظهور الخطوات من 18% إلى 43%.

ثلاث فئات من طرق الإصلاح

(1) الرندرة المسبقة: الخادم ينشئ HTML كاملاً، وبرنامج الزحف يزحف إليه مباشرة

تعني الرندرة المسبقة تشغيل JS على جهة الخادم لإنشاء HTML يحتوي على المحتوى الديناميكي الكامل، ثم إرسال هذا الـ HTML إلى برنامج الزحف.

يمكن لأدوات مثل Prerender.io أو وحدات الرندرة المسبقة في Nginx التعرف تلقائيًا على طلبات برامج الزحف وإرجاع HTML المرندر مسبقًا.

النتيجة: بعد استخدام Prerender.io للرندرة المسبقة في تطبيق SPA لتجارة إلكترونية، ارتفع معدل نجاح زحف علامات Product من 75% إلى 92%، وارتفع معدل ظهور النتائج المنسقة من 5% إلى 28%.

(2) الرندرة من جهة الخادم (SSR): استخدام إطارات العمل لرندرة محتوى JS مباشرة

تعني SSR استخدام إطارات عمل مثل Next.js (لـ React) أو Nuxt.js (لـ Vue) لرندرة مكونات JS كإصدار HTML نصي على جهة الخادم قبل إرسالها إلى العميل.

وبهذه الطريقة، يحتوي HTML الأولي على العلامات الكاملة، ولا يحتاج برنامج الزحف لانتظار تنفيذ JS.

حالة: تم إعادة بناء موقع إخباري باستخدام Next.js، حيث يتم إنتاج منطقة تعليقات Article عبر SSR.

عند زحف Googlebot، حصل مباشرة على علامات Comment للتعليقات، وارتفع معدل ظهور المقتطف المميز من 10% إلى 50%، وزاد التفاعل مع التعليقات بنسبة 35%.

(3) تحسين مدة تنفيذ JS: التأكد من تحميل العلامات في غضون 3 ثوانٍ

إذا تعذر إجراء الرندرة المسبقة أو SSR، فيجب تحسين وقت تنفيذ JS لضمان تحميل العلامات الديناميكية في غضون 3 ثوانٍ.

استخدم Lighthouse أو علامة تبويب Performance في Chrome DevTools لفحص وقت تحميل العلامات:

• ضغط ملفات JS: استخدام Webpack أو Rollup لضغط الكود وتقليل حجم الملفات؛
• تأجيل تحميل JS غير الضروري: ضبط السكربتات التي لا تؤثر على العلامات (مثل الإعلانات والإحصائيات) لتكون async أو defer؛
• تخزين الموارد مؤقتًا: استخدام CDN لتخزين ملفات JS لتقليل وقت التحميل.

بيانات: قام موقع إعلامي بتحسين وقت تنفيذ JS من 4.2 ثانية إلى 2.5 ثانية، مما رفع معدل نجاح زحف Googlebot من 68% إلى 90%، وزاد ظهور النتائج المنسقة لـ Article بنسبة 22%.

أخيرًا أود أن أقول: سطر واحد صحيح من JSON، وتداخل معياري واحد، ورندرة مسبقة في وقتها، كلها أمور قد تنقل نتائجك المنسقة من “العدم” إلى “الوجود”.