„Fragmente“ der Codebasis von Yandex sind letzte Woche online durchgesickert. Ähnlich wie Google ist Yandex eine Plattform mit vielen Aspekten wie E-Mail, Karten, einem Taxidienst usw. Das Codeleck enthielt Teile davon.

Gemäß der darin enthaltenen Dokumentation wurde die Codebasis von Yandex 2013 zu einem großen Repository namens Arcadia zusammengefasst. Die durchgesickerte Codebasis ist eine Teilmenge aller Projekte in Arcadia und wir finden darin mehrere Komponenten, die sich auf die Suchmaschine im „Kernel“, „Library ”, „Roboter“, „Suche“ und „ExtSearch“-Archive.

Der Umzug ist völlig beispiellos. Seit den AOL-Suchanfragendaten von 2006 ist etwas so Wesentliches im Zusammenhang mit einer Websuchmaschine nicht mehr öffentlich zugänglich geworden.

Obwohl uns die Daten und viele Dateien fehlen, auf die verwiesen wird, ist dies das erste Beispiel für einen konkreten Einblick in die Funktionsweise einer modernen Suchmaschine auf Codeebene.

Persönlich kann ich nicht darüber hinwegkommen, wie fantastisch das Timing ist, um den Code tatsächlich sehen zu können, wenn ich mein Buch „The Science of SEO“ fertigstelle, in dem ich über Information Retrieval spreche, wie moderne Suchmaschinen tatsächlich funktionieren und wie einen einfachen selbst zu bauen.

Auf jeden Fall habe ich den Code seit letztem Donnerstag analysiert, und jeder Ingenieur wird Ihnen sagen, dass die Zeit nicht ausreicht, um zu verstehen, wie alles funktioniert. Ich vermute also, dass es noch einige weitere Beiträge geben wird, während ich weiter bastele.

Bevor wir einsteigen, möchte ich Ben Wills von Ontolo dafür danken, dass er den Code mit mir geteilt hat, mir die anfängliche Richtung gezeigt hat, wo die guten Sachen sind, und mit mir hin und her gegangen ist, während wir die Dinge entschlüsselt haben. Holen Sie sich hier die Tabelle mit allen Daten, die wir zu den Ranking-Faktoren zusammengestellt haben.

Grüßen Sie auch Ryan Jones dafür, dass er sich eingearbeitet und einige wichtige Ergebnisse mit mir über IM geteilt hat.

OK, machen wir uns an die Arbeit!

Es ist nicht der Code von Google, also warum interessiert uns das?

Einige glauben, dass die Überprüfung dieser Codebasis eine Ablenkung ist und dass es nichts gibt, was sich auf ihre Geschäftsentscheidungen auswirken wird. Ich finde das merkwürdig, wenn man bedenkt, dass dies Leute aus derselben SEO-Community sind, die das CTR-Modell aus den AOL-Daten von 2006 als Industriestandard für die Modellierung über alle Suchmaschinen hinweg für viele Jahre verwendet haben.

Allerdings ist Yandex nicht Google. Dennoch sind die beiden hochmoderne Websuchmaschinen, die weiterhin auf dem neuesten Stand der Technik geblieben sind.

Softwareingenieure beider Unternehmen gehen zu denselben Konferenzen (SIGIR, ECIR usw.) und tauschen Erkenntnisse und Innovationen in den Bereichen Informationsabruf, Verarbeitung/Verständnis natürlicher Sprache und maschinelles Lernen aus. Yandex ist auch in Palo Alto präsent und Google war zuvor in Moskau präsent.

Eine schnelle LinkedIn-Suche deckt einige hundert Ingenieure auf, die bei beiden Unternehmen gearbeitet haben, obwohl wir nicht wissen, wie viele von ihnen tatsächlich bei beiden Unternehmen an der Suche gearbeitet haben.

In einer direkteren Überschneidung nutzt Yandex auch die Open-Source-Technologien von Google, die für Innovationen in der Suche wie TensorFlow, BERT, MapReduce und, in viel geringerem Maße, Protocol Buffers von entscheidender Bedeutung waren.

Obwohl Yandex sicherlich nicht Google ist, ist es auch kein zufälliges Forschungsprojekt, von dem wir hier sprechen. Aus der Überprüfung dieser Codebasis können wir viel darüber lernen, wie eine moderne Suchmaschine aufgebaut ist.

Zumindest können wir uns von einigen veralteten Vorstellungen lösen, die noch immer SEO-Tools durchdringen, wie Text-zu-Code-Verhältnisse und W3C-Konformität oder die allgemeine Überzeugung, dass die 200 Signale von Google einfach 200 einzelne On- und Off-Page-Features sind und keine Klassen von zusammengesetzte Faktoren, die möglicherweise Tausende von Einzelkennzahlen verwenden.

