Facebook Sharing : OG Image not detected first time loaded

When running a website that you share posts regularly to Facebook, it can be frustrating when the image you have so carefully curated doesn’t appear when you drop your link into the share box on Facebook.

Why does it happen? You’ve done everything correct, and you look at your HTML source and see the og:image tag is set and the image is valid. The answer is actually quite simple. Facebook uses a specific process on first load if a post has never been shared on Facebook before. It tries to load an image asynchronously and determines image dimensions in a separate process and therefore doesn’t know what dimensions are associated. The Facebook crawler must see the image at least once before it will render the image. This means the first person sharing the image will not see a rendered image with the link.

So what option do I have to make sure that I get an image loaded with my links I share? Well there are two options

1. Pre-cache the image with the Sharing Debugger

Run the URL through the URL debugger to pre-fetch metadata for the page. You should also do this if you update the image for a piece of content.

Now this option isn’t really ideal. Having to go to the Facebook debugger to force the crawler to read the page and render the image at least once and THEN going back to Facebook to share the post successfully. It’s not ideal and if you forget and someone else tries to share the image, they get the shoddy experience.

Facebook however do offer a second option!

2. Use og:image:width and og:image:height Open Graph tags

Using these tags will specify the image dimensions to the crawler so that it can render the image immediately without having to asynchronously download and process it.

This is a little more like it. It gives us a specific tag setting we can provide to tell Facebook, “Hey that image you want to preload, don’t worry about it, just render it in this image width and height. This should work perfectly for the majority of website owners by simply placing the correct HTML tags in the header.

Despite this being a default action of WordPress SEO, which attempts to inject the featured image as og:image and grab the images size as the default height and width. Completely logical and removes a need to make any changes manually yourself, especially if you already use the popular plugin. For my site, despite the og:image, og:image:height and og:image:width tags in the head, it was not loading. On some research online, I can’t be sure it’s still an outstanding bug or not but the logic was that og:image URIs using HTTP work just fine and URIs using HTTPS do not.

I moved the website to HTTPS for no other reason than to test using SSL certs and understand the impact and limitations and security concerns of content publishing when using this. The site didn’t particularly need an SSL cert. As such I amended the WordPress Yoast SEO plugin function to set two tags instead of one. The first takes the existing image link which is HTTPs by default and outputs it using a tag og:image:secure_url, then I swap https for http and output the standard http link via og:image.

I’m still hunting for validation on whether this bug still exists in Facebook, but the fact the sites images are loading first time now suggest it may indeed still be impacting on Facebook’s Open Graph configuration for HTTPs sites.

public function image( $image = false ) {
$opengraph_images = new WPSEO_OpenGraph_Image( $this->options, $image );

foreach ( $opengraph_images->get_images() as $img ) {
$this->og_tag( 'og:image:secure_url', esc_url( $img ) );
$img = str_replace( 'https://', 'http://', $img );
$this->og_tag( 'og:image', esc_url( $img ) );
}

$dimensions = $opengraph_images->get_dimensions();

if ( ! empty( $dimensions['width'] ) ) {
$this->og_tag( 'og:image:width', absint( $dimensions['width'] ) );
}

if ( ! empty( $dimensions['height'] ) ) {
$this->og_tag( 'og:image:height', absint( $dimensions['height'] ) );
}
}