Facebook and Whatsapp meta tag cache issue

Question

Problem Statement

I share URLs via Facebook and Whatsapp. These messaging apps tend to generate a "rich preview" in the form of a thumbnail for the link shared. Everything seems to work fine thus far

But if I change the content which my link points to then the next time I share the same link with a completely different person, the changes are not reflected! This applies to rich preview thumbnails in both Facebook and WhatsApp. The new person whom I messaged, still sees the old thumbnail that the previous user received from me.

For example, here is a snapshot of the thumbnail rendered by the messaging apps after a message with a link was sent by me to ALICE:

And here is a snapshot of another thumbnail rendered by the messaging apps after I edited the content to which my link points. I changed the name to Pro3 and price to 549 and sent a new message to BOB ... but BOB sees the same thumbnail preview as ALICE!

Not good solutions

1. Changing the URL ever so slightly is not a solution that is a good fit for me.
2. The scrape option on Facebook debugger would only work for that platform and it is not a good fit because it must be done manually, which means it cannot scale!

What I need help with

My preferred solution is to use Cache-Control and Pragma tags (as per web-standards) for disabling cache but it doesn't seem to work.

Here is my code

 '<title>' + metaData.title + '</title>' +
    '<meta http-equiv="Cache-Control" content="no-cache, no-store, must-revalidate">\n' +
    '<meta http-equiv="Pragma" content="no-cache">\n' +
    '<meta http-equiv="Expires" content="0">\n' +
    '<meta http-equiv="refresh" content="0; url=http://my.site.com/my/products">' +
    '<meta name="description" content="' + metaData.description + '" />\n' +
    '<meta property="og:type" content="product" />\n' +
    '<meta property="og:title" content="' + metaData.title + '" />\n' +
    '<meta property="og:description" content="' + metaData.description + '" />\n' +
    '<meta property="og:image" content="' + metaData.imageUrl + '" />\n' +
    '<meta property="og:image:width" content="' + metaData.imgWidth + '"/>\n' +
    '<meta property="og:image:height" content="' + metaData.imgHeight + '" />\n' +
    '<meta property="og:image:alt" content="' + metaData.imgAlt + '"/>' +
    '<meta property="og:url" content="' + metaData.url + '" />\n' +
    '<meta name="og_site_name" property="og:site_name" content="' + metaData.domainName + '" />' +
    '<meta name="keywords" content="' + metaData.keywords + '">' +

Can someone please suggest another approach worth trying or help me fix whatever I might be doing wrong with the current approach?

Answer 1

You don't need to add the no-cache meta tag in to your codes to control the cache method, somehow it's is bad solution related to the performance as standard (should caches what we need to cache).

In this case I think you should prevent the caches just for what you need only. You can add the versioning as timestamp at last. Something like this:

<meta property="og:image" content="' + metaData.imageUrl + '?v=' + timestamp + '" />\n

Go with this way, the file will be re-downloaded whenever your app is loaded because in understanding, the file is always new. As I said above, just add into your meta tag which you need to avoid caching.

Answer 2

There is no simple solution to this. This is like controlling what someone else is doing with your URL. You want them to scrape you every time you share a URL but the sharing service would want to cache information, so that resources are saved on their end for fetching the resources

So what can you do?

• You can change the url when you share it. I usually add a ?_=<epochtim> to do so. This will work on your shortened url as well
• You could see of a 302 Temporary Redirect discourages the service to cache the url. So in that case you will have url http://site/r/<path> and it should cause a 302 withhttp://site/?_=`. If looking at the 302 these sites decide to scrape again, then the approach could help

There is no fool proof solution here and I don't think one can expect one

Answer 3

I expect this issue is relative to the Facebook and Whatsapp CDN...

Apparently on Facebook you may use the debugger tool and force Facebook to refresh the URL it has cached. (maybe use API to force the refresh), but I did not find this option on Whatsapp ...

The best solution is one of your "Not good solutions":

Changing the URL

which force implicitly the CDN to re-cache/update the new content.