Etwas Kontext zur Architektur von Yandex

Ohne Kontext oder die Fähigkeit, ihn erfolgreich zu kompilieren, auszuführen und schrittweise zu durchlaufen, ist Quellcode sehr schwer zu verstehen.

In der Regel erhalten neue Ingenieure Dokumentation, Walk-Throughs und beteiligen sich an der Paarprogrammierung, um in eine vorhandene Codebasis integriert zu werden. Und es gibt eine begrenzte Onboarding-Dokumentation im Zusammenhang mit der Einrichtung des Build-Prozesses im Dokumentationsarchiv. Allerdings verweist der Code von Yandex durchgängig auch auf interne Wikis, die aber nicht durchgesickert sind und auch die Kommentierung im Code ist recht spärlich.

Glücklicherweise gibt Yandex in seiner öffentlichen Dokumentation einige Einblicke in seine Architektur. Es gibt auch ein paar Patente, die sie in den USA veröffentlicht haben und die helfen, ein wenig Licht ins Dunkel zu bringen. Nämlich:

• Computerimplementiertes Verfahren und System zum Durchsuchen eines invertierten Indexes mit mehreren Buchungslisten
• Rangfolge der Suchergebnisse

Während ich Google für mein Buch recherchiert habe, habe ich durch verschiedene Whitepapers, Patente und Vorträge von Ingenieuren, die auf meiner SEO-Erfahrung beruhen, ein viel tieferes Verständnis der Struktur seiner Ranking-Systeme entwickelt. Ich habe auch viel Zeit damit verbracht, mein Verständnis der allgemeinen Best Practices für den Informationsabruf für Websuchmaschinen zu schärfen. Es überrascht nicht, dass es tatsächlich einige Best Practices und Ähnlichkeiten mit Yandex gibt.

Die Dokumentation von Yandex behandelt ein doppelt verteiltes Crawler-System. Eine für Echtzeit-Crawling namens „Orange Crawler“ und eine für allgemeines Crawling.

In der Vergangenheit soll Google einen Index in drei Buckets geschichtet haben, einen für Echtzeit-Crawling, einen für regelmäßig gecrawlte und einen für selten gecrawlte. Dieser Ansatz gilt als Best Practice im Bereich IR.

Yandex und Google unterscheiden sich in dieser Hinsicht, aber die allgemeine Idee des segmentierten Crawlings, die von einem Verständnis der Aktualisierungshäufigkeit angetrieben wird, gilt.

Hervorzuheben ist, dass Yandex kein separates Rendering-System für JavaScript hat. Sie sagen dies in ihrer Dokumentation, und obwohl sie ein Webdriver-basiertes System für visuelle Regressionstests namens Gemini haben, beschränken sie sich auf textbasiertes Crawlen.

Die Dokumentation behandelt auch eine fragmentierte Datenbankstruktur, die Seiten in einen invertierten Index und einen Dokumentenserver aufteilt.

Genau wie bei den meisten anderen Websuchmaschinen erstellt der Indexierungsprozess ein Wörterbuch, speichert Seiten und platziert dann Daten in den invertierten Index, sodass Bigramme und Trigame und ihre Platzierung im Dokument dargestellt werden.

Dies unterscheidet sich von Google darin, dass sie zu einer phrasenbasierten Indexierung übergegangen sind, was bedeutet, dass N-Gramme vor langer Zeit viel länger sein können als Trigramme.

Das Yandex-System verwendet jedoch auch BERT in seiner Pipeline, sodass an einem bestimmten Punkt Dokumente und Abfragen in Einbettungen umgewandelt und Techniken zur Suche nach dem nächsten Nachbarn für das Ranking verwendet werden.

Beim Ranking-Prozess beginnen die Dinge interessanter zu werden.

Yandex verfügt über eine Ebene namens Metasearch , auf der zwischengespeicherte beliebte Suchergebnisse bereitgestellt werden, nachdem sie die Abfrage verarbeitet haben. Wenn die Ergebnisse dort nicht gefunden werden, wird die Suchanfrage gleichzeitig an eine Reihe von Tausenden verschiedener Maschinen in der Basic Search -Schicht gesendet. Jeder erstellt eine Posting-Liste relevanter Dokumente und sendet sie dann an MatrixNet zurück, die neuronale Netzwerkanwendung von Yandex zur Neubewertung, um die SERP zu erstellen.

