Etiquetas Open Graph: qué hacen, tamaños y errores

Compartes un artículo en LinkedIn y aparece un cuadro gris con el dominio y ningún título. O aparece, pero con la imagen de hace tres meses porque la plataforma la guardó cuando publicaste el borrador. Ninguno de los dos problemas tiene que ver con tu posicionamiento en Google, y ninguno se arregla con un plugin que «activa Open Graph» sin que sepas qué emite.

Aquí separo lo que dice el protocolo de lo que hace cada plataforma, doy solo las cifras que figuran en documentación oficial y marco las que no existen, explico la caché de las previsualizaciones y enseño qué emite hoy cristofercruz.net, con lo que le falta.

Qué es Open Graph y quién lo lee

Open Graph es un protocolo de metadatos que Facebook creó y que hoy describe la web ogp.me. Consiste en etiquetas meta con atributo property dentro del <head> que dicen a quien rastree la página cuál es su título, su imagen y su URL «oficial». La página de ogp.me lo resume como la forma de que una página se convierta en un objeto rico en un grafo social.

Quien lee esas etiquetas no es el buscador, sino el rastreador de cada plataforma cuando alguien pega tu enlace. Meta usa facebookexternalhit; Slack usa Slackbot-LinkExpanding y su documentación dice que busca «oEmbed y Twitter Card / Open Graph»; WhatsApp rastrea con una petición GET y un User-Agent del tipo WhatsApp/2.x.x.x. Cada una cachea el resultado por su cuenta.

Eso explica casi todos los síntomas raros: lo que ves en LinkedIn puede ser distinto de lo que ves en Slack, porque son dos copias guardadas en dos momentos, leídas por dos sistemas con reglas propias.

Las etiquetas del protocolo: obligatorias y recomendadas

Según ogp.me, las cuatro propiedades obligatorias para toda página son og:title, og:type, og:image y og:url. La documentación de Meta para webmasters habla de otro conjunto básico: og:url, og:title, og:description y og:image. La diferencia es de enfoque, no una contradicción: una es la especificación y otra la lista de lo que Meta necesita para pintar la tarjeta. Yo emito las seis.

Dos detalles que ahorran errores. El primero: og:locale por defecto es en_US, así que si no lo declaras en una web en español, el protocolo asume inglés. El segundo: og:url debería coincidir con tu canonical; ogp.me la define como el ID permanente del objeto, así que si apunta a una URL distinta de la que indexas, estás dando dos identidades a la misma página (el canonical lo tienes explicado en mi guía de canonicals).

<meta property="og:type" content="article">
<meta property="og:title" content="Etiquetas Open Graph: tamaños y errores">
<meta property="og:description" content="Qué etiquetas necesitas y cómo refrescar la caché.">
<meta property="og:url" content="https://ejemplo.com/blog/open-graph/">
<meta property="og:image" content="https://ejemplo.com/img/open-graph.jpg">
<meta property="og:image:width" content="1200">
<meta property="og:image:height" content="630">
<meta property="og:image:alt" content="Esquema de una tarjeta de previsualización">
<meta property="og:site_name" content="Nombre del sitio">
<meta property="og:locale" content="es_ES">

ogp.me incluye en sus ejemplos la declaración prefix="og: https://ogp.me/ns#" en <html> o <head>. Yo no la declaro en mi web y no he medido si algún consumidor la exige; si trabajas con un sitio donde una plataforma no lee las etiquetas, añadirla es una prueba barata.

Twitter/X Cards: lo que sigue siendo necesario

X usa su propio conjunto de etiquetas, twitter:*. La que no tiene equivalente en Open Graph es twitter:card, que define el formato: summary para una miniatura cuadrada y summary_large_image para una imagen ancha. Mi web declara summary_large_image junto a twitter:title, twitter:description y twitter:image. Ojo con el atributo: estas etiquetas van con name=, no con property=.

