Dans une analyse publiée sur Hobo, le consultant SEO Shaun Anderson examine les relations entre Goldmine, RankLab et NSR. Spécialiste du référencement et du développement web depuis plus de vingt ans, il croise les structures de la documentation interne du Google Content Warehouse pour proposer une lecture de leur fonctionnement commun.
Son modèle distingue l’évaluation des éléments d’une page, l’expérimentation sur les modèles et l’utilisation des signaux dans les résultats de recherche.
Goldmine évalue plusieurs candidats pour un même titre
Le premier niveau concerne les textes que Google peut afficher dans les résultats. Le module QualityPreviewRanklabTitle rassemble les données associées à chaque titre candidat. Sa description prévoit deux usages, la sélection des titres en production et l’entraînement des modèles de sélection.
La balise <title> représente donc une source parmi plusieurs. D’autres champs identifient les en-têtes de la page, les ancres de liens internes et externes ou un titre généré. Anderson décrit Goldmine, nommé AlternativeTitlesAnnotator dans les commentaires techniques, comme le système qui évalue ces propositions.
Deux attributs précisent les étapes de cette évaluation. goldminePageScore correspond au score calculé dans Goldmine. goldmineAdjustedScore conserve un score après ajustements supplémentaires, dont la description mentionne BlockBERT.
La structure expose aussi des caractéristiques du texte. dupTokens compte les mots répétés, goldmineHasBoilerplateInTitle concerne le texte standardisé et widthFraction rapporte la largeur du titre à la largeur autorisée. Le champ isTruncated indique si le candidat est tronqué.
Anderson rapproche enfin goldmineNavboostFactor des données de comportement associées à NavBoost. Il y voit une articulation entre l’évaluation du texte et les interactions des internautes. La documentation nomme cette composante, sans préciser son poids dans le score.
RankLab conserve les données nécessaires aux comparaisons
Le deuxième niveau porte sur la comparaison des modèles. Dans QualityPreviewRanklabTitle, les champs baseRank et testRank enregistrent la position d’un titre candidat dans une configuration de référence et dans une configuration de test. Des attributs distincts conservent les scores Goldmine obtenus dans les deux configurations.
Une autre structure, MustangReposWwwSnippetsSnippetsRanklabFeatures, décrit l’export des données de titres et d’extraits vers des fichiers destinés à RankLab. Elle distingue notamment l’origine du titre, celle de l’extrait et la couverture des termes de la requête.
Sa liste titles contient les candidats classés par score, du meilleur au moins bon. Le premier élément correspond au titre effectivement sélectionné. Pour les extraits, la documentation distingue également les candidats et le texte finalement affiché.
Ces éléments conduisent Anderson à présenter RankLab comme un environnement d’expérimentation. Il le distingue des systèmes qui servent les résultats aux internautes. Les caractéristiques enregistrées permettent d’examiner les choix des modèles et de comparer différentes versions.
NSR rassemble des signaux au-delà de chaque page
Le troisième niveau concerne l’évaluation du site. Anderson s’appuie sur QualityNsrNsrData, une structure qui rassemble des données à l’échelle d’un « sitechunk », un regroupement d’URL dont le périmètre peut être plus précis qu’un domaine entier.
Les champs siteLinkIn et siteLinkOut décrivent des valeurs agrégées sur les liens. chromeInTotal désigne des vues issues de Chrome à l’échelle du site. D’autres attributs conservent des impressions, des prédictions de qualité et des données de classification.
La structure distingue aussi deux formes de variabilité. siteQualityStddev estime la dispersion des évaluations de qualité entre les pages. Le commentaire technique le différencie de nsrVariance, qui concerne l’erreur de prédiction du NSR lui-même.
Anderson relie ces informations aux signaux de qualité des pages et au champ siteAuthority. Dans CompressedQualitySignals, ce dernier est décrit comme une valeur convertie depuis quality_nsr.SiteAuthority, puis appliquée dans Qstar.
Son interprétation repose sur une évaluation à plusieurs échelles. Les caractéristiques propres à une page seraient associées à des informations sur l’ensemble auquel elle appartient. Il présente cette appréciation collective comme une base susceptible de limiter ou de soutenir sa visibilité.
Anderson propose une explication des changements par paliers
L’auteur prolonge cette lecture avec une hypothèse sur les Core Updates. Son scénario comporte trois étapes. Google collecte les données, les modèles sont réévalués hors du traitement immédiat des requêtes, puis les nouvelles valeurs sont déployées dans les systèmes de recherche.
Il attribue les variations soudaines de visibilité à ce renouvellement des évaluations. Dans son modèle, une modification de la qualité attribuée au site pourrait affecter simultanément de nombreuses pages.
Anderson avance aussi qu’un plafond d’autorité resterait stable entre deux déploiements. Cette proposition explique, selon lui, pourquoi des corrections locales ne suffiraient pas toujours à provoquer une récupération rapide. La documentation citée ne démontre toutefois ni ce gel des valeurs ni sa synchronisation avec les Core Updates.
Les structures décrivent bien des mécanismes de stockage et de versionnement. versionedData conserve des valeurs NSR pour expérimenter une prochaine version. site2vecEmbeddingEncoded stocke une représentation encodée du site, car les représentations complètes occupent trop d’espace. Ces commentaires documentent la préparation et le transport des données, sans fournir le calendrier de leur actualisation en production.
