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.


我可以看到调试器正在从您的URL检索4og:image标记。

第一个图像是最大的,因此加载时间最长。 试着缩小第一个图像,或者改变顺序,先显示一个更小的图像。


有些属性可以附加额外的元数据。这些元数据的指定方式与其他具有属性和内容的元数据相同,但属性将有额外的:

image属性有一些可选的结构化属性:

og:image:url -与og:image相同。 image:secure_url—An 如果网页需要HTTPS,可以使用其他url。 og:image:type - A 此映像的MIME类型。 og:image:width -像素的宽度。 og:image:height -高的像素数。

完整的图像示例:

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

因此,您需要将HTTPS url的og:image属性更改为og:image:secure_url

Ex:

图片的HTTPS元标签:

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

图片的HTTP元标签:

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

来源:http://ogp.me/#structured <—您可以访问该网站了解更多信息。

编辑:不要忘记在更新代码后ping facebook服务器- URL Linter


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

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


从谷歌到这里,但这对我没有多大帮助。事实证明,该标志要求的最小纵横比为3:1。我的几乎是4:1。我用Gimp裁剪到3:1,瞧——我的标志现在显示在FB上。


经过几个小时的测试和尝试……

我尽可能简单地解决了这个问题。 我注意到他们在Facebook开发者页面中使用了“测试页面”,其中只包含“og”标签和body标签中的一些文本,这些文本引用了这个og标签。

我做了什么?

我在我的应用程序中创建了第二个视图,包含他们使用的相同内容。

我怎么知道Facebook正在访问我的页面,所以我可以改变视图?他们有一个独特的用户代理:“facebookexternalhit/1.1”


我也遇到过类似的问题。我删除了属性="og:image:secure_url",现在它只会用og:image擦洗。有时候,少即是多


此外,当您添加用户生成的故事(不使用og:image)时,也会出现这个问题。例如:

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

以上内容只适用于http,而不适用于https。如果你使用https,你会得到一个错误说: attach image()上传失败


我不知道,如果它只是与我,但我og:image不工作,它选择我的网站标志,即使facebook调试器显示正确的图像。

但是将og:image更改为og:image:url对我来说是可行的。希望这能帮助其他面临类似问题的人。


我有同样的错误,以前没有任何帮助,所以我尝试遵循开放图形协议的原始文档,我添加了前缀属性到我的html标签,一切都变得很棒。

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

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

转到调试器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机器人请求的)。

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


我发现了另一个可能导致此问题的场景。我完成了问题和答案中描述的所有步骤,但问题仍然存在。

我检查了我的图片,发现我的一些帖子在og:image中有太大的缩略图,在几千像素和几兆字节的范围内。

这是由于最近从WP迁移到Jekyll,我用gulp优化了我的图像,但错误地使用了og:image中的原始图像。

截至目前,Facebook为我们提供了以下建议:

使用至少1200 x 630像素的图像以获得最佳显示效果 高分辨率设备。至少,您应该使用 是600 x 315像素显示链接页面帖子与较大的图像。 图像的大小可达8MB。

所以有8MB的上限。


我遇到了同样的问题,然后我注意到og:url的域不同

一旦我确定og:url和og:image的域是相同的,它就工作了。

希望这能有所帮助。


从我所观察到的,我看到,当你的网站是公共的,即使图像url是https,它只是工作正常。


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

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。(在上面的链接中阅读更多)

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


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


对我来说,这很有效:

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

类似的症状(Facebook等不能通过https正确获取og:image和其他资产)也会在站点的https证书不完全兼容时发生。

你的网站的https证书可能看起来有效(在浏览器和所有),但如果它缺少中间证书或链证书,它将不会正确抓取。这可能导致浪费大量时间检查和重新检查所有不同的缓存和元标记。

可能不是你的问题,但可能是其他人有类似的症状(比如我的)。有许多方法可以检查您的证书—我碰巧使用的是:https://www.sslshopper.com/ssl-checker.html


今天遇到了类似的问题,共享调试器帮助我解决了这个问题。Facebook(目前)似乎无法理解嵌入XMP元数据的图像。当我用不含XMP元数据的版本替换文章中的图像并重新抓取页面(使用共享调试器)时,问题就消失了。十六进制编辑器将帮助您查看映像是否包含XMP元数据。


我把http://从og:image中去掉,用普通的www代替。然后它开始正常工作。

你可以使用这个工具,通过Facebook重置你的图像抓取缓存和测试什么URL是为演示图像拉。