Basierend auf Videos, in denen Google-Ingenieure über die Infrastruktur der Suche gesprochen haben, ist dieser Ranking-Prozess der Google-Suche ziemlich ähnlich. Sie sprechen davon, dass sich die Technologie von Google in gemeinsam genutzten Umgebungen befindet, in denen sich verschiedene Anwendungen auf jedem Computer befinden und Jobs je nach verfügbarer Rechenleistung auf diese Computer verteilt werden.

Einer der Anwendungsfälle ist genau dies, die Verteilung von Abfragen auf eine Reihe von Maschinen, um die relevanten Index-Shards schnell zu verarbeiten. Die Berechnung der Buchungslisten ist der erste Ort, an dem wir die Ranking-Faktoren berücksichtigen müssen.

Es gibt 17.854 Ranking-Faktoren in der Codebasis

Am Freitag nach dem Leck teilte der unnachahmliche Martin MacDonald eifrig eine Datei aus der Codebasis mit dem Namen web_factors_info/factors_gen.in. Die Datei stammt aus dem „Kernel“-Archiv im Codebase-Leak und enthält 1.922 Ranking-Faktoren.

Natürlich hat die SEO-Community diese Nummer und diese Datei verwendet, um eifrig Neuigkeiten über die darin enthaltenen Erkenntnisse zu verbreiten. Viele Leute haben die Beschreibungen übersetzt und Tools oder Google Sheets und ChatGPT entwickelt, um die Daten zu verstehen. All dies sind großartige Beispiele für die Macht der Gemeinschaft. Die 1.922 stellt jedoch nur eine von vielen Reihen von Ranking-Faktoren in der Codebasis dar.

Ein tieferer Einblick in die Codebasis zeigt, dass es zahlreiche Ranking-Faktor-Dateien für verschiedene Untergruppen der Abfrageverarbeitungs- und Ranking-Systeme von Yandex gibt.

Wenn wir diese durchkämmen, stellen wir fest, dass es insgesamt 17.854 Ranking-Faktoren gibt. In diesen Ranking-Faktoren sind eine Vielzahl von Metriken enthalten, die sich auf Folgendes beziehen:

• Klicks.
• Verweilzeit.
• Nutzung des Google Analytics-Äquivalents von Yandex, Metrika.

Es gibt auch eine Reihe von Jupyter-Notebooks, die neben denen im Kerncode weitere 2.000 Faktoren haben. Vermutlich stellen diese Jupyter-Notebooks Tests dar, bei denen Ingenieure zusätzliche Faktoren in Betracht ziehen, die der Codebasis hinzugefügt werden können. Auch hier können Sie alle diese Funktionen mit Metadaten überprüfen, die wir aus der gesamten Codebasis unter diesem Link gesammelt haben.

Die Dokumentation von Yandex verdeutlicht weiter, dass es drei Klassen von Ranking-Faktoren gibt: Statische, dynamische und solche, die sich speziell auf die Suche des Benutzers und deren Durchführung beziehen. In ihren eigenen Worten:

In der Codebase sind diese in den Rangfaktorendateien mit den Tags TG_STATIC und TG_DYNAMIC gekennzeichnet. Die suchbezogenen Faktoren haben mehrere Tags wie TG_QUERY_ONLY, TG_QUERY, TG_USER_SEARCH und TG_USER_SEARCH_ONLY.

Während wir potenzielle 18.000 Ranking-Faktoren zur Auswahl aufgedeckt haben, weist die Dokumentation zu MatrixNet darauf hin, dass die Bewertung aus Zehntausenden von Faktoren aufgebaut und basierend auf der Suchanfrage angepasst wird.

Dies weist darauf hin, dass das Ranking-Umfeld sehr dynamisch ist, ähnlich dem Google-Umfeld. Laut Googles Patent „Framework zur Bewertung von Bewertungsfunktionen“ gibt es seit langem etwas Ähnliches, bei dem mehrere Funktionen ausgeführt werden und die besten Ergebnisse zurückgegeben werden.

Wenn man bedenkt, dass die Dokumentation Zehntausende von Ranking-Faktoren referenziert, sollten wir schließlich auch bedenken, dass es viele andere Dateien gibt, auf die im Code verwiesen wird, die im Archiv fehlen. Es ist also wahrscheinlich mehr los, was wir nicht sehen können. Dies wird weiter veranschaulicht, indem die Bilder in der Onboarding-Dokumentation überprüft werden, die andere Verzeichnisse zeigt, die nicht im Archiv vorhanden sind.

Zum Beispiel vermute ich, dass im /semantic-search/-Verzeichnis mehr mit DSSM zu tun hat.

Die anfängliche Gewichtung der Rankingfaktoren

