البيانات المنظمة للبحث بالذكاء الاصطناعي: Schema لخدمة GEO تطابق الواقع
بقلم Dfeelings · آخر تحديث
الإجابة المختصرة
البيانات المنظمة للبحث بالذكاء الاصطناعي هي ترميز JSON-LD يصف النشاط التجاري وخدماته وأشخاصه وصفحاته بمفردات Schema.org، مترابطًا عبر معرّفات @id ثابتة. وفي تحسين محركات البحث التوليدية (GEO) تجعل البيانات المنظمة حقائق الكيان صريحة ومتسقة. وتؤكد Google أنه لا حاجة إلى ترميز خاص للظهور في AI Overviews أو AI Mode، وأن الترميز يجب أن يطابق المحتوى الظاهر؛ فالـSchema طبقة وضوح لا طريق مختصر، ولا يستطيع أحد ضمان استشهاد نظام ذكاء اصطناعي بأي نشاط.
حقائق أساسية
- تقول Google إنه لا حاجة إلى ملفات جديدة مقروءة آليًا أو ملفات نصية للذكاء الاصطناعي أو ترميز للظهور في AI Overviews أو AI Mode.
- توصي Google بصيغة JSON-LD للبيانات المنظمة متى سمح إعداد الموقع بذلك.
- تنص إرشادات Google على عدم ترميز محتوى غير ظاهر لقرّاء الصفحة.
- ألغت Google النتيجة المنسّقة للأسئلة الشائعة (FAQ) وتذكر أنها لم تعد تظهر في نتائج بحث Google (2026).
- يوصي Schema.org باستخدام رموز IETF BCP 47، مثل ar أو en، في خاصية inLanguage.
ما الذي تقدّمه البيانات المنظمة للبحث بالذكاء الاصطناعي؟
تعرض البيانات المنظمة للبحث بالذكاء الاصطناعي حقائق الصفحة بصيغة قياسية يقرؤها النظام آليًا، فلا يضطر إلى استنتاجها من التصميم والنص. وتصف Google البيانات المنظمة بأنها صيغة قياسية لتقديم معلومات عن الصفحة وتصنيف محتواها. وفي تحسين محركات البحث التوليدية (GEO) تجعل البيانات المنظمة حقائق الكيان صريحة، لكنها لا تُغني عن محتوى ظاهر واضح.
وثائق Google عن ميزات الذكاء الاصطناعي صريحة: لا متطلبات إضافية للظهور في AI Overviews أو AI Mode، ولا حاجة إلى إنشاء ملفات جديدة مقروءة آليًا أو ملفات نصية للذكاء الاصطناعي أو ترميز للظهور فيهما. وتذكر الصفحة نفسها «التأكد من أن البيانات المنظمة تطابق النص الظاهر في الصفحة» ضمن الممارسات الجيدة العامة. فالبيانات المنظمة عناية أساسية بالبحث عمومًا، لا رافعة ترتيب خاصة بالذكاء الاصطناعي.
ولا تنشر منصات الذكاء الاصطناعي الأخرى كيف تستخدم ترميز Schema.org عند صياغة الإجابات، أو هل تستخدمه أصلًا. والموقف الأمين أن البيانات المنظمة تقلل الغموض لأي نظام يقرؤها، وكلفتها قليلة حين تُولَّد من المصدر نفسه الذي يولّد الصفحة الظاهرة. وأي ادعاء بأن نوع Schema بعينه «يفتح» الاستشهاد في إجابات الذكاء الاصطناعي ادعاء غير مثبت.
لماذا تُعد JSON-LD الصيغة الموصى بها لترميز Schema؟
تُعد JSON-LD الصيغة الموصى بها لترميز Schema لأنها توضع في كتلة سكربت واحدة منفصلة عن HTML الصفحة، فيسهل توليدها وصيانتها والتحقق منها مقارنةً بالصيغ المدمجة في النص. وتذكر Google أنها توصي عمومًا بـJSON-LD متى سمح إعداد الموقع، مع دعمها لـMicrodata وRDFa. ويعرّف W3C صيغة JSON-LD بأنها صيغة مبنية على JSON لتسلسل البيانات المترابطة.
ولأن JSON-LD منفصلة عن العرض، يستطيع الموقع المعروض من الخادم بناءها من البيانات نفسها التي تعرض الصفحة. وهذه أوثق طريقة لإبقاء الترميز والمحتوى متطابقين: مصدر واحد ومخرجان. أما الترميز المكتوب يدويًا في قالب فينحرف عن المحتوى بمجرد أن يعدّل أحدهم النص وينسى السكربت.
وجزء «البيانات المترابطة» مهم في GEO؛ إذ تتيح JSON-LD منح كل عنصر معرّفًا عبر @id والإشارة إليه من أماكن أخرى، فتتحول المقاطع المتفرقة إلى وصف مترابط لنشاط واحد.
ما رسم @id المترابط، ولماذا يهم؟
رسم @id المترابط هو بيانات منظمة يملك فيها كل كيان، كـOrganization وWebSite وWebPage وService وPerson وArticle، معرّفًا ثابتًا، وتشير الكيانات إلى بعضها بهذا المعرّف بدل إعادة تعريفها في كل صفحة. ويصف معيار JSON-LD من W3C الخاصية @id بأنها وسيلة تعريف العقدة والإشارة إليها من مكان آخر. والرسم المترابط يجعل العلاقات صريحة.
يبدو رسم نشاط خدمي نموذجي هكذا: لـOrganization المعرّف https://example.com/#organization، ولـWebSite المعرّف https://example.com/#website ويذكر المؤسسة ناشرًا. ولكل WebPage معرّفها، وهي جزء من WebSite ولها BreadcrumbList. والـService تذكر المؤسسة مقدّمًا للخدمة (provider) وتحدد areaServed. والـPerson يعمل لدى المؤسسة (worksFor). والـArticle يذكر الشخص كاتبًا والمؤسسة ناشرًا.
الفائدة هي الاتساق: حين تُحفظ تفاصيل المؤسسة في عقدة واحدة يُشار إليها في كل مكان، لا تستطيع صفحة أن تصفها خطأً برقم هاتف قديم أو اسم مختلف. وحين تضيف إضافةٌ كتلة Organization ثانية متعارضة، يظهر التعارض عند التحقق.
- Organization: كيان النشاط (name وalternateName وurl وlogo وsameAs وaddress).
- WebSite: الموقع، وتنشره المؤسسة.
- WebPage: كل صفحة، جزء من الموقع، ولها مسار تنقّل.
- Service: تقدّمها المؤسسة، مع areaServed.
- Person: يعمل لدى المؤسسة ويكتب المقالات.
- Article: يكتبه شخص وتنشره المؤسسة.
- BreadcrumbList: موقع الصفحة في هيكل الموقع.
ما أنواع Schema الأهم لنشاط قائم على الخدمات؟
أنواع Schema الأهم لنشاط قائم على الخدمات هي Organization (أو نوع فرعي من LocalBusiness عند وجود موقع فعلي يزوره العملاء)، وWebSite، وWebPage، وService، وPerson، وArticle، وBreadcrumbList. وتصف هذه الأنواع معًا من هو النشاط، وماذا يقدّم، وأين يخدم، ومن يؤدي العمل، وكيف تنتظم صفحاته. ولا تُضف أنواعًا أخرى إلا إذا احتوت الصفحة فعلًا ذلك المحتوى.
Organization هو المرتكز. توصي Google بوضعه في الصفحة الرئيسية أو في صفحة واحدة تصف المؤسسة، ولا تشترط خصائص إلزامية، وتوصي بخصائص منها name وalternateName وurl وlogo وaddress وtelephone وsameAs. أما LocalBusiness فمناسب لموقع يزوره العملاء فعلًا، وتذكر Google أن name وaddress خاصيتاه الإلزاميتان.
وService نوع في Schema.org لخدمة تقدّمها مؤسسة، بخصائص مثل provider وserviceType وareaServed. ولا تقدّم Google نتيجة منسّقة لـService، فقيمته في وضوح الوصف لا في ميزة بحث. ويدعم ترميز Article خصائص author وdatePublished وdateModified، وتنصح Google بذكر كل كاتب على حدة واستخدام Person أو Organization بحسب الحال.
لماذا يجب أن تطابق البيانات المنظمة المحتوى الظاهر في الصفحة؟
يجب أن تطابق البيانات المنظمة المحتوى الظاهر لأن إرشادات Google العامة تشترط أن يكون الترميز تمثيلًا صادقًا لمحتوى الصفحة، وتنص على عدم ترميز محتوى لا يراه القرّاء. والترميز الذي يصف محتوى مخفيًا أو غير ذي صلة أو مضللًا قد يؤدي إلى إجراء يدوي يُسقط أهلية النتائج المنسّقة. وفي GEO يصنع الترميز غير المطابق حقائق متناقضة.
وتنص إرشادات Google أيضًا على وضع البيانات المنظمة في الصفحة التي تصفها ما لم تقل الوثائق غير ذلك، وعلى عدم ترميز محتوى غير ذي صلة أو مضلل كالمراجعات المزيفة. وتضيف Google أنها لا تضمن ظهور البيانات المنظمة في نتائج البحث حتى لو كانت صحيحة.
عمليًا، تتكرر ثلاثة أنواع من عدم التطابق: كتلة Organization تعدّد خدمات لم يعد الموقع يقدّمها، وقيمة dateModified في Article تتغير مع كل نشر رغم أن النص لم يتغير، وصفحة عربية تحمل ترميزًا إنجليزيًا منسوخًا من القالب الإنجليزي. وكل منها يخبر الأنظمة بشيء لا تقوله الصفحة الظاهرة.
هل ما زال ترميز FAQPage مفيدًا للبحث والذكاء الاصطناعي؟
لم يعد ترميز FAQPage ينتج نتيجة منسّقة في Google. فسجل تحديثات وثائق Google يذكر أن النتيجة المنسّقة للأسئلة الشائعة أُلغيت، وأنها توقفت عن الظهور اعتبارًا من 7 مايو 2026، وأنها لم تعد تظهر في نتائج بحث Google، وأُزيلت وثائقها في يونيو 2026. يبقى FAQPage نوعًا صالحًا في Schema.org، لكنه لم يعد أسلوبًا للحصول على نتيجة منسّقة في Google.
وهذا يعكس نصيحة شائعة لسنوات، وما زالت أدلة قديمة كثيرة توصي بـFAQPage لمساحة إضافية في نتائج البحث. وقبل الإلغاء كانت Google قد حصرت نتائج الأسئلة الشائعة المنسّقة منذ عام 2023 في المواقع الحكومية والصحية المعروفة وذات المرجعية.
أما ما يبقى مهمًا فهو محتوى الأسئلة الشائعة الظاهر نفسه؛ فأقسام السؤال والجواب الواضحة تفيد القارئ وتمنح أنظمة الذكاء الاصطناعي فقرات مكتفية بذاتها قابلة للاقتباس. وإن أبقيت ترميز FAQPage فيجب أن يطابق الأسئلة والأجوبة الظاهرة حرفيًا، دون توقّع ميزة بحث من Google بسببه.
كيف تعلن الصفحات العربية لغتها في البيانات المنظمة؟
تعلن الصفحات العربية لغتها في البيانات المنظمة عبر خاصية inLanguage برمز BCP 47 مثل ar، أو برمز إقليمي مثل ar-SA عند الحاجة. ويعرّف Schema.org خاصية inLanguage بأنها لغة المحتوى، ويوصي برموز IETF BCP 47. ويجب أن يستخدم الترميز العربي أيضًا الأسماء والأوصاف العربية الظاهرة في الصفحة العربية.
تنطبق inLanguage على أنواع CreativeWork، ومنها WebPage وWebSite وArticle. ضعها في عقدة WebPage لكل صفحة وفي عقد Article. ويمكن أن تحتفظ المؤسسة بالمعرّف @id نفسه في اللغتين، وفي الصفحة العربية يكون name الاسم العربي الرسمي مع الاسم اللاتيني في alternateName.
ولا تحل البيانات المنظمة محل hreflang؛ فـGoogle تستخدم وسوم hreflang لفهم النسخ المحلية من الصفحة، وتشترط أن تشير كل نسخة لغوية إلى نفسها وإلى جميع النسخ الأخرى. حافظ على اتساق الإشارتين: الصفحة المعلنة ar في الترميز هي نفسها التي يحددها hreflang بـar.
كيف تتحقق من صحة البيانات المنظمة؟
تتحقق من صحة البيانات المنظمة بأداتين لغرضين. أداة اختبار النتائج المنسّقة من Google على search.google.com/test/rich-results تفحص الأهلية لنتائج Google المنسّقة. وأداة Schema Markup Validator على validator.schema.org تفحص ترميز Schema.org عمومًا وتلخّص رسم البيانات المستخرج. وبعد النشر، تؤكد أداة فحص عنوان URL في Search Console ما وجدته Google في الصفحة الحية.
تستخرج أداة Schema Markup Validator صيغ JSON-LD وRDFa وMicrodata وتنبّه إلى أخطاء الصياغة، فهي الأداة المناسبة لأنواع مثل Service التي لا نتيجة منسّقة لها في Google. أما أداة اختبار النتائج المنسّقة فهي المناسبة لميزات Google مثل مسارات التنقّل وArticle.
يكشف التحقق أخطاء الصياغة والخصائص الناقصة، لكنه لا يتحقق من صدق المعلومة. يبقى على شخص أن يقارن القيم المستخرجة بالصفحة الظاهرة باللغتين، وأن يتأكد من أن مراجع @id تشير إلى العقد المقصودة.
- شغّل أداة اختبار النتائج المنسّقة للميزات التي تدعمها Google.
- شغّل Schema Markup Validator لفحص الرسم كاملًا.
- قارن كل قيمة مستخرجة بنص الصفحة الظاهر.
- أعد الفحص بعد تغيير القوالب وبعد تعديل المحتوى.
| نوع Schema | الغرض | الخصائص الأساسية | الصلة بـGEO |
|---|---|---|---|
| Organization | يعرّف كيان النشاط | name وalternateName وurl وlogo وaddress وtelephone وsameAs | يثبّت حقائق الكيان ويربط الملفات الخارجية |
| LocalBusiness | يصف موقعًا فعليًا يزوره العملاء | name وaddress وtelephone وgeo وopeningHoursSpecification | يحدد أين يوجد مكتب فعلًا |
| WebSite | يصف الموقع واسمه | name وalternateName وurl وpublisher | يربط اسم الموقع بالمؤسسة |
| WebPage | يصف كل صفحة | name وinLanguage وisPartOf وbreadcrumb | يعلن لغة الصفحة وموقعها في الرسم |
| Service | يصف خدمة مقدّمة | name وserviceType وprovider وareaServed | يجعل الخدمات والأسواق صريحة |
| Person | يصف الكتّاب والخبراء | name وjobTitle وworksFor وsameAs | يدعم النسبة والتأليف |
| Article | يصف المحتوى التحريري | headline وauthor وpublisher وdatePublished وdateModified وinLanguage | يوضح الكاتب وحداثة المحتوى |
| BreadcrumbList | يُظهر هيكل الموقع | itemListElement مع item وname في ListItem | يوضح علاقة الصفحات ببعضها |
الأسئلة الشائعة
هل أحتاج إلى Schema خاص للظهور في Google AI Overviews؟
لا. تقول Google إنه لا حاجة إلى تحسينات خاصة للظهور في AI Overviews أو AI Mode، ولا إلى إنشاء ترميز جديد لذلك. يجب أن تكون الصفحة مفهرسة ومؤهلة للظهور مع مقتطف. وتبقى البيانات المنظمة القياسية الدقيقة ممارسة جيدة.
هل يغني ملف llms.txt عن البيانات المنظمة؟
لا. تقول Google إن الملفات النصية للذكاء الاصطناعي ليست مطلوبة للظهور في ميزاتها. وملف llms.txt عُرف منفصل تنشره بعض المواقع، ولا يحل محل ترميز Schema.org، ولا يغني أيٌّ منهما عن محتوى ظاهر واضح. قيّم كلًا منهما على حدة.
هل يجب تكرار ترميز Organization كاملًا في كل صفحة؟
توصي Google بوضع Organization في الصفحة الرئيسية أو في صفحة واحدة تصف المؤسسة، لا في كل صفحة. ويمكن للصفحات الأخرى الإشارة إلى المؤسسة بمعرّفها @id، فيبقى تعريف واحد معتمد وتُتجنّب النسخ المتعارضة.
هل يمكن أن تضر البيانات المنظمة بالموقع؟
البيانات غير الدقيقة قد تضر. تذكر إرشادات Google أن مشكلات البيانات المنظمة قد تؤدي إلى إجراء يدوي يُسقط أهلية النتائج المنسّقة، مع تأكيدها أنه لا يؤثر في ترتيب البحث. كما ينشر الترميز المضلل معلومات خاطئة عن النشاط.
بأي لغة يُكتب اسم المؤسسة في الصفحات العربية؟
استخدم الاسم العربي الرسمي في الصفحات العربية بما يطابق النص الظاهر، وضع الاسم اللاتيني الرسمي في alternateName. وحافظ على المعرّف @id نفسه في النسختين العربية والإنجليزية لتفهم الأنظمة أنهما تصفان مؤسسة واحدة.
كيف تطبّق Dfeelings البيانات المنظمة
تقع البيانات المنظمة في المرحلة 03 الأساس التقني من إطار Dfeelings للـGEO، وتعتمد على سجل الكيان من المرحلة 02 الكيان. وتبني Dfeelings المواقع داخليًا؛ فموقعها نفسه مبني بـNext.js ومعروض من الخادم مع بيانات JSON-LD المنظمة وhreflang ثنائي اللغة وملف llms.txt، فيُولَّد الترميز من المصدر نفسه الذي يولّد المحتوى الظاهر بالعربية والإنجليزية. وتخدم Dfeelings من عمّان أنشطة في السعودية والأردن، وتتحقق من مطابقة الترميز للصفحات الظاهرة باللغتين. ولا يستطيع أحد ضمان أن يستشهد نظام ذكاء اصطناعي بأي نشاط تجاري.
مصادر رسمية
- Google Search Central: ميزات الذكاء الاصطناعي وموقعك
- Google Search Central: مقدمة إلى ترميز البيانات المنظمة
- Google Search Central: الإرشادات العامة للبيانات المنظمة
- Google Search Central: آخر تحديثات الوثائق (إلغاء نتيجة الأسئلة الشائعة)
- Google Search Central: بيانات Organization المنظمة
- Google Search Central: بيانات Article المنظمة
- Google Search Central: بيانات مسار التنقّل المنظمة
- Google Search Central: النسخ المحلية من صفحتك
- Schema.org: Schema Markup Validator
- Schema.org: inLanguage
- Schema.org: Service
- W3C: JSON-LD 1.1