FB OpenGraph og:image not pulling images (possibly https?)

Question

Facebook cannot grasp my og:image files and I have tried every usual solution. I'm beginning to think it might have something to do with 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.

I am at the end of my rope. If I said how much time myself and others have spent on this, you'd be shocked. The issue is that this is an online store. We absolutely, positively cannot NOT have images. We have to. We have ten or so other sites... This is the only one with og:image problems. It's also the only one on https, so we thought maybe that was the problem. But we can't find any precedent anywhere on the web for that.

These are the 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">

In case you want it, here's a link to one of our product pages that we've been working on. [Link shortened to try to curb this getting into search results for our site]: http://rockn.ro/114

EDIT ----

Using the "see what facebook sees" scraper tool, we were able to see the following:

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

We tested all links it found for a single page. All were perfectly valid images.

EDIT 2 ----

We tried a test and added a subdomain to the NONSECURE website (from which images are actually visible through facebook). Subdomain was http://img.[nonsecuresite].com. We then put all images into the main subdomain folder and referenced those. It would not pull those images into FB. However, it would still pull any images that were referenced on the nonsecure main domain.

POSTED WORKAROUND ----

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.

Impudicity

Well documented question. Upvoted it for you! – Gyroscope

For troubleshooting, try changing og:type: og_products:product to type website and see if the images can be picked up. – Gyroscope

Does this happen if you serve images referenced in og:image from HTTP and not HTTPS? – Overliberal

Juicy, we have an og:image referenced from an outside site that is http and not https and it shows up. – Impudicity

Hi, thanks, great post. Just a small remark on you worrying about having to update the cache if you go back to https-urls once those start working: I wouldn't worry about that as the fb cache is released after some time, so just keep double data for a day or two and the cache will be released automatically using the new urls. – Babe

@NiclasLindqvist Hey just for the record, we've had old images stay in the cache for MONTHS and months before, so I'd take FB's cache standards with a grain of salt. – Impudicity

Very helpful. That's why my https hosted image doesn't work.hah – Cutis

Answer 1

I ran into the same problem and reported it as a bug on the Facebook developer site. It seems pretty clear that og:image URIs using HTTP work just fine and URIs using HTTPS do not. They have now acknowledged that they are "looking into this."

Update: As of 2020, the bug is no longer visible in Facebook's ticket system. They never responded and I don't believe this behavior has changed. However, specifying HTTPS URI in og:image:secure does seem to be working fine.

Ruperto

KEEGAN! Thank you! This is the first time we've seen the HTTPS issue documented as being a bug..... and we looked hard. Posting our workaround in the question comments. – Impudicity

As of Aug2013, that url doesn't show the bug. Has there been any updates to it? – Neolamarckism

developers.facebook.com/bugs/256470807842897 This newest bug is also relevant. While the question has been answered, I figured I would add the link here so if anyone else with a similar problem lands here they will find it. – Duodecimal

Says problem was fixed March 18th 20145, not for me thought. – Caravan

anybody got solution for that? – Carrasquillo

Yeah, looking into it .... fixed.... Its still completely broken, as soon as I changed form https to http it worked like a charm. Also, I tried adding :secure_url to og:image and it did not work at all, I just got error that they cant even find the og:image tag... So if you are forcing HTTPS for users, add your FB image to excluded urls and allow http for it. – Azriel

Facebook seems to load HTTPS images fine now. In my case it turned out the issue was the image size - there's a maximum image size of 8MB. – Hale

@MattBrowne Nope, it's not fixed for me :-( – Meninges

Having this issue as well. the thumbnails work fine over non secure. However it defaults to the fallback image on secure. – Jalbert

Got this exact same bug and providing an unsecure URL fixed the issue. Thanks! – Rhotacism

@keegan the facebook debug tool gives me this issue could not be downloaded because it exceeded the maximum allowed sized of 8Mb or your server was too slow to respond. i am getting images from cloud front and images are less than 30 kb and also they are valid image urls to if i give the url in browser then the images are being shows but facebook debug tool gives me this error. Kindly help me on this issue please. – Undetermined

6 years had passed and they still didn't fix that bug. – Transmute

In my case the problem was that there where some whitespaces in the filename. I solved encoding the filename with rawurlencode (PHP) – Juster

