Vista previa gratuita de Open Graph y tarjetas sociales

¿Qué es el despliegue de enlaces y por qué importa?

Cuando pegas una URL en Facebook, Twitter, LinkedIn, Slack, Discord, iMessage o WhatsApp, la plataforma envía un crawler a esa URL, lee las metaetiquetas dentro del head de la página y renderiza una tarjeta de vista previa con título, descripción e imagen. Esa vista previa se llama unfurl, tarjeta de enlace o tarjeta social según la plataforma. Es lo primero que ve cada usuario antes de decidir si hace clic. Una tarjeta bien renderizada aumenta las tasas de clics por un amplio margen en comparación con un simple enlace azul, y una tarjeta rota destruye el engagement por completo.

El sistema funciona sobre el protocolo Open Graph, que Facebook publicó en 2010 para dar a las plataformas de compartición una forma estándar de extraer una vista previa limpia. Open Graph define un espacio de nombres de metaetiquetas con el prefijo og: — og:title, og:description, og:image, og:url, og:type, y una larga cola de campos opcionales para vídeo, audio, artículos y productos. Twitter construyó su propio protocolo Twitter Card encima en 2012, con un espacio de nombres twitter: que anula Open Graph cuando ambos están presentes. LinkedIn, Slack, Discord y la mayoría de las aplicaciones de mensajería leen Open Graph directamente y añaden sus propias particularidades.

Cada plataforma aplica su propia lógica de renderizado. Facebook y LinkedIn renderizan una imagen hero con título y descripción debajo, ocupando aproximadamente cuatro líneas del feed. La tarjeta summary_large_image de Twitter renderiza una imagen hero con el host de la URL debajo. Slack renderiza un adjunto compacto con una miniatura pequeña en línea. Discord renderiza una tarjeta que incorpora cualquier vídeo o audio embebido cuando el tipo está configurado. iMessage renderiza una tarjeta en formato vertical con una imagen cuadrada. El mismo conjunto de metaetiquetas impulsa a todos ellos, pero el resultado visual varía lo suficiente como para que previsualizar en cada superficie por separado sea la única forma de detectar problemas.

El coste de un unfurl roto es real. Un tweet de campaña sin imagen obtiene una fracción del engagement de uno con tarjeta. Una publicación en LinkedIn que despliega un icono de globo genérico en lugar del hero del artículo parece inacabada. Un canal de Slack donde un enlace despliega una imagen 404 rompe la confianza en el propio enlace. Ninguno de estos casos es catastrófico por sí solo, pero en un equipo de marketing o contenido que publica decenas de enlaces a la semana, la pérdida acumulada es significativa.

Cómo usar esta herramienta de vista previa

El previsualizador renderiza una URL en todas las plataformas principales a la vez, para que puedas detectar problemas específicos de cada plataforma sin tener que probar en cada una por separado.

Paso 1 — Pega tu URL. Introduce una URL completa en el campo de entrada. El crawler obtiene la página, lee el head y extrae todas las etiquetas Open Graph y Twitter Card relevantes. Si la página requiere autenticación o está detrás del desafío de bots de Cloudflare, la solicitud falla y el previsualizador muestra el error para que sepas que el unfurl también fallará en las plataformas reales.

Paso 2 — Revisa las cinco tarjetas de plataforma. Facebook, LinkedIn, Twitter, Slack y Discord se renderizan en paralelo. Busca imágenes faltantes, texto truncado y recortes de relación de aspecto que corten tu imagen hero. El previsualizador marca las etiquetas requeridas que faltan en rojo y las dimensiones subóptimas en ámbar.

Paso 3 — Edita y previsualiza de nuevo. Actualiza las metaetiquetas en la página fuente y haz clic en Actualizar. El previsualizador obtiene una copia nueva sin ninguna caché, de modo que ves el nuevo estado de inmediato. Una vez que se vea correcto aquí, los compartidos en vivo en las plataformas reales coincidirán — siempre que recuerdes invalidar las cachés de Facebook y LinkedIn después de la actualización.

Particularidades de renderizado por plataforma

Las mismas metaetiquetas producen tarjetas diferentes en distintas plataformas porque cada una tiene su propio motor de renderizado. Conocer las diferencias ahorra tiempo cuando algo se ve mal en una plataforma pero bien en las demás.

Facebook

