FB OpenGraph og: a imagem não puxa imagens (possivelmente https?)


301

Primeiro - não acredito que seja uma questão duplicada. Procurei extensivamente problemas iguais ou semelhantes no SO e, devido à natureza da solução de problemas antes de perguntar, acredito que esse problema é único.

O Facebook não consegue entender meus og:imagearquivos e tentei todas as soluções usuais. Estou começando a pensar que isso pode ter algo a ver comhttps://...

  • Eu verifiquei http://developers.facebook.com/tools/debug e tenho zero avisos ou erros.
  • Ele encontra as imagens às quais vinculamos no " og:image", mas elas aparecem em branco. Quando clicamos na (s) imagem (s), no entanto, elas EXISTEM e é preciso direto para elas.
  • Ele mostra uma imagem - uma imagem hospedada em um servidor não https.
  • Tentamos imagens quadradas, jpegs, pngs, tamanhos maiores e tamanhos menores. Colocamos as imagens em public_html. Zero está aparecendo.
  • Não é um erro de armazenamento em cache, porque quando adicionamos outro og:imageà meta, o linter do FB encontra e lê isso. Ele mostra uma prévia. A visualização está em branco. A única exceção que estamos recebendo é para imagens que não estão neste site.
  • Achamos que talvez houvesse algum tipo de anti-lixiviação cpanelou .htaccessque estivesse impedindo a exibição das imagens, então verificamos. Não havia. Até fizemos um rápido < img src="[remote file]" >em um servidor completamente diferente e a imagem aparece bem.
  • Achamos que talvez fosse a og:typeou outra estranheza com outra meta tag. Removemos todos eles, um de cada vez, e verificamos. Nenhuma mudança. Apenas avisos.
  • O mesmo código em um site diferente é exibido sem nenhum problema.
  • Achamos que talvez não estivesse obtendo imagens porque estamos usando as mesmas páginas de produtos para vários produtos (alterando-as com base no valor de obtenção, ou seja, "details.php? Id = xxx"), mas ainda está inserindo uma imagem (de um URL diferente).
  • Deixando any og:imageou image_src, o FB não encontra nenhuma imagem.

Estou no fim da minha corda. Se eu dissesse quanto tempo eu e outros gastamos nisso, você ficaria chocado. A questão é que esta é uma loja online. Absolutamente, positivamente, NÃO podemos ter imagens. Nós temos que. Temos dez ou mais outros sites ... Esse é o único com og:imageproblemas. Também é o único https, então pensamos que talvez esse fosse o problema. Mas não podemos encontrar nenhum precedente em nenhum lugar da Web para isso.

Estas são as meta-tags:

<meta property="og:title" content="[The product name]" /> 
<meta property="og:description" content="[the product description]" /> 
<meta property="og:image" content="https://www.[ourwebsite].com/images/shirts/overdriven-blues-music-tshirt-details-black.png" />
<meta property="og:image" content="https://www.[ourwebsite].com/images/shirts/overdriven-blues-music-tshirt-art-black.png" />
<meta property="og:image" content="http://www.[ADIFFERENTwebsite].com/wp-content/uploads/2011/06/ARS-Header-Shine2.png" />
<meta property="og:image" content="https://www.[ourwebsite].com/images/ARShopHeader.png" />
<meta property="og:image" content="http://www.[ourwebsite].com/overdriven-blues-music-tshirt-art-black.JPG" />
<meta property="og:type" content="product"/>
<meta property="og:url" content="https://www.[ourwebsite].com/apparel-details.php?i=10047" />
<meta property="og:site_name" content="[our site name]" />      
<meta property="fb:admins" content="[FB-USER-ID-NUMBER]"/>
<meta name="title" content="[The product name]" />
<meta name="description" content="[The product description]" />
<link rel="image_src" href="https://www.[ourwebsite].com/images/shirts/overdriven-blues-music-tshirt-details-black.png" />
<meta name="keywords" content="[four typical keywords]">
<meta name="robots" content="noarchive">

Caso você queira, aqui está um link para uma de nossas páginas de produtos em que estamos trabalhando. [Link encurtado para tentar reduzir essa entrada nos resultados de pesquisa do nosso site]: http://rockn.ro/114

EDITAR ----

Usando a ferramenta raspadora "ver o que o facebook vê", pudemos ver o seguinte:

"image": [          
      {
         "url": "https://www.[httpSwebsite].com/images/shirts/soul-man-soul-music-tshirt-details-safari.png"
      },
      {
         "url": "https://www.[httpSwebsite].com/images/shirts/soul-man-soul-music-tshirt-art-safari.png"
      },
      {
         "url": "http://www.[theotherNONSECUREwebsite].com/wp-content/uploads/2011/06/ARS-Header-Shine2.png"
      }
   ],

Testamos todos os links encontrados para uma única página. Todas eram imagens perfeitamente válidas.

EDIT 2 ----

Tentamos um teste e adicionamos um subdomínio ao site NONSECURE (do qual as imagens são realmente visíveis no facebook). O subdomínio era http: // img. [Nonsecuresite] .com. Em seguida, colocamos todas as imagens na pasta principal do subdomínio e as referenciamos. Não puxaria essas imagens para o FB. No entanto, ele ainda puxaria qualquer imagem referenciada no domínio principal não seguro.

SOLUÇÃO POSTERIOR ----

Graças a Keegan, agora sabemos que isso é um bug no Facebook. Para contornar o problema, colocamos um subdomínio em outro site NON-HTTPS e colocamos todas as imagens nele. Referenciamos a http://img.otherdomain.com/[like-image.jpg]imagem de coordenação em og:imagecada página do produto. Tivemos que passar pelo FB Linter e executar TODOS os links para atualizar os dados do OG. Isso funcionou, mas a solução é uma solução alternativa para band-aid, e se o httpsproblema for corrigido e voltarmos a usar o domínio https natural, o FB terá armazenado em cache as imagens de um site diferente, complicando as coisas. Esperamos que esta informação ajude a salvar alguém de perder 32 horas de codificação de sua vida.


27
Pergunta bem documentada. Voto por favor para você!
DMCS 13/01/12

Para solução de problemas, tente alterar og:type: og_products:productpara o tipo de site e veja se as imagens podem ser captadas.
DMCS

2
Suculento, temos uma imagem og: referenciada a partir de um site externo que é http e não https e aparece.
precisa saber é o seguinte

1
Oi, obrigado, ótimo post. Apenas uma pequena observação sobre você se preocupar em ter que atualizar o cache se voltar aos https-urls assim que eles começarem a funcionar: eu não me preocuparia com isso, pois o cache fb é liberado após algum tempo, portanto, mantenha os dados em dobro por um tempo. dia ou dois e o cache será liberado automaticamente usando os novos URLs.
Niclas Lindqvist

1
@NiclasLindqvist Ei, só para constar, tivemos imagens antigas permanecendo no cache por MESES e meses antes, então eu aceitaria os padrões de cache do FB com um pouco de sal.
precisa saber é o seguinte

Respostas:


93

Encontrei o mesmo problema e o relatei como um bug no site de desenvolvedor do Facebook. Parece bastante claro que os og:imageURIs usando HTTP funcionam bem e os URIs usando HTTPS não. Eles agora reconheceram que estão "investigando isso".

Atualização: a partir de 2020, o bug não será mais visível no sistema de tickets do Facebook. Eles nunca responderam e eu não acredito que esse comportamento tenha mudado. No entanto, especificar URI HTTPS og:image:secureparece estar funcionando bem.


3
KEEGAN! Obrigado! Esta é a primeira vez que vimos o problema HTTPS documentado como sendo um bug ... e parecemos muito atentos. Publicando nossa solução alternativa nos comentários da pergunta.
usar o seguinte código

2
Desde agosto de 2013, esse URL não mostra o bug. Houve alguma atualização?
Andreas Andreou 12/08

3
developers.facebook.com/bugs/256470807842897 Esse bug mais recente também é relevante. Embora a pergunta tenha sido respondida, achei que adicionaria o link aqui; portanto, se alguém mais com um problema semelhante parar aqui, eles o encontrarão.
Zoidberg

4
Diz que o problema foi corrigido em 18 de março de 20145, não para mim, pensei.
Mike Flynn