Ich bin zunächst davon ausgegangen, dass die Codebasis keine Gewichtungen für die Ranking-Faktoren hat. Dann war ich schockiert, als ich sah, dass die Datei nav_linear.h im Verzeichnis /search/relevance/ die anfänglichen Koeffizienten (oder Gewichtungen), die mit Ranking-Faktoren verbunden sind, vollständig angezeigt werden.

Dieser Abschnitt des Codes hebt 257 der über 17.000 Ranking-Faktoren hervor, die wir identifiziert haben. ( Hutspitze an Ryan Jones, der diese herausgezogen und mit den Beschreibungen der Ranking-Faktoren abgeglichen hat.)

Zur Verdeutlichung: Wenn Sie an einen Suchmaschinenalgorithmus denken, denken Sie wahrscheinlich an eine lange und komplexe mathematische Gleichung, durch die jede Seite basierend auf einer Reihe von Faktoren bewertet wird. Während dies eine zu starke Vereinfachung ist, ist der folgende Screenshot ein Auszug einer solchen Gleichung. Die Koeffizienten stellen dar, wie wichtig jeder Faktor ist, und die daraus resultierende berechnete Punktzahl wird verwendet, um Auswahlseiten nach Relevanz zu bewerten.

Dass diese Werte fest codiert sind, deutet darauf hin, dass dies sicherlich nicht der einzige Ort ist, an dem das Ranking stattfindet. Stattdessen ist diese Funktion höchstwahrscheinlich dort, wo die anfängliche Relevanzbewertung durchgeführt wird, um eine Reihe von Posting-Listen für jeden Shard zu generieren, der für das Ranking in Betracht gezogen wird. In dem ersten oben aufgeführten Patent sprechen sie darüber als ein Konzept der abfrageunabhängigen Relevanz (QIR), das dann Dokumente einschränkt, bevor sie auf abfragespezifische Relevanz (QSR) überprüft werden.

Die resultierenden Buchungslisten werden dann mit Abfragefunktionen zum Vergleich an MatrixNet übergeben. Obwohl wir die Einzelheiten der nachgelagerten Vorgänge (noch) nicht kennen, ist es dennoch wichtig, diese Gewichtungen zu verstehen, da sie Ihnen die Anforderungen für eine Seite mitteilen, damit sie für den Erwägungssatz infrage kommt.

Das wirft jedoch die nächste Frage auf: Was wissen wir über MatrixNet?

Es gibt neuralen Ranking-Code im Kernel-Archiv und es gibt zahlreiche Verweise auf MatrixNet und „mxnet“ sowie viele Verweise auf Deep Structured Semantic Models (DSSM) in der gesamten Codebasis.

Die Beschreibung eines der FI_MATRIXNET-Ranking-Faktoren zeigt an, dass MatrixNet auf alle Faktoren angewendet wird.

Faktor {

Index: 160

CppName: „FI_MATRIXNET“

Name: „MatrixNet“

Tags: [TG_DOC, TG_DYNAMIC, TG_TRANS, TG_NOT_01, TG_REARR_USE, TG_L3_MODEL_VALUE, TG_FRESHNESS_FROZEN_POOL]

Beschreibung: „MatrixNet wird auf alle Faktoren angewendet – die Formel“

}

Es gibt auch eine Reihe von Binärdateien, die möglicherweise die vortrainierten Modelle selbst sind, aber ich werde mehr Zeit brauchen, um diese Aspekte des Codes zu enträtseln.

Was sofort klar ist, ist, dass es mehrere Ebenen für das Ranking gibt (L1, L2, L3) und dass es eine Auswahl an Ranking-Modellen gibt, die auf jeder Ebene ausgewählt werden können.

Die Datei selection_rankings_model.cpp legt nahe, dass während des gesamten Prozesses auf jeder Ebene unterschiedliche Bewertungsmodelle berücksichtigt werden können. So funktionieren neuronale Netze im Grunde. Jede Ebene ist ein Aspekt, der Operationen abschließt, und ihre kombinierten Berechnungen ergeben die neu eingestufte Liste von Dokumenten, die schließlich als SERP erscheinen. Wenn ich mehr Zeit habe, werde ich mit einem tiefen Einblick in MatrixNet nachfassen. Für diejenigen, die einen kleinen Vorgeschmack benötigen, sehen Sie sich das Patent für die Rangfolge der Suchergebnisse an.

Werfen wir zunächst einen Blick auf einige interessante Ranking-Faktoren.

Top 5 der negativ gewichteten anfänglichen Ranking-Faktoren

