Pendant quinze ans, la question du « bac à sable » a tourné en boucle : les nouveaux sites sont-ils retenus quelque temps avant de pouvoir se classer ? Les porte-parole de Google ont répondu non, régulièrement. La documentation interne rendue publique en 2024 contient un champ dont le commentaire emploie le mot — et ce commentaire ne dit pas tout à fait ce que la profession lui fait dire.
Le champ existe, et son commentaire prononce le mot
PerDocData.hostAge. Voici son commentaire, tronqué de sa fin technique :
« The earliest firstseen date of all pages in this host/domain. These data are used in twiddler to sandbox fresh spam in serving time. It is 16 bit and the time is day number after 2005-12-31, and all the previous time are set to 0. […] »
En français : la date de première détection la plus ancienne parmi toutes les pages de cet hôte ou de ce domaine. Ces données sont utilisées dans un twiddler pour mettre en bac à sable le spam récent au moment de servir les résultats. Le champ tient sur 16 bits ; le temps est exprimé en numéro de jour après le 31 décembre 2005, et tout ce qui précède est mis à zéro.
Quatre choses sont écrites là, et elles ne sont pas interchangeables.
Ce que ce commentaire dit, et ce qu’il ne dit pas
Ce qui est mis en bac à sable, c’est « fresh spam ». Pas « les nouveaux sites », pas « les nouveaux domaines » : du spam récent. Le commentaire décrit une donnée d’âge utilisée par un mécanisme anti-spam, pas un délai de carence appliqué à tout site neuf. La nuance est la totalité du sujet.
Le mécanisme est un twiddler, et il agit au moment de servir. Un twiddler retouche un classement déjà calculé — c’est le sujet d’un article dédié. L’âge n’entre donc pas dans le calcul du score de base décrit ici : il alimente une retouche, et seulement pour le cas nommé.
L’âge mesuré est celui de l’hôte ou du domaine, pas de la page. C’est la plus ancienne date de première détection parmi toutes les pages. Une seule page ancienne suffit à dater l’ensemble.
Ce que le commentaire ne dit pas : ce que le twiddler fait exactement, pendant combien de temps, à partir de quel âge, et sur quels critères une page est jugée « fresh spam ». Aucun de ces éléments n’est écrit.
L’encodage raconte une histoire que personne ne relève
Relisez la fin de la phrase : « the time is day number after 2005-12-31, and all the previous time are set to 0 » — le temps est le numéro de jour après le 31 décembre 2005, et tout ce qui précède est mis à zéro.
Tous les domaines apparus avant le 31 décembre 2005 portent la même valeur : zéro. Un site de 1998 et un site de 2005 sont, dans ce champ, strictement indiscernables. L’ancienneté ne s’accumule pas au-delà de cette borne — elle s’y arrête.
Le champ tient sur 16 bits, ce qui permet de compter environ 65 000 jours, soit près de cent-quatre-vingts ans à partir de 2006. La contrainte n’est donc pas la capacité : c’est le choix d’une date de départ. Ce qui précède est écrasé.
Conséquence pratique, et elle est contre-intuitive : dans ce champ précis, « mon domaine a vingt-cinq ans » n’apporte rien de plus que « mon domaine a vingt ans ».
Deux dates de registre, et le mot « dernière »
Une structure distincte, RegistrationInfo, contient deux champs sur le cycle de vie administratif du domaine.
createdDate : « This is the number of days since January 1st 1995 that this domain was last created. » — le nombre de jours depuis le 1er janvier 1995 où ce domaine a été créé pour la dernière fois.
expiredDate : « This is the number of days since January 1st 1995 that this domain last expired. […] Jan 1st 1995 was chosen by the history project as a special epoch date. » — le nombre de jours depuis la même date où ce domaine a expiré pour la dernière fois ; cette date de référence a été choisie par ce que le commentaire appelle le projet d’historique.
Le mot décisif est « last », dans les deux commentaires. Un domaine n’a pas une date de création : il a une dernière date de création. Autrement dit, le système est construit pour des domaines qui naissent, meurent et renaissent — et il retient la dernière occurrence de chaque événement.
Le domaine expiré est marqué deux fois, dont une par un « pénaliseur »
Deux champs, dans deux structures différentes, portent sur l’expiration côté liens.
AnchorsAnchor.expired : « true iff exp domain » — vrai si et seulement si le domaine est expiré. Cinq mots, un booléen, collé au lien lui-même.
IndexingDocjoinerAnchorStatistics.pageFromExpiredTaggedAnchors, et son commentaire tient en une ligne : « Set in SignalPenalizer::FillInAnchorStatistics. » — renseigné dans un composant dont le nom est, littéralement, un pénaliseur de signaux.
Ce que ça établit : les liens venus d’une page sur domaine expiré sont marqués, comptés, et le compteur est rempli par un composant nommé pénaliseur. Ce que ça n’établit pas : ce que le pénaliseur fait de ce compte. Le nom du composant n’est pas une description de son effet.
La correspondance exacte est bien un champ de démotion
Dernier champ du lot. CompressedQualitySignals.exactMatchDomainDemotion, dont le commentaire décrit d’abord toute la structure puis précise : « exact_match_domain_demotion: converted from QualityBoost.emd.boost » — démotion de domaine à correspondance exacte, convertie depuis un autre protocole.
Le champ existe donc, avec un nom sans ambiguïté, logé sur les mêmes dix bits que les autres signaux compressés de cette structure. Ce que « correspondance exacte » recouvre — la requête entière dans le domaine, une partie, avec ou sans tirets — n’est écrit nulle part.
Cet article détaille un point de la page sur la popularité vue par les documents. Voir aussi pourquoi la page d’accueil concentre la popularité.
Ce qui est documenté, ce qui est déduit, ce qui reste inconnu
| Affirmation | Statut | Source |
|---|---|---|
| Un champ stocke la plus ancienne date de première détection des pages d’un hôte ou domaine | Documenté | Commentaire de hostAge |
| Ces données sont utilisées dans un twiddler pour mettre en bac à sable le spam récent au moment de servir | Documenté | Idem |
| Le temps est compté en jours après le 31 décembre 2005, et tout ce qui précède vaut zéro | Documenté | Idem |
| Deux domaines apparus avant 2006 sont indiscernables dans ce champ | Déduit | Conséquence directe de la mise à zéro |
| Une date de dernière création et une date de dernière expiration du domaine sont stockées | Documenté | Commentaires de createdDate et expiredDate |
| Un booléen marque un lien venu d’un domaine expiré | Documenté | Commentaire de expired |
| Un compteur de liens venus de pages sur domaine expiré est rempli par un composant nommé pénaliseur | Documenté | Commentaire de pageFromExpiredTaggedAnchors |
Un champ exactMatchDomainDemotion existe |
Documenté | Commentaire du champ |
domainAge n’a pour tout commentaire que « 16-bit » |
Mesuré | Relevé des commentaires du dépôt |
| « Google met les nouveaux sites en bac à sable » | Imprécis | Le commentaire dit « fresh spam », pas « nouveaux sites » |
| « L’âge du domaine est un facteur de classement » | Non documenté | Le champ alimente une retouche pour un cas nommé ; aucun poids n’est donné |
| La durée du bac à sable, et le seuil d’âge concerné | Non documenté | Aucun chiffre dans aucun commentaire |
| Ce que le pénaliseur fait des liens venus de domaines expirés | Non documenté | Le compteur est nommé, son usage ne l’est pas |
| Ce que « correspondance exacte » recouvre exactement | Non documenté | Le champ est nommé, jamais défini |
Limites de cet article. Le dépôt décrit l’état d’un système interne au premier trimestre 2024 et n’a pas été mis à jour depuis : rien ne garantit que ces champs soient encore renseignés aujourd’hui. La fin du commentaire de hostAge, consacrée aux valeurs sentinelles et à un langage interne, a été tronquée ici : elle ne porte pas sur le mécanisme.
Questions fréquentes
Le bac à sable existe-t-il, oui ou non ? Un champ d’âge existe, et son commentaire dit qu’il sert à mettre en bac à sable du spam récent. C’est différent d’un délai appliqué à tout nouveau site. Les deux positions publiques — « il n’y a pas de sandbox pour les nouveaux sites » et « le mot apparaît dans le code » — peuvent être vraies en même temps.
Faut-il acheter un domaine ancien ? Rien dans ces champs ne le recommande. Et deux éléments vont contre l’idée d’un gain mécanique : l’ancienneté est écrasée avant 2006, et le système retient la dernière date de création d’un domaine, pas la première.
Un domaine expiré racheté repart-il de zéro ? Les documents ne le disent pas. Ils établissent que la dernière expiration est datée, que les liens venus de domaines expirés sont marqués, et qu’un composant nommé pénaliseur remplit ce compteur. Ce qu’il en fait n’est écrit nulle part.
Un nom de domaine contenant mon mot clé est-il pénalisé ? Un champ de démotion pour correspondance exacte existe. Ce qui déclenche cette démotion, et ce qu’elle retire, ne sont documentés ni dans le dépôt ni dans les sources publiques de Google.
Sources
- Miroir public du client Elixir ContentWarehouse, instantané du 27 mars 2024 — sur github.com