1
@MattBrowne Nope, não está consertado para mim :-(
starbeamrainbowlabs

131

Algumas propriedades podem ter metadados extras anexados a elas. Eles são especificados da mesma maneira que outros metadados com propertye content, mas propertyterão extra:

A og:imagepropriedade possui algumas propriedades estruturadas opcionais:

  • og:image:url - Idêntico ao og: imagem.
  • og:image:secure_url - Um URL alternativo para usar se a página da Web exigir HTTPS.
  • og:image:type - Um tipo MIME para esta imagem.
  • og:image:width - O número de pixels de largura.
  • og:image:height - O número de pixels de altura.

Um exemplo de imagem completa:

<meta property="og:image" content="http://example.com/ogp.jpg" />
<meta property="og:image:secure_url" content="https://secure.example.com/ogp.jpg" /> 
<meta property="og:image:type" content="image/jpeg" /> 
<meta property="og:image:width" content="400" /> 
<meta property="og:image:height" content="300" />

Portanto, você precisa alterar a og:imagepropriedade dos URLs HTTPS paraog:image:secure_url

Ex:

META TAG HTTPS PARA IMAGEM:

<meta property="og:image:secure_url" content="https://www.[YOUR SITE].com/images/shirts/overdriven-blues-music-tshirt-details-black.png" />

TAG META HTTP PARA IMAGEM:

<meta property="og:image" content="http://www.[YOUR SITE].com/images/shirts/overdriven-blues-music-tshirt-details-black.png" />

Fonte: http://ogp.me/#structured <- Você pode visitar este site para obter mais informações.

Espero que isso ajude você.

EDIT: Não se esqueça de executar ping nos servidores do facebook após atualizar seus códigos - URL Linter


1
Senhor, muito obrigado. Eu não sabia que havia mais metadados para imagens! Tentamos fazer a imagem: secure_url por si só e o FB lançou um erro. Tentamos o image & secure_url * de várias maneiras) e o linter não mostrou nenhuma alteração.
precisa saber é o seguinte

Para mim, ele continua mostrando as imagens de visualização, não a imagem da metatag. Definitivamente, também tenho o URL certo! :( Idéias?
jaminroe

1
@jaminroe Você fiava? Se não o fia, então. Isso deve resolver principalmente o problema. Se ainda assim não escolher, veja o que a ferramenta pode raspar, você também pode ver o que está sendo raspado, há um link no final do resultado, See exactly what our scraper sees for your URLclique nele e veja se está mostrando a fonte completa ou a remoção do link qualquer coisa. Se charsetestiver errado , o raspador não poderá raspar por algum motivo (eu respondi a uma pergunta semelhante há algum tempo com esse problema). Portanto, verifique se todas essas coisas estão corretas.
Syed IR

3
Caso ajude alguém - nosso URL og: image não possui uma extensão de arquivo, pois as imagens são criadas por um serviço (/ foo / bar). Esta resposta corrigiu nossos problemas com o Facebook linter, provavelmente devido a og: type = "image / png". Obrigado!!
Dunc

3
@JohnWasham A og:imagetag pode ser HTTPS (que é o que StackExchange, YouTube, WordPress.com, Amazon etc.). Isso faz você se perguntar o que og:image:secure_urlé realmente?
docroot

16

Eu não sei, se é só comigo, mas para mim og:imagenão funciona e escolhe o logotipo do meu site, mesmo que o depurador do facebook mostre a imagem correta.

Mas mudar og:imagepara og:image:urlfuncionou para mim. Espero que isso ajude outras pessoas que enfrentam problemas semelhantes.


Felicidades - funcionou para mim - mas o depurador do facebook também quer imagem, então eu envio as duas. og: image e og: image: url - ambos com o mesmo valor / url
pperrin

1
A sintaxe og: image: url é reconhecida ou está incorreta e, portanto, não é analisada? Em outras palavras, é o mesmo que não ter a meta tag?
Jonathan Tonge

@JonathanTonge A codificação para ogp.me " og:image:urlé idêntica a og:image".
docroot

9

Cheguei aqui do Google, mas isso não foi de grande ajuda para mim. Verificou-se que há uma proporção mínima de 3: 1 necessária para o logotipo. O meu era quase 4: 1. Eu usei o Gimp para cortá-lo com exatamente 3: 1 e pronto - meu logotipo agora é exibido no FB.


2
É uma razão máxima de aspecto de 3: 1 ( developers.facebook.com/docs/opengraphprotocol ), com um tamanho mínimo de 50 pixels x 50 pixels
rpearce

1
De acordo com o depurador do facebook, o requisito de tamanho agora é de 200px x 200px
braX

8

tl; dr - seja paciente

Acabei aqui porque estava vendo imagens em branco veiculadas em um site https. O problema era bem diferente:

Quando o conteúdo é compartilhado pela primeira vez, o rastreador do Facebook raspa e armazena em cache os metadados do URL compartilhado. O rastreador precisa ver uma imagem pelo menos uma vez antes de poder ser renderizada. Isso significa que a primeira pessoa que compartilha um conteúdo não verá uma imagem renderizada

[ https://developers.facebook.com/docs/sharing/best-practices/#precaching]

Durante os testes, o Facebook levou cerca de 10 minutos para finalmente mostrar a imagem renderizada. Então, enquanto eu estava coçando a cabeça e jogando tags og aleatórias no facebook (e suspeitando do problema do https mencionado aqui), tudo que eu precisava fazer era esperar.

Como isso pode realmente impedir as pessoas de compartilhar seus links pela primeira vez, o FB sugere duas maneiras de contornar esse comportamento: a) executando o OG Debugger em todos os seus links: a imagem será armazenada em cache e pronta para compartilhamento após ~ 10 minutos ou b ) especificando og: image: width e og: image: height. (Leia mais no link acima)

