We use cookies to understand how you use our site and to improve your experience. This includes
personalizing content and advertising.By continuing to use our site, you accept our use of cookies, revised
Privacy Policy and Terms of Use.

How to Recover Your Facebook Shares after Moving from HTTP to HTTPS

Google is pushing for a shift from http to https, there is no secret in this. This strategy would probably be effective anyway, but with Google behind, the shift starts to resemble a done deal. The question is no longer whether sites will follow, but when. After all, who in their right minds would give up geolocation, encrypted media extensions or application cache?

But aside from the technical complications of this move, there are other considerations as well. One such unforeseen side effect is that switching from http to https would cause the loss of the social share counts on Facebook and Google+ pages. To be fair, this disadvantage is not specifically linked to the https switch, but to any URL change in general (which might be why Google has not put forward an official fix for this, so far).

We ourselves faced share counts loss when we migrated our site from http to https. It was a punch in the stomach for us; yet, we had no other chance than finding an efficient method to recover Facebook shares after the previous URLs changed to https. Finding the right solution of getting the Facebook shares back wasn’t an easy ride. But a solution was needed and we are really happy that we found it. As we are your number one fans, we couldn’t keep the fix of getting your shares back for ourselves. Below you will find the exact steps that you need to take if you experience a similar problem and you want your hard-worked social shares displayed on your web pages.

With the cognitive’s reunited superpowers we came across a solution to recover your social shares after moving from HTTP to HTTPS.

Tested Steps to Maintain Your Social Shares after a Site Migration from HTTP to HTTPS

The truth is that moving from HTTP to HTTPS doesn’t come up easily. It can be a real pain, not to mention that if you’re not 100% vigilant, you can suddenly lose your ranks. We’ve written a blog post not long ago on how not to lose your ranks when doing a website redesign. Moving from HTTP to HTTPS is not a walk in the park. Maintaining your shares while doing so can be even harder. And we know that from our own experience.

Long story short, when moving from HTTP to HTTPS you lose all your hard worked social share counts from Facebook and Google+. It is not a pleasant situation at all, especially when you’ve worked so hard for each and every social share. It’s a vanity metric some may say, and that’s true. Yet, it’s a highly important social proof that can give you tons of insight about your overall social media strategy.

For Facebook and Google+ there are two different methods to get your social share counts back when moving from http to https. Along with those, there are a couple of generic changes you need to perform. Below, I am going to list you the generic updates which are common for recovering the social shares for both Facebook and Google + and afterwards some specific actions that you need to take for each social network separately.

Generic Changes to Get Your Social Share Counts Back

1. Create a 301 redirect from HTTP to HTTPS

This is probably the first and the most important step you need to make when migrating your site. What the 301 permanent redirects do is to redirect any visitor, including search engines, to your new version of the site, the one with https. Along with the direct traffic, the age, authority and reputation of your old website in search engines is transferred to the new web address. If you don’t implement 301 redirects correctly, not only will your social shares be forever lost, but also your ranks and traffic.

You can find more details on how to perform 301 redirects on Google’s support page. Also, the world of internet is pretty generous when it comes to giving pieces of advice on how to move your site to https. Putting it simply, with only a few lines of code you can transfer all the organic search traffic from one domain to another.

2. Add <link rel=”canonical”> to the new HTTPs page

The rel=canonical is an HTML element that helps you prevent duplicate content issues. Basically, what it does is to tell the search engines which one is the preferred version of your web page. When you switch to https, what will happen is that you will have two websites with identical content: your http and your https version. In order to avoid duplicate content and all the related problems, you need to let search engines know which version they should show up in their results.

To make sure that your current URL (the one with https) shows up in search results, you need to add <link rel=”canonical”> on your new HTTPS version of your site. As through exemplification is the easiest way of understanding things, let me show you how this works by using a URL of our own. As I want this blog post , the https version, to be the one that will show up when people will be looking for ways of repurposing content, this is how the URL should look like:

3. Change <meta property=”og:url”>

To begin with, you need to know that the purpose of “og:url” is to set the preferred URL for the page you are sharing. If you are thinking for a second that this isn’t so important, let me know tell you that through “og:url” you define the page that all your shares will go to. Therefore it’s highly – decidedly – deeply – eminently to set the <meta property=”og:url”> to point to your newly HTTPS version. Therefore, here is how a URL should look like:

How to Get Your Social Shares Back on Facebook after Moving from HTTP to HTTPS

We all create a lot of content. We try to make it the best, the most documented; that kind of content that goes straight to your inbox and makes you read it. Content is king; but what is a king without followers? Along with being a social proof instrument, the social medium is a fantastic traffic driver and it can even influence your ranks (we’ve previously written a blog post on this). Therefore, losing your Facebook social shares is a tremendous problem. And, unfortunately, it happens when you switch to https. We encountered the same situation ourselves when we migrated our site and after long researches we figured out a way on how to move to https without losing Facebook shares. Below we are going to show you a workaround, tested and implemented by ourselves.

