Pré-visualização gratuita de Open Graph e cartões sociais

O que é o link unfurling e por que é importante?

Quando cola um URL no Facebook, Twitter, LinkedIn, Slack, Discord, iMessage ou WhatsApp, a plataforma envia um crawler para esse URL, lê as meta tags dentro do head da página e renderiza um cartão de pré-visualização com título, descrição e imagem. Essa pré-visualização é chamada de unfurl, link card ou cartão social consoante a plataforma. É a primeira coisa que cada utilizador vê antes de decidir se clica. Um cartão bem renderizado aumenta significativamente as taxas de clique em comparação com um link azul simples, e um cartão com falhas elimina completamente o engagement.

O sistema assenta no protocolo Open Graph, que o Facebook publicou em 2010 para dar às plataformas de partilha uma forma padronizada de extrair uma pré-visualização limpa. O Open Graph define um namespace de meta tags prefixadas com og: — og:title, og:description, og:image, og:url, og:type, e uma longa lista de campos opcionais para vídeo, áudio, artigos e produtos. O Twitter criou o seu próprio protocolo Twitter Card em 2012, com um namespace twitter: que substitui o Open Graph quando ambos estão presentes. O LinkedIn, Slack, Discord e a maioria das aplicações de mensagens leem o Open Graph diretamente e acrescentam as suas próprias particularidades.

Cada plataforma aplica a sua própria lógica de renderização. O Facebook e o LinkedIn renderizam uma imagem de destaque com título e descrição abaixo, ocupando cerca de quatro linhas no feed. O cartão summary_large_image do Twitter renderiza uma imagem de destaque com o host do URL abaixo. O Slack renderiza um anexo compacto com uma miniatura inline pequena. O Discord renderiza um cartão que inclui qualquer embed de vídeo ou áudio quando o tipo está definido. O iMessage renderiza um cartão em formato vertical com uma imagem quadrada. O mesmo conjunto de meta tags alimenta todos eles, mas o resultado visual varia o suficiente para que a pré-visualização em cada plataforma separadamente seja a única forma de detetar problemas.

O custo de um unfurl com falhas é real. Um tweet de campanha sem imagem recebe uma fração do engagement de um com cartão. Uma publicação no LinkedIn que aparece com um ícone de globo genérico em vez da imagem de destaque do artigo parece inacabada. Um canal Slack onde um link apresenta uma imagem 404 quebra a confiança no próprio link. Nenhum destes casos é catastrófico por si só, mas numa equipa de marketing ou conteúdo que publica dezenas de links por semana, a perda acumulada é significativa.

Como usar esta ferramenta de pré-visualização

O visualizador renderiza um URL em todas as principais plataformas de uma só vez, para que possa detetar problemas específicos de cada plataforma sem ter de testar em cada uma separadamente.

Passo 1 — Cole o seu URL. Introduza um URL completo no campo de entrada. O crawler obtém a página, lê o head e extrai todas as tags Open Graph e Twitter Card relevantes. Se a página exigir autenticação ou estiver protegida pelo desafio de bot do Cloudflare, a obtenção falha e o visualizador mostra o erro para que saiba que o unfurl também falhará nas plataformas reais.

Passo 2 — Analise os cinco cartões de plataforma. Facebook, LinkedIn, Twitter, Slack e Discord são renderizados lado a lado. Procure imagens em falta, texto truncado e recortes de proporção que cortem a sua imagem de destaque. O visualizador assinala as tags obrigatórias em falta a vermelho e as dimensões inadequadas a âmbar.

Passo 3 — Edite e volte a pré-visualizar. Atualize as suas meta tags na página de origem e clique em Atualizar. O visualizador obtém uma cópia nova sem cache, para que veja o novo estado imediatamente. Quando estiver correto aqui, as partilhas ao vivo nas plataformas reais corresponderão — desde que se lembre de invalidar as caches do Facebook e do LinkedIn após a atualização.

Particularidades de renderização específicas de cada plataforma

As mesmas meta tags produzem cartões diferentes em plataformas diferentes porque cada uma tem o seu próprio motor de renderização. Conhecer as diferenças poupa tempo quando algo parece errado numa plataforma mas correto noutras.

