مخطط ImageObject

الخلاصة — يتيح ImageObject وصف الصورة لمحركات البحث بأكثر من عنوانها على الويب، مثل مالكها وطريقة ترخيصها والتعليق المصاحب لها. ولا تحتاج إليه في معظم الحالات؛ فعندما يطلب مخطط صورة، يكفي رابط URL عادي. استخدم ImageObject الكامل عندما تريد إرفاق هذه المعلومات الإضافية، وغالبًا بهدف التأهل لشارة “Licensable” في صور Google.

ما ImageObject؟

عندما تضيف بيانات منظمة إلى صفحة، فأنت تصف محتواها كي تفهمه محركات البحث. وImageObject هو نوع schema.org الذي يصف الصورة نفسها، لا كلمات الصفحة، في صورة بيانات يمكن للآلة قراءتها.

إليك ما تتجاوزه معظم الأدلة: نادرًا ما يُستخدم ImageObject مستقلًا. فوظيفته الحقيقية أن يكون قيمة لخاصية الصورة في نوع آخر. وعندما تضيف ترميزًا لمنتج أو مقال أو وصفة، يضم كل نوع منها موضعًا للصورة، ويمكنك ملؤه بطريقتين:

• برابط URL عادي — أي عنوان الصورة على الويب فحسب، وهو كل ما تحتاج إليه غالبًا.
• بكائن ImageObject كامل — عندما تريد توضيح ما يتجاوز “هذا هو الملف”، مثل هوية المصور أو طريقة ترخيص الصورة.

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

متى تحتاج فعلًا إلى النسخة الكاملة؟

تنتقل من رابط URL عادي إلى ImageObject كامل عندما تريد إرفاق بيانات وصفية عن الصورة نفسها، وغالبًا لأغراض الترخيص. فإذا كنت مصورًا أو وكالة صور مخزنة أو ناشرًا يريد أن تعرض صوره شارة Licensable في صور Google، وهي تسمية صغيرة تصل إلى موضع شراء الترخيص، فهذه الشارة هي السبب الرئيسي لاستخدام ImageObject كامل.

الخاصية الوحيدة التي تتيح تلك الشارة هي license، وهي رابط إلى شروط الترخيص. ويمكنك إضافة معلومات أخرى، مثل منشئ الصورة وسطر نسبها وإشعار حقوق النشر، لكن license هي الخاصية الحاسمة للأهلية.

أكثر ما يخطئ فيه الناس

لا يمنح ImageObject نتيجة منسقة مستقلة. فهو لا ينتج “بطاقة صورة”. إما أن يدعم أهلية نوع آخر، مثل النتيجة المنسقة لوصفة، أو يتيح شارة Licensable المنفصلة؛ ولا يفعل أكثر من ذلك.

وتعامل بحذر شديد مع أي دليل يعدك بنسبة محددة للزيارات أو النقرات بعد إضافة مخطط الصور، مثل “+30% clicks!”. لقد تتبعت مصادر هذه الأرقام، والإجابة الصادقة أنها بلا مصدر؛ فهي مختلقة. يستحق المخطط التنفيذ، لكن ليس بسبب نسبة مصطنعة.

هل تريد الشرح المتعمق، بما فيه الخصائص الدقيقة وطريقة عمل شارة Licensable وسبب عدم تحكم صور Recipe في الصورة المصغرة وخرافة صورة Product؟ انتقل إلى علامة التبويب Advanced.

الخلاصة — يُستخدم ImageObject (Thing > CreativeWork > MediaObject > ImageObject) أساسًا بوصفه نوع قيمة متداخلًا، لا مخطط وجهة مستقلًا. فهو قيمة Product.image وArticle.image وRecipe.image وOrganization.logo وWebPage.primaryImageOfPage. يكفي رابط URL عادي عندما لا تحتاج إلى بيانات وصفية؛ وانتقل إلى الكائن الكامل للترخيص ونسب العمل. تتطلب وصفة شارة Licensable وجود contentUrl مع واحدة على الأقل من creator أو creditText أو copyrightNotice أو license، لكن خاصية license تحديدًا هي التي تمنح أهلية الشارة. استخدم contentUrl بدل url لأن Google تصفه بأنه أدق. وهناك حقيقتان يغفل عنهما كثيرون: خاصية image في Recipe مطلوبة لكنها لا تؤثر في الصورة المصغرة لنتيجة البحث النصية، وفق توضيح Google في يونيو 2025، كما أن image في Product ليست ضمن قوائم Google الرسمية للخصائص المطلوبة أو الموصى بها. ولا يُعد ذلك عامل ترتيب؛ بل له الأثر غير المباشر نفسه لسائر المخططات.

موضع ImageObject في التسلسل وكيف يُستخدم فعليًا

يقع ImageObject في schema.org ضمن التسلسل Thing > CreativeWork > MediaObject > ImageObject. ويشرح هذا الأصل خصائصه كلها: فهو يرث حقول الترخيص ونسب العمل من CreativeWork، ومنها license وacquireLicensePage وcreditText وcopyrightNotice وcreator وauthor، ويرث حقول الملف من MediaObject، ومنها contentUrl وencodingFormat وheight وwidth وcontentSize وuploadDate، إلى جانب خصائص تخصه مثل caption وexifData.

يُستخدم بطريقتين:

