Audit SEO e-commerce : que vérifier et dans quel ordre

L'audit SEO e-commerce, en pratique, a rarement besoin d'outils payants. L'essentiel de ce qu'il faut vérifier, Google le donne déjà gratuitement dans Search Console et Merchant Center — le problème n'est pas l'accès aux données, mais l'ordre dans lequel on les lit. Un audit qui commence par le contenu produit a peu de valeur si une grande partie du catalogue n'est pas encore indexée ; un audit qui commence par les Core Web Vitals n'a pas de sens si les robots de Google n'atteignent même pas les pages produits à cause d'une navigation à facettes mal configurée.

Cet article découpe l'audit SEO e-commerce en sept étapes, dans l'ordre où elles comptent — de l'indexation à la performance, puis aux résultats enrichis, au contenu et aux données Merchant Center — en s'appuyant sur la documentation de Google Search Console et de l'aide Merchant Center, consultée le 1er octobre 2026. L'audit général d'un site, quel que soit le secteur, fait l'objet de l'article sur l'audit de site internet ; cet article se concentre sur ce qui diffère dans une boutique en ligne — des milliers d'URL, des filtres, des variantes et des exigences Merchant Center qu'un site d'entreprise ou un blog n'a pas.

Pourquoi l'ordre des étapes compte dans un audit SEO e-commerce

Chacune des sept étapes ci-dessous s'appuie sur la précédente : elle vérifie un point qui n'a de sens que si l'étape d'avant est déjà en ordre. C'est pourquoi un audit SEO e-commerce commencé au milieu — par exemple par le contenu produit ou par l'apparence d'une page dans les résultats de recherche — peut se terminer par des corrections qui changent peu de choses, si la cause réelle se trouve un niveau plus bas, dans l'indexation ou dans la structure des URL.

Étape 1 : le rapport sur l'indexation des pages

Dans l'audit d'une boutique, la première question n'est pas celle du positionnement, mais de savoir si une page produit a la moindre chance d'apparaître. Le rapport sur l'indexation des pages dans Search Console contient des informations sur l'état d'indexation par Google de toutes les URL que Google connaît sur votre site, et montre « le nombre d'URL de votre site explorées et indexées par Google » (Search Console, rapport sur l'indexation des pages, consulté le 1er octobre 2026).

Les deux statuts principaux — « Dans l'index » et « Non indexée » — ne sont qu'un début. Pour « Non indexée », le rapport donne une raison précise : erreur serveur, blocage par robots.txt, balise noindex, erreur 404, ou autre. Dans une boutique avec un catalogue important, le schéma compte plus qu'une URL isolée : si des dizaines de pages produits partagent la même raison de non-indexation — par exemple le même paramètre d'URL bloqué dans robots.txt — le problème est structurel, pas accidentel.

Avec un grand catalogue, il est aussi utile de savoir ce que le rapport ne promet pas. Google indique qu'il ne faut pas s'attendre à ce que toutes les URL du site soient indexées, seulement les pages canoniques, et qu'une page alternative avec une balise canonique correcte ne demande aucune action : Google a trouvé la version canonique et l'a indexée. La liste d'exemples d'URL affichée pour chaque statut est plafonnée à 1 000 entrées ; dans une boutique de plusieurs dizaines de milliers de produits, vous n'y verrez donc pas toutes les pages concernées. Lisez le schéma dans l'échantillon, mais vérifiez l'ampleur dans les totaux du graphique (Search Console, rapport sur l'indexation des pages, consulté le 5 octobre 2026).

Deux statuts se ressemblent mais ne disent pas la même chose. « Détectée, actuellement non indexée » signifie que Google connaît l'URL mais ne l'a pas encore explorée ; selon l'aide, la raison la plus fréquente est que Google a estimé que l'exploration risquait de surcharger le site et l'a reportée. « Explorée, actuellement non indexée » signifie que Google a exploré la page sans l'indexer ; elle pourra l'être ou non à l'avenir, et l'aide précise qu'il n'est pas nécessaire de soumettre à nouveau l'URL pour exploration. Comme la surcharge est la cause habituelle du premier statut, des milliers de fiches produits détectées mais non explorées sont un signal : vérifiez combien d'URL vos filtres génèrent et à quelle vitesse votre serveur répond.

Le rapport comporte aussi une section séparée, moins critique, qui couvre les problèmes qui n'empêchent pas l'indexation mais limitent la capacité de Google à interpréter et à indexer correctement vos pages — à vérifier après les statuts principaux, pas avant.

Si cette étape montre qu'une part importante du catalogue n'est pas indexée à cause des filtres et des paramètres, lisez la section sur la navigation à facettes plus bas (étape 4) avant de poursuivre — c'est là que nous détaillons comment Google recommande de limiter l'indexation des filtres.

