2

Trying to share this article to Facebook, but the featured image (which is also specified in the open graph tag og:image) does not appear in either the share sheet, or in the post when it is created.

Facebook’s sharing debugger reports the following:

Provided og:image, https://signs.adventistchurch.com/wp-content/uploads/sites/26/2019/02/Pg44-GettyImages-867175514.jpg 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.

Strangely, the problem only affects certain articles. These articles are not affected. It seems that Facebook is tripping over particular images — but these images show up everywhere else just fine, including as a link preview when sharing to LinkedIn, for example. So my analysis is that our server is configured properly, and the images are encoded properly; so the problem has to be at Facebook’s end.

Has anyone else experienced a similar problem? Has anyone found a workaround?

Improve this question
6
  • I don't know if it would help with FB, but that image is 1.4MB and saved at 98% image quality. I would never recommend saving an image for the web at greater than 90% quality. That image has all soft gradients so you can drastically reduce the JPEG save quality without losing detail. I re-saved it at 60% quality. It looks the same to me and is only 128K.
    – Stephen Ostermiller ♦
    Mar 5, 2019 at 8:40
  • I agree that the image should be compressed. But the lack of compression is not the trigger for this problem — I have tried both lowering the resolution and increasing the compression — makes no difference to Facebook.
    – Brett Donald
    Mar 5, 2019 at 23:26
  • I find I have to use image sizes that FB considers acceptable for them to appear. postplanner.com/….
    – Trebor
    Mar 6, 2019 at 0:35
  • Thanks @Trebor, the workaround I have been using is to use a different image editor to re-save (and compress) the images, but keeping the 1920x1080 resolution. That has worked for all images I've tried so far, except for the house on fire. So I tried reducing the res to 1200x628, as postplanner suggested, and yes! it worked! So it looks like using an image of 1200x628 causes Facebook to execute a different code path than an image of 1920x1080. Thanks for the tip!
    – Brett Donald
    Mar 6, 2019 at 1:42
  • Glad that worked for you @Brett
    – Trebor
    Mar 6, 2019 at 3:00

3 Answers 3

Reset to default
3

You should start debugging with your server logs i.e. check if they contain any clues as to what happened when the crawler was requesting a given resource.

A sample log line would look like this: 834:2a03:2880:ff:16::face:b00c - - [12/Jan/2019:18:17:31 +0100] "GET /wp-content/uploads/2018/11/alpha.jpg HTTP/1.0" 200 534066 "-" "facebookexternalhit/1.1 (+http://www.facebook.com/externalhit_uatext.php)"

Note that the response code in this example is 200 so everything should be fine.

Without server log access we can try to emulate Facebook's bot and see if everything is OK.

Checking your URL with curl -I 'https://signs.adventistchurch.com/wp-content/uploads/sites/26/2019/02/Pg44-GettyImages-867175514.jpg' -H 'pragma: no-cache' -H 'cache-control: no-cache' -H 'upgrade-insecure-requests: 1' -H 'user-agent: facebookexternalhit/1.1 (+http://www.facebook.com/externalhit_uatext.php)' -H 'dnt: 1' -H 'accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8' -H 'accept-encoding: gzip, deflate' --compressed gives the following answer:

HTTP/2 200 
server: nginx
date: Tue, 05 Mar 2019 08:31:32 GMT
content-type: image/jpeg
content-length: 1425514
last-modified: Thu, 28 Feb 2019 03:06:49 GMT
etag: "5c775049-15c06a"
x-type: static/known
cache-control: public, max-age=2592000
vary: Accept-Encoding
access-control-allow-origin: *
accept-ranges: bytes

So either everything should be fine or we're not treated as Facebook's bot.

I can see that you are using WPEngine as your hosting provider, which might do some wonky checks/redirections even if the examples they give shouldn't apply.

They do admit that it could interfere with Facebook's bot, though:

WHEN SHOULD IT BE TURNED OFF?

If a service you’re using to scan your site is having issues or receiving a 301 redirect, there’s a chance this is due to the redirect bots setting. For example, using Facebook’s URL debugger tool attempts to scrape a specific page of the site that ends in a number, using one of the well known user agents that is redirected by default. This causes the tool to show an error. With this setting turned off, it allows Facebook to properly scrape and analyze the data given.

So it seems like you should try turning it off and checking again.

Improve this answer
1
  • Thanks for your suggestions. WPEngine switched off Redirect Bots for me, but that didn't help. I will edit my question to add the information that some articles are affected, and some are not.
    – Brett Donald
    Mar 5, 2019 at 23:30
2

Our issue was with newly installed SSL certificate.

Our blog is also hosted on WPEngine and in our case the problem started to appear after we updated our SSL certificates.

It took me a lot of convincing and elevating the problem until WPEngine support began to dig deeper until they found that they forgot to chain the SSL certificate. Facebook didn't properly report this issue hence the confusion.

After they fixed that the error of "This can happen due to several different reasons such as your server using unsupported content-encoding." went away. As long as the images are ~1200px wide we have no problems any longer.

Improve this answer
2
  • Were you using a WPEngine-managed Lets Encrypt certificate? Or a DIY retail certificate?
    – Brett Donald
    Jun 6, 2019 at 12:30
  • It was a retail certificate which I then uploaded via sFTP to a dedicated folder and then asked WPEngine support to activate it (as per their documentation). It worked for several years until last time. A human error.
    – Denis Zubkov
    Jun 9, 2019 at 12:22
1

One workaround I have found which seems to work most of the time is to take the image which has been edited in Photoshop to a pixel size of 1920x1080 and exported (at 100% quality), and to open it in another image editor (Fireworks) and export it from there (at 90% quality).

However, the above procedure did not work with one particular image. For that image, I was able to get it working by editing in Photoshop to a pixel size of 1200x628 (as per this cheat sheet, thanks @Trebor) and exporting at 90% quality.

I only have a small sample size at this stage, so only time will tell whether these workarounds turn out to be 100% reliable. And of course, these workarounds are only necessary because Facebook’s image processing for link sharing code is buggy. Hopefully one day Facebook will fix the underlying issue.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.