• مستقلًا — في صفحة غرضها الكامل وصف صورة واحدة، مثل صفحة هبوط لترخيص صورة. ويكون السبب في ذلك غالبًا شارة Licensable.
• متداخلًا — بوصفه قيمة لخاصية image أو logo أو primaryImageOfPage في نوع آخر. وهذه هي الحالة الأكثر شيوعًا بفارق كبير؛ لذلك من الأدق تقديم ImageObject بوصفه نوعًا مساعدًا تعتمد عليه الأنواع الفرعية من CreativeWork من دون ضجيج، لا نوع مخطط ترسل الناس إليه. وهو قريب موضوعيًا من فئة مخططات الأعمال الإبداعية؛ إذ تعتمد Article وRecipe وVideoObject على ImageObject عبر خصائص image من دون أن تجعله محورًا لها.

الفكرة الأساسية هي أن schema.org وGoogle يقبلان معًا “رابط URL أو ImageObject موصوفًا بالكامل” لقيمة خاصية image. فسلسلة URL مجردة قيمة صالحة تمامًا للصورة، ولا تتحمل تكلفة الكائن الكامل إلا عندما تكون لديك بيانات وصفية جديرة بالإرفاق.

الخصائص الأساسية

contentUrl أم url؟ استخدم contentUrl

تشير الخاصيتان إلى ملف الصورة، لكن Google تحدد بوضوح أيهما تفضل. فوفق وثائق البيانات الوصفية للصور، تستخدم Google contentUrl “to determine which image the photo metadata applies to.” (ترجمة) «لتحديد الصورة التي تنطبق عليها البيانات الوصفية للصورة». وعن الاختيار بينهما تقول: “While the url property is not as precise and we recommend you use contentUrl instead, existing markup may still use url.” (ترجمة) «خاصية url أقل دقة، ونوصي باستخدام contentUrl بدلًا منها، مع بقاء الترميز الحالي الذي يستخدم url مقبولًا». وبعبارة عملية، تحدد contentUrl بدقة أي صورة تصفها البيانات الوصفية، أما url فهي خيار قديم أقل تحديدًا لا يزال يعمل لكنه لا ينبغي أن يكون الخيار الافتراضي.

license وacquireLicensePage: خاصيتا Licensable المتكاملتان

لهذا الجزء فائدة مرئية. ترتبط license بصفحة تشرح شروط ترخيص الصورة، بينما ترتبط acquireLicensePage بالموضع الذي يستطيع منه الشخص شراء الترخيص فعليًا. تتكاملان طبيعيًا؛ فالأولى تقول “هذه هي الشروط” والثانية “من هنا تشتري الترخيص”، لكن وزنهما ليس متساويًا، كما يوضح القسم التالي.

creator وcreditText وcopyrightNotice: ثلاثية نسب العمل

تنسب هذه الخصائص الصورة إلى صاحبها. وهناك تفصيل مهم: لا يلزم أن يكون creator شخصًا. تقول وثائق Google: “This is usually the photographer, but it may be a company or organization (if appropriate).” (ترجمة) «يكون عادة المصور، لكنه قد يكون شركة أو مؤسسة عند الاقتضاء».

caption وexifData وheight/width وthumbnail

هذه بيانات وصفية وتقنية مفيدة وقد تظهر أحيانًا، لكن أيًا منها لا يتيح ميزة بحث بمفرده.

التأهل لشارة Licensable

هذه هي الصيغة الدقيقة الوحيدة التي تستحق الحفظ، لأن متطلبها دقيق.

البنية المطلوبة: تحتاج إلى contentUrl مع واحدة على الأقل من creator أو creditText أو copyrightNotice أو license. تقول وثائق Google: “In addition to contentUrl, you must include one of the following properties: creator, creditText, copyrightNotice, license. Once you include one of these properties, the other three properties become recommended in the Rich Results Test.” (ترجمة) «إلى جانب contentUrl، يجب تضمين إحدى الخصائص الآتية: creator أو creditText أو copyrightNotice أو license. وبعد تضمين إحداها تصبح الخصائص الثلاث الأخرى موصى بها في اختبار النتائج المنسقة».

لكن للشارة نفسها شرط أكثر صرامة. فاجتياز التحقق لا يعني التأهل للشارة. تقول Google: “If you’re using structured data to specify an image, you must include the license property for your image to be eligible to be shown with the Licensable badge.” (ترجمة) «إذا استخدمت البيانات المنظمة لتحديد صورة، فيجب تضمين خاصية license كي تكون الصورة مؤهلة للظهور مع شارة Licensable». لذلك قد يجتاز creator أو creditText وحده التحقق، لكنك لن تحصل على الشارة؛ فخاصية license هي المفتاح. وتضيف Google: “We recommend that you also add the acquireLicensePage property if you have that information.” (ترجمة) «نوصي أيضًا بإضافة خاصية acquireLicensePage إذا كانت هذه المعلومات متاحة».

البيانات المنظمة ليست المسار الوحيد. فالبيانات الوصفية IPTC المضمّنة في الصورة مسار صالح بالقدر نفسه لنيل الأهلية ذاتها، ولا تتطلب ترميز schema.org إطلاقًا. لكن إذا استخدمت المسارين وتعارضا، توضح Google قاعدة الترجيح: “If you choose to use both IPTC photo metadata and structured data, and if any information conflicts between the two, Google will use the structured data information.” (ترجمة) «إذا اخترت استخدام بيانات IPTC الوصفية للصور والبيانات المنظمة معًا وحدث تعارض بينهما، فستستخدم Google معلومات البيانات المنظمة». وهذا عكس ما يفترضه كثيرون من أن البيانات المضمّنة في الملف هي المصدر الأكثر “حجية”.

