This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
Facebook share url thumbnail problem
How to clear Facebook Sharer cache?
I placed a Facebook Like button on my website about 7 days ago. It seemed to work fine; except several days later I noticed that it was giving out the wrong meta data in the Facebook message that is sent. The Title, the Description and the Canonical URL were all wrong. Mea Culpa. It was my fault. I had cloned an old page to save time, had changed the content but had forgotten to change the Meta data at the top. Easy to fix, right. Edit the html page. WRONG. Made no difference. Deleted the Like button code, and re-created a new Like button on the Facebook Developers website and pasted the new code. Made no difference. The button still shows the Meta data from the first button.Tried different variations of button code. Made no difference whatever. It seems the original data has been cached in the Facebook database, and cannot be changed.
Any help somebody?
Load the URL in the Facebook debugger. That might flush the cache.
You should probably try changing URL with a query string in the end.
Also, URL Linter provides you an insight on how FB is going to read your like Meta Tags.
it is always a good practice to check your like page URL here and see what all Meta Tags FB is picking up ..
http://developers.facebook.com/tools/debug
Related
I've got a site that has multiple share buttons on entries in a WordPress site.
We designed this so there are no individual entries to view, they're Podcasts and videos. The listing page has a minimum of 10 entries, each with share buttons.
Currently the share links and titles are working correctly. But the page is not recognizing the og:image, and instead is picking up the default logo for the site itself.
I read another post on Stack Overflow that said it might be an issue for LinkedIn if the image is utilizing SSL for the link. But I just find that hard to believe.
The other issue I'm struggling with, the docs say once an image is scraped it stays cached for approximately 7 days.
I had an issue with FaceBook and there's a debugger that allows you to rescrape the page which let's me verify my changes worked.
My two questions are, is there something other than the og:image i should be specifying? since I can't specify it per post, it's in the head of the page itself, i would think it would pick that up. No?
Second, is there a way a developer can re-check after the meta info has been changed to see if the changes worked, without having to wait the TTL on the cache?
try this:
url/link?blah=1
url/link?blah=2
url/link?blah=3
to get around the cache.
This should trick it into thinking its a new page each time.
Can i get a link to test?
Anthony Walz posted the correct answer. Through email he also helped another problem i had which corrected a new issue i didn't realize I had until i looked.
my LinkedIn shares were not picking up the show title, they were picking up the page description instead (i have several podcasts showing on one page, we don't use individual post pages, they all play from the listing.)
he pointed me to the developer docs on formatting sharing links
Which gives a real world example - here:
https://www.linkedin.com/shareArticle?mini=true&url=http://developer.linkedin.com&title=LinkedIn%20Developer%20Network
&summary=My%20favorite%20developer%20program&source=LinkedIn
Thanks a ton for assist Anthony!
I have my blog (wordpress) web site hosted at bluehost.com. A few months ago I decided to enable Cloudflare (through CPanel).
It's all working well (and I am seeing better overall performance etc) BUT I have a small issue I am dealing with.
I posted this blog some 10 days ago: http://it20.info/2016/01/why-docker-containers-and-docker-oss-docker-inc/
A few days later I had to change picture #2 (of 3) to tweak it a bit. The old picture says "Unikernel" in the red rectangle and the new picture (I uploaded) says "Unikernel/vm".
Note that inside the blog post I make an external reference to the picture (in the html code):
http://www.it20.info/misc/pictures/WhyDocker-ContainersAndDockerOSS-DockerInc2.jpg
If you point STRAIGHT to the picture you will see the new version (so I know I have updated it properly).
However the blog post still shows the old picture (as if Cloudflare is caching it indefinitely).
If in the blog post I right click on the image and do a "view image" (Firefox) it points to: http://i0.wp.com/www.it20.info/misc/pictures/WhyDocker-ContainersAndDockerOSS-DockerInc2.jpg?resize=640%2C392
(which shows the OLD image).
Funny enough if I remove the "?resize=640%2C392" it shows the proper picture.
I am trying to figure out a proper procedure to 1) write a blog post that refers to pictures as external links 2) possibly update said picture via an FTP upload and 3) have Cloudflare render the updated picture.
Thanks.
The root of your problem could be that query string after the image URL:
?resize=640%2C392
In CloudFlare, go to the caching settings and check if your current caching level is standard. If yes try changing to either no query string or ignore query string.
As far as a proper proceedure for future posts where images could change, as an alternative to purging all your site files in CloudFlare, or selectively purging just the image file in question, woudl it be feasible for you to simply change the name of the updated image file, or keep the same name but upload it to a different directory? And of course update the image src in your HTML as well.
Good luck
The past week, Facebook has been getting every article feature image wrong on my site. The og:image is clearly defined, worked fine for the past few months and even the debugger shows the correct image, yet it chooses to use the same incorrect image across all new articles now.
Article
http://www.highwaysindustry.com/causeway-creating-a-competitive-edge/
Facebook Debugger:
https://developers.facebook.com/tools/debug/og/object/
URL: http://www.highwaysindustry.com/causeway-creating-a-competitive-edge/
The meta tag, which clearly provides/defines the correct image Facebook should be using:
<meta property="og:image" content="http://www.highwaysindustry.com/wp-content/uploads/2015/05/Causeway-image-1.jpg" />
When on the debugger, if you Fetch New Scrape Information it will fix the issue. However I am currently having to do this on every single article that is posted. Why it's getting the wrong image in the first place I don't know.
In case someone runs the 'fetch new scrape information', here it is at the moment for that URL provided:
https://www.dropbox.com/s/8t4o9h3o1p9uxhv/debugger-fb.png?dl=0
I am using WordPress and Yoast SEO.
There's a warning. And it's going to take some time to update the latest information but for now you might have to fetch new scrape information yourself.
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://www.highwaysindustry.com/wp-content/uploads/2015/02/Dorman00001-e1423681471392.jpg' will be used instead.
My problem is that I was using a "Like button" plugin on wordpress and I didn't liked the looks of it. I deactivated the plugin and then tried with manual code of XFBML button. That screwed the count to some of the posts, having their counts all in one. I reverted the changes, using the plugin again, deleted the code added and the problem persists. Some of the posts have the "shared" count box. And when you "Like!" any of that posts, only the last one appears on Facebook.
It's it possible that this is a caché issue or something that is wrong in the code?
I tried reverting the meta tag "og:type" from "blog" to "website" but it didn't allowed me, can this be the problem?
Why do some of the posts share that countbox if the links are not the same?
And the wierdest thing, why only some of the posts have the issue while some are shared correctly?
As for an example, say post 1, 5 and 7 share the same countbox (+200). When you "like!" any of them, only the last of them (the most recent) gets to the FB wall.
This doesn't happen with the new posts, only with part of the old ones.
If the case, you can see it working: http://elrincondelacritica.com/
Thanks in advance.
By the way, if you need any piece of code just ask, this is not my page and I really need to fix this asap, also because it's online and running.
Thank you.
The FB debug tool shows that you didn't supply the fb:app_id > which seems to be crucial to render the news feed.
See: https://developers.facebook.com/tools/debug/og/object?q=http%3A%2F%2Felrincondelacritica.com%2F
You can create a Facebook App here: http://developers.facebook.com/apps
Once you've done that you can add the fb:app_id by adding this into your header:
<meta property="fb:app_id" content="000yourAPID000"/>
Thanks mate for the share. Next time I make a website I'll make sure to create an APP too.
And by the way, the error was because of the meta tag og:type changed from website to article. What I did was to leave it to article (not trying to change it "forcing" og:type - website) and placing each "bad" post in the FB Debugger. There were 30 or so... but it worked, and now the new posts work too, with zero count from the start and incrementing correctly, each in particular.
First off, I saw similar posts already, but they weren't exactly what I am asking.
I used the Facebook Dev to create a like button for my website, stuck the code in and the the button showed up. The only issue is that it likes the wrong url when I click the button.
I'm pretty sure the issue is that I have it set to redirect automatically from mydomain.com to the most recent post. I think this is gumming up the works with the like button and causing it to like mydomain.com/mostrecentpost instead of simply liking mydomain.com.
Is there a way to correct this issue without having to get rid of the redirect (because that isn't an option)?
Sorry if that was a little wordy, wanted to make sure I explained the issue fully.
Is there a way to correct this issue without having to get rid of the redirect (because that isn't an option)?
Either don’t redirect in those cases where the user agent header of the request points to it being Facebook’s scraper;
or set the canonical URL of http://example.com/mostrecentpost to just http://example.com/ using the appropriate Open Graph meta tag. (Although that would mean you would not be able to like a single post any more, because all of your posts would just point to your base domain as the “real” website; so the first is probably the better option.)