dedlfix: Google, POST und Javascript

Hi!

Der folgende Beitrag dient lediglich zur Information und als Diskussionsgrundlage. Eine Frage hab ich nicht.

Golem berichtet: Googles Crawler lernt Ajax. Die Quelle hat der Artikel nicht erwähnt, aber es ist GET, POST, and safely surfacing more of the web aus Googles Webmaster Central Blog.

Gelegentlich tauchen ja Fragen auf, wie:

  • Wann GET und wann POST verwenden?
  • Können Suchmaschinen Javascript?

Der Artikel gibt eine recht deutliche Antwort. GET und POST sollten weiterhin wie vorgesehen verwendet werden: reine Informationsabfragen per GET, Requests mit Nebenwirkungen (Daten werden geändert) per POST. Nun kann es vorkommen, dass GET nicht reicht, weil damit zu wenig Daten übertragen werden können. Dann muss man auf POST umsteigen. Manche Webseiten- oder Programm-Autoren machen es einfach ohne Not falsch und Google hätte aber in beiden Fällen gern den Inhalt gesehen, um ihn ihren (Be)suchern präsentieren zu können. Dass der Google-Bot auch Formular-Requests auslöst, haben sie schon vor längerer Zeit bekanntgegeben (im Google-Blog-Artikel der Verweis zu crawling forms). Wie auch im aktuellen Artikel zu lesen ist, werden diese jedoch nicht wahllos ausgeführt, sondern mit Bedacht, wenn sich der Bot also sicher ist, dass nichts unerwünschtes passiert. Natürlich kann er das nicht in jedem Fall richtig entscheiden, weswegen weiterhin die GET-POST-Aufgabenteilung die bevorzugte und natürlich auch sinnvollste Variante bleibt.

Neu hinzugekommen ist (oder vielleicht hab ich es bisher nur nicht wahrgenommen, vielleicht macht er das ja für GET schon länger), dass der Bot nun auch in Javascript/Ajax "versteckten" POST-Requests folgt. Das muss auch so sein, denn mit zunehmender Verwendung von Ajax-Nachladen muss auch die Suchmaschine darauf reagieren. Natürlich sind Ajax-Request per GET für das reine Informationsabfragen ohne beabsichtigte Nebenwirkungen zu bevorzugen. Doch wie schon gesagt, ist das nicht in jedem Fall möglich und POST findet auch dann Verwendung.

Das heißt also, dass zumindest der Bot von Google auch Javascript auswertet und mitunter sogar POST-Requests auslöst, denn anderweitig kommt er ja nicht an die Informationen zu den Ajax-Requests. Allerdings - um die Befürchtungen etwas zu dämpfen - folgt er nur solchem Javascript-Code, der ohne Nutzereingriff sowieso ausgeführt werden würde, also beispielsweise Aktionen bei onload oder bei document-ready. Zudem wird natürlich das bekannte Bot-Lenk-Dokument robots.txt befolgt.