Das Folgende ist eine Liste der höchsten negativ gewichteten anfänglichen Rankingfaktoren mit ihren Gewichtungen und einer kurzen Erklärung basierend auf ihren aus dem Russischen übersetzten Beschreibungen.

1. FI_ADV: -0.2509284637 - Dieser Faktor bestimmt, dass Werbung jeglicher Art auf der Seite vorhanden ist und verhängt die schwerste gewichtete Strafe für einen einzelnen Ranking-Faktor.
2. FI_DATER_AGE: -0.2074373667 – Dieser Faktor ist die Differenz zwischen dem aktuellen Datum und dem durch eine Datumsfunktion ermittelten Datum des Dokuments. Der Wert ist 1, wenn das Dokumentdatum gleich heute ist, 0, wenn das Dokument 10 Jahre oder älter ist oder wenn das Datum nicht definiert ist. Dies deutet darauf hin, dass Yandex ältere Inhalte bevorzugt.
3. FI_QURL_STAT_POWER: -0,1943768768 – Dieser Faktor ist die Anzahl der URL-Impressionen in Bezug auf die Abfrage. Es scheint, als wollten sie eine URL herabstufen, die in vielen Suchen auftaucht, um die Vielfalt der Ergebnisse zu fördern.
4. FI_COMM_LINKS_SEO_HOSTS: -0.1809636391 – Dieser Faktor ist der Prozentsatz der eingehenden Links mit „kommerziellem“ Ankertext. Der Faktor fällt auf 0,1 zurück, wenn der Anteil solcher Links mehr als 50 % beträgt, ansonsten wird er auf 0 gesetzt.
5. FI_GEO_CITY_URL_REGION_COUNTRY: -0.168645758 – Dieser Faktor ist die geografische Übereinstimmung des Dokuments und des Landes, aus dem der Benutzer gesucht hat. Dies macht keinen Sinn, wenn 1 bedeutet, dass das Dokument und das Land übereinstimmen.

Zusammenfassend weisen diese Faktoren darauf hin, dass Sie für die beste Punktzahl Folgendes tun sollten:

• Vermeiden Sie Anzeigen.
• Aktualisieren Sie ältere Inhalte, anstatt neue Seiten zu erstellen.
• Stellen Sie sicher, dass die meisten Ihrer Links gebrandeten Ankertext enthalten.

Alles andere in dieser Liste liegt außerhalb Ihrer Kontrolle.

Top 5 der positiv gewichteten anfänglichen Ranking-Faktoren

Um nachzufassen, hier ist eine Liste der am höchsten gewichteten positiven Ranking-Faktoren.

1. FI_URL_DOMAIN_FRACTION: +0.5640952971 – Dieser Faktor ist eine seltsame maskierende Überlappung der Abfrage mit der Domain der URL. Das angegebene Beispiel ist die Tscheljabinsker Lotterie, die als Chelloto abgekürzt wird. Um diesen Wert zu berechnen, findet Yandex drei abgedeckte Buchstaben (che, hel, lot, olo) und sieht, welcher Anteil aller drei Buchstabenkombinationen im Domainnamen enthalten sind.
2. FI_QUERY_DOWNER_CLICKS_COMBO: +0.3690780393 – Die Beschreibung dieses Faktors lautet „geschickt kombiniert aus FRC und Pseudo-CTR“. Es gibt keinen unmittelbaren Hinweis darauf, was FRC ist.
3. FI_MAX_WORD_HOST_CLICKS: +0.3451158835 – Dieser Faktor ist die Anklickbarkeit des wichtigsten Wortes in der Domain. Klicken Sie beispielsweise für alle Suchanfragen, in denen das Wort „Wikipedia“ vorkommt, auf Wikipedia-Seiten.
4. FI_MAX_WORD_HOST_YABAR: +0.3154394573 – Die Faktorbeschreibung lautet „das charakteristischste Suchwort, das der Website entspricht, laut Bar.“ Ich gehe davon aus, dass dies das Schlüsselwort ist, nach dem in der Yandex Toolbar am häufigsten gesucht wird, das mit der Website verknüpft ist.
5. FI_IS_COM: +0.2762504972 – Der Faktor ist, dass die Domain eine .COM ist.

Mit anderen Worten:

• Spielen Sie Wortspiele mit Ihrer Domain.
• Stellen Sie sicher, dass es ein Dotcom ist.
• Ermutigen Sie die Leute, in der Yandex-Leiste nach Ihren Ziel-Keywords zu suchen.
• Fahren Sie fort, Klicks zu generieren.

Es gibt viele unerwartete anfängliche Ranking-Faktoren

