Related
Please note that I am far from being proficient in HTML so I might be doing something silly. Also I am posting this question because although I found other questions about the same topic, none of them addressed the exact problem I am having. Thanks.
I am trying to use the Open Graph properties in the meta-data of my blog to control which image facebook shows, but facebook claims that there is a problem with my image.
Here is the metadata I have added inside the <header/> tag:
<meta property="og:type" content="article" />
<meta property="og:title" content="Salud, cuerpo, mente y dieta" />
<meta property="og:description" content="Que tu alimento sea tu medicina y la medicina tu alimento - Aristóteles de Cos" />
<meta content='http://3.bp.blogspot.com/-9eH_b6ILSic/VwneIrX1hZI/AAAAAAAAUR4/8t-krO2wqzAT90Rrv3PQ-rwB1E09IVt3g/s1600-r/salud_cuerpo_mente_dieta_612x327.PNG' property='og:image'/>
When I use facebook's Open Graph Object Debugger and point it to my blog (saludcuerpodieta.blogspot.ca), this is the problem I find:
og:image could not be downloaded or is too small
og:image was not defined, could not be downloaded or was not big enough. Please define a chosen image using the og:image metatag, and use an image that's at least 200x200px and is accessible from Facebook. Image 'http://poweredbygreensmoothies.com/wp-content/uploads/2014/01/green-smoothie-jars-1.jpg' will be used instead. Consult http://developers.facebook.com/docs/sharing/webmasters/crawler for more troubleshooting tips.
I read several things, including facebook's guidelines and best practices, where they say that the image has to be bigger than 600x315. Mine is 612x327, so it should work.
I have found that if I replace the image I want with the image facebook falls back to, things work as expected. That image is 2034x1296. Now, the problem with making my image that big, is that it is the header of my blog and it would not look good having the image that big (in fact, I would like the image to be even smaller than 600x315, but I made it bigger because of the troubleshooting tips I read).
Can you help me, please? What I am doing wrong?
Thanks!
If Facebook tried to reach the image URL and it was invalid, unreachable, etc, the URL is cached as being an invalid image -
Try changing the filename if you're sure the image you're trying to use is reachable and valid (e.g. add a cache busting parameter to the og:image value or rename the file)
I'm making a Facebook sharer with FB UI. I have og tag:
<meta property="og:image" content="https://www.mydomain.fi/img/fb-share-img.jpg" />
The image is 1200 × 627. The og debugger doesn't give any errors. However, when sharing the link, share image appears to be small square instead of full width image.
What might cause this?
The weird thing is that earlier og was fetching the data right and showed the photo bigger. I had to debug something and fetch the site again and now I can't get the big image back.
I, too, had all the right og: tags and a large share image. When sharing the url directly, I got a large image. When sharing from the Facebook JS SDK, it started out as large, then suddenly got small. As others have pointed out, this is almost a random selection based on FB algorithms. Having spent many hours fighting with tags and the debug tool, I accidentally stumbled upon a hack (use at own risk):
Without knowing it, I copy-pasted an og:type tag from another website which contained an invalid character (in my case the quotation marks were "printer's quotes")
meta property="og:type" content=”website”
(see the difference between the quotes around "og:type" and "website"?)
To my stunned disbelief, while this caused on error in the debug tool ("Object at URL '[myurl]' is invalid because the configured 'og:type' of '”website”/' is invalid.") it actually forced the large image to be used, and all other meta data was fine.
I have no idea how or why, so don't ask. But it worked. All the time. And I hope this helps some other developers out there until we can be assured of the correct size image being shown. As I said, your mileage may vary, and don't blame me if you break it :)
Say if you have set the facebook image for your webpage via the meta tag of the open graph protocol like this:
<meta property="og:image" content="http://ia.media-imdb.com/rock.jpg"/>
If you want to replace/update the image with another image of the same name rock.jpg, how do you get facebook to update your image accordingly with the new image when you share the page? Forcing facebook to fetch your page's data with this link http://developers.facebook.com/tools/debug won't update the image.
this is the most consistent answer I've found to this problem: https://stackoverflow.com/a/21468084/339698
If you're too lazy to go to that link, you can POST an ajax request with the url you are trying to clear:
$.post(
'https://graph.facebook.com',
{
id: 'http://www.site.com/my/share/url/',
scrape: true
},
function(response){
console.log(response);
}
);
Facebook stores your image into their own image on their servers, and then caches it for 24h. The cache delay might change in the future, so to check it just open the image that facebook creates from your image and check its "max-age" value in the http headers. So if you change your image, facebook will not update its version until 24h even if you use this link http://developers.facebook.com/tools/debug to force the data fetching.
To solve this, if you need to see the effect of your change right away you should rename your image. So if the old version was rock.jpg name it rock2.jpg then use this link http://developers.facebook.com/tools/debug to get facebook to create a new image from your updated image. This will update immediately your webpage's facebook image in the facebook share.
Years later after this post was made and this is still a problem, but its not facebook's cache: It is quite often human error (allow me to elaborate)
OG:TYPE effects your image scrape:
https://ogp.me/#type_article not the same as https://ogp.me/#type_website
Be aware that og:type=website will cause any /sub-pages/ of that url to become "canonical". This means you will have trouble getting your images to update using the scraper no matter 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 /child-2/ will inherit the og:image of the parent
Those are not "all websites", 1 is a website, the others are articles.
If you do that Facebook will think all of those are canonical and it will put the FIRST og:image into all of them. (try it, you'll see) - if you set the og:url to be your root or parent domain you've told facebook they are all canonical. (there is good reason for that, but its off topic)
Consider this solution (which 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 that now Facebook will give you far far less problems with scraping your NEW images.
In closing, YES the cache busters, random vars, changing urls and suggestions here can work, but they will seem like "intermittent voodoo" if the 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.)
if you are using any cache plugin, make sure you clear all your caches. Also make sure the image you are using has the recommended facebook size: 1200(w) x 630(h) or 600 x 315.
I'm having troubles with my meta tags with Open Graph. It seems as though Facebook is caching old values of my meta tags. Old values for Attributes og:title and og:url are still used, even though I have changed them already.
I ran Lint on a page in my site, and this appeared:
Notice that there are two values for og:title and og:url, and the last one prevailed. However, The last two entries are the OLD entries that I used for this site. I am now currently using these meta tags (you can verify if you view the source of the HTML):
<meta property="og:title" content="Smart og rummelig pusletaske fra Petit Amour med god plads til alt – værdi 1.099 kr – køb nu kun 599 kr "/>
<meta property="og:description" content="Pinq.dk - Det gode liv for det halve"/>
<meta property="og:type" content="product"/>
<meta property="og:url" content="http://pinq.dk/tilbud/landsdaekkende/lissy/"/>
<meta property="og:image" content="http://pinq.dk/wp-content/themes/pinq/images/logo-top.png"/>
<meta property="og:site_name" content="Pinq" />
<meta property="fb:app_id" content="161840830532004" />
Why is Facebook caching og:title and og:url? Is anyone experiencing the same issue?
Go to http://developers.facebook.com/tools/debug
Enter the URL following by fbrefresh=CAN_BE_ANYTHING
Examples:
http://www.example.com?fbrefresh=CAN_BE_ANYTHING
http://www.example.com?postid=1234&fbrefresh=CAN_BE_ANYTHING
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 I got this solution from some website.
Facebook saves your cache thumbnail. It won't refresh even if you delete the thumnail/image from your server. But Facebook allows you to refresh by using fbrefresh.
The most voted question is quite outdated:
These are the only 2 options that should be used as of November 2014:
For non developers
Use the FB Debugger: https://developers.facebook.com/tools/debug/og/object
Paste the url you want to recache. (Make sure you use the same url included on your og:url tag)
Click the Fetch Scrape information again Button
For Developers
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)
Make sure the og:url tag included on the head on that page matches with the one you are passing.
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 refresh them manually - you can do it automatically.
Lets 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 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 Facebook cache. If you use the jQuery solution, have a look at "response" in console.log - you will find there "updated_time" field and other useful information.
The OG thumbnail does not seem to refresh even if passing the fbrefresh variable.
To update this without waiting for automated clearing you'll need to change the filename of the thumbnail associated meta tag value and refresh.
Basically, the answer is patience ;)
I checked the Linter this morning, and og:title and og:url displays correctly, without the redundant values. I guess FaceBook automatically clears its cache at some specific interval. I just have to wait.
I had the same issues using og:image, several attempts to rename the file or clear FB cache did not work either via the facebook debugger or testing via an actual account.
The new facebook guidelines state the image size should be 1200 x 630 or having that aspect ratio, this seems to be wrong, the only thing that worked for me was using an image with square dimensions.
Edit* Afew hours I went back to use 1200 x 630 and it magically worked, it was magical.
I also renamed the files to f*^*kfacebook.jpg, not sure it helped but it felt good.
Yes, facebook automatically clears the cache every 24 hours: Actually facebook scrapes the pages and updates the cache every 24 hours https://developers.facebook.com/docs/reference/plugins/like/#scraperinfo.
Ooook, finally it helped (I use IP.Board). What I had to do was:
Change url of og:image on my website (General configuration).
Try this method with ?fbrefresh=1154464gd56
Thanks to author for this thread!
EDIT: What is more you need to remember about image requirements. For now (january 2013) it's:
- at least 200 px in both directions
- maximum ratio 3:1
Visit the FB page https://developers.facebook.com/tools/debug/og/object/
Enter your domain.
Click the button "Fetch new scrape information"
Done
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 are things that have been reported to work by others but I have had ZERO success with 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 a spot on way to confirm it is not an issue with browser cache or some caching service. If the meta information is up to date in your code and you've tried all of the above (unless another suggestion comes to fruition), the correct answer is you can do nothing but wait.
We just ran into this, as it turns out, we weren't linting the right url, since the real url had a query string (duh, different page as far as a bot is concerned).
http://example.com/
!==
http://example.com/?utm_campaign=foo
The linter will recache your page, you don't have to wait.
One thing to add, the url is case sensitive. Note that:
apps.facebook.com/HELLO
is different in the linter's eyes then
apps.facebook.com/hello
Be sure to use the exact site url that was entered in the developer settings for the app. The linter will return the properties otherwise but will not refresh the cache.
I've found out that if your image is 72dpi it will give you the image size error. Use 96dpi instead. Hope this helps.
Go to http://developers.facebook.com/tools/debug
Paste in the url of the page and click debug. If your site is using url aliases make sure you are using the same url as Facebook
is using for the page you are sharing (example: in Drupal use the
node/* path instead of the alias if the page is shared via that
url).
Click in the "Share preview" part on "See this in the share dialog" link
Facebook Developer Documents says title property has exception:
Once 50 actions (likes, shares and comments) have been associated with
an object, you won't be able to update its title
https://developers.facebook.com/docs/sharing/opengraph/using-objects#update
Had a similar experience. Website link was showing a 404 in the preview that facebook generated. Turns out the og:url metadata was wrong. We had already fixed it a few days back but were still seeing a 404 on the preview. We used the tool at https://developers.facebook.com/tools/debug/ and that forced the refresh (didn't have to append any parameters by the way)
In our case, Facebook didn't refresh the cache after 24 hours but the tool helped force it.
It is a cache, ofc it refreshes, that's what cache is ment to do once in a while. So waiting will eventually work but sometimes you need to do that faster. Changing the filename works.
I was having this issue too. The scraper shows the right information, but the share url was still populated with old data.
The way I got around this was to use the feed method, instead of share, and then populate the data manually (which isn't exposed with 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 just need to generate a new url when you update your meta tags. It's as simple as adding a "&cacheBuster=1" to your url. If you change the meta tags, just increment 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 each like a new url and get fresh meta data.
Years later and this is still a common problem, but its not always facebook's cache: It is very often human error (allow me to elaborate)
OG:TYPE effects your image scrape:
https://ogp.me/#type_article not the same as https://ogp.me/#type_website
Be aware that og:type=website will cause any /sub-pages/ of that url to become "canonical". This means you will have trouble getting your images to update using the scraper no matter 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 /child-2/ will inherit the og:image of the parent
Those are not "all websites", 1 is a website, the others are articles.
If you do that Facebook will think all of those are canonical and it will put the FIRST og:image into all of them. (try it, you'll see) - if you set the og:url to be your root or parent domain you've told facebook they are all canonical. (there is good reason for that, but its off topic)
Consider this solution (which 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 that now Facebook will give you far far less problems with scraping your NEW images.
In closing, YES the cache busters, random vars, changing urls and suggestions here can work, but they will seem like "intermittent voodoo" if the 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 Facebook recently, and found that the scraper/debug page mentioned, simply does not appear to read any page in its entirety. My meta properties for Open Graph were further down in the head section, and the scraper would constantly inform me that the image specification was not correct, and would use a cached version regardless. I moved the Open Graph tags further up in the code, near the very top of the page, and then everything worked perfectly, every time.
I had the same problem with fb and twitter caching old meta data, this threw me for a curve as I continued to edit the code but no change. I finally discovered they had caching my first request. Adding a query string to the url worked for twitter but not fb(for me).
Facebook cannot grasp my og:image files and I have tried every usual solution. I'm beginning to think it might have something to do with https://...
I have checked http://developers.facebook.com/tools/debug and have zero warnings or errors.
It is finding the images we linked to in the "og:image", but they're showing up blank. When we click the image(s), however, they DO exist and it takes is straight to them.
It DOES show one image -- an image hosted on a non-https server.
We've tried square images, jpegs, pngs, larger sizes and smaller sizes. We've put the images right in public_html. Zero are showing up.
It's not a caching error, because when we add another og:image to the meta, FB's linter does find and read that. It DOES show a preview. The preview is blank. The only exception we're getting is for images that are not on this website.
We thought maybe there was some anti-leach on cpanel or the .htaccess that was preventing the images from showing up, so we checked. There was not. We even did a quick < img src="[remote file]" > on an entirely different server and the image shows up fine.
We thought maybe it was the og:type or another oddity with another meta tag. We removed all of them, one at a time and checked it. No change. Just warnings.
The same code on a different website shows up without any issue.
We thought maybe it was not pulling images because we're using the same product page(s) for multiple products (changing it based on the get value, ie, "details.php?id=xxx") but it's still pulling in one image (from a different url).
Leaving any og:image or image_src off, FB does not find any images.
I am at the end of my rope. If I said how much time myself and others have spent on this, you'd be shocked. The issue is that this is an online store. We absolutely, positively cannot NOT have images. We have to. We have ten or so other sites... This is the only one with og:image problems. It's also the only one on https, so we thought maybe that was the problem. But we can't find any precedent anywhere on the web for that.
These are the meta-tags:
<meta property="og:title" content="[The product name]" />
<meta property="og:description" content="[the product description]" />
<meta property="og:image" content="https://www.[ourwebsite].com/images/shirts/overdriven-blues-music-tshirt-details-black.png" />
<meta property="og:image" content="https://www.[ourwebsite].com/images/shirts/overdriven-blues-music-tshirt-art-black.png" />
<meta property="og:image" content="http://www.[ADIFFERENTwebsite].com/wp-content/uploads/2011/06/ARS-Header-Shine2.png" />
<meta property="og:image" content="https://www.[ourwebsite].com/images/ARShopHeader.png" />
<meta property="og:image" content="http://www.[ourwebsite].com/overdriven-blues-music-tshirt-art-black.JPG" />
<meta property="og:type" content="product"/>
<meta property="og:url" content="https://www.[ourwebsite].com/apparel-details.php?i=10047" />
<meta property="og:site_name" content="[our site name]" />
<meta property="fb:admins" content="[FB-USER-ID-NUMBER]"/>
<meta name="title" content="[The product name]" />
<meta name="description" content="[The product description]" />
<link rel="image_src" href="https://www.[ourwebsite].com/images/shirts/overdriven-blues-music-tshirt-details-black.png" />
<meta name="keywords" content="[four typical keywords]">
<meta name="robots" content="noarchive">
In case you want it, here's a link to one of our product pages that we've been working on. [Link shortened to try to curb this getting into search results for our site]: http://rockn.ro/114
EDIT ----
Using the "see what facebook sees" scraper tool, we were able to see the following:
"image": [
{
"url": "https://www.[httpSwebsite].com/images/shirts/soul-man-soul-music-tshirt-details-safari.png"
},
{
"url": "https://www.[httpSwebsite].com/images/shirts/soul-man-soul-music-tshirt-art-safari.png"
},
{
"url": "http://www.[theotherNONSECUREwebsite].com/wp-content/uploads/2011/06/ARS-Header-Shine2.png"
}
],
We tested all links it found for a single page. All were perfectly valid images.
EDIT 2 ----
We tried a test and added a subdomain to the NONSECURE website (from which images are actually visible through facebook). Subdomain was http://img.[nonsecuresite].com. We then put all images into the main subdomain folder and referenced those. It would not pull those images into FB. However, it would still pull any images that were referenced on the nonsecure main domain.
POSTED WORKAROUND ----
Thanks to Keegan, we now know that this is a bug in Facebook. To workaround, we placed a subdomain in a different NON-HTTPS website and dumped all images in it. We referenced the coordinating http://img.otherdomain.com/[like-image.jpg] image in og:image on each product page. We then had to go through FB Linter and run EVERY link to refresh the OG data. This worked, but the solution is a band-aid workaround, and if the https issue is fixed and we go back to using the natural https domain, FB will have cached the images from a different website, complicating matters. Hopefully this information helps to save someone else from losing 32 coding hours of their life.
Some properties can have extra metadata attached to them. These are specified in the same way as other metadata with property and content, but the property will have extra :
The og:image property has some optional structured properties:
og:image:url - Identical to og:image.
og:image:secure_url - An
alternate url to use if the webpage requires HTTPS.
og:image:type - A
MIME type for this image.
og:image:width - The number of pixels wide.
og:image:height - The number of pixels high.
A full image example:
<meta property="og:image" content="http://example.com/ogp.jpg" />
<meta property="og:image:secure_url" content="https://secure.example.com/ogp.jpg" />
<meta property="og:image:type" content="image/jpeg" />
<meta property="og:image:width" content="400" />
<meta property="og:image:height" content="300" />
So you need to change og:image property for your HTTPS URLs to og:image:secure_url
Ex:
HTTPS META TAG FOR IMAGE:
<meta property="og:image:secure_url" content="https://www.[YOUR SITE].com/images/shirts/overdriven-blues-music-tshirt-details-black.png" />
HTTP META TAG FOR IMAGE:
<meta property="og:image" content="http://www.[YOUR SITE].com/images/shirts/overdriven-blues-music-tshirt-details-black.png" />
Source: http://ogp.me/#structured <-- You can visit this site for more information.
EDIT: Don't forget to ping facebook servers after updating your code - URL Linter
I ran into the same problem and reported it as a bug on the Facebook developer site. It seems pretty clear that og:image URIs using HTTP work just fine and URIs using HTTPS do not. They have now acknowledged that they are "looking into this."
Update: As of 2020, the bug is no longer visible in Facebook's ticket system. They never responded and I don't believe this behavior has changed. However, specifying HTTPS URI in og:image:secure does seem to be working fine.
I don't know, if it's only with me but for me og:image does not work and it picks my site logo, even though facebook debugger shows the correct image.
But changing og:image to og:image:url worked for me. Hope this helps anybody else facing similar issue.
tl;dr – be patient
I ended up here because I was seeing blank images served from a https site. The problem was quite a different one though:
When content is shared for the first time, the Facebook crawler will scrape and cache the metadata from the URL shared. The crawler has to see an image at least once before it can be rendered. This means that the first person who shares a piece of content won't see a rendered image
[https://developers.facebook.com/docs/sharing/best-practices/#precaching]
While testing, it took facebook around 10 minutes to finally show the rendered image. So while I was scratching my head and throwing random og tags at facebook (and suspecting the https problem mentioned here), all I had to do was wait.
As this might really stop people from sharing your links for the first time, FB suggests two ways to circumvent this behavior:
a) running the OG Debugger on all your links: the image will be cached and ready for sharing after ~10 minutes or b) specifying og:image:width and og:image:height. (Read more in the above link)
Still wondering though what takes them so long ...
Got here from Google but this wasn't much help for me. It turned out that there is a minimum aspect ratio of 3:1 required for the logo. Mine was almost 4:1. I used Gimp to crop it to exactly 3:1 and voila - my logo is now shown on FB.
I had similar problems. I removed the property="og:image:secure_url" and now it will scrub with just og:image. Sometimes, less is more
I had the same error and nothing of previous have helped, so I tried to follow original documentation of Open Graph Protocol and I added prefix attribute to my html tag and everything became awesome.
<html prefix="og: http://ogp.me/ns#">
As I accidentally found, transparent blank image comes with response header indicating possible cause of the problem.
Go to the debugger at https://developers.facebook.com/tools/debug/og/object/
Put your URL
In the bottom, facebook shows your "image" (transparent 1x1 GIF)
Image is linked to your original image - no point pressing it
Press right and view image (you'll get something like https://external-ams3-1.xx.fbcdn.net/safe_image.php?d=...&url=...)
Turn on Net tab on firebug/developer tools, refresh page if needed
You'll get x-error-detail response header with explanation
For example, in my case it was Invalid image extension for URL: https://[mydomain]/[myfilename].jpg
The real issue in my case was related to prerender.io.
As it turns out, if image is requested via prerender, it's converted to HTML. Something like this:
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd">
<html>
<head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head>
<body style="margin: 0px;"><img style="-webkit-user-select: none; cursor: -webkit-zoom-in; " src="https://[yourdomain].com/[yourfilename].jpg" width="1078" height="718"></body>
</html>
It's either bug in prerender itself, or it's supposed to be configured in your proxy to not use prerender for *.jpg requests (even if they are requested by Facebook bot).
It's really hard to notice this, as prerender is used only on certain user-agent headers.
In my case the problem was in not providing CA Root Certificate. I figured it out after using: https://www.ssllabs.com/ssltest/analyze.html to analyze SSL configuration.
I took http:// out of my og:image and replaced it with just plain old www. then it started working fine.
You can use this tool, by Facebook to reset your image scrape cache and test what URL it is pulling for the demo image.
I have a Wordpress site that uses og:image with an https URL to the image and the images show up just fine in Facebook preview links.
I have another site I was working on that uses og:image with an https URL and sometimes the images would appear and sometimes they wouldn't. I tried the suggestions on this page, using og:image:url and og:image:secure_url and neither one made any difference, the image wouldn't be used for the preview.
Both sites have valid https certificates, so it wasn't a certificate problem.
After searching some more I found out that Facebook has a MINIMUM SIZE for images. If the og:image is less than 200x200px it will not be used by Facebook. The recommended size is 600x600px for stories and 1200x630px for everything else.
I scaled up the image sizes on my second site and they started appearing on Facebook. Mystery solved.
Hope you find this useful.
I discovered another scenario that can cause this issue. I went through all the steps described in the question and the answers, still the problem remained.
I checked my images and found that some of my posts had way too large thumbnail images in og:image in the range of several thousand pixels and several megabytes.
This happened due to the recent migration from WP to Jekyll, I optimized my images with gulp, but used the original images in og:image by mistake.
Facebook gives us the following recommendations as of today:
Use images that are at least 1200 x 630 pixels for the best display on
high resolution devices. At the minimum, you should use images that
are 600 x 315 pixels to display link page posts with larger images.
Images can be up to 8MB in size.
So there is an upper limit of 8MB.
I ran into the same issue and then I noticed that I had a different domain for the og:url
Once I made sure that the domain was the same for og:url and og:image it worked.
Hope this helps.
Similar symptoms (Facebook et al not correctly fetching og:image and other assets over https) can occur when the site's https certificate is not fully compliant.
Your site's https cert may seem valid (green key in the browser and all), but it will not scrape correctly if it's missing an intermediate or chain certificate. This can lead to many wasted hours checking and rechecking all the various caches and meta tags.
Might not have been your problem, but could be other's with similar symptoms (like mine). There's many ways to check your cert - the one I happened to use: https://www.sslshopper.com/ssl-checker.html
I can see that the Debugger is retrieving 4 og:image tags from your URL.
The first image is the largest and therefore takes longest to load.
Try shrink that first image down or change the order to show a smaller image first.
In addition, this problem also occurs when you add a user generated story (where you do not use og:image). For example:
POST /me/cookbook:eat?
recipe=http://www.example.com/recipes/pizza/&
image[0][url]=http://www.example.com/recipes/pizza/pizza.jpg&
image[0][user_generated]=true&
access_token=VALID_ACCESS_TOKEN
The above will only work with http and not with https. If you use https, you will get an error that says:
Attached image () failed to upload
Don't forget to refresh servers through :
Facebook Debugger
And click on "Collect new info"
Had a similar problem today, which the Sharing Debugger helped me solve. It seems that Facebook can’t (currently) understand images with XMP metadata embedded. When I replaced the images on our articles with versions without XMP metadata, and re-scraped the page (using the Sharing Debugger), the problem went away. A hex editor will help you see whether or not your image contains XMP metadata.
OK... I realize this thread is old and overcrowded, but in case someone comes in like I did struggling to get their og:image tag to work right in Facebook, here's the trick that worked for me:
do NOT use this link:
https://developers.facebook.com/tools/debug/sharing/?q=https%3A%2F%2Fwww.google.com
to work through your problem. Or if you do, immediately scroll down to the bottom and click on Scrape VIA API.
https://developers.facebook.com/tools/explorer/?method=POST&path=%3Fscrape%3Dtrue%26id%3Dhttps%3A%2F%2Fwww.google.com&version=v5.0
There are errors displayed in the explorer tool that are NOT shown in the "debug" tool. Maddening!!! (in my case, a space in the image filename knocked my image out silently in the debug tool, but it showed the error in the explorer tool).
I came across another reason for og images not to display on FB cards. Furthermore, using the FB scraper tool to debug the og meta tags, I could confirm all the required tags where present in my WordPress page, and yet I would get the following file download error,
Provided og:image, < https-link-to-jpg-image > could not be downloaded.
This can happen due to several different reasons such as your server
using unsupported content-encoding. The crawler accepts deflate and gzip content encodings.
I had a vague feeling that the image format had an issue, the link to the image was working but the message seems to indicate something amiss with the content-encoding.
After much searching, I ended up looking at the php extensions that are required for a WordPress server, and realised the pho-exif module was not installed. The exif module writes exif metadata to all uploaded images. As a result the images used in the FB og image tag did not have any exif metadata associated with them.
Once the exif module is enabled, WordPress allows exif metadata to be reset for an image (Media library->select and image->Edit more details->Map exif metadata) and the image now appeared on the FB card as expected.
In my case, it seems that the crawler is just having a bug. I've tried:
Changing links to http only
Removing end white space
Switching back to http completely
Reinstalling the website
Installing a bunch of OG plugins (I use WordPress)
Suspecting the server has a weird misconfiguration that blocks the bots (because all the OG checkers are unable to fetch tags, and other requests to my sites are unstable)
None of these works. This costed me a week. And suddenly out of nowhere it seems to work again.
Here are my research, if someone meets this problem again:
What makes Open Graph checkers unable to detect Open Graph data?
How to know what bots of a website, if I have no root access to the hosting they will read?
👍 What makes Open Graph checkers unable to detect Open Graph data? - Let's Encrypt Community Support
👍 Crawler is unable to fetch images, but adding a brand new, unique query string can make it work for one first time - Facebook for Developers
Also, there are more checkers other than the Facebook's Object Debugger for you to check: OpenGraphCheck.com, Abhinay Rathore's Open Graph Tester, Iframely's Embed Codes, Card Validator | Twitter Developers.
I arrived here because an updated facebook meta tag image wasn't showing on facebook shares.
For anyone else in this predicament, the reason was simply that you need to ask facebook to scrape your site again.
Once you do that, it will appear as expected.
I'm using cloudfront distributions pointing to s3 bucket to serve static images...my cloudfront origins are set to redirect http to https...so maybe that has something to do with it?
regardless...
Updating og:image from https to http resolved the issue for me, images are now being posted to facebook posts with links to my site.
UPDATE: the above behavior continued to happen...anytime I were to change the og:image url, or invalidate my cloudFront cache, the image would work on the FB debugger, but the image would never show up on FB.
I added a new behavior for my og:image endpoint and set min ttl, max ttl, and default ttl to 0. And now everything is working great...not ideal as I'd prefer it to be cached, but apparently FB can't handle the cloudfront 304 response?
I had the same issue and the cause was the minimum TLS version specified in Cloudflare:
If I set minimum TLS to 1.3 - no meta images. If I set it to 1.2 or lower - meta images appear.
It seems that social media previews don't support TLS 1.3, hence the issue. For the record, I have no og:image:secure_url and have HTTP redirected to HTTPS. The site is completely not accessible via HTTP. Only the TLS version was causing trouble.
I struggled to find an answer to this and was getting this puzzling error from LinkedIn:
We encountered an SSL connection error while trying to access the URL.
Please check that the site is using a prime size that is compatible
with Java 8, or contact Support with the content's URL.
The answer was, even though I had both TLSv1.2 and TLSv1.3 enabled in nginx, TLSv1.2 wasn't available due to my cipher list as verified by this checker. It appears facebook and linkedin both use TLSv1.2 to generate previews (as of Nov 2022).
I had to update nginx to the following according to the first answer on this post:
ssl_protocols TLSv1.3 TLSv1.2;
ssl_prefer_server_ciphers on;
ssl_ciphers "EECDH+AESGCM,EDH+AESGCM";
If your image links look like this:
"https://someurl Wed Sep 14 2022 05:59:25 GMT+0000 (Coordinated Universal Time).jpg"
Then make sure that you are using encodeURI function (JavaScript) or any similar function in other languages while setting the URL.
This will help you to create a valid URL which can be understood by og:image.
{
'og:title': "title",
'og:description': "description",
'og:image': encodeURI(image),
'og:image:secure_url': encodeURI(image),
}
From what I observed, I see that when your website is public and even though the image url is https, it just works fine.
For me this worked:
<meta property="og:url" content="http://yoursiteurl" />
<meta property="og:image" content="link_to_first_image_if_you_want" />
<meta property="og:image" content="link_to_second_image_if_you_want" />
<meta property="og:image:type" content="image/jpeg" />
<meta property="og:image:width" content="400" />
<meta property="og:image:height" content="300" />
<meta property="og:title" content="your title" />
<meta property="og:description" content="your text about homepage"/>
After several hours of testing and trying things...
I solved this problem as simple as possible.
I notice that they use "test pages" inside Facebook Developers Page that contains only the "og" tags and some text in the body tag that referals this og tags.
So what have i done?
I created a second view in my application, containing this same things they use.
And how i know is Facebook that is accessing my page so i can change the view? They have a unique User Agent: "facebookexternalhit/1.1"
Once you update the meta tag make sure the content(image) link is absolute path and
go here https://developers.facebook.com/tools/debug/sharing enter you site link and click on scrape again in next page