Meta tags que o Google e as redes sociais entendem

O lado do buscador: título, description e o que ele ignora

Comece pelo par mais visível na busca: o title e a meta name="description". O título vira o link azul do resultado e o texto da aba do navegador; a description é a sugestão de resumo que aparece embaixo. A palavra "sugestão" carrega toda a nuance. O Google descreve o próprio comportamento sem rodeios: os snippets são criados principalmente a partir do conteúdo da página, e a description só é usada quando ela pode dar ao usuário uma descrição mais exata do que o texto da própria página. Ou seja, o padrão é o Google gerar o snippet sozinho; a sua description entra como candidata, não como texto garantido. Por isso ele reescreve o snippet com frequência, sobretudo quando a description está vazia, duplicada, genérica ou desalinhada da busca digitada.

Aqui mora o mal-entendido nº 1: a description não é fator de ranqueamento. Ela não empurra a página para cima; ela influencia a taxa de clique quando o Google decide usá-la. Escrever uma boa description ainda vale a pena, é a chance de vender o clique com as suas palavras,, mas trate-a como copy de anúncio, não como alavanca de posição. E não perca tempo com a meta name="keywords": o Google anunciou publicamente em 2009 que a ignora no ranqueamento de busca, porque a tag virou terreno de spam. Preenchê-la hoje só entrega a sua lista de palavras-chave para concorrentes lerem no código-fonte.

Um exemplo numérico deixa o truncamento concreto. Suponha uma description de 240 caracteres. Numa SERP de desktop, o Google costuma exibir por volta de 155 a 160 caracteres antes das reticências; os 80 e poucos caracteres finais simplesmente não aparecem. Se a sua chamada de ação estava no fim ("...peça um orçamento grátis hoje"), ela some. Agora inverta: coloque o gancho nos primeiros 120 caracteres e o corte deixa de doer. A conta não muda a description, muda onde você põe o que importa.

1. 2009O Google abandona meta keywords

   Em 21 de setembro de 2009, o blog oficial do Google confirma que não usa a tag keywords no ranqueamento de busca, por causa do abuso.

2. 2010Facebook lança o Open Graph

   Na conferência f8, em abril de 2010, o Facebook publica o protocolo Open Graph, criando as tags og: que hoje viram cartão em quase toda rede.

3. 2011Google introduz o hreflang

   Em dezembro de 2011, o Google adota rel="alternate" hreflang para relacionar versões de uma página em idiomas e regiões diferentes.

4. 2012Twitter lança os Cards

   Em junho de 2012, o Twitter (hoje X) apresenta as tags twitter:, com fallback para o Open Graph quando elas faltam.

5. anos 2010JSON-LD vira o preferido

   Ao longo da década, o Google passa a recomendar JSON-LD como formato de dados estruturados, por ser o mais fácil de manter em escala.

O lado social: Open Graph e o cache do scraper

Agora troque de pipeline. Quando você cola um link no WhatsApp, no LinkedIn, no Slack ou no Discord, nenhum deles consulta o ranqueamento do Google nem lê a sua description. Um scraper visita a página e procura as propriedades Open Graph, o protocolo que o Facebook criou em 2010 e que virou padrão de fato. A especificação (ogp.me) define quatro propriedades obrigatórias, e o resto é reforço. Se essas quatro estiverem certas, você já tem um cartão decente em quase todo lugar.

A imagem é onde mais gente tropeça. A spec do Open Graph não fixa dimensões, mas as próprias plataformas recomendam uma prévia grande em torno de 1200×630 px (proporção ~1,91:1), que preenche o cartão sem cortes no Facebook e no LinkedIn. Duas regras práticas evitam a maioria dos cartões quebrados: sirva a imagem por uma URL absoluta em HTTPS (muitos scrapers ignoram og:image relativa ou insegura) e acrescente og:image:alt para acessibilidade. Se você está escolhendo o formato do arquivo, o guia de formatos de imagem para a web ajuda a decidir entre JPEG, PNG, WebP e AVIF, para cartão social, JPEG ou PNG bem comprimidos são a aposta mais compatível.

Twitter/X cards: o mínimo viável e o fallback

O X (ex-Twitter) tem o seu próprio conjunto, prefixado por twitter:. A tag central é a twitter:card, que escolhe o formato do cartão e é a única realmente obrigatória. O truque que economiza trabalho: quando faltam as tags twitter:title, twitter:description e twitter:image, o X recorre às equivalentes de Open Graph. Então o mínimo viável é ter um Open Graph completo e declarar apenas o twitter:card. Você não precisa duplicar tudo, precisa apenas dizer ao X qual formato usar.

