اللغات

صور المشاركة الاجتماعية (og:image وtwitter:image): الأحجام والحدود والبدائل

ورقة مواصفات صور og:image وtwitter:image: الإعداد الآمن 1200×630 (1,91:1)، وأبعاد المنصات وحدود الملفات، وقاعدة العنوان المطلق، ومتطلبات Google للصور المصغرة في 2026، وأسباب الفشل والبدائل.

نُشر أول مرة: 2 يوليو 2026 · آخر تحديث: 13 أغسطس 2026 · Advanced
اللغات
AIمن تأليفAI v2

تشير og:image وtwitter:image إلى صورة بطاقة معاينة الرابط؛ وهذا شرح متعمق لمتطلبات الصورة لا لبنية الوسم، التي يغطيها موضوعا Open Graph وTwitter Cards. الإعداد الآمن عبر المنصات هو عنوان HTTPS مطلق لصورة نحو 1200×630px (1,91:1)، لكنه حل وسط استقر عليه المجتمع لا مواصفة رسمية موحدة. أرقام Meta وحدها أولية المصدر: حد أدنى 200×200، وأرضية 600×315، وتوصية ≥1200×630، ونسبة 1,91:1، وحد 8 MB. أما أرقام X التقريبية 1200×628/675 ونحو 5 MB، وقراءة Slack لأول نحو 32 KB من HTML، وإسقاط WhatsApp الصامت للصور الكبيرة، فهي إجماع مجتمعي لا مواصفات أولية حديثة قابلة للتحقق. قاعدة العنوان المطلق نمط فشل صامت حقيقي؛ فزواحف التواصل لا تحل المسارات النسبية. يتيح الوسم الغائب صورة احتياطية من المتن، أما الصورة المحددة التي تفشل بسبب 404 أو الحجم الزائد أو حجب المصادقة فهي أقل تسامحًا وغالبًا لا تعرض أي صورة. منذ مارس 2026 تقرأ Google og:image لصورها المصغرة في Search وDiscover، ولا تمد وثائقها ذلك إلى أسطح الذكاء الاصطناعي، لكن مواصفاتها 16:9 / عرض ≥1200px / أكثر من 300K بكسل / بلا شعارات / بلا نص، وهي هيئة تختلف عن قص التواصل 1,91:1. لا يصل إصلاح الصورة إلى الروابط التي سبقت مشاركتها حتى تفرض إعادة الجلب. هذا شرح متعمق ضمن محور Meta Tags for SEO.

الخلاصة — هذه ورقة مواصفات للصورة، لا لبنية الوسم؛ فتفاصيل og:image وtwitter:image موجودة في موضوعي Open Graph وTwitter Cards. 1200×630 (1,91:1) هو إعداد افتراضي آمن، لا معيارًا عالميًا رسميًا. أرقام Meta وحدها موثقة من مصدر أولي: حد أدنى 200×200، وأرضية 600×315، وتوصية ≥1200×630، ونسبة 1,91:1، وحد 8 MB. أما أرقام X التقريبية 1200×628/675 و5 MB، وقراءة Slack لنحو 32 KB من بداية HTML، وإسقاط WhatsApp للملفات قرب 300 KB فهي إجماع مجتمعي وليست مواصفات أولية حديثة قابلة للتحقق، وأميز بوضوح بين الفئتين. يجب أن يكون عنوان الصورة مطلقًا؛ فزواحف التواصل لا تحل المسارات النسبية. المفقود لا يساوي المعطل: غياب الوسم يتيح صورة احتياطية من المتن، أما الصورة المحددة التي تفشل (404 أو حجم زائد أو حجب بالمصادقة/robots) فكثيرًا ما تترك البطاقة بلا صورة. تقرأ Google الآن og:image لصورها المصغرة في Search وDiscover (مارس 2026)، لكن مواصفاتها 16:9 / عرض ≥1200px / أكثر من 300K بكسل / بلا شعار / بلا نص، وهي هيئة تختلف عن قص التواصل 1,91:1. ولا يصل الإصلاح إلى الروابط المنشورة قبل فرض إعادة الجلب.

Evidence for this claim The Open Graph protocol uses og:image to identify an image and defines optional image URL, MIME type, width, height, and alt properties. Scope: Open Graph protocol metadata. Confidence: high · Verified: Open Graph protocol Evidence for this claim X Cards support summary and summary_large_image card types and image metadata, subject to X's crawler and card requirements. Scope: Current X Cards markup documentation. Confidence: high · Verified: X Developer Platform: Cards markup

ما الذي تغطيه هذه المقالة (وما الذي يغطيه الموضوعان الشقيقان)؟