Étape 2 : le rapport Core Web Vitals — quand creuser plus loin

Vient ensuite la performance. Le rapport Core Web Vitals dans Search Console « indique les performances de vos pages en fonction de données d'utilisation réelles », et regroupe les URL par état (« Médiocre », « Amélioration nécessaire », « Bon »), par métrique (LCP, INP, CLS) et par groupe d'URL — par exemple, toutes les pages produits construites sur le même modèle. L'état d'un groupe « est défini par défaut sur l'état le plus lent qui lui est attribué pour ce type d'appareil » — une seule métrique médiocre suffit donc pour que tout le groupe s'affiche comme médiocre (Search Console, rapport Core Web Vitals, consulté le 1er octobre 2026).

Les données de ce rapport proviennent du rapport CrUX, qui rassemble des mesures anonymisées des temps de performance d'utilisateurs réels visitant vos URL — pas d'un test ponctuel en laboratoire. C'est ce qui distingue ce rapport d'un simple passage dans Lighthouse, qui mesure une page dans des conditions contrôlées ; PageSpeed Insights montre les deux — les données de champ issues de CrUX et un score de test Lighthouse. Si le rapport Search Console montre un problème pour un groupe précis de pages (par exemple toutes les fiches produit), c'est seulement à ce moment-là qu'il est pertinent d'examiner une page isolée dans PageSpeed Insights, pour voir exactement ce qui la ralentit.

Cet ordre « d'abord les données de champ, ensuite les données de laboratoire » n'est pas arbitraire — c'est le conseil de Google lui-même : « Les données de champ sont déterminées en surveillant tous les utilisateurs qui accèdent à une page et en mesurant un ensemble donné de métriques de performances pour chacune des expériences individuelles de ces utilisateurs… Les données de laboratoire sont déterminées en chargeant une page Web dans un environnement contrôlé avec un ensemble prédéfini de conditions réseau et d'appareil », et « si vous disposez à la fois de données sur le terrain et de données de laboratoire pour une page donnée, vous devez utiliser les données sur le terrain pour hiérarchiser vos efforts » (web.dev, différences entre données de laboratoire et données de terrain, consulté le 1er octobre 2026). En pratique : ne commencez pas un audit par un test Lighthouse ponctuel d'une page prise au hasard — commencez par le rapport Search Console, qui montre quels groupes de pages ont réellement un problème pour vos vrais clients, et utilisez les données de laboratoire seulement pour diagnostiquer ce qui, dans le code de cette page, cause le mauvais score.

Nous détaillons les mécanismes qui dégradent ces métriques dans une boutique, avec un plan de correction et une comparaison des plateformes issue du HTTP Archive Web Almanac, dans notre article sur les Core Web Vitals e-commerce. Si vous préférez commencer par un test ponctuel d'une page précise, utilisez notre test de vitesse de site.

Étape 3 : résultats enrichis — extrait produit et fiche de marchand

La troisième étape vérifie si Google dispose de données suffisantes pour afficher une page produit avec davantage qu'un simple titre et une description dans les résultats de recherche. Deux types de résultats enrichis apparentés :

• Extrait produit (product snippet) — utilisé « pour les pages produit sur lesquelles les utilisateurs ne peuvent pas acheter directement le produit » — donne plus de place aux avis et aux détails ; il nécessite des données structurées avec name et au moins un élément parmi review, aggregateRating ou offers.
• Fiche de marchand (merchant listing) — utilisée pour les « pages depuis lesquelles un internaute peut acheter un produit » — affiche la taille, la livraison, la politique de retour, et comporte toujours un prix ; elle nécessite name, image et offers avec un prix supérieur à zéro et une devise ; « les fiches de marchand nécessitent un élément Offer » là où l'extrait produit accepte aussi un AggregateOffer (Search Central, données structurées des fiches de marchand, consulté le 1er octobre 2026). Les deux se recoupent en partie : selon Google, ajouter les propriétés requises pour les fiches de marchand rend généralement la page produit éligible aussi aux extraits produit (Search Central, données structurées Produit, consulté le 1er octobre 2026).

L'aide Search Console présente aussi les outils généraux des résultats enrichis : un rapport de synthèse, un rapport sur les données structurées impossibles à analyser et l'outil de test des résultats enrichis. Sa section Shopping mentionne un rapport séparé, « le rapport sur les opportunités pour les marchands », qui « vous propose des recommandations pour améliorer la façon dont votre boutique en ligne apparaît sur Google », ainsi qu'un paramètre « Livraison et retours » sous Paramètres > Shopping, qu'une boutique dotée d'un compte Merchant Center ne voit qu'une fois ce compte associé à la propriété Search Console (Search Console, rapports Shopping, consulté le 1er octobre 2026) — un argument de plus pour garder ces deux comptes reliés plutôt que de les faire fonctionner séparément.