Ainda me pergunto o que os leva tanto tempo ...


A razão para isso é a proporção da imagem. Se a relação de dimensão da imagem não é exatamente 1,91: 1 e / ou os og:image:widthe og:image:heightdados i não incluído, então o Facebook terá de processar a imagem após a demolição-lo para caber suas dimensões. A imagem também será cortada, o que pode ser indesejável. Para obter detalhes, consulte: developers.facebook.com/docs/sharing/best-practices/#images
Slicktrick

1
Especificar og: image: width e og: image: height em imagens que não estão em uma lista muito curta de resoluções qualificadas, não acelera as coisas nos meus testes.
Chris Moschini

5

Eu tive o mesmo erro e nada do anterior ajudou, então tentei seguir a documentação original do Open Graph Protocol e adicionei o atributo prefix à minha tag html e tudo ficou incrível.

<html prefix="og: http://ogp.me/ns#">

2

Eu tive problemas semelhantes. Eu removi a propriedade = "og: image: secure_url" e agora ele esfrega com apenas og: image. As vezes menos é mais


1
Sua resposta deve ter muito mais votos! Você está completamente certo, se você veicular conteúdo apenas por https, basta usar og: image: url e pronto.
marcvangend

1
Não consigo entender por que isso é uma solução. a questão claramente não têm a SECURE_URL em primeiro lugar, por que você acha que funciona, é muito aleatório
Decebal

1

Eu descobri outro cenário que pode causar esse problema. Passei por todas as etapas descritas na pergunta e nas respostas, ainda o problema permaneceu.

Verifiquei minhas imagens e descobri que algumas das minhas postagens tinham imagens em miniatura muito grandes og:imageno intervalo de vários milhares de pixels e vários megabytes.

Isso aconteceu devido à recente migração do WP para o Jekyll, eu otimizei minhas imagens com gulp, mas usei as imagens originais em og: image por engano.

O Facebook nos dá as seguintes recomendações a partir de hoje :

Use imagens com pelo menos 1200 x 630 pixels para obter a melhor exibição em dispositivos de alta resolução. No mínimo, você deve usar imagens de 600 x 315 pixels para exibir postagens de páginas de links com imagens maiores. As imagens podem ter até 8 MB de tamanho.

Portanto, há um limite superior de 8 MB.


1

