XFBML-Problem gelöst: ?fb_xd_fragment macht keine Probleme mehr

Das war mal wieder ein Problem, das mich etliche Stunden gekostet hat, obwohl ich einfach hätte sagen können: „Wer den IE nutzt, ist selber schuld“ Die Rede ist vom in letzter Zeit populär gewordenen ?fb_xd_fragment-Problem beim Einbinden von XFBML-Facebook-Like-Buttons auf der eigenen Seite.

Dieses Problem tritt ausschließlich im Internet Explorer auf (Version 6-8, soviel ich weiß. Ob es in der 9er noch so ist, weiß ich nicht.). Opera, Firefox, Safari, Chrome, Iron, etc. sind davon nicht betroffen. Das Problem äußert sich folgendermaßen:

  1. Webmaster baut den XFBML-Code für einen „gefällt mir„- oder „empfehlen„-Button in seine Website ein, um hohen Traffic von Facebook zu bekommen.
  2. IE-Nutzer liest einen Beitrag, der ihm gefällt und klickt den Button an
  3. IE-Nutzer sieht nur noch eine leere Seite, der Klickt wurde nicht gewertet und der Nutzer verlässt genervt die Seite

Wichtig zu wissen: Es ist ausschließlich die XFBML-Variante von diesem Problem betroffen. Die iframe-Variante funktioniert in allen Browsern problemlos.

Mir ist die Sache aufgefallen, als ich meine Google Analytics – Statistiken analysiert habe. Die Artikel, die viele Like-Klicks verbucht haben, waren bei Analytics doppelt gelistet.

(Zum Vergrößern einfach anklicken)

Einmal mit und einmal ohne ?fb_xd_fragment=-Parameter.  Von 3353 Seitenaufrufen endeten 560 Seitenaufrufe mit einer leeren Seite. (Diese Seite ist übrigens gar nicht leer, sondern nur unsichtbar. Ein Blick in den HTML-Quelltext einer ?fb_xd_fragment=-vereuchten Seite verrät, dass dem HTML-Tag nur ein display:none verpasst wurde. Leider habe ich überhaupt keine Ahnung, was Facebook sich davon erhofft)

Das ist natürlich deutlich zu viel und eine Zumutung für meine Besucher. Also habe ich mich auf die Suche nach einer Lösung für das Problem gemacht und bin auch fündig geworden.

Die Lösung

Normalerweise baut man den Facebook-Code folgendermaßen an der gewünschten Stelle in seiner Website ein:

<script src="http://connect.facebook.net/de_DE/all.js#xfbml=1"></script>
<fb:like href="http://www.net-developers.de/blog" layout="box_count" show_faces="true" width="140" action="recommend" font="arial"></fb:like>

Mit diesem Codeschnipsel erhält man einen Like-Button für Facebook. Dieser wird dort angezeigt, wo man ihn im HTML-Code platziert hat und scheint auf den ersten Blick auch super zu funktionieren. Doch wer dann mit dem IE testet, wird sich wundern.

Leider ist Facebook in Sachen Dokumentation nicht sonderlich fleißig, denn selbst nach langer Suche in der Doku habe ich die Lösung nicht gefunden. Über ein Forum, das ich über Google gefunden habe, fand ich eine Seite in der Dokumentation, in der eine Lösung (gut versteckt unter Custom Channel URL) beschrieben ist. Diese ist sehr einfach umzusetzen.

Alles, was zu tun ist:

  1. Auf seiner Website eine Datei namens channel.html anlegen. Diese Datei sollte im Root-Verzeichnis liegen, um unnötige Probleme zu vermeiden. Aber theoretisch sollte es mit jedem anderen Verzeichnis auch funktionieren.
  2. Die Datei bekommt nun folgenden Inhalt:
    <script src="http://connect.facebook.net/de_DE/all.js"></script>
  3. Diese Datei muss jetzt noch bekannt gemacht werden. Das geschieht in der FB.init()-Methode. Folgender Code muss direkt nach dem öffnenden Body-Tag eingefügt werden:
    <div id="fb-root"></div> <script>
     window.fbAsyncInit = function() {
         FB.init({
           appId  : 'MY APP ID', //Kann man auch weglassen, bei mir funktioniert es ohne App-ID!
           status : true, // check login status
           cookie : true, // enable cookies to allow the server to access the session
           xfbml  : true,  // parse XFBML
          channelUrl  : 'http://net-developers.de/blog/channel.html' // Deine Channel-ID
         });   };
    
       (function() {
         var e = document.createElement('script');
         e.src = document.location.protocol + '//connect.facebook.net/de_DE/all.js';
         e.async = true;
         document.getElementById('fb-root').appendChild(e);
     }());</script>
    

    Bei channelURL: … gibt man dann die absolute URL (mit Domain) zu seiner channel.html an.

  4. Jetzt muss man die Datei nur noch abspeichern, die Seite neu laden (Cache leeren!) und dann feststellen, dass das Problem behoben ist!

