Un audit SEO d’une boutique en ligne ne ressemble pas à celui d’un blog. Le catalogue introduit des variables qu’un site éditorial ne possède pas : variantes de produit, filtres à facettes, stock changeant et paramètres de tri qui génèrent des milliers d’URL. C’est pourquoi, lorsqu’on me demande par où commencer, ma réponse est toujours la même : n’ouvre pas Search Console pour regarder les graphiques. Configure d’abord un environnement reproductible qui te permette de mesurer sans bruit. Cet article décrit cette séquence exacte, dans l’ordre où il convient de l’exécuter.
Étape 0 : prépare l’environnement avant de toucher à la boutique
Avant d’auditer quoi que ce soit, tu as besoin de trois choses en place. Si tu les sautes, tu finiras par prendre des décisions sur des données contaminées.
1. Un crawl de référence avec le user-agent de Googlebot
Configure Screaming Frog (ou l’outil que tu utilises) avec le user-agent de Googlebot smartphone et active le rendu JavaScript. Sur un ecommerce avec lazy loading des images et prix chargés par AJAX, le crawl sans rendu te renvoie des templates vides et de faux doublons. C’est l’erreur la plus fréquente que je vois : on audite avec le crawl par défaut en desktop et on conclut qu’il y a du contenu dupliqué là où il n’y a qu’un rendu incomplet.
2. Des propriétés séparées dans Search Console
Aie une propriété de domaine et une propriété de préfixe d’URL avec la version canonique. Compare les deux. Si les données diffèrent beaucoup, tu as un problème de redirection ou de paramètres que tu ne contrôles pas.
3. Exportation des logs du serveur
Demande à l’équipe d’infrastructure au moins 15 jours de logs avec IP, user-agent, URL demandée et code de statut. Sans cela, tu ne peux pas savoir ce que Google crawle réellement, seulement ce que ton outil croit qu’il crawle.
Étape 1 : fige l’indexabilité et documente l’état initial
Avant de modifier les canonicals ou d’ajouter des noindex, sauvegarde une capture de l’état actuel : nombre d’URL indexées, sitemap envoyé, robots.txt et directives meta des templates principaux (catégorie, produit, filtres).
Un détail qui ne s’apprend qu’avec la pratique : sur PrestaShop et dans certaines configurations de WooCommerce avec des plugins de filtres, le robots.txt bloque /*?orderby= mais les liens internes continuent de pointer vers ces URL. Résultat : Google ne peut pas crawler la page, mais il découvre bien le lien et accumule des signaux sur une URL bloquée. Vérifie toujours la cohérence entre ce qui est bloqué et ce qui est lié.
Étape 2 : cartographie l’architecture réelle du catalogue
Pas celle que tu as conçue, celle qui existe. Exporte toutes les URL crawlées et classe-les en quatre catégories :
- Produits canoniques
- Catégories navigables
- Facettes et paramètres
- URL système (panier, checkout, compte, recherche interne)
Compte combien il y en a de chaque type. Dans les boutiques de taille moyenne, il est courant de constater que les facettes dépassent en nombre les produits. C’est là que se trouve la majeure partie du budget de crawl.
Décision pratique sur les facettes
Il n’existe pas de règle universelle. Les facettes avec un volume de recherche réel (par exemple, les combinaisons de couleur et de taille en mode) méritent d’être indexées comme landing. Celles qui ne servent qu’à naviguer doivent rester accessibles mais non indexables. Ce qui ne fonctionne pas : appliquer un noindex massif à toutes les facettes et découvrir ensuite que certaines apportaient du trafic long tail. Consulte Search Console avant de décider, en filtrant par URL avec paramètres et requêtes avec impressions.
Étape 3 : configure les canonicals, la pagination et les variantes
C’est le point où le plus de boutiques perdent de la force. Trois configurations concrètes :
Variantes de produit
Si chaque taille ou couleur génère une URL propre avec un contenu presque identique, choisis une canonique. Sur Shopify, les variantes par défaut ne créent pas d’URL indépendante, mais beaucoup de thèmes les génèrent avec des paramètres ; sur Magento, il est courant d’avoir des URL par variante. Décide si la variante mérite une page (parce qu’elle a sa propre demande) ou si elle doit pointer vers le produit parent.
Pagination
La page 2 d’une catégorie doit être indexable et autocanonique. Ne la canonise pas vers la page 1 : tu perds le crawl des produits qui n’apparaissent que là. Et ne la bloque pas dans robots.txt, car alors Google ne verra pas les liens de cette page.
Tri et affichage
Les paramètres de tri (?orderby=price, ?view=grid) doivent pointer avec une canonique vers l’URL propre de la catégorie. Vérifie que le lien interne ne les propage pas.
Étape 4 : données structurées de produit, avec des nuances
L’implémentation du schema Product et Offer est obligatoire si tu veux des rich results, mais il convient ici d’être honnête sur les limites. Selon la documentation officielle de Google, les données structurées ne garantissent pas l’apparition d’améliorations dans les résultats ; elles sont une condition nécessaire, pas suffisante.
Des erreurs qui apparaissent encore et encore :
- availability désynchronisé avec le stock réel. Un produit marqué comme InStock qui est en réalité épuisé génère des pénalités dans les améliorations et de la confusion chez l’utilisateur.
- price sans devise ou avec un format local (19,99 € au lieu de 19.99 avec priceCurrency: EUR).
- Des avis agrégés inventés ou importés d’un fournisseur. Google exige qu’ils reflètent des avis réels du site.
Si ta boutique compte des milliers de références et que l’ERP met à jour les prix toutes les heures, la synchronisation du schema est un projet de développement, pas un ajustement de template. Planifie-le comme tel.
Étape 5 : mesure la performance avec des données de terrain, pas de laboratoire
Les Core Web Vitals en ecommerce ont un problème structurel : les templates de produit alourdis par les images et les scripts tiers. Lighthouse te donne une photo de laboratoire ; ce qui compte, c’est la donnée de terrain dans Search Console, section Expérience.
Vérifie d’abord quels templates concentrent les problèmes. Dans beaucoup de boutiques, la home passe les seuils et ce sont les fiches produit avec beaucoup d’images qui échouent sur le LCP. Optimiser la home ne fait pas bouger l’aiguille. Priorise par template et par trafic.
Nuance importante : si ton catalogue change de prix et de disponibilité via du JavaScript tiers (recommandeurs, chat, passerelles de paiement), l’INP peut être affecté et n’est pas toujours sous ton contrôle direct. Documente quels scripts sont dispensables et lesquels ne le sont pas avant de supprimer quoi que ce soit.
Vérifie combien de clics Googlebot a besoin pour atteindre un produit depuis la home. Dans les catalogues profonds, les produits de la page 5 d’une catégorie peuvent se retrouver à quatre ou cinq clics. Ajoute des blocs de liens internes (produits associés, catégories sœurs, mis en avant) qui raccourcissent cette distance.
Et vérifie le menu : les liens vers des facettes depuis le menu principal sont un signal fort d’indexation. Si tu ne veux pas qu’une facette soit indexée, ne la mets pas dans le menu.
Étape 7 : contenu de catégorie et thin content
Les catégories avec seulement un listing de produits se positionnent mal. Ajouter du texte descriptif aide, mais pas n’importe quel texte. Les descriptions génériques copiées du fabricant génèrent de la duplication entre boutiques. Selon des études du secteur, les ecommerce qui travaillent un contenu propre sur les catégories principales obtiennent de meilleures performances organiques, bien que la corrélation n’implique pas la causalité et dépende beaucoup du niche.
Un cas concret que je rencontre souvent : des catégories avec des centaines de produits où le texte est inséré à la fin et est identique dans toutes les sous-catégories. Google le détecte comme du contenu dupliqué interne. Solution : un contenu différencié par sous-catégorie, au moins dans celles qui ont une demande de recherche.
Étape 8 : tableau de bord et vérification
Clôture l’audit avec un tableau de bord que tu peux consulter chaque mois :
- URL indexées vs. envoyées dans le sitemap
- Distribution des codes de statut dans le crawl
- Requêtes avec impressions mais sans clics (opportunités de titre et de meta)
- Templates avec le pire LCP de terrain
- Produits épuisés et leur traitement (301, 410 ou maintien avec avertissement)
À propos des produits épuisés : il n’y a pas de réponse unique. Si le produit va revenir, maintiens l’URL avec un avertissement et une disponibilité à jour. S’il est définitivement déréférencé, redirige vers la catégorie ou vers un substitut. Tout rediriger vers la home est une pratique qui dilue les signaux et désoriente l’utilisateur.
Ce que cet audit ne résout pas
La transparence compte. Un audit technique ne corrige pas un catalogue sans demande, ne remplace pas une stratégie de prix et ne garantit pas de positions. Il ne peut pas non plus compenser une expérience d’achat déficiente : si le checkout échoue sur mobile, le trafic organique ne convertit pas. Et il y a des limites pratiques : dans les boutiques avec des milliers de SKU et un ERP legacy, la synchronisation parfaite des données structurées peut prendre des mois et il convient de prioriser les références à plus fort trafic plutôt que de viser 100 % de couverture.
L’audit est le diagnostic. L’exécution par phases, avec des métriques par template, est ce qui fait bouger les résultats.