Uma landing page pode funcionar perfeitamente quando aberta e ainda chegar mal a uma conversa, post ou mensagem. O compartilhamento mostra uma imagem antiga, corta o assunto principal, usa o título da home ou deixa a URL sem contexto. Em alguns canais, o cartão nem aparece.

Esse preview não é uma captura automática e confiável da página. Clientes de compartilhamento consultam metadados, baixam assets, aplicam seus próprios layouts e podem manter cache de versões anteriores. Por isso, testar somente o visual no navegador não fecha a entrega.

Este guia organiza uma revisão completa: definir a promessa do cartão, inspecionar Open Graph, validar a imagem e o acesso público, testar em consumidores reais e registrar o que foi confirmado. A meta é compartilhar uma URL coerente — não fabricar uma miniatura bonita que contradiz a landing.

Entenda as camadas do preview

Um cartão de compartilhamento costuma combinar:

  • URL que foi colada;
  • título;
  • descrição;
  • imagem;
  • nome ou domínio do site;
  • regras e cache do consumidor.

Essas peças vêm de fontes diferentes. O Open Graph Protocol define quatro propriedades básicas: og:title, og:type, og:image e og:url. Também recomenda propriedades como og:description, og:site_name, og:locale e informações estruturadas da imagem.

Ter as tags não obriga todo canal a produzir o mesmo cartão. Cada produto decide o que lê, quanto texto mostra, como corta a mídia e por quanto tempo mantém a resposta anterior. Trate o protocolo como uma base interoperável, não como renderização idêntica.

Defina o conteúdo aprovado antes do código

Registre uma ficha por página:

URL canônica:
tipo de página:
título aprovado:
descrição aprovada:
imagem social e versão:
texto alternativo da imagem:
idioma:
domínio de produção:
canais prioritários:
responsável pela aprovação:

Não peça ao agente para “criar um preview viral”. Isso abre espaço para uma promessa, número, depoimento ou urgência que não existe na página.

O cartão precisa ajudar a pessoa a decidir se abre o link. Ele não substitui a oferta e não deve parecer anúncio de outro produto.

Inspecione as tags no HTML final

Uma base comum para uma landing é:

<meta property="og:title" content="Título específico da página" />
<meta property="og:type" content="website" />
<meta property="og:url" content="https://exemplo.com/campanha/" />
<meta property="og:image" content="https://exemplo.com/assets/social/campanha.png" />
<meta property="og:description" content="Resumo fiel da página." />
<meta property="og:locale" content="pt_BR" />
<meta property="og:site_name" content="Nome da marca" />
<meta property="og:image:alt" content="Descrição objetiva da imagem social" />

O protocolo exige URL HTTP ou HTTPS para os campos do tipo URL. Na prática, use endereços absolutos no metadata publicado. Um caminho como /imagem.png pode funcionar no navegador da página e falhar para um coletor externo.

Confira no HTML produzido:

  • uma propriedade principal por página, sem valores conflitantes;
  • og:url igual à URL preferida daquela rota;
  • og:image apontando para o asset atual;
  • og:type coerente, como website ou article;
  • título e descrição compatíveis com o conteúdo;
  • og:image:alt descrevendo a imagem, não repetindo o slogan;
  • locale correto para o conteúdo em português brasileiro.

O guia sobre título e meta description complementa essa inspeção. Os textos podem compartilhar uma fonte, mas snippet de busca e cartão social não são o mesmo contrato.

Verifique a imagem social como asset de produção

Uma hero visualmente boa nem sempre funciona como imagem social. O recorte pode remover o produto, a escala pode tornar detalhes irreconhecíveis e texto incorporado pode ficar ilegível.

Avalie:

  • dimensões reais e proporção;
  • formato e tipo MIME;
  • peso do arquivo;
  • foco visual dentro de uma área segura;
  • contraste após redução;
  • ausência de texto minúsculo;
  • acesso sem autenticação;
  • URL HTTPS estável;
  • resposta sem bloqueio para coletores;
  • presença do asset na Version publicada.

O LinkedIn documenta para compartilhamentos tags Open Graph, imagem de pelo menos 1200 × 627 pixels, proporção recomendada de 1,91:1 e arquivo de até 5 MB. Essas medidas são referência para esse consumidor, não uma regra universal para toda rede.

Uma imagem 1200 × 630 costuma oferecer uma base horizontal próxima, mas teste os canais prioritários do projeto. Reserve margens: interfaces podem recortar ou sobrepor elementos.

O artigo sobre otimização de imagens antes de publicar cobre compressão, dimensões, formatos, carregamento e paths. Para a imagem social, acrescente o teste fora do fluxo visual da página.

Não coloque informação essencial somente na imagem

Se o preço, o prazo ou a condição existe apenas dentro do asset, o cartão pode perder a informação por recorte, falha de download ou ausência da imagem. Também fica mais difícil atualizar a campanha sem produzir outra arte.

Use título e descrição para comunicar o assunto. Use a imagem para reforçar identidade e contexto. Quando houver texto incorporado aprovado, confirme:

  • legibilidade no tamanho pequeno;
  • caracteres e acentos corretos;
  • correspondência com a página;
  • validade de preço, data e condição;
  • área segura em recortes diferentes;
  • versão correta no arquivo final.

Imagem gerada por IA não deve simular depoimento, interface, selo ou resultado que não foi aprovado. Para materiais de campanha, registre a origem do asset e mantenha a revisão de marca.