تغطي مقالتا وسوم Open Graph ووسوم Twitter Cards آليات الوسوم: خصائص Open Graph الأربع المطلوبة، والفرق بين name= وproperty=، وأنواع بطاقات Twitter الأربع، وقاعدة رجوع twitter:image إلى og:image. أما هذه المقالة فهي ورقة المواصفات المصاحبة: الأبعاد، ونسبة العرض إلى الارتفاع، وحجم الملف، والتنسيق، وشرط عنوان URL المطلق، وما الذي يتعطل فعلًا عند الخطأ في أي منها. إذا كنت هنا لكتابة سطر <meta> فابدأ بالمقالتين السابقتين؛ وإذا كنت هنا لأن مقاس صورتك خاطئ أو لأنها لا تظهر، فأنت في المكان الصحيح.

نكرر قاعدة الرجوع الاحتياطي لأنها تحدد عدد الصور المطلوبة: إذا غاب twitter:image تستخدم X قيمة og:image، لذلك تضبط معظم المواقع صورة واحدة لكليهما، ولا تفصل بينهما إلا إذا أرادت قصًا مختلفًا لمنصة X.

الإعداد الافتراضي الآمن: 1200×630 (1,91:1) — ولماذا هو حل وسط

تبدأ كل الأدلة تقريبًا بمقاس 1200×630 وتتوقف عنده. إنه خيار افتراضي جيد، لكن من المهم توضيح مصدره: فليس معيارًا واحدًا عابرًا للمنصات تنشره جميعها بالصورة نفسها. بل هو المقاس الذي استقر عليه المجتمع لأنه يحقق توصية Facebook ويُعرض بصورة مقبولة في بقية المنصات. تذكر بعض الأدلة 1200×627، وتذكر أخرى 1200×628 لمنصة X؛ وهذه فروق تقريبية ومتغيرات قديمة للفكرة نفسها، أي نسبة نحو 1,91:1، وليست مواصفات متنافسة. اختر 1200×630، ولن تحتاج إلى صورة ثانية إلا لمنصة X إذا أردت قصًا أضيق فيها تحديدًا.

الأبعاد وحجم الملف حسب المنصة

أهم ما تفعله هذه الصفحة هو الفصل بين الأرقام الموثقة من مصدر أولي (Meta) والإجماع المجتمعي (كل ما عدا ذلك). وقد أوضحت صراحةً أيها ينتمي إلى كل فئة؛ فلا تتعامل مع الأرقام غير الصادرة عن Meta كحقائق قطعية.

Facebook / Meta (مصدر أولي)

وفق وثائق Meta الخاصة بصور المشاركة:

  • الحد الأدنى: “The minimum allowed image dimension is 200 x 200 pixels.” (ترجمة) «أصغر أبعاد مسموح بها للصورة هي 200 × 200 بكسل».
  • الحد الأدنى لتجنب العرض الصغير: “At the minimum, you should use images that are 600 x 315 pixels to display link page posts with larger images.” (ترجمة) «استخدم على الأقل صورًا بأبعاد 600 × 315 بكسل لعرض منشورات روابط الصفحات بصور أكبر».
  • الموصى به: “Use images that are at least 1200 x 630 pixels for the best display on high resolution devices.” (ترجمة) «استخدم صورًا لا تقل عن 1200 × 630 بكسل للحصول على أفضل عرض على الأجهزة عالية الدقة».
  • النسبة: اجعلها “as close to 1.91:1 aspect ratio as possible” (ترجمة) «أقرب ما يمكن إلى نسبة 1,91:1» لتجنب القص في Feed.
  • حد الملف: “The size of the image file must not exceed 8 MB.” (ترجمة) «يجب ألا يتجاوز حجم ملف الصورة 8 MB».

Meta هي أيضًا مصدر خصوصية التخزين المؤقت عند المشاركة الأولى: يجب أن يرى الزاحف الصورة مرة قبل عرضها، ولذلك “the first person who shares a piece of content won’t see a rendered image.” (ترجمة) «لن يرى أول شخص يشارك المحتوى صورة معروضة». ويتصرف LinkedIn على نحو مشابه؛ وهذه هي قصة إعادة الجلب التي يغطيها موضوع Open Graph.

X / Twitter (إجماع مجتمعي — تعامل معه بحذر)

