FB OpenGraph og:image无法提取图片(可能是https导致的问题?)

379

Facebook无法处理我的og:image文件,我已经尝试了所有常规解决方法。我开始觉得这可能与https://...有关。

  • 我已检查http://developers.facebook.com/tools/debug,没有任何警告或错误。
  • 它可以找到我们链接到的图像在“og:image”中,但是它们显示为空白。然而,当我们单击图像时,它们确实存在,而且能够直接访问它们。
  • 它确实显示一个图像 - 一个托管在非HTTPS服务器上的图像。
  • 我们已经尝试使用正方形图像、JPEG、PNG、不同大小的图像并将它们放在public_html目录下,但是没有一个显示出来。
  • 这不是缓存错误,因为当我们添加另一个og:image到meta标记时,FB的lint工具会找到它并读取它。它确实显示预览,但预览为空白。唯一的例外是那些不在此网站上的图像。
  • 我们认为可能是cpanel或.htaccess上的反盗链措施导致图像无法显示,所以我们进行了检查,但并没有发现问题。我们甚至在完全不同的服务器上进行了< img src="[remote file]" >测试,图像可以正常显示。
  • 我们认为可能是og:type或其他meta标签的问题。我们逐一删除它们并进行检查,但没有任何变化,仅出现警告。
  • 在其他网站上相同的代码可以正常显示。
  • 我们想可能是因为我们对多个产品使用同一个产品页面(基于get值进行更改,例如“details.php?id=xxx”)而无法拉取图像,但仍然可以拉取一个图像(来自不同的URL)。
  • 如果不加任何og:image或image_src标记,FB就无法找到任何图像。

我已经束手无策了。如果我说出我和其他人在此上花费的时间,你会感到震惊。问题是这是一个在线商店。我们绝对、肯定不能没有图像。我们必须有图像。我们还有大约十个其他网站......只有这个网站有og:image问题。它也是唯一一个使用https的网站,所以我们认为这可能是问题的原因。但我们在网络上找不到任何类似的先例。

这些是meta标记:

<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

编辑——

使用“查看 Facebook 所看到的内容”抓取工具,我们能够看到以下内容:

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

我们进行了一项测试,并向非安全网站添加了一个子域名(实际上通过Facebook可以查看其中的图像)。子域名为http://img.[nonsecuresite].com。然后,我们将所有图像放入主域名文件夹中并引用它们。它不会将这些图像拉入FB。但是,它仍然会拉入在非安全主域上引用的任何图像。

发布解决方法 ----

感谢Keegan,我们现在知道这是Facebook中的一个错误。为了解决问题,我们在另一个非HTTPS网站中放置了一个子域名,并且把所有图像都放在里面。我们在每个产品页面的og:image中引用对应的http://img.otherdomain.com/[like-image.jpg]图像。然后,我们必须遍历FB Linter并运行每个链接以刷新OG数据。这起作用了,但解决方案只是一个权宜之计,如果https问题得到解决而我们回到使用自然 https 域名,则FB会从不同的网站缓存图像,使问题变得更加复杂。希望这些信息能够帮助其他人节省32个编码小时的生命


38
问题描述得非常清楚,我为你点了赞! - DMCS
尝试进行故障排除,将 og:type: og_products:product 更改为网站类型,看看是否可以获取图像。 - DMCS
2
很好,我们有一个来自外部网站的og:image引用,它是http而不是https,并且它显示出来了。 - Cyprus106
1
嗨,谢谢,很棒的帖子。只是关于你担心如果回到https-url时需要更新缓存的小备注:我不会担心这个问题,因为fb缓存在一段时间后会释放,所以只需将双倍数据保留一两天,缓存就会自动使用新的url释放。 - Niclas Lindqvist
1
@NiclasLindqvist 嘿,就记录而言,我们曾经有过旧图像在缓存中停留了数月之久,因此我认为应该对 FB 的缓存标准持保留态度。 - Cyprus106
显示剩余2条评论
30个回答

2
我偶然发现,透明空白图像附带响应头,指示问题的可能原因。
  1. 进入调试器,网址是https://developers.facebook.com/tools/debug/og/object/
  2. 输入您的URL
  3. 在底部,Facebook会显示您的“图片”(透明的1x1 GIF)
    1. 图片链接到您的原始图片-没有点击的必要
    2. 按右键查看图像(您将得到类似于https://external-ams3-1.xx.fbcdn.net/safe_image.php?d=...&url=...的内容)
  4. 在firebug/开发者工具上打开Net选项卡,如果需要,请刷新页面
  5. 您将收到带有解释的x-error-detail响应头
例如,在我的情况下,它是这样的:Invalid image extension for URL: https://[mydomain]/[myfilename].jpg 在我这种情况下,真正的问题与prerender.io有关。
事实证明,如果通过prerender请求图像,则会将其转换为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机器人请求的)。

这很难注意到,因为预渲染仅在特定的用户代理标头上使用。


1
我遇到了相同的问题,后来发现我的og:urlog:image使用了不同的域名。当我确保这两个标签使用相同的域名后,问题得到解决。希望这能帮到你。

