Atualização instantânea da imagem do WhatsApp para WooCommerce

Uma atualização instantânea da imagem do WhatsApp para WooCommerce significa que o cartão correto está pronto no momento em que você guarda um produto — não que o WhatsApp volte a ler a ligação por comando. Ninguém consegue obrigar o WhatsApp a reler uma ligação: ele coloca as pré-visualizações em cache na aplicação do destinatário e não expõe nenhuma API de atualização. O que você controla é tudo do lado da loja, e isso é suficiente para que a próxima pessoa que partilhar a ligação veja o produto, o preço e a fotografia atuais.

A resposta curta

Há dois relógios numa pré-visualização do WhatsApp, e apenas um deles é seu.

Relógio Quem o controla Pode ser instantâneo?
O og:image que a sua página serve Você (a loja) Sim — é esta a parte a corrigir
O WhatsApp a ler a página e a colocar em cache o que leu O WhatsApp, por destinatário Não — sem API, sem debugger, sem contorno

Toda a alegação de "atualização instantânea" que ignora a segunda linha é mentira, e todo o produto que só corrige a primeira linha continua a mostrar a imagem certa assim que o WhatsApp volta a olhar. É esse o jogo todo: garantir que o lado da loja está comprovadamente correto e depois deixar de esperar que o WhatsApp colabore.

Porque a sua atualização não aparece

Existem quatro caches separadas entre "alterei o preço" e "a pré-visualização mudou". Os comerciantes quase sempre culpam a errada.

# Cache Indexada por O que realmente a limpa
1 A cache de página / CDN da sua loja o URL da página limpar a cache de página
2 A cache de pré-visualização de links do WhatsApp o link que as pessoas partilharam nada — expira segundo o calendário do WhatsApp
3 A cópia dos bytes da imagem do WhatsApp o URL da imagem um novo URL de imagem
4 A sua CDN de imagens / cache de renderização o URL da imagem um novo URL de imagem, ou limpá-la

A linha 1 é a que as pessoas esquecem. Uma página HTML em cache ainda contém o URL og:image antigo, por isso mesmo um cartão perfeitamente reconstruído nunca chega a ser descoberto. Limpe primeiro a cache de página e só depois olhe para o resto.

As linhas 3 e 4 são a razão pela qual acrescentar uma versão ao URL da imagem é o único cache-buster fiável — um novo URL de imagem é uma falha de cache em todo o lado ao mesmo tempo.

A parte do WooCommerce: a sua tag nunca deve estar desatualizada

No WooCommerce, o problema da tag costuma ser uma de duas coisas, e nenhuma delas é culpa do WhatsApp:

  • Não existe nenhuma og:image de todo. O WordPress e o WooCommerce não emitem nenhuma para product, product_cat ou para a página da loja. O seu plugin de SEO fornece uma — e, para um produto, recorre à imagem destacada estática.
  • A tag existe mas aponta para um ficheiro fixo. Um URL de imagem estática não pode mudar quando o preço muda. Cada partilha após a edição volta a colocar em cache a mesma imagem desatualizada.

O FastOG segue o outro caminho. A capa é um URL assinado cuja query contém os valores que a produziram, lidos do catálogo em tempo real em cada pedido: o nome do produto, o preço atual (get_price() — o preço promocional num produto com desconto), o preço "antes" de comparação, o selo de promoção, a avaliação, o stock e a fotografia do produto.

Isso tem uma consequência que vale a pena afirmar claramente: uma alteração de preço é uma alteração de URL. O URL antigo já não descreve o produto, por isso o CDN não tem nada desatualizado para servir, e o pedido seguinte volta a renderizar. Sem truques de cache-busting, sem lista de verificação de "será que já limpei a cache".

O que acontece quando você clica em Guardar num produto

Para o Facebook — a única plataforma que permite a qualquer pessoa pedir — a FastOG faz o pedido por você:

  1. O WooCommerce dispara o seu webhook nativo product.updated / product.created (o permalink está no payload).
  2. A FastOG atualiza o registo do catálogo da loja, para que a próxima capa seja desenhada a partir dos dados atuais.
  3. É enfileirado um job RefreshMetaPreview para o URL da página desse produto. É enfileirado em vez de executado inline — uma sincronização de catálogo completo não pode acrescentar uma chamada bloqueante à Meta por item — e é desduplicado, para que guardar repetidamente o mesmo produto não gaste o rate limit da Meta.
  4. O job chama o endpoint de scrape da Meta com um app access token, e a Meta substitui a sua cópia em cache da pré-visualização dessa página.

Isto é best-effort por design. Se a Meta estiver lenta, recusar ou limitar o rate, a sincronização continua a ter sucesso: a tag na sua página já está correta, e o único custo é que a Meta atualiza segundo o seu próprio calendário em vez de imediatamente.

Não atualiza o WhatsApp, o LinkedIn nem o X, porque nenhum deles oferece uma API para atualizar o que quer que seja. Isso não é uma limitação da FastOG — é a ausência de um endpoint do outro lado.

Verifique pela ordem correta

Quando uma pré-visualização não atualiza, percorra esta lista em vez de adivinhar:

bash
# 1. Does the page still serve the OLD tag? (page cache — cache row 1)
curl -s https://your-store.com/product/example | grep -i 'og:image'

# 2. Is that image URL reachable without credentials? (cache row 3)
curl -I "https://...the-og-image-url-from-step-1..."

# 3. Did the image URL change after the edit? Compare with the URL from before.

Se o passo 1 ainda mostrar o URL anterior à edição, nada a jusante pode ajudar — limpe a cache da página. Se o passo 1 mostrar um novo URL e o passo 2 devolver 200 OK com um image/png, o lado da loja está correto e você está a olhar para a linha 2 da cache, que é o relógio do WhatsApp.

Quer ver as quatro linhas a partir do exterior? Cole o URL do produto em See Your Links The Way Buyers Do — ele obtém a página como um crawler faz, lê as tags em tempo real e apresenta o resultado tal como o WhatsApp, o X e o Messenger o mostram, ao lado de uma capa FastOG criada a partir dos mesmos dados do produto. Sem registo.

Um plugin de cache-busting ou ?v=2 ajudam?

Ajudam de uma forma limitada, e o compromisso é real.

Uma pré-visualização é colocada em cache em função do link que as pessoas partilharam. Um URL que ninguém partilhou nunca tem pré-visualização em cache — é por isso que acrescentar uma query string que muda (?v=2) é um truque tão comum. Funciona, mas tem custos: o link partilhado deixa de ser o URL canónico do seu produto, os motores de busca veem um segundo endereço e as ferramentas de analytics dividem o tráfego.

O FastOG aplica o mesmo mecanismo um nível abaixo, onde não tem custos. O URL da página mantém-se canónico; apenas o URL da imagem muda com o conteúdo. Assim, a capa antiga não pode voltar a ser servida, e o link que partilha continua a ser a página de produto que quer indexada.

O que ninguém consegue corrigir, e porque o dizemos

  • O WhatsApp guarda a pré-visualização em cache na aplicação do destinatário. Não existe API, depurador nem ferramenta — incluindo a nossa — que consiga chegar lá.
  • O LinkedIn e o X também não expõem nenhuma API documentada de invalidação programática. Os seus crawlers voltam a ler segundo os seus próprios calendários; não trate uma estimativa de tempo de terceiros como uma garantia da plataforma.
  • O Facebook é a exceção, e a única plataforma que a FastOG contacta por você. Consulte Force a Facebook Open Graph Cache Refresh para os detalhes.

Um fornecedor que lhe diz que atualiza o WhatsApp está a descrever o comportamento do Facebook e a esperar que você não verifique. Preferimos dar-lhe o mapa exato.

FAQ

Não. O WhatsApp não expõe nenhum endpoint de atualização nem debugger, e a pré-visualização em cache reside na aplicação do destinatário. Só podes garantir que a imagem correta está à espera da próxima leitura.

Não existe um valor publicado nem forma de o consultar — é por destinatário, por dispositivo. Trata-o como "até o WhatsApp decidir o contrário" e otimiza antes o lado da loja.

Porque é que atualizou para mim mas não para o meu cliente?

Porque testaste ao partilhar um link que nunca tinha sido partilhado a partir do teu dispositivo, ou enviaste-o para uma conversa nova. O teu cliente está a ver uma pré-visualização em cache. A pré-visualização dele e a tua são independentes.

Alterar o URL do produto força uma atualização?

Um URL que ninguém partilhou não tem pré-visualização em cache, por isso sim — à custa de um segundo endereço para o mesmo produto. Alterar o URL da imagem obtém o mesmo efeito sem mexer no teu permalink, que é o que o FastOG faz.

Preciso de um plugin, ou posso editar o meu tema eu mesmo?

Um og:image estático no teu tema é muito melhor do que nada, e é gratuito. O que não consegue fazer é ser diferente por produto sem criar manualmente uma imagem por produto — ou acompanhar uma alteração de preço. É nesse ponto que uma capa dinâmica se paga a si mesma.

O meu site não está no FastOG. Alguma coisa disto continua a ajudar?

Sim. As quatro caches, a ordem de verificação e os limites das plataformas são a forma como as plataformas se comportam, não como o FastOG se comporta. Percorre a lista com curl e os debuggers.

Existe um plano gratuito?

Sim. O nível Community gratuito cobre até 100 itens entre páginas de produto, categoria, loja e artigos de blogue, com cinco modelos base mais os modelos de produto Black Friday e Seasonal Offer. As suas capas são limpas — nenhum plano leva marca de água, incluindo o Community. O Community é renderizado no servidor Community partilhado e está limitado por limites de taxa por loja/IP em vez de por branding. Os planos pagos usam um servidor dedicado separado do Community, aumentam a quota de itens e desbloqueiam modelos e capacidades adicionais (badges de avaliação a partir do Starter, mapeamento de metafields a partir do Pro, regras com âmbito e renderização prioritária a partir do Scale). Os planos pagos incluem também um teste de 14 dias sem necessidade de cartão de crédito.

Experimente gratuitamente — sem necessidade de registo

Pré-visualize e teste imagens OG dinâmicas em segundos.

Abrir o Testador Gratuito de Imagens OG

From Us

A BeCaSimulations site