Redes Sociais: Otimizar a Publicação e Visibilidade de um Site

Um link partilhado no LinkedIn, no Facebook, no X ou no WhatsApp não mostra a página — mostra uma carta construída a partir das meta tags que o crawler da plataforma leu no <head> do site. Quando essa carta sai vazia, com o título errado ou com uma imagem esticada, o custo é imediato: menos cliques, menos tráfego de referência e uma imagem de marca descuidada no canal onde o público da empresa mais partilha.

A mecânica é estável e pequena: o protocolo Open Graph define um punhado de tags, todas as grandes plataformas as leem, e existem ferramentas gratuitas — o Sharing Debugger do Facebook e o Post Inspector do LinkedIn — que mostram exactamente o que o crawler vê e limpam a cache quando as tags mudam. O guia percorre o ciclo completo no site WordPress de uma PME: inspecionar as metas com curl, corrigi-las no Yoast, gerar a imagem certa, testar em cada plataforma e automatizar a verificação.

Neste artigo

  1. Como os Crawlers das Redes Sociais Lêem uma Página
  2. As Metas Open Graph que Têm de Existir
  3. Passo 1 — Verificar as Metas Existentes no Site
  4. Passo 2 — Corrigir as Metas no WordPress com Yoast SEO
  5. Passo 3 — Gerar e Otimizar a Imagem 1200×630
  6. Passo 4 — Testar no Facebook com o Sharing Debugger
  7. Passo 5 — Testar no LinkedIn com o Post Inspector
  8. Passo 6 — Testar no X e no WhatsApp
  9. Passo 7 — Automatizar a Verificação em Vários URLs
  10. Schema.org JSON-LD como Camada Extra
  11. Erros Comuns
  12. Checklist

1. Como os Crawlers das Redes Sociais Lêem uma Página

Cada plataforma tem um crawler próprio — o facebookexternalhit no Facebook, o WhatsApp/2.x.x.x no WhatsApp (uma partilha pode também disparar o facebookexternalhit e o Facebot, mas são crawlers distintos), o bot do LinkedIn, o Twitterbot no X. O funcionamento é igual em todos: quando alguém cola um URL, o crawler pede o HTML da página e procura as tags Open Graph no <head>. Não corre JavaScript pesado e não consulta o sitemap.xml — a prévia nasce só das meta tags presentes nesse HTML.

Duas consequências: um site que construa as metas via JavaScript corre o risco de aparecer sem imagem e sem descrição, porque nem todos os crawlers executam esse código. E o robots.txt e o sitemap.xml ficam fora da carta social — afectam a descoberta nos motores de busca, não a prévia. Excepção: se o robots.txt bloquear o user-agent do crawler social, a prévia fica vazia.

Para ver o HTML que o crawler vê, pedir a página com o user-agent do crawler — um curl simples apresenta-se como curl/x.y e pode receber um HTML diferente:

curl -sL -A "facebookexternalhit/1.1" https://www.dominio.pt/instalar-wordpress-plesk/ | head -30
<!DOCTYPE html>
<html lang="pt-PT">
<head>
  <meta charset="UTF-8">
  <title>Instalar o WordPress Manualmente no Plesk – Dominio.pt</title>
  <meta property="og:title" content="Instalar o WordPress Manualmente no Plesk">
  <meta property="og:image" content="https://www.dominio.pt/wp-content/uploads/2026/09/capa.png">
  …
</head>

2. As Metas Open Graph que Têm de Existir

O protocolo Open Graph, publicado em ogp.me, define as tags base. Uma página preparada para partilha tem este bloco no <head>:

<meta property="og:title" content="Instalar o WordPress Manualmente no Plesk" />
<meta property="og:description" content="Guia passo a passo: criar a base de dados, fazer upload dos ficheiros e concluir a instalação no Plesk." />
<meta property="og:image" content="https://www.dominio.pt/wp-content/uploads/2026/09/capa-instalar-wordpress.png" />
<meta property="og:image:width" content="1200" />
<meta property="og:image:height" content="630" />
<meta property="og:url" content="https://www.dominio.pt/instalar-wordpress-plesk/" />
<meta property="og:type" content="article" />
<meta property="og:site_name" content="Dominio.pt" />
<meta name="twitter:card" content="summary_large_image" />
Tag O que faz Limite prático
og:title Título da carta ~60 caracteres
og:description Descrição sob o título 110-160 caracteres
og:image Imagem da prévia 1200×630, PNG ou JPEG, URL absoluto em HTTPS
og:image:width / og:image:height Dimensões declaradas Permitem renderizar a prévia sem esperar pelo download da imagem
og:url URL canónico da página O endereço que deve aparecer na barra do browser
og:type Tipo de conteúdo article em posts, website na homepage
og:site_name Nome do site Aparece em algumas prévias
twitter:card Tipo de card no X summary_large_image para a carta grande