هناك سياسة توقع البعض في الخطأ: يجب أن يكون رابط الصورة قابلًا للوصول. تنص سياسات البيانات المنظمة لدى Google على أن “All image URLs specified in structured data must be crawlable and indexable” (ترجمة) «يجب أن تكون جميع روابط الصور المحددة في البيانات المنظمة قابلة للزحف والفهرسة». فإذا حجبت مضيف الصور في robots.txt فستفشل البنية كلها من دون تنبيه واضح.

ImageObject داخل أنواع محددة

Recipe: مطلوب، وتوضيح يونيو 2025

في Recipe، تكون image مطلوبة، ولها إرشادات فعلية: يجب أن تكون قابلة للزحف والفهرسة وأن تمثل الطبق، كما تقول Google: “recommend[s] providing multiple high-resolution images (minimum of 50K pixels when multiplying width and height) with the following aspect ratios: 16x9, 4x3, and 1x1.” (ترجمة) «نوصي بتوفير عدة صور عالية الدقة، بحد أدنى 50 ألف بكسل عند ضرب العرض في الارتفاع، وبنسب أبعاد 16x9 و4x3 و1x1».

وهنا التفصيل المخالف للتوقع الذي لم تلحق به معظم الأدلة. فمنذ تحديث للوثائق في يونيو 2025، تقول Google بوضوح: “Specifying the image property in Recipe markup has no impact on the image chosen for a text result image.” (ترجمة) «تحديد خاصية image في ترميز Recipe لا يؤثر في الصورة المختارة للنتيجة النصية». بعبارة أخرى، تتحكم image في Recipe في أهلية النتيجة المنسقة للوصفة، لا في الصورة المصغرة بجانب النتيجة العادية ذات الرابط الأزرق؛ فهذا نظام منفصل تمامًا، كما سيأتي. وقد أورد باري شوارتز هذا التغيير في Search Engine Land بتاريخ 5 يونيو 2025.

Product: ليست مطلوبة رسميًا، بعكس الخرافة الشائعة

يزعم معظم الناس أن الصور “مطلوبة” لنتائج Product المنسقة، لكنها ليست كذلك وفق قوائم Google الموثقة على الأقل. فالخصائص المطلوبة رسميًا في وثائق مقتطفات المنتجات هي name مع واحدة من review أو aggregateRating أو offers، أما قائمة الخصائص الموصى بها فهي aggregateRating وoffers وreview. ولا تظهر خاصية image إلا في الأمثلة التطبيقية، لا في جدولي المطلوب والموصى به. أضف صور المنتجات مع ذلك، لأن بطاقة بلا صورة تكون أضعف في التحويل، لكن اعلم أن هذه حجة تتعلق بتجربة المستخدم وShopping، لا بمتطلب موثق للمخطط. ولا تخلط بينها وبين قواعد دقة صور المنتجات المنفصلة والأشد صرامة في Merchant Center؛ فهذا نظام آخر مستقل تمامًا عن ImageObject.

Article وOrganization

في Article، تكون image خاصية موصى بها تدعم أهلية Article، لكنها لا تنتج بطاقة صورة مستقلة. أما Organization.logo فللشعار متطلبات منفصلة خاصة به، وهو الصورة التي قد تستخدمها Google في مواضع مثل لوحة المعلومات وبعض أشكال العلامة التجارية في النتائج المنسقة. يستحق الشعار الترميز، لكن هذه مهمة تخص الشعار، لا ترخيص ImageObject عمومًا.

التحكم في الصورة المصغرة في Search وDiscover

إذا أردت فعلًا التأثير في الصورة التي تعرضها Google كمعاينة لصفحتك، فهذه آلية مختلفة عما سبق، وقد أوضحتها Google في تحديث للوثائق في مارس 2026. تقول وثيقة أفضل ممارسات SEO للصور: “Google’s selection of an image preview is completely automated and takes into account a number of different sources to select which image on a given page is shown on Google.” (ترجمة) «اختيار Google لمعاينة الصورة مؤتمت بالكامل، ويراعي عددًا من المصادر المختلفة لاختيار الصورة التي تظهر من صفحة معينة على Google».

تغذي هذا الاختيار ثلاث إشارات متوازية يمكن استخدامها معًا:

1. خاصية primaryImageOfPage في schema.org على WebPage.
2. خاصية image المرفقة عبر mainEntity أو mainEntityOfPage.
3. وسم البيانات الوصفية og:image.

وتقدم Google الإرشاد نفسه للإشارات الثلاث: “Choose an image that’s relevant and representative of the page. Avoid using a generic image (for example, your site logo) or an image with text in the schema.org markup or og:image meta tag.” (ترجمة) «اختر صورة وثيقة الصلة بالصفحة وتمثلها، وتجنب الصور العامة، مثل شعار موقعك، والصور التي تحتوي نصًا في ترميز schema.org أو وسم og:image». وقد غطى مات جي. ساذرن التحديث في Search Engine Journal بتاريخ 2 مارس 2026، موضحًا النقطة الأساسية: يُعتد بكل من ترميز المخطط وog:image، فهما مدخلان متوازيان لا خياران متنافيان.