一旦你更新元标签,确保内容(图像)链接是绝对路径和 去这里https://developers.facebook.com/tools/debug/sharing输入你的网站链接,然后在下一页再次点击抓取


好吧……我意识到这个线程是旧的和拥挤的,但如果有人进来像我一样努力让他们的og:image标签在Facebook上工作,这里有一个对我有用的技巧:

请勿使用此链接:

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

解决你的问题。或者,如果你这样做,立即向下滚动到底部,并点击刮VIA API。

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

在资源管理器工具中显示的错误没有在“调试”工具中显示。发狂! !(在我的例子中,图像文件名中的一个空格在调试工具中无声地淘汰了我的图像,但它在资源管理器工具中显示了错误)。


我发现了另一个og图像不显示在FB卡上的原因。此外,使用FB刮刀工具来调试og元标签,我可以确认所有必需的标签在我的WordPress页面中,但我会得到以下文件下载错误,

如果og:image, < http -link-to-jpg-image >无法下载。 这可能是由于几个不同的原因,如您的服务器 使用不支持的内容编码。爬虫接受deflate和gzip内容编码。

我隐约觉得图像格式有问题,图像链接正常,但信息似乎表明内容编码有问题。

经过大量的搜索,我最终找到了WordPress服务器所需的php扩展,并意识到phop -exif模块没有安装。exif模块将exif元数据写入所有上传的图像。因此,FB og图像标记中使用的图像没有任何exif元数据与之关联。

一旦exif模块被启用,WordPress允许为一个图像重置exif元数据(Media library->select and image->Edit more details->Map exif元数据),图像现在如预期的那样出现在FB卡上。


我有一个Wordpress网站,使用og:image与一个https URL的图像和图像显示良好的Facebook预览链接。

我有另一个网站,我正在工作,使用og:image与https URL,有时图像会出现,有时他们不会。我尝试了这个页面上的建议,使用og:image:url和og:image:secure_url,两者都没有任何区别,图像不会用于预览。

这两个网站都有有效的https证书,所以不是证书问题。

在搜索了更多之后,我发现Facebook对图片有最小尺寸要求。如果og:image小于200x200px, Facebook将不会使用它。故事的推荐尺寸是600x600px,其他的推荐尺寸是1200x630px。

我在我的第二个网站上扩大了图片的大小,它们开始出现在Facebook上。神秘的解决。

希望这对你有用。


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

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

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


我使用cloudfront分发指向s3桶来提供静态图像…我的云前端起源设置重定向HTTP到https…所以也许这和这事有关?

不管……

更新og:image从https到http解决了我的问题,图像现在被张贴到facebook的帖子与我的网站链接。

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

我为我的og:image端点添加了一个新的行为,并将最小ttl、最大ttl和默认ttl设置为0。现在一切都很顺利……不理想,因为我更喜欢它被缓存,但显然FB不能处理cloudfront 304响应?


我也遇到了同样的问题,原因是Cloudflare中指定的最小TLS版本:

如果我将最小TLS设置为1.3 -没有元图像。如果我将它设置为1.2或更低-元图像出现。

社交媒体预览似乎不支持TLS 1.3,因此出现了这个问题。为了记录,我没有og:image:secure_url,并将HTTP重定向到HTTPS。该网站完全不能通过HTTP访问。只有TLS版本造成了麻烦。


我努力寻找答案,却从领英(LinkedIn)上得到了一个令人费解的错误:

我们在尝试访问URL时遇到了SSL连接错误。 请检查该网站使用的主要大小是否兼容 使用Java 8,或通过内容的URL联系技术支持。

答案是,尽管我在nginx中启用了TLSv1.2和TLSv1.3,但由于这个检查器验证了我的密码列表,TLSv1.2不可用。facebook和linkedin似乎都使用TLSv1.2来生成预览(截至2022年11月)。

根据这篇文章的第一个答案,我不得不将nginx更新为以下内容:

ssl_protocols TLSv1.3 TLSv1.2;
ssl_prefer_server_ciphers on;
ssl_ciphers "EECDH+AESGCM,EDH+AESGCM";

如果你的图片链接是这样的: “https://someurl 2022年9月14日星期三05:59:25 GMT+0000(协调世界时).jpg”

然后确保在设置URL时使用encodeURI函数(JavaScript)或其他语言中的任何类似函数。

这将帮助您创建一个可以被og:image理解的有效URL。

{ 
  'og:title': "title",
  'og:description': "description",
  'og:image': encodeURI(image),
  'og:image:secure_url': encodeURI(image),
}