Lo!

  1. Moin,
    lustig finde ich den ersten Kommentar zum Artikel, dass der GoogleBot jetzt auch Reisen bucht^^

    Meine Frage zu dem Thema wäre: Wenn der GoogleBot Post-Requests auslöst um Inhalte zu crawlen, wie bietet er dann dem suchenden User diesen Inhalt? Denn mit normalen <a href="..." ...>Bla</a> Links lassen sich ja meines Wissens keine Post-Daten mit übermitteln, sodass genau auf diese Seite umgeleitet werden kann.

    Grüße Marco

    1. Hi!

      Meine Frage zu dem Thema wäre: Wenn der GoogleBot Post-Requests auslöst um Inhalte zu crawlen, wie bietet er dann dem suchenden User diesen Inhalt? Denn mit normalen <a href="..." ...>Bla</a> Links lassen sich ja meines Wissens keine Post-Daten mit übermitteln, sodass genau auf diese Seite umgeleitet werden kann.

      Google schreibt, dass sie im Zusammenhang mit Ajax nur solche POST-Requests auslösen, die sowieso ohne weiteres Zutun des Besuchers ausgelöst worden wären. Also, der Besucher/Bot kommt auf eine Seite, die vielleicht erstmal nur ein Grundgerüst ist. Dann läuft Javascript los und löst einen Ajax-Request aus (bevorzugt GET, manchmal eben auch POST). Der Inhalt wird in die Seite eingebunden und kann betrachtet werden. Der Ajax-Request findet für einen Browser auf alle Fälle statt und der Bot ist nun befähigt worden, in ebendiesen automatischen Fällen denselben Inhalt wie ein Browser zu sehen. Die Suchergebnisse werden wie bisher einfache Links bleiben und auf die Seite mit dem Grundgerüst verweisen, nicht jedoch das Ajax-Request-Ziel direkt verlinken, denn das wäre auch sonst nicht sinnvoll, weil dessen Antwort in der Regel nur unbehauene Daten sind, die erst durch die Einbettung in eine Seite sinnvoll zu betrachten sind.

      Lo!

      1. Moin,

        Der Ajax-Request findet für einen Browser auf alle Fälle statt und der Bot ist nun befähigt worden, in ebendiesen automatischen Fällen denselben Inhalt wie ein Browser zu sehen.

        Ah alles klar. In dem Artikel ist das IMHO nicht so rausgekommen. AJAX kann ja weit mehr als autmatisch beim Seitenaufruf einige Daten laden.

        Die Suchergebnisse werden wie bisher einfache Links bleiben und auf die Seite mit dem Grundgerüst verweisen, nicht jedoch das Ajax-Request-Ziel direkt verlinken, denn das wäre auch sonst nicht sinnvoll, weil dessen Antwort in der Regel nur unbehauene Daten sind, die erst durch die Einbettung in eine Seite sinnvoll zu betrachten sind.

        Aber nochmal was zum Verständnis: Der AJAX-Inhalt ist ja AJAX-Inhalt, weil er dynamisch geladen wird. Hat Google dann nicht ein Problem mit veralteten Indexierungsdaten? Weil der Crawler kann ja nicht aller 10 Minuten nachsehen, ob sich bei einer noname-AJAX-Seite der Startseitencontent verändert hat.
        Wenn ich mir jetzt eine Seite programmiere, die per AJAX alle halbe Stunde einen anderen Newsbeitrag lädt, woher weiß Google das, und bietet dann dem Sucher keine unnützen Infos?

        Grüße Marco

        1. Hi,

          Wenn ich mir jetzt eine Seite programmiere, die per AJAX alle halbe Stunde einen anderen Newsbeitrag lädt, woher weiß Google das, und bietet dann dem Sucher keine unnützen Infos?

          Gegenfrage: (Woher) weiß Google das bei Ressourcen, die nicht per AJAX, sondern auf herkömmlichem Wege geladen werden?

          MfG ChrisB

          --
          RGB is totally confusing - I mean, at least #C0FFEE should be brown, right?
          1. Moin,

            Gegenfrage: (Woher) weiß Google das bei Ressourcen, die nicht per AJAX, sondern auf herkömmlichem Wege geladen werden?

            Naja, das weiß man nicht, aber bei AJAX ist es ja sehr viel wahrscheinlicher, da wenn die Inhalte nur in größeren Zeitabständen geändert würden, man kein AJAX bräuchte... Oder seh ich das falsch?

            Grüße Marco

            1. Hi!

              Gegenfrage: (Woher) weiß Google das bei Ressourcen, die nicht per AJAX, sondern auf herkömmlichem Wege geladen werden?
              Naja, das weiß man nicht, aber bei AJAX ist es ja sehr viel wahrscheinlicher, da wenn die Inhalte nur in größeren Zeitabständen geändert würden, man kein AJAX bräuchte... Oder seh ich das falsch?

              Theoretisch ist anders als praktisch (und manchmal alles andere als praktisch). Manche setzen Ajax nicht der Aktualität wegen sondern für das Erlebnis des Besuchers ein.

              Irgendwann gab es mal eine News-Meldung, die von der Telekom berichtete, das sie ein Framework für die Seitenerstellung erstellt habe. Vielleicht hatte sie es auch zur Benutzung freigegeben, ich weiß es nicht mehr, ist für die Story auch nicht weiter relevant. Jedenfalls stand in der Meldung, dass das Framework kann, dass von Seiten erstmal das Gerüst und als Inhalt nur ein Wartedingsbums ausgeliefert wird. Der Inhalt kommt dann hinterhergekleckert. Man macht dies, um angeblich die Antwortgeschwindigkeit auf Klicks zu erhöhen. Der Besucher sieht also recht zeitnah eine Reaktion auf seinen Click, aber der eigentliche Inhalt ist noch gar nicht erstellt, weil dazu eine etwas langsamere Datenbank oder ähnliches Backend befragt werden muss. Wenn die sich ausgekäst hat, kommt endlich der Nutzinhalt auf den Schirm. Die Idee ist gar nicht mal schlecht, aber die insgesamte Ausführung ist es. Man hat zwar nun recht fix eine rohe Seite, aber auf den Inhalt muss man trotzdem warten - und das teilweise sehr lange. Als ich diese Meldung las, war mir klar, warum der Seitenaufbau so ist, wie ich ihn vorher bereits beobachtete (irgendwo in dem Bereich, in dem man Daten zu seinem Vertrag und Anschluss einsehen kann). Nicht nur, dass die Server (vielleicht auch nur zu Spitzenzeiten) dermaßen überlastet sind, dass die Wartezeit mein Besuchserlebnis dämpft - um es mal stark untertrieben auszudrücken - fühle ich mich nun erst recht verarscht. Man muss weiterhin warten, aber bekommt schonmal ein nichtssagendes Trostbonbon zur Ansicht. Hätten sie mal lieber in skalierende Hardware statt Entwicklungskosten investiert. Lange Rede usw. ... die dort abzufragenden Daten sind sowieso nicht Google-relevant, aber das ist ein Beispiel für über Ajax nachgeladene nahezu starre Daten. Und es gibt sicherlich Anwendungsfälle, wo öffentliche Daten derart nachgeladen werden. Achja, die Telekom ist nicht der einzige Provider, der das so macht, auch bei der Mobilcom-Debitel sehe ich dieses Prinzip.

              Lo!

              1. Die Idee ist gar nicht mal schlecht, aber die insgesamte Ausführung ist es. Man hat zwar nun recht fix eine rohe Seite, aber auf den Inhalt muss man trotzdem warten - und das teilweise sehr lange.

                Ich hab sowas bei "großer österreichischer Konzern" umgesetzt - da wird zuerst die Website gelanden mit einem schönen großen Bild im Header - die ist auch recht fix da. Sobald das alles komplett ist, beginnt ein XHR herumzurödeln und läd zeug nach, welches zwar nett zum Anschaun ist, aber nicht primär benötigt wird, wenn man jetzt z.B. von einer Suchmaschine kommt.

                z.B. wird das statische Bild im Header durch eine Slideshow ersetzt. Weitere themenrelevante Artikel werden im Sidebar nachgeladen usw.

                Das hat zur Folge, dass das eigentliche Dokument mit Fließtext auch auf Smartphones extrem schnell geladen wird und und zusätzliche Dinge, nach und nach (oder auch garnicht, wenn das Gerät sie sowieso nicht (sinnvoll) unterstützt) daherkommen.

                1. Hi!

                  Ich hab sowas bei "großer österreichischer Konzern" umgesetzt - da wird zuerst die Website gelanden mit einem schönen großen Bild im Header - die ist auch recht fix da. Sobald das alles komplett ist, beginnt ein XHR herumzurödeln und läd zeug nach, welches zwar nett zum Anschaun ist, aber nicht primär benötigt wird, wenn man jetzt z.B. von einer Suchmaschine kommt.
                  Das hat zur Folge, dass das eigentliche Dokument mit Fließtext auch auf Smartphones extrem schnell geladen wird und und zusätzliche Dinge, nach und nach (oder auch garnicht, wenn das Gerät sie sowieso nicht (sinnvoll) unterstützt) daherkommen.

                  Das ist auch einer der guten Anwendungsfälle für diese Vorgehensweise. Aber wenn meine Hauptdaten ewig braucht, um aus dem Backend ermittelt zu werden, nützt mir das nur ganz gering als ein kleines bisschen Vertröst-Feedback.

                  Lo!

        2. Hi!

          Der Ajax-Request findet für einen Browser auf alle Fälle statt und der Bot ist nun befähigt worden, in ebendiesen automatischen Fällen denselben Inhalt wie ein Browser zu sehen.
          Ah alles klar. In dem Artikel ist das IMHO nicht so rausgekommen. AJAX kann ja weit mehr als autmatisch beim Seitenaufruf einige Daten laden.

          Deswegen verwies ich auch noch auf den im Golem-Artikel nicht verlinkten Google-Blog-Eintrag, denn da sind Beispiele angegeben.

          Der AJAX-Inhalt ist ja AJAX-Inhalt, weil er dynamisch geladen wird. Hat Google dann nicht ein Problem mit veralteten Indexierungsdaten?

          Nicht mehr und nicht weniger als mit Inhalten, die auf Nicht-Ajax-Seiten stehen und sich ständig ändern.

          Weil der Crawler kann ja nicht aller 10 Minuten nachsehen, ob sich bei einer noname-AJAX-Seite der Startseitencontent verändert hat.

          Wenn die noname ist, ist sie vielleicht weniger interessant. Die Besuchshäufigkeit des Bots hängt unter anderem auch von der Häufigkeit der Änderungen ab. Die Hauptseite einer Zeitung wird sicher mehrfach am Tag Besuch bekommen (schon wegen Google News), die Seite im Archiv eher seltener.

          Wenn ich mir jetzt eine Seite programmiere, die per AJAX alle halbe Stunde einen anderen Newsbeitrag lädt, woher weiß Google das, und bietet dann dem Sucher keine unnützen Infos?

          Das bekommt der Bot irgendwann mit. Wenn zwischen seinen Besuchen sich etwas ändert, erhöht er die Frequenz.

          Lo!