Des « fragments » de la base de code de Yandex ont été divulgués en ligne la semaine dernière. Tout comme Google, Yandex est une plate-forme avec de nombreux aspects tels que le courrier électronique, les cartes, un service de taxi, etc. La fuite de code comportait des morceaux de tout cela.

Selon la documentation qui s'y trouve, la base de code de Yandex a été repliée dans un grand référentiel appelé Arcadia en 2013. La base de code divulguée est un sous-ensemble de tous les projets d'Arcadia et nous y trouvons plusieurs composants liés au moteur de recherche dans le "Kernel", "Library". », « Robot », « Search » et « ExtSearch ».

Le déménagement est totalement inédit. Jamais depuis les données de requête de recherche AOL de 2006, quelque chose d'aussi matériel lié à un moteur de recherche Web n'est entré dans le domaine public.

Bien qu'il nous manque les données et de nombreux fichiers référencés, il s'agit du premier exemple d'un aperçu tangible du fonctionnement d'un moteur de recherche moderne au niveau du code.

Personnellement, je ne peux pas comprendre à quel point le moment est fantastique pour pouvoir réellement voir le code alors que je termine mon livre "La science du référencement" où je parle de la récupération d'informations, du fonctionnement réel des moteurs de recherche modernes et de la façon dont pour en construire un simple vous-même.

Quoi qu'il en soit, j'analyse le code depuis jeudi dernier et n'importe quel ingénieur vous dira que ce n'est pas assez de temps pour comprendre comment tout fonctionne. Donc, je soupçonne qu'il y aura plusieurs autres messages pendant que je continue à bricoler.

Avant de nous lancer, je tiens à féliciter Ben Wills d'Ontolo pour avoir partagé le code avec moi, m'avoir indiqué la direction initiale de l'endroit où se trouvent les bonnes choses et avoir fait des allers-retours avec moi pendant que nous déchiffrions les choses. N'hésitez pas à saisir la feuille de calcul avec toutes les données que nous avons compilées sur les facteurs de classement ici.

Merci également à Ryan Jones d'avoir creusé et partagé certaines découvertes clés avec moi par messagerie instantanée.

OK, occupons-nous !

Ce n'est pas le code de Google, alors pourquoi s'en soucier ?

Certains pensent que l'examen de cette base de code est une distraction et que rien n'aura d'impact sur la façon dont ils prennent des décisions commerciales. Je trouve cela curieux étant donné que ce sont des personnes de la même communauté SEO qui ont utilisé le modèle CTR des données AOL 2006 comme norme de l'industrie pour la modélisation sur n'importe quel moteur de recherche pendant de nombreuses années.

Cela dit, Yandex n'est pas Google. Pourtant, les deux sont des moteurs de recherche Web à la pointe de la technologie qui sont restés à la pointe de la technologie.

Les ingénieurs logiciels des deux sociétés assistent aux mêmes conférences (SIGIR, ECIR, etc.) et partagent leurs découvertes et innovations en matière de recherche d'informations, de traitement/compréhension du langage naturel et d'apprentissage automatique. Yandex est également présent à Palo Alto et Google était auparavant présent à Moscou.

Une recherche rapide sur LinkedIn révèle quelques centaines d'ingénieurs qui ont travaillé dans les deux sociétés, bien que nous ne sachions pas combien d'entre eux ont réellement travaillé sur la recherche dans les deux sociétés.

Dans un chevauchement plus direct, Yandex utilise également les technologies open source de Google qui ont été essentielles aux innovations dans la recherche comme TensorFlow, BERT, MapReduce et, dans une bien moindre mesure, Protocol Buffers.

Ainsi, même si Yandex n'est certainement pas Google, ce n'est pas non plus un projet de recherche aléatoire dont nous parlons ici. Nous pouvons en apprendre beaucoup sur la façon dont un moteur de recherche moderne est construit en examinant cette base de code.

