Imágenes para compartir en redes sociales (og:image y twitter:image): tamaños, límites y alternativas

TL;DR — La imagen para compartir en redes sociales aparece en la tarjeta de vista previa al pegar un enlace en Facebook, LinkedIn, Slack o X. Se configura mediante og:image —y twitter:image para X—. Debe ser una URL https:// absoluta, de aproximadamente 1200×630 píxeles, con un archivo ligero. Una proporción incorrecta, un enlace roto o un archivo demasiado grande puede hacer que la plataforma muestre otra imagen o ninguna.

Qué es la imagen social

Cuando se comparte un enlace, la mayoría de las aplicaciones muestra una tarjeta de vista previa con un titular, texto y una imagen. Esa imagen es la imagen para compartir en redes sociales. La imagen se indica mediante og:image en la cabecera de la página. X puede usar una etiqueta twitter:image distinta; si no se configura, reutiliza og:image.

Esta página se centra en la imagen: sus dimensiones, el tamaño del archivo y los modos de fallo. La sintaxis de las etiquetas se explica por separado en los artículos de Open Graph y Twitter Cards.

El tamaño principal que conviene recordar

No existe un tamaño oficial único para todas las plataformas, pero 1200×630 píxeles —aproximadamente 1,91:1— es el valor predeterminado seguro. Facebook recomienda al menos 1200×630 píxeles y ese tamaño se muestra adecuadamente en LinkedIn, Slack y X.

Tres reglas que confunden a la gente

1. Debe usarse una URL absoluta, no una ruta relativa. og:image necesita una URL https://www.example.com/image.jpg completa. Una ruta como /image.jpg puede omitirse porque los rastreadores sociales no siempre disponen del contexto necesario para resolver el dominio.
2. Conviene mantener el archivo ligero. Facebook permite hasta 8 MB, pero otras aplicaciones descartan archivos pesados. Unos cientos de KB suelen bastar; el objetivo práctico es menos de 1 MB.
3. Una etiqueta ausente y una imagen rota producen resultados distintos. Si falta la etiqueta, las plataformas pueden extraer otra imagen de la página. Si la referencia existe pero falla —URL incorrecta, bloqueo o archivo demasiado grande—, algunas aplicaciones no muestran imagen.

Por qué la imagen a veces no se actualiza

Si se corrige una imagen pero sigue apareciendo la anterior, la plataforma conserva una versión en caché. Debe solicitarse un nuevo rastreo mediante una herramienta como Facebook Sharing Debugger o LinkedIn Post Inspector.

Los números exactos por plataforma, los límites de tamaño, las reglas de Google y la diferencia entre una etiqueta ausente y una imagen rota se explican en la pestaña Advanced.

TL;DR — Esta es la hoja de especificaciones de la imagen, no la sintaxis de la etiqueta — la mecánica de og:image / twitter:image vive en los temas hermanos de Open Graph y Twitter Cards. 1200×630 (1,91:1) es el valor predeterminado seguro, no un estándar universal oficial. Solo los números de Meta tienen fuente primaria: mínimo de 200×200, mínimo de 600×315, ≥1200×630 recomendado, 1,91:1, límite de 8 MB. El ~1200×628/675 y ~5 MB de X, el ~32 KB de Slack en la lectura temprana de HTML, y el descarte silencioso de ~300 KB de WhatsApp son consenso de la comunidad, no especificaciones de fuente primaria verificables recientemente — aquí se identifica cada categoría. La regla de URL absoluta es un fallo silencioso real: los rastreadores sociales no resuelven rutas relativas. Faltante ≠ rota: una etiqueta ausente recurre a una imagen del cuerpo extraída; una imagen presente pero que falla (404, demasiado grande, bloqueada por autenticación/robots) a menudo no muestra nada. Google ahora lee og:image para sus propias miniaturas de Búsqueda y Discover (marzo de 2026), pero su especificación es 16:9 / ≥1200px de ancho / ≥300K píxeles / sin logotipo / sin texto — una forma diferente al recorte social de 1,91:1. El almacenamiento en caché significa que una corrección no llega a los enlaces ya compartidos hasta que se fuerza un nuevo rastreo.

Lo que cubre este artículo (y lo que cubren los artículos hermanos)

