Estou tendo problemas com minhas metatags com o Open Graph. Parece que o Facebook está armazenando em cache valores antigos de minhas meta tags. Valores antigos para Atributos og:titlee og:urlainda são usados, mesmo que eu já os tenha alterado.

Corri o Lint em uma página do meu site e isso apareceu:

Observe que existem dois valores para og:titlee og:url, e o último prevaleceu. No entanto, as duas últimas entradas são as entradas VELHAS que eu usei para este site. Atualmente, estou usando essas metatags (você pode verificar se visualiza a fonte do HTML):

<meta property="og:title" content="Smart og rummelig pusletaske fra Petit Amour med god plads til alt &#8211; værdi 1.099 kr &#8211; køb nu kun 599 kr   "/>
<meta property="og:description" content="Pinq.dk - Det gode liv for det halve"/>
<meta property="og:type" content="product"/>
<meta property="og:url" content="http://pinq.dk/tilbud/landsdaekkende/lissy/"/>
<meta property="og:image" content="http://pinq.dk/wp-content/themes/pinq/images/logo-top.png"/>
<meta property="og:site_name" content="Pinq" />
<meta property="fb:app_id" content="161840830532004" />

Por que o cache do Facebook og:titlee og:url? Alguém está enfrentando o mesmo problema?

1. Vá para http://developers.facebook.com/tools/debug
2. Digite o URL seguido por fbrefresh=CAN_BE_ANYTHING

Exemplos:

1. http://www.example.com?fbrefresh=CAN_BE_ANYTHING
2. http://www.example.com?postid=1234&fbrefresh=CAN_BE_ANYTHING
3. OU visite: http://developers.facebook.com/tools/debug/og/object?q=http://www.example.com/?p=3568&fbrefresh=89127348912

Eu estava com o mesmo problema ontem à noite e obtive essa solução em algum site.

O Facebook salva sua miniatura de cache. Ele não será atualizado mesmo que você exclua o thumnail / imagem do seu servidor. Mas o Facebook permite que você atualize usandofbrefresh

Eu espero que isso ajude.

A pergunta mais votada está bastante desatualizada:

Estas são as únicas 2 opções que devem ser usadas a partir de novembro de 2014 :

Para não desenvolvedores

1. Use o FB Debugger: https://developers.facebook.com/tools/debug/og/object
2. Cole o URL que deseja recuperar. Use o mesmo URL incluído na sua tag og: url
3. Clique no botão Buscar informações de raspar novamente

Para desenvolvedores

1. Faça uma chamada GET programaticamente para este URL: https://graph.facebook.com/?id=[YOUR_URL_HEREingerie&scrape=true (consulte: https://developers.facebook.com/docs/games_payments/takingpayments#scraping )
2. Verifique se a tag og: url incluída no cabeçalho dessa página corresponde à que você está passando.
3. você pode até analisar a resposta json para obter o número de compartilhamentos desse URL.

Informações adicionais sobre a atualização de imagens

• Se o URL og: image permanecer o mesmo, mas a imagem realmente tiver sido alterada, ela não será atualizada nem remontada pelos raspadores do Facebook, mesmo fazendo o acima. (mesmo passando um? last_update = [TIMESTAMP] no final do URL da imagem não funcionou para mim).
• A única solução eficaz para mim foi atribuir um novo nome à imagem.

Nota sobre atualizações de imagem ou vídeo em postagens postadas anteriormente:

• Quando você chama o depurador para descartar alterações nas tags og: da sua página, todos os compartilhamentos anteriores no Facebook desse URL ainda mostrarão a imagem / vídeo antigo. Não há como atualizar todas as postagens anteriores e é dessa forma por motivos de segurança. Caso contrário, alguém seria capaz de fingir que um usuário compartilhou algo que ele / ela realmente não compartilhou.

Se você possui muitas páginas e não deseja atualizá-las manualmente, pode fazê-lo automaticamente.

Digamos que você tenha uma página de perfil de usuário com foto:

$url = 'http://'.$_SERVER['HTTP_HOST'].'/'.$user_profile;
$user_photo = 'http://'.$_SERVER['HTTP_HOST'].'/'.$user_photo;

<meta property="og:url" content="<?php echo $url; ?>"/>
<meta property="og:image" content="<?php echo $user_photo; ?>"

Basta adicionar isso à sua página:

// with jQuery
$.post(
    'https://graph.facebook.com',
    {
        id: '<?php echo $url; ?>',
        scrape: true
    },
    function(response){
        console.log(response);
    }
);

// with "vanilla" javascript
var fbxhr = new XMLHttpRequest();
fbxhr.open("POST", "https://graph.facebook.com", true);
fbxhr.setRequestHeader("Content-type", "application/x-www-form-urlencoded");
fbxhr.send("id=<?php echo $url; ?>&scrape=true");