Aquí tengo que marcar un límite. Intenté abrir la documentación oficial de Cards en developer.x.com y las URLs redirigen a docs.x.com, cuya portada trata solo de la API. No he encontrado una especificación vigente de Cards publicada por X. Lo que circula (que las twitter:* caen a su equivalente og:* si faltan, o que el validador de Cards ya no funciona) lo leo en guías de terceros que no puedo contrastar con X, así que no lo doy por documentado. Mi criterio práctico: declarar las dos familias explícitamente y no depender del fallback.

Slack, en cambio, sí documenta que lee metadatos de Open Graph y de X (Twitter) Card. Con esas dos familias presentes cubres a Meta, X y Slack con el mismo bloque de código.

Tamaños de la imagen og:image según cada plataforma

Sobre este tema circulan muchas cifras sin fuente. Esto es lo que figura en documentación oficial que he podido abrir y lo que no.

La documentación de WhatsApp que he leído pertenece a su plataforma de mensajería para empresas. Asumo que el cliente de uso diario se comporta igual, pero no lo documentan y no lo he medido.

La conclusión práctica es modesta: una imagen de 1200 x 630 px, relación 1,91:1, por debajo de 600 KB, cumple todo lo documentado a la vez. Con el texto importante en el centro, además, resiste que una plataforma la recorte. Sobre pesos y formatos en general tienes el detalle en mi guía de optimización de imágenes para SEO.

Open Graph y Google: qué sí y qué no

Open Graph no es una señal de ranking, y eso no lo dice una opinión: la página de Google con las meta etiquetas que soporta (description, robots, viewport, notranslate, etc.) no incluye ninguna og: ni twitter:. Google indica que ignora las meta etiquetas que no soporta.

Hay un matiz que casi nadie cuenta. En su documentación sobre title links, Google lista las fuentes que puede usar para generar el título que muestra en resultados, y entre ellas aparece «contenido en etiquetas meta og:title», junto al <title>, los encabezados y el texto destacado. No es una instrucción que puedas imponer: es una fuente más entre nueve. En cambio, la documentación de snippets dice que Google usa «principalmente el contenido de la página» y, a veces, la meta description; no menciona Open Graph.

Entonces, ¿sirve para algo en SEO? Indirectamente. Una tarjeta con título claro e imagen coherente puede mejorar el clic en redes, y más tráfico social puede traer visitas, menciones y enlaces. Esa cadena la repiten las guías que revisé, sin datos que la respalden. Yo tampoco los tengo: no he medido el CTR de compartidos de mi web, así que no te doy un porcentaje.

Si lo que te preocupa es controlar cómo aparecen tus fragmentos en Google, las herramientas son otras, como el atributo data-nosnippet o la meta robots.

Cómo previsualizan WhatsApp, LinkedIn y Slack

Cada plataforma tiene condiciones propias, y varias son técnicas, no de diseño. Meta, además, exige que el servidor soporte las codificaciones gzip y deflate.

• WhatsApp. Según su documentación, el <head> con las etiquetas debe estar dentro de los primeros 300 KB del HTML; og:title, og:description y og:url deben existir y no estar vacías; og:image debe ser URL absoluta. El título se muestra en un máximo de 2 líneas y, para la descripción, bastan unos 80 caracteres. Avisan de que pueden relajar requisitos, pero que no hay que depender de ello.
• Slack. Solicita solo parte de cada página con cabeceras Range y busca oEmbed y etiquetas Twitter Card / Open Graph. Si apuntan a una imagen, la descarga para validarla.
• LinkedIn. No he podido abrir documentación oficial de sus previsualizaciones. Sé que existe una herramienta, Post Inspector, y que las guías la describen como el sitio para refrescar un enlace. Lo que cuentan sobre medidas y duración de caché no lo cito.

El requisito de los 300 KB importa en webs con CSS en línea o muchos scripts antes de las etiquetas: pon el bloque de metadatos arriba del <head>.

