How social image sharing works and how to optimize your og:image tags

Optimizing how your content looks when it’s shared on third-party platforms like Facebook, Twitter or WhatsApp can drive improved visibility, clickthrough, and conversions. But it’s not as simple as just picking a great social image and adding it to your page…

When you share a URL on Facebook, Twitter, or other platforms, they’ll typically show a preview of the page, with a title, description, and image. These elements are typically taken from Open Graph tags defined in the source code of the page you’re sharing.

How does this work?

The way in which this works is defined by the Open Graph Protocol. This is an open source standard (like WordPress, and even the Yoast SEO plugin), which allows webmasters to tell third-party systems about their pages. Third-party systems like Facebook, Twitter, Pinterest, or even WhatsApp, Skype or Hotmail.

It defines a set of meta tags which allow you to provide information about the type of content on a page (e.g., “this is a page about a movie”), metadata about that thing (e.g., “it’s called Star Wars – The Last Jedi”), and how it should be presented when shared.

They look like something this:

<meta property="og:title" content="Star Wars - The Last Jedi" />
<meta property="og:type" content="video.movie" />
<meta property="og:url" content="https://www.imdb.com/title/tt2527336/" />
<meta property="og:image" content="https://ia.media-imdb.com/images/M/MV5BMjQ1MzcxNjg4N15BMl5BanBnXkFtZTgwNzgwMjY4MzI@._V1_SY1000_CR0,0,675,1000_AL_.jpg" />
<meta property="og:image:width" content="675" />
<meta property="og:image:height" content="1000" />

Most websites (and those running the Yoast SEO plugin) automatically output elements like these for all pages, posts and archives.

The og:image tags are particularly important because Open Graph tags most commonly play a role in social sharing dialogues. This tag defines the picture which shows up when users share your content across social networks, apps, and other systems. Optimizing the composition, dimensions, and even the file size of the social image you use can influence whether somebody clicks and the quality of their experience.

Using social images that are too large, too small, or in the wrong dimensions can result in errors, or in platforms omitting your images entirely. But optimizing your Open Graph markup isn’t as simple as just picking a good social image. There are some complexities around how different platforms use these tags, treat your images, and support different rules.

TL;DR

• It’s impossible to specify different images/formats/files for different networks, other than for Facebook and Twitter. The Facebook social image is used, by default, for all other networks/systems. This is a limitation of how these platforms work. The same goes for titles and descriptions.
• The Yoast SEO plugin will automatically try and specify the best social image for each platform where you share your content, based on the constraints of these platforms.
• The image size and cropping won’t always be perfect across different platforms, as the way in which they work is inconsistent.
• Specifically, your social images should look great on ‘broadcast’ platforms like Facebook and Twitter but might sometimes crop awkwardly on platforms designed for 1:1 or small group conversations, like WhatsApp or Telegram.
• For best results, you should manually specify og:image tags for each post, through the plugin. You should ensure that your primary og:image is between 1200x800px and 2000x1600px, and is less than 2mb in size.
• We’ll be adding developer support for more advanced customization via theme functions and filters.

It’s not as simple as just picking a good social image

Even though Open Graph tags use an open standard, each platform treats Open Graph tags slightly differently. Some even have their own proprietary ‘versions’ of Open Graph tagging, too. Twitter’s ‘twitter card’ markup, for example, bears a strong resemblance to, and overlaps with, Open Graph tagging.

As an open project, the Open Graph constantly changes and improves too. Features and support come and go, the documentation isn’t always up to date, and individual platforms make (and change) their own decisions on how they interpret it, and which bits they implement.

The number of platforms keeps increasing

And as the web itself continues to evolve, there are more and more ‘platforms’ where people share content. And where the Open Graph is used. From Slack to WeChat, to tomorrow’s productivity and social media apps. They all rely on the Open Graph but use it in subtly different ways.

