I did some investigating, and this seems to be caused by two bugs (that I can tell). One, that Facebook's API causes a bug in IE that sends this query in the first place, and second that my website, because of the Facebook API, causes the page to become visibly blank because of it.
So, what to do? I decided to kill the query string at the source: my apache web server using mod_rewrite.
So here's what I added to the apache config for just this web server:
RewriteEngine On
RewriteCond %{QUERY_STRING} fb_xd_fragment=
RewriteRule (.*) $1? [R=301]So this basically sends a 301 HTTP code (Moved Permanently) with the same request, minus the query string. Note that the "?" on the RewriteRule is needed so that mod_rewrite doesn't append the old query back on. Seems to be doing the trick, and now I'm not losing traffic due to a Facebook API bug.
Hi Ben, check this blog post. It explains where the problem is coming from and suggests ways to fix it without changing your server settings: How to fix the Like button bug
ReplyDeleteThanks Stephan. I did in fact do a few of the things suggested in order to fix things up, but I prefer keeping the apache mod_rewrite just o make sure the request gets to a working page. As you know, even a few missed visitors can cost you money :)
ReplyDeleteGood one, I've been wondering where this came from and couldn't reproduce it (no IE around).
ReplyDeleteFor those who can't use mod_rewrite, the same results can be created in PHP with the following snippet of code:
if ( array_key_exists( 'fb_xd_fragment', $_GET ) ) {
header( "Location: ". $_SERVER['SCRIPT_URL'] );
exit();
}
Put it on top of your page (or init script, or whatever).
Of course even better would be to only unset the fb_xd_fragment path and redirect with the rest of the query string intact.
Oh, something I forgot: in my example you'll obviously want
ReplyDeleteheader( 'HTTP/1.1 301 Moved Permanently' );
as well, to instruct search engines to ignore the URI containing the offending query string.
Ben may I ask you something? Your solution is perfect if you can access the configuration file of your web server, but what do you suggest for people like me using blogger?
ReplyDeletethanks
We have written up a little tutorial on how to fix the problem: http://www.siliconbeachtraining.co.uk/free-resources/strange-code-google-analytics-training/
ReplyDeletethis will fix both the duplicate content problem and the Google Analytics problem
Hi,
ReplyDeleteYour code is redirecting ok, but appending the server path to the vhost:
http://www.server.pt/index.php?fb_xd_fragment=
redirects to
http://www.server.pt/sites/internos/directobras/html/index.php
any thoughts?
thanks for any help,
Gustavo Melo
Hi,
ReplyDeleteYour code is redirecting, but appending the complete server path of the vhost to the url:
http://www.server.pt/index.php?fb_xd_fragment=
redirects to
http://www.server.pt/sites/internos/directobras/html/index.php
any thoughts?
thanks for any help,
Gustavo Melo
Hi Ben
ReplyDeleteThanks for this. I like your solution - one question.
Forgive me if I have misunderstood the source of the problem at some level but I am working in "panic mode" since I discovered this in my Analytics and want to move fast to avoid SEO penalties.
It is my understanding that some versions of IE are redirecting on pages with like buttons to the same page with the fb_xd_fragment variable appended.
If that is the case, won't an apache redirect send them into a never-ending loop?
Thanks
James
Hi Ben, check this blog post too, i've found another URL different form the standard fb_xd_fragment URL that we have been seeing. It also takes visitors to a blank page and requires an additional 301 redirect. fd_xd_fragment
ReplyDelete- Alec Gordon