Isso atualizará o cache do Facebook. Se você usar a solução jQuery, consulte "response" no console.log - você encontrará o campo "updated_time" e outras informações úteis.

A miniatura do OG parece não ser atualizada, mesmo que você passe a variável fbrefresh. Para atualizar isso sem esperar pela limpeza automática, você precisará alterar o nome do arquivo do valor da metatag associado à miniatura e atualizar.

Eu tive os mesmos problemas ao usar og:image, várias tentativas de renomear o arquivo ou limpar o cache do FB não funcionaram nem pelo depurador do Facebook nem pelo teste através de uma conta real.

As novas diretrizes do facebook declaram que o tamanho da imagem deve ser 1200 x 630 ou, com essa proporção, isso parece estar errado, a única coisa que funcionou para mim foi usar uma imagem com dimensões quadradas .

Editar * Algumas horas voltei a usar 1200 x 630 e funcionou magicamente, foi mágico.

Também renomeei os arquivos para f * ^ * kfacebook.jpg, não tendo certeza de que ajudava, mas me senti bem.

Basicamente, a resposta é paciência;)

Eu verifiquei o Linter hoje de manhã e og: title e og: url são exibidos corretamente, sem os valores redundantes. Eu acho que o FaceBook limpa automaticamente o cache em algum intervalo específico. Eu só tenho que esperar.

Acabamos de descobrir isso, pois não estávamos aprendendo a URL certa, pois a URL real tinha uma string de consulta (duh, página diferente no que diz respeito a um bot).

http://example.com/

! ==

http://example.com/?utm_campaign=foo

O linter irá recuperar a página novamente, você não precisa esperar.

Sim, o facebook limpa automaticamente o cache a cada 24 horas: na verdade, o Facebook raspa as páginas e atualiza o cache a cada 24 horas https://developers.facebook.com/docs/reference/plugins/like/#scraperinfo .

Ooook, finalmente ajudou (eu uso o IP.Board). O que eu tinha que fazer era:

1. Alterar url da imagem og: no meu site (Configuração geral).
2. Experimente este método com? Fbrefresh = 1154464gd56

Obrigado ao autor por este tópico!

EDIT: O que mais você precisa lembrar sobre os requisitos de imagem. Por enquanto (janeiro de 2013) é: - pelo menos 200 px em ambas as direções - proporção máxima 3: 1

1. Visite a página do FB https://developers.facebook.com/tools/debug/og/object/
2. Digite seu domínio.
3. Clique no botão "Buscar novas informações de raspar"
4. Feito

Uma coisa a acrescentar: o URL diferencia maiúsculas de minúsculas . Observe que:

apps.facebook.com/ HELLO

é diferente aos olhos do linter

apps.facebook.com/ olá

Certifique-se de usar o URL exato do site inserido nas configurações do desenvolvedor do aplicativo. Caso contrário, o linter retornará as propriedades, mas não atualizará o cache.

Sinto muito pessoal, mas a resposta correta é:

Não existe uma maneira infalível de atualizar o gráfico aberto og: URL da imagem com resultado imediato. Ele é armazenado em cache até atualizações fb (supostamente a cada 24 horas)

Aqui estão algumas coisas que foram relatadas como funcionando por outras pessoas, mas tive sucesso ZERO com qualquer uma delas.

• Escolhendo "Buscar novas informações de raspar"
• Alterar o nome do arquivo da imagem real e / ou excluir o original
• Adicionando uma string de consulta ao URL da imagem anexando um PHP TIMESTAMP ou? Qualquer coisa
• Adicionando a cadeia de consulta "... yoursite.com/?fbrefresh=anything" ao URL de busca do depurador
• Escolhendo o link da API do gráfico na parte inferior da página og dev
• Optando por ver exatamente o que o raspador vê - não parece solicitar dados de raspagem não armazenados em cache em tempo real, ele ainda mostra o URL da imagem em cache, mesmo que o arquivo não exista mais

A inspeção do seu código é sempre uma maneira de confirmar que não há um problema no cache do navegador ou em algum serviço de cache. Se as meta informações estiverem atualizadas no seu código e você tiver tentado todas as opções acima (a menos que outra sugestão seja concretizada), a resposta correta é que você não pode fazer nada além de esperar .

Descobri que, se sua imagem tiver 72 dpi, ocorrerá um erro no tamanho da imagem. Use 96dpi. Espero que isto ajude.

1. Vá para http://developers.facebook.com/tools/debug

2. Cole o URL da página e clique em debug. Se o seu site estiver usando aliases de URL, verifique se você está usando o mesmo URL que o Facebook está usando para a página que está compartilhando (exemplo: no Drupal, use o caminho do nó / * em vez do alias, se a página for compartilhada por meio desse URL).

3. Clique no link "Compartilhar visualização" no link "Veja isso na caixa de diálogo de compartilhamento"