تتطلب أرقام X حذرًا خاصًا. أُوقفت أداة Card Validator في 2022 من دون بديل، واختفت عمليًا وثائق Cards في developer.x.com: فقد أعادت استجابة HTTP 402 Payment Required في أوائل يوليو 2026، ومنذ هذا التحديث أصبح عنوان URL نفسه يعيد توجيه HTTP 307 إلى الصفحة الرئيسية لـdocs.x.com، حيث يعيد مسار ترميز Cards المكافئ 404s؛ فهو رابط ميت في الحالتين، ولا توجد الآن مواصفة أولية حية وحديثة يمكن التحقق منها لدى X. الأرقام المتداولة في الأدلة — نحو 1200×628 أو 1200×675 لبطاقة summary_large_image، وحد أدنى 300×157، وحد أقصى 4096×4096، وحد ملف نحو 5 MB، مع حاجة بطاقة summary الصغيرة إلى مربع أصغر بحد أدنى يقارب 144×144 — هي إجماع من مصادر ثانوية، لا مواصفة رسمية حالية مؤكدة. وهي قريبة بما يكفي من الإعداد الافتراضي 1,91:1 لتكون مفيدة، لكنني لا أقدم أي رقم محدد للبايتات أو البكسلات في X على أنه موثوق رسميًا. ويغطي موضوع Twitter Cards وضع وثائق X وأداة التحقق كاملًا.

LinkedIn وSlack وWhatsApp وDiscord وiMessage

  • LinkedIn هي المنصة الوحيدة غير Meta التي تنشر أرقامها الخاصة: تذكر صفحة المساعدة التي تشرح جعل الموقع قابلًا للمشاركة حدًا أدنى 1200×627 بكسل، ونسبة موصى بها 1,91:1، وحدًا أقصى للملف 5 MB، وتوضح منفصلةً أن “images less than 401 pixels wide display as a thumbnail image.” (ترجمة) «الصور التي يقل عرضها عن 401 بكسل تُعرض كصورة مصغرة». أنشئ الصورة وفق الإعداد 1200×630 فتتجاوز هذه الحدود بهامش؛ ولا تخلط بينها وبين أرقام Facebook، فهي أرقام LinkedIn نفسها. وأداة Post Inspector هي أداة إعادة الجلب.
  • Slack يواجه مشكلة في موضع الوسم أكثر من حجم الصورة؛ إذ يُذكر على نطاق واسع أنه لا يقرأ سوى أول نحو 32 KB من HTML الخام للصفحة عند إظهار المعاينة. فإذا وقعت وسوم الرأس — ومن ثم مرجع og:image — بعد ذلك، فقد لا يراها Slack أبدًا. تؤكد وثائقه الخاصة بإظهار المعاينات أنه يقرأ بيانات Open Graph وX Card، لكنها لا تنشر حدًا للبايتات؛ لذا تعامل مع رقم 32 KB بوصفه رقمًا مُبلّغًا عنه لا مؤكدًا رسميًا.
  • WhatsApp يُقال إنه يسقط صورة المعاينة بصمت عند كبر الملف، وغالبًا ما يُذكر حد يقارب 300 KB، مع تداول رقم أعلى يقارب 600 KB بلهجة «رسمية». وفي الحالتين يكون الملف الثقيل هو نمط الفشل.
  • Discord وiMessage يرثان Open Graph من دون مواصفات مستقلة موثقة للصورة؛ أنشئ الصورة وفق الإعداد 1200×630 وسيتبعانه.

الخلاصة العملية: بدل مطاردة أصغر حد منشور، استهدف أقل من نحو 1 MB، ويفضل 100–300 KB لتظل دون حدود جميع المنصات.

قاعدة عنوان URL المطلق — فشل حقيقي وصامت

هذه القاعدة تُذكر في كل مكان بوصفها حقيقة، لكن نادرًا ما تُشرح. يجب أن تكون قيمتا og:image وtwitter:image عنوان URL مطلقًا من نوع https://.... لا يُرفض المسار النسبي مثل /images/share.jpg برسالة خطأ ظاهرة، بل يُتجاهل بصمت. والسبب أن المتصفح يحل المسار النسبي قياسًا إلى عنوان URL للصفحة لأنه يعرف الصفحة التي يعرضها، أما زاحف التواصل الذي يجلب الوسم فلا يملك سياق الأساس هذا ولا يستطيع إعادة بناء نطاقك بصورة موثوقة. لذلك يتجاوز الوسم ويعود إلى أي صورة أخرى يمكنه استخراجها. فإذا كانت الصورة «لا تظهر» وكان المسار في المصدر يبدأ بـ/ بدل https://، فهذا هو الخلل.

صورة واحدة واستخدامان: مواصفة Google للصور المصغرة في 2026

منذ 2 مارس 2026 توثق Google og:image بوصفه أحد مصدري البيانات الوصفية المقبولين، إلى جانب primaryImageOfPage في schema.org، لاختيار صورها المصغرة في Search وDiscover. وتحصر وثائق Google الادعاء في هذين السطحين ولا تمدده إلى AI Overviews. لذلك قد تضطر الصورة نفسها إلى خدمة منصات التواصل وصور Google، مع أن الأشكال المطلوبة تختلف.