À tout le moins, nous pouvons nous détromper de certaines notions obsolètes qui imprègnent encore les outils de référencement comme les ratios texte-code et la conformité W3C ou la croyance générale selon laquelle les 200 signaux de Google sont simplement 200 fonctionnalités individuelles sur et hors page plutôt que des classes de facteurs composites qui utilisent potentiellement des milliers de mesures individuelles.

Un peu de contexte sur l'architecture de Yandex

Sans contexte ni capacité à le compiler, l'exécuter et le parcourir avec succès, le code source est très difficile à comprendre.

En règle générale, les nouveaux ingénieurs obtiennent de la documentation, des visites guidées et s'engagent dans la programmation en binôme pour s'intégrer à une base de code existante. De plus, il existe une documentation d'intégration limitée liée à la configuration du processus de construction dans l'archive docs. Cependant, le code de Yandex fait également référence à des wikis internes, mais ceux-ci n'ont pas fui et les commentaires dans le code sont également assez rares.

Heureusement, Yandex donne un aperçu de son architecture dans sa documentation publique. Il y a aussi quelques brevets qu'ils ont publiés aux États-Unis qui aident à faire la lumière. À savoir:

• Procédé et système mis en oeuvre par ordinateur pour rechercher un index inversé comportant une pluralité de listes de publications
• Classement des résultats de recherche

Au cours de mes recherches sur Google pour mon livre, j'ai développé une compréhension beaucoup plus approfondie de la structure de ses systèmes de classement grâce à divers livres blancs, brevets et entretiens d'ingénieurs contre mon expérience SEO. J'ai également passé beaucoup de temps à affiner ma compréhension des meilleures pratiques générales de recherche d'informations pour les moteurs de recherche Web. Il n'est pas surprenant qu'il existe en effet des pratiques exemplaires et des similitudes en jeu avec Yandex.

La documentation de Yandex traite d'un système de chenilles à double distribution. Un pour l'exploration en temps réel appelé "Orange Crawler" et un autre pour l'exploration générale.

Historiquement, Google aurait eu un index stratifié en trois compartiments, un pour héberger l'exploration en temps réel, un pour l'exploration régulière et un pour l'exploration rare. Cette approche est considérée comme une pratique exemplaire en RI.

Yandex et Google diffèrent à cet égard, mais l'idée générale d'une exploration segmentée motivée par une compréhension de la fréquence de mise à jour est valable.

Une chose qui mérite d'être signalée est que Yandex n'a pas de système de rendu séparé pour JavaScript. Ils le disent dans leur documentation et, bien qu'ils disposent d'un système basé sur Webdriver pour les tests de régression visuelle appelé Gemini, ils se limitent à l'exploration textuelle.

La documentation traite également d'une structure de base de données fragmentée qui décompose les pages en un index inversé et un serveur de documents.

Comme la plupart des autres moteurs de recherche Web, le processus d'indexation crée un dictionnaire, met les pages en cache, puis place les données dans l'index inversé de sorte que les bigrammes et les trigames et leur placement dans le document soient représentés.

Cela diffère de Google en ce sens qu'ils sont passés à l'indexation basée sur les phrases, ce qui signifie des n-grammes qui peuvent être beaucoup plus longs que les trigrammes il y a longtemps.

Cependant, le système Yandex utilise également BERT dans son pipeline, donc à un moment donné, les documents et les requêtes sont convertis en intégrations et des techniques de recherche du voisin le plus proche sont utilisées pour le classement.

Le processus de classement est l'endroit où les choses commencent à devenir plus intéressantes.

Yandex a une couche appelée Metasearch où les résultats de recherche populaires mis en cache sont servis après avoir traité la requête. Si les résultats ne s'y trouvent pas, la requête de recherche est envoyée simultanément à une série de milliers de machines différentes dans la couche de recherche de base . Chacun crée une liste de publication des documents pertinents, puis la renvoie à MatrixNet, l'application de réseau neuronal de Yandex pour le reclassement, afin de créer le SERP.