Teste o acesso como um coletor externo

Abrir a imagem no seu navegador autenticado não basta. Faça requisições públicas para a página e o asset.

Confirme:

status da página: 200 esperado
content-type da página: text/html
status da imagem: 200 esperado
content-type da imagem: image/png, image/jpeg ou formato aceito
redirecionamentos: intencionais e estáveis
autenticação: ausente para conteúdo público
robots ou firewall: compatíveis com a política do projeto

Um preview pode falhar quando:

  • a imagem depende de cookie;
  • a URL redireciona em loop;
  • o ambiente bloqueia bots ou datacenters;
  • o asset está em host temporário;
  • o caminho diferencia maiúsculas e minúsculas;
  • a resposta envia HTML de erro com status 200;
  • a imagem excede o limite do consumidor;
  • o deploy publicou metadata novo e asset antigo.

Não relaxe proteção do site inteiro apenas para fazer um debugger funcionar. Identifique o bloqueio e avalie a política correta.

Valide a URL final, não apenas o preview local

Metadados sociais frequentemente dependem do domínio. Antes do deploy, você consegue validar estrutura e assets do pacote. Depois, precisa testar os endereços absolutos reais.

Uma sequência segura:

  1. gere a build aprovada;
  2. inspecione o <head> de cada rota;
  3. confirme a imagem dentro do pacote;
  4. publique no Site e slug corretos;
  5. acompanhe o deploy até sucesso;
  6. abra a URL pública;
  7. busque as tags no HTML servido;
  8. abra a URL absoluta da imagem;
  9. use ferramentas oficiais dos canais prioritários quando disponíveis;
  10. faça um compartilhamento de teste controlado.

A documentação de Publicação explica o formato aceito pelo Site no Ar. Se for uma atualização, siga o fluxo de republicação no mesmo Site para não trocar a URL sem necessidade.

Trate cache como parte do diagnóstico

Você corrigiu as tags, publicou e ainda vê o cartão antigo. Antes de editar outra vez, separe três estados:

Estado Evidência
fonte atual arquivo ou componente contém o valor correto
publicação atual HTML público contém o valor correto
consumidor atual ferramenta ou compartilhamento buscou a versão nova

Se o HTML público está antigo, o problema é build, pacote ou deploy. Se o HTML está novo e o consumidor mostra o valor anterior, pode haver cache externo. Use o inspetor ou debugger oficial do canal, quando houver, para solicitar nova leitura ou observar o diagnóstico.

Não acrescente um parâmetro aleatório à URL de produção como primeira solução. Isso pode criar outra identidade de compartilhamento, fragmentar métricas e esconder o problema real.

Quando a imagem muda mantendo a mesma URL, alguns consumidores podem preservar a versão anterior. Uma estratégia de asset versionado pode ser adequada, desde que og:image seja atualizado e os arquivos antigos não sejam removidos antes de a nova versão estabilizar.

Compare canais sem exigir pixel perfeito

Monte uma matriz com os destinos que importam para a campanha:

Canal Título Descrição Imagem Recorte URL Resultado
canal A correto correto atual aceitável correta aprovado
canal B correto omitida atual aceitável correta aprovado com diferença esperada
canal C antigo antiga antiga — correta investigar cache

O critério não deve ser “todos parecem iguais”. Deve ser:

  • nenhuma informação está incorreta;
  • a página pode ser identificada;
  • a imagem continua compreensível;
  • o domínio e a URL são os esperados;
  • diferenças de layout do consumidor estão registradas;
  • a tarefa de abrir o link funciona.

Faça o teste em mensagem ou publicação de baixo risco antes de distribuir a campanha amplamente. Apague rascunhos ou posts de teste conforme a política do canal.

Dê ao agente um pedido verificável

Revise o preview de compartilhamento deste site criado por IA.
Escopo:
- fonte e versão: [repositório, branch e commit]
- build ou pacote: [caminho]
- URLs: [lista]
- canais prioritários: [lista]
- título, descrição e imagem aprovados: [referências]
1. Extraia Open Graph e metadados relacionados por rota.
2. Valide valores, URLs absolutas, acesso público e resposta da imagem.
3. Compare o conteúdo com a página e marque divergências.
4. Informe dimensões, formato e peso de cada imagem social.
5. Classifique problemas entre fonte, build, deploy e consumidor/cache.
6. Não altere copy, oferta, domínio, canonical ou imagem sem aprovação.
7. Não prometa aparência idêntica em todos os canais.
8. Entregue o inventário e a menor correção possível antes de editar.

Depois da aprovação, o agente pode corrigir a fonte, gerar a build e verificar o HTML público. A inspeção visual nos canais finais continua necessária porque o repositório não controla o layout nem o cache deles.

Registre o resultado para a próxima atualização

Feche a revisão com:

site_id e URL:
deploy e versão:
rotas verificadas:
imagem social e checksum ou versão:
tags confirmadas no HTML público:
canais testados:
diferenças esperadas:
cache atualizado ou pendente:
responsável e data:

Esse registro evita que a próxima pessoa troque a arte, atualize o title e esqueça o preview. Também separa claramente o que foi validado na fonte, na publicação e fora da plataforma.

Um bom cartão de compartilhamento começa com conteúdo coerente, passa por metadata correto e termina em teste real. O agente consegue automatizar o inventário e a validação técnica. A entrega só está pronta quando a URL pública, o asset e os consumidores prioritários contam a mesma história — mesmo que cada um a apresente de um jeito próprio.