C2PA و”About this image”: موضوع مجاور لا يندرج ضمن ImageObject

هناك تقنية مجاورة مستقبلية تستحق الذكر، مع توضيح انفصالها عن ترخيص ImageObject: بيانات منشأ المحتوى C2PA، وهي مضمّنة في ملف الصورة وليست جزءًا من schema.org. تقول Google: “If an image contains C2PA metadata, Google can extract those details and may show information in the ‘About this image’ feature, such as how the image was created or if it was edited with AI tools.” (ترجمة) «إذا احتوت الصورة على بيانات C2PA الوصفية، فيمكن لـGoogle استخراجها وقد تعرض معلومات في ميزة “About this image”، مثل كيفية إنشاء الصورة أو ما إذا عُدلت بأدوات الذكاء الاصطناعي». إنها إشارة إلى المنشأ في السياق نفسه الذي تظهر فيه معلومات الترخيص، لكنها تقيم في بيان داخل الملف، لا في ترميز ImageObject؛ فلا تخلط بينهما.

هل ImageObject عامل ترتيب؟

لا؛ فله الأثر غير المباشر نفسه الذي لسائر البيانات المنظمة. ويتمثل موقف Google المستقر، كما عبّر عنه غاري إيليس وجون مولر، في أن المخطط يساعد المحركات على فهم المحتوى وقد يمنح أهلية لبعض الميزات، لكنه ليس مدخلًا مباشرًا للترتيب. وفوائد ImageObject محددة وضيقة: شارة Licensable عبر license، وأهلية الأنواع الأصل مثل Recipe للنتائج المنسقة عبر image صالحة، وإشارة لاختيار الصورة المصغرة عبر primaryImageOfPage. ولا يعني أي منها “ترتيبًا أعلى”. كما تنص إرشادات Google لاستكشاف الأخطاء على أن ظهور كتلة بيانات وصفية صحيحة تمامًا للصورة غير مضمون. ولا تثبت المصادر المراجعة أثرًا لـImageObject في الاستشهاد داخل إجابات الذكاء الاصطناعي؛ فلم أجد مصدرًا يبين أنه يزيد فرصة الاستشهاد بمحتواك. ومن يبيعك نسبة محددة لزيادة الزيارات بفضل مخطط الصور يستشهد برقم لا أصل له.

أخطاء شائعة

• استخدام url بدل contentUrl. تعمل الخاصيتان، لكن Google تفضل contentUrl لأنها أدق.
• نسيان license تحديدًا. تجتاز خصائص نسب العمل الثلاث الأخرى التحقق، لكنها لا تتيح شارة Licensable.
• افتراض أن image في Recipe تتحكم في الصورة المصغرة للنتيجة النصية. لا تفعل ذلك، وفق توضيح Google في يونيو 2025؛ بل تؤثر فقط في أهلية النتيجة المنسقة للوصفة.
• افتراض أن صور Product مطلوبة رسميًا في المخطط. ليست ضمن قوائم Google الموثقة، مع أنك ينبغي أن تضيفها لتجربة المستخدم وShopping.
• حجب رابط الصورة. يؤدي منع مضيف الصورة في robots.txt أو تطبيق noindex عليه إلى الإخفاق في متطلب Google الخاص بإمكان الزحف والفهرسة.
• تكرار إحصاءات أداء مختلقة. تستشهد أدلة منافسة كثيرة بنسبة “+X% CTR/traffic” بلا إحالة، ولا يرجع أي منها إلى مصدر.

موضع هذا الموضوع

ImageObject شرح متعمق ضمن المجموعة الفرعية للبيانات المنظمة إلى جانب مقالات أنواع المخططات الشقيقة، ومنها article-schema وrecipe-schema وproduct-schema وvideoobject-schema وorganization-schema. وهو موضوعيًا النوع المساعد الذي تعتمد عليه عائلة مخططات الأعمال الإبداعية، ويقع تحت محور البيانات المنظمة لـSEO. أما النص البديل والصيغ وخرائط مواقع الصور والتحميل الكسول فتندرج ضمن موضوع مستقل هو SEO للصور؛ ويركز هذا المقال تحديدًا على كيفية وصف الصورة كبيانات، وهو ما تعتمد عليه تلك الموضوعات الأخرى من دون تصريح.

ملخص الذكاء الاصطناعي

خلاصة مكثفة للنسخة المتقدمة:

• ImageObject نوع قيمة متداخل، وليس نتيجة منسقة مستقلة. تسلسله Thing > CreativeWork > MediaObject > ImageObject، وهو قيمة Product.image وArticle.image وRecipe.image وOrganization.logo وWebPage.primaryImageOfPage. رابط URL العادي قيمة صالحة لـimage؛ ولا تنتقل إلى الكائن الكامل إلا إذا كانت لديك بيانات وصفية تريد إرفاقها.
• صيغة شارة Licensable: يلزم contentUrl مع واحدة على الأقل من creator أو creditText أو copyrightNotice أو license لاجتياز التحقق، لكن خاصية license تحديدًا هي التي تمنح أهلية الشارة. أضف acquireLicensePage أيضًا إن كانت لديك.
• استخدم contentUrl بدل url؛ تقول Google إن contentUrl أدق في تحديد الصورة التي تصفها البيانات، بينما url بديل قديم.
• IPTC مسار بديل مكافئ للأهلية نفسها، لكن إذا تعارضت IPTC والبيانات المنظمة، تستخدم Google البيانات المنظمة.
• Recipe: خاصية image مطلوبة، بحد أدنى 50 ألف بكسل مربع ونسب 16x9 و4x3 و1x1، لكنها لا تؤثر في الصورة المصغرة للنتيجة النصية، وفق توضيح Google في يونيو 2025.
• Product: ليست image ضمن القوائم الرسمية للخصائص المطلوبة أو الموصى بها لدى Google. أضفها لتجربة المستخدم وShopping، لا بوصفها متطلبًا موثقًا للمخطط.
• التحكم في الصورة المصغرة آلية منفصلة أوضحت في مارس 2026، وتعتمد primaryImageOfPage وصورة الكيان الرئيسي وog:image بوصفها ثلاث إشارات متوازية.
• C2PA تغذي ميزة “About this image” بمعلومات المنشأ، ومنها تعديلات الذكاء الاصطناعي، لكنها تقيم في الملف لا في ترميز ImageObject؛ فلا تخلط بينهما.
• ليس عامل ترتيب؛ فتأثيره غير مباشر في أحسن الأحوال، والظهور نفسه غير مضمون، ولا يثبت أي مصدر أثرًا في الاستشهاد بالذكاء الاصطناعي. تجاهل إحصاءات “+X%” المختلقة.

الوثائق الرسمية

وثائق المصادر الأولية من Google وschema.org.

Google

• Image Metadata (Google Images SEO) — الوثيقة الأساسية لترخيص ImageObject: الخصائص المطلوبة، والمفاضلة بين contentUrl وurl، وقاعدة license لشارة Licensable، والتعارض بين IPTC والبيانات المنظمة، وC2PA.
• Structured Data General Guidelines — متطلبات إمكان الزحف والفهرسة وملاءمة المحتوى التي تنطبق على أي صورة في البيانات المنظمة.
• Recipe structured data — اشتراط image، وإرشادات الحجم ونسب الأبعاد، وتوضيح عدم تأثيرها في صورة النتيجة النصية.
• Product snippet structured data — القائمتان الرسميتان للخصائص المطلوبة والموصى بها، مع ملاحظة أن image ليست في أي منهما.
• Image SEO best practices — استخدام primaryImageOfPage وصورة الكيان الرئيسي وog:image إشارات لاختيار الصورة المصغرة.

schema.org

• ImageObject — تعريف النوع وتسلسله (Thing > CreativeWork > MediaObject > ImageObject) وقائمة خصائصه الكاملة.
• contentUrl · license · acquireLicensePage — الخصائص التي تعتمد عليها إرشادات Google للترخيص.

اقتباسات من المصدر

تصريحات موثقة من Google، ويقود كل رابط مباشرة إلى المقطع المقتبس في صفحة المصدر.

Google: contentUrl مقابل url

• “Google uses contentUrl to determine which image the photo metadata applies to.” (ترجمة) «تستخدم Google contentUrl لتحديد الصورة التي تنطبق عليها بيانات الصورة الوصفية». — وثائق Google Search Central. الانتقال إلى الاقتباس
• “While the url property is not as precise and we recommend you use contentUrl instead, existing markup may still use url.” (ترجمة) «خاصية url أقل دقة، ونوصي باستخدام contentUrl بدلًا منها، مع بقاء الترميز الحالي الذي يستخدم url مقبولًا». الانتقال إلى الاقتباس

Google: البنية المطلوبة ومفتاح شارة Licensable

• “In addition to contentUrl, you must include one of the following properties: creator, creditText, copyrightNotice, license.” (ترجمة) «إلى جانب contentUrl يجب تضمين إحدى الخصائص الآتية: creator أو creditText أو copyrightNotice أو license». الانتقال إلى الاقتباس
• “If you’re using structured data to specify an image, you must include the license property for your image to be eligible to be shown with the Licensable badge.” (ترجمة) «إذا استخدمت البيانات المنظمة لتحديد صورة، فيجب تضمين license كي تتأهل الصورة للظهور مع شارة Licensable». الانتقال إلى الاقتباس
• “We recommend that you also add the acquireLicensePage property if you have that information.” (ترجمة) «نوصي أيضًا بإضافة acquireLicensePage إذا كانت هذه المعلومات متاحة». الانتقال إلى الاقتباس

Google: IPTC مقابل البيانات المنظمة، ومنشئ الصورة

• “If you choose to use both IPTC photo metadata and structured data, and if any information conflicts between the two, Google will use the structured data information.” (ترجمة) «إذا استخدمت بيانات IPTC الوصفية للصور والبيانات المنظمة معًا وحدث تعارض، فستستخدم Google معلومات البيانات المنظمة». الانتقال إلى الاقتباس
• عن creator: “This is usually the photographer, but it may be a company or organization (if appropriate).” (ترجمة) «يكون عادة المصور، لكنه قد يكون شركة أو مؤسسة عند الاقتضاء». الانتقال إلى الاقتباس

Google: سياسة الصور وRecipe واختيار الصورة المصغرة