Caché de previsualizaciones y cómo refrescarlas

Es el problema que más molesta y el que menos tratan las guías en español que revisé. Las plataformas guardan la tarjeta la primera vez que alguien comparte el enlace.

Lo que documenta Meta con claridad:

• Las imágenes se cachean «según la URL» y no se actualizan a menos que la URL cambie. Para sustituir una imagen, publica la nueva en otra URL y conserva la antigua, porque las publicaciones existentes pueden seguir apuntando a ella.
• El rastreador guarda la imagen la primera vez que se comparte la URL, de modo que quien comparte primero puede no verla pintada. Meta recomienda precargarla con el Sharing Debugger o por la API de Graph, y declarar og:image:width y og:image:height para que se renderice a la primera.
• El Sharing Debugger muestra las etiquetas que rastrea, errores y avisos, y además fuerza un nuevo rastreo de la página.
• Actualizar la imagen no cambia las previsualizaciones de publicaciones ya compartidas; se refrescan por separado.

Slack documenta una caché global de unos 30 minutos para sus respuestas, lo que hace que ahí el problema dure poco. De la caché de LinkedIn y de WhatsApp no tengo cifras oficiales; no repito las que veo en blogs.

article:published_time, author y otras etiquetas de artículo

Cuando og:type vale article, ogp.me define un espacio de nombres con propiedades adicionales: article:published_time (primera publicación), article:modified_time, article:expiration_time, article:author (perfil de los autores), article:section y article:tag. Las fechas van en formato de fecha y hora.

Lo que no puedo darte es qué plataforma pinta cada una. En las páginas de Meta, Slack y WhatsApp que he leído no se describe ningún uso de article:* en la tarjeta. Mi lectura es que son metadatos estructurales que algunos consumidores pueden aprovechar, no algo que cambie el aspecto del enlace hoy. Para que Google entienda fecha y autor, el camino es el marcado de datos estructurados BlogPosting, que sí uso (más abajo).

<meta property="article:published_time" content="2026-09-02T09:00:00+02:00">
<meta property="article:modified_time" content="2026-09-02T09:00:00+02:00">
<meta property="article:author" content="https://ejemplo.com/sobre-mi/">
<meta property="article:section" content="Metaetiquetas">

Errores típicos con Open Graph

Otro error silencioso es bloquear a los rastreadores. Meta advierte de que facebookexternalhit puede saltarse el robots.txt en comprobaciones de seguridad e integridad, y Slack descarga la imagen para validarla. No he probado qué pasa con cada plataforma si bloqueas la carpeta de imágenes, así que no lo des por seguro: revisa el robots.txt como se explica en mi guía de robots.txt.

Lo que emite cristofercruz.net y lo que le falta

Esto es lo que he leído en el código (includes/header.php y includes/article-page.php) y en el HTML que devuelve una entrada del blog.

Qué emite