La mecánica de las etiquetas —las cuatro propiedades obligatorias de Open Graph, name= frente a property=, los cuatro tipos de Twitter Card y la regla de respaldo twitter:image → og:image— ya se explica en Open Graph Tags y Twitter Card Tags. Este artículo complementario se centra en dimensiones, proporción, tamaño, formato, URL absolutas y modos de fallo. Para escribir la línea <meta>, conviene comenzar por esos dos artículos; para diagnosticar una imagen con tamaño incorrecto o que no aparece, esta es la sección pertinente.

Un rápido repaso de la regla de respaldo, porque decide cuántas imágenes se necesitan: twitter:image recurre a og:image cuando está ausente, por lo que la mayoría de los sitios configuran una imagen y la usan para ambos — solo se requiere una excepción si se busca específicamente un recorte diferente para X.

El valor predeterminado seguro: 1200×630 (1,91:1) — y por qué es un compromiso

Casi todas las guías comienzan con 1200×630 y se detienen ahí. Es un buen valor predeterminado, pero vale la pena ser honesto sobre de dónde viene: no es un estándar multiplataforma único que alguien publique de manera idéntica. Es el tamaño convergido por la comunidad que supera la recomendación de Facebook y se renderiza aceptablemente en todo lo demás. Algunas guías dicen 1200×627, otras dicen 1200×628 para X — esas son variantes de redondeo y legado de la misma idea de ~1,91:1, no especificaciones en competencia. Puede elegirse 1200×630, y el único lugar donde podría convenir una segunda imagen es X, si se necesita un recorte más ajustado allí.

Dimensiones y tamaño de archivo por plataforma

Esta sección separa las cifras con fuente primaria —Meta y LinkedIn— de las que proceden del consenso de la comunidad. Los valores sin respaldo oficial no deben tratarse como límites infalibles.

Facebook / Meta (fuente primaria)

De la documentación de imágenes para compartir de Meta:

• Mínimo: “The minimum allowed image dimension is 200 x 200 pixels.” (traducción) «La dimensión mínima permitida de imagen es de 200 x 200 píxeles.»
• Mínimo para evitar la renderización pequeña: “At the minimum, you should use images that are 600 x 315 pixels to display link page posts with larger images.” (traducción) «Como mínimo, deberías usar imágenes de 600 x 315 píxeles para mostrar publicaciones de páginas con enlaces con imágenes más grandes.»
• Recomendado: “Use images that are at least 1200 x 630 pixels for the best display on high resolution devices.” (traducción) «Usa imágenes de al menos 1200 x 630 píxeles para la mejor visualización en dispositivos de alta resolución.»
• Relación de aspecto: debe mantenerse “as close to 1.91:1 aspect ratio as possible” (traducción) «lo más cerca posible de una relación de aspecto de 1.91:1» para evitar recortes en el Feed.
• Límite de tamaño de archivo: “The size of the image file must not exceed 8 MB.” (traducción) «El tamaño del archivo de imagen no debe superar los 8 MB.»

Meta también es la fuente de la peculiaridad de caché del “primer uso compartido”: el rastreador tiene que ver la imagen al menos una vez antes de que se renderice, por lo que “the first person who shares a piece of content won’t see a rendered image.” (traducción) «la primera persona que comparte un contenido no verá una imagen renderizada.» (LinkedIn se comporta de manera similar — esta es la historia del re-rastreo, cubierta en el artículo hermano de Open Graph).

X / Twitter (consenso de la comunidad — tratar con precaución)

Los números de X son los que hay que tratar con cuidado. El Card Validator oficial fue retirado en 2022 sin reemplazo, y la documentación de Cards de developer.x.com está efectivamente desaparecida: devolvió una respuesta HTTP 402 Payment Required a principios de julio de 2026, y al momento de esta actualización la misma URL en su lugar redirige (HTTP 307) a la página principal de docs.x.com, donde la ruta equivalente de marcado de Cards no está disponible — una ruta inactiva en cualquier caso, por lo que no hay una especificación oficial de X viva y verificable en este momento. Las cifras que circulan entre las guías — aproximadamente 1200×628 o 1200×675 para summary_large_image, un mínimo de 300×157, un máximo de 4096×4096 y un límite de archivo de ~5 MB, con la tarjeta pequeña summary que necesita un cuadrado más pequeño de ~144×144 como mínimo — son consenso de terceros, no una especificación oficial actual confirmada. Son lo suficientemente cercanas al valor predeterminado de 1,91:1 como para ser útiles, pero ningún límite de bytes o píxeles específico de X debería presentarse como dato oficial. (La situación de la documentación y el validador de X se cubre en su totalidad en el artículo hermano de Twitter Cards.)