Basé sur des vidéos dans lesquelles les ingénieurs de Google ont parlé de l'infrastructure de la recherche, ce processus de classement est assez similaire à la recherche Google. Ils parlent de la technologie de Google dans des environnements partagés où diverses applications sont installées sur chaque machine et où les tâches sont réparties sur ces machines en fonction de la disponibilité de la puissance de calcul.

L'un des cas d'utilisation est exactement celui-ci, la distribution des requêtes à un assortiment de machines pour traiter rapidement les fragments d'index pertinents. Le calcul des listes d'affichage est le premier endroit où nous devons considérer les facteurs de classement.

Il y a 17 854 facteurs de classement dans la base de code

Le vendredi suivant la fuite, l'inimitable Martin MacDonald a partagé avec empressement un fichier de la base de code appelé web_factors_info/factors_gen.in. Le fichier provient de l'archive "Kernel" dans la fuite de la base de code et comporte 1 922 facteurs de classement.

Naturellement, la communauté SEO a couru avec ce numéro et ce fichier pour diffuser avec impatience les nouvelles des informations qu'il contient. De nombreuses personnes ont traduit les descriptions et construit des outils ou Google Sheets et ChatGPT pour donner un sens aux données. Ce sont tous d'excellents exemples du pouvoir de la communauté. Cependant, le 1 922 ne représente qu'un des nombreux ensembles de facteurs de classement dans la base de code.

Une plongée plus approfondie dans la base de code révèle qu'il existe de nombreux fichiers de facteurs de classement pour différents sous-ensembles des systèmes de traitement et de classement des requêtes de Yandex.

En les parcourant, nous constatons qu'il existe en fait 17 854 facteurs de classement au total. Ces facteurs de classement comprennent une variété de mesures liées à :

• Clics.
• Temps de séjour.
• Tirer parti de l'équivalent Google Analytics de Yandex, Metrika.

Il existe également une série de blocs-notes Jupyter qui ont 2 000 facteurs supplémentaires en plus de ceux du code principal. Vraisemblablement, ces cahiers Jupyter représentent des tests où les ingénieurs envisagent des facteurs supplémentaires à ajouter à la base de code. Encore une fois, vous pouvez passer en revue toutes ces fonctionnalités avec les métadonnées que nous avons collectées à travers la base de code sur ce lien.

La documentation de Yandex précise en outre qu'ils ont trois classes de facteurs de classement : statiques, dynamiques et ceux liés spécifiquement à la recherche de l'utilisateur et à la manière dont elle a été effectuée. Dans leurs propres mots :

Dans la base de code, ceux-ci sont indiqués dans les fichiers de facteurs de rang avec les balises TG_STATIC et TG_DYNAMIC. Les facteurs liés à la recherche ont plusieurs balises telles que TG_QUERY_ONLY, TG_QUERY, TG_USER_SEARCH et TG_USER_SEARCH_ONLY.

Bien que nous ayons découvert un potentiel de 18 000 facteurs de classement parmi lesquels choisir, la documentation relative à MatrixNet indique que la notation est construite à partir de dizaines de milliers de facteurs et personnalisée en fonction de la requête de recherche.

Cela indique que l'environnement de classement est très dynamique, similaire à celui de Google. Selon le brevet "Framework for evaluation scoring functions" de Google, ils ont depuis longtemps quelque chose de similaire où plusieurs fonctions sont exécutées et le meilleur ensemble de résultats est renvoyé.

Enfin, étant donné que la documentation fait référence à des dizaines de milliers de facteurs de classement, nous devons également garder à l'esprit qu'il existe de nombreux autres fichiers référencés dans le code qui manquent dans l'archive. Donc, il se passe probablement plus que nous ne pouvons pas voir. Ceci est encore illustré en examinant les images dans la documentation d'intégration qui montre d'autres répertoires qui ne sont pas présents dans les archives.