On modern mobile phone handsets, even your SMS messages frequently source open graph titles and images from URLs they reference. With their own proprietary approaches to (and opinions on) formats and sizes.

How does the Yoast SEO plugin deal with this?

So when we try to define a ‘best practice’ approach to support with our plugin, it’s not as simple as picking the ‘best social image’. We need to make sure that we provide the right tags and image formats for each platform and network.

To make things more complex, these tags and approaches sometimes conflict with or override each other. Twitter’s twitter:image property, for example, overrides an og:image value for images shared via Twitter, when both sets of tags are on the same page.

Lastly, the open graph specification allows us to provide multiple og:image values. This, in theory, allows the platform to make the best decision about which size to use. And allows people who share some choice over which social image they pick. How different platforms interpret these values, however, varies considerably.

This logic behind which platforms use which social images, in which scenarios, gets complex pretty quickly! So more often than not, we’re stuck relying on the og:image value(s) as a general default for all platforms. And adding specific support where we can, whilst trying to minimize conflict. This doesn’t always produce perfect results. So we’re always on the lookout for better ways to ‘get it right’. Without requiring end-users to spend hours specifying multiple social image formats for each post they write.

The challenge of og:image as a default

In a perfect world, there are two different approaches to how platforms handle Open Graph tagging. They look like this:

1. All platforms only use og:image tags. When multiple images are set, they automatically select (and crop) the best version for their context.
2. All platforms have specific Open Graph tags (or their own versions). They allow fine-grain control over every scenario. By enabling us to specify the exact image which should be used in each case.

Unfortunately, we’re stuck somewhere in-between. Some platforms allow a degree of control, but the og:image tag functions as a general fallback for all other scenarios.

This is particularly problematic, as the og:image is also Facebook’s primary image. This is a huge challenge for the Yoast SEO plugin team. And anybody else trying to define a ‘best practice’ approach to tagging. The image we specify as the main social image for Facebook sharing (usually a large, high-res picture) also has to be suitable as a general default for all platforms that don’t have their own specific tags.

Is Facebook’s social image the answer?

For many of these platforms, a large file size optimized for sharing in a Facebook newsfeed isn’t appropriate for their context. For example, Pinterest expects a relatively small, square cropped thumbnail image when sharing from a page – and whilst it has its own tagging mechanisms, the presence of an og:image tag on the page overrides those.

There’s more complexity, too. Different platforms have varying restrictions on image dimensions, ratios, and file size. A high-res og:image optimized for Facebook (with a large file size) will, more often than not, not display at all when someone shares it on Slack, for example.

Frequently, Yoast SEO has to share the same default og:image between multiple platforms. Even though they have different expectations and apply different rules and treatments. Trying to work out what the ‘default’ image tag(s) should be when it has to be the main image for Facebook and a universal default, is tricky. But it’s a problem that needs solving if we want to provide a best practice ‘default’ setting for WordPress users.

There are lots of unknowns

There are often gaps in our knowledge. Because each platform maintains its own rules and documentation on how they treat og:image tags. Specific restrictions, edge cases, and in particular, information on which rules override other rules, are rarely well-documented. The documentation which does exist is often ambiguous at best. Google+ “snippet” documentation, for example, states that they won’t use images which are “not square enough”. It’s unclear what this means in specific, technical terms. 

In order to determine the best universal approach to image sharing markup, we had to do some digging and experimentation.

We were particularly interested in understanding how different platforms react to the presence of multiple og:image tags. If we can specify more than one image, and different platforms handle that differently, perhaps there’s a way in which we can get them to pick the most suitable image for their needs.

What we found

The way in which different platforms handle og:image tags (and in particular, multiple og:image tags) is often inconsistent. And frequently complex. Thankfully, most small platforms and apps simply crop and use the og:image tag (or the first og:image tag, if there are multiple in the set), and apply some reasonable constraints around dimensions, ratio, and file size. Some of the larger and more popular platforms, however, exhibit some particularly challenging behaviors, which complicate matters.