LinkedIn, Slack, WhatsApp, Discord, iMessage

• LinkedIn publica cifras propias: mínimo de 1200×627 píxeles, proporción recomendada de 1,91:1 y tamaño máximo de 5 MB. También indica que “images less than 401 pixels wide display as a thumbnail image” (traducción) «las imágenes de menos de 401 píxeles de ancho se muestran como miniatura». Una imagen de 1200×630 supera esos mínimos. Estas cifras pertenecen a LinkedIn y no deben confundirse con las de Facebook. Post Inspector es su herramienta de nuevo rastreo.
• Slack plantea sobre todo un problema de ubicación: se informa que solo lee los primeros ~32 KB del HTML sin procesar. Si las etiquetas de cabecera aparecen después, quizá no detecte og:image. La documentación confirma que Slack lee Open Graph y X Card, pero no publica un límite de bytes; por tanto, 32 KB debe presentarse como una cifra reportada, no oficial.
• WhatsApp puede descartar silenciosamente imágenes pesadas. Suele citarse un umbral de ~300 KB, y también circula otro de ~600 KB, pero ninguno dispone aquí de una fuente primaria verificable.
• Discord e iMessage heredan Open Graph sin especificaciones de imagen independientes. El valor seguro de 1200×630 suele ser suficiente.

La conclusión honesta: en lugar de perseguir la cifra documentada más estricta, conviene mantener el archivo por debajo de ~1 MB — idealmente 100–300 KB — para quedar por debajo del límite de cada plataforma con margen.

La regla de la URL absoluta — un modo de fallo real y silencioso

Esto se afirma como un hecho en todas partes, pero rara vez se explica. og:image y twitter:image deben ser una URL absoluta https://.... Una ruta relativa como /images/share.jpg no se rechaza con un error visible — simplemente se ignora silenciosamente. La razón: un navegador resuelve una ruta relativa contra la URL de la propia página porque ya sabe en qué página está, pero un rastreador social que obtiene la etiqueta no tiene ese contexto base y no reconstruirá el dominio de manera confiable. Así que omite la etiqueta y recurre a lo que pueda extraer. Si la imagen “no se muestra” y la ruta en el código fuente comienza con / en lugar de https://, esa es la causa.

Una imagen, dos amos: la especificación de miniaturas de Google de 2026

Aquí está el ángulo más reciente y menos cubierto. A partir del 2 de marzo de 2026, Google documenta og:image como una de las dos fuentes de metadatos aceptadas (junto con primaryImageOfPage de schema.org) para seleccionar sus propias miniaturas en Search y Discover — los documentos propios de Google describen estas dos superficies específicamente y no extienden la afirmación a AI Overviews u otras superficies de IA, por lo que la afirmación tampoco se extiende aquí. Eso significa que el mismo archivo de imagen ahora a menudo tiene que satisfacer tanto a las plataformas sociales como a las miniaturas de resultados de texto/Discover de Google — y sus especificaciones no tienen la misma forma.

La guía de imágenes de Google (documentos de Discover y SEO de imágenes):

• Dimensiones: “at least 1200 px wide.” (traducción) «al menos 1200 px de ancho».
• Proporción: 16:9, no la proporción social de 1,91:1.
• Resolución: “more than 300,000 total pixels” (traducción) «más de 300 000 píxeles en total»; una imagen de 1280×720 contiene 921 600.
• Contenido: Google indica que deben evitarse “a generic image (for example, your site logo) or an image with text” (traducción) «una imagen genérica —por ejemplo, el logotipo del sitio— o una imagen con texto», así como “an extreme aspect ratio” (traducción) «una proporción extrema».
• Elegibilidad: la miniatura grande de Discover requiere max-image-preview:large —una directiva de robots meta— o AMP. Este requisito es independiente del archivo de imagen y se explica en la etiqueta meta robots.

Una imagen social de 1200×630 (1,91:1) contiene 756 000 píxeles: supera los mínimos de Google de ≥1200 px de ancho y ≥300 000 píxeles, pero no tiene una proporción 16:9. Una imagen bien compuesta puede funcionar en ambas superficies. Si se necesita optimizar cada una por separado, puede declararse un primaryImageOfPage específico para Google y mantener el recorte 1,91:1 para redes sociales. Evitar logotipos aislados y texto abundante también favorece el CTR social.

Ausente vs. rota: dos modos de fallo diferentes

Estos conceptos suelen confundirse, pero producen resultados distintos:

• La etiqueta og:image está ausente. Las plataformas pueden extraer una imagen del cuerpo o usar un valor genérico. Se obtiene una vista previa no controlada, pero rara vez una tarjeta completamente vacía.
• La etiqueta og:image está presente, pero la imagen falla. Un estado 404, un archivo descartado por tamaño, un tipo MIME incorrecto o un bloqueo por autenticación o robots.txt puede impedir que se muestre cualquier imagen. La referencia rota puede producir un resultado peor que el de una etiqueta ausente porque la plataforma ya detectó una imagen declarada.

Y el detalle de renderizado frente a rastreo que subyace a ambos: la mayoría de los bots sociales no ejecutan JavaScript, por lo que si la etiqueta se inyecta en el lado del cliente, no se verá. Como se explica en la guía de SEO de JavaScript de Ahrefs, “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.” (traducción) «Los bots de redes sociales no ejecutan JavaScript, por lo que cosas como las etiquetas OG no se verán a menos que renderices el contenido antes de servírselo». La etiqueta debe renderizarse en el servidor; de lo contrario, el rastreador no podrá detectarla.

Compatibilidad de formatos

• JPEG/JPG y PNG son compatibles universalmente: seguros en todas partes.
• WebP es compatible con la mayoría de los consumidores modernos (Meta lo menciona explícitamente), pero conviene mantener un respaldo JPEG/PNG para cualquier cosa que no pueda probarse.
• GIF/WebP animados no son fiables para una tarjeta de vista previa estática: la mayoría de las plataformas capturan un solo fotograma o ignoran la animación. No debe confiarse en el movimiento en una imagen para compartir.

Caché: la última milla

Corregir una imagen demasiado grande o rota no se propaga a los enlaces que la gente ya compartió hasta que se fuerza un nuevo rastreo: el Facebook Sharing Debugger y el LinkedIn Post Inspector vuelven a obtener la página y actualizan su vista previa en caché. Este es el punto central del artículo hermano de Open Graph, así que puede resumirse en una línea: la imagen debe editarse y después debe solicitarse un nuevo rastreo, o la antigua persistirá.

Dónde encaja

Este es un análisis en profundidad bajo el centro de Meta Tags for SEO, situado justo al lado de los dos artículos hermanos sobre sintaxis de etiquetas — Open Graph y Twitter Cards — que este artículo amplía. También roza el clúster separado de SEO de imágenes (que cubre formatos de archivo, texto alt e indexación de imágenes en general): la diferencia es que el SEO de imágenes trata sobre las imágenes dentro del contenido, mientras que este artículo trata sobre la única imagen de metadatos que representa toda la página en una tarjeta para compartir y, ahora, en una miniatura de Google.

Resumen de IA

Una versión condensada de la versión avanzada:

• Alcance: los requisitos de imagen para og:image / twitter:image, no la sintaxis de la etiqueta (eso es de los artículos hermanos de Open Graph y Twitter Cards). twitter:image recurre a og:image, por lo que la mayoría de los sitios usan una sola imagen para ambos.
• Valor seguro por defecto: una URL HTTPS absoluta a una imagen de ~1200×630px (1,91:1) — un compromiso convergente de la comunidad, no un estándar oficial único multiplataforma.
• Solo los números de Meta tienen fuente primaria: mínimo de 200×200, mínimo de 600×315, ≥1200×630 recomendado, 1,91:1, límite de 8 MB. Los ~1200×628/675 y ~5 MB de X, la lectura temprana de ~32 KB de HTML de Slack y el descarte silencioso de ~300 KB de WhatsApp son consenso de la comunidad — el validador de X está muerto y su documentación ha desaparecido (detrás de un muro de pago y luego una redirección muerta).
• Regla de URL absoluta: las rutas relativas se ignoran silenciosamente — los rastreadores sociales no tienen contexto base para resolverlas.
• Ausencia ≠ error: una etiqueta ausente recurre a una imagen del cuerpo extraída; una imagen presente pero fallida (404, sobredimensionada, bloqueada por autenticación/robots) a menudo muestra ninguna imagen en absoluto.
• Google (marzo de 2026) lee og:image para sus propias miniaturas de Search y Discover (su propia documentación limita esto a esas dos superficies, no a “miniaturas de IA” en general), pero su especificación es 16:9 / ≥1200px de ancho / ≥300K píxeles / sin logotipo / sin texto — una forma diferente a 1,91:1. Una imagen de 1200×630 supera los mínimos de píxeles de Google pero no es 16:9; necesita max-image-preview:large para la miniatura grande de Discover.
• Formatos: JPEG/PNG universales, WebP mayormente bien, formatos animados poco fiables.
• Renderizado: los bots sociales no ejecutan JavaScript — la etiqueta debe renderizarse en el servidor.
• Objetivo práctico: menos de ~1 MB, idealmente 100–300 KB, para superar todas las plataformas.
• Caché: arreglar la imagen no arregla los enlaces ya compartidos hasta que se fuerce un nuevo rastreo (Facebook Sharing Debugger, LinkedIn Post Inspector).