As tags twitter:site e twitter:creator recebem @perfis, o do site e o do autor. Um erro silencioso comum é esquecer o "@"; o gerador de meta tags avisa quando o handle está sem ele. Sobre imagem: o summary_large_image pede proporção 2:1, enquanto o og:image "seguro" de 1200×630 é ~1,91:1. Na prática, uma boa imagem 1200×630 serve os dois, o X recorta um fio nas laterais, sem drama. Como o cartão do X reaproveita a og:image quando você não define twitter:image, você raramente precisa de uma segunda imagem só para ele.

Indexação: canonical, robots e a armadilha do robots.txt

De volta ao buscador, três controles decidem se, e como, a página entra no índice. Eles são invisíveis ao usuário e decisivos para o SEO, e cada um esconde uma sutileza que derruba sites inteiros quando mal compreendida.

link rel="canonical"

Aponta a versão preferida de uma página que existe em várias URLs. É um sinal forte, não uma diretiva: o Google costuma respeitá-lo, mas pode escolher outra URL como canônica se os sinais discordarem.

meta name="robots"

No HTML da página: index/noindex decide se ela pode aparecer na busca; follow/nofollow decide se os links passam sinal. Só vale se o crawler conseguir ler a página.

X-Robots-Tag

O mesmo controle, mas entregue no cabeçalho HTTP da resposta. Serve para arquivos sem HTML (PDF, imagem) e para aplicar noindex no servidor sem tocar no corpo da página.

robots.txt (Disallow)

Um arquivo na raiz que pede ao crawler para NÃO rastrear certos caminhos. Controla rastreio, não indexação, e essa diferença é a armadilha abaixo.

O canonical guarda a sua própria pegadinha, o mal-entendido nº 3. Ele é uma dica, não um comando. O Google o trata como um sinal forte de qual versão você prefere, mas reserva a palavra final: se a sua página aponta um canonical para outra URL que, por sua vez, aponta de volta a lugar nenhum, se o conteúdo das duas difere muito, se há redirects ou hreflang conflitantes, o Google pode ignorar a sua escolha e canonizar a URL que ele julga melhor. Um canonical apontando para a home por engano, clássico em templates mal configurados, pode desindexar páginas boas. Antes de suspeitar do canonical, confirme que o servidor responde 200 na URL certa: uma página que devolve 404 ou entra num 301 não será indexada como você espera. Cheque o status no http status checker; o guia de códigos de status HTTP essenciais detalha as nuances de 301, 302 e 404.

Idiomas e dados estruturados: hreflang e JSON-LD

Se o seu site existe em mais de um idioma, como este, em pt-BR e en-US,, o hreflang diz ao Google qual versão mostrar para cada usuário. A regra que mais gera erro é a reciprocidade: as anotações precisam ser bidirecionais. O Google é direto: se duas páginas não apontam uma para a outra, as tags são ignoradas. Isso existe para impedir que um site alheio se declare "versão alternativa" da sua página. Então a página pt-BR precisa listar a en-US como alternativa, e a en-US precisa listar a pt-BR de volta, cada uma listando também a si mesma.

Duas exigências fecham a configuração. Primeiro, use o valor reservado x-default para a página de fallback, a que atende quem não casa com nenhum dos seus idiomas. Segundo, as URLs do hreflang têm de ser absolutas, com protocolo: https://exemplo.com/foo, nunca //exemplo.com/foo nem /foo. Você pode entregar o hreflang de três formas equivalentes: tags link no head, cabeçalhos HTTP (para PDFs e afins) ou anotações no sitemap XML. Escolha uma e seja consistente, misturar sinais contraditórios é receita para o Google descartar tudo.

Fecha o head técnico a camada de dados estruturados, que descreve o conteúdo em linguagem de máquina (schema.org) e habilita resultados enriquecidos. Existem três sintaxes, JSON-LD, microdados e RDFa, e para o Google as três valem, desde que corretas. Mas há uma preferência declarada: o Google recomenda usar JSON-LD, por ser o mais fácil de implementar e manter em escala e o menos sujeito a erro. A vantagem prática é que o JSON-LD vive num único bloco script no head, separado do HTML visível, em vez de entrelaçar atributos nos elementos como fazem os microdados. Se você vai investir em dados estruturados, comece por JSON-LD.

De modo geral, o Google recomenda usar JSON-LD para dados estruturados, se a configuração do seu site permitir, por ser a solução mais fácil de implementar e manter em escala.

Google Search Central, Introdução aos dados estruturados

Quem lê o quê, montando e auditando o head

Junte as duas pipelines numa tabela só e a confusão evapora. Repare como quase nenhuma tag é lida pelos dois lados: Open Graph não move o ranqueamento, e title/description não montam o cartão social.