Sobre a imagem: exige URL absoluto (caminhos relativos não são resolvidos pelo crawler), o Facebook ignora ficheiros abaixo de 200×200 px e mostra-os como miniatura abaixo de 600×315 px, e os limites diferem por plataforma — até 8 MB no Facebook e nos uploads de imagem do LinkedIn, até 5 MB nos cards do X. O WhatsApp é o mais exigente: a Meta indica imagem com menos de 600 KB, pelo menos 300 px de largura e rácio até 4:1 — por isso, comprimir o ficheiro (JPEG ou PNG optimizado) em vez de confiar num único teto.

3. Passo 1 — Verificar as Metas Existentes no Site

Antes de corrigir, confirmar o estado actual. Um grep sobre o HTML devolve as tags sociais da página:

curl -sL https://www.dominio.pt/instalar-wordpress-plesk/ \
  | grep -ioE '<meta [^>]*(og:|twitter:)[^>]*>'
<meta property="og:title" content="Instalar o WordPress Manualmente no Plesk">
<meta property="og:description" content="Guia passo a passo: criar a base de dados, …">
<meta property="og:image" content="https://www.dominio.pt/wp-content/uploads/2026/09/capa.png">
<meta name="twitter:card" content="summary_large_image">

Três cenários. Nenhuma linha com og: — o tema não emite as tags, típico de um WordPress sem plugin de SEO, e o sinal para instalar o Yoast ou o Rank Math (Passo 2). Og:title com o nome do site em vez do título do artigo — as tags existem mas usam valores por omissão. Og:image a apontar para um ficheiro pequeno ou inexistente — a correcção passa pela imagem do Passo 3.

Repetir na homepage e num artigo recente completa a radiografia — as metas de entrada e as de conteúdo são geradas por caminhos diferentes.

4. Passo 2 — Corrigir as Metas no WordPress com Yoast SEO

O Yoast SEO emite og:title, og:description, og:url, og:site_name e twitter:card sem configuração extra — o título vem do campo SEO do post e a descrição da meta description. A imagem é o ponto delicado: com o post editado no wp-admin, o og:image sai da featured image. No fluxo REST, o Yoast pode não a emitir — depende da versão e da configuração do plugin, e a meta com prefixo _ só é gravável via REST se estiver registada com show_in_rest; sem isso, o pedido devolve 200 e ignora a meta em silêncio. O workaround passa por gravar a meta directamente e confirmar o og:image no HTML da página depois da chamada — se não aparecer, editar o post no wp-admin e definir a imagem destacada:

curl -s -X POST -u "$WP_USER:$WP_PASS" \
  -H 'Content-Type: application/json' \
  --data-binary '{"meta":{"_yoast_wpseo_opengraph-image":"https://www.dominio.pt/wp-content/uploads/2026/09/capa-19527.png"}}' \
  "https://www.dominio.pt/wp-json/wp/v2/posts/19527"
{"id":19527,"date":"2026-09-19T10:14:00","link":"https://www.dominio.pt/instalar-wordpress-plesk/",…}

O HTTP 200 grava a meta mesmo que a resposta não a mostre de volta — o endpoint de meta do REST não a devolve na leitura. A confirmação fiável faz-se no HTML da página (Passo 1) ou nas ferramentas dos Passos 4 e 5. No Rank Math, o equivalente é a meta rank_math_facebook_image (guarda o URL da imagem, como no Yoast). Sem plugin de SEO nenhum, instalar um dos dois resolve título, descrição e card — resta a imagem, no passo seguinte.

5. Passo 3 — Gerar e Otimizar a Imagem 1200×630

