Since recently switching a website from http to https the News section on the website "which has a Facebook "Share" button" has lost all the counts for that URL.
I have tried the following:
Add og:url tag on the HEAD section of the website <meta property="og:url" content="http://www.example.com" />
Modifying the Facebook code to count http likes
Using the Facebook Developers sharing debugger - The client put the old URL it used to be before the switch and scraped the http version but there was no change to the share counter
Use 301 Redirect on web page for HTTP to HTTPS - anybody trying to go to a http URL is redirected to the new URL on https
Any help would be greatly appreciated.
Related
Can you please help me debug this! Whenever we are sharing content links from our website in facebook; its not working. Redirection to content works if I'm using desktop browser or directly opening the link in mobile browser. But from facebook in app browser I can see either its loading 404 page or the video doesn't play. What could be the reason behind this? Please check below link from here
Either redirect from http to https in general or change the og:image to https instead of http. If you enter the URL into the browser, you get redirected: http://www.bioscopelive.com/bundles/bongoweb/images/oglogo.jpg
You can also add og:image:secure_url as metatag with the https URL of the image.
Make sure that everything is public and not locked by gelocation or login. Facebook servers need to be able to reach the URLs.
Scenario of the problem:
We enforced HTTPS on a website. Any URL with HTTP now redirects (301 permanent redirect) to an appropriate HTTPS URL.
To avoid Facebook like/share buttons (that are placed on many pages of the website) loosing previous numbers of likes/shares, we made the buttons to "link" to the old HTTP URLs via the "data-href" property.
Additionally we placed the "og:url" meta tag on some pages, pointing to the old HTTP URLs.
I then scraped that pages at the Facebook debugger tool https://developers.facebook.com/tools/debug to make sure the Facebook gets the fresh data. According to the scraped data, canonical URLs were indeed pointing to the old HTTP URLs just as it should be according to our actions listed above. This was also reflected in the like/share buttons on our pages keeping the old numbers.
A few days later I discovered that some pages lose the old numbers of likes/shares. Checking the pages in the Facebook debugger shows that Facebook now takes HTTPS URLs as canonical. We did not make any changes on our pages, and the "og:url" tag is still pointing to the HTTP URLs. But the Facebook wrongly takes HTTPS URLs as canonical URLs. Now if I scrape the information again in the debugger, it agains becomes normal, showing HTTP as canonical and restoring the old number of likes/shares. But obviously it's not a solution to the problem, because we cannot constantly monitor all our pages and scrape them again and again.
Any ideas of what may causing the problem?
Facebook follows HTTP redirects as well. You need to make your old HTTP URLs available to the scraper, without redirecting it to the HTTPS version. (The scraper can be recognized by its User-Agent, see social plugins FAQ.)
The old HTTP URLs need to be available to the scraper, and not redirected to HTTPS, as the FAQ also mentions:
“This also requires that the old URL still renders a document with Open Graph tags and returns a HTTP 200 response, at least when loaded by Facebook's crawler. If you want other clients to redirect when they visit the URL, you must send your 301 HTTP response to all non-Facebook crawler clients. The old URL should contain its own og:url tag that points to itself.”
I had about 30000 likes for my page and decided to move it to HTTPS, made 301 redirection from HTTP to HTTPS and found out that all Likes are lost. Switched back to HTTP but still can't get back Likes.
Facebook API show the same Likes count for both URL
Old url https://graph.facebook.com/http://www.freepdfconvert.com
and
New https url https://graph.facebook.com/https://www.freepdfconvert.com
Maybe someone knows how to get Likes back?
The only thing you can do is use the http URL in the og:url tag and redirect to https with .htaccess.
More information can be found in this thread (and others): Switching from HTTP to HTTPS, lost all Facebook "Likes"
I have a single page angularjs web app. I'm trying enable it to be crawlable by search engines. To achieve this I'm using prerender.io, a nodejs webserver with a phantomjs browser to render ajax pages.
I am basing my nginx config off the following gist: https://gist.github.com/Stanback/6998085
This works for the most part. I can curl my app and get the correct response: curl -o test.html domain.com/?_escaped_fragment=/path
The request is redirected to the prerender.io proxy and the proxy makes a single request with the following url: domain.com/#!/path
All other requests (js, img, css and xhr) pass through nginx as normal. Phantomjs has no trouble rendering the proxy request after waiting for the following JS variable to be set to true: window.prerenderReady = false;
This is all great... Google can crawl my website! Enter Facebook.
I'm setting a number of OG metatags so that I can use the Facebook like button (iFrame). The following metatags are set for each page:
<link rel="canonical" href="http://domain.com/#!/asset">
<meta property="og:url" content="http://domain.com/#!/asset">
<meta property="og:type" content="website">
<meta property="og:image" content="http://domain.com/image.jpg">
<meta property="fb:app_id" content="xxx">
<meta property="og:description" content="foo">
<meta property="og:title" content="bar">
<meta property="og:site_name" content="domain.com">
These metatags are updated correctly by angularjs for each asset and the phantomyjs proxy correctly waits for them to be updated before returning the response.
However when I test the URL http://domain.com/#!/asset with the Facebook URL linter I get some problems.
Facebook claims that the canonical URL and the og:url differ, however when I click "See exactly what our scraper sees for your URL" they are idential
When I click "See exactly what our scraper sees for your URL" the canonical and og:url have been replaced with domain.com/?fb_locale=en_GB#!/asset
The proxy receives 3 requests. The first for the asset then it seems it follows the canonical and og:url
When a user clicks the Like this page iFrame the link back to my website looks like domain.com/?_escaped_fragment_=/asset
Number 4 is the issue that is a deal breaker. If a user likes a page on my post it goes into their Facebook activity stream. If that user then clicks on the link back to my site in their stream it will direct them through the proxy and render the page through phantomjs!
I'm guessing that I shouldn't be sharing the links with the hash-bang through Facebook. I think I should be sharing a link and setting the canonical / og:url to something like domain.com/static/asset. The nginx config should be updated to catch /static urls, if useragent = Facebook or params contain _escaped_fragment_ then direct to proxy else redirect the user to #!/asset.
I have tired all that I can think to get a modified nginx config to work with this however it has beaten me. When I intercept those /static urls and rewrite to the proxy randomly image, css and js assets are requested through the proxy and phantomjs crashes.
Could someone please help me modify this nginx config so that I can forward web crawler requests to the proxy, allow facebook to scrape the correct og tags off my site AND have the correct link-back url specified when users share my content on Facebook?
Did you figure this out yet? Facebook doesn't do a very good job with #! urls. This StackOverflow answer does a good job explaining it: How to handle facebook sharing/like with hashbang urls?
When a user is on a page on your site (http://domain.com/#!/asset) and does a sharing action on your website, it should share the canonical url http://domain.com/asset.
Then if a user visits http://domain.com/asset, you just redirect them to http://domain.com/#!/asset.
And if Facebook accesses the canonical URL (http://domain.com/asset), then redirect it to your Prerender.io server.
Or...just switch from #! to html5 pushstate, and you won't have to do any of the #! redirecting for Facebook. That way the proxy becomes more simple, so you'd always just proxy any request from Facebook to your Prerender.io server
When I enter my page URL http://korydor.in.ua/reviews/1507-vzyat-na-karandash to https://developers.facebook.com/tools/debug/ I can see that Canonical URL is pointing to some random ya.ru domain.
How to get in touch with Facebook dev team to fix that ?
This page has relevant metadata information, it is not a case of the problem
meta property="og:url" content="http://korydor.in.ua/reviews/1507-vzyat-na-karandash"
Further down that same page it explains why this is happening, screenshot attached
Your site is redirecting Facebook's crawler - you need to stop redirecting the crawler if you want the metadata for that URL instead of the after-redirect URL