Baidu aus verschiedenen Exits betrachten: Index, Operatoren und Grenzen

Der teuerste Fehler bei der Fernbetrachtung einer regionalen Suchmaschine besteht darin, jeden beobachteten Unterschied der Exit-IP zuzuschreiben. Eine Ergebnisseite entsteht aus mindestens vier unabhängigen Eingaben: was sich gerade im Index der Engine befindet, die geografische Ableitung des Netzes, aus dem die Anfrage kommt, die vom Client gemeldete Sprachpräferenz und die in der Oberfläche ausgewählte Regions- oder Filtereinstellung. Ein Proxy ändert davon nur die zweite.

Bei Baidu ist diese Unterscheidung noch schärfer, denn was die Identität der Engine bestimmt, liegt nicht auf der Netz-, sondern auf der Indexseite: welche Sprachen bei den erfassten Dokumenten überwiegen, welche Quellen auf der Ergebnisseite Platz finden und ob eine Anfrage in diesem Index überhaupt eine Entsprechung hat. Ein Wechsel von einem Exit in Deutschland zu einem in Singapur ändert dieses Gewicht nicht.

Die folgenden Abschnitte bauen der Reihe nach auf: der Weg der Anfrage durch das Netz, die Auswirkung des Index-Unterschieds auf die Messung, die Prüfung des Operatorenverhaltens, die Compliance-Grenzen und die Einrichtung.

Woraus speist sich Baidus Ergebnismenge?

Baidu ist keine Metasuch-Ebene. Die Engine durchsucht das Web mit einem eigenen Crawler, pflegt einen eigenen Index und erzeugt ihr Ranking mit eigenen Signalen. Für die Messung bedeutet das konkret: Ein Ranking, das Sie auf einer anderen Engine sehen, können Sie hier nicht als Referenz verwenden; der Unterschied zwischen beiden Engines ist kein Fehler, sondern der erwartete Zustand. Auch dass eine Anfrage hier ohne Treffer bleibt, liegt meist nicht am Netz, sondern am Index.

Der zweite bestimmende Faktor ist das Sprach- und Quellengewicht. Der Index speist sich überwiegend aus chinesischsprachigen Inhalten; zwischen einer auf Chinesisch formulierten Anfrage und deren türkischer oder englischer Entsprechung sehen Sie große Unterschiede bei Ergebnisanzahl, Blockvielfalt und Tiefe. Bei Anfragen in lateinischer Schrift wird die Ergebnismenge dünner, die Seiten sind auf der zweiten oder dritten Seite rasch erschöpft. Das bedeutet nicht, dass Ihr Exit „nicht funktioniert“, sondern dass die Abdeckung Ihrer Anfragesprache im Index schmal ist.

Der dritte Faktor ist das eigene Ökosystem der Engine. Blöcke aus eigenen Diensten wie Enzyklopädie, Frage-Antwort- und Community-Inhalten nehmen auf der Ergebnisseite deutlich Raum ein. Vorhandensein und Reihenfolge dieser Blöcke variieren je nach Anfragetyp (informationsorientiert, navigierend, kommerzielle Absicht). Beantworten Sie beim Entwurf eines Vergleichs vor der Frage „auf welcher Position stehe ich“ zuerst die Frage „aus welchen Blöcken besteht die Seite“; wenn sich die Blockkomposition ändert, sagt eine Verschiebung in der organischen Position für sich genommen nichts aus.

Die Anfragekette und der Punkt, an dem der Proxy eingreift

Wenn Sie eine Anfrage senden, wird zuerst der Domainname aufgelöst, dann die TCP-Verbindung aufgebaut und der TLS-Handshake durchgeführt. Bei Verwendung eines HTTP Proxy meldet der Client das Ziel in der Form CONNECT ornek.example:443 und der Proxy übernimmt die Auflösung; bei SOCKS5 hängt es vom Client ab, wo die Auflösung erfolgt. Diese Unterscheidung ist wichtiger, als sie wirkt: Erfolgt die Auflösung in Ihrem Netz, wird der Zielname für Ihren lokalen DNS-Server sichtbar, und es wird ein Edge-Knoten in Ihrer Nähe zurückgegeben, während die Verbindung aus dem Land des Proxys aufgebaut wird. Details unter Wo wird DNS bei SOCKS5 aufgeloest und HTTP-CONNECT-Methode.

Die Ergebnisseite selbst stammt nicht von einem einzigen Domainnamen: Oberflächenskripte, Icons und Bildvorschauen werden von separaten Domains für statische Ressourcen ausgeliefert. Wenn Sie eine Regel geschrieben haben, die nur die Hauptdomain abdeckt, öffnet sich die Seite, wirkt aber unvollständig – ein Hinweis darauf, dass nicht der Proxy versagt, sondern Ihr Geltungsbereich zu eng ist.

Wie berücksichtigen Sie den Index-Unterschied in Ihrer Messung?

Der Index-Unterschied verfälscht eine Messung nicht, er verändert, was die Messung misst. Ein Setup, das dies ignoriert, liest ein Ergebnis, das eigentlich sagt „die Abdeckung dieser Anfrage im Index ist schmal“, als „mein Exit ist problematisch“. Halten Sie deshalb in jeder Serie mindestens eine Kontrollanfrage bereit: einen Begriff, von dem Sie wissen, dass er reichlich Treffer liefert und im Index sicher breit vertreten ist. Wenn die Kontrollanfrage normal und Ihre Messanfrage leer zurückkommt, liegt das Problem nicht am Netz.

Die zweite Praxis besteht darin, die Anfrage in zwei Sprachen auszuführen. Wenn Sie die chinesische und die lateinisch geschriebene Fassung desselben Begriffs als getrennte Serien verfolgen, können Sie unterscheiden, ob der beobachtete Unterschied von der Sprache oder vom Exit stammt. Halten Sie den Exit in beiden Serien konstant; wenn Sie Sprache und Exit gleichzeitig ändern, bleibt Ihnen ein nicht interpretierbares Bild.

Die dritte ist die Beweissicherung. Zu sagen „ich habe eine Ergebnisseite gesehen“ ist keine Messung. Halten Sie für jeden Durchlauf den Anfragetext, den Zeitstempel, die Exit-Bezeichnung, das Exit-Land, den Sprach-Header des Clients und die gespeicherte Fassung der Seite fest. Dass dieselbe Anfrage im Abstand von zwei Wochen anders ausfällt, ist normal; wenn Sie nur Ihre Erinnerung haben, können Sie diesen Unterschied niemandem vermitteln. Verwenden Sie auch die geschätzten Angaben zur Ergebnisanzahl nicht wie eine Metrik; diese Werte werden näherungsweise erzeugt und schwanken von Durchlauf zu Durchlauf.

Die Eingaben trennen: Netz, Client, Oberfläche, Index

Um einen Unterschied der richtigen Ursache zuzuschreiben, müssen Sie die Eingaben einzeln aus- und einschalten. Die folgende Tabelle fasst die vier Eingaben zusammen, die eine Suchanfrage prägen, und ob der Proxy jeweils darauf einwirkt. Betrachten Sie diese Zeilen beim Aufbau Ihres Messaufbaus wie Variablen: Variieren Sie immer nur eine gleichzeitig.

Die am häufigsten verwechselte Zeile in der Tabelle ist die Sprachpräferenz. Wenn Sie einen Proxy einsetzen, verlagert sich Ihr Exit in ein anderes Land, Ihr Browser sendet aber weiterhin dieselbe Sprachliste; und die Engine gewichtet diese Liste in den meisten Setups stark. Das ist nahezu immer die Ursache der Klage „Ich habe den Exit gewechselt, die Oberfläche ist immer noch in derselben Sprache“. Ein Ländertest ohne Änderung der Client-Sprache misst nur die Netzseite.

Die Oberflächeneinstellung wird dagegen im Cookie transportiert: Ein zweiter Durchlauf, den Sie ohne ein sauberes Profil starten, erbt die Präferenzen des ersten Durchlaufs. Führen Sie jeden Messdurchlauf in einem separaten, leeren Browserprofil aus.

Aus welchen Eingaben summiert sich der Unterschied im Ergebnis?

Das folgende Schema zeigt mit repräsentativen Gewichtungen, woraus sich der zwischen zwei Exits beobachtete Unterschied zusammensetzt. Es handelt sich nicht um ein Messergebnis, sondern um relative Anteile, die die Entscheidungsreihenfolge beschreiben: Der größte Anteil liegt meist auf der Index- und Sprachseite, während die Netzableitung eine Eingabe ist, die das Ergebnis zwar prägt, aber nicht allein bestimmt.

Praktisch bedeutet das: Wenn der Unterschied in einem Test, bei dem Sie nur das Exit-Land ändern, kleiner ausfällt als erwartet, ist Ihr Setup nicht defekt. Der Unterschied ist klein, weil Sie eine Variable mit geringem Gewicht variiert haben. Wenn Sie einen deutlichen Unterschied sehen möchten, müssen Sie auch die Sprach- und Oberflächeneinstellung passend zu Ihrem Szenario ändern – dies jedoch als eigene Serie durchführen.

Auch die Umkehrung gilt: Dass die Netzseite ein geringes Gewicht hat, macht sie nicht unwichtig. Lokale Blöcke, regionale Dienstlinks und bestimmte Inhaltshinweise reagieren sensibel auf das Netz, aus dem die Anfrage kommt. Die Existenz dieser Blöcke zu verifizieren ist oft ein wertvolleres Ergebnis als die Frage „auf welcher Position stehe ich“ – denn es ist reproduzierbar und per Screenshot belegbar. Auch zu welchem Netz der Exit zu gehören scheint, gehört in dieses Bild: Ob eine Adresse zu einem Rechenzentrum oder zu einem Anschlussnetz gehört, lässt sich am zugehörigen autonomen System ablesen (ASN und IP-Reputation).