• “All image URLs specified in structured data must be crawlable and indexable.” (ترجمة) «يجب أن تكون جميع روابط الصور المحددة في البيانات المنظمة قابلة للزحف والفهرسة». الانتقال إلى الاقتباس
• “Specifying the image property in Recipe markup has no impact on the image chosen for a text result image.” (ترجمة) «تحديد خاصية image في ترميز Recipe لا يؤثر في الصورة المختارة للنتيجة النصية». الانتقال إلى الاقتباس
• “Specify the schema.org primaryImageOfPage property with a URL or ImageObject.” (ترجمة) «حدد خاصية primaryImageOfPage في schema.org باستخدام URL أو ImageObject». الانتقال إلى الاقتباس

رابط URL عادي أم ImageObject كامل؟ وما الميزة التي تسعى إليها أصلًا؟

السؤال العملي الأكثر شيوعًا عن ImageObject ليس “كيف أكتبه؟”، بل “هل أحتاج إلى الكائن الكامل أصلًا، وإن احتجت إليه فلماذا؟” أجب عن الأسئلة التالية للصورة التي ترمّزها.

ImageObject: ورقة مرجعية سريعة

مستقل أم متداخل؟

صيغة شارة Licensable

contentUrl مقابل url

خاصية الصورة حسب النوع الأصل

حقائق سريعة

• التسلسل: Thing > CreativeWork > MediaObject > ImageObject.
• ليس عامل ترتيب؛ فهو يمنح الأهلية لا ترتيبًا أعلى.
• IPTC مسار مكافئ للشارة، وإذا وقع تعارض تنتصر البيانات المنظمة.
• يجب أن تكون روابط الصور قابلة للزحف والفهرسة وإلا يفشل الترميز من دون تنبيه واضح.
• التحكم في الصورة المصغرة = primaryImageOfPage أو صورة الكيان الرئيسي أو og:image، وهي آلية منفصلة أوضحت في مارس 2026.
• C2PA لا تساوي ImageObject؛ فهي بيانات منشأ مضمّنة في الملف لميزة “About this image”.

أنماط سيئة: أكثر أخطاء ImageObject التي أراها

إضافة creator أو creditText وتوقع شارة Licensable. هذا أكثر إخفاقات التنفيذ قربًا من النجاح. تجتاز هاتان الخاصيتان التحقق، لكن الشارة مشروطة بخاصية license تحديدًا. فنسب الصورة بلا رابط ترخيص لا يمنحك ميزة مرئية.

استخدام ImageObject كامل حين يكفي رابط URL. إذا لم تكن لديك بيانات وصفية لإرفاقها، فرابط URL المجرد هو القيمة الصحيحة لخاصية image؛ إذ يقبله كل من schema.org وGoogle. ويؤدي تغليف كل صورة في كائن كامل إلى زيادة مواضع الخطأ فحسب.

استخدام url لأن أداة إنشاء أخرجتها. لا تزال أدوات كثيرة تخرج url. وهي تعمل، لكن Google تفضل contentUrl لأنها أدق. استخدم contentUrl في الترميز الجديد.

الاعتقاد بأن image في Recipe تحدد الصورة المصغرة للبحث. هي مطلوبة للنتيجة المنسقة للوصفة، لكن Google تقول صراحة إنها لا تؤثر في الصورة المصغرة للنتيجة النصية. وإذا أردت التأثير في تلك الصورة فهذه مهمة منفصلة تستخدم primaryImageOfPage أو og:image.

اعتبار صور Product حقلًا مطلوبًا في المخطط. ليست ضمن قوائم Google الموثقة للخصائص المطلوبة أو الموصى بها. أضفها للتحويل وShopping، لكن لا تستشهد بكونها “مطلوبة للمخطط”، ولا تخلط بينها وبين قواعد دقة الصور المنفصلة في Merchant Center.

حجب مضيف الصور. يخفق رابط صورة محظور في robots.txt أو مطبق عليه noindex في متطلب إمكان الزحف والفهرسة. وقد يكون الترميز مثاليًا مع ذلك ولا ينتج شيئًا.

تكرار إحصاءات نسبية مختلقة. لا يستند قول مثل “يرفع مخطط ImageObject معدل النقر 30%” إلى مصدر. يستحق المخطط التنفيذ لما يقدمه فعلًا من أهلية وفهم، لا بسبب رقم مصنوع.

الخلط بين منشأ C2PA وترخيص ImageObject. تأتي معلومات منشأ الذكاء الاصطناعي في “About this image” من بيانات C2PA داخل الملف، لا من المخطط. إنهما نظامان مختلفان يظهران على السطح نفسه.

أمثلة على التنفيذ

يغطي نمطان كل الحالات تقريبًا: صورة ترخيص مستقلة، وImageObject متداخل داخل نوع أصل.

1. صورة مستقلة لترخيص الصور، بهدف التأهل لشارة Licensable

خاصية license هي التي تمنح أهلية الشارة، بينما تكملها acquireLicensePage وcreator وcreditText وcopyrightNotice.

{
  "@context": "https://schema.org/",
  "@type": "ImageObject",
  "contentUrl": "https://example.com/photos/harbor-at-dawn.jpg",
  "license": "https://example.com/licenses/standard/",
  "acquireLicensePage": "https://example.com/photos/harbor-at-dawn/buy/",
  "creator": {
    "@type": "Person",
    "name": "Alex Rivera"
  },
  "creditText": "Alex Rivera / Example Studio",
  "copyrightNotice": "© 2026 Example Studio",
  "caption": "The harbor at dawn, long exposure",
  "width": 2400,
  "height": 1600
}

