1 281 pages en doublon, et la vraie cause n'était pas celle qu'on croyait

Le contexte

Meubles & Bois vend du mobilier en bois massif sur PrestaShop. Le gérant constatait dans Search Console un nombre croissant d'URL signalées, concentrées sur ses pages catégories — celles qui portent l'essentiel de son chiffre d'affaires.

La lecture naturelle était inquiétante : « Google n'indexe pas mes catégories ».

Le diagnostic

L'analyse a porté sur un échantillon de 1 000 URL signalées entre décembre 2025 et avril 2026, croisée avec des requêtes HTTP directes contre la production — avec trois agents différents, Googlebot Desktop, Googlebot Smartphone et un navigateur — pour reproduire exactement ce que voit Google.

Les catégories n'avaient aucun problème. Deux sources de duplicats parasites produisaient l'essentiel du bruit :

À elles deux, 75 % du total. Les corriger ne « débloquait » pas l'indexation — il n'y avait rien à débloquer. Cela nettoyait le rapport, libérait du budget d'exploration pour les pages utiles, et rendait enfin lisible l'indexation réelle des catégories.

L'enquête sur le paramètre fantôme

Le plus intéressant a été de comprendre d'où venait ?language-select=. Le paramètre prenait pour valeurs onze noms de polices Google Fonts — Hind, Lora, Ubuntu, Roboto, Playfair… — multipliés par les catégories, d'où les centaines de variantes.

Problème : le mécanisme générateur n'existait plus. Ni dans le HTML servi, ni dans le dernier instantané disponible sur Wayback Machine. Trois empreintes ont permis de reconstituer l'origine :

• Le JavaScript d'un module tiers contenait encore une fonction de changement de police réagissant à un sélecteur, et appliquant sur le body une classe correspondant exactement aux onze noms observés.
• Le CSS compilé du thème contenait toujours les onze règles correspondantes (body.Roboto, body.Ubuntu…) — preuve que le mécanisme avait existé.
• Le nom language-select est un libellé inadapté pour un sélecteur de polices. C'est la signature d'un module tiers livré tel quel et jamais relu.

Le correctif

La source était tarie : plus aucune variante nouvelle n'était générée. L'objectif n'était donc pas de corriger un bug, mais d'accélérer la disparition de l'existant.

Une redirection 301 posée dans le .htaccess, avant les règles de réécriture PrestaShop, supprime le paramètre et renvoie vers l'URL propre. Sans risque fonctionnel : aucun visiteur légitime ne génère ce paramètre. Le même traitement a été appliqué aux URL de la navigation à facettes.

Le résultat

Correctif déployé le 26 mai 2026. Évolution du nombre de pages classées « Autre page avec balise canonique correcte » dans Search Console :

−51 % en onze semaines, avec une décrue qui démarre dans les jours suivant la mise en ligne du correctif. Les deux correctifs sont toujours actifs aujourd'hui.

Deuxième chantier : la performance front

Un index propre ne sert à rien si les pages mettent cinq secondes à s'afficher. Le thème PrestaShop, comme souvent, embarquait une feuille de style générique dont la boutique n'utilisait qu'une fraction, et servait toutes ses images en JPEG.

La purge du CSS s'est faite en deux passes, avec sauvegarde et script de restauration à chaque étape : sur un thème e-commerce, retirer une règle de trop casse une page produit que personne ne regardait. Les images ont été régénérées en WebP par lot avec bascule au niveau du serveur, pour ne pas toucher au contenu. Et un cache serveur a été mis en place, avec préchauffage des pages principales pour que le premier visiteur ne paie pas la génération.

Les images sont servies en différé : une trentaine en chargement paresseux sur l'accueil, avec jeux de tailles adaptatifs. Le JavaScript tient en 24 Ko compressés.

Troisième chantier : les catégories en cocon

Sur une boutique de mobilier, la page catégorie est la page qui vend. Elle était pourtant réduite à une grille de produits — sans contexte, sans conseil, sans rien à lire pour quelqu'un qui hésite entre du chêne et du pin.

Chaque catégorie a été reconstruite autour de l'intention d'achat réelle. Une page comme « meuble TV en bois massif » compte aujourd'hui :

• 3 600 mots et une quarantaine de sections ;
• de vrais guides d'achat — « quelle largeur pour quel écran ? », le comparatif des essences — et non du texte d'habillage ;
• une FAQ balisée en données structurées, plus le fil d'Ariane et les fiches produits ;
• 83 liens internes vers les autres catégories, qui tissent le cocon.

Le menu principal a été repensé par matière plutôt que par rayon, pour coller à la façon dont les clients cherchent réellement : on tape « commode chêne » ou « lit pin massif », pas « chambre ».

Ce qu'on peut en retenir

Le symptôme ment presque toujours. Le client voyait « mes catégories ne sont pas indexées » et aurait pu dépenser des mois à réécrire ses pages catégories. Le problème était ailleurs, dans un module tiers dont plus personne ne se souvenait.

Un diagnostic doit être rejouable. L'audit livré contenait, en annexe, les commandes de vérification à exécuter — de simples curl et grep — pour que le prestataire technique du client puisse rejouer chaque test après mise en production. Un audit qu'on ne peut pas vérifier n'est pas un audit, c'est une opinion.

Le SEO technique seul ne vend rien. Nettoyer l'index libère du budget d'exploration, alléger le front fait rester les visiteurs, mais c'est le contenu des catégories qui transforme une visite en commande. Les trois chantiers ne valent que pris ensemble — et c'est l'avantage d'avoir la même personne sur le diagnostic, le serveur et la rédaction.