Preserve Google +1, Facebook Like, and Twitter Tweet This button counts after URI change - redirect

My question is very simple: is there any way to (programmatically, technically, or manually) make a Google +1, Facebook Like, or Twitter Tweet This button preserve its count after a change of URI?
Programmatically: Doing something with the javascript to make it show the combined counts of two URIs while posting the new action to only the latter.
Technically: Do they detect and follow a 301 redirect from the original resource? Is there any special text I can include in the HTTP header to tell them that they should move all "points" from the old URI to the new one?
Manually: Some form somewhere on their site that I can submit or someone I can email that will be able to copy our points over to the new URI?
(note that I use URI and not URL in this question on purpose. The canonical resource link is changing from something.php?id=idnumber to /mycoolproduct/)
EDIT
Bounty started, but don't answer with "it can't be done"

I believe there is only one solution that fits your request above universally. That solution would be to 301/302 the old URIs to the new URIs and then keep using the old URIs with your social buttons. All the major social buttons allow you to specify the URL for which to like/g+/tweet/etc. This would preserve your existing social share counts and all shared posts would still direct to the same page. The choice now becomes whether to 301 or 302 redirect. A 302 may help preserve current search placement and avoid loosing your ranking if its pretty good. A 301 redirect (moved permanently) will cause search engines to start indexing your new URLs and dropping the old ones. This might cause a loss in current search rankings. It appears that as of this post, nobody is honoring redirects for social votes of any kind.
So I think the the safest route is to 302 redirect and continue to use the old URIs for social votes. You will keep your equity this way, but must maintain your redirects and become even more invested in the old URI template. How are your redirects implemented? .htaccess? or in page? You will need to weigh the cost-benefits for your case.
Otherwise you should probably 301 and start using the new URIs for your social buttons. In this case you might loose your social equity, but are free to build new without fear of messing up anything. If the social equity you are replacing can be recouped in say 6 months or less I wouldn't bother with it and start fresh.
However, this brings up an interesting point. You mentioned programatically adding two counts. Well yes, you could put together some JavaScript to add a couple counts together, but I gotta ask why? Adding them together for visual display purposes will not actually help increase referral traffic or search ranking. So its just a facade that I don't think helps you. If you're just looking to fool your visitors into thinking you're popular, why not just generate an image server side that keeps counting up. (bad joke, don't do it!) Bottom line you can't actually redirect your social equity, you may be able to pretend to have moved it, but you can't actually.
Considering your original question asks about several social buttons, its important to note that even if one or two of these services started honoring redirects when applying social votes, it wouldn't relieve you from making the decisions above. You'll still need the redirects for existing backlinks, and if you are supporting multiple social buttons on your page the choice of redirect type will need to be made with all of the social buttons in mind.