2. ImageObject متداخل داخل Product

هنا يكون ImageObject هو قيمة Product.image. ولاحظ أن image ليست خاصية مطلوبة رسميًا في Product؛ فهذا ترقية لإرفاق البيانات الوصفية بدل رابط URL عادي.

{
  "@context": "https://schema.org/",
  "@type": "Product",
  "name": "Trailhead 30L Backpack",
  "image": {
    "@type": "ImageObject",
    "contentUrl": "https://example.com/products/trailhead-30l.jpg",
    "license": "https://example.com/licenses/product-photography/",
    "creditText": "Example Gear Co."
  },
  "offers": {
    "@type": "Offer",
    "price": "129.00",
    "priceCurrency": "USD",
    "availability": "https://schema.org/InStock"
  }
}

3. متى يكون رابط URL العادي هو الإجابة الصحيحة؟

إذا لم تكن لديك بيانات وصفية لإرفاقها، فلا تعقّد التنفيذ؛ فسلسلة URL مجردة قيمة صالحة لـimage:

{
  "@context": "https://schema.org/",
  "@type": "Product",
  "name": "Trailhead 30L Backpack",
  "image": "https://example.com/products/trailhead-30l.jpg",
  "offers": {
    "@type": "Offer",
    "price": "129.00",
    "priceCurrency": "USD",
    "availability": "https://schema.org/InStock"
  }
}

تحقق من صحة أي من هذه الأمثلة في اختبار النتائج المنسقة وأداة التحقق من schema.org قبل النشر.

أدوات إنشاء ترميز ImageObject وفحصه

افحصه باستخدام أداة التحقق من ترميز المخطط: ألصق JSON-LD، أو صفحة HTML كاملة، أو اجلب رابطًا مباشرًا، فتكتشف الأداة كتلة ImageObject سواء كانت مستقلة أم متداخلة داخل Product أو Article أو Recipe، وتضع إشارات إلى المشكلات بحسب شدتها. وهي أسرع طريقة لفحص الأنماط الدقيقة في تبويب الأمثلة: هل تميز contentUrl من url؟ وهل license موجودة، لا مجرد creator أو creditText أو copyrightNotice؟ وهل تُحلل Product.image المتداخلة على أنها ImageObject وليست سلسلة مجردة عندما تقصد إرفاق بيانات وصفية؟

ثم أكد الأهلية باستخدام أداة فحص أهلية النتائج المنسقة: لا يعني التحقق من JSON-LD سليم أن الصفحة مؤهلة لميزة معينة. شغّل الرابط في هذه الأداة لمعرفة ما إذا كان النوع الأصل، مثل Recipe أو Product، يبلغ فعلًا عن أهلية لنتيجته المنسقة. يفيد ذلك لأن image في Product ليست خاصية مطلوبة رسميًا، وقد تبقى المفقودة أو المشوهة خارج قوائم Google المطلوبة والموصى بها من دون أن يفشل التحقق.

أداة خارجية: اختبار النتائج المنسقة من Google: هذا هو المصدر الذي تحيل إليه Google نفسها لمتطلبات شارة Licensable المقتبسة في المقال. استخدمه فحصًا ثانيًا لأهلية الشارة تحديدًا، لأنها أشد من مجرد اجتياز التحقق الأساسي لـJSON-LD؛ إذ تحتاج إلى license، لا واحدة من خصائص نسب العمل الثلاث الأخرى فحسب.

اختبارات التحقق: هل أصبح تعديل ImageObject نافذًا فعلًا؟

إثبات أن تعديلًا محددًا في ImageObject نُشر بصورة صحيحة، لا أنه يبدو صحيحًا في المصدر فقط.

الاختبار 1: تحليل JSON-LD بلا أخطاء

• الاختبار — ألصق JSON-LD للصفحة، أو اجلب الرابط المباشر، في أداة التحقق من ترميز المخطط.
• النتيجة المتوقعة — تُكتشف كتلة ImageObject، مستقلة كانت أم متداخلة، بلا أخطاء صياغة أو تحليل، وتشير contentUrl إلى الحقل المقصود.
• تفسير الإخفاق — يعني فشل التحليل عادة خللًا في القالب، مثل كائن متداخل مشوه في موضع Product.image كان ينبغي أن يحمل ImageObject لكنه صار JSON مكسورًا، أو سلسلة شاردة في موضع يتوقع كائنًا.
• نافذة المراقبة — فورية.
• سبب التراجع — إذا عجزت الأداة عن اكتشاف ImageObject بعد نشر قالب، فالترميز لا يُعرض؛ تراجع عن التغيير.

الاختبار 2: اجتياز التحقق لشارة Licensable، مع فحص الشرط الأشد