Interessanter bei den anfänglich gewichteten Ranking-Faktoren sind die unerwarteten. Das Folgende ist eine Liste von siebzehn Faktoren, die aufgefallen sind.

1. FI_PAGE_RANK: +0.1828678331 – PageRank ist der 17. höchste gewichtete Faktor in Yandex. Sie haben zuvor Links vollständig aus ihrem Ranking-System entfernt, daher ist es nicht allzu schockierend, wie weit unten sie auf der Liste stehen.
2. FI_SPAM_KARMA: +0.00842682963 – Das Spam-Karma ist nach „Antispammer“ benannt und ist die Wahrscheinlichkeit, dass der Host Spam ist; basierend auf Whois-Informationen
3. FI_SUBQUERY_THEME_MATCH_A: +0.1786465163 – Wie genau die Abfrage und das Dokument thematisch übereinstimmen. Dies ist der 19. höchste gewichtete Faktor.
4. FI_REG_HOST_RANK: +0.1567124399 – Yandex hat einen Host- (oder Domain-) Ranking-Faktor.
5. FI_URL_LINK_PERCENT: +0.08940421124 – Verhältnis von Links, deren Ankertext eine URL (statt Text) ist, zur Gesamtzahl der Links.
6. FI_PAGE_RANK_UKR: +0.08712279101 – Es gibt einen bestimmten ukrainischen PageRank
7. FI_IS_NOT_RU: +0.08128946612 – Es ist positiv, wenn die Domain keine .RU ist. Anscheinend vertraut die russische Suchmaschine russischen Seiten nicht.
8. FI_YABAR_HOST_AVG_TIME2: +0.07417219313 – Dies ist die von YandexBar gemeldete durchschnittliche Verweildauer
9. FI_LERF_LR_LOG_RELEV: +0.06059448504 – Dies ist die Linkrelevanz basierend auf der Qualität jedes Links
10. FI_NUM_SLASHES: +0.05057609417 – Die Anzahl der Schrägstriche in der URL ist ein Rankingfaktor.
11. FI_ADV_PRONOUNS_PORTION: -0.001250755075 – Der Anteil der Pronomen auf der Seite.
12. FI_TEXT_HEAD_SYN: -0.01291908335 – Das Vorhandensein von [Abfrage]-Wörtern im Header unter Berücksichtigung von Synonymen
13. FI_PERCENT_FREQ_WORDS: -0.02021022114 – Der Prozentsatz der Anzahl der Wörter, das sind die 200 häufigsten Wörter der Sprache, von der Anzahl aller Wörter des Textes.
14. FI_YANDEX_ADV: -0.09426121965 – Yandex wird mit der Abneigung gegen Anzeigen konkreter und bestraft Seiten mit Yandex-Anzeigen.
15. FI_AURA_DOC_LOG_SHARED: -0.09768630485 – Der Logarithmus der Anzahl der Schindeln (Textbereiche) im Dokument, die nicht eindeutig sind.
16. FI_AURA_DOC_LOG_AUTHOR: -0.09727752961 – Der Logarithmus der Anzahl der Schindeln, auf denen dieser Eigentümer des Dokuments als Autor erkannt wird.
17. FI_CLASSIF_IS_SHOP: -0.1339319854 – Anscheinend wird Yandex Sie weniger lieben, wenn Ihre Seite ein Geschäft ist.

Die wichtigste Erkenntnis aus der Überprüfung dieser ungeraden Ranking-Faktoren und der Reihe der in der Yandex-Codebasis verfügbaren Faktoren ist, dass es viele Dinge gibt, die ein Ranking-Faktor sein könnten.

Ich vermute, dass die von Google gemeldeten „200 Signale“ tatsächlich 200 Signalklassen sind, wobei jedes Signal aus vielen anderen Komponenten zusammengesetzt ist. Ähnlich wie Google Analytics über Dimensionen mit vielen verknüpften Metriken verfügt, verfügt die Google-Suche wahrscheinlich über Klassen von Ranking-Signalen, die aus vielen Merkmalen bestehen.

Yandex scraped Google, Bing, YouTube und TikTok

Die Codebasis zeigt auch, dass Yandex viele Parser für andere Websites und ihre jeweiligen Dienste hat. Für Westler sind die bemerkenswertesten davon diejenigen, die ich in der Überschrift oben aufgelistet habe. Darüber hinaus verfügt Yandex über Parser für eine Vielzahl von Diensten, mit denen ich nicht vertraut war, sowie für die eigenen Dienste.

Was sofort ersichtlich ist, ist, dass die Parser vollständig sind. Jede sinnvolle Komponente der Google SERP wird extrahiert. In der Tat könnte jeder, der erwägt, einen dieser Dienste zu schaben, gut daran tun, diesen Code zu überprüfen.

