Facebook无法掌握我的og:图像文件,我已经尝试了所有常见的解决方案。我开始认为这可能与https://..有关。

I have checked http://developers.facebook.com/tools/debug and have zero warnings or errors. It is finding the images we linked to in the "og:image", but they're showing up blank. When we click the image(s), however, they DO exist and it takes is straight to them. It DOES show one image -- an image hosted on a non-https server. We've tried square images, jpegs, pngs, larger sizes and smaller sizes. We've put the images right in public_html. Zero are showing up. It's not a caching error, because when we add another og:image to the meta, FB's linter does find and read that. It DOES show a preview. The preview is blank. The only exception we're getting is for images that are not on this website. We thought maybe there was some anti-leach on cpanel or the .htaccess that was preventing the images from showing up, so we checked. There was not. We even did a quick < img src="[remote file]" > on an entirely different server and the image shows up fine. We thought maybe it was the og:type or another oddity with another meta tag. We removed all of them, one at a time and checked it. No change. Just warnings. The same code on a different website shows up without any issue. We thought maybe it was not pulling images because we're using the same product page(s) for multiple products (changing it based on the get value, ie, "details.php?id=xxx") but it's still pulling in one image (from a different url). Leaving any og:image or image_src off, FB does not find any images.

我已经山穷水尽了。如果我说我自己和其他人在这方面花了多少时间,你会感到震惊。问题是这是一个在线商店。我们绝对绝对不能没有图像。我们必须这么做。我们还有十多个其他网站……这是唯一一个有og:图像问题的。它也是唯一一个使用https的,所以我们认为这可能是问题所在。但我们在网上找不到任何这样的先例。

这些是元标签:

<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">

如果你想要它,这里有一个链接到我们一直在做的产品页面。[缩短链接,试图阻止这进入我们网站的搜索结果]:http://rockn.ro/114

编辑——

使用“see what facebook sees”刮刀工具,我们可以看到以下内容:

"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"
      }
   ],

我们测试了它为单个页面找到的所有链接。所有这些都是完全有效的图像。

编辑2 ----

我们尝试了一个测试,并在NONSECURE网站上添加了一个子域名(从该网站上的图像实际上可以通过facebook看到)。子域名为http://img.[nonsecuresite].com。然后,我们将所有图像放入主子域文件夹并引用它们。它不会把这些图片拉进FB。但是,它仍然会提取在不安全的主域上引用的任何图像。

发布的解决方案----

Thanks to Keegan, we now know that this is a bug in Facebook. To workaround, we placed a subdomain in a different NON-HTTPS website and dumped all images in it. We referenced the coordinating http://img.otherdomain.com/[like-image.jpg] image in og:image on each product page. We then had to go through FB Linter and run EVERY link to refresh the OG data. This worked, but the solution is a band-aid workaround, and if the https issue is fixed and we go back to using the natural https domain, FB will have cached the images from a different website, complicating matters. Hopefully this information helps to save someone else from losing 32 coding hours of their life.


当前回答

在我的情况下,问题是没有提供CA根证书。我在使用:https://www.ssllabs.com/ssltest/analyze.html分析SSL配置后发现了它。

其他回答

不要忘记通过以下方式刷新服务器:

Facebook的调试器

然后点击“收集新信息”

我也遇到了同样的问题,并在Facebook开发者网站上报告了一个bug。很明显,使用HTTP的og:image uri可以正常工作,而使用HTTPS的uri则不行。他们现在承认正在“调查此事”。

更新:截至2020年,该漏洞在Facebook的票务系统中不再可见。他们从来没有回应,我不相信这种行为已经改变。但是,在og:image:secure中指定HTTPS URI似乎可以正常工作。

我来到这里是因为更新的facebook元标签图像没有显示在facebook分享。

对于其他陷入这种困境的人来说,原因很简单,你需要再次要求facebook刮掉你的网站。

一旦你这样做了,它就会像预期的那样出现。

耐心点

我最终来到这里,因为我看到了一个https网站提供的空白图像。但问题是完全不同的:

当内容第一次共享时,Facebook爬虫将从共享的URL中抓取并缓存元数据。爬虫必须至少看到图像一次,然后才能渲染图像。这意味着第一个分享内容的人不会看到渲染的图像

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

在测试过程中,facebook花了大约10分钟才最终显示渲染的图像。因此,当我抓着我的头,扔在facebook随机的og标签(并怀疑https问题在这里提到),我所要做的就是等待。

因为这可能真的会阻止人们第一次分享你的链接,FB建议两种方法来规避这种行为: a)在所有链接上运行OG调试器:图像将在大约10分钟后缓存并准备共享或b)指定OG:image:width和OG:image:height。(在上面的链接中阅读更多)

我还在想他们为什么要花这么长时间……

我偶然发现,透明的空白图像带有响应头,指示问题的可能原因。

转到调试器https://developers.facebook.com/tools/debug/og/object/ 写上你的URL 在底部,facebook显示你的“图像”(透明1x1 GIF) 图像链接到您的原始图像-没有点按它 按右键查看图片(你会看到类似https://external-ams3-1.xx.fbcdn.net/safe_image.php?d=...&url=…) 打开firebug/开发者工具的Net选项卡,如果需要,刷新页面 您将得到带有解释的x-error-detail响应头

例如,在我的例子中,它是URL的无效图像扩展名:https://[mydomain]/[myfilename].jpg

在我的案例中,真正的问题与prerender.io有关。

事实证明,如果图像是通过预渲染请求的,它会被转换为HTML。就像这样:

<!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>

这要么是预渲染本身的错误,要么是在代理中配置不使用预渲染*.jpg请求(即使它们是由Facebook机器人请求的)。

很难注意到这一点,因为预渲染只在某些用户代理头上使用。