Par exemple, je soupçonne qu'il y a plus de liens avec le DSSM dans le répertoire /semantic-search/ .

La pondération initiale des facteurs de classement

J'ai d'abord opéré en supposant que la base de code n'avait pas de poids pour les facteurs de classement. Ensuite, j'ai été choqué de voir que le fichier nav_linear.h dans le répertoire /search/relevance/ présente les coefficients initiaux (ou poids) associés aux facteurs de classement en plein affichage.

Cette section du code met en évidence 257 des plus de 17 000 facteurs de classement que nous avons identifiés. ( Chapeau à Ryan Jones pour les avoir tirés et les avoir alignés avec les descriptions des facteurs de classement.)

Pour plus de clarté, lorsque vous pensez à un algorithme de moteur de recherche, vous pensez probablement à une équation mathématique longue et complexe par laquelle chaque page est notée en fonction d'une série de facteurs. Bien qu'il s'agisse d'une simplification excessive, la capture d'écran suivante est un extrait d'une telle équation. Les coefficients représentent l'importance de chaque facteur et le score calculé qui en résulte est ce qui serait utilisé pour évaluer la pertinence des pages de sélecteur.

Ces valeurs étant codées en dur suggèrent que ce n'est certainement pas le seul endroit où le classement se produit. Au lieu de cela, cette fonction est très probablement là où la notation de pertinence initiale est effectuée pour générer une série de listes de publications pour chaque fragment pris en compte pour le classement. Dans le premier brevet répertorié ci-dessus, ils en parlent comme d'un concept de pertinence indépendante de la requête (QIR) qui limite ensuite les documents avant de les examiner pour la pertinence spécifique à la requête (QSR).

Les listes d'affichage résultantes sont ensuite transmises à MatrixNet avec des fonctionnalités de requête à comparer. Ainsi, bien que nous ne connaissions pas (encore) les spécificités des opérations en aval, ces pondérations sont toujours utiles à comprendre car elles vous indiquent les conditions requises pour qu'une page soit éligible à l'ensemble de considération.

Cependant, cela soulève la question suivante : que savons-nous de MatrixNet ?

Il y a du code de classement neuronal dans l'archive du noyau et il y a de nombreuses références à MatrixNet et "mxnet" ainsi que de nombreuses références aux modèles sémantiques structurés profonds (DSSM) dans toute la base de code.

La description d'un des facteurs de classement FI_MATRIXNET indique que MatrixNet est appliqué à tous les facteurs.

Facteur {

Indice : 160

CppName : "FI_MATRIXNET"

Nom : "MatrixNet"

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

Description : "MatrixNet est appliqué à tous les facteurs - la formule"

}

Il y a aussi un tas de fichiers binaires qui peuvent être les modèles pré-formés eux-mêmes, mais cela va me prendre plus de temps pour démêler ces aspects du code.

Ce qui est immédiatement clair, c'est qu'il existe plusieurs niveaux de classement (L1, L2, L3) et qu'il existe un assortiment de modèles de classement qui peuvent être sélectionnés à chaque niveau.

Le fichier selected_rankings_model.cpp suggère que différents modèles de classement peuvent être pris en compte à chaque couche tout au long du processus. C'est essentiellement ainsi que fonctionnent les réseaux de neurones. Chaque niveau est un aspect qui complète les opérations et leurs calculs combinés donnent la liste reclassée des documents qui apparaît finalement comme un SERP. Je poursuivrai avec une plongée approfondie sur MatrixNet quand j'aurai plus de temps. Pour ceux qui ont besoin d'un aperçu, consultez le brevet de classement des résultats de recherche.

Pour l'instant, examinons quelques facteurs de classement intéressants.

Top 5 des facteurs de classement initial pondérés négativement

Ce qui suit est une liste des facteurs de classement initiaux les plus pondérés négativement avec leurs poids et une brève explication basée sur leurs descriptions traduites du russe.