Documentación oficial

Documentación de fuente primaria para la especificación de imagen.

Meta / Facebook (la fuente más autorizada para dimensiones y tamaño de archivo)

• Compartir — Imágenes — la recomendación de ≥1200×630, el mínimo de 200×200, el mínimo de 600×315, la proporción 1,91:1 y el límite de tamaño de archivo de 8 MB.
• Compartir — Webmasters — cómo el rastreador extrae, el comportamiento de caché del primer compartido y las heurísticas de respaldo cuando falta el marcado.

El protocolo Open Graph

• ogp.me — las subpropiedades de og:image: og:image:url, og:image:secure_url, og:image:type, og:image:width, og:image:height y og:image:alt.

Google

• Especifica una imagen preferida con metadatos — og:image y schema.org como fuentes de selección de miniaturas; evita logotipos, texto en la imagen y proporciones extremas (actualizado el 2 de marzo de 2026).
• Google Discover — los números concretos de imagen: al menos 1200px de ancho, 16:9, más de 300 000 píxeles en total, además del requisito de elegibilidad de max-image-preview:large / AMP.

LinkedIn

• Haz que el sitio web sea compartible en LinkedIn — los números propios de LinkedIn: mínimo de 1200×627, proporción recomendada de 1,91:1, tamaño máximo de archivo de 5 MB, y las imágenes más estrechas de 401px se renderizan como miniatura.

Slack

• Desplegar enlaces en mensajes — confirma que Slack lee los metadatos de Open Graph / X Card; no publica un límite específico de bytes o imágenes en este documento.

X / Twitter (documentación prácticamente inaccesible en 2026)

• La documentación de Cards en developer.x.com devolvía HTTP 402 durante la investigación de julio de 2026. En esta actualización, la misma URL redirige con HTTP 307 a la página principal de docs.x.com, donde las rutas equivalentes no ofrecen una especificación vigente; la ruta heredada de developer.twitter.com tampoco la ofrece. Por tanto, las dimensiones y límites específicos de X deben identificarse como consenso de terceros. El artículo Twitter Cards contiene el contexto completo.

Citas de la fuente

Declaraciones oficiales sobre la especificación de imágenes. Cada enlace salta a (o documenta) el pasaje citado.

Meta / Facebook — las cifras de fuentes primarias

• “Use images that are at least 1200 x 630 pixels for the best display on high resolution devices.” (traducción) «Usa imágenes de al menos 1200 x 630 píxeles para una mejor visualización en dispositivos de alta resolución.» — Meta for Developers, documentación de Sharing Images. Fuente
• “At the minimum, you should use images that are 600 x 315 pixels to display link page posts with larger images.” (traducción) «Como mínimo, deberías usar imágenes de 600 x 315 píxeles para mostrar publicaciones de páginas enlazadas con imágenes más grandes.» Fuente
• “The minimum allowed image dimension is 200 x 200 pixels.” (traducción) «La dimensión mínima permitida para imágenes es de 200 x 200 píxeles.» y “The size of the image file must not exceed 8 MB.” (traducción) «El tamaño del archivo de imagen no debe superar los 8 MB.» Fuente

LinkedIn — su propio mínimo documentado

• “Minimum image dimensions: 1200 (w) x 627 (h) pixels” (traducción) «Dimensiones mínimas de imagen: 1200 (ancho) x 627 (alto) píxeles», “Recommended ratio: 1.91:1” (traducción) «Relación recomendada: 1.91:1», “Max file size: 5 MB” (traducción) «Tamaño máximo de archivo: 5 MB» y “Images less than 401 pixels wide display as a thumbnail image.” (traducción) «Las imágenes de menos de 401 píxeles de ancho se muestran como imagen en miniatura.» — Ayuda de LinkedIn, “Make your website shareable on LinkedIn.” Fuente

Google — og:image como fuente de miniaturas (marzo de 2026)