A dimensão base é 1200×630 px (rácio 1.91:1). O LinkedIn recorta para 1200×627 — três píxeis sem efeito prático. O X prefere 2:1 (1200×600) mas escala a 1200×630 sem cortes visíveis com summary_large_image. Uma única capa cobre as quatro plataformas.

Para gerar capas consistentes com Python e PIL:

from PIL import Image, ImageDraw, ImageFont

img = Image.new("RGB", (1200, 630), "#0F172A")
d = ImageDraw.Draw(img)
d.rectangle([0, 0, 1200, 8], fill="#3182CE")

font = ImageFont.truetype(
    "/usr/share/fonts/truetype/dejavu/DejaVuSans-Bold.ttf", 48)
d.text((80, 250), "Instalar o WordPress Manualmente no Plesk",
       font=font, fill="#FFFFFF")
d.text((80, 560), "dominio.pt · Tutoriais de Tecnologia",
       font=font, fill="#63B3ED")

img.save("capa-19527.png", optimize=True)

Depois de gerar, confirmar dimensões e peso:

python3 gerar_capa.py && identify -format "%wx%h\n" capa-19527.png && ls -lh capa-19527.png
1200x630
-rw-r--r-- 1 duarte duarte 84K Sep 19 10:20 capa-19527.png

Compressão: texto e áreas flat em PNG, fotografias em JPEG com quality=85 — o ficheiro encolhe para dezenas de KB, muito abaixo dos 5 MB. No desenho, texto longe das margens (o recorte do WhatsApp é quadrado e come as pontas) e contraste alto — a capa é lida em ecrãs de telemóvel a um terço do tamanho.

6. Passo 4 — Testar no Facebook com o Sharing Debugger

O Facebook faz scrape da página na primeira partilha e guarda o resultado em cache. Daí duas situações frequentes: quem partilhar primeiro pode ver a carta sem imagem, e as correcções às tags não aparecem enquanto a cache não for limpa.

A ferramenta é o Sharing Debugger, em developers.facebook.com/tools/debug. Colar o URL e clicar em Debug devolve a prévia como o Facebook a renderiza, as tags que o facebookexternalhit leu e os avisos — imagem pequena, og:image em falta, descrição longa. O botão Scrape Again força um scrape novo e limpa a cache: é o botão de cada correcção. E as tags og:image:width e og:image:height permitem renderizar a carta sem descarregar a imagem — a diferença entre a primeira partilha sair completa ou com o espaço vazio.

7. Passo 5 — Testar no LinkedIn com o Post Inspector

O LinkedIn lê as mesmas tags og: e acrescenta uma cache de prévias de cerca de 7 dias, pelo que corrigir as tags e voltar a partilhar mostra frequentemente a versão antiga. O Post Inspector, em linkedin.com/post-inspector, resolve: colar o URL e clicar em Inspect devolve a prévia final e, mais abaixo, a lista exacta das metas que o crawler leu. Cada Inspect força um re-scrape, por isso a sequência corrigir → Inspect → confirmar fecha o ciclo em minutos. Dimensões: og:image a 1200×627 px (630 também serve), PNG ou JPEG, URL absoluto em HTTPS e abaixo de 5 MB — o limite que os cards do X e as imagens do LinkedIn partilham.

8. Passo 6 — Testar no X e no WhatsApp

No X, a tag que manda é twitter:card. Com summary_large_image, o card ocupa toda a largura do post com a imagem em rácio 2:1 — mínimos 300×157 px, máximos 4096×4096 px, até 5 MB. Sem essa tag, o X cai no card pequeno mesmo com uma boa og:image presente — o og: serve só de fallback. Não há validador público estável do lado do X: a confirmação prática é colar o URL numa nova publicação e observar a prévia antes de publicar.

O WhatsApp herda o og: e mostra a imagem como thumbnail no cartão da mensagem, com limites próprios: a Meta indica imagem com menos de 600 KB, pelo menos 300 px de largura e rácio até 4:1 — ficheiros muito acima disso podem nem gerar thumbnail. O recorte é quadrado — o texto da capa deve ficar centrado — e a cache é agressiva, podendo manter a prévia antiga durante dias. Para forçar um scrape novo durante os testes, partilhar o URL com um parâmetro de descarte:

https://www.dominio.pt/instalar-wordpress-plesk/?v=2

O site ignora o parâmetro, mas o WhatsApp trata o endereço como um URL novo e refresca a prévia.

9. Passo 7 — Automatizar a Verificação em Vários URLs

Para quem mantém dezenas de artigos, a verificação manual não escala. Um script simples conta as tags de qualquer conjunto de URLs:

#!/bin/bash
# verificar-og.sh — conta as tags Open Graph em vários URLs
for url in "$@"; do
  echo "== $url"
  curl -sL "$url" | grep -ioE 'property="og:(title|description|image)"' \
    | sort | uniq -c
done
chmod +x verificar-og.sh && ./verificar-og.sh https://www.dominio.pt/ https://www.dominio.pt/instalar-wordpress-plesk/
== https://www.dominio.pt/
   1 property="og:description"
   1 property="og:image"
   1 property="og:title"
== https://www.dominio.pt/instalar-wordpress-plesk/
   1 property="og:description"
   1 property="og:image"
   1 property="og:title"

A leitura é por contagem: cada tag uma vez por página — linha ausente é meta em falta. Para cobrir o site inteiro, o sitemap serve de inventário:

curl -s https://www.dominio.pt/sitemap.xml \
  | grep -oE 'https://[^<]+' \
  | xargs -n 1 ./verificar-og.sh

Correr o script sobre o sitemap antes de uma campanha apanha os artigos que ficaram para trás — mais barato do que descobrir a prévia vazia depois de o link sair.

10. Schema.org JSON-LD como Camada Extra

As tags og: resolvem a carta social. A camada seguinte — que não as substitui — é o Schema.org em JSON-LD, o formato que os motores de busca leem para rich results e que o Yoast emite automaticamente a partir da featured image:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Instalar o WordPress Manualmente no Plesk",
  "image": "https://www.dominio.pt/wp-content/uploads/2026/09/capa-19527.png",
  "datePublished": "2026-09-19"
}
</script>

Manter a imagem do JSON-LD igual à do og:image evita divergências entre o que o Google mostra e o que as redes sociais mostram. A ferramenta de teste é o Rich Results Test.

Erros Comuns

Problema Causa Solução
A prévia sai sem imagem na primeira partilha O crawler ainda não processou o og:image — o Facebook só a renderiza depois de a ter visto uma vez Passar o URL no Sharing Debugger e clicar em Scrape Again antes de partilhar
As correcções às tags não aparecem na prévia Cache de prévias por plataforma — cerca de 7 dias no LinkedIn, dias no WhatsApp Scrape Again no Facebook, Inspect no Post Inspector, parâmetro ?v= no WhatsApp
og:image não sai num post criado via REST API com Yoast O Yoast não emite og:image só a partir do featured_media no fluxo REST Gravar a meta _yoast_wpseo_opengraph-image com o URL absoluto da capa
A imagem aparece como miniatura pequena no feed Ficheiro abaixo de 600×315 px no Facebook ou abaixo de 1200 px de largura no LinkedIn Regenerar a capa a 1200×630 e actualizar o og:image
O X mostra o card pequeno sem imagem grande twitter:card ausente — o fallback é o card summary Adicionar a meta twitter:card com summary_large_image
A descrição aparece cortada com reticências og:description acima de ~160 caracteres Encurtar para 110-160 caracteres e re-testar nas ferramentas oficiais

Checklist

  • [ ] og:title presente, único e dentro de ~60 caracteres
  • [ ] og:description presente com 110-160 caracteres
  • [ ] og:image com URL absoluto em HTTPS, 1200×630, PNG ou JPEG, abaixo de 5 MB
  • [ ] og:image:width e og:image:height declarados no <head>
  • [ ] og:url canónico e og:type correcto (article nos posts)
  • [ ] twitter:card com summary_large_image no <head>
  • [ ] URL passado no Sharing Debugger com Scrape Again depois das correcções
  • [ ] Prévia confirmada no Post Inspector do LinkedIn
  • [ ] Partilha de teste no WhatsApp com thumbnail legível
  • [ ] verificar-og.sh corrido sobre os URLs principais do site

Artigos Relacionados

Fontes Oficiais