• og:type es website por defecto y article en las entradas del blog (lo fija article-page.php).
• og:locale es_ES y og:site_name «Cristofer Cruz — Consultor SEO», en todas las páginas.
• og:title y og:description reutilizan el título SEO y la meta description de cada página. og:url es el mismo valor que el canonical.
• og:image es una URL absoluta: SITE_URL más la ruta del archivo con hash en el nombre (por ejemplo, https://cristofercruz.net/assets/cache/…webp). Ese hash cambia si cambia el archivo, que es justo lo que Meta pide para invalidar su caché por URL. La política de caché del resto de recursos la cuento en mi guía de caché SEO.
• twitter:card con summary_large_image, más twitter:title, twitter:description y twitter:image con los mismos valores.
• Las etiquetas aparecen pronto: en la entrada de caché que medí, og:image queda en el byte 1.441 de un HTML de unos 163 KB sin comprimir, muy dentro de los 300 KB que pide WhatsApp. El .htaccess activa mod_deflate para el HTML, y Meta exige las codificaciones gzip o deflate.
• El robots.txt no bloquea imágenes ni /blog/: solo carpetas internas como /includes/ y /tools/.

De dónde sale la imagen

En una entrada del blog, article-page.php busca assets/blog/covers/SLUG.webp y, si no existe, usa assets/og-cristofer-cruz-v3.jpg. Esa imagen de reserva mide 1200 x 630 px y pesa 89.151 bytes (unos 87 KB). Las portadas de las entradas miden 1600 x 900 px; la de caché pesa 26.216 bytes (unos 26 KB) en WebP. El resto de páginas usan la imagen de reserva, salvo alguna con la suya propia, como la de /sobre-mi/.

Carencias reales

1. El tamaño declarado no es el real en el blog. header.php escribe siempre og:image:width 1200 y og:image:height 630, pero las portadas son de 1600 x 900 (relación 1,78:1, no 1,91:1). Al adaptarlas a 1,91:1 se pierden unos 63 px de alto en total. Mi cabecera dice una cosa y el archivo otra.
2. Las portadas son WebP. Meta solo lista JPG, GIF y PNG como tipos MIME de og:image. Existe una versión JPG de cada portada, pero hoy no es la que se declara. No he comprobado cómo lo trata cada plataforma.
3. og:image:alt es genérico. Es el mismo texto («Cristofer Cruz, consultor SEO…») en todas las páginas, también en entradas cuya portada dice otra cosa. Cómo redactarlo está en mi guía de texto alternativo.
4. No emito article:published_time, modified_time, author ni section. La fecha y el autor sí están en el JSON-LD BlogPosting de cada entrada (datePublished, dateModified, author), no en etiquetas Open Graph.
5. No uso twitter:site, twitter:creator ni fb:app_id. Este último solo hace falta para Facebook Insights, que no uso.
6. No declaro og:image:type. Es opcional, pero sirve de apoyo si el formato no es el habitual.
7. og:title arrastra el sufijo del título SEO («| Cristofer Cruz»), que repite lo que ya dice og:site_name.

Tampoco tengo medido si estas carencias cuestan clics. Son diferencias entre lo que hace mi web y lo que documentan las fuentes.

Cómo auditar tus etiquetas Open Graph

1. Mira el HTML que recibe un rastreador. Con curl -s -A "facebookexternalhit/1.1" https://tudominio.com/pagina/ | grep -i -E 'og:|twitter:' ves las etiquetas tal como las entrega el servidor, sin que tu navegador ejecute JavaScript. Si no aparecen, las inyecta JS y ningún rastreador social las verá (lo desarrollo en mi artículo de CSR, SSR, SSG e ISR).
2. Comprueba la imagen. Abre la URL de og:image en el navegador y con curl -I: debe responder 200, sin redirecciones largas, con content-type de imagen y un peso razonable. Compara sus medidas reales con og:image:width y height.
3. Pasa el depurador de Meta. Te enseña lo que rastrea, los avisos y, de paso, fuerza el nuevo rastreo. Hazlo cada vez que cambies una imagen o un título.
4. Comparte en privado. Pega la URL en un chat de WhatsApp contigo mismo, en un canal de Slack de pruebas y, si tienes cuenta, en un borrador de LinkedIn. Es lo único que te dice lo que verá la gente.

Si compartes contenido a menudo y quieres que cada pieza salga con su tarjeta cuidada, es parte de lo que trabajo en marketing de contenidos.

Preguntas frecuentes sobre Open Graph

Referencias

1. The Open Graph protocol ogp.me
2. Sharing for Webmasters Meta for Developers
3. Best Practices: images Meta for Developers
4. Link Previews WhatsApp Business Platform, Meta
5. Slack web crawlers Slack API
6. Unfurling links in messages Slack Developer Docs
7. Meta tags that Google supports Google Search Central
8. Influence your title links in search results Google Search Central