1. Go to http://developers.facebook.com/tools/debug
2. Enter the URL following by fbrefresh=CAN_BE_ANYTHING

Examples:

1. http://www.example.com?fbrefresh=CAN_BE_ANYTHING
2. http://www.example.com?postid=1234&fbrefresh=CAN_BE_ANYTHING
3. OR visit: http://developers.facebook.com/tools/debug/og/object?q=http://www.example.com/?p=3568&fbrefresh=89127348912

I was having the same issue last night, and 5 I got this solution from some website.

Facebook 4 saves your cache thumbnail. It won't refresh 3 even if you delete the thumnail/image from 2 your server. But Facebook allows you to 1 refresh by using fbrefresh

I hope this helps.

The most voted question is quite outdated:

These 2 are the only 2 options that should be used 1 as of November 2014:

For non developers

1. Use the FB Debugger: https://developers.facebook.com/tools/debug/og/object
2. Paste the url you want to recache. (Make sure you use the same url included on your og:url tag)
3. Click the Fetch Scrape information again Button

For Developers

1. Make a GET call programmatically to this URL: https://graph.facebook.com/?id=[YOUR_URL_HERE]&scrape=true (see: https://developers.facebook.com/docs/games_payments/takingpayments#scraping)
2. Make sure the og:url tag included on the head on that page matches with the one you are passing.
3. you can even parse the json response to get the number of shares of that URL.

Additional Info About Updating Images

• If the og:image URL remains the same but the image has actually changed it won't be updated nor recached by Facebook scrapers even doing the above. (even passing a ?last_update=[TIMESTAMP] at the end of the image url didn't work for me).
• The only effective workaround for me has been to assign a new name to the image.

Note regarding image or video updates on previously posted posts:

• When you call the debugger to scrap changes on your og:tags of your page, all previous Facebook shares of that URL will still show the old image/video. There is no way to update all previous posts and it's this way by design for security reasons. Otherwise, someone would be able to pretend that a user shared something that he/she actually didn't.

If you have many pages and don't want to 7 refresh them manually - you can do it automatically.

Lets 6 say you have user profile page with photo:

$url = 'http://'.$_SERVER['HTTP_HOST'].'/'.$user_profile;
$user_photo = 'http://'.$_SERVER['HTTP_HOST'].'/'.$user_photo;

<meta property="og:url" content="<?php echo $url; ?>"/>
<meta property="og:image" content="<?php echo $user_photo; ?>"

Just 5 add this to your page:

// with jQuery
$.post(
    'https://graph.facebook.com',
    {
        id: '<?php echo $url; ?>',
        scrape: true
    },
    function(response){
        console.log(response);
    }
);

// with "vanilla" javascript
var fbxhr = new XMLHttpRequest();
fbxhr.open("POST", "https://graph.facebook.com", true);
fbxhr.setRequestHeader("Content-type", "application/x-www-form-urlencoded");
fbxhr.send("id=<?php echo $url; ?>&scrape=true");

This will refresh 4 Facebook cache. If you use the jQuery solution, have 3 a look at "response" in console.log - you 2 will find there "updated_time" field and 1 other useful information.

The OG thumbnail does not seem to refresh 5 even if passing the fbrefresh variable. To 4 update this without waiting for automated 3 clearing you'll need to change the filename 2 of the thumbnail associated meta tag value 1 and refresh.

I had the same issues using og:image, several attempts 11 to rename the file or clear FB cache did 10 not work either via the facebook debugger 9 or testing via an actual account.

The new 8 facebook guidelines state the image size 7 should be 1200 x 630 or having that aspect 6 ratio, this seems to be wrong, the only 5 thing that worked for me was using an image 4 with square dimensions.

Edit* Afew hours I went back to use 1200 3 x 630 and it magically worked, it was magical.

I 2 also renamed the files to f*^*kfacebook.jpg, not 1 sure it helped but it felt good.

Basically, the answer is patience ;)

I checked 5 the Linter this morning, and og:title and 4 og:url displays correctly, without the redundant 3 values. I guess FaceBook automatically clears 2 its cache at some specific interval. I just 1 have to wait.

Yes, facebook automatically clears the cache 3 every 24 hours: Actually facebook scrapes 2 the pages and updates the cache every 24 1 hours https://developers.facebook.com/docs/reference/plugins/like/#scraperinfo.

Ooook, finally it helped (I use IP.Board). What 5 I had to do was:

1. Change url of og:image on my website (General configuration).
2. Try this method with ?fbrefresh=1154464gd56

Thanks to author for this 4 thread!

EDIT: What is more you need to remember 3 about image requirements. For now (january 2 2013) it's: - at least 200 px in both directions - maximum 1 ratio 3:1

1. Visit the FB page https://developers.facebook.com/tools/debug/og/object/
2. Enter your domain.
3. Click the button "Fetch new scrape information"
4. Done

0

I'm sorry folks but the correct answer is:

There is no fool proof way to update the open graph og:image url with immediate result. It is cached until fb updates (reportedly every 24 hours)

Here 9 are things that have been reported to work 8 by others but I have had ZERO success with 7 any of them.

• Choosing "Fetch new scrape information"
• Changing the actual image filename and/or deleting the original
• Adding a query string to the image url by appending a PHP TIMESTAMP or ?anything
• Adding the "...yoursite.com/?fbrefresh=anything" query string to the debugger fetch url
• Choosing the graph API link at the bottom of the og dev page
• Choosing to see exactly what the scraper sees - does not appear to request real time un-cached scrape data, it still shows the cached image url even if the file no longer exists