It’s important to know that these changes should be done only for pages that already existed on your site when you made the switch. For newer pages these modifications should not be applied.

1. Find out how many Facebook shares you have for a URL

To see how many social shares Facebook has for a URL, you need to use Facebook’s developer debug interface. You need to get to a page similar with the one from the screenshot below. You have the possibility of entering any URL to see how many shares it has. You will add here the http pages you are interested in getting your shares back for. Of course, you can use this interface for other issues as well, yet, from the present purpose you need to use the Sharing Debugger category.

2. Set both your HTTP and HTTPs social shares to zero

After adding the URLs you are interested in Facebook’s debug interface, you will have the possibility to “Scrape Again” (you will have a button with this exact message). Once you do this, all your Facebook shares will be zero, for both HTTP and HTTPS. Don’t panic, as the next step will fix this situation.

3. Update rel=”canonical”

The previous step left you with all your shares to zero. By now you might be thinking how these steps are really helping you in getting your shares back. Bear with me as you are closer and closer to getting your social shares count.

The next step in solving the social share loss situation is to alter the content you are showing to Facebook’s crawler. What you need to do, for Facebook only, is to make sure that the rel= canonical tag is placed, but not the way you would think of. It’s exactly the other way around: you need to make the http version the preferred one, just like in the example below:

4. Identify Facebook’s Crawler

If you think that the problem is already solved and your share counts are already updated, I must ask you to have a little more patience, as you are just one step closer already.

We’ve previously told you that you need to alter your content’s page for Facebook’s crawlers. Yes, this is very similar to cloaking, an old school search engine optimization technique in which the content presented to the search engine spider is different from that presented to the user’s browser. However, this situation is different than the one in which you want to grossly manipulate Google’s ranks. Using this will not impact your ranks and will not affect your site negatively. What you are going to do is not altering the exact content of the page, but only the protocol and with the sole purpose of keeping or getting back the social shares.

An important step is correctly identifying Facebook’s crawler. You can do this identification by user agent or IP.

In the screenshot below you can see how things should look like in the Facebook debug interface after altering the content for the crawler. As you can see, the fetched URL is the one with https while the canonical URL is with http. Remember that this should be apply for the old pages that you had on http.

For the new pages, the one that you’ve created on https already, things should look like in the screenshot below. HTTPS for both fetched and canonical URL. In the screenshot below there is a blog post that we’ve created after the https migration. As mentioned before, for newer pages the modifications presented in this chapter should not be applied.

You can get inspired from the code examples below, for three different instances, for PHP, forNginx and for Apache.

For Apache, you can create a code similar to the one above, depending on the web Apache server syntax.

Bonus: How to Get Your Social Shares Back on Google+ after Moving from HTTP to HTTPS

As in the previous case, you need to know that the following changes need to be done only for pages that already existed on your site when you made the switch to https. For newer pages these modifications should not be applied.

Wen it comes to getting your social shares back from Google Plus, things are a bit easier than in the case of Facebook. No crawler identification or content alteration is needed. The only thing you need to modify are the Google+ sharing buttons so that you will share the URL on http and not on https. To do so, for your old pages you can get inspired from the code example below:

As you can see, when it comes to Google Plus only the social share button suffers changes; no content fixer or https URL alterations. You can switch to SSL and still keep your shares just with a workaround on the sharing button.

The Struggle of Getting Your Facebook Shares Back

Facebook likes are linked to the URL, meaning that even a single character change (like the extra “s” that gets added when you switch from “http” to “https”) will cause you to lose your likes.

As Facebook itself explains on the social plugins part of their FAQs, “you can’t move the likes, shares or comments directly to the new URL but you can use the old URL as the canonical source for the number of likes or shares at the new URL”.

However, the feedback on the effectiveness of this solution and others is mixed, at best, with some users suggesting that even fixes like those proposed by Facebook are incomplete or ineffective.

Other solutions suggest to manually put the old share count into the custom fields of a plugin but those share counts will not increase until the new share count for that link equals the share count you pasted into the custom field. Therefore, not quite a solution if you really need your old shares back; not to mention that if you have lots of pages with different share counts it’s very unlikely that you know those numbers by heart.

It’s true that the social media networks might suffer from manipulation if they blindly moved social signals across redirects.

You could, for instance, buy an old domain and transfer all the social signals to another landing page that interests you. But what webmasters usually want is to get their shares back, the social shares that they already have with no other deceiving intent.