Naja, nicht ganz! Es treten jetzt zwar keine weißen Seiten mehr auf, wenn man im IE auf Like klickt und die Klicks werden auch gezählt, aber man wird nach wie vor eine leere Seite sehen, wenn man eine URL mit fb_xd_fragment-Parameter aufruft. Und zwar in allen Browsern! Besonders problematisch ist das, wenn Google bereits eine falsche URL indiziert hat. Für alle, die auch hierfür eine Lösung suchen, habe ich den nächsten Abschnitt verfasst.

Weitere Probleme mit fb_xd_fragment in der URL

Verrückt: Nach der Veröffentlichung dieses Artikels habe ich beim Aufruf der URL ebenfalls nur eine weiße Seite gesehen. Und das, obwohl nicht direkt ein ?fb_xd_fragment darin vorkam, sondern nur fb_xd_fragment (ohne Fragezeichen, also nicht als GET-Parameter) im Permalink. Und das ist nicht alles. Selbst wenn #fb_xd_fragment in der URL steht, bekommt der Nutzer keinen Content angezeigt. Probiert es aus!

Wenn man sich jetzt mit Firebug den Quelltext anzeigen lässt, sieht man

<html style="display: none">

ziemlich am Anfang des Quelltexts. „display:none“ sorgt dafür, dass die Seite nicht angezeigt wird. Doch auch hierfür habe ich eine Lösung oder eher einen Workaround:

<script type="text/javascript">
      var htmltags = document.getElementsByTagName("html");
      var htmltag = htmltags[0];
      htmltag.style.display = "block";
  </script>

Wenn man diesen Code direkt vor dem schließenden body-Tag platziert, wird der display-Wert des HTML-Tags auf „block“ (Gegenteil von none) gesetzt, nachdem die Seite geladen wurden. Das heißt, dass die Benutzer nach einer kurzen Ladezeit die gesamte Seite sehen, wie sie die Seite auch ohne das ?fb_xd_fragment-Problem sehen würden. Während der Ladezeit sehen sie jedoch nur eine leere Seite.

Im Moment weiß ich mir leider nicht anders zu helfen. Facebook arbeitet auch an keiner Lösung dieses Problems, denn der fb_xd_fragment-Bug gilt als gefixt.

Double Content / Duplicate Content

Hat Google erstmal eine Seite doppelt indiziert, hat man schnell ein Problem wegen DC (Duplicate Content). Im schlimmsten Fall könnte man komplett aus dem Google-Index fliegen. Aus diesem Grund sollte man dafür sorgen, dass Google keine URLs indiziert, die ?fb_xd_fragment beinhalten. URLs mit #fb_xd_fragment sind dagegen harmlos, diese indiziert Google sowieso nicht (bzw. nur bis zum Hash). Google und die meisten wichtigen Suchmaschinen und andere Bots beachten die robots.txt. Diese Tatsache machen wir uns zu Nutze:

User-agent: *
Disallow: */?fb_xd_fragment

Diese beiden Zeilen müssen in der robots.txt im Root-Verzeichnis eurer Domain liegen. Nur so wird sie von den Bots erkannt und gelesen. Im Grunde erklärt sich der Inhalt dieser Datei von selbst:

  1. User-agent: *“ sagt, dass die folgenden Zeilen für alle User-Agents (Bots/Suchmaschinen) gelten
  2. */?fb_xd_fragment“ verhindert, dass URLs von Bots indiziert werden, die ?fb_xd_fragment enthalten

Wenn ihr die Schritte in diesem Artikel befolgt, solltet ihr keine Probleme mit dem Facebook-XFBML-Code mehr haben. Wer noch mehr auf Nummer Sicher gehen will, kann noch jeder Seite eine Canonical-URL verpassen. Eigentlich ist dies aber nicht notwendig, da Google ja durch die robots.txt schon daran gehindert wird, die falsche URL in seinen Index aufzunehmen.

Viel Erfolg!

Weitere Informationen zum Thema

1 Star2 Stars3 Stars4 Stars5 Stars (4 Stimme, durchschnittlich 4,00 / 5)
Loading...