Os Documentos de desenvolvedor do Facebook dizem que a propriedade do título tem exceção:

Depois que 50 ações (curtidas, compartilhamentos e comentários) forem associadas a um objeto, você não poderá atualizar seu título

https://developers.facebook.com/docs/sharing/opengraph/using-objects#update

Teve uma experiência semelhante. O link do site estava mostrando um 404 na visualização que o facebook gerou. Acontece que os metadados og: url estavam incorretos. Já o consertamos há alguns dias, mas ainda estávamos vendo um 404 na pré-visualização. Usamos a ferramenta em https://developers.facebook.com/tools/debug/ e forçamos a atualização (não foi necessário anexar nenhum parâmetro a propósito) No nosso caso, o Facebook não atualizou o cache após 24 horas, mas a ferramenta ajudou a forçá-la.

É um cache, muitas vezes atualizado, é o que o cache deve fazer de vez em quando. Portanto, a espera funcionará, mas às vezes você precisa fazer isso mais rapidamente. Alterar o nome do arquivo funciona.

Eu também estava tendo esse problema. O raspador mostra as informações corretas, mas o URL de compartilhamento ainda estava preenchido com dados antigos.

A maneira como resolvi isso foi usar o método de alimentação, em vez de compartilhar, e então preencher os dados manualmente (o que não é exposto ao método de compartilhamento)

Algo assim:

shareToFB = () => {
    window.FB.ui({
    method: 'feed',
    link: `signup.yourdomain.com/?referrer=${this.props.subscriber.sid}`,
    name: 'THIS WILL OVERRIDE OG:TITLE TAG',
    description: 'THIS WILL OVERRIDE OG:DESCRIPTION TAG',
    caption: 'THIS WILL OVERRIDE THE OG:URL TAG'
  });
};

Realmente fácil resolver. Testado e funcionando. Você só precisa gerar um novo URL quando atualizar suas metatags. É tão simples quanto adicionar um "& cacheBuster = 1" ao seu URL. Se você alterar as metatags, apenas incremente o "& cacheBuster = 2"

URL original

www.example.com

URL quando as metatags são atualizadas:

www.example.com?cacheBuster=1

URL quando as metatags são atualizadas novamente:

www.example.com?cacheBuster=2

O Facebook tratará cada um como um novo URL e obterá novos metadados.

Anos depois, isso ainda é um problema comum, mas nem sempre é o cache do facebook: muitas vezes é um erro humano (permita-me elaborar)

OG: TYPE afeta a raspagem da sua imagem:

1. https://ogp.me/#type_article não é o mesmo que https://ogp.me/#type_website

Esteja ciente de que og: type = website fará com que qualquer / subpágina / desse URL se torne "canônica". Isso significa que você terá problemas para atualizar suas imagens usando o raspador, não importa o que faça.

Considere esta "suposição e erro comum"

- <meta property="og:type" content="website" />=> https://www.example.org (pai)
- <meta property="og:type" content="website" />=> https://www.example.org/sub-page/
- <meta property="og:type" content="website" />=> https://www.example.org/sub-page/child -2 /
- Ergo: /sub-page/e /child-2/herdará oog:image do pai

Esses não são "todos os sites", 1 é um site, os outros são artigos.

Se você fizer isso, o Facebook pensará que tudo isso é canônico e colocará a PRIMEIRA og: imagem em todos eles. (experimente, você verá) - se você definir o og: url como seu domínio raiz ou pai, você disse ao facebook que são todos canônicos. (há uma boa razão para isso, mas não é o tópico)

Considere esta solução (que é o que a maioria das pessoas "realmente deseja")

- <meta property="og:type" content="article" />=> https://www.example.org/sub-page/
- <meta property="og:type" content="article" />=> https://www.example.org/sub-page/child-2/

Se você fizer isso agora, o Facebook fornecerá muito menos problemas para raspar suas NOVAS imagens.

Para finalizar, SIM, os busters de cache, os vars aleatórios, os URLs e as sugestões alterados aqui podem funcionar, mas parecerão "vodu intermitente" se og:typenão for especificado corretamente.

PS: lembre-se de que um cache da CDN ou do servidor servirá para o raspador do Facebook, mesmo que você "pense" que pode ver a versão mais recente. (Não vou dedicar tempo a isso, a não ser salientar que ele desperdiçará quantidades colossais do seu tempo, se não for verificado duas vezes.)

Recentemente, tive um problema diferente, mas semelhante, com o Facebook e descobri que a página de raspador / depuração mencionada simplesmente não parece ler nenhuma página na íntegra. Minhas propriedades meta para o Open Graph estavam mais abaixo na seção principal, e o raspador me informava constantemente que a especificação da imagem não estava correta e usaria uma versão em cache independentemente. Mudei as tags Open Graph ainda mais para cima no código, perto do topo da página, e então tudo funcionava perfeitamente, sempre.