L'équipe SEO de la marketplace a réécrit sa règle d'indexation après qu'une simple politique « moins de 3 annonces = noindex » a provoqué la disparition des pages de catégories de Google, nécessitant des semaines pour leur retour. En ajoutant un enregistrement de « déverrouillage » unidirectionnel qui permet à une page de passer de noindex à index mais jamais l'inverse, le site a stoppé ce phénomène d'instabilité.
Pourquoi la règle initiale a échoué
La plateforme de petites annonces génère de nombreuses pages de catégories et de localisations. Lorsqu'une page apparaît pour la première fois, elle ne contient souvent qu'une poignée d'annonces ; l'équipe a donc décidé de la masquer des moteurs de recherche jusqu'à ce qu'elle atteigne un seuil minimal de trois éléments. La logique était simple :
- < 3 annonces → ajouter une balise meta
noindex - ≥ 3 annonces → supprimer la balise (autoriser l'indexation)
Au début, cela permettait d'exclure les pages « thin » (à faible valeur ajoutée) des résultats de Google. Le problème est apparu avec l'expiration des annonces. Une page comptant cinq annonces un jour pouvait n'en avoir plus que deux le lendemain, repassant instantanément en noindex. Google a obéi, a retiré l'URL de son index, et la page a perdu tout le classement qu'elle avait acquis. Lorsqu'une nouvelle annonce arrivait, la page redevenait indexable, mais le processus de réintégration prenait des semaines.
Le résultat était un cycle constant d'« allumage-extinction » : les pages entraient dans l'index, disparaissaient, réintégraient, et ainsi de suite.
La solution du « déverrouillage » unidirectionnel
La faille principale était que la règle n'avait pas de mémoire ; elle recalculait le seuil à chaque requête. L'équipe a introduit une petite table de base de données — seo_unlocks — qui enregistre le moment où une page atteint pour la première fois le seuil de trois annonces. Le nouveau flux de travail est le suivant :
- Vérifier le nombre d'annonces. Si la page contient trois annonces actives ou plus, continuer.
- Écrire une ligne de déverrouillage. Insérer un enregistrement pour cette page dans
seo_unlocks. - Traiter la page comme étant indexable de façon permanente. Même si le nombre d'annonces tombe ultérieurement en dessous de trois, la présence d'une ligne de déverrouillage empêche la page de repasser dans le flux
noindex.
Comme le déverrouillage ne peut être écrit qu'une seule fois, une page peut passer de « noindex » à « index » mais jamais l'inverse. L'équipe a ajouté des garde-fous pour que les URL filtrées (par exemple, les résultats de recherche avec des plages de prix) ne puissent pas créer de déverrouillages pour leurs catégories parentes, et a encapsulé l'appel à la base de données dans un bloc try/catch pour éviter qu'une défaillance de la DB ne fasse planter tout le site.
Ce que cela signifie pour le budget de crawl et les pages « thin »
Une idée reçue courante est que le noindex permet d'économiser du budget de crawl. Google doit tout de même récupérer la page, lire la balise, puis la retirer de l'index. Si l'objectif est d'empêcher Google de solliciter tout un modèle d'URL, le bon outil est le robots.txt. Utilisez noindex uniquement lorsque vous voulez que Google voie la page sans l'afficher dans les résultats de recherche.
Pour les annuaires, les sites d'emploi et les marketplaces qui reposent sur un grand nombre de pages générées automatiquement, la leçon est claire : les règles relatives aux pages « thin » doivent être couplées à une couche de persistance qui se souvient du moment où une page a mérité sa place dans l'index. Sans cette mémoire, une baisse temporaire de contenu peut entraîner la perte du classement acquis par une page, et sa réintégration peut prendre des semaines.
À retenir
Une règle statique de type « si le nombre < 3 alors noindex » crée une volatilité SEO pour les sites d'annonces dynamiques. L'ajout d'un enregistrement de déverrouillage unidirectionnel donne une mémoire à la règle, permettant aux pages de gagner et de conserver leur statut d'indexation, même lorsque le nombre d'annonces fluctue. En associant cela à une utilisation appropriée du robots.txt pour de réelles économies de budget de crawl, vous pouvez protéger à la fois vos classements et vos ressources serveur.