Verifique os seus cartões de partilha antes de publicar
Última atualização:
Um cartão de partilha é a pequena pré-visualização — um título, uma descrição e uma imagem — que uma rede social ou uma aplicação de chat constrói quando alguém cola uma ligação para a sua página. Para a maioria das pessoas que alguma vez encontra essa página, o cartão é a única versão dela que verão: cruzam-se com ele a meio da rolagem, julgam-no em cerca de um segundo e decidem se a página por trás dele merece um toque. A parte desconfortável é que as falhas do cartão são silenciosas. A sua página pode parecer perfeita no seu próprio navegador enquanto o cartão não mostra imagem, mostra uma manchete do mês passado ou uma descrição cortada a meio de uma palavra, porque o cartão não é construído a partir do que vê no ecrã — é construído a partir de um punhado de meta tags no head da página, obtidas uma única vez por um scraper que nunca observa. Por isso, antes de publicar qualquer coisa que pretenda partilhar, passe o URL do rascunho pelo verificador de Open Graph e olhe para a sua página como os seus leitores a verão: como quatro cartões pequenos.
A ligação é o anúncio
Quando uma ligação é colada num feed social ou numa conversa de chat, nenhum humano visita a sua página primeiro. A plataforma envia um scraper — um crawler pequeno e impaciente — que obtém a página uma vez e constrói o cartão a partir das meta tags que encontra no head. Ninguém nessa cadeia vê o seu layout, a sua tipografia, a sua cuidada secção principal ou a captura de ecrã que colocou acima da dobra. Veem exatamente três campos e uma imagem: og:title, og:description e og:image. Se esses três estiverem errados, em falta ou desatualizados, então, no que diz respeito ao seu público, a sua página está errada, em falta ou desatualizada — a bela página por trás do cartão nunca tem a oportunidade de corrigir a impressão.
O cartão também é teimoso. As plataformas guardam em cache essa recolha, normalmente associada ao URL exato, por isso a primeira versão que um scraper constrói é muitas vezes a que continua a ser partilhada durante semanas ou meses, muito depois de ter editado a página. É por isso que um cartão de partilha merece o mesmo respeito que o material publicitário: para uma publicação cujo único propósito é ser partilhada, a ligação é o anúncio, e as meta tags são o texto. Escrevê-las como um pensamento tardio — ou deixar um gerador de sites preenchê-las com o texto que por acaso estiver por perto — é lançar uma campanha cujo material ninguém reviu.
O que cada plataforma realmente lê
Comece pela base. O Facebook e o LinkedIn leem Open Graph: og:title, og:description, og:image, og:url e og:type, tal como definidos pelo protocolo Open Graph. Se esses cinco estiverem presentes e forem sensatos, as duas maiores superfícies profissionais de partilha estão cobertas. O X lê primeiro as suas próprias tags de Twitter Card — twitter:card, twitter:title, twitter:description, twitter:image — e recorre aos equivalentes Open Graph quando as tags de Twitter estão ausentes. O Slack lê primeiro Open Graph, com as tags de Twitter Card como recurso. Por outras palavras, as plataformas concordam nos ingredientes e discordam, ligeiramente, sobre a que prateleira chegam primeiro.
Em todo o lado, o último recurso é o mesmo: o vulgar elemento <title> e a meta description, chamados ao serviço quando não existe nem Open Graph nem tags de Twitter. Esse recurso importa para a forma como lê qualquer verificador, incluindo o nosso. Quando uma ferramenta lhe mostra o título de um cartão, a pergunta honesta é de onde veio o valor — de uma tag dedicada que escreveu de propósito, ou de um recurso resgatado de um elemento title escrito para uma página de resultados de pesquisa e um orçamento de caracteres que o seu cartão não partilha. Um verificador que substitui recursos em silêncio e os apresenta como tags está a mentir-lhe por omissão, e é por isso que o verificador de Open Graph rotula cada recurso como recurso em vez de fingir que a tag existe.
As falhas que fazem os cartões parecerem partidos
O clássico é o og:image relativo. A tag diz content="/images/share.png" — um caminho, não um URL — e funciona no seu navegador, porque o navegador sabe em que site está. Um scraper não o vai resolver: quer um URL completo e absoluto a começar por https://, e quando não o obtém constrói simplesmente um cartão sem imagem, pelo qual os leitores passam sem nunca saberem o que perderam. Logo atrás vem a imagem que existe mas não encaixa: muito mais pequena do que os 1200×630 píxeis que as plataformas recomendam, ou com uma proporção que o corte centrado transforma num disparate. Trate os 1200×630 como aquilo que são — uma orientação de plataforma amplamente publicada, não uma norma que alguém tenha ratificado — mas uma orientação ignorada continua a ser um cartão com a manchete cortada para fora da imagem.
O resto é mais silencioso. Uma tag twitter:card em falta significa que o X recorre a um cartão de resumo pequeno — uma miniatura ao lado do texto — mesmo quando lhe deu uma imagem grande e bonita e esperava o tratamento de largura total do summary_large_image. Valores de tag vazios são piores do que tags em falta: um og:title com content="" não aciona o recurso, substitui-o por nada. E um og:url errado — a apontar para o domínio de testes, para a página inicial ou para o artigo da semana passada, como tantas vezes fazem os modelos copiados — diz a cada plataforma que a página canónica está noutro lugar, dividindo partilhas, contadores e entradas de cache para longe da página que realmente publicou.
Porque é que o cartão antigo continua a aparecer depois de corrigir as tags
Corrigiu as tags, voltou a publicar, colou a ligação outra vez — e o título antigo continua lá, a sorrir-lhe. Nada está partido. Cada plataforma guarda em cache o cartão que construiu para o seu URL, e essa cache não vigia o seu site à procura de alterações; do ponto de vista da plataforma, ela já sabe qual é o aspeto da sua página, e voltar a obter cada URL em cada partilha seria uma quantidade enorme de rastreio para muito pouco benefício. O cartão desatualizado não é prova de que a sua correção falhou. É prova de que ainda não disseram à cache para olhar outra vez — e até que o façam, cada colega e cada leitor que partilhe a ligação volta a servir a recolha antiga.
Por isso, diga-lhe. Cada plataforma principal oferece uma forma de forçar uma nova recolha de um único URL: o Depurador de Partilhas do Facebook e o Post Inspector do LinkedIn voltam a obter a página e mostram-lhe o cartão que reconstruíram — o X oferecia historicamente um validador de cartões para o mesmo trabalho. Passe o seu URL pela ferramenta relevante depois de qualquer correção de tags e confirme o novo cartão antes de anunciar a publicação. Onde não existir ferramenta de nova recolha, mudar o URL muda a chave de cache: acrescentar uma cadeia de consulta como ?v=2 faz a plataforma tratar a ligação como uma que nunca viu, um truque perfeitamente respeitável para uma partilha pontual. E guarde um pouco de paciência — as caches podem demorar a largar mesmo depois de uma nova recolha, por isso verifique, espere e verifique mais uma vez antes de começar a editar tags que já estavam corretas.
Uma rotina de dois minutos antes de publicar
Faça disto uma rotina, não uma investigação. Um: cole o URL do rascunho no verificador de Open Graph — o URL de testes ou de pré-visualização serve, desde que seja a página que os scrapers vão obter. Dois: confirme que os quatro cartões — Facebook, X, LinkedIn e Slack — mostram o título, a descrição e a imagem que pretendia, e anote tudo o que esteja rotulado como recurso, porque um recurso escolhido é aceitável e um recurso com que tropeçou é uma tag à espera de ser escrita. Três: confirme que o URL da imagem é absoluto e que a imagem em si tem pelo menos 1200×630. Quatro: confirme que twitter:card é summary_large_image onde quer o formato grande no X, e que og:url nomeia a página canónica que está prestes a publicar.
Cinco: publique — e depois cole você mesmo a ligação em algum lugar uma vez, para forçar a primeira recolha enquanto ainda está a observar, e veja o cartão que volta. Se estiver desatualizado ou errado, volte a recolhê-lo com a ferramenta da própria plataforma em vez de editar em pânico. Dois minutos, cinco passos, e a versão da sua página que a maioria das pessoas alguma vez verá é uma versão que realmente aprovou. Para a varredura mais ampla antes de publicar — TLS, cabeçalhos de segurança, redirecionamentos, o resto das verificações de rotina que uma página merece antes de sair — execute ao lado a verificação de saúde do site; os cartões são a porta da frente, mas não são a casa inteira.