Worked, insane that FB did not fix it yet... did this: <meta property="og:image" content="[IMAGE]"/><meta property="og:image:secure" content="[IMAGE]"/> - when I had 'og:image' it was throwing warning and wrong picture when I did 'og:image:secure' it was saying it needs 'og:image' explicitly so I put both and all worked entire site and all pages working perfectly now and showing in debugger picture I want. – Marquess

Answer 2

Some properties can have extra metadata attached to them. These are specified in the same way as other metadata with property and content, but the property will have extra :

The og:image property has some optional structured properties:

• og:image:url - Identical to og:image.
• og:image:secure_url - An alternate url to use if the webpage requires HTTPS.
• og:image:type - A MIME type for this image.
• og:image:width - The number of pixels wide.
• og:image:height - The number of pixels high.

A full image example:

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

So you need to change og:image property for your HTTPS URLs to og:image:secure_url

Ex:

HTTPS META TAG FOR IMAGE:

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

HTTP META TAG FOR IMAGE:

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

Source: http://ogp.me/#structured <-- You can visit this site for more information.

EDIT: Don't forget to ping facebook servers after updating your code - URL Linter

Leukocyte

SIR, Thanks a lot. I didn't know there was further metadata for images! We did try to do image:secure_url by itself and FB threw an error. We tried image & secure_url *in a number of ways) and linter showed no change whatsoever. – Impudicity

For me, it keeps showing the Preview images, not the meta tag image. I definitely have the right URL too! :( Ideas? – Barogram

@jaminroe Did you lint? If not lint it then. That should mostly fix the issue. If it still doesn't pick, then see what the tool is able to scrape, you can also see what exactly is being scraped, there's a link at the end of result See exactly what our scraper sees for your URL click on it and see if it's showing your link's complete source or stripping anything. If wrong charset is set, then the scraper won't be able to scrape for some reason (I had answered a similar question sometime ago with this problem). So make sure all these things are correct. – Leukocyte

@Syed edit: I just noticed it said my image wasn't big enough LOL #facepalm. Guess they changed that in the past couple years – Barogram

@jaminroe: Yep, Big image is required now. So problem resolved :) – Leukocyte

In case it helps anyone - our og:image URL doesn't have a file extension as images are created by a service (/foo/bar). This answer fixed our problems with Facebook linter, presumably due to og:type="image/png". Thank you!! – Romanist

No HTTPS on my end but it was a missing "og:image:url" meta tag that fixed it for me. Thank you! – Covenanter

I see. No problem :) – Leukocyte

All our images are served over https. When only including og:image:secure_url, we got an error from FB that property 'og:image:url' of type 'url' was not provided. I understand this occurs because secure_url is an alternative, but are we really supposed to list the same image twice, once with og:image and once with og:image:secure_url? And does the og:image tag have to be http, or can it also be https? – Chirm

@JohnWasham The og:image tag can be HTTPS (which is what StackExchange, YouTube, WordPress.com, Amazon, etc. does). It kinda makes you wonder what og:image:secure_url is really for? – Hemoglobin

A combination of og:image, og:image:secure_url, og:image:width and og:image:height, solved the issue for me. Also fb tool was a big help. – Connolly

Thank you mate! Just have to scraped my url. Been solving this for hours. Cheers! – Weapon

og:image:secure_url solved the problem for me – Rancidity

THANK YOU!! og:image:secure_url HELPED ME – Laminous

Answer 3

I don't know, if it's only with me but for me og:image does not work and it picks my site logo, even though facebook debugger shows the correct image.

But changing og:image to og:image:url worked for me. Hope this helps anybody else facing similar issue.

Unkindly

Cheers - worked for me - but the facebook debugger wants image too, so I send both. og:image and og:image:url - both with the same value/url – Pelaga

Is og:image:url recognized syntax or is it incorrect and therefore isn't parsed? In other words is this the same as not having the meta tag at all? – Josejosee

@JonathanTonge Accoding to ogp.me, "og:image:url is identical to og:image". – Hemoglobin

Answer 4

tl;dr – be patient

I ended up here because I was seeing blank images served from a https site. The problem was quite a different one though:

When content is shared for the first time, the Facebook crawler will scrape and cache the metadata from the URL shared. The crawler has to see an image at least once before it can be rendered. This means that the first person who shares a piece of content won't see a rendered image

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

While testing, it took facebook around 10 minutes to finally show the rendered image. So while I was scratching my head and throwing random og tags at facebook (and suspecting the https problem mentioned here), all I had to do was wait.