1. FI_ADV : -0,2509284637 -Ce facteur détermine qu'il y a de la publicité de toute sorte sur la page et inflige la pénalité pondérée la plus lourde pour un seul facteur de classement.
2. FI_DATER_AGE : -0,2074373667 – Ce facteur est la différence entre la date actuelle et la date du document déterminée par une fonction de date. La valeur est 1 si la date du document est la même qu'aujourd'hui, 0 si le document date de 10 ans ou plus, ou si la date n'est pas définie. Cela indique que Yandex a une préférence pour les contenus plus anciens.
3. FI_QURL_STAT_POWER : -0,1943768768 : ce facteur correspond au nombre d'impressions d'URL en rapport avec la requête. Il semble qu'ils veuillent rétrograder une URL qui apparaît dans de nombreuses recherches pour promouvoir la diversité des résultats.
4. FI_COMM_LINKS_SEO_HOSTS : -0,1809636391 - Ce facteur est le pourcentage de liens entrants avec un texte d'ancrage "commercial". Le facteur revient à 0,1 si la proportion de ces liens est supérieure à 50 %, sinon, il est défini sur 0.
5. FI_GEO_CITY_URL_REGION_COUNTRY : -0,168645758 – Ce facteur est la coïncidence géographique du document et du pays à partir duquel l'utilisateur a effectué la recherche. Celui-ci n'a pas vraiment de sens si 1 signifie que le document et le pays correspondent.

En résumé, ces facteurs indiquent que, pour obtenir le meilleur score, vous devez :

• Évitez les publicités.
• Mettez à jour le contenu plus ancien plutôt que de créer de nouvelles pages.
• Assurez-vous que la plupart de vos liens ont un texte d'ancrage de marque.

Tout le reste de cette liste est hors de votre contrôle.

Top 5 des facteurs de classement initial pondérés positivement

Pour continuer, voici une liste des facteurs de classement positifs les plus pondérés.

1. FI_URL_DOMAIN_FRACTION : +0.5640952971 - Ce facteur est un chevauchement de masquage étrange de la requête par rapport au domaine de l'URL. L'exemple donné est la loterie de Chelyabinsk, abrégée en chelloto. Pour calculer cette valeur, Yandex trouve trois lettres qui sont couvertes (che, hel, lot, olo), voir quelle proportion de toutes les combinaisons de trois lettres se trouve dans le nom de domaine.
2. FI_QUERY_DOWNER_CLICKS_COMBO : +0,3690780393 - La description de ce facteur est qu'il est "intelligemment combiné de FRC et de pseudo-CTR". Il n'y a aucune indication immédiate de ce qu'est le FRC.
3. FI_MAX_WORD_HOST_CLICKS : +0.3451158835 – Ce facteur est la cliquabilité du mot le plus important du domaine. Par exemple, pour toutes les requêtes dans lesquelles il y a le mot « wikipédia », cliquez sur les pages wikipédia.
4. FI_MAX_WORD_HOST_YABAR : +0.3154394573 - La description du facteur indique "le mot de requête le plus caractéristique correspondant au site, selon la barre". Je suppose que cela signifie le mot-clé le plus recherché dans la barre d'outils Yandex associée au site.
5. FI_IS_COM : +0.2762504972 – Le facteur est que le domaine est un .COM.

En d'autres termes:

• Jouez à des jeux de mots avec votre domaine.
• Assurez-vous que c'est un point com.
• Encouragez les gens à rechercher vos mots-clés cibles dans la barre Yandex.
• Continuez à générer des clics.

Il existe de nombreux facteurs de classement initiaux inattendus

Ce qui est plus intéressant dans les facteurs de classement pondérés initiaux, ce sont les facteurs inattendus. Voici une liste de dix-sept facteurs qui se sont démarqués.