• الاختبار — شغّل الرابط نفسه في أداة التحقق من ترميز المخطط أو اختبار النتائج المنسقة من Google، وابحث تحديدًا عن contentUrl مع واحدة على الأقل من creator أو creditText أو copyrightNotice أو license.
• النتيجة المتوقعة — تجتاز كتلة بيانات الصورة الوصفية التحقق بلا أخطاء في الخصائص المطلوبة.
• تفسير إخفاق “التحقق ناجح لكن لا شارة” — لا يعني اجتياز التحقق أهلية الشارة. فإذا أضفت creator أو creditText من دون license، ستجتاز الكتلة التحقق ولن تعرض شارة Licensable أبدًا؛ فوثائق Google صريحة في أن license تحديدًا هي المفتاح. لا تعتبر نجاح التحقق تأكيدًا لظهور الشارة.
• نافذة المراقبة — التحقق فوري، لكن ظهور الشارة نفسها في صور Google قد يستغرق وقتًا بعد زحف ناجح، لذا انتظر بضعة أسابيع قبل استنتاج غيابها.
• سبب التراجع — إذا كانت license موجودة ونجح التحقق ولم تظهر الشارة بعد نافذة زحف معقولة، فتحقق أولًا من إمكان الزحف إلى رابط الصورة وفهرسته؛ إذ يجعل الحظر في robots.txt على مضيف الصور الترميز يفشل بصمت، قبل افتراض خطأ الترميز.

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

• الاختبار — شغّل رابط صفحات Recipe في أداة فحص أهلية النتائج المنسقة لتأكيد أهلية النتيجة المنسقة للوصفة، وافصل ذلك عن فحص الصورة التي تظهر بجوار النتيجة النصية العادية في Search.
• النتيجة المتوقعة — تظهر النتيجة المنسقة للوصفة مؤهلة مع image صالحة. وبشكل منفصل، تكون الصورة المصغرة للنتيجة النصية هي التي تختارها primaryImageOfPage أو صورة الكيان الرئيسي أو og:image، وقد لا تكون الصورة نفسها.
• تفسير الإخفاق — إذا كانت النتيجة المنسقة للوصفة غير مؤهلة، فالمشكلة في خاصية image على نوع Recipe نفسه، كأن تكون مفقودة أو ذات نسبة أبعاد خاطئة أو غير قابلة للزحف. أما إذا كانت الصورة المصغرة للنتيجة النصية خاطئة، فتلك إشارة مستقلة تمامًا، إذ لا تتحكم image في Recipe فيها وفق توضيح Google في يونيو 2025؛ افحص primaryImageOfPage وog:image بدلًا منها.
• نافذة المراقبة — يمكن فحص أهلية النتيجة المنسقة فور زحف ناجح، بينما اختيار الصورة المصغرة مؤتمت وقد يستغرق وقتًا أطول ليستقر في نتائج Search المباشرة؛ انتظر بضعة أسابيع قبل مواصلة الاستكشاف.
• سبب التراجع — إذا انخفضت أهلية النتيجة المنسقة للوصفة بعد تغيير في القالب، فتراجع وأعد فحص قابلية الزحف إلى خاصية image وحجمها.

موارد تستحق وقتك

من كتاباتي ذات الصلة

• Structured Data: What It Is and How to Use It — دليلي في Ahrefs لأنواع المخططات وصيغها والتحقق منها وزاوية الكيانات في sameAs، وهو السياق الأوسع الذي يقع فيه ImageObject.
• The Beginner’s Guide to Technical SEO — موضع البيانات المنظمة والصور ضمن الصورة التقنية الأكبر.

من محاضراتي

• How Search Works على SlideShare — شرحي للزحف والعرض والفهرسة وكيف يدعم الترميز الفهم. وينطبق تنبيهي المعتاد: “This is my understanding of systems… not going to be 100% complete or accurate.” (ترجمة) «هذا هو فهمي للأنظمة، ولن يكون كاملًا أو دقيقًا بنسبة 100%».

مصادر رسمية

• وثيقة بيانات الصور الوصفية من Google — المرجع الأساسي لترخيص ImageObject.
• وثيقتا Recipe ومقتطفات Product من Google — لحقائق الخصائص المطلوبة والموصى بها.
• أفضل ممارسات SEO للصور من Google — إرشادات اختيار الصورة المصغرة باستخدام primaryImageOfPage وog:image.
• schema.org/ImageObject — تعريف النوع وقائمة خصائصه الكاملة.

من مصادر القطاع

• تحديث Google للبيانات المنظمة في Event وRecipe لباري شوارتز، Search Engine Land، 5 يونيو 2025 — مصدر توضيح أن صورة Recipe لا تؤثر في الصورة المصغرة للنتيجة النصية.
• توضيح Google لكيفية اختيار الصور المصغرة في Search وDiscover لمات جي. ساذرن، Search Engine Journal، 2 مارس 2026 — تحديث اختيار الصورة المصغرة عبر primaryImageOfPage وصورة الكيان الرئيسي image وog:image.
• دليل سريع لبيانات IPTC الوصفية وصور Google من IPTC — مطابقة حقول IPTC مع schema.org لمسار الترخيص البديل.
• جزء مخطط الصور من Yoast من بوابة مطوري Yoast — مرجع تقني جيد لاستخدام ImageObject داخل مخطط @graph في JSON-LD والإشارة إليه عبر @id عند إعادة استخدام الصورة نفسها.
• r/TechSEO — مجتمع لاستكشاف مشكلات البيانات المنظمة وترميز الصور.

اختبر معلوماتك: مخطط ImageObject

خمسة أسئلة سريعة عن طريقة عمل ImageObject فعليًا. اختر إجابة لكل سؤال ثم تحقق منها.

سجل التغييرات