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:urligual à URL preferida daquela rota;og:imageapontando para o asset atual;og:typecoerente, comowebsiteouarticle;- título e descrição compatíveis com o conteúdo;
og:image:altdescrevendo 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 esperadocontent-type da página: text/htmlstatus da imagem: 200 esperadocontent-type da imagem: image/png, image/jpeg ou formato aceitoredirecionamentos: intencionais e estáveisautenticação: ausente para conteúdo públicorobots ou firewall: compatíveis com a política do projetoUm 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:
- gere a build aprovada;
- inspecione o
<head>de cada rota; - confirme a imagem dentro do pacote;
- publique no Site e slug corretos;
- acompanhe o deploy até sucesso;
- abra a URL pública;
- busque as tags no HTML servido;
- abra a URL absoluta da imagem;
- use ferramentas oficiais dos canais prioritários quando disponíveis;
- 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.