1. FI_PAGE_RANK : +0,1828678331 – Le PageRank est le 17e facteur pondéré le plus élevé de Yandex. Auparavant, ils supprimaient entièrement les liens de leur système de classement, il n'est donc pas trop choquant de savoir à quel point il est bas sur la liste.
2. FI_SPAM_KARMA : +0.00842682963 – Le spam karma est nommé d'après les « antispams » et correspond à la probabilité que l'hôte soit un spam ; basé sur les informations Whois
3. FI_SUBQUERY_THEME_MATCH_A : +0,1786465163 : la correspondance thématique entre la requête et le document. Il s'agit du 19e facteur pondéré le plus élevé.
4. FI_REG_HOST_RANK : +0.1567124399 - Yandex a un facteur de classement d'hôte (ou de domaine).
5. FI_URL_LINK_PERCENT : +0,08940421124 – Rapport des liens dont le texte d'ancrage est une URL (plutôt que du texte) au nombre total de liens.
6. FI_PAGE_RANK_UKR : +0.08712279101 – Il existe un PageRank ukrainien spécifique
7. FI_IS_NOT_RU : +0.08128946612 - C'est une chose positive si le domaine n'est pas un .RU. Apparemment, le moteur de recherche russe ne fait pas confiance aux sites russes.
8. FI_YABAR_HOST_AVG_TIME2 : +0,07417219313 - Il s'agit du temps de séjour moyen tel que rapporté par YandexBar
9. FI_LERF_LR_LOG_RELEV : +0.06059448504 - Il s'agit de la pertinence du lien basée sur la qualité de chaque lien
10. FI_NUM_SLASHES : +0,05057609417 - Le nombre de barres obliques dans l'URL est un facteur de classement.
11. FI_ADV_PRONOUNS_PORTION : -0.001250755075 – La proportion de noms pronom sur la page.
12. FI_TEXT_HEAD_SYN : -0.01291908335 - La présence de mots [query] dans l'en-tête, en tenant compte des synonymes
13. FI_PERCENT_FREQ_WORDS : -0,02021022114 - Le pourcentage du nombre de mots, qui sont les 200 mots les plus fréquents de la langue, par rapport au nombre de tous les mots du texte.
14. FI_YANDEX_ADV : -0.09426121965 - Devenant plus précis avec le dégoût envers les publicités, Yandex pénalise les pages avec des publicités Yandex.
15. FI_AURA_DOC_LOG_SHARED : -0.09768630485 – Le logarithme du nombre de bardeaux (zones de texte) dans le document qui ne sont pas uniques.
16. FI_AURA_DOC_LOG_AUTHOR : -0.09727752961 - Le logarithme du nombre de bardeaux sur lesquels ce propriétaire du document est reconnu comme l'auteur.
17. FI_CLASSIF_IS_SHOP : -0.1339319854 - Apparemment, Yandex va vous donner moins d'amour si votre page est un magasin.

Le principal point à retenir de l'examen de ces facteurs de classement étranges et de la gamme de ceux disponibles dans la base de code Yandex est qu'il y a beaucoup de choses qui pourraient être un facteur de classement.

Je soupçonne que les « 200 signaux » rapportés par Google sont en fait 200 classes de signaux où chaque signal est un composite construit de nombreux autres composants. De la même manière que Google Analytics a des dimensions avec de nombreuses mesures associées, Google Search a probablement des classes de signaux de classement composés de nombreuses fonctionnalités.

Yandex gratte Google, Bing, YouTube et TikTok

La base de code révèle également que Yandex dispose de nombreux analyseurs pour d'autres sites Web et leurs services respectifs. Pour les Occidentaux, les plus notables d'entre eux sont ceux que j'ai énumérés dans la rubrique ci-dessus. De plus, Yandex dispose d'analyseurs pour une variété de services que je ne connaissais pas ainsi que pour ses propres services.

Ce qui est immédiatement évident, c'est que les analyseurs sont complets. Chaque composant significatif du SERP de Google est extrait. En fait, toute personne qui pourrait envisager de supprimer l'un de ces services ferait bien de revoir ce code.