• Google influye en su selección automática de imágenes “by providing your preferred image through one of the following metadata sources” (traducción) «proporcionando tu imagen preferida a través de una de las siguientes fuentes de metadatos» — schema.org primaryImageOfPage o la etiqueta meta og:image. Ir a la cita
• “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.” (traducción) «Evita usar una imagen genérica (por ejemplo, el logotipo de tu sitio) o una imagen con texto en el marcado schema.org o en la etiqueta meta og:image.» Ir a la cita
• En Discover, Google dice que “use either schema.org markup or the og:image meta tag to specify a large image,” (traducción) «uses el marcado schema.org o la etiqueta meta og:image para especificar una imagen grande», de al menos 1200 px de ancho, 16:9 y más de 300 000 píxeles en total. Ir a la cita

Barry Schwartz, Search Engine Land — cobertura de la actualización de marzo de 2026

• Informó que Google usa tanto el marcado schema.org como la etiqueta meta og:image como fuentes al determinar las miniaturas de imágenes en Google Search y Discover. Leer la cobertura

Patrick Stox — el detalle de renderizado

• “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.” (traducción) «Los bots de redes sociales no ejecutan JavaScript, por lo que cosas como las etiquetas OG no se verán a menos que renderices el contenido antes de servírselo.» — de la guía de JavaScript SEO de Ahrefs del autor. Fuente

«La imagen no se muestra»: diagnóstico de tamaño, URL y caché

El árbol puede seguirse de arriba abajo; la primera respuesta afirmativa suele identificar la causa.

1. ¿La imagen acaba de cambiar, pero todavía aparece la anterior? → Es un problema de caché. Debe solicitarse un nuevo rastreo mediante Facebook Sharing Debugger o LinkedIn Post Inspector. Ningún otro cambio surtirá efecto hasta que la plataforma vuelva a obtener los metadatos.

2. ¿og:image contiene una ruta relativa que empieza por / o ./? → Es un problema de URL. Debe sustituirse por una URL https://... absoluta y después debe solicitarse un nuevo rastreo.

3. ¿La etiqueta de imagen se inyecta mediante JavaScript o solo aparece tras el renderizado? → Es un problema de renderizado. Los bots sociales no ejecutan JavaScript; la etiqueta debe incluirse en el HTML inicial renderizado por el servidor.

4. ¿La URL de la imagen carga en una ventana de incógnito sin iniciar sesión? → Si no carga —por estado 404, autenticación o bloqueo en robots.txt—, es un problema de accesibilidad. Una referencia presente pero rota puede producir una tarjeta sin imagen. Debe corregirse la ruta o retirarse el bloqueo.

5. ¿El archivo supera ~1 MB o el límite máximo de 8 MB de Meta? → Es un problema de tamaño. Meta rechaza archivos superiores a 8 MB y otras plataformas pueden descartar archivos mucho más pequeños. Conviene comprimir la imagen hasta 100–300 KB y solicitar un nuevo rastreo.

6. ¿La imagen mide menos de 200×200 o tiene una proporción extrema? → Es un problema de dimensiones. Por debajo de 600×315 puede mostrarse pequeña o recortada; por debajo de 200×200, Meta la rechaza. El valor seguro es aproximadamente 1200×630.

7. ¿El problema solo aparece en Slack? → Probablemente sea un problema de ubicación. Slack puede leer únicamente la parte inicial del HTML; conviene colocar las etiquetas de cabecera dentro de los primeros ~32 KB.

Si ninguna condición coincide y el único problema es la miniatura de Google, debe consultarse la sección «Una imagen, dos amos» de la pestaña Advanced.

Hoja de referencia de imágenes sociales

Especificación por plataforma — con fuentes honestas

Datos rápidos

• Un valor predeterminado seguro lo resuelve casi todo: URL HTTPS absoluta, ~1200×630 (1,91:1), archivo 100–300 KB.
• Solo URL absoluta — las rutas relativas se ignoran silenciosamente, no generan error.
• twitter:image recurre a og:image — una imagen suele servir para ambos.
• Ausencia ≠ roto: etiqueta ausente → imagen de respaldo obtenida por rastreo; imagen rota → a menudo no hay imagen en absoluto.
• Google quiere 16:9, las redes sociales quieren 1,91:1 — una imagen de 1200×630 (756K píxeles) supera los mínimos de Google de ≥1200px de ancho / ≥300K píxeles, pero no es 16:9.
• Formatos: JPEG/PNG en todas partes; WebP en la mayoría; los formatos animados no son fiables.
• Solo los 8 MB de Meta están documentados oficialmente — cualquier otro número de bytes es consenso de la comunidad.
• Arreglar la imagen no arregla los enlaces compartidos hasta que se solicite un nuevo rastreo.