Inspecting your code is always 6 a spot on way to confirm it is not an issue 5 with browser cache or some caching service. If 4 the meta information is up to date in your 3 code and you've tried all of the above (unless 2 another suggestion comes to fruition), the 1 correct answer is you can do nothing but wait.

We just ran into this, as it turns out, we 5 weren't linting the right url, since the 4 real url had a query string (duh, different 3 page as far as a bot is concerned).

http://example.com/

!==

http://example.com/?utm_campaign=foo

The 2 linter will recache your page, you don't have 1 to wait.

One thing to add, the url is case sensitive. Note that:

apps.facebook.com/HELLO

is 5 different in the linter's eyes then

apps.facebook.com/hello

Be 4 sure to use the exact site url that was 3 entered in the developer settings for the 2 app. The linter will return the properties 1 otherwise but will not refresh the cache.

I've found out that if your image is 72dpi 2 it will give you the image size error. Use 1 96dpi instead. Hope this helps.

1. Go to http://developers.facebook.com/tools/debug

2. Paste in the url of the page and click 6 debug. If your site is using url aliases 5 make sure you are using the same url as 4 Facebook is using for the page you are sharing 3 (example: in Drupal use the node/* path 2 instead of the alias if the page is shared 1 via that url).

3. Click in the "Share preview" part on "See this in the share dialog" link

Facebook Developer Documents says title 4 property has exception:

Once 50 actions (likes, shares 3 and comments) have been associated with an 2 object, you won't be able to update its 1 title

https://developers.facebook.com/docs/sharing/opengraph/using-objects#update

Had a similar experience. Website link was 9 showing a 404 in the preview that facebook 8 generated. Turns out the og:url metadata 7 was wrong. We had already fixed it a few 6 days back but were still seeing a 404 on 5 the preview. We used the tool at https://developers.facebook.com/tools/debug/ and that 4 forced the refresh (didn't have to append 3 any parameters by the way) In our case, Facebook 2 didn't refresh the cache after 24 hours 1 but the tool helped force it.

It is a cache, ofc it refreshes, that's 4 what cache is ment to do once in a while. So 3 waiting will eventually work but sometimes 2 you need to do that faster. Changing the 1 filename works.

I was having this issue too. The scraper 6 shows the right information, but the share 5 url was still populated with old data.

The 4 way I got around this was to use the feed 3 method, instead of share, and then populate 2 the data manually (which isn't exposed with 1 the share method)

Something like this:

shareToFB = () => {
    window.FB.ui({
    method: 'feed',
    link: `signup.yourdomain.com/?referrer=${this.props.subscriber.sid}`,
    name: 'THIS WILL OVERRIDE OG:TITLE TAG',
    description: 'THIS WILL OVERRIDE OG:DESCRIPTION TAG',
    caption: 'THIS WILL OVERRIDE THE OG:URL TAG'
  });
};

Really easy solve. Tested and working. You 6 just need to generate a new url when you 5 update your meta tags. It's as simple as 4 adding a "&cacheBuster=1" to your url. If 3 you change the meta tags, just increment 2 the "&cacheBuster=2"

Orginal URL

www.example.com

URL when og meta tags are updated:

www.example.com?cacheBuster=1

URL when og meta tags are updated again:

www.example.com?cacheBuster=2

Facebook will treat 1 each like a new url and get fresh meta data.

Years later and this is still a common problem, but 23 its not always facebook's cache: It is very 22 often human error (allow me to elaborate)

OG:TYPE effects your image scrape:

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

Be 21 aware that og:type=website will cause any 20 /sub-pages/ of that url to become "canonical". This 19 means you will have trouble getting your 18 images to update using the scraper no matter 17 what you do.

Consider this "assumption 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 16 /child-2/ will inherit the og:image of the parent

Those are 15 not "all websites", 1 is a website, the 14 others are articles.

If you do that Facebook 13 will think all of those are canonical and 12 it will put the FIRST og:image into all 11 of them. (try it, you'll see) - if you set 10 the og:url to be your root or parent domain 9 you've told facebook they are all canonical. (there 8 is good reason for that, but its off topic)

Consider this solution (which 7 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 6 you do that now Facebook will give you far 5 far less problems with scraping your NEW 4 images.

In closing, YES the cache busters, random 3 vars, changing urls and suggestions here 2 can work, but they will seem like "intermittent voodoo" if the 1 og:type is not specified correctly.

PS: remember that a CDN or serverside cache will serve to Facebook's scraper even if you "think" you can see the most recent version. (I wont spend any time on this other than to point out it will waste colossal amounts of your time if not double checked.)

I had a different, but similar problem with 11 Facebook recently, and found that the scraper/debug 10 page mentioned, simply does not appear to 9 read any page in its entirety. My meta 8 properties for Open Graph were further down 7 in the head section, and the scraper would 6 constantly inform me that the image specification 5 was not correct, and would use a cached 4 version regardless. I moved the Open Graph 3 tags further up in the code, near the very 2 top of the page, and then everything worked 1 perfectly, every time.

I had the same problem with fb and twitter 6 caching old meta data, this threw me for 5 a curve as I continued to edit the code 4 but no change. I finally discovered they 3 had caching my first request. Adding a query 2 string to the url worked for twitter but 1 not fb(for me).