Here are some examples of the undocumented behaviors we’ve discovered. Note that we’ve not talked about platforms that simply pick the first og:image tag, and that don’t exhibit any other ‘odd’ behavior). If you find any other undocumented features or behaviors which we haven’t covered or supported (or if we’ve made any mistakes in our research), we’d love to hear from you!

Facebook

When multiple og:image tags are specified, Facebook uses the first tag in the set. This is in line with their documentation, but contrary to popular opinion (which assumes that the largest valid image is chosen). It’s also interesting to note that it uses the first image even if it’s invalid/broken. 

Additional images are available for selection by the user at the point of sharing (on desktop only). Images are hard-cropped and sized to fit the sharing dialogue window, based on the size of the window.

Instagram

Instagram behaves similarly to Facebook, except that it will only show an image preview for ‘small’ images (if the image file size is smaller than 300KB, and the dimensions are ~256×256 – though we’ve seen up to 400×400 work). Plus it only supports JPG and PNG formats.

Twitter

Twitter uses the last image in an og:image set, unless a twitter:image tag exists. Using the twitter:image tag allows us to control Twitter images independently of all other types. But this unfortunately doesn’t allow us to specify multiple values (to accommodate for different tweet contexts/layouts).

To add some complexity, Twitter supports multiple card layouts, which can be defined in a twitter:card tag. The default value is ‘summary’ (1:1 ratio). But it’s also possible to specify ‘summary_large_image’ for a larger, full-width image (2:1) ratio.

Unhelpfully, Twitter’s documentation shows the same layout for both card versions (summary, summary with large image).

Interestingly, Twitter used to support a ‘gallery’ type of card which held multiple images. However, they deprecated this into the ‘summary with large image’ card some time ago.

WhatsApp

WhatsApp also uses the last image in the og:image set, which it hard crops to a small square. Note that, this appears to accept enormous images, both in terms of file size and dimensions; this red square is cropped from a 10000×10000, 1.49mb image. 

Skype

Takes the first og:image, but caches it seemingly permanently (both locally and in the cloud). Making it impossible to change/update an image thumbnail for a URL (without, e.g., manipulating the og:url value to include cache-busting elements).

LinkedIn

Frustratingly, if there’s oembed functionality enabled on a page (as is often the case with WordPress sites), LinkedIn with often retrieve the values from that embed code. Rather than any on-page values.

This took some rather painful debugging. But we were thankfully able to fix the problem in Yoast SEO by also rewriting the oembed values to match the on-page values (or disabling / conditionally routing oembed).

Telegram

Takes values from Facebook’s cache (typically the first og:image in a set). Cached images can be updated by messaging the Telegram bot (as a Telegram user) with up to 10 URLs. Note, caches only be updated if a page’s <html> tag contains a prefix=”og: http://ogp.me/ns#” attribute.

Pinterest

Pinterest’s documentation mentions that they “support” up to six og:image tags. However, sharing the page only ever utilizes the first* image in the set.

They also support marking up inline images through Schema.org markup. However, when an og:image tag is present on the page (which is almost always the case), it uses this instead.

There’s also some ambiguity around the difference between how they handle Open Graph data with ‘article pins’ vs ‘rich pins’. The latter is an ‘upgraded’ version which displays more information on the card. But using these requires the site owner to validate their domain.

*There’s an edge-case where, if there are more than six images in the array, the sharing dialogue periodically seems to choose the seventh value (and there’s some other weirdness depending on the total number of images in the array).

What we’ve considered, and our decisions

That’s a lot of moving parts. We need to compare all of these rules and decide which og:image tags we output for any given post or page, on any given WordPress site running the Yoast SEO plugin. That means optimizing for the most common and general use-cases, without breaking too many edge-cases. It also means providing tools, hooks, and filters in WordPress to allow users with special requirements to alter the behavior to meet their particular needs.