Facebook

O Facebook lê og:title, og:description, og:image e og:url e renderiza um cartão de destaque com a imagem no topo, título a negrito abaixo, descrição em cinzento e o domínio do host em letras maiúsculas pequenas na parte inferior. A imagem é recortada para uma proporção de 1,91:1 se não corresponder. O Facebook guarda em cache o resultado de forma agressiva — na primeira vez que um URL é partilhado, o crawler extrai as tags e as partilhas subsequentes reutilizam o cartão em cache durante horas ou dias. Para atualizar, cole o URL no Sharing Debugger e clique em Scrape Again. Não existe outra forma fiável de invalidar a cache. O crawler do Open Graph identifica-se com o agente de utilizador facebookexternalhit.

Twitter

O Twitter lê primeiro twitter:card, twitter:title, twitter:description, twitter:image e twitter:site, recorrendo aos equivalentes og: quando a tag twitter: está ausente. O valor de twitter:card determina o layout: summary produz uma miniatura quadrada pequena à esquerda do título e descrição, ocupando cerca de um tweet de espaço vertical; summary_large_image produz uma grande imagem de destaque acima do título com o host do URL abaixo, duplicando o espaço visual. A validação do Twitter Card migrou para o Twitter Ads em 2022, pelo que o Validador de Cards independente deixou de existir, mas a plataforma continua a respeitar o protocolo exatamente como antes.

LinkedIn

O LinkedIn lê o Open Graph de forma idêntica ao Facebook e renderiza um cartão de destaque semelhante. O crawler é o LinkedInBot, e guarda os resultados em cache durante cerca de sete dias, a menos que invalide via Post Inspector em linkedin.com/post-inspector. O LinkedIn exige que o og:image tenha pelo menos 1200 por 627 pixels (note o limite mínimo ligeiramente diferente) e menos de 5MB. As imagens servidas via HTTP são silenciosamente rejeitadas. O LinkedIn também ignora as sugestões og:image:width e og:image:height ao validar, por isso teste sempre com uma obtenção real.

Slack

O Slack lê Open Graph mas renderiza um anexo mais compacto por padrão. O og:title torna-se o título do link, og:description torna-se o corpo e og:image torna-se uma miniatura inline pequena ao lado. Os workspaces podem configurar o comportamento de unfurl por canal e por aplicação, o que significa que o mesmo link pode aparecer como um cartão completo num canal e como um URL em texto simples noutro. O Slack também elimina duplicados de unfurls dentro de uma janela de tempo curta, pelo que colar novamente o mesmo URL após editar meta tags muitas vezes mostra a versão em cache. As contas de bots e os webhooks de entrada têm definições de unfurl separadas que podem precisar de ser ativadas explicitamente.

Discord

O Discord renderiza cartões Open Graph como embeds dentro da mensagem, com a imagem renderizada inline como destaque. Também respeita og:video e incorpora players de vídeo diretamente quando presentes, tornando o Discord uma das poucas plataformas principais onde as tags Open Graph de vídeo têm utilidade. As cores dos cartões provêm de theme-color no head meta quando nenhuma outra cor é especificada. O crawler é o Discordbot, e ao contrário do Facebook ou LinkedIn, o Discord não guarda em cache de forma agressiva — a maioria das edições refletem em minutos.

Requisitos de tamanho de imagem por plataforma

A razão mais comum para um cartão ser reduzido a miniatura ou falhar na renderização é a imagem. Cada plataforma tem as suas próprias dimensões preferidas e tamanhos mínimos.

Facebook e LinkedIn preferem 1200 por 630 pixels numa proporção de 1,91:1. Ambos renderizarão um cartão com imagens até 600 pixels no lado maior, mas reduzem para um layout de miniatura pequena abaixo desse limite. O tamanho do ficheiro deve ficar abaixo de 5MB. PNG e JPG funcionam ambos; WebP é suportado pelo Facebook mas não consistentemente pelo LinkedIn, por isso use PNG ou JPG para og:image.

Twitter prefere 1200 por 675 pixels para summary_large_image, uma proporção 16:9 ligeiramente mais larga. O mínimo é 300 por 157, mas qualquer coisa abaixo de 600 de largura produz uma queda visível de qualidade. Para cartões summary, a imagem é quadrada e recortada para 144 por 144 no feed; projete para que o centro da imagem transmita o significado.