L'absence d'une propriété requise (par exemple priceCurrency dans offers) signifie que la page ne remplit pas les conditions de ce type de résultat enrichi — un problème différent du statut dans le rapport sur l'indexation des pages. Dans un audit, il est utile de passer en revue ce genre de manques avec un développeur, car les données structurées sont généralement générées par le modèle de la page produit : une seule correction du modèle couvre toutes les pages qui l'utilisent.

Étape 4 : filtres, doublons et URL canoniques — une checklist

C'est là qu'une boutique génère le plus d'URL, et avec elles, une bonne partie des problèmes d'indexation de l'étape 1. Vérifiez, dans l'ordre :

• Navigation à facettes. L'implémentation la plus courante, basée sur les paramètres d'URL, « peut générer des espaces d'URL infinis », ce qui entraîne deux effets : la surexploration, parce que les URL créées par les filtres « semblent être nouvelles » pour les robots, et une indexation plus lente des nouvelles pages utiles, car les robots perdent du temps sur des combinaisons de filtres inutiles. La recommandation : « Autorisez plutôt l'exploration des pages des éléments individuels, ainsi que d'une page de liste dédiée qui affiche tous les produits sans filtres appliqués », et renvoyez un code d'état HTTP 404 pour les combinaisons de filtres qui ne donnent aucun résultat. Les méthodes plus faibles — rel=canonical et nofollow sur les liens de filtres — sont « généralement moins efficaces à long terme » que les règles robots.txt et les fragments d'URL (Search Central, gérer la navigation à facettes, consulté le 5 octobre 2026).
• Pagination. Chaque page d'une liste de produits devrait avoir une URL unique, par exemple avec un paramètre ?page=n ; ne définissez pas la première page d'une séquence comme canonique pour le reste — attribuez à chaque page sa propre URL canonique. Google « ne tient plus compte » des balises rel="next"/rel="prev", « bien qu'elles puissent encore être utilisées par d'autres moteurs de recherche » — si elles sont encore dans votre code depuis quelques années, elles ne nuisent pas, mais elles n'influencent plus non plus l'indexation chez Google (Search Central, pagination et chargement incrémentiel des pages, consulté le 1er octobre 2026).
• Variantes de produit (couleur, taille). Google demande de s'assurer « que chaque variante peut être identifiée par une URL distincte » — sous forme de segment de chemin ou de paramètre de requête (Search Central, structure des URL pour les sites e-commerce, consulté le 1er octobre 2026). Google ne publie pas de règle unique disant « canonicalisez toujours les variantes vers une seule URL de base » — c'est une décision commerciale, qui dépend de votre souhait de voir chaque couleur apparaître séparément dans la recherche.
• Doublons et URL canonique. Le choix de l'URL canonique « consiste à sélectionner l'URL représentative (canonique) d'un contenu », et parmi les sources de doublons, Google cite lui-même « les résultats des fonctions de tri et de filtrage d'une page de catégories » — le cas le plus courant dans une boutique. Mise en garde importante : « l'indication d'une préférence canonique ne garantit pas que l'URL sera choisie comme URL canonique » — Google tient aussi compte d'autres facteurs, parmi lesquels HTTP ou HTTPS, les redirections et la présence de l'URL dans un sitemap (Search Central, choix de l'URL canonique, consulté le 1er octobre 2026).
• Le mythe de la « pénalité pour contenu dupliqué ». La documentation actuelle de Google (2026) le formule avec nuance : « Votre site devrait s'en sortir sans spécifier de préférence canonique » (Search Central, consolider les URL en double, consulté le 1er octobre 2026) — la balise rel="canonical" vous donne la maîtrise et économise le budget d'exploration ; elle ne protège pas contre une pénalité. L'affirmation plus forte, souvent répétée, selon laquelle il n'existe pas de pénalité pour contenu dupliqué sauf intention de tromper et de manipuler les classements, provient d'un article du blog Google Search Central de septembre 2008 (« Let's put this to bed once and for all, folks: There's no such thing as a "duplicate content penalty." », traduction libre : « Réglons la question une fois pour toutes : la “pénalité pour contenu dupliqué” n'existe pas ») et ne fait plus partie de la documentation actuelle — à traiter comme un repère historique, pas comme la position d'aujourd'hui.

L'explication complète de la structure des URL, de la pagination, de la navigation à facettes et des doublons dans une boutique — avec des exemples par plateforme — se trouve dans l'article sur le référencement technique e-commerce.

Étape 5 : contenu produit et catégorie

La cinquième étape n'a de sens que si les étapes 1 à 4 montrent déjà des pages indexées et techniquement correctes — sinon, améliorer le contenu change peu de choses dans les résultats de recherche. Vérifiez si les descriptions de produits et de catégories relèvent du contenu « people-first », que Google définit comme « le contenu créé principalement pour les internautes, et non pour manipuler les classements dans les moteurs de recherche » (Search Central, créer du contenu utile, consulté le 1er octobre 2026). Si une grande partie des descriptions est générée automatiquement à grande échelle sans valeur ajoutée, ce n'est plus une question de style, mais un risque au regard de la règle sur « l'utilisation abusive de contenu à grande échelle » (Search Central, règles concernant le spam, consulté le 5 octobre 2026), que Google a introduite le 5 mars 2024 avec la mise à jour principale de mars 2024.

La checklist complète de ce qu'une page produit devrait contenir — limites de caractères Merchant Center, exigences sur les images, quand les descriptions de catégories aident ou nuisent, et comment traiter le contenu généré par IA — se trouve dans l'article sur la fiche produit SEO.

Étape 6 : diagnostic dans Merchant Center

Si une boutique utilise Google Merchant Center (flux de produits, fiches gratuites ou annonces), l'audit doit aussi porter sur ce compte, car les erreurs qui s'y trouvent ne sont pas visibles dans le rapport d'indexation standard. Vérifiez :

• les statuts des produits et les raisons de refus — selon les exigences relatives aux pages de destination, le prix affiché « doit correspondre à celui de vos données produit » et la page doit indiquer clairement la disponibilité du produit (Aide Merchant Center, exigences concernant les pages de destination, consulté le 1er octobre 2026) ;
• les avertissements dans les notifications du compte — pour certaines règles, comme celle sur le contenu Shopping non accepté, Google précise que leur non-respect « n'entraînera pas la suspension immédiate du compte sans avertissement préalable » et qu'« un avertissement sera envoyé à l'annonceur au moins sept jours avant toute suspension du compte » (Aide Merchant Center, contenu Shopping non accepté, consulté le 1er octobre 2026) — mais vous ne profitez de ce délai que si vous consultez réellement ces notifications ;
• la conformité de la page de destination — un prix visible et conforme aux données du flux, un lien vers le produit précis, aucun élément qui masque les informations requises ;
• la connexion avec Search Console — sans elle, vous ne verrez pas le paramètre « Livraison et retours » sous Paramètres > Shopping.

La création d'un compte Merchant Center, la validation de votre site et la différence entre un flux et les données structurées font l'objet d'un article séparé sur Google Merchant Center.

Étape 7 : le faire soi-même ou confier l'audit

Il n'existe pas de prix public moyen fiable et méthodologiquement documenté pour un audit SEO e-commerce, en Suisse, dans l'UE ou ailleurs — les études examinées pour cette recherche mesurent des choses entièrement différentes (salaires des spécialistes SEO, visibilité d'une boutique dans l'index d'un outil précis) ou sont des contenus marketing d'agences avec des fourchettes choisies pour générer des prospects, pas des données issues d'un échantillon. Nous ne donnons donc pas de chiffre ici — à la place, vous pouvez parcourir vous-même les étapes 1 à 4 ci-dessus avec notre checklist d'auto-audit, car elles demandent surtout de lire des rapports gratuits de Google, pas d'outils spécialisés.

Confier l'audit à un prestataire devient plus pertinent quand : le catalogue atteint des milliers d'URL et un problème d'indexation a plusieurs causes qui se superposent à la fois (filtres, variantes, migration de plateforme) ; quand vous avez besoin d'aide pour déterminer laquelle, parmi plusieurs causes simultanées, est responsable d'une baisse de visibilité ; ou quand les rapports signalent un problème sans que vous sachiez quel élément précis du modèle ou de l'extension en est la cause — c'est un travail qui demande le temps d'une personne compétente, pas seulement la lecture d'un rapport.

La différence pratique entre une checklist et un audit confié à un prestataire tient justement à cette étape d'interprétation. Une checklist dit « vérifiez le rapport sur l'indexation des pages et voyez s'il y a des erreurs » — et cela suffit à repérer un problème. Elle ne dit pas quoi faire ensuite quand il y a plusieurs centaines d'erreurs à la fois, réparties sur plusieurs causes : une partie des pages est bloquée par une règle robots.txt ajoutée lors d'une migration précédente, une partie porte encore une balise noindex oubliée après une phase de test, et une partie n'a simplement aucun lien pointant vers elle depuis le reste du site. Séparer ces causes, décider laquelle corriger en premier, et vérifier qu'une correction du modèle ne casse rien d'autre sur toutes les autres pages du même type — c'est un travail qu'un prestataire externe fait plus vite que quelqu'un qui regarde ces rapports pour la première fois.