Which brings us to our decision

That’s why we’re choosing to optimize the first image in the og:set for large, high-resolution sharing. The kind which Facebook supports and requires. But which causes issues with networks which expect a smaller image (like Instagram, or Telegram) sharing.

Whilst you could argue that Facebook might not necessarily wield the influence and domination that it used to, it’s undoubtedly still a significant platform in terms of audience size, and a place where page/post sharing is prolific. And where the quality/treatment of the image is critical to click through.

Given that both Facebook, and most platforms’ default is the first og:image tag in a set, we must ensure that this image is a large, high-quality image (with a suitable aspect ratio for Facebook). Unfortunately, this approach has some side-effects. There’ll be many cases where the image used is too large for Instagram (and other platforms which expect small thumbnails) to feature in shared post links.

Sometimes you have to compromise

We’re not completely happy with this as a solution, but it’s the best compromise we can come up with. As an aside, we also believe that, in its current state, Open Graph markup is a bit broken. We think that it feels intuitively right that the first and default og:image in a set should be a high quality, high-resolution image – and that it’s the responsibility of the platform to crop this down appropriately, or to use secondary/smaller og:images, or to provide their own markup/solutions.

Ideally, Open Graph tags would inherit some of the kinds of thinking behind CSS media queries, where you can specify the different screen widths at which different sets of logic apply. We’ll be seeking to lobby and work with the various platforms to improve their support and collaboration in the coming months and years.

User context is an important factor

We also think that this compromise makes more sense than optimizing for smaller images. This is because the context in which smaller thumbnails are used is different.

We believe that individuals sharing URLs in one-to-one chat, or in small groups (e.g., in WhatsApp), are less likely to be negatively affected by a missing (or awkwardly sized/cropped) image. They’re usually chatting, engaged, and know the sender.

In the context of a newsfeed, like on Facebook or Twitter, the quality of the image is much more important. You’re scrolling through lots of noise and you’re less engaged. So a better image is an increased chance of a click/share/like. 

In the case of Pinterest, and other systems where your interest is the image itself, we believe that most interaction occurs directly on the image. Rather than from the page it’s on or a browser bookmarklet. Given this, we’re less concerned about Pinterest using the first og:image tag (which is a large image, optimized for Facebook) as a small, square thumbnail.

There’s an upper size limit to social images, too

The biggest image you can have (both in terms of file size and dimensions) varies by platform, too. Some platforms support huge images (Facebook allows images to be up to 8mb) – but they chop these down into smaller thumbnails depending on the context. Some have relatively small max sizes, like LinkedIn and Telegram’s 2mb limit.

This makes it even more challenging to determine what the ‘best’ image should be, and which images should feature in the og:image set. We want to show a large, high-resolution image, but not too large.

It’s particularly tricky to pick the best size with WordPress, where we’re not always sure what image sizes we’ll be working with. That’s because, when a user uploads an image to WordPress, their site creates multiple versions of that image with different sizes and cropping. Typically, these are the original ‘full’ size, and ‘large’ (1024x1024px), ‘medium_large’ (768px, cropped), ‘medium’ (300x300px) and ‘thumbnail’ (150x150px) versions. But these default sizes are often altered by WordPress theme or plugin code, and by server configuration – and frequently, some might be too large for general use.

Some automatic restrictions to help you out

Because we need to make sure that the first og:image is suitable as a general default for as many platforms as possible, the Yoast SEO plugin evaluates post content, spots all of the images, and tries to pick the best size for each post. To get this right, we’ve evaluated the maximum file sizes and dimensions of a number of platforms, and we’ve set some automatic restrictions in the plugin.

Specifically:

• When the ‘full’ size image is over 2mb and/or over 2000 pixels on either axis, we’ll try and fall back to a smaller standard WordPress image size. Or scan the post content for an alternative.
• If we can’t find a suitable smaller image, we’ll omit the og:image tag, in the hopes that the platform will select an appropriate alternative. Note that this may result in the image not appearing in some sharing contexts.
• If the ratio exceeds 3:1 we’ll present a warnin (this is the maximum ratio for many networks).