Como descobri acidentalmente, a imagem em branco transparente vem com o cabeçalho de resposta, indicando a possível causa do problema.

  1. Vá para o depurador em https://developers.facebook.com/tools/debug/og/object/
  2. Coloque seu URL
  3. Na parte inferior, o facebook mostra sua "imagem" (GIF transparente 1x1)
    1. A imagem está vinculada à sua imagem original - não adianta pressioná-la
    2. Pressione para a direita e veja a imagem (você verá algo como https://external-ams3-1.xx.fbcdn.net/safe_image.php?d=...&url=...)
  4. Ative a guia Net nas ferramentas firebug / desenvolvedor, atualize a página, se necessário
  5. Você receberá um x-error-detailcabeçalho de resposta com uma explicação

Por exemplo, no meu caso, foi Invalid image extension for URL: https://[mydomain]/[myfilename].jpg

O verdadeiro problema no meu caso estava relacionado ao prerender.io .

Como se vê, se a imagem é solicitada via pré-renderizador, é convertida em HTML. Algo assim:

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd">
<html>
<head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head>
<body style="margin: 0px;"><img style="-webkit-user-select: none; cursor: -webkit-zoom-in; " src="https://[yourdomain].com/[yourfilename].jpg" width="1078" height="718"></body>
</html>

É um bug no pré-renderizador propriamente dito ou deve estar configurado no seu proxy para não usar o pré-renderizador para *.jpgsolicitações (mesmo que sejam solicitadas pelo bot do Facebook).

É realmente difícil perceber isso, pois o pré-renderizador é usado apenas em determinados cabeçalhos de agente do usuário.


1

Encontrei o mesmo problema e notei que tinha um domínio diferente para o og:url

Uma vez, verifiquei se o domínio era o mesmo og:urle og:imagefuncionou.

Espero que isto ajude.


2
Porém, isso nem sempre é possível, porque og: image pode ser um URL de CDN na frente da nuvem. Além disso, no meu caso, enquanto o FB (em 2017!) Não está captando a imagem CDN da própria página, está capturando outra imagem CDN que também é Cloudfront, o que significa que também não é o meu: og: url. Portanto, seu argumento está incorreto.
PKHunter

Isso é verdade. Eu não estava usando um URL da CDN. Eu apenas pensei em compartilhar o que funcionou para mim.
Darren Hall


1

Sintomas semelhantes (o Facebook e outros não estão buscando corretamente og: image e outros ativos por https) podem ocorrer quando o certificado https do site não é totalmente compatível.

O certificado https do seu site pode parecer válido (chave verde no navegador e tudo), mas não raspa corretamente se estiver faltando um certificado intermediário ou em cadeia. Isso pode levar a muitas horas perdidas verificando e verificando novamente todos os vários caches e metatags.

Pode não ter sido o seu problema, mas pode haver outros com sintomas semelhantes (como o meu). Há muitas maneiras de verificar seu certificado - o que eu usei: https://www.sslshopper.com/ssl-checker.html


1

Tirei http://do meu og:imagee substituí-o por simplesmente velho, www.então ele começou a funcionar bem.

Você pode usar essa ferramenta, pelo Facebook, para redefinir o cache de raspagem de imagem e testar o URL que está puxando para a imagem de demonstração.


0

Percebo que o Depurador está recuperando 4 og:imagetags do seu URL.

A primeira imagem é a maior e, portanto, leva mais tempo para carregar. Tente reduzir a primeira imagem para baixo ou altere a ordem para mostrar uma imagem menor primeiro.


Obrigado Lix! Na verdade, tínhamos uma pequena imagem quadrada, com cerca de 200x200 no máximo, como a primeira imagem por um longo tempo. Nós reorganizamos e re-raspamos várias vezes. Também fizemos uma combinação de tornar as menores, maiores ou alternativas as únicas imagens e recriar com uma taxa de sucesso zero.
precisa saber é o seguinte

0

Além disso, esse problema também ocorre quando você adiciona uma história gerada pelo usuário (onde você não usa og: image). Por exemplo:

POST /me/cookbook:eat?
  recipe=http://www.example.com/recipes/pizza/&
  image[0][url]=http://www.example.com/recipes/pizza/pizza.jpg&
  image[0][user_generated]=true&
  access_token=VALID_ACCESS_TOKEN

O exemplo acima funcionará apenas com http e não com https. Se você usar https, receberá um erro dizendo: Falha ao fazer upload da imagem anexada ()


Amor-lo, o Google está se movendo no sentido de dar mais sites relevância para sites com https, e dois anos depois de fazer esta pergunta, FB ainda está (inadvertidamente, talvez, mas ainda um pecado) punir sites que a segurança valor do seu visitante
Cyprus106


0

Hoje tive um problema semelhante, que o Debugger de Compartilhamento me ajudou a resolver. Parece que o Facebook (atualmente) não consegue entender imagens com os metadados XMP incorporados. Quando substituí as imagens em nossos artigos por versões sem metadados XMP e raspei novamente a página (usando o Sharing Debugger), o problema desapareceu. Um editor hexadecimal ajudará você a ver se sua imagem contém ou não metadados XMP.


0

No meu caso, parece que o rastreador está apenas tendo um bug. Eu tentei:

  • Alterar links apenas para http
  • Removendo o Espaço em Branco Final
  • Voltando ao http completamente
  • Reinstalando o site
  • Instalando um monte de plugins OG (eu uso o WordPress)
  • Suspeitar que o servidor tenha uma configuração estranha e estranha que bloqueie os bots (porque todos os verificadores OG não conseguem buscar tags e outras solicitações para meus sites são instáveis)

Nenhum desses trabalhos. Isso me custou uma semana. E de repente do nada parece funcionar novamente.

Aqui está minha pesquisa, se alguém encontrar esse problema novamente:

Além disso, existem mais outros que o damas Debugger objeto do Facebook para que você verifique: OpenGraphCheck.com , Open Graph Tester de Abhinay Rathore , códigos Incorporar de Iframely , Cartão Validador | Desenvolvedores do Twitter .


0

OK ... Eu sei que esse tópico é antigo e superlotado, mas no caso de alguém entrar como eu, lutando para que sua tag og: image funcione corretamente no Facebook, aqui está o truque que funcionou para mim:

NÃO use este link:

https://developers.facebook.com/tools/debug/sharing/?q=https%3A%2F%2Fwww.google.com

para resolver seu problema. Ou, se o fizer, role imediatamente para baixo e clique em Scrape VIA API.

https://developers.facebook.com/tools/explorer/?method=POST&path=%3Fscrape%3Dtrue%26id%3Dhttps%3A%2F%2Fwww.google.com&version=v5.0

Existem erros exibidos na ferramenta explorer que NÃO são mostrados na ferramenta "depuração". Enlouquecedor !!! (no meu caso, um espaço no nome do arquivo da imagem derrubou minha imagem silenciosamente na ferramenta de depuração, mas mostrou o erro na ferramenta explorer).


0

Me deparei com outro motivo para as imagens og não serem exibidas nos cartões FB. Além disso, usando a ferramenta raspador FB para depurar as metatags og , eu poderia confirmar todas as tags necessárias presentes na minha página do WordPress e, mesmo assim, obteria o seguinte erro de download de arquivo,

Fornecido og: image, <https-link-to-jpg-image> não pôde ser baixado. Isso pode acontecer devido a vários motivos diferentes, como o servidor usando codificação de conteúdo não suportada. O rastreador aceita codificações de conteúdo deflate e gzip.

Tive uma vaga sensação de que o formato da imagem estava com problemas, o link para a imagem estava funcionando, mas a mensagem parece indicar algo errado com a codificação do conteúdo.

Depois de muita pesquisa, acabei analisando as extensões php necessárias para um servidor WordPress e percebi que o módulo pho-exif não estava instalado. O módulo exif grava metadados exif em todas as imagens carregadas. Como resultado, as imagens usadas na tag FB og image não tinham nenhum metadado exif associado a elas.

Depois que o módulo exif é ativado, o WordPress permite que os metadados exif sejam redefinidos para uma imagem (Biblioteca de mídia-> selecione e imagem-> Editar mais detalhes-> Mapeie metadados exif) e a imagem agora aparece no cartão FB conforme o esperado.


-1

Pelo que observei, vejo que quando seu site é público e mesmo que o URL da imagem seja https, ele funciona bem.


-1

Para mim, isso funcionou:

<meta property="og:url" content="http://yoursiteurl" />
    <meta property="og:image" content="link_to_first_image_if_you_want" />
    <meta property="og:image" content="link_to_second_image_if_you_want" />
    <meta property="og:image:type" content="image/jpeg" /> 
    <meta property="og:image:width" content="400" /> 
    <meta property="og:image:height" content="300" />
    <meta property="og:title" content="your title" />
    <meta property="og:description"  content="your text about homepage"/> 

-2

Após várias horas de testes e testes, ...

Resolvi esse problema o mais simples possível. Percebo que eles usam "páginas de teste" dentro da Página de desenvolvedores do Facebook que contém apenas as tags "og" e algum texto na tag body que faz referência a essas tags og.

Então o que eu fiz?

Criei uma segunda visualização no meu aplicativo, contendo as mesmas coisas que eles usam.

E como sei que o Facebook está acessando minha página para que eu possa mudar a visualização? Eles têm um agente de usuário exclusivo: "facebookexternalhit / 1.1"


-2

Depois de atualizar a metatag, verifique se o link do conteúdo (imagem) é o caminho absoluto. Acesse aqui https://developers.facebook.com/tools/debug/sharing o link do site e clique scrape againna próxima página

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.