I can't speak for how to do this with Twitter/G+ but for Facebook:
You can't 'move' the likes and comments between URLs, and for new content you should definitely start using the new URLs, but for your existing URLs you can still have the original like counts/comments work if you:
Continue pointing the Like button on the new URL to the old URL (i.e <fb:like url="http://oldurl"/>
Add an exception to your redirect code so that when Facebook's crawler (facebookexternalhit/1.* - currently 1.1) accesses it, the original set of open graph meta tags are displayed (this will keep the description, title, thumbnail, etc, working as before)
Other users that land on the 'old' URL will still be redirected to the content in its new location

I have a real solution to this problem it might not be the most conventional but it does work 100%. Using a simple jQuery plugin called sharrre. Keep in mind I'm not the best jQuery coder (If you see improvements please let me know!) but this works regardless.
Here is how I did it on my site:
Using the sharrre plugin you can add the current share count to any element on your page. I simply got the data for both URLs then added them together and displayed them on the like, tweet, share, etc buttons.
This example is with Twitter but I'm doing this with Facebook, Google Plus, Pinterest and Linkedin. Here is the code:
<li id="twitter" data-url="CURRENT-URL" class="twitter sharrre"></li>
<li id="twitter-old" data-url="OLD-URL" class="twitter sharrre" style="display: none;"></li>
Then I called sharrre's code:
$(function(){ sharrreItUp(); }
This is how my function looks on my .js file:
function sharrreItUp() {
$('#twitter').sharrre({
share: {
twitter: true
},
enableHover: false,
click: function(api, options){
api.simulateClick();
api.openPopup('twitter');
}
});
$('#twitter-old').sharrre({
share: {
twitter: true
}
});
setTimeout(function(){
var oldTwts = $('#twitter-old .box .count').html();
var newTwts = $('#twitter .box .count').html();
$('#twitter .box .count').html(parseInt(oldTwts) + parseInt(newTwts));
}, 2000);
}
And BAM... you have your new URL being sharrred and the old shares from different social networks get added into them.

Unfortunately, there is no solution for this. We have tried all possible solutions and you will simply lose your social equity if you do a 301 Redirect. We found it to not be worth the hassle of trying to maintain our vote counts, and have instead pointed our buttons to the homepage in the interim of moving to the new url structure.

demo: http://so.devilmaycode.it/preserve-google-1-facebook-like-and-twitter-tweet-this-button-counts-after-ur/
i don't wanna say something wrong, but i think you just need to define the URI inside each share button, so no matter from what URL the vote come from, the defined url will be used as count.
if you, instead already have two different sources and you want to join it, you should follow the iframe src and scrape the count from it; for google +1 the div id that contain the count is #aggregateCount for twitter is #count; an example could be as below:
<?php
$doc = new DOMDocument();
$doc->loadHTMLFile('iframe-url-goes-here');
$count = $doc->getElementById('aggregateCount');
echo $count->nodeValue;
?>
then, on your page after the DOM is loaded and the widget are loaded, you can append your own value.
hope this help, in anycase i prefer the first way.

Put in the head of the new page
<meta property="og:url" content="old_url_here"/>
This way Facebook attributes likes for the old page. The only downside is that this way when people share your link, the old rich snippet will be included.

Related

Creating a Tumblr Landing Page Using Redirect Code

there was a similar question to this one asked a while back - but for some reason the comment that contained specific instructions for the workaround was deleted.
I am attempting to create a landing page on a tumblr page using the redirect code below.
<script type="text/javascript">
if(location.href == 'http://labellablog.com/') location.replace('http://labellablog.com/welcome');;
</script>
The issue that I'm experiencing is the same as the person who posted the question in the first place - by putting the redirect code in the index page, it creates a loop. i.e. In trying to click the link on the 'welcome page' in order to get to the home page containing blog posts, navigation etc., it simply re-directs to the 'welcome' page.
The solution that is mentioned (not in great detail) on another question states that you must set the cookies to expire in a certain amount of time. Unfortunately I'm a huge amateur when it comes to coding and am not entirely sure how to achieve this.
Thanks in advance for any advice.
Method 1
Based on your question this is how I would resolve it (this is not using the cookie method at all, but I will come to that).
Make sure jquery is installed in your theme, alot of themes already have it, if not you can add it to the head of the document like so:
<script src="https://ajax.googleapis.com/ajax/libs/jquery/2.1.3/jquery.min.js"></script>
Lets look for the index page:
var primaryDir = document.location.pathname.split("/")[1]; // get the first directory
if (!primaryDir){ // if the primary directory is empty (index page) lets redirect to another page
window.location('/welcome');
}
You can use /welcome and that will work if you change the name/url of your site/tumblr.
So this method means this will always run (unless you disable javascript) for every client that connects to your site. This means effectively that the index page is never visible.
Now if you wanted a cookie method, this would mean that you would create the redirect on the first visit, then set the cookie and then after that the index page would be visible.
If that is what you want, let me know, but that involves quite a bit more code, slightly more complex solution.
EDIT
Another way to achieve this is to create a hidden div in the main template that only shows on the index page and is hidden on all other pages, this means you don't have to rely on a slightly slower redirect.
I only posted an answer to that issue the other day: How can I make a Tumblr background image only for one page?
Method 2
OK here is a method adopting cookies.
First I recommend downloading this jquery cookie plugin
You will then need to link to that as a resource in your theme, so you need somewhere to host that file. I use dropbox, but tumblr also has a repository for linking to files (well it used to seems to have disappeared).
Now create an element that will sit over the main page:
Enter
You can style this to fill the whole page if required (modify to your needs):
#entry {
position:fixed;
top:0;
right:0;
bottom:0;
left:0;
background:#CCC;
color:#FFF;
// yadda yadda
}
Now we need some click event to create the cookie when we click on this huge anchor:
$(document).ready(function(){
var entry = $('#entry'); // lets cache the selector in a variable
entry.on('click',function(){
$.cookie('deadlyrhythm', '1', { path: '/', expires: 1}); // set a cookie with the name deadlyrhythm to the value of 1 on the entire site for 1 day.
$(this).hide();
return false;
});
});
Now we need a method to check if the cookie exists, so inside the same document ready function:
if ($.cookie('deadlyrhythm') != '1'){
entry.hide();
}
This should mean that for 24 hours the cookie is set and the entry will not display if the same user revists the site, but it will after one day, of course you can set that value to anything you like.
As I mentioned this is slightly more complex to implement, but in the console of the browser you can check to see if a cookie exists and delete it manually (I use chrome for this) this is really useful for testing.

Do Facebook Like Buttons require an App ID?

When going to the set up pages for all the Social Plugins, they now provide example code using an APP ID.
http://developers.facebook.com/docs/plugins/
Is an APP ID now required for the Like Button and other plugins? What happens if an APP ID is not included when using the plugins?
I've checked the Facebook developer blog and read about the Like Button Migration. I haven't been able to find a straight answer for this either there or in the FB Like Reference.
Notice:
This is an old dated information, the official facebook's behaviors are changed.
Simply, the answer is No, just look at the following official Facebook resource.
Notice: To do it without need to the app id, you have to visit the above page when you are signed out from Facebook. Look at the following screen shot.
As semsem said, the simple answer is "no it is not required"... there are ways to get around having an appId associated with the "like" button. Here's my experience working with this. I'm not a Facebook or Open Graph expert, so YMMV.
Why we avoided using the appId on the button:
We're providing an service where we have one website (the engine, as it were) that provides a service distributing online courses to students (customers). Instructors (also customers) who what to use our service to disseminate courses to students can brand the site how they wish, and map their domain to their section of our website that serves those course(s).
As a simplified example: we serve from http://courses.example.com/instructor_name, but we want students to access the content through http://www.instructors-domain.com/. Any courses would be sub-directories off the base URL.
Associating the "like" button with our Facebook App disallows any cross domain shenanigans. While there are valid reasons for doing so, it doesn't work for where we're at in our company and product evolution. So we needed to find a workaround.
We wanted to allow folks to "like" a course, have the "story" point to the appropriate places on the net, as well as get some customization (e.g. "NAME likes an online course on FBAppName"). We basically achieved this. We lost some functionality which we deemed acceptable at this point in our evolution.
The short of it
I used the iframe version of the Facebook "like" button as dictated by the appropriate Facebook developer's page (for the link see semesm's answer for the link, I got no rep). I took their code snippet and manually removed the appId query string in the iframe's src.
In the "liked" page itself (which was the same page that had the "like" button) I used the Open Graph meta tags including specifying the appId. (These tags were specified: fb:app_id, og:type, og:url, og:site_name, og:title, og:description, og:image.)
The og:type was our custom type of the form 'namespace:app_custom_object_name'.
A failed approach
My first attempt was to use what I understand as the preferred method, the "HTML5" tab in the "Get Code" section of the developer's "like-button" page. I tried their method stripping the appId from the appropriate places. This method proved ineffectual.
If the domain doesn't match that in the Facebook App, there will be no "like" button.
If the domain does match, the "like" button will appear. However, it takes 3 clicks to actually "like" something. The first click changes the "thumbs-up Like" icon to a normal anchor with one word that didn't make obvious sense (I forgot what the word was). The second click will brings up the login/authorization window for using our app. The third actually bring up the modern fancy "like" box where you can type in a comment. I didn't find a way around this behavior.
Note that when I specified the appId in this approach on the appropriate domain, it worked as one would expect (though inconsistent with our desired behavior).
I did not try the other two options in the "Get Code" section of the "like-button" page.
Informed speculation and rumor
In my research around this, my overall impression is that requiring an appId is the way of the future for Facebook. Who knows if the old way will be depreciated, probably never, though I didn't find anything in the docs talking about this "legacy" behavior. This makes sense to me with their newer offerings and the advanced tracking that becomes available with this method.
I've seen suggestions that the "likes" used in this manner are akin to second-class citizens... treated as inferior in some respects. In my own experimentation I found the behavior of the fully specified appId (in the "like" button itself) to be different and more accessible and predictable (in terms of Open Graph queries and visibility on my limited Facebook tests) than the partially specified appId. (Again, I've found no solid documentation on this, and did not endeavor to full grok the differences.)
May this info help someone else along. Good luck!
So, I just tried the sємsєм method, as comments say: Facebook want you to login to get the code, and if you have an app, you have to choose one.
But if you don't, it gives you a code without any app reference.
So when you get a code – no matter any app you choose –, you just need to remove the appId parameter in the .js URL (&appId=##############), and you got (for the latest HTML5 code, 6th line):
js.src = "//connect.facebook.net/en_US/all.js#xfbml=1";
The code for the div element does not change.
I simply use the URL code inside an iframe tag without an appID and it seams to work,
here is an example:
<iframe src="http://www.facebook.com/plugins/like.php?href=<%=request.original_url%>&width&layout=button_count&action=like&show_faces=false&share=false&height=35&appId=" frameBorder="0" width="150" height="25">
</iframe>
According to Facebook's Social Plugins FAQ
Web: If you are using Social Plugins on the web, you do not need to create a Facebook app for integrating a Social Plugin.
iOS/Android: If you are using Social Plugins within a iOS or Android app, you need to create a Facebook app and tie it to your app identifier.
It seems that the official answer is that they are only required for iOS/Android.

Dealing with 301 redirects for a brand new website

I have seen multiple articles on redirecting Urls when the site has been redesigned or Url just changed to a standard format but I need to know how to manage when the Url has no correlation to the old one.
For instance, an old Url may have been www.mysite.com/index.php?product=12 but there is no way to map that Url to the new site.
I don't want search engines to think that the page has broken so I assume the best thing to do is to 301 redirect to the home page but I am not sure how I would do that effectively. Would I just change the 404 error page to do a 301 to the home page?
Also, would that then cause issues with duplicate content via dofferent Urls?
Is it better to just not worry about these and let the search engines re-index the new Urls?
I am running IIS7 with Rewrite module and ASP.NET 2.
Thanks.
Why do you say there is no way to map that URL to the new one? There probably is, since both should be unique identifiers for a given resource. If your site has good rankings, it may be worth the pain to work this out and have a 301 redirect to the right page. In this way, the ranks should be unchanged.
Redirecting everything to the new home page will probably have a negative effect. It really depends on how the bots are going to interpret this. But it may seem an artificial way to increase the rank of the home page, and correspondingly get a penalty.
Doing nothing and waiting for the bots to index your new site will of course work, but often you cannot afford to lose the high rank you have gained.
All in all, I would advise you to ask here a new question on how to map the old URLs to the new ones, and do proper redirects.
That product URL you supplied is obviously, well, a product. The best bet is to 301 redirect it to a new page that is the most relevant to that old page. If there aren't any external links even pointing to it at all, just let it die. Be sure to remove it from any sitemaps or old navigation links you may have internally though or it will keep getting re-indexed which is what you want to avoid.
Once you have your new site structure set up, visit a site like AuditMyPc.com and create a brand new sitemap of your new site setup. Then login to Google Webmaster Tools and resubmit the new sitemap. This normally will fix the problem, but if that page is indexed, expect it to stay in Google's index for a while. They don't clean themselves up too well.

How best to setup 301 redirects from an old site that has many duplicate entries indexed on Google?

I am currently working with a client to redevelop their website. One of the final things I need to do before launch, is to make sure that their old website's pages are correctly redirected to the new URL structure of the new website.
Unfortunately, when I check Google to see how their current site is indexed, this relatively small website appears to have over 1500 pages indexed.
When I look at the indexed links on Google, many appear to be duplicates of the same page, but because of the terrible URI structure used on the old website, Google treats them differently.
For example, the 'Map' page is indexed at least twice on Google, under the following 2 URLs:
www.website.com/frame_page-map.html?mp_session=iris7k85851j05q55piqci31u3&mp_session=iris7k85851j05q55piqci31u3?page_code=map&mp_session=iris7k85851j05q55piqci31u3&mp_session=iris7k85851j05q55piqci31u3
www.website.com/frame_page-map.html?mp_session=sel6m8j5cu8lulep4dqa32sne7&mp_session=sel6m8j5cu8lulep4dqa32sne7?page_code=map&mp_session=sel6m8j5cu8lulep4dqa32sne7&mp_session=sel6m8j5cu8lulep4dqa32sne7
Only the session name is different in the URL (and I have no idea why it is repeated four times in a single URL, either).
For reference, the replacement URL for this page is:
www.website.com/contact/map
My question is: How do I setup a redirect for these multiple records on Google? Do I simply set-up the redirect for the old URL minus all of the URI parameters (i.e. www.website.com/frame_page-map.html) or is there another better method to do this?
Thanks for any help you might be able to offer!
It depends on what your goals are. If you don't care about the querystrings then setup a 301 (permanent redirect) that points to just your root page - map.html. To prevent google from indexing querystring params as separate pages use the canonical tag and have it reference the parent. This isn't guaranteed to work, but google takes your canonical into consideration when indexing.
If you care about the querystring values then you will have to setup a redirect for each one. There is a querystring parameter that you can append to your redirects that will tell it to be ignored so you don't have to write a regex that detects it.

How can I pull in my BlogSpot page into a page on my web site

I have a blog on BlogSpot.com, and I have a domain based on my own name. I want to have a URL on my site (like http://www.mydomain.com/blog) that will then pull in the content from my blog page, but I want the URL in the address bar to stay on http://www.mydomain.com/blog, so that it does not look like you left my site.
(I have a Windows hosting account on 1and1.com)
I did Google this question, and I found how a few things, like:
1: Adding a tag in to "refresh". Tried this, but it changes the address bar.
<meta http-equiv="refresh" content="0; URL=http://myblog.blogspot.com" />
2: I also learned about the html iframe thing, but it has height and scrollbar issues.
3: Then, I found this partial code snippet, but I don't know what to do with it, or if it will even work against the BlogSpot server, or on my server:
<%
Set objHTTP = Server.CreateObject("Microsoft.XMLHTTP")
objHTTP.Open "GET", "http://myblog.blogspot.com", false
objHTTP.Send
Response.Write objHTTP.ResponseText
%>
I am a client app guy, so this web stuff is all new to me.
Any help will be greatly appreciated.
The third option will probably work for the initial page load, but any links on the page will then direct the user to the BlogSpot page, and change the url. It simply fetches the page from blogspot, and then sends it to the user without any changes.
For me, the changing url is not a big deal, as long as it's easy for the user to get from one to the other easily; have prominent links on either page that tell the user where they go. Most people don't care about the url, they just care about the content.
Using an IFrame is probably your best bet. Many Facebook applications are in IFrames and still integrate very well.
I think using a regular frame or an iFrame is probably the easiest solution. What kind of scrollbar issues did you encounter? You can set custom values for some of these attributes, just check out the documentation here:
http://www.w3schools.com/TAGS/tag_iframe.asp
If you didn't want to use frames, you could actually proxy the entire page using a server side application like Squid. However, this is more difficult to setup, requires the ability to install software and configure firewall/iptable settings on your host, and must be configured properly to prevent malicious abuse.
-Mark
Here are some options you can try:
If you have PHP installed:
<?php
echo file_get_contents('http://myblog.blogspot.com'); // or you can use fopen()
?>
Or Server-Side-Includes installed:
<!--# include virtual="http://myblog.blogspot.com" -->
You can also pull blog content from Blogspot using the Blogger Data API.
The advantage of this is that you can reformat and reorganize the content to match the style of your website. The disadvantage is that it's more work than an iframe, and you probably won't match the full functionality of Blogspot.
I'm playing with this now to see whether I can use Blogspot as a type of CMS for a club news system.