In conclusion…

We don’t want our users to have to micromanage the details of how all of this works. Of course, when you’re producing great content for your audience, you should consider how that content appears on third-party platforms. But it should be as simple a matter of picking an appropriate image, and letting the system do the rest. From sizing and file management, to ensuring that the best version shows up when it’s shared in other locations. Because every platform follows its own rules, however, we’ve had to make some decisions which won’t please every user and won’t work for every scenario.

For most normal use-cases, we’d suggest that you manually set og:image values on your posts via the Yoast SEO plugin, and ensure that their dimensions are between 1200x800px and 2000x1600px (and that they’re less than 2mb in size).

If you disagree with the decisions we’ve made, or want to help us improve our solution; we’d love for you to get in touch. WordPress and Yoast SEO are both open source products – you can help by explaining your use-cases, reporting your bugs, and thinking about how a better solution might work.

We’d love to hear your thoughts; the Open Graph is a mess at the moment, and it’s up to all of us to fix it.

Some additional technical details

We’ve taken some liberty in the og:image markup, and we’re aware that we’re adding quite a lot of weight and markup with this approach. Specifically, we’ll output HTML which looks something like this:

<meta property="og:image" content="https://www.example.com/main-image.jpg" />
<meta property="og:image:secure_url" content="https://www.example.com/main-image.jpg" />
<meta property="og:image:height" content="2000" />
<meta property="og:image:width" content="2000" />
<meta property="og:image:alt" content="A description of the image" />
<meta property="og:image:type" content="image/jpg" />

<meta property="og:image" content="https://www.example.com/second-image.jpg" />
<meta property="og:image:secure_url" content="https://www.example.com/second-image.jpg" />
<meta property="og:image:height" content="800" />
<meta property="og:image:width" content="800" />
<meta property="og:image:alt" content="A description of the image" />
<meta property="og:image:type" content="image/jpg" />

<meta property="og:image" content="https://www.example.com/third-image.jpg" />
<meta property="og:image:secure_url" content="https://www.example.com/third-image.jpg" />
<meta property="og:image:height" content="600" />
<meta property="og:image:width" content="400" />
<meta property="og:image:alt" content="A description of the image" />
<meta property="og:image:type" content="image/jpg" />

<meta property="og:image" content="https://www.example.com/fourth-image.jpg" />
<meta property="og:image:secure_url" content="https://www.example.com/fourth-image.jpg" />
<meta property="og:image:height" content="256" />
<meta property="og:image:width" content="256" />
<meta property="og:image:alt" content="A description of the image" />
<meta property="og:image:type" content="image/jpg" />

Note the progression ‘down’ from ‘large, high-quality image’, through different media sizes (depending on the site/theme setup), ending at a universal ‘small’ size.

We’ll also output a twitter:image tag, alongside the other twitter:card requirements (unless you’ve chosen to disable it in the Yoast SEO plugin config).

We’ll likely continue to iterate and improve on the approach, but here’s our rationale behind some of our assumptions:

• The og:image:type may not be strictly necessary in all cases, but there are many websites and server configurations where the images don’t have clean and recognizable ‘.jpg’ (or similar) file extensions. By making sure that we signpost the type of file, rather than making networks work it out, we reduce the risk of errors.
• Facebook’s documentation around how it uses secure_url tags is unclear, especially for sites which are fully HTTPS. However, in the case of video tags, it mentions explicitly that both tags are required, even if both feature the same HTTPS URL. As such, we’ll retain the secure_url tags even when your site and image are served over HTTPS.
• It’s generally considered best practice to label images with descriptive alt attributes, in order to support users who rely on screen readers and assistive technologies. We believe that Open Graph image tags shouldn’t be any different. This tag is only output when your images are labeled, so we encourage you to write some descriptive text during your image upload workflow.
• Our 2mb file size limit aligns, incidentally, to the default upload size set in most WordPress implementations which run on ‘off the shelf’ hosting.
• Our 2000×2000 pixel size flag should be a suitable maximum for almost all websites and screen sizes. Most browsers on desktop monitors have a width of fewer than 2,000 pixels (4k monitors and upwards often use image scaling to prevent everything from looking tiny). It’s also rare for any sharing ‘thumbnail’ activity (e.g., a Facebook message preview box) to take up the full width of the screen.
• As Google+ isn’t widely used, we chose not to add additional complexity to the Yoast SEO plugin by offering the ability to specify dedicated, schema-based image markup for Google+ images. In most cases, we believe that the default og:image should be a suitable option for Google+ sharing – though we’re keen to hear from you if you find that this is not the case.
• Unlike most other networks, WhatsApp supports SVG file formats. That means that, in theory, you could achieve optimal sharing for both WhatsApp and Facebook by setting your first og:image to be an SVG, and setting your second og:image as your full-res, large image. However. many other networks only read the first image, and won’t use the SVG file. SVG formats also come with a myriad of security risks, and so we’re not comfortable recommending their general use in this context.

Some undocumented Facebook ‘features’

If you’re feeling particularly geeky, you might also enjoy the following discoveries!

• In addition to specifying the URL of an image, you can specify its height and width. This has some benefits, including encouraging Facebook to pre-cache the image on the first time it’s shared. However, when you specify multiple og:image tags, invalid/malformed height/width in any of those tags may cause problems with all of your images. E.g., an invalid og:image:height or og:image:width value on an image which isn’t chosen, prevents pre-rendering.
• Specifying an image triggers the pre-caching process, regardless of whether it’s correct or not.
• Facebook has different ‘share layout’ sizes, depending on the image size. Small images don’t scale up to a large preview very well, so they provide a condensed layout. However, the share layout size sometimes defaults to accommodating the smallest image from a set (e.g., if you have 10 huge og:image tags, and 1 small one, you sometimes get the small share layout).
• Facebook also sometimes falls back to the ‘small’ layout if you have too many broken images in your set (as Facebook’s broken image file is only 540×300).
  

  

• Setting incorrect image sizes lets you upscale small images in the Facebook debugger. But it doesn’t look like this is respected in the share dialogue. You cannot ‘downscale’ images so far as I can tell. There’s a “upscale=1” parameter in the version of the image which Facebook creates, which I suspect controls this.

• 

  Large images break! The maximum square image size appears to be in the region of 9200×9200. However, some images with unequal dimensions larger than this, but a lower total area (e.g., 10000×3000) work. As long as a 3:1 ratio or higher.
  This suggests that the boundaries might be based, in part, on a maximum square area of ~95,000,000 pixels.
• As an additional note, when sharing a too-large image directly (linking to the file itself), Facebook shows a blank image. There’s no fallback file/function used in their ‘safe image’ cleaner in this context.
• Facebook supports a really interesting feature that lets you build relationships between pages featuring partial/linked Open Graph information. This, theoretically, allows you to ‘inherit’ and/or place centralized og markup elsewhere, reducing page weight. This might be useful for mobile/responsive subdomains, and some internationalization/versioning scenarios, perhaps, if other platforms supported it.
• Additionally, where cloaking is often a risky tactic in SEO (and frowned upon by Google), Facebook actively suggests cloaking mechanisms as a method of managing scenarios with paywalls, struggling servers, and other scenarios.
• Despite claiming otherwise in their documentation. Like Google+, Facebook’s crawler appears to ignore or disregard robots.txt directives. It’ll happily fetch Open Graph values from pages which are blocked by robots.txt files.

Some potential “hacks”?

