37 GB Traffic an einem Tag?

[Michael Schröpl]

Hi Thomas,

Wobei %2C für , steht. Naja, der Crawler "klickt" auf "schließen", udn dann wird an alle Links die ID der geschlossenen Threads gehängt, und das äändert sich natürlich bei jedem Schließen eine s Threads, udn zwar für alle Links. so hat er sich halt verirrt. Ist halt beta, nichts desto trotz sollte man die meta-Anageb zu robots anpassen damit wenigstens sowas vermieden wird.
Wenn der Crawler klicken "muss", wobei ich auch nciht weiss, was er schließen soll, es sei den ... er macht für jede Posting ein eigenes Fenster auf, aber das kann nciht sein, denn dann ist es nicht beta sonder ein fehl-Software.

falls ich das Problem richtig verstanden habe, dann fängt der Crawler damit an, aus der Forums-Hauptdatei sämtliche Links zu extrahieren, weil er ja in die entsprechende Richtung weiter traversieren will. Bei denjenigen Links, welche tatsächlich zu Threads führen, ist das auch die richtige Entscheidung; bei denjenigen Links, welche nur zu einer inhaltlich reduzierten Darstellung derselben Hauptdatei führen (eben das "Schließen" eines threads), ist das keine gute Idee, denn aus der entsprechenden Seite wird er zwar eine Information gewinnen können, die er noch nicht hat, nicht aber eine, die ihn "inhaltlich weiterbringt". Und bei n aktiven Threads gibt es 2^n mögliche Ausblendungs-Zustände ... entsprechend explodiert dann die Anzahl der Anforderungen auf "customized" Hauptdatei-Ansichten, die letztlich alle wiederum nur zu denjenigen Threads führen, welche der Crawler alle schon aus der vollständigen Hauptansicht kennt.
(Von benutzerspezifischen Restriktionen in der /my/-Ansicht reden wir besser gar nicht - diese ist glücklicherweise auch hinter der Authentifizierungs-Anforderung verborgen, da kommt ein Crawler nicht ran.)

Sämtliche aufgrund von Benutzereinstellungen oder -interaktionen dynamisch entstandenen Varianten der Forums-Hauptdatei sollten für Suchmaschinen-Robots also nicht ansprechbar sein.
Da das entsprechende Forums-Skript sehr wohl weiß, ob es die vollständige aktuelle Hauptdatei ausgibt oder eine wie auch immer reduzierte Form, könnte sie dies durch entsprechende <meta>-Tags innerhalb der generierten HTML-Seite zum Ausdruck bringen ... das ist aber zu spät, in diesem Moment hat der Crawler bereits das Unglück angerichtet. Das entsprechende URL-Muster mit Query-Strings, welche auf solche Restriktionen hinweisen, müßte also in der "robots.txt" definiert sein - nur dann kann der Crawler diese reduzierten Hauptdatei-Ansichten anders behandeln als die vollständige Ansicht.

Falls eine Suchmaschine sich an solche Angaben nicht gebunden fühlt, dann wäre es zumindest aus dieser Perspektive sinnvoll, ihr Seiten mit "Links verschiedener Klassen" anzubieten. Beispielsweise wäre es - nur aus der Suchmaschinen-Perspektive - sinnvoll, wenn funktionell einschränkende Links über JavaScript realisiert würden, während Links auf Threads aus normalem TML-Code bestehen würden ... ja, ich weiß, daß das Forum dann von JavaScript abhängig würde und daß wir diesen Preis nicht bezahlen wollen.
Aber bloß mal um die Idee weiter zu denken: Die Auslieferung der entsprechenden Seite erfolgt durch eine serverseitige Intelligenz. Diese könnte über eine automatische Auswertung des HTTP-UserAgent oder sonstiger, für gängige Browser übliche HTTP-Header eine Unterscheidung zwischen Dialog-Clients und Suchmaschinen-Crawler vornehmen und letzteren entsprechend modifizierte Seiten ausliefern. Ja, auch das ist ein Problem, weil die Unterscheidung angesichts von UserAgents wie "Ferrari 352" nur mit aufwändiger manueller Konfiguration halbwegs in den Griff zu bekommen ist ... aber es gibt sehr wohl Firmen, die genau so etwas tun (einige sogar, um Google damit zu spammen - wir hatten hier im Forum schon Threads zu diesem Thema).
Fakt ist, daß es fehlerhaft arbeitende Software gibt und daß diese entsprechende Wirkungen auf ein Web-Portal haben _kann_. Die Frage bleibt, auf welcher Ebene eine Reaktion erfolgen könnte. Die oben skizzierten Ideen versuchen, auf der Ebene von HTML bzw. HTTP zu agieren; alternativ wäre beispielsweise denkbar, einen modifizierten Webserver einzusetzen, welcher den Traffic pro Tag und Client-IP-Adresse limitiert (wobei "IP-Adresse" wahrscheinlich nicht ausreichen wird - vielleicht das entsprechende 3-Byte-IP-Adreß-Segment?). In diesem Fall würde der Server nicht zwischen einem absichtlichen DoS-Angriff und einem irrelaufenden Crawler unterscheiden - aber wäre das so schlimm?

Hm ... ich mag Probleme, zu denen es keine einfachen Lösungen gibt. ;-)

Viele Grüße
      Michael