Facebook like - showing a cached version of og: image, a way to update or reindex?

You are having a problem with Facebook and og: image caching.

In short: Facebook cached an older version of our similar image. The metadata URL cannot be changed. Is there anything I can do to update it?

Long Story: The site I'm working on has a meta tag for og: image, which Facebook uses when the page likes. This meta tag uses the same image URL on all pages on the site. The image is just a branding image for the site.

The problem is that the site has recently updated its branding, and we cannot update the image like Facebook. When a user clicks on a similar link, the resulting Facebook post still shows the old branding image.

The meta tag is similar to:

<meta property="og:image" content="http://[domain].com/images/bookmark/apple-touch-icon.png"/> 

Whenever it looks like Facebook, the image url changes to a cached Facebook url similar to this:

 http://external.ak.fbcdn.net/safe_image.php?d=AQDajxm-qgVNdfEL&w=90&h=90&url=http%3A%2F%2F[domain].com%2Fimages%2Fbookmark%2Fapple-touch-icon.png 

This URL displays an earlier version of the site’s branding. More than a week has passed and it has not yet been updated.

Is there a way to get Facebook to reindex the image / clear the cache? Or, does Facebook periodically do this automatically? I could not find relevant information about this.

I know that changing the URL in the meta tag can fix the problem, but the meta tag is generated by code used on several sites, and it cannot be changed. I also tried the divider tool, as suggested by others. Bad luck.

+53
facebook facebook-like facebook-opengraph
Sep 27 '11 at 16:23
source share
4 answers

Paste your URL into your linter and it should reload its cache

+75
Sep 27 '11 at 16:28
source share

You can use the Facebook object debugger, which allows you to enter the URL of the page, and then on the next page you can resend it in the "Get new scratch information" request. This will clear the Facebook cache for the given URL - not something it might take some time to spread around all of their cache nodes.

Debugging Facebook objects can be found here: https://developers.facebook.com/tools/debug/

We recently discovered that Facebook cached URLs using a query string against a relative URL, and that the query string is ignored, which spoiled several dynamic images that we served solely on the basis of the query string.

It turns out that you can specify the last modified timestamp (in timestamp unix format) to ensure that when scanning the FB of your site, it always gets the correct image.

This can be done by including the following OG meta tag:

For dynamic sites, you need to create a content value - with PHP, the current unix timestamp can be inserted as follows:

 <meta property="og:updated_time" content="<?=time()?>" /> 

Hope this helps!

+21
Jun 24 '15 at 9:36
source share

I find a solution possible ... what if you add a random string at the end of the URL?

like www.server.com/something.php?v=<?php echo rand() ?> or www.server.com/something.jpg?v=<?php echo rand() ?>

I think the facebook cahce object is URL dependent ... changing it randomly ... might help.

+8
May 14 '13 at 10:20
source share

7 years after this post was made, and this is still a problem, but this is not a Facebook cache: this is a human error (let me clarify)

OG: TYPE affects image cleaning:

  1. https://ogp.me/#type_article is not the same as https://ogp.me/#type_website

Keep in mind that og: type = website will cause any / subpages / of this URL to become "canonical". This means that you will have problems updating the images with a scraper no matter what you do.

Consider this a "guess and common mistake"

- <meta property="og:type" content="website" /> => https://www.example.org (parent)
- <meta property="og:type" content="website" /> => https://www.example.org/sub-page/
- <meta property="og:type" content="website" /> => https://www.example.org/sub-page/child-2/
- Ergo: /sub-page/ and /child-2/ will inherit the og:image parent

This is not "all sites", 1 site, other articles.

If you do this, Facebook will consider all this canonical and place the FIRST og: image on them. (try, you will see) - if you set og: url as the root or parent domain, you told Facebook that they are all canonical. (there is a good reason for this, but this is off topic)

Consider this solution (this is what most people “really want”)

- <meta property="og:type" content="article" /> => https://www.example.org/sub-page/
- <meta property="og:type" content="article" /> => https://www.example.org/sub-page/child-2/

If you do it now, Facebook will give you much less trouble cleaning up your NEW images.

In conclusion, YES, cache blocks, random variables, changing URLs and sentences may work here, but they will look like "intermittent voodoo" if og:type not specified correctly.

PS: remember that a CDN or server cache will serve as a Facebook scraper, even if you “think” you can see the latest version. (I will not spend any time on this, except to indicate that it will spend a huge amount of your time if it is not checked twice)

0
Sep 06 '19 at 19:29
source share



All Articles