As this might really stop people from sharing your links for the first time, FB suggests two ways to circumvent this behavior: a) running the OG Debugger on all your links: the image will be cached and ready for sharing after ~10 minutes or b) specifying og:image:width and og:image:height. (Read more in the above link)

Still wondering though what takes them so long ...

Potentate

The reason for this is the image ratio. If the image dimension ratio is not exactly 1.91 : 1 and/or the og:image:width and og:image:height data i not included, then Facebook will have to process the image after scrapping it to fit their dimensions. The image will also end up being cropped, which may be unwanted. For details, see: developers.facebook.com/docs/sharing/best-practices/#images – Southwick

Specifying og:image:width and og:image:height on images that aren't on their very short list of qualified resolutions, don't speed things up any in my testing. – Elyseelysee

Answer 5

Got here from Google but this wasn't much help for me. It turned out that there is a minimum aspect ratio of 3:1 required for the logo. Mine was almost 4:1. I used Gimp to crop it to exactly 3:1 and voila - my logo is now shown on FB.

Kiushu

It's a maximum aspect ratio of 3:1 (developers.facebook.com/docs/opengraphprotocol), with a minimum size of 50px x 50px – Durer

According to the facebook debugger, the size requirement is now 200px x 200px – Zounds

Answer 6

I had similar problems. I removed the property="og:image:secure_url" and now it will scrub with just og:image. Sometimes, less is more

Book

Your answer should have much more votes! You're completely right, if you only serve content over https, just use og:image:url and be done with it. – Eddieeddina

I can't understand why this is a solution. the question clearly did not have the secure_url in the first place, why would you think it works, it's too random – Hibbitts

@Hibbitts it's completely relevant to the issue at hand. it's also the only answer here that helped me so i wouldn't call it 'too random' at all. – Lyndell

Why the og specification then, why bother, why follow guidelines, why facebook does not repair, why all those rules and suggestions with 50 different possible combinations. I hate wasting my life for such things. Just saying, that it all should not be so complicated. Robots will not replace us because of such solutions. Don´t worry guys. – Edee

Answer 7

I had the same error and nothing of previous have helped, so I tried to follow original documentation of Open Graph Protocol and I added prefix attribute to my html tag and everything became awesome.

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

Centigrade

Answer 8

I have a Wordpress site that uses og:image with an https URL to the image and the images show up just fine in Facebook preview links.

I have another site I was working on that uses og:image with an https URL and sometimes the images would appear and sometimes they wouldn't. I tried the suggestions on this page, using og:image:url and og:image:secure_url and neither one made any difference, the image wouldn't be used for the preview.

Both sites have valid https certificates, so it wasn't a certificate problem.

After searching some more I found out that Facebook has a MINIMUM SIZE for images. If the og:image is less than 200x200px it will not be used by Facebook. The recommended size is 600x600px for stories and 1200x630px for everything else.

I scaled up the image sizes on my second site and they started appearing on Facebook. Mystery solved.

Hope you find this useful.

Illailladvised

I tried and it fixed my problem. – Osiris

Answer 9

As I accidentally found, transparent blank image comes with response header indicating possible cause of the problem.