Facebook lee og:title, og:description, og:image y og:url y renderiza una tarjeta hero con la imagen arriba, el título en negrita debajo, la descripción en gris y el dominio host en versalitas al fondo. La imagen se recorta a una relación de aspecto 1,91:1 si no coincide. Facebook almacena el resultado en caché de forma agresiva — la primera vez que se comparte una URL, el crawler extrae las etiquetas y los compartidos posteriores reutilizan la tarjeta en caché durante horas o días. Para actualizar, pega la URL en el Sharing Debugger y haz clic en Scrape Again. No hay otra forma fiable de invalidar la caché. El crawler de Open Graph se identifica con el agente de usuario facebookexternalhit.

Twitter

Twitter lee twitter:card, twitter:title, twitter:description, twitter:image y twitter:site primero, recurriendo a los equivalentes og: cuando falta la etiqueta twitter:. El valor de twitter:card determina el diseño: summary produce una miniatura cuadrada pequeña a la izquierda del título y la descripción, ocupando aproximadamente el espacio vertical de un tuit; summary_large_image produce una imagen hero grande sobre el título con el host de la URL debajo, duplicando el espacio visual. La validación de Twitter Card se trasladó a Twitter Ads en 2022, por lo que el Validador de Cards independiente ya no existe, pero la plataforma sigue respetando el protocolo exactamente igual que antes.

LinkedIn

LinkedIn lee Open Graph de forma idéntica a Facebook y renderiza una tarjeta hero similar. El crawler es LinkedInBot, y almacena los resultados en caché durante unos siete días a menos que los invalides a través del Post Inspector en linkedin.com/post-inspector. LinkedIn requiere que la og:image tenga al menos 1200 por 627 píxeles (nota el límite inferior ligeramente diferente) y pese menos de 5 MB. Las imágenes servidas por HTTP se descartan silenciosamente. LinkedIn también ignora las sugerencias og:image:width y og:image:height al validar, así que siempre prueba con una obtención real.

Slack

Slack lee Open Graph pero renderiza un adjunto más compacto por defecto. El og:title se convierte en el título del enlace, og:description en el cuerpo, y og:image en una miniatura pequeña en línea al lado. Los espacios de trabajo pueden configurar el comportamiento de unfurl por canal y por aplicación, lo que significa que el mismo enlace puede aparecer como una tarjeta completa en un canal y como una URL de texto plano en otro. Slack también deduplica los unfurls dentro de una ventana de tiempo corta, de modo que volver a pegar la misma URL después de editar las metaetiquetas a menudo muestra la versión en caché. Las cuentas de bot y los webhooks entrantes tienen configuraciones de unfurl separadas que puede ser necesario activar explícitamente.

Discord

Discord renderiza las tarjetas Open Graph como embeds dentro del mensaje, con la imagen renderizada en línea como hero. También respeta og:video e incorpora reproductores de vídeo directamente cuando está presente, lo que hace de Discord una de las pocas plataformas principales donde las etiquetas Open Graph de vídeo realmente valen la pena. Los colores de las tarjetas provienen de theme-color en el head meta cuando no se especifica otro color. El crawler es Discordbot, y a diferencia de Facebook o LinkedIn, Discord no almacena en caché de forma agresiva — la mayoría de las ediciones se reflejan en minutos.

Requisitos de tamaño de imagen por plataforma

La razón más común por la que una tarjeta se degrada a miniatura o no se renderiza es la imagen. Cada plataforma tiene sus propias dimensiones preferidas y tamaños mínimos.

Facebook y LinkedIn prefieren 1200 por 630 píxeles con una relación de aspecto 1,91:1. Ambas renderizarán una tarjeta con imágenes de hasta 600 píxeles en el lado largo, pero degradan a un diseño de miniatura pequeña por debajo de ese umbral. El tamaño del archivo debe mantenerse por debajo de 5 MB. PNG y JPG funcionan ambos; WebP es compatible con Facebook pero no de forma consistente con LinkedIn, así que usa PNG o JPG para la og:image.

Twitter prefiere 1200 por 675 píxeles para summary_large_image, una relación 16:9 ligeramente más ancha. El mínimo es 300 por 157, pero cualquier cosa de menos de 600 píxeles de ancho produce una caída visible de calidad. Para las tarjetas summary, la imagen es cuadrada y se recorta a 144 por 144 en el feed; diseña pensando en que el centro de la imagen debe transmitir el significado.