Il existe un autre code qui indique que Yandex utilise certaines données de Google dans le cadre des calculs DSSM, mais les 83 facteurs de classement nommés par Google eux-mêmes indiquent clairement que Yandex s'est assez fortement appuyé sur les résultats de Google.

De toute évidence, Google ne tirerait jamais la décision de Bing de copier les résultats d'un autre moteur de recherche ni ne dépendrait d'un seul pour les calculs de classement de base.

Yandex a des limites supérieures anti-SEO pour certains facteurs de classement

315 facteurs de classement ont des seuils auxquels toute valeur calculée au-delà indique au système que cette fonctionnalité de la page est sur-optimisée. 39 de ces facteurs de classement font partie des facteurs initialement pondérés qui peuvent empêcher une page d'être incluse dans la liste des publications initiales. Vous pouvez les trouver dans la feuille de calcul que j'ai liée ci-dessus en filtrant le coefficient de classement et la colonne anti-SEO.

Conceptuellement, il n'est pas exagéré de s'attendre à ce que tous les moteurs de recherche modernes définissent des seuils sur certains facteurs dont les référenceurs ont historiquement abusé, tels que le texte d'ancrage, le CTR ou le bourrage de mots clés. Par exemple, Bing aurait tiré parti de l'utilisation abusive des méta-mots clés comme facteur négatif.

Yandex booste les "hôtes vitaux"

Yandex dispose d'une série de mécanismes de renforcement dans toute sa base de code. Il s'agit d'améliorations artificielles de certains documents pour s'assurer qu'ils obtiennent un score plus élevé lorsqu'ils sont pris en compte pour le classement.

Vous trouverez ci-dessous un commentaire de "l'assistant de boosting" qui suggère que les fichiers plus petits bénéficient le mieux de l'algorithme de boosting.

Il existe plusieurs types de boosts ; J'ai vu un boost lié aux liens et j'ai aussi vu une série de "HandJobBoosts" dont je ne peux que supposer qu'il s'agit d'une traduction étrange de changements "manuels".

L'un de ces boosts que j'ai trouvé particulièrement intéressant est lié aux "hôtes vitaux". Où un hôte vital peut être n'importe quel site spécifié. NEWS_AGENCY_RATING est spécifiquement mentionné dans les variables, ce qui me porte à croire que Yandex donne un coup de pouce qui biaise ses résultats à certains organes de presse.

Sans entrer dans la géopolitique, c'est très différent de Google en ce sens qu'ils ont insisté sur le fait de ne pas introduire de biais comme celui-ci dans leurs systèmes de classement.

La structure du serveur de documents

La base de code révèle comment les documents sont stockés dans le serveur de documents de Yandex. Ceci est utile pour comprendre qu'un moteur de recherche ne se contente pas de faire une copie de la page et de l'enregistrer dans son cache, il capture diverses fonctionnalités sous forme de métadonnées à utiliser ensuite dans le processus de classement en aval.

La capture d'écran ci-dessous met en évidence un sous-ensemble de ces fonctionnalités qui sont particulièrement intéressantes. D'autres fichiers avec des requêtes SQL suggèrent que le serveur de documents a plus de 200 colonnes, y compris l'arborescence DOM, la longueur des phrases, l'heure de récupération, une série de dates et le score antispam, la chaîne de redirection et si le document est traduit ou non. La liste la plus complète que j'ai rencontrée se trouve dans /robot/rthub/yql/protos/web_page_item.proto.

Ce qui est le plus intéressant dans le sous-ensemble ici est le nombre de simhashes qui sont employés. Les Simhashes sont des représentations numériques du contenu et les moteurs de recherche les utilisent pour une comparaison rapide comme l'éclair afin de déterminer le contenu dupliqué. Il existe diverses instances dans l'archive du robot qui indiquent que le contenu dupliqué est explicitement rétrogradé.

De plus, dans le cadre du processus d'indexation, la base de code comprend TF-IDF, BM25 et BERT dans son pipeline de traitement de texte. La raison pour laquelle tous ces mécanismes existent dans le code n'est pas claire, car il y a une certaine redondance dans leur utilisation.