Auditoría de imagen social — lista de verificación

Una pasada para confirmar que la imagen para compartir es correcta, accesible y con el tamaño adecuado:

• og:image es una URL absoluta https://... — sin rutas relativas.
• La imagen es aproximadamente 1200×630px (1,91:1) — al menos 600×315, nunca por debajo de 200×200.
• El tamaño del archivo es inferior a ~1 MB, idealmente 100–300 KB, para superar el límite de cada plataforma (el límite duro de Meta es 8 MB; otras descartan archivos grandes silenciosamente).
• El formato es JPEG, PNG o WebP — no un GIF/WebP animado para una tarjeta estática.
• La URL de la imagen carga en un navegador de incógnito nuevo — no 404, no protegida por autenticación, no bloqueada por robots.txt.
• La etiqueta og:image está en el HTML renderizado en el servidor, no inyectada por JavaScript (los bots sociales no renderizan JS).
• La etiqueta está al principio del <head> (ayuda a Slack, que solo lee los primeros ~32 KB).
• twitter:image está omitida (recurre a og:image) o configurada deliberadamente para un recorte diferente en X.
• La imagen evita un logotipo desnudo o texto pesado — bueno para el CTR y requerido para la elegibilidad de miniaturas de Google.
• Para la miniatura grande de Discover de Google, la página tiene max-image-preview:large (o AMP).
• Después de cualquier cambio, se ha solicitado un nuevo rastreo con el Facebook Sharing Debugger / LinkedIn Post Inspector para que los enlaces compartidos se actualicen.

Ejemplos prácticos

Casos concretos de antes/después para los modos de fallo que cubre este artículo.

URL absoluta vs. relativa

<!-- Silently ignored — a social crawler has no base to resolve this against -->
<meta property="og:image" content="/images/share.jpg" />

<!-- Correct — a full absolute HTTPS URL -->
<meta property="og:image" content="https://www.example.com/images/share.jpg" />

Una imagen para ambas plataformas (usando el respaldo)

<!-- twitter:image is omitted on purpose; X falls back to og:image -->
<meta property="og:image" content="https://www.example.com/share-1200x630.jpg" />
<meta property="og:image:width" content="1200" />
<meta property="og:image:height" content="630" />
<meta property="og:image:alt" content="Descriptive alt text for the share image" />

Un recorte diferente y más ajustado solo para X

<meta property="og:image" content="https://www.example.com/share-1200x630.jpg" />
<!-- Overrides the OG image on X specifically -->
<meta name="twitter:image" content="https://www.example.com/share-x-1200x675.jpg" />

Los dos modos de fallo, lado a lado

• Etiqueta ausente: sin og:image en absoluto → Facebook/LinkedIn obtienen una imagen del cuerpo o muestran un valor predeterminado genérico. Sin control, rara vez en blanco.
• Imagen rota: og:image apunta a https://www.example.com/old-hero.jpg que ahora no está disponible → varias plataformas muestran ninguna imagen de tarjeta, porque ya detectaron una referencia de imagen. El resultado puede ser peor que el de una etiqueta ausente.

Cálculo de tamaño para la pregunta de los “dos amos”

• Objetivo social: 1200×630 = 1,91:1 = 756 000 píxeles.
• Mínimo de Google: ≥1200 px de ancho y >300 000 píxeles. La imagen de 1200×630 supera ambos valores.
• Proporción preferida de Google: 16:9 —por ejemplo, 1280×720 = 921 600 píxeles—. La imagen de 1200×630 cumple los mínimos, pero no esa proporción. Para optimizar ambas superficies por separado puede declararse un primaryImageOfPage específico para Google.

Confirmar que una corrección de imagen social realmente surtió efecto

Debido a la caché, editar el archivo no demuestra que la corrección haya llegado a las tarjetas compartidas. Estas comprobaciones deben realizarse en orden antes de considerar terminado el cambio.

Confirmar que la plataforma volvió a rastrear la nueva imagen

Procedimiento: la URL se introduce en Facebook Sharing Debugger o LinkedIn Post Inspector y se solicita un nuevo rastreo, en lugar de limitarse a observar el resultado en caché. Resultado esperado: la vista previa muestra la imagen nueva y una marca de tiempo reciente. Interpretación del fallo: si continúa la imagen anterior, la caché no se actualizó o la etiqueta apunta al archivo equivocado. Ventana de monitoreo: inmediata; WhatsApp e iMessage pueden tardar algunas horas. Disparador de reversión: tras dos errores de recuperación, debe restablecerse la última URL funcional mientras se investiga.