Slack acepta casi cualquier tamaño y escala la imagen para que encaje en una miniatura pequeña. La miniatura tiene aproximadamente 80 por 80 píxeles en el renderizado lateral. El detalle de una imagen de 1200 píxeles de ancho se desperdicia en este diseño, pero la misma imagen funciona bien porque Slack escala en lugar de recortar.

Discord renderiza la imagen completa en línea hasta la mayor dimensión que admite la superficie del chat, típicamente hasta 1280 píxeles de ancho en escritorio. Las imágenes más grandes se escalan hacia abajo preservando la calidad. Discord sí recorta las imágenes altas a una relación de aspecto máxima, así que evita las imágenes en formato retrato para las tarjetas hero.

Las etiquetas og:image:width y og:image:height son sugerencias de dimensión que los crawlers usan para reservar espacio de maquetación antes de que la imagen termine de cargarse. No cambian la imagen, pero ayudan a que la vista previa se renderice sin saltos de diseño. Inclúyelas siempre que sean estables, y usa las dimensiones reales en píxeles del archivo que estás sirviendo.

Errores comunes que perjudican el compartido

URLs relativas en og:image. Open Graph y Twitter Card requieren URLs absolutas. Una ruta como /og.png es rechazada silenciosamente por todas las plataformas principales. Usa siempre la forma completa https://example.com/og.png.

og:image con HTTP en una página HTTPS. Mezclar URLs de imagen HTTP en una página HTTPS hace que la mayoría de las plataformas descarten la imagen. La tarjeta se degrada a miniatura o se renderiza sin imagen. Todas las URLs de Open Graph deben ser HTTPS independientemente del protocolo de la página.

og:image:width y og:image:height ausentes. Sin sugerencias de dimensión, los crawlers esperan a que la imagen se cargue antes de decidir el diseño de la tarjeta. En servidores de imágenes lentos, la plataforma agota el tiempo de espera y recurre a una tarjeta más pequeña. Incluye siempre las sugerencias cuando sirvas una imagen de tamaño conocido.

og:image idéntica en miles de páginas. Una imagen compartida única funciona para la página de inicio, pero hace que todos los artículos parezcan idénticos cuando se comparten. Las imágenes OG dinámicas con plantilla, generadas en el servidor a partir del título y un fondo, dan a cada página una tarjeta distintiva sin trabajo manual.

Olvidarse de refrescar la caché de Facebook después de editar. Las ediciones realizadas después de que una URL ya fue compartida son invisibles hasta que vuelves a hacer scrape mediante el Sharing Debugger. Los equipos que actualizan metaetiquetas sin invalidar la caché a menudo creen que sus cambios no funcionaron, cuando en realidad las plataformas están mostrando versiones antiguas en caché.

Valor incorrecto de twitter:card. Establecer summary cuando tienes una imagen hero de 1200 píxeles de ancho produce una tarjeta de miniatura pequeña, desperdiciando el recurso. Establecer summary_large_image sin una imagen grande real produce una tarjeta con espacio vacío donde debería estar el hero. Haz coincidir el tipo de tarjeta con el tamaño de imagen que estás sirviendo.

Descripción copiada literalmente del cuerpo de la página. Un párrafo introductorio truncado como og:description rara vez invita al clic. Las vistas previas de compartido son texto de ventas en 200 caracteres; trátalo como tal y escribe texto de descripción que enmarque el enlace, no que resuma la página.

Casos extremos que nadie menciona

Los crawlers de Open Graph ven una versión diferente de tu página a la que ven los navegadores. Típicamente no ejecutan JavaScript, no almacenan cookies y agotan el tiempo antes que una solicitud normal. Las aplicaciones de una sola página que inyectan metaetiquetas en el cliente mediante React Helmet o document.head producen tarjetas vacías porque el crawler lee el HTML inicial renderizado en el servidor antes de que se ejecute ningún JS. La solución es renderizar las metaetiquetas en el servidor mediante los metadatos de Next.js, el useHead de Nuxt, o equivalentes. Algunas configuraciones de CDN también bloquean los agentes de usuario de bots en el borde, devolviendo un 403 a facebookexternalhit mientras sirven a los usuarios normalmente — un error que es invisible hasta que alguien comparte el enlace y la tarjeta no se renderiza.