Agora o exemplo trabalhado nº 1: um head real, cheio de erros comuns. Cada linha problemática está comentada.

<!-- HEAD COM PROBLEMAS / PROBLEM HEAD -->
<title>Home</title>                                  <!-- generico: sem palavra-chave, o Google reescreve -->
<meta name="description" content="" />               <!-- vazia: o Google gera o snippet do conteudo -->
<meta name="keywords" content="tenis, comprar, barato, promocao" /> <!-- ignorada desde 2009 -->
<meta name="robots" content="noindex" />             <!-- e a pagina esta com Disallow no robots.txt (!) -->
<link rel="canonical" href="/produtos/123" />        <!-- URL relativa: fragil -->
<meta property="og:image" content="/img/capa.jpg" /> <!-- relativa, sem og:title/og:type/og:url -->

O que cada erro causa: o title "Home" não diz nada, então o Google monta o próprio; a description vazia joga o snippet nas mãos do algoritmo; a meta keywords é peso morto; o par noindex + Disallow no robots.txt é o pior de todos, como o crawler não pode rastrear, ele nunca lê o noindex, e a página fica indexada só pela URL, sem descrição; o canonical relativo é frágil e pode ser mal interpretado; e a og:image relativa, sem og:title, og:type nem og:url, produz um cartão social sem imagem e sem título. Agora o exemplo trabalhado nº 2: o mesmo head, corrigido e comentado, cobrindo SEO, Open Graph, X, canonical e hreflang.

<!-- ===== Documento (navegador, nao o Google) ===== -->
<meta charset="utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1" />

<!-- ===== Busca: o buscador le isto ===== -->
<title>Contraste de cor na WCAG 2.2: como medir AA e AAA</title>
<meta name="description" content="Como calcular a razao de contraste e passar nos limiares AA e AAA da WCAG 2.2, com exemplos e formula." />
<link rel="canonical" href="https://exemplo.com/guias/contraste" />
<meta name="robots" content="index, follow, max-image-preview:large" />

<!-- ===== Versoes por idioma: reciprocas, absolutas, com x-default ===== -->
<link rel="alternate" hreflang="pt-BR" href="https://exemplo.com/pt/guias/contraste" />
<link rel="alternate" hreflang="en-US" href="https://exemplo.com/en/guides/contrast" />
<link rel="alternate" hreflang="x-default" href="https://exemplo.com/en/guides/contrast" />

<!-- ===== Open Graph: WhatsApp, Facebook, LinkedIn, Slack, Discord ===== -->
<meta property="og:title" content="Contraste de cor na WCAG 2.2" />
<meta property="og:description" content="Limiares AA/AAA e como medir a razao de contraste." />
<meta property="og:type" content="article" />
<meta property="og:url" content="https://exemplo.com/guias/contraste" />
<meta property="og:image" content="https://exemplo.com/og/contraste.png" /> <!-- absoluta, HTTPS, ~1200x630 -->
<meta property="og:image:alt" content="Texto sobre fundo com a razao de contraste destacada" />
<meta property="og:site_name" content="Exemplo" />
<meta property="og:locale" content="pt_BR" />

<!-- ===== X (Twitter) Card: so o card e os handles; o resto cai no og: ===== -->
<meta name="twitter:card" content="summary_large_image" />
<meta name="twitter:site" content="@exemplo" />
<meta name="twitter:creator" content="@autora" />

<!-- ===== Dados estruturados: JSON-LD, o formato que o Google recomenda ===== -->
<script type="application/ld+json">
{ "@context": "https://schema.org", "@type": "Article",
  "headline": "Contraste de cor na WCAG 2.2",
  "inLanguage": "pt-BR" }
</script>

Uma ressalva honesta: o gerador de meta tags produz o bloco de busca (title, description, canonical, robots), o Open Graph e o X, o miolo que muda a cada página. O charset, o viewport, o hreflang e o JSON-LD do exemplo acima você acrescenta à mão (ou o seu framework injeta), porque dependem da estrutura do site inteiro, não de uma página só. Gere o núcleo aqui e cole no seu head:

• title único e descritivo, com o essencial nos primeiros ~60 caracteres.
• description honesta com o gancho no começo, sabendo que o Google pode reescrevê-la.
• canonical absoluto apontando para a URL que responde 200.
• Para remover da busca: liberar o rastreio e servir noindex (nunca só Disallow no robots.txt).
• Open Graph com as quatro obrigatórias (og:title, og:type, og:image, og:url) e og:image absoluta em HTTPS.
• twitter:card declarado; handles com "@".
• hreflang recíproco, absoluto e com x-default, se o site é multilíngue.
• Depois de publicar: re-scrapear a URL no depurador da rede para limpar o cache do cartão.