Facteurs de lien et priorisation

La façon dont Yandex gère les facteurs de lien est particulièrement intéressante, car ils avaient auparavant complètement désactivé leur impact. La base de code révèle également de nombreuses informations sur les facteurs de lien et sur la hiérarchisation des liens.

Le calculateur de spam de lien de Yandex a 89 facteurs qu'il examine. Tout ce qui est marqué comme SF_RESERVED est obsolète. Le cas échéant, vous pouvez trouver les descriptions de ces facteurs dans la feuille Google liée ci-dessus.

Notamment, Yandex a un classement d'hôte et certains scores semblent perdurer à long terme après qu'un site ou une page ait développé une réputation de spam.

Une autre chose que fait Yandex est d'examiner la copie sur un domaine et de déterminer s'il y a du contenu en double avec ces liens. Il peut s'agir de placements de liens sur l'ensemble du site, de liens sur des pages en double ou simplement de liens avec le même texte d'ancrage provenant du même site.

Cela illustre à quel point il est trivial de ne pas tenir compte de plusieurs liens provenant de la même source et clarifie à quel point il est important de cibler des liens plus uniques provenant de sources plus diverses.

Que pouvons-nous appliquer de Yandex à ce que nous savons de Google ?

Naturellement, c'est toujours la question qui préoccupe tout le monde. Bien qu'il existe certainement de nombreux analogues entre Yandex et Google, à vrai dire, seul un ingénieur logiciel de Google travaillant sur la recherche pourrait répondre définitivement à cette question.

Pourtant, ce n'est pas la bonne question.

Vraiment, ce code devrait nous aider à élargir notre réflexion sur la recherche moderne. Une grande partie de la compréhension collective de la recherche est construite à partir de ce que la communauté SEO a appris au début des années 2000 grâce à des tests et de la bouche des ingénieurs de recherche lorsque la recherche était beaucoup moins opaque. Cela n'a malheureusement pas suivi le rythme rapide de l'innovation.

Les informations tirées des nombreuses fonctionnalités et facteurs de la fuite de Yandex devraient produire davantage d'hypothèses à tester et à prendre en compte pour le classement dans Google. Ils devraient également introduire plus de choses qui peuvent être analysées et mesurées par l'exploration SEO, l'analyse des liens et les outils de classement.

Par exemple, une mesure de la similarité cosinusoïdale entre les requêtes et les documents utilisant les intégrations BERT pourrait être utile pour comprendre par rapport aux pages concurrentes, car c'est quelque chose que les moteurs de recherche modernes font eux-mêmes.

De la même manière que les journaux de recherche AOL nous ont éloignés de deviner la distribution des clics sur SERP, la base de code Yandex nous éloigne de l'abstrait vers le concret et nos déclarations "ça dépend" peuvent être mieux qualifiées.

À cette fin, cette base de code est un cadeau qui continuera à donner. Cela ne fait qu'un week-end et nous avons déjà glané des informations très convaincantes à partir de ce code.

Je prévois que certains ingénieurs SEO ambitieux avec beaucoup plus de temps libre continueront à creuser et peut-être même à remplir suffisamment de ce qui manque pour compiler cette chose et la faire fonctionner. Je pense également que les ingénieurs des différents moteurs de recherche examinent et analysent également les innovations dont ils peuvent tirer des enseignements et les ajouter à leurs systèmes.

Simultanément, les avocats de Google rédigent probablement des lettres de cessation et d'abstention agressives liées à tous les grattages.

J'ai hâte de voir l'évolution de notre espace qui est animée par les personnes curieuses qui maximiseront cette opportunité.

Mais bon, si obtenir des informations à partir du code réel ne vous est pas utile, vous pouvez recommencer à faire quelque chose de plus important, comme discuter des sous-domaines par rapport aux sous-répertoires.