3
但是这并非总是可行的,因为og:image可能是Cloudfront CDN URL。而且,在我的情况下,虽然FB(在2017年!)没有从页面本身获取CDN图像,但它正在获取另一个CDN图像,该图像也是Cloudfront,这意味着那个图像也不是我的og:url。所以你的观点是不正确的。 - PKHunter
没错。我没有使用CDN URL。我只是想分享一下对我有用的东西。 - Darren Hall
同样的共用代码有两个不同的国家CDN。我正在使用VPN进行测试,对于PH我们有不同的CDN,对于SG我们也有不同的CDN。 SG的那一个显示了缩略图,但是PH的那一个没有显示出来。可能问题出在PH CDN上,因为它针对PH位置的IP进行验证,而SG CDN则没有这样的限制。 - Rahul Verma

1
我发现了另一种可能导致这个问题的情况。我按照问题和答案中描述的所有步骤进行了操作,但问题仍然存在。
我检查了我的图片并发现我的某些帖子在og:image中有过大的缩略图,尺寸达到几千像素和几兆字节。 这是由于最近从WP迁移到Jekyll,我使用gulp优化了我的图片,但错误地在og:image中使用了原始图片。 Facebook今天给我们以下建议

使用至少1200 x 630像素的图片以在高分辨率设备上获得最佳显示效果。最小值应该使用600 x 315像素的图片来显示具有更大图片的链接页面帖子。图片的大小可达8MB。

因此,有一个8MB的上限。

1
类似的症状(Facebook等未能正确获取og:image和其他https资源)可能会在网站的https证书不完全符合要求时发生。您的网站https证书可能看起来有效(浏览器中有绿色钥匙等),但如果缺少中间或链式证书,则无法正确抓取。这可能导致许多浪费时间的检查和重复检查各种缓存和元标记。也许这不是您的问题,但可能会出现类似症状的其他人(像我一样)。有很多检查证书的方法-我碰巧使用的是:https://www.sslshopper.com/ssl-checker.html

0

好的...我意识到这个帖子已经古老而且过度拥挤,但是如果有人像我一样苦苦挣扎地让他们的og:image标签在Facebook中正常工作,这里是对我有效的技巧:

不要使用这个链接:

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

为解决您的问题,请仔细阅读。如果已经明确了解决方案,请直接向下滚动并单击“通过API抓取”。

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

在资源管理器工具中显示的错误并未在“调试”工具中显示。这真是让人发疯!(在我的情况下,图像文件名中的空格在调试工具中默默地使我的图像消失了,但它在资源管理器工具中显示了错误)。

0

我发现了另一个导致FB卡片上og图片无法显示的原因。此外,使用FB刮刀工具来调试og meta标签,我可以确认所有必需的标签都存在于我的WordPress页面中,但我仍然会收到以下文件下载错误:

提供的og:image,<https-link-to-jpg-image>无法下载。 这可能是由于您的服务器使用不受支持的内容编码而导致的。爬虫接受deflate和gzip内容编码。

我有一种模糊的感觉,认为图像格式存在问题,图像链接有效,但消息似乎表明内容编码出了问题。

经过大量搜索,我最终查看了用于 WordPress 服务器的 php 扩展程序,并意识到 pho-exif 模块未安装。exif 模块会将 exif 元数据 写入所有上传的图像。因此,FB og 图像标签中使用的图像没有与之关联的 exif 元数据。

启用 exif 模块后,WordPress 允许重置图像的 exif 元数据(媒体库- > 选择图像 - > 编辑更多细节 - > 映射 exif 元数据),然后图像如预期地显示在 FB 卡上。


0

在我的情况下,似乎爬虫只是出现了一个错误。我尝试过:

  • 将链接更改为仅使用http
  • 删除末尾的空格
  • 完全切换回http
  • 重新安装网站
  • 安装了一堆OG插件(我使用WordPress)
  • 怀疑服务器存在奇怪的错误配置,阻止了机器人(因为所有OG检查器都无法获取标签,并且对我的网站的其他请求不稳定)

这些都没有起作用。这让我浪费了一周的时间。突然间,它又开始工作了。

如果有人再次遇到这个问题,这里是我的研究结果:

此外,除了Facebook的对象调试器之外,还有更多的检查器可供您检查:OpenGraphCheck.comAbhinay Rathore的Open Graph测试工具Iframely的嵌入代码Twitter开发者的卡片验证器

几个链接已经失效。 - Leandro Bardelli

0

我也遇到了同样的问题,造成这个问题的原因是Cloudflare中指定的最低TLS版本:

enter image description here

如果我将最低TLS设置为1.3,则没有元图像。如果我将其设置为1.2或更低,则元图像会出现。
社交媒体预览似乎不支持TLS 1.3,因此出现了问题。记录一下,我没有og:image:secure_url,并且已经将HTTP重定向到HTTPS。该网站完全无法通过HTTP访问。只有TLS版本引起了麻烦。

0

我正在使用CloudFront分发指向S3存储桶以提供静态图像...我的CloudFront源已设置为将http重定向到https...所以可能与此有关?

无论如何...

将og:image从https更新为http解决了我的问题,现在可以发布带有指向我的网站链接的Facebook帖子中的图像。

更新:上述行为继续发生...每当我更改og:image url或使我的CloudFront缓存失效时,该图像都会在FB调试器上工作,但该图像永远不会显示在FB上。

我为我的og:image端点添加了一个新的行为,并将min ttl、max ttl和default ttl设置为0。现在一切都很好...虽然不理想,因为我更喜欢它被缓存,但显然FB无法处理CloudFront 304响应?


0

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

对于其他人遇到类似问题的情况,原因很简单,你需要要求Facebook再次抓取你的网站

一旦你这样做了,它就会如预期般出现。


网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接