معظم المواقع التي تشغّل JSON-LD اليوم ستفشل في اختبار سلامة بسيط: الصق بياناتها البنيوية في أداة تحقق وانظر ما الذي يظهر فعليًا. المسألة ليست «هل هي محسّنة». بل ببساطة: هل يتم تحليلها (parse) بنجاح؟ هل تشير إلى كيان واحد أم إلى ثلاثة كيانات متضاربة؟ هل هي ترميز لنتيجة منسقة لا تزال Google تمنحها؟
أصبح Schema مجرد خانة يتم وضع علامة عليها — تُثبَّت إضافة (plugin)، يُنسخ قالب من تدوينة، ويفترض الجميع أنه يعم ل لأن لا شيء تغيّر ظاهريًا في الصفحة. أعطال البيانات البنيوية غير مرئية بطبيعتها. لا يوجد تخطيط معطوب يمكن ملاحظته. هناك فقط Knowledge Graph لا يفهم أبدًا من أنت بالضبط، ونتائج منسقة لا تظهر مطلقًا، ولا أحد يقوم بتصحيح المشكلة لأن لا شيء يبدو خاطئًا.
ما الذي يفعله JSON-LD فعليًا في 2026
يُدرَج عملان مختلفان تحت مسمى «ترميز Schema»، والخلط بينهما هو حيث يبدأ الكثير من الجهد المهدور.
المهمة الأولى هي النتائج المنسقة (rich results): التحسينات المرئية في صفحة نتائج البحث (SERP) — تقييمات النجوم، نطاقات الأسعار، تواريخ الفعاليات، إعلانات الوظائف، مسارات التنقل (breadcrumbs)، صور مصغّرة للفيديو. مجموعة محدودة فقط من أنواع @type تتأهل لذلك، وGoogle تغيّر هذه المجموعة دون سابق إنذار يُذكر.
المهمة الثانية هي وضوح الكيان (entity clarity): إخبار Google من أنت، وما الذي تنتمي إليه، وكيف ترتبط صفحاتك ببعضها البعض. تقوم أنواع مثل Organization وWebSite وPerson وWebPage بهذه المهمة غالبًا. نادرًا ما تُنتج مقتطفًا مرئيًا بمفردها، لكنها المصدر الذي تعتمد عليه لوحة المعرفة (Knowledge Panel)، ومربع بحث روابط الموقع (sitelinks search box)، وتوضيح هوية العلامة التجارية عند التباسها.
معظم أخطاء Schema التي تستحق الإصلاح تقع ضمن واحدة من ثلاث فئات، وليست خفية ب مجرد أن تعرف أين تبحث.
الخطأ الأول: JSON معطوب بسبب أخطاء الهروب (escaping) في القالب
هذا هو الخطأ الأكثر شيوعًا والأقل ظهورًا. يحدث عند نقطة التماس بين نظام إدارة المحتوى (CMS) ووسم <script type="application/ld+json">.
اقتباس من مراجعة يحتوي على علامة اقتباس مزدوجة عشوائية بداخله. وصف منتج تم لصقه من ورقة مواصفات ويحتوي على فاصل سطر خام في منتصفه. أي من هذه الحالات، عند إدراجها في قالب JSON-LD عبر دمج نصوص (string concatenation) ساذج بدلاً من التسلسل (serialization) الصحيح، ينتج عنه شيء كهذا:
{
"@type": "Product",
"name": "Editor's Choice Desk Lamp",
"description": "The reviewer called it "the best lamp under $50""
}
علامة الاقتباس المزدوجة الداخلية غير المهروبة هذه تكسر محلل JSON عند تلك النقطة بالضبط. ستقوم أداة Rich Results Test من Google بوسمها كغير صالحة — لكن هذا الاختبار عادةً ما يُشغَّل مرة واحدة فقط، عند الإطلاق، على رابط واحد مُختار يدويًا. لا أحد يعيد تشغيله على الـ400 صفحة منتج التي تُطلق بعد ستة أشهر بعادات ترقيم مختلفة من كاتب محتوى جديد.
الحل ليس معقدًا: لا تبنِ سلسلة JSON يدويًا أبدًا. ابنِ الكائن (object) بلغة القوالب التي تستخدمها وقم بتسلسله (serialize) بشكل صحيح (JSON.stringify في JS، أو json_encode في PHP، أو ما يعادله ا في أي أداة تُصيّر صفحاتك) بحيث تتم معالجة الهروب (escaping) بواسطة كود يفهم ماهية JSON، لا بواسطة كاتب قالب لا يفهمها. ثم تحقق من HTML المُصيَّر — الاستجابة الفعلية التي يراها الزاحف — وليس مصدر القالب. يمكن أن يبدو القالب مثاليًا وما زال يُصدر JSON معطوبًا لأي سلسلة نصية تحتوي على حرف خاص.
الخطأ الثاني: كيانات Organization مكررة بدون @id مشترك
يظهر هذا الخطأ في كل مرة تقريبًا يمر فيها الموقع بإعادة تصميم، أو ترحيل لنظام إدارة المحتوى، أو استخدام أكثر من إضافة SEO في الوقت نفسه.
يُصدر القالب (theme) كتلة Organization في التذييل (footer). تُصدر إضافة أخرى كتلة ثانية في كل صفحة، بقيمة logo وقائمة sameAs مختلفة قليلًا. أضاف مطوّر كتلة ثالثة يدويًا في الصفحة الرئيسية، منذ سنتين، لاختبار ترميز Schema لم يُنظَّف قط. لا تشترك أي منها في @id واحد.
بالنسبة لـGoogle، ثلاثة كائنات Organization بدون معرّف مشترك لا تُقرأ على أنها «نفس الشركة موصوفة ثلاث مرات». بل تُقرأ على أنها غامضة — ربما ثلاثة كيانات مختلفة، وربما إشارات مكررة تُلغي بعضها البعض. وهذا الغموض هو بالضبط ما يُفترض بترميز الكيانات منعه.
الحل هو @id أساسي (canonical) واحد، يُنشأ مرة واحدة ويُشار إليه في كل مكان:
{
"@type": "Organization",
"@id": "https://example.com/#organization",
"name": "Example Co",
"url": "https://example.com",
"logo": "https://example.com/logo.png",
"sameAs": ["https://www.linkedin.com/company/example"]
}
بعد ذلك تشير كل صفحة أخرى إلى ذلك الـ@id بدلاً من إعادة كتابة الكائن بالكامل — سواء في publisher الخاص بـWebSite، أو author أو publisher الخاص بـArticle، أو isPartOf الخاص بـWebPage. كيان واحد، مجموعة واحدة من الحقائق، يُشار إليها باستمرار. هذا نمذجة رسم بياني (graph modeling)، لا زخرفة، وهو الفرق بين أن تدمج Google إشاراتك أو أن تتردد في تحديد أي نسخة منك تثق بها.
الخطأ الثالث: أنواع Schema التي توقفت عن تحقيق أي فائدة
قامت Google بتقليص نتائج FAQ المنسقة في أغسطس 2023 لتقتصر على مجموعة صغيرة من المواقع الحكومية والصحية، ثم أزالت الميزة من Search بالكامل لاحقًا — حتى ذلك الاستثناء اختفى أيضًا. لا يزال ترميز FAQPage يُنسخ ويُلصق في مكتبات القوالب وإضافات أنظمة إدارة المحتوى كممارسة افتراضية «فضلى»، ولا تزال العديد من مواقع B2B والتجارة الإلكترونية تُصدره، دون الحصول على أي فائدة منه، بل وفي بعض الحالات تُعرّض نفسها لخطر حقيقي: إذا لم يتطابق نص الأسئلة الشائعة المُرمّز مع ما يظهر فعليًا على الصفحة، فهذا يُعد مخالفة لإرشادات البيانات البنيوية، وليس مجرد ترميز مهدور. نتائج HowTo المنسقة اختفت بالطريقة نفسها — أُزيلت من الجوال في 2023، ثم من سطح المكتب، ولم يعد هناك أي واجهة لا يزال فيها هذا النوع يحقق نتيجة مرئية.
النمط الذي يجب الانتباه إليه ليس فقط «هذا النوع أصبح مهجورًا». بل هو الترميز الذي نُسخ من قالب منذ ثلاث سنوات ولم تتم إعادة مراجعته مقابل ما يقوم به هذا النوع حاليًا. مفردات Schema.org مستقرة؛ أما استعداد Google لعرض نوع معين كنتيجة منسقة فليس كذلك، وهو يتغير وفق جدول زمني لا يُرسل لك أحد إشعارًا به.
ما الذي لا يزال يحقق نتيجة منسقة
القائمة التي تُثمر بشكل موثوق في 2026: Product مع سعر حقيقي، وتوفر فعلي، وAggregateRating مستمدة من مراجعات حقيقية لذلك المنتج تحديدًا (سياسة Google الخاصة بمقتطفات المراجعات تحظر صراحةً المراجعات الذاتية — أي أن تقوم الشركة بمراجعة منتجها الخاص — لذا يجب أن تكون المراجعات مراجعات عملاء حقيقية، لا مصطنعة)؛ BreadcrumbList؛ VideoObject؛ JobPosting؛ Event؛ Recipe؛ وSoftwareApplication مع applicationCategory صالحة. إلى جانب هذه الأنواع، تستمر Organization وWebSite ببنية @id نظيفة وغير مكررة في أداء مهمتها الأقل ظهورًا المتمثلة في وضوح الكيان وأهلية مربع بحث روابط الموقع، حتى بدون مقتطف مرئي خاص بها.
تدقيق بسيط يستحق التنفيذ كل ربع سنة
- تحقق من استجابة HTML المُصيَّرة، لا من ملف القالب — أخطاء الهروب (escaping) لا تظهر إلا بعد التصيير (render).
- ابحث (grep) في قاعدة الكود عن كل مكان يُصدر فيه
OrganizationأوWebSite. إذا كان هناك أكثر من مكان واحد، وحّدها خلف@idمشترك. - قارن كل
@typeتُصدره مقابل توثيق Google الحالي للبيانات البنيوية، لا مقابل التدوينة التي نسخته منها. - راجع تقارير Enhancements في Search Console شهريًا — أي ارتفاع مفاجئ في أخطاء "Invalid JSON-LD" أو "Missing field" يكون عادةً بسبب عملية نشر (deploy)، لا تغييرًا في سياسة Google.
- تأكد من أن كل ادعاء مُرمَّز (تقييم مراجعة، إجابة سؤال شائع، سعر) ظاهر على الصفحة بنفس الشكل. الترميز غير المدعوم بمحتوى مرئي هو مخالفة لإرشادات Google بانتظار أن تُلاحَظ.
الخلاصة
البيانات البنيوية هي بنية تحتية، لا زخرفة — وهي تفشل بالطريقة التي تفشل بها أي بنية تحتية: بصمت، إلى أن يكشفها تدقيق أو إجراء يدوي (manual action). المواقع التي تحقق نتائج منسقة في 2026 ليست تلك التي تملك أكبر قدر من Schema. بل هي تلك التي يُحلَّل JSON الخاص بها فعليًا بنجاح، وتُحل كياناتها إلى @id واحد، ويتطابق ترميزها مع ما يراه الشخص على الصفحة.
إذا كنت تريد فحص ذلك بشكل صحيح — المخرجات المُصيَّرة، لا مصدر القالب — فإن فريق SEO لدينا يُجري التحقق من البيانات البنيوية كجزء أساسي من كل تدقيق تقني، إلى جانب أعمال قابلية الزحف (crawlability) وCore Web Vitals التي عادةً ما تتضح أنها متصلة بها بشكل مباشر.