Es gibt einen anderen Code, der darauf hinweist, dass Yandex einige Google-Daten als Teil der DSSM-Berechnungen verwendet, aber die 83 von Google benannten Ranking-Faktoren selbst machen deutlich, dass Yandex sich ziemlich stark auf die Ergebnisse von Google gestützt hat.

Offensichtlich würde Google niemals den Bing-Schritt ziehen, die Ergebnisse einer anderen Suchmaschine zu kopieren, oder sich für die Berechnung des Kernrankings auf eine verlassen.

Yandex hat Anti-SEO-Obergrenzen für einige Ranking-Faktoren

315-Ranking-Faktoren haben Schwellenwerte, bei denen jeder berechnete Wert darüber hinaus dem System anzeigt, dass dieses Merkmal der Seite überoptimiert ist. 39 dieser Ranking-Faktoren sind Teil der anfänglich gewichteten Faktoren, die verhindern können, dass eine Seite in die Liste der anfänglichen Postings aufgenommen wird. Sie finden diese in der Tabelle, auf die ich oben verlinkt habe, indem Sie nach dem Rangkoeffizienten und der Anti-SEO-Spalte filtern.

Es ist konzeptionell nicht weit hergeholt zu erwarten, dass alle modernen Suchmaschinen Schwellenwerte für bestimmte Faktoren festlegen, die SEOs in der Vergangenheit missbraucht haben, wie z. B. Ankertext, CTR oder Keyword-Stuffing. Beispielsweise soll Bing die missbräuchliche Verwendung der Meta-Keywords als negativen Faktor genutzt haben.

Yandex verstärkt „Vital Hosts“

Yandex verfügt in seiner gesamten Codebasis über eine Reihe von Boosting-Mechanismen. Dies sind künstliche Verbesserungen an bestimmten Dokumenten, um sicherzustellen, dass sie beim Ranking besser abschneiden.

Unten ist ein Kommentar des „Boosting-Assistenten“, der darauf hindeutet, dass kleinere Dateien am besten vom Boosting-Algorithmus profitieren.

Es gibt mehrere Arten von Boosts; Ich habe einen Boost im Zusammenhang mit Links gesehen und ich habe auch eine Reihe von „HandJobBoosts“ gesehen, von denen ich nur annehmen kann, dass sie eine seltsame Übersetzung von „manuellen“ Änderungen sind.

Einer dieser Boosts, den ich besonders interessant fand, bezieht sich auf „Vital Hosts“. Wobei ein wichtiger Host jede angegebene Site sein kann. In den Variablen wird speziell NEWS_AGENCY_RATING erwähnt, was mich zu der Annahme veranlasst, dass Yandex einen Schub gibt, der seine Ergebnisse auf bestimmte Nachrichtenorganisationen verzerrt.

Ohne in die Geopolitik einzusteigen, dies unterscheidet sich sehr von Google, da sie darauf bestanden haben, solche Vorurteile nicht in ihre Ranking-Systeme einzuführen.

Die Struktur des Dokumentenservers

Die Codebasis zeigt, wie Dokumente auf dem Dokumentenserver von Yandex gespeichert werden. Dies ist hilfreich, um zu verstehen, dass eine Suchmaschine nicht einfach eine Kopie der Seite erstellt und in ihrem Cache speichert, sondern verschiedene Merkmale als Metadaten erfasst, um sie dann im nachgelagerten Ranking-Prozess zu verwenden.

Der folgende Screenshot hebt eine Teilmenge dieser besonders interessanten Funktionen hervor. Andere Dateien mit SQL-Abfragen deuten darauf hin, dass der Dokumentenserver fast 200 Spalten hat, darunter DOM-Baum, Satzlängen, Abrufzeit, eine Reihe von Datumsangaben und Antispam-Bewertung, Umleitungskette und ob das Dokument übersetzt ist oder nicht. Die vollständigste Liste, auf die ich gestoßen bin, befindet sich in /robot/rthub/yql/protos/web_page_item.proto.

Das Interessanteste an der Untermenge hier ist die Anzahl der verwendeten Simhashes. Simhashes sind numerische Repräsentationen von Inhalten und werden von Suchmaschinen zum blitzschnellen Vergleich zur Ermittlung von Duplicate Content verwendet. Es gibt verschiedene Fälle im Robot-Archiv, die darauf hinweisen, dass doppelter Inhalt ausdrücklich herabgestuft wird.