1. Go to the debugger at https://developers.facebook.com/tools/debug/og/object/
2. Put your URL
3. In the bottom, facebook shows your "image" (transparent 1x1 GIF)
   1. Image is linked to your original image - no point pressing it
   2. Press right and view image (you'll get something like https://external-ams3-1.xx.fbcdn.net/safe_image.php?d=...&url=...)
4. Turn on Net tab on firebug/developer tools, refresh page if needed
5. You'll get x-error-detail response header with explanation

For example, in my case it was Invalid image extension for URL: https://[mydomain]/[myfilename].jpg

The real issue in my case was related to prerender.io.

As it turns out, if image is requested via prerender, it's converted to HTML. Something like this:

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

It's either bug in prerender itself, or it's supposed to be configured in your proxy to not use prerender for *.jpg requests (even if they are requested by Facebook bot).

It's really hard to notice this, as prerender is used only on certain user-agent headers.

Barometrograph

Answer 10

In my case the problem was in not providing CA Root Certificate. I figured it out after using: https://www.ssllabs.com/ssltest/analyze.html to analyze SSL configuration.

Aureus

Answer 11

I took http:// out of my og:image and replaced it with just plain old www. then it started working fine.

You can use this tool, by Facebook to reset your image scrape cache and test what URL it is pulling for the demo image.

Mayotte

Answer 12

I discovered another scenario that can cause this issue. I went through all the steps described in the question and the answers, still the problem remained.

I checked my images and found that some of my posts had way too large thumbnail images in og:image in the range of several thousand pixels and several megabytes.

This happened due to the recent migration from WP to Jekyll, I optimized my images with gulp, but used the original images in og:image by mistake.

Facebook gives us the following recommendations as of today:

Use images that are at least 1200 x 630 pixels for the best display on high resolution devices. At the minimum, you should use images that are 600 x 315 pixels to display link page posts with larger images. Images can be up to 8MB in size.

So there is an upper limit of 8MB.

Ability

Answer 13

I ran into the same issue and then I noticed that I had a different domain for the og:url

Once I made sure that the domain was the same for og:url and og:image it worked.

Hope this helps.

Mythology

This isn't always possible though, because og:image may be a cloudfront CDN URL. Also, in my case, while FB (in 2017!) is not picking up the CDN image from the page itself, it's picking up another CDN image which is also Cloudfront, which means that too is not my og:url. So your point is incorrect. – Roodepoortmaraisburg

That is true. I was not using a CDN URL. I just thought I that I would share what did work for me. – Mythology

Same sharing code have two diff country CDN. Which I was testing with VPN. For PH we have different CDN and for SG we have different CDN. The one with SG is showing a thumbnail. But one with PH is not showing it. Maybe the issue is with PH CDN cause it is validated against IP for PH location. Where as SG CDN have no such restrictions. – Canon

Answer 14

Similar symptoms (Facebook et al not correctly fetching og:image and other assets over https) can occur when the site's https certificate is not fully compliant.

Your site's https cert may seem valid (green key in the browser and all), but it will not scrape correctly if it's missing an intermediate or chain certificate. This can lead to many wasted hours checking and rechecking all the various caches and meta tags.

Might not have been your problem, but could be other's with similar symptoms (like mine). There's many ways to check your cert - the one I happened to use: https://www.sslshopper.com/ssl-checker.html

Friesen

Answer 15

I can see that the Debugger is retrieving 4 og:image tags from your URL.

The first image is the largest and therefore takes longest to load. Try shrink that first image down or change the order to show a smaller image first.

Jacintojack

Thanks Lix! We actually had a small square image, about 200x200 max, as the first image for a long time. We've re-arranged & re-scraped a number of times. We also did a combination of making the smaller, larger, or alternate ones the only images & rescraping with a zero success rate. – Impudicity

Answer 16

In addition, this problem also occurs when you add a user generated story (where you do not use og:image). For example:

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

The above will only work with http and not with https. If you use https, you will get an error that says: Attached image () failed to upload

Tarbox

Love it, Google's moving towards giving sites MORE relevancy to sites with https, and two years after asking this question, FB's still (inadvertently, perhaps, but still a sin) punishing websites that value their visitor's security – Impudicity

Answer 17

Don't forget to refresh servers through :

Facebook Debugger

And click on "Collect new info"

Sisera

No such link or button – Aceto

Answer 18

Had a similar problem today, which the Sharing Debugger helped me solve. It seems that Facebook can’t (currently) understand images with XMP metadata embedded. When I replaced the images on our articles with versions without XMP metadata, and re-scraped the page (using the Sharing Debugger), the problem went away. A hex editor will help you see whether or not your image contains XMP metadata.

Stepson

Answer 19

In my case, it seems that the crawler is just having a bug. I've tried:

• Changing links to http only
• Removing end white space
• Switching back to http completely
• Reinstalling the website
• Installing a bunch of OG plugins (I use WordPress)
• Suspecting the server has a weird misconfiguration that blocks the bots (because all the OG checkers are unable to fetch tags, and other requests to my sites are unstable)

None of these works. This costed me a week. And suddenly out of nowhere it seems to work again.

Here are my research, if someone meets this problem again:

• What makes Open Graph checkers unable to detect Open Graph data?

• How to know what bots of a website, if I have no root access to the hosting they will read?

• 👍 What makes Open Graph checkers unable to detect Open Graph data? - Let's Encrypt Community Support

• 👍 Crawler is unable to fetch images, but adding a brand new, unique query string can make it work for one first time - Facebook for Developers

Also, there are more checkers other than the Facebook's Object Debugger for you to check: OpenGraphCheck.com, Abhinay Rathore's Open Graph Tester, Iframely's Embed Codes, Card Validator | Twitter Developers.

Loathe

several links are dead – Misericord

Answer 20

OK... I realize this thread is old and overcrowded, but in case someone comes in like I did struggling to get their og:image tag to work right in Facebook, here's the trick that worked for me:

do NOT use this link:

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

to work through your problem. Or if you do, immediately scroll down to the bottom and click on Scrape VIA API.

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

There are errors displayed in the explorer tool that are NOT shown in the "debug" tool. Maddening!!! (in my case, a space in the image filename knocked my image out silently in the debug tool, but it showed the error in the explorer tool).

Grindstone

Answer 21

I came across another reason for og images not to display on FB cards. Furthermore, using the FB scraper tool to debug the og meta tags, I could confirm all the required tags where present in my WordPress page, and yet I would get the following file download error,

Provided og:image, < https-link-to-jpg-image > could not be downloaded. This can happen due to several different reasons such as your server using unsupported content-encoding. The crawler accepts deflate and gzip content encodings.

I had a vague feeling that the image format had an issue, the link to the image was working but the message seems to indicate something amiss with the content-encoding.

After much searching, I ended up looking at the php extensions that are required for a WordPress server, and realised the pho-exif module was not installed. The exif module writes exif metadata to all uploaded images. As a result the images used in the FB og image tag did not have any exif metadata associated with them.

Once the exif module is enabled, WordPress allows exif metadata to be reset for an image (Media library->select and image->Edit more details->Map exif metadata) and the image now appeared on the FB card as expected.

Nonrecognition

Answer 22

I arrived here because an updated facebook meta tag image wasn't showing on facebook shares.

For anyone else in this predicament, the reason was simply that you need to ask facebook to scrape your site again.

Once you do that, it will appear as expected.

Nether

Answer 23

I'm using cloudfront distributions pointing to s3 bucket to serve static images...my cloudfront origins are set to redirect http to https...so maybe that has something to do with it?

regardless...

Updating og:image from https to http resolved the issue for me, images are now being posted to facebook posts with links to my site.

UPDATE: the above behavior continued to happen...anytime I were to change the og:image url, or invalidate my cloudFront cache, the image would work on the FB debugger, but the image would never show up on FB.

I added a new behavior for my og:image endpoint and set min ttl, max ttl, and default ttl to 0. And now everything is working great...not ideal as I'd prefer it to be cached, but apparently FB can't handle the cloudfront 304 response?

Chiron

Answer 24

I had the same issue and the cause was the minimum TLS version specified in Cloudflare:

If I set minimum TLS to 1.3 - no meta images. If I set it to 1.2 or lower - meta images appear.

It seems that social media previews don't support TLS 1.3, hence the issue. For the record, I have no og:image:secure_url and have HTTP redirected to HTTPS. The site is completely not accessible via HTTP. Only the TLS version was causing trouble.

Ephemerid

Answer 25

I struggled to find an answer to this and was getting this puzzling error from LinkedIn:

We encountered an SSL connection error while trying to access the URL. Please check that the site is using a prime size that is compatible with Java 8, or contact Support with the content's URL.

The answer was, even though I had both TLSv1.2 and TLSv1.3 enabled in nginx, TLSv1.2 wasn't available due to my cipher list as verified by this checker. It appears facebook and linkedin both use TLSv1.2 to generate previews (as of Nov 2022).

I had to update nginx to the following according to the first answer on this post:

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

Solorio

Answer 26

If your image links look like this: "https://someurl Wed Sep 14 2022 05:59:25 GMT+0000 (Coordinated Universal Time).jpg"

Then make sure that you are using encodeURI function (JavaScript) or any similar function in other languages while setting the URL.

This will help you to create a valid URL which can be understood by og:image.

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

Wormwood

Answer 27

From what I observed, I see that when your website is public and even though the image url is https, it just works fine.

Dong

Answer 28

For me this worked:

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

Cristicristian

Answer 29

After several hours of testing and trying things...

I solved this problem as simple as possible. I notice that they use "test pages" inside Facebook Developers Page that contains only the "og" tags and some text in the body tag that referals this og tags.

So what have i done?

I created a second view in my application, containing this same things they use.

And how i know is Facebook that is accessing my page so i can change the view? They have a unique User Agent: "facebookexternalhit/1.1"

Marsland

Answer 30

Once you update the meta tag make sure the content(image) link is absolute path and go here https://developers.facebook.com/tools/debug/sharing enter you site link and click on scrape again in next page

Chat