12 Kommentare zu “XFBML-Problem gelöst: ?fb_xd_fragment macht keine Probleme mehr”

  1. Danke für den klasse Beitrag!

    Als Ergänzung bzw. Alternative zur Vermeidung der Anzeige einer Blankpage hilft auch eine globale CSS-Definition mittels !important:

    html{display:block!important}

    Bei speziellen Plugins (wie z.B. die Wibiya-Toolbar) ist das sogar die einzige Möglichkeit.

  2. Man könnte falls es sich um eine dynamische Seite handelt, die Variable verbieten lassen, sprich auf eine 404-Seite weiterleiten, oder in den Webmastertools diese auf ignor setzen.

    Dann geht man dem DC aus dem Weg (vorausgesetzt FB braucht die Var nicht).

  3. Ich such noch nach einem Parameter für diesen FB-Button, und zwar will ich nicht, dass nebem dem eigentlichen Button ein Text erschreint.

    Jemand eine Idee wie man das hinbekommt?
    Danke

  4. @Zweifler: Hmm, man könnte da irgendwie was mit CSS hinpfuschen (dass der Text durch andere Elemente überlagert wird), ein Paramter ist mir aber nicht bekannt. Aber gibt es nicht auch Buttons ohne Text?

    https://developers.facebook.com/docs/reference/plugins/like/

    Auf dieser Seite kannst du auch andere Layouts wählen. Vielleicht findest du ja dort das, was du suchst.

    @Catridge-Space: Keine Ahnung, ob FB den Paramter braucht. Aber ich denke mal schon, sonst würden die das nicht so lösen. Mit meiner oben beschriebenen Lösung bin ich bisher sehr gut klar gekommen.

    @UpDown: Danke für die Ergänzung!

  5. Danke für die Hilfestellung. Als ich diese Url mit ?fb_xd_fragment= in Google Analytics gesehen hatte, habe ich mich ganz schön erschrocken.

  6. Da braucht man starke Nerven, ich weiß 🙂

  7. Danke für den Beitrag, hab mich auch zunächst einmal über die seltsamen URLs gewundert.

    Bezüglich Duplikate Content:
    Da würde ich mir keine Sorgen machen. DC führt bestenfalls zu Positionsverlusten, und dafür ist hier die Vorraussetzung nicht gegeben.

    Szenario für DC:
    zwei Domains zeigen auf den gleichen Webspace. Irgendwann wird Google die beiden Domains synonym verwenden (das kann man mit der „site:[url]“ Abfrage überprüfen).

    Beide Domainnamen müssen über eigene externe Links verfügen. Nachdem Google die Seiten als synonym erkannt hat, wird der Präsenz die Summe der Links „gutgeschrieben.“

    Jetzt ändern wir in regelmäßigen kurzen Abständen die Topnews oder andere Inhalte auf der Seite. Goolgebot schaut sich die eine Domain an, nach der nächsten News die andere. Jetzt sind die Inhalte nicht mehr gleich. passiert das häufiger, wird Google die beiden Domains nicht mehr als synonym betrachten. Beide Domains müssen nun im Google-Ranking mit ihrem eigenen, reduzierten Satz an Backlinks überleben. Das führt zu Positionsverlusten.

    Workaround: Hauptdomain bestimmen, alle andern Domains in ein anderes Verzeichnis Routen und per 301 weitergeleitet werden.

    Viele Grüße,

    Klaus

  8. So wie du das mit dem DC beschreibst, war es mir bisher nicht bekannt. Mein Kenntnisstand war, dass Google diejenigen Seiten entfernt, die SPÄTER mit DC gefunden werden. Also wenn es Seite A seit 2009 gibt und Seite B im Jahr 2011 plötzlich (teilweise) exakt den selben Inhalt hat.

    Kann aber sein, dass sich das geändert hat. Hast Du dazu eine Quelle bzw. mehr Informationen?

    Das, was du unter Workaround beschreibst, halte ich auch für die beste Lösung, so mache ich das auch in der Regel.

    MfG
    Simon

  9. Danke für die Hilfe habe lange danach gesucht. Merci!

  10. Gerne!

  11. Moin, moin,
    meine Güte, der Bug besteht immer noch!
    Heute bin ich in den Log-Files auf diesen Bug gestoßen, und habe diesen Artikel auf der Suche nach einer Lösung gefunden.
    Werde wohl die IFRAME-Variante wählen.

    Danke!

  12. Gute Wahl 🙂

Hinterlasse einen Kommentar!

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.

»Informationen zum Artikel

Autor: Simon
Datum: 25.03.2011
Zeit: 19:00 Uhr
Kategorien: Internet
Gelesen: 16797x heute: 3x

Kommentare: RSS 2.0.
Diesen Artikel kommentieren oder einen Trackback senden.

»Meta