Confirmación de que la URL es absoluta y accesible

Procedimiento: debe abrirse la URL exacta de og:image en una ventana de incógnito sin sesión ni caché, o puede ejecutarse curl -I. Resultado esperado: la imagen carga directamente, devuelve HTTP/1.1 200 OK y usa una URL https://... absoluta. Interpretación del fallo: un estado 404, una redirección al inicio de sesión o cualquier respuesta distinta de 200 impide el acceso del rastreador. Ventana de monitoreo: inmediata y después de cada corrección. Disparador de reversión: cualquier respuesta distinta de 200 exige restablecer temporalmente la última URL que devolvía 200.

Confirmación de que la etiqueta está en el HTML renderizado por el servidor, no inyectada por JavaScript

Procedimiento: debe consultarse el código fuente (Ctrl+U / Cmd+Option+U) o ejecutarse curl, y buscar og:image en el HTML sin procesar; el DOM de DevTools puede incluir etiquetas inyectadas que los bots no ven. Resultado esperado: la línea <meta property="og:image" content="https://..."> aparece en la respuesta original. Interpretación del fallo: si solo aparece en el panel Elements, la etiqueta se inyecta en el cliente. Ventana de monitoreo: inmediata y después de cambios en plantillas o hidratación. Disparador de reversión: si falta en dos comprobaciones consecutivas con curl, el cambio de plantilla debe considerarse defectuoso y revertirse.

Confirmación de que las dimensiones y el tamaño del archivo cumplen los límites de la plataforma

Procedimiento: deben comprobarse las dimensiones y el tamaño reales del archivo mediante una herramienta de inspección, el panel Network o curl -sI con Content-Length. Resultado esperado: aproximadamente 1200×630 px —al menos 600×315 y nunca menos de 200×200— y menos de ~1 MB, idealmente 100–300 KB. Interpretación del fallo: las dimensiones pequeñas producen una representación reducida o recortada; Meta rechaza archivos que superan 8 MB y otras plataformas descartan archivos pesados con límites menores. Ventana de monitoreo: inmediata. Disparador de reversión: por encima de ~1 MB o por debajo de 600×315, la imagen debe sustituirse por una versión comprimida y correctamente dimensionada antes del nuevo rastreo.

Recursos recomendados

Publicaciones relacionadas del autor

• Problemas de SEO de JavaScript y mejores prácticas — por qué los bots sociales que no ejecutan JavaScript no detectan un og:image inyectado en el cliente.
• La guía para principiantes del SEO técnico — contexto general de los metadatos en la página.

Ponencia del autor

• How Search Works (SlideShare) — explicación del rastreo, el renderizado y la indexación. Advertencia original: “This is my understanding of systems… not going to be 100% complete or accurate.” (traducción) «Esta es mi comprensión de los sistemas; no será completa ni exacta al 100 %».

Oficial

• Meta — Sharing Images — la única especificación de dimensiones y tamaño de archivo de fuente primaria (≥1200×630, mínimo 200×200, mínimo 600×315, 1,91:1, límite de 8 MB).
• The Open Graph protocol — las subpropiedades de og:image.
• Google — Specify a preferred image with metadata y Google Discover — los requisitos de imagen en miniatura propios de Google.
• Slack — Unfurling links in messages — confirma que Slack lee los metadatos de OG / X Card.

De la industria

• Google uses both schema.org markup and og:image meta tag for thumbnails in Google Search and Discover (Search Engine Land, Barry Schwartz, 2 de marzo de 2026) — cobertura del mismo día de la actualización de documentación de marzo de 2026.
• Google Clarifies How It Picks Thumbnails For Search, Discover (Search Engine Journal) — el artículo complementario sobre la misma actualización.
• Open Graph Meta Tags: Everything You Need to Know (Ahrefs, Michal Pecánek) — una referencia general sólida sobre Open Graph (no es de mi autoría).
• r/TechSEO — la comunidad para depurar vistas previas rotas y problemas de re-rastreo.

Evaluación: imágenes para compartir en redes sociales

Cinco preguntas rápidas sobre los requisitos de og:image y twitter:image. Se selecciona una respuesta para cada pregunta y después se comprueba el resultado.

Registro de cambios