Being stuck having to ‘share’ the first og:image tag between multiple networks is, as we’re discovering, limiting, and not ideal. Sticking to the Open Graph standards, as they’re written, lumps us with all sorts of unfortunate compromises and dead-ends.

So what if we think outside the rules a bit?

If we’re creative, there may be some clever tricks or undocumented approaches which we can use to bypass, confuse, or force certain behaviors from some of the trickier platforms.

Here are a few approaches we’ve considered, but ultimately discarded.

Can we use platform detection to create a dynamic solution?

Imagine for a moment, that every time a page is shared, the platform visits that page, reads the og:image tag(s), and grabs the social image.

Theoretically, the Yoast SEO plugin could detect which platform is requesting the page or image. And execute some clever code to serve it the perfect image for its requirements.

That’d enable us to ensure that the first og:image is the best option for the scenario. Regardless of what’s being shared, and where.

However, the platforms don’t visit every time. They visit once and save a copy of the tags (and the images) they found for a little while. That length of time, and the scenarios which cause them to revisit and/or update their cached version vary wildly by platform.

Still, theoretically, the Yoast SEO plugin could try and serve the right tags to the platform when they do visit. At the moment when they create their cache. But this approach relies heavily on the platforms identifying themselves when they visit. And on us recognizing their identities. But also on the website in question having a certain type of server configuration. And on our software doing some tricksy logic around deciding which tag(s) to show.

It might also open things up to forms of abuse by users and platforms who falsify their identities. And it won’t work for any website running any form of advanced caching (where the static pages are served to most visitors).

It’s pretty complicated, and it’s not a robust enough approach to rely on.

Hidden image techniques

Some platforms, like Pinterest, do more than just grab the og:image tag(s). They scan the page and look for other images too. That means we can place optimized social images outside of the Open Graph tags as part of the page content. And hope that users select these when sharing.

In most scenarios, those images don’t necessarily need to be visible. We can place hidden images in the source code of a page.

Unfortunately, this technique doesn’t help in most cases. Other than increasing the chance of an image showing up in a selection process. For example, where Facebook allows you to select a thumbnail from an og:image set. Or where Pinterest allows you to choose an image to share from a page when using their browser bookmarklet.

In most scenarios, in-page images are ignored when og:image tags are specified. Hiding images can also cause unexpected side-effects. Such as accessibility issues, or slower page loads. Especially when sharing the kinds of large images which platforms like Pinterest or Facebook look for.

Publish-and-switch techniques

For some platforms, like Facebook, we can ‘push’ a specific social image to them. This is done by setting the first og:image and sending a request to their cache-busting URL.

We could adapt the Yoast SEO plugin to set a specific image as the first in the set. To then ping the relevant platform’s cache-busting system to update the image. Then we could change the og:image ordering and repeat the process. Setting the best image for each platform which allows for remote cache updating

Unfortunately, this only allows us to set the initial social image. When their caches expire, we’re back to square one – they’ll use the logic we’ve outlined to pick their preferred images.

To repeat the cache-setting process, we’d need to constantly juggle the order of the tags, in line with the specific cache-expiry times of each platform. This adds a wealth of complexity and simply isn’t feasible in most site setups (especially those running their own caching solutions). Plus only a few platforms support this kind of cache-busting.

More importantly, we want to avoid tactical hacks

As we’ve explored, we’re not keen on going to these kinds of lengths to try and fix a problem which could be fixed so much more effectively, and comprehensively, by the platforms themselves. And improvements to the Open Graph protocol.

We’re not adverse to implementing clever, technical solutions to help get the image selection process right. But we’d rather work with the platforms to address the problems at the source. Rather than tackling the symptoms across the 8 million+ websites running the Yoast SEO plugin.

That’s why we’d love to hear your thoughts! How do you think WordPress, Yoast SEO, the Open Graph Protocol and big platforms like Facebook and Twitter can work together better?

Read more: Social media optimization with Yoast SEO »