fb_xd_fragment added to URLs with IE 7.0

Seeing URLs with fb_xd_fragment= reported in Google Analytics may not mean that your SEO is suffering, so don’t panic!

Your alarm might rise further when you see that the presence of the fb_xd_fragment= parameter causes the entire page content to become hidden whilst the page is loading. Still, don’t panic – investigate!

There are three main situations when panic is justifiable:

1. If you see that Google has indexed pages from your site with the additional &fb_xd_fragment= parameter, (Hint: use the site: and inurl: operators to check)

2. Users are reporting that they are seeing ‘blank’ pages on your site e.g. http://www.letsrun.com/forum/flat_read.php?thread=4349142 If you have come to this page looking for a solution as a user of a site, try to delete the ‘&fb_xd_fragment=‘ from the end of the URL and reload the page. if that does let you see the page then contact the webmaster and direct them to this post so they can implement a fix.

3. Since the confirmation that Google is indexing facebook comments (cf. Matt Cutts http://www.searchenginejournal.com/google-indexing-facebook-comments/35594/), the indexation of bad URLs from your site may grow as a consequence. Google may read the javascript on your site and generating these URLs to find additional pages to crawl.

Why are URL including &fb_xd_fragment= being visited in the first place?

The standard implementation of Facebook Javascript SDK for ‘Like’ buttons has been cited as the cause of fb_xd_fragment being appended to URLs for users of “certain browsers”.

It appears that Facebook Javascript SDK causes these ‘phantom’ visits when real visitor clicks on a ‘Like’ button (and overwhelmingly, the visits come from visitors using IE 7.0). It is a combination of the XFBML version of facebook plugins and IE 7 that gives rise to these URLs being generated by javascript and then reported in GA.

Now for a run through of the solutions to the fb_xd_fragment bug…

Here’s a recipe for various solutions depending upon the scale of your problem:

fb_xd_fragment solution A:

Use a custom channelURL file (channel.html) stored at root level. This is used to overload the FB.init() constructor by setting the channelUrl parameter value when FB initialises.The contents of channel.html are simply:

<script src="//connect.facebook.net/en_GB/all.js"></script>

The file above must be cached for as long as possible to provide a smooth user experience and avoid time delays.

This file can fix cross-site scripting issues (see http://developers.facebook.com/docs/reference/javascript/) – Facebook dev resources refer to this issue with tongue in cheek: “The channel file addresses some issues with cross domain communication in certain browsers.”

Finally, add the following code to your pages (on detection of IE 7.0):

<div id="fb-root"></div>
window.fbAsyncInit = function() {
   FB.init({appId  : 'MY APP ID',  status : true,  cookie : true, xfbml  : true, 
            channelUrl  : 'http://www.yourdomain.com/channel.html'});

(function() {
var e = document.createElement('script');
e.src = document.location.protocol + '//connect.facebook.net/en_GB/all.js';
e.async = true;


fb_xd_fragment solution B:

Use javascript to undo the nasty side effects of the fb_xd_fragment= in order to make the hidden html visible once again. Use onLoad() to run the following script. NB. As with all scripts, this solution may not work every time, as is essentially a sticking plaster to undo what has already been done.

<!-- Correct fb_xd_fragment Bug Start -->
<!-- Correct fb_xd_fragment Bug End -->


fb_xd_fragment solution C:

For those of you that would rather not use a custom FB.init and channelUrl, or add script to undo this ‘blanking’ effect, then the cheaper option is to use a redirect. Use 301 redirection to ensure that any URL requested with the fb_xd_fragment is redirected to the same URL only without this fragment.


fb_xd_fragment solution D:

Taking another step back from addressing the cause, you could try to prevent indexing of these pages by using the rel canonical link. Ensure that rel canonical is defined without the fb_xd_fragment on all pages that have Like buttons (use Browser/User Agent detection to set the canonical to keep page weight down, if preferred).

fb_xd_fragment solution E:

Use WebmasterTools Site Configuration / URL Parameter settings to set to ‘ignore’ the fb_xd_fragment parameter. This informs Google that URLs with this parameter are not important, and should not be indexed.

fb_xd_fragment solution F:

Fix (or more accurately, ‘hide’) the reporting. To keep these ‘phantom’ additional page views out of GA, add a filter in Google Analytics to strip all pages that include the fb_xd_fragment. Ensure that you have identified and fixed (if necessary) the cause before filtering these pages from GA! If you have implemented Solution A, then you don’t need to use a filter. The problem of reporting the ‘phantom’ pages should go away with Solution A!


As with most SEO work, pick the solution appropriate to your needs.


If you see visitors appearing to come from a Google cache with this parameter, it is likely that these visitors use iGoogle and they are following a cached link from their dashboard. Look at the rlz parameter in the cache string for G1 to identify the source as iGoogle:

iGoogle cache with Internet Explorer 7 rlz parameter


Enhanced by Zemanta

Leave a Reply

Your email address will not be published. Required fields are marked *