上下文
我通过https运行网站，其中新内容（每个条目都有自己的页面）可以由用户创建和共享。
每个页面都有一个图片，此图片网址显示在页面顶部的og:image元标记中。
问题
Facebook似乎很难接受og:image。当首次创建页面并且用户尝试共享URL时，对于前1-3次尝试，og:image不会被Facebook（标题和描述）删除/呈现。之后，图像在共享对话框中清晰可见。
使用Facebook的OG URL调试工具时也会出现类似的问题。我第一次弹出URL时，它没有显示图像。如果我选择再次从源中获取页面，则会显示图像。
附加说明
起初，我认为可能是网站代码最初没有显示图像，但我发送了一个curl请求并欺骗了Facebook的一个用户代理字符串（这对于访问该页面很重要）以及由此产生的结果HTML包含带有正确图片网址的og:image代码。我也知道这与访问该网页没有任何关系，或者og:title和og:description数据不会显示（但确实如此）。
我唯一的领导是它可能是SSL或HTTPS问题。我最近设置了SSL证书，但我不确定为什么会导致延迟而不能正常工作。
为了清楚起见，该站点在标准LAMP堆栈顶部的WordPress上运行。
答案 0 :(得分：6)
这个问题显然是一个相当普遍的问题。解决方案是，在内容创建时，使用内容的URL向facebook的scraper工具发送请求。刮刀将拾取并处理图像，允许第一份共享已经由Facebook缓存该图像。
答案 1 :(得分：0)
是的，我也注意到了这一点。 Facebook需要很长时间才能缓存og：image。 Tumblr自动完成。我可以想象为什么Facebook除了糟糕的编程之外还做其他事情的唯一原因是因为他们可能会有一个审阅小组滚动缩略图来阻止裸露和其他原始图像。如上所述，在创建时手动点击Facebook共享网址会提示他们对其进行缓存，希望在其他人点击之前也是如此。
答案 2 :(得分：0)
一年前我一直在分析这个问题。我有同样的问题。 og:image元标记仅在多次重新扫描尝试后才更新。
可以在此页面https://developers.facebook.com/tools/debug/
根据我以前的分析，这种行为的根本原因是FB scraper似乎有一个非常短的超时。如果内容页面没有快速回复刮刀请求，则FB不会将此回复考虑在内。即使内容页面提供正确的元数据和有效的HTTP / 200回复，FB也会忽略它，因为＆＃34;太晚太迟了＆＃34;。
除了＆＃34; prescraping＆＃34;我还没有找到任何解决方案。正如肖恩已经描述过的那样。
答案 3 :(得分：0)
就我而言，我有一个使用HTTPS设置但未安装SSL证书的Azure Web App。在生产阶段，我通过恢复为HTTP进行了测试。检测到所有“ og”标签。 因此，如果未正确配置SSL和/或Facebook给出了CURL SSL错误，则调查SSL可能会有所帮助。