Slack aceita quase qualquer tamanho e dimensiona a imagem para caber numa miniatura pequena. A miniatura tem aproximadamente 80 por 80 pixels na renderização lateral. O detalhe de uma imagem com 1200 de largura é desperdiçado neste layout, mas a mesma imagem funciona bem porque o Slack redimensiona em vez de recortar.

Discord renderiza a imagem completa inline até à maior dimensão suportada pela interface de chat, tipicamente até 1280 pixels de largura no computador. Imagens maiores são reduzidas com qualidade preservada. O Discord recorta imagens altas para uma proporção máxima, por isso evite imagens em formato retrato para cartões de destaque.

As tags og:image:width e og:image:height são sugestões de dimensão que os crawlers usam para reservar espaço no layout antes do carregamento da imagem. Não alteram a imagem, mas ajudam a pré-visualização a renderizar sem uma mudança de layout. Inclua-as sempre que forem estáveis e use as dimensões reais em pixels do ficheiro que está a servir.

Erros comuns que prejudicam a partilha

URLs relativos em og:image. O Open Graph e o Twitter Card exigem URLs absolutos. Um caminho como /og.png é silenciosamente rejeitado por todas as principais plataformas. Use sempre a forma completa https://exemplo.com/og.png.

og:image HTTP numa página HTTPS. Misturar URLs de imagem HTTP numa página HTTPS faz com que a maioria das plataformas rejeite a imagem. O cartão é reduzido a miniatura ou renderiza sem imagem de todo. Todos os URLs do Open Graph devem ser HTTPS independentemente do protocolo da página.

og:image:width e og:image:height em falta. Sem sugestões de dimensão, os crawlers aguardam o carregamento da imagem antes de decidir o layout do cartão. Em servidores de imagem lentos, a plataforma esgota o tempo limite e recorre a um cartão menor. Inclua sempre as sugestões ao servir uma imagem de tamanho conhecido.

og:image idêntico em milhares de páginas. Uma única imagem partilhada funciona para a página inicial, mas faz com que todos os artigos pareçam idênticos quando partilhados. Imagens OG dinâmicas por template, geradas no servidor a partir do título e de um fundo, dão a cada página um cartão distintivo sem trabalho manual.

Esquecer de atualizar a cache do Facebook após edições. As edições feitas depois de um URL já ter sido partilhado são invisíveis até re-fazer o scrape via Sharing Debugger. As equipas que atualizam meta tags sem invalidar a cache muitas vezes pensam que as suas alterações não funcionaram, quando na realidade as plataformas estão a mostrar versões antigas em cache.

Valor errado em twitter:card. Definir summary quando tem uma imagem de destaque com 1200 de largura produz um cartão de miniatura pequena, desperdiçando o recurso. Definir summary_large_image sem uma imagem grande real produz um cartão com espaço vazio onde o destaque deveria estar. Faça corresponder o tipo de cartão ao tamanho de imagem que está a servir.

Descrição copiada literalmente do corpo da página. Um parágrafo inicial truncado como og:description raramente motiva o clique. As pré-visualizações de partilha são texto de vendas em 200 caracteres; trate-as dessa forma e escreva texto de descrição que enquadre o link, não que resuma a página.

Casos extremos que ninguém menciona

Os crawlers do Open Graph veem uma versão diferente da sua página em relação aos browsers. Tipicamente não executam JavaScript, não armazenam cookies e têm tempos limite mais curtos do que uma obtenção normal. As aplicações de página única que injetam meta tags do lado do cliente via React Helmet ou document.head produzem cartões vazios porque o crawler lê o HTML inicial renderizado pelo servidor antes de qualquer JS ser executado. A solução é renderizar as meta tags do lado do servidor via metadados do Next.js, useHead do Nuxt ou equivalente. Algumas configurações de CDN também bloqueiam agentes de utilizador de bots na edge, devolvendo um 403 ao facebookexternalhit enquanto servem humanos normalmente — um bug invisível até alguém partilhar o link e o cartão falhar na renderização.