CRO
Comparateur de page produit
Comparez une fiche produit à deux concurrentes sur des critères SEO, UX et CRO propres à l'e-commerce : prix visible, CTA, signaux de confiance, données structurées Product/Offer.
Photo par Luke Chesser sur Unsplash
Cet outil analyse la structure HTML de la page (CTA, formulaires, signaux de confiance, prix, navigation) et sa performance de chargement. Il ne peut pas mesurer un taux de conversion réel : ça nécessite le tracking propre au site analysé (Contentsquare, Hotjar, GA4...), inaccessible sur une URL tierce.
🕵️
Comment utiliser cet outil
- 1Entrez l'URL de votre fiche produit et jusqu'à deux concurrentes
- 2Lancez la comparaison
- 3Consultez le détail des critères qui passent ou non, avec le conseil associé
Un exemple concret
Sur une fiche produit type, l'outil relève par exemple un prix bien visible et un CTA d'achat clair, mais aucune donnée structurée Product/Offer détectée dans le code source : la page peut être irréprochable visuellement tout en étant invisible des extraits enrichis Google (prix, note, disponibilité dans les résultats de recherche).
Votre fiche produit donne-t-elle assez de raisons d'ajouter au panier ?
Une fiche produit se joue en quelques secondes : un prix, un bouton d'achat, une preuve que d'autres ont acheté avant vous. Ce comparateur place la vôtre face à deux fiches concurrentes sur huit critères propres à la vente d'un article, du prix détecté aux données structurées Product. Il ne connaît ni vos ventes ni votre taux d'ajout au panier : il juge ce que la page expose dans son code.
Le prix et le bouton d'achat doivent exister dans le HTML
Le prix, le CTA et les signaux de confiance valent chacun environ 16,7 % du score UX/CRO. Pour le prix, l'outil cherche dans le HTML, débarrassé de ses scripts, un nombre suivi de €, $, EUR ou USD, ou bien un € ou un $ suivi d'un nombre. « EUR 10 » n'est donc pas lu, pas plus qu'un « 29 € » dont l'espace insécable est écrit en entité HTML. Conséquence peu intuitive : un prix présent seulement dans votre JSON-LD Product, ou injecté par un script après le chargement, n'est pas détecté. Pour le bouton, « Ajouter au panier », « Acheter » ou « Commander » sont reconnus, s'ils forment l'intitulé, 60 caractères maximum, d'une balise <a> ou <button>. Un bouton d'achat rendu par un composant JavaScript peut donc manquer à l'appel. Le champ secteur agit deux fois sur cette grille. Choisir santé, finance ou immobilier dispense la fiche d'afficher un prix. Et pour quatre secteurs (luxe, santé, finance, institutionnel), aucune mention d'urgence n'est tolérée.
Lire la suiteRéduire
Urgence et avis : deux détecteurs à lire avec recul
Le critère d'urgence pèse ici environ 11 %, presque deux fois plus que sur une page tarifs. Il repère des expressions comme « stock limité », « offre limitée », « derniers jours » ou « plus que », et chaque expression distincte compte une fois. La dernière se glisse aussi dans une phrase banale comme « plus que jamais ». En secteur générique, deux expressions passent encore : une fiche qui affiche « plus que 3 en stock » et « offre limitée » est donc déjà au plafond. Côté confiance, une seule expression reconnue suffit, comme « garantie » ou « avis vérifié », et un balisage Review ou AggregateRating compte aussi. Un lien « Garanties » dans le pied de page fait ainsi passer le critère sans rien dire de la fiche elle-même. À l'inverse, des étoiles affichées en image (sauf alt qui reprend une expression reconnue) ou un widget d'avis chargé en JavaScript restent invisibles pour l'outil. Sur cette ligne, la couleur dit si un mot est présent dans le code, pas si la fiche inspire confiance.
Données structurées et vitesse, ce qui se joue aussi hors de la page
Le critère de données structurées passe dès qu'un type Product, Offer, Review ou AggregateRating est trouvé, même imbriqué dans un @graph. Il ne vérifie pas les propriétés : un Product sans offre ni prix passe quand même, et la ligne verte ne garantit en rien des extraits enrichis dans Google. Le global ajoute la note Lighthouse mobile, pour 30 %, aux 70 % de la grille. Le bloc Core Web Vitals affiche les données terrain CrUX au 75e centile quand elles existent, sinon une estimation de laboratoire. Pour repère, web.dev considère un LCP comme bon jusqu'à 2,5 secondes. L'outil ne compare pas non plus vos prix à ceux des fiches concurrentes : il constate seulement qu'un prix est affiché, quel que soit son montant. Un écart vous semble injuste ? Indiquez l'adresse de la fiche et la ligne en cause, prix ou données structurées, dans le formulaire « Un résultat difficile à interpréter ? » juste sous l'outil.
Questions fréquentes
Cet outil mesure-t-il un vrai taux de conversion ?
Non. Un taux de conversion réel nécessite le tracking propre au site (Google Analytics, Contentsquare, Hotjar...), inaccessible sur une URL tierce. L'outil analyse la structure de la page qui corrèle avec la conversion, sans la mesurer directement.
Que veulent dire FCP, LCP, CLS et INP/TBT ?
Ce sont les Core Web Vitals, les indicateurs que Google utilise pour évaluer l'expérience de chargement d'une page. FCP (First Contentful Paint) mesure le temps d'affichage du premier élément visible. LCP (Largest Contentful Paint) mesure le temps d'affichage du plus gros élément visible. CLS (Cumulative Layout Shift) mesure la stabilité visuelle pendant le chargement. INP (Interaction to Next Paint) mesure la réactivité réelle de la page aux interactions ; TBT (Total Blocking Time) en est l'équivalent labo.
Quelle est la différence entre PSI, Lighthouse et CrUX ?
PageSpeed Insights (PSI) est l'API Google utilisée par cet outil. Elle combine deux sources : Lighthouse, un test de laboratoire qui simule un chargement sur un appareil et un réseau standardisés, et CrUX (Chrome User Experience Report), qui agrège les mesures réelles des internautes ayant visité la page avec Chrome. Le score "Performance mobile" de cet outil vient de Lighthouse. Le bloc Core Web Vitals affiche les données CrUX quand elles existent, sinon l'estimation labo Lighthouse.
Pourquoi le bloc Core Web Vitals affiche parfois une estimation labo plutôt que des données terrain ?
CrUX ne renvoie des données que si la page a reçu un trafic Chrome suffisant sur les 28 derniers jours. En dessous de ce seuil, fréquent sur les sites à trafic modeste ou les pages récentes, aucune donnée terrain n'existe : l'outil bascule alors sur l'estimation labo Lighthouse, un test simulé plutôt qu'une mesure réelle.
Pourquoi l'indicateur devient TBT au lieu d'INP en estimation labo ?
INP mesure la réactivité réelle aux interactions des internautes : il ne peut être mesuré que sur du trafic réel, pas sur un test de laboratoire où personne n'interagit avec la page. TBT est l'indicateur labo le plus proche : il estime le temps où la page reste bloquée et incapable de répondre rapidement à une interaction.
Pourquoi vérifier les données structurées sur une fiche produit ?
Les balises Product, Offer et Review/AggregateRating permettent à Google d'afficher des extraits enrichis (prix, note, disponibilité) directement dans les résultats de recherche, ce qui améliore le taux de clic.
L'outil peut-il détecter un prix qui varie selon les options (taille, couleur) ?
Il détecte la présence d'un prix affiché sur la page telle qu'elle est chargée, pas les variantes chargées dynamiquement après un clic. Si vos prix ne s'affichent qu'après sélection d'une option, testez l'URL avec l'option par défaut sélectionnée.
Les avis clients comptent-ils comme signal de confiance ?
Oui, l'outil recherche des mentions d'avis, de notes ou de témoignages dans le contenu de la page. Leur absence n'est pas éliminatoire, mais c'est l'un des signaux de confiance les plus efficaces sur une fiche produit e-commerce.
Tester un autre outil
À lire aussi
A/B testing : et si votre trafic ne suffisait pas ?
La majorité des sites n'ont pas le trafic nécessaire pour un test A/B fiable. Comment le savoir avant de lancer un test grâce au MDE, et quoi faire à la place quand ce n'est pas le cas.
Trop d'options tue la conversion : le paradoxe du choix
Multiplier les options sur une page produit semble généreux, mais réduit souvent la conversion. Comment simplifier sans appauvrir l'offre.
Tests A/B : pourquoi vos résultats ne sont pas toujours significatifs
Un test A/B arrêté trop tôt ou mené sur un échantillon trop petit ne prouve rien. Comment calculer la significativité, éviter le peeking et fiabiliser vos résultats.