إرشادات Google للصور (وثائق Discover وImage SEO):

  • الأبعاد: “at least 1200 px wide.” (ترجمة) «بعرض 1200 بكسل على الأقل».
  • النسبة: 16:9، لا نسبة التواصل 1,91:1.
  • الدقة: “more than 300,000 total pixels” (ترجمة) «أكثر من 300 000 بكسل إجمالًا»؛ فصورة 1280×720 تضم 921 600 بكسل.
  • المحتوى: تجنب “a generic image (for example, your site logo) or an image with text,” (ترجمة) «صورة عامة مثل شعار الموقع أو صورة تحتوي نصًا»، وتجنب “an extreme aspect ratio.” (ترجمة) «نسبة عرض إلى ارتفاع متطرفة».
  • شرط الأهلية: يتطلب عرض الصورة الكبيرة في Discover توجيه max-image-preview:large أو AMP؛ وهو شرط منفصل يغطيه موضوع وسم meta robots.

صورة اجتماعية 1200×630 (1,91:1) تحتوي 756 000 بكسل، فتتجاوز حدي Google للعرض وعدد البكسلات، لكنها ليست بنسبة 16:9. يمكن لصورة جيدة واحدة خدمة الاثنين، أو يمكنك تحديد primaryImageOfPage منفصلة لـGoogle مع إبقاء قص 1,91:1 للتواصل. ونصيحة تجنب الشعار والنص الثقيل مفيدة أيضًا لنسبة النقر الاجتماعية.

المفقودة والمعطلة — نمطا فشل مختلفان

يخلط الناس بينهما، لكن سلوكهما مختلف:

  • وسم og:image غائب. تلجأ المنصات إلى صورة من متن الصفحة أو صورة افتراضية. تكون المعاينة غير متحكم فيها، لكنها نادرًا ما تكون فارغة تمامًا.
  • الوسم موجود لكن الصورة تفشل — بسبب 404، أو ملف كبير يُسقط بصمت، أو نوع MIME خاطئ، أو عنوان محجوب بالمصادقة أو robots.txt. هذا الوضع أقل تسامحًا؛ فقد لا تعرض منصات عدة أي صورة لأنها تعرف أنك حددت واحدة. وقد تكون الإشارة المعطلة أسوأ من عدم الإشارة أصلًا.

وتحت الحالتين مشكلة العرض والزحف: معظم روبوتات التواصل لا تشغّل JavaScript، لذلك لن ترى وسمًا يُحقن من جهة العميل. وكما كتبت في دليل Ahrefs لـJavaScript SEO: “Social media bots don’t run JavaScript, so things like OG tags won’t be seen unless you render the content before serving it to them.” (ترجمة) «لا تشغّل روبوتات التواصل JavaScript، لذلك لن ترى وسوم OG ما لم تعرض المحتوى قبل تقديمه لها». اعرض الوسم على الخادم.

دعم التنسيقات

  • JPEG/JPG وPNG مدعومان في كل مكان.
  • WebP مدعوم لدى معظم المستهلكين الحديثين (وتذكره Meta صراحة)، لكن احتفظ ببديل JPEG/PNG عندما لا تستطيع الاختبار.
  • GIF/WebP المتحركان غير موثوقين لبطاقة ثابتة؛ فمعظم المنصات تلتقط إطارًا واحدًا أو تتجاهل الحركة.

التخزين المؤقت — المرحلة الأخيرة

لا ينتقل إصلاح الصورة كبيرة الحجم أو المعطلة إلى الروابط التي سبقت مشاركتها حتى تفرض إعادة الجلب؛ إذ تعيد أداتا Facebook Sharing Debugger وLinkedIn Post Inspector جلب الصفحة وتحديث المعاينة المخزنة مؤقتًا. وهذه هي الفكرة المحورية في موضوع Open Graph، لذلك أختصرها هنا في سطر واحد: عدّل الصورة ثم أعد الجلب، وإلا بقيت الصورة القديمة.

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

هذا شرح متعمق تحت محور وسوم Meta لـSEO، وبجوار موضوعي بنية الوسم اللذين توسع هذه المقالة فيهما: Open Graph وTwitter Cards. وهو يمس أيضًا مجموعة SEO للصور المنفصلة، التي تغطي تنسيقات الملفات ونص alt وفهرسة الصور عمومًا. والفرق أن SEO للصور يتناول الصور داخل المحتوى، بينما نتناول هنا صورة بيانات وصفية واحدة تمثل الصفحة كلها في بطاقة مشاركة، وأصبحت الآن تمثلها أيضًا في صورة Google المصغرة.

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.