Außerdem enthält die Codebasis als Teil des Indexierungsprozesses TF-IDF, BM25 und BERT in ihrer Textverarbeitungspipeline. Es ist nicht klar, warum all diese Mechanismen im Code vorhanden sind, da es eine gewisse Redundanz gibt, sie alle zu verwenden.

Linkfaktoren und Priorisierung

Wie Yandex mit Link-Faktoren umgeht, ist besonders interessant, da sie deren Einfluss zuvor vollständig deaktiviert haben. Die Codebasis verrät auch viele Informationen über Linkfaktoren und wie Links priorisiert werden.

Der Link-Spam-Rechner von Yandex berücksichtigt 89 Faktoren. Alles, was als SF_RESERVED gekennzeichnet ist, ist veraltet. Wo angegeben, finden Sie die Beschreibungen dieser Faktoren in der oben verlinkten Google-Tabelle.

Insbesondere hat Yandex einen Host-Rang und einige Bewertungen, die langfristig zu bestehen scheinen, nachdem eine Website oder Seite einen Ruf als Spam entwickelt hat.

Eine weitere Sache, die Yandex durchführt, ist die Überprüfung von Kopien über eine Domain hinweg und die Feststellung, ob es doppelte Inhalte mit diesen Links gibt. Dies können Linkplatzierungen auf der gesamten Website, Links auf doppelten Seiten oder einfach Links mit demselben Ankertext sein, die von derselben Website stammen.

Dies zeigt, wie trivial es ist, mehrere Links aus derselben Quelle zu rabattieren, und verdeutlicht, wie wichtig es ist, auf eindeutigere Links aus unterschiedlichen Quellen abzuzielen.

Was können wir von Yandex auf das anwenden, was wir über Google wissen?

Diese Frage beschäftigt natürlich immer noch alle. Obwohl es sicherlich viele Analogien zwischen Yandex und Google gibt, kann ehrlich gesagt nur ein Google-Softwareingenieur, der an der Suche arbeitet, diese Frage definitiv beantworten.

Doch das ist die falsche Frage.

Wirklich, dieser Code sollte uns dabei helfen, unser Denken über die moderne Suche zu erweitern. Ein Großteil des kollektiven Verständnisses der Suche basiert auf dem, was die SEO-Community in den frühen 2000er Jahren durch Tests und aus dem Mund von Suchingenieuren gelernt hat, als die Suche weitaus weniger undurchsichtig war. Das hat mit dem rasanten Innovationstempo leider nicht Schritt gehalten.

Erkenntnisse aus den vielen Merkmalen und Faktoren des Yandex-Lecks sollten zu mehr Hypothesen von Dingen führen, die für das Ranking in Google getestet und berücksichtigt werden können. Sie sollten auch mehr Dinge einführen, die durch SEO-Crawling, Linkanalyse und Ranking-Tools analysiert und gemessen werden können.

Beispielsweise könnte ein Maß für die Kosinusähnlichkeit zwischen Abfragen und Dokumenten, die BERT-Einbettungen verwenden, im Vergleich zu Seiten von Mitbewerbern wertvoll sein, um sie zu verstehen, da dies etwas ist, was moderne Suchmaschinen selbst tun.

Ähnlich wie die AOL-Suchprotokolle uns davon abgehalten haben, die Verteilung von Klicks auf SERP zu erraten, bringt uns die Yandex-Codebasis weg vom Abstrakten zum Konkreten, und unsere „es kommt darauf an“-Aussagen können besser qualifiziert werden.

Zu diesem Zweck ist diese Codebasis ein Geschenk, das weitergeben wird. Es ist nur ein Wochenende her und wir haben bereits einige sehr überzeugende Erkenntnisse aus diesem Code gewonnen.

Ich gehe davon aus, dass einige ehrgeizige SEO-Ingenieure mit viel mehr Zeit weiter graben und vielleicht sogar genug von dem ergänzen werden, was fehlt, um dieses Ding zu kompilieren und zum Laufen zu bringen. Ich glaube auch, dass Ingenieure bei den verschiedenen Suchmaschinen auch Innovationen durchgehen und analysieren, von denen sie lernen und die sie ihren Systemen hinzufügen können.

Gleichzeitig verfassen Google-Anwälte wahrscheinlich aggressive Unterlassungserklärungen im Zusammenhang mit all dem Scraping.

Ich bin gespannt auf die Entwicklung unseres Raums, die von den neugierigen Menschen vorangetrieben wird, die diese Gelegenheit maximieren werden.

Aber, hey, wenn es für Sie nicht wertvoll ist, Erkenntnisse aus dem tatsächlichen Code zu erhalten, können Sie gerne wieder etwas Wichtigeres tun, wie z. B. über Subdomains und Unterverzeichnisse zu streiten.