You don’t want your site to be considered as having insecure content but you also want your http and https urls to have their social count recoveries as fast as possible. The problem comes when Google considers that the SSL certificate is a must but not Facebook likes not so much. Any webmaster would probably think different, that both are important and both are a part of your overall digital marketing strategy. Along with the changes required in Google Analytics when you make the switch from https to https, you should consider the workarounds presented above in order to maintain your Facebook likes safe and sound.

Cornelia is a proud Digital Marketer @ cognitiveSEO. When she is not documenting for the next amazing case study, she is probably somewhere trying out a new extreme sport such as Hang Gliding. Also, she's an avid traveler, extreme sports enthusiast, and aspiring drum singer.

I dont feel like playing with canonical is right thing to do.
Another solution is to change ‘data-href’ attribute for fb-like button, pointing it to the old http address. That way all likes and (probably) shares are collected (inside FB Graph) for the older version of URL, being displayed for the new one.
But you really should skip zeroing likes+sharing count if you stick with that method.
Cheers

Thanks for Giving Information about how to recover your facebook shares after moving from HTTP to HTTPS. It helped me a lot and specially that bonus part recover of Google+ shares after moving.
Keep Posting

Any chance you’d be willing to share with me how this should be implemented via WP? I’m thinking about targeting an array of posts using is_single, but unsure how to implement the useful snippet above. Thanks again! 🙂

Jordan, I cannot offer you here the exact technical steps you need to follow but I am sure that if you follow the steps tackled in the article and you collaborate with someone with some WP experience, you’ll get the job done 🙂

Hi, Marni! If you are using a Content Management System (like WordPress), it is relatively easy to identify which articles are old or not, by an ID or by the published date, after that, using a bit of coding these changes will apply for all your older articles, if it’s the case. Basically, you will create a rule that will apply for all your articles, no need to do these changes for each piece of content.
Good luck in getting your shares back!

Very useful article. My only worry would be how Google understands this kind of implementation by having the old URL in the canonical tag. For ex In WordPress when you change the permalink structure, it also changes the URL structure, so in this case (to recover FB shares) if I keep old URL in canonical tag – Google might not index new URL structure in search results & will give preference to old structure which may also affect the flow of overall SEO juice from Old URL to new URL. What are your thoughts on this? Any suggestions you would like to provide?

Thank you so much! I followed your steps and had restored Facebook share on two WordPress websites successfully, one uses clouldflare.
On WordPress, I removed “share this” plugin and used a social media plugin that installed on server.

This is so frustrating! In my case, just a few page site using “manual” Facebook buttons — I placed the buttons manually — I am not running WordPress, just PHP. The only way any method works for me is if I remove the 301 redirect in Htaccess file (from HTTP -> HTTPS). Facebook ignores the REL canonical, pointing to HTTP, otherwise. It checks first if there is a 301, if there is, that is the canonical link, the HTTPS.

It seems pretty incredulous not to have a 301 redirect in place after migrating to HTTPS! This is code I used. In fact, this is not the code I used a few days ago after migrating, it’s twice the length of what I used. It looks like my host provider (or something automated on server) altered it:

You talked about identifying the Facebook crawler. I’m not quite sure how to do that. I added the PHP snippet, but this did not force Facebook to read the HTTP canonical. Nothing did, until I removed the 301 redirect. That was immediate, the 2.5k Likes appeared instantly.

Also, the manual Facebook share button is set to HTTP. “change ‘data-href’ attribute for fb-like button, pointing it to the old http address”. That worked fine until I put the 301 in place, which brought that count immediately back to zero.

I am struggling with a 3 page site right now! I am in the midst of migrating a blog of over 2,000 pages to a WordPress install (stage 1), then after that gets done, moving to HTTPS (stage 2). At least in that scenario I will have plugins to help.

Thank you for your article. After I followed the steps, the sharing debugger still shows canonical URL as “https://…” despite that the scraped html by facebook has canonical set to “http://”. In the code, I recognize the facebook crawler using PHP to set canonical url as “http://…”. Is it neccessary also to stop redirection to https for the facebook crawler using nginx?

hi I have purchased SSL and not yet applied it- I have a big site allthoseshapes.com – over 1300 pages. if i have to add rel:canonical to all of them (which All-in-One SEO allows for) and og:url (which there is no option per post/page) – well im freaking as you can imagine.

Yes I will add canonical to only pages which have shares (but that means going through every page AAARRRRGGGH! before the SSL switch).

But is it better / does it work adding just the redirect – then adding the facebook crawler detect php? (and, where do you add that?

I’m having troubles fetching the canonical url.
If I view the page-source I can clearly see the canonical url in http-variant. However if I try to fetch this webpage Facebook debugger shows me the https-variant. I’ve already tried disabling all kind of plugins but this problem still occurs.