Comment créer un test A/B pour une URL dynamique ? Tutoriel pas à pas
Réponse rapide
Pour réaliser un test A/B sur des URL dynamiques (pages produits filtrées, pages personnalisées par session), utilisez un test de redirection d'URL qui normalise les paramètres de requête et attribue les utilisateurs à une URL de variante au niveau du serveur ou du CDN plutôt que dans le navigateur. Ainsi, chaque visiteur voit systématiquement la même variante d'une requête à l'autre, et les moteurs de recherche n'indexent pas plusieurs versions d'URL.
Points clés à retenir
- Les URL dynamiques avec des paramètres propres à la session nécessitent une répartition du trafic côté serveur ou en périphérie : les redirections uniquement côté navigateur provoquent du flickering et une attribution incohérente des variantes.
- Utilisez les motifs avec caractère générique (*) dans Mida pour couvrir des familles entières d'URL : une seule expérience peut ainsi s'appliquer à des milliers d'URL de produits, de catégories ou d'articles de blog à la fois.
- Normalisez les paramètres de requête dans vos règles de redirection afin que l'attribution des variantes reste cohérente sur les URL paginées, filtrées ou triées.
- Définissez des balises canoniques sur toutes les pages de variantes, pointant vers l'URL d'origine, afin d'empêcher les moteurs de recherche d'indexer du contenu dupliqué.
- Les bots et les robots d'indexation sont automatiquement exclus de la redirection : ils voient toujours l'URL de contrôle d'origine, ce qui garde votre index canonique propre.
Vous vous demandez peut-être : « Pourquoi ne pas simplement utiliser des URL classiques ? »
Vous le pourriez, mais il y a un hic : lorsque vous gérez un site e-commerce ou un site au contenu changeant, les URL dynamiques entrent en jeu. Ces URL sont générées à la volée pour chaque session ou chaque utilisateur. Par exemple, quand les utilisateurs filtrent ou trient les résultats, ou achètent avec des préférences personnalisées.
Le défi consiste à mener efficacement des tests A/B sur ces pages web générées dynamiquement, qui diffèrent d'un utilisateur à l'autre.
Voyons comment créer un test A/B pour une URL dynamique.
Qu'est-ce qu'une URL dynamique ?
Une URL dynamique est une adresse web générée automatiquement, généralement par une base de données, un CMS ou un serveur, plutôt que de pointer vers un fichier fixe créé manuellement. Vous les reconnaissez généralement à la présence de chaînes de requête, d'identifiants numériques ou de segments de chemin qui changent selon le produit, la catégorie ou la session de l'utilisateur.
Exemples d'URL dynamiques :
- Pages produits e-commerce : https://shop.example.com/product/running-shoes/id/4482
- Résultats de recherche avec filtres : https://example.com/search?category=shoes&color=red&sort=price_asc
- Pages de liste paginées : https://example.com/blog?page=3
- Landing pages personnalisées par session : https://example.com/lp/summer-sale?utm_id=abc123&user=xyz
Point commun essentiel : il n'existe aucune URL de « contrôle » canonique unique que vous pourriez saisir en dur dans une expérience. Il existe plutôt un motif d'URL, et ce motif doit être pris en compte dans son ensemble dans la configuration de votre expérience.
Pourquoi les URL dynamiques compliquent les tests A/B
Les outils de test A/B standard gèrent sans difficulté une URL fixe : afficher la variation A à 50 % des visiteurs, la variation B aux 50 % restants, puis mesurer laquelle convertit le mieux. Mais avec des URL dynamiques, une même page produit peut être visitée via des centaines de chemins d'URL différents. Si votre expérience ne cible qu'une seule URL précise, vous passez à côté de toutes les autres variantes de cette page.
Voici les trois principaux défis que posent les URL dynamiques :
1. Volume : trop d'URL à cibler une par une
Une boutique en ligne de 10 000 références peut avoir 10 000 URL de produits uniques. Créer une expérience distincte pour chacune n'est pas réaliste, et cela épuiserait instantanément votre quota mensuel d'utilisateurs testés. Il vous faut un moyen de cibler un motif d'URL, et non une URL spécifique.
2. Cohérence : les visiteurs doivent voir la même variante
Si un visiteur arrive sur /product/sneakers/id/1001 et voit la nouvelle mise en page, puis quitte la page et revient plus tard, il doit continuer à voir la nouvelle mise en page. L'attribution de la variante doit être persistante : liée au visiteur, et non à la chaîne d'URL qu'il a utilisée lors de cette session.
3. SEO : éviter les pénalités pour contenu dupliqué
Lorsque vous redirigez des utilisateurs vers l'URL d'une variante (par ex. /product-v2/sneakers/id/1001), les robots des moteurs de recherche peuvent découvrir et indexer cette URL séparément de l'originale. Sans balise canonique pointant vers l'originale, vous risquez des problèmes de contenu dupliqué : deux pages au contenu quasi identique qui se disputent les mêmes positions.
Outil de test A/B gratuit
Lancez votre prochain test A/B dans les règles de l'art
Éditeur visuel, script de 15 Ko, natif GA4 et gratuit à vie jusqu'à 100 000 visiteurs mensuels. Aucun développeur requis.
Cas d'usage courants des tests A/B sur URL dynamique
Les tests de redirection sur URL dynamique sont la bonne approche dans plusieurs scénarios courants :
- Refonte de pages produits e-commerce : tester une nouvelle mise en page de page produit sur l'ensemble de votre catalogue, sans dupliquer l'expérience pour chaque référence.
- Variantes de pages de catégorie ou de collection : comparer une présentation en grille et une présentation en liste sur toutes les URL de catégories filtrées (par ex. /category/shoes/*).
- Tests de modèles de blog ou de contenu : comparer un nouveau modèle d'article (/new-blog/*) à l'existant (/blog/*) sur l'ensemble de votre bibliothèque de contenus.
- Variantes du tunnel de paiement : rediriger les utilisateurs de /checkout/step1 vers /checkout-v2/step1 tout en conservant les paramètres dynamiques de commande et de session.
- Personnalisation de landing pages : tester des expériences de landing pages personnalisées dont les paramètres UTM ou les identifiants de campagne font partie du motif d'URL.
Structure d'une URL dynamique
Si votre objectif est de rediriger https://www.example.com/product/laptop/12345 vers https://www.example.com/product/laptop-test/12345 pour chaque produit, et pas seulement pour le produit 12345, il existe un moyen très simple d'y parvenir sans créer des milliers de tests pour chaque identifiant de produit.
Il vous suffit d'utiliser la correspondance par caractère générique.
Suivez simplement ces 3 étapes pour configurer rapidement la redirection d'URL dynamique :
Prérequis : vous devrez créer un compte Mida.so : il est totalement gratuit pour démarrer, jusqu'à 100 000 utilisateurs testés par mois.
1. Choisir le type de test

Tout d'abord, votre type de test doit être Split URL / Redirect Test. Une fois celui-ci sélectionné, veillez à configurer des règles de redirection pour chacune de vos variantes, c'est-à-dire les versions de l'élément ou des éléments que vous testez.
Choisir le bon type de test est important, car il détermine la façon dont Mida attribue les utilisateurs aux variantes. Pour un test de redirection, Mida enregistre l'attribution de la variante dans un cookie first-party sur le navigateur du visiteur, ce qui garantit qu'il voit toujours la même variante lors de ses visites suivantes, même si l'URL exacte change légèrement d'une session à l'autre.
2. Configurer l'URL de redirection et les caractères génériques

Configurez maintenant l'URL de la variation de base avec le lien d'origine, en remplaçant la partie dynamique par un astérisque (*). Configurez ensuite la variation 1 avec /laptop-test/*.
Par exemple, si votre URL est https://example.com/blog/what-is-SEO et que vous souhaitez tester une nouvelle structure de blog avec https://example.com/new-blog/what-is-SEO, vous pouvez créer les modèles avec astérisque https://example.com/blog/* et https://example.com/new-blog/*.
L'astérisque (*) est un caractère générique qui correspond à n'importe quelle suite de caractères à cet emplacement. Lorsqu'un visiteur arrive sur une URL correspondant au modèle de contrôle, Mida capture le segment dynamique et l'associe à l'URL de la variante correspondante, en conservant l'identifiant unique intact.
Vous pouvez aussi utiliser plusieurs caractères génériques dans un même modèle. Par exemple, https://shop.example.com/*/id/* correspondra à toute combinaison de catégorie et d'ID produit, ce qui permet à une seule expérience de couvrir tout votre catalogue produits en une fois.
Outil de test A/B gratuit
Lancez votre prochain test A/B dans les règles de l'art
Éditeur visuel, script de 15 Ko, natif GA4 et gratuit à vie jusqu'à 100 000 visiteurs mensuels. Aucun développeur requis.
3. Lancer le test

C'est terminé !
Votre configuration d'une expérience entre /laptop/(dynamic-ids) et /laptop-test/(dynamic-ids) est terminée. Vous pouvez maintenant définir l'objectif, répartir le trafic et publier votre test.
Avant de lancer, voici quelques dernières vérifications à effectuer :
- Définissez un objectif principal : choisissez un événement de conversion (un achat, l'envoi d'un formulaire, un clic) afin que Mida dispose d'une métrique claire à optimiser.
- Définissez une répartition du trafic adaptée : pour la plupart des tests, une répartition 50/50 est idéale. Si vous testez une variante plus risquée, envisagez de commencer avec 80/20 en faveur du contrôle.
- Vérifiez les balises canoniques : assurez-vous que vos pages variantes incluent une balise canonique pointant vers l'URL d'origine. Cela empêche les moteurs de recherche d'indexer la variante comme une page distincte.
Modèles pris en charge et exemples
Pour mieux comprendre ce qu'il est possible de faire avec les tests d'URL dynamiques en split test, voici quelques exemples de modèles pris en charge :
Scénario de configuration 1
Modèle de correspondance du contrôle : https://example.com/blog/*
Modèle de correspondance de la variante 1 : https://example.com/blog/*/v1
Modèle de correspondance de la variante 2 : https://example.com/blog/*?v=2
Résultat n° 1
Un utilisateur a visité cette URL : https://example.com/blog/what-is-seo
Correspondance avec la variante 1 : https://example.com/blog/what-is-seo/v1
Correspondance avec la variante 2 : https://example.com/blog/what-is-seo?v=2
Scénario de configuration 2
Modèle de correspondance du contrôle : https://shop.example.com/product/*/id/*
Modèle de correspondance de la variante 1 : https://shop.example.com/product/*/id/*-2
Résultat n° 2
Un utilisateur a visité cette URL : https://shop.example.com/product/apple-watch/id/1133
Variante 1 (en cas de correspondance) : https://shop.example.com/product/apple-watch/id/1133-2
Un utilisateur a visité cette URL : https://shop.example.com/product/samsumg-galaxy-14S/id/4439
Variante 1 (en cas de correspondance) : https://shop.example.com/product/samsumg-galaxy-14S/id/4439-2
Considérations SEO lors du test d'URL dynamiques
L'une des préoccupations les plus courantes des équipes concernant les tests A/B par redirection est leur impact sur le classement dans les moteurs de recherche. La bonne nouvelle : Google indique explicitement que les tests A/B sont autorisés et n'entraînent pas de pénalité, à condition de respecter quelques règles techniques. Pour aller plus loin, consultez notre guide complet sur l'impact des tests A/B sur le SEO.
Utilisez des balises canoniques sur toutes les pages variantes
Lorsque l'URL de votre variante (/laptop-test/12345) est une page distincte et indexable, Google peut l'explorer et la considérer comme un contenu quasi dupliqué par rapport à votre page d'origine (/laptop/12345). Pour l'éviter, ajoutez sur vos pages variantes une balise canonique pointant vers l'URL d'origine. Cela indique aux moteurs de recherche que la variante est une version de test, et non une destination permanente méritant d'être indexée séparément.
Mida utilise une redirection JavaScript, pas une redirection serveur 301 ou 302
Mida effectue la redirection entièrement dans le navigateur via JavaScript : le script détecte le modèle d'URL correspondant et redirige l'utilisateur vers l'URL de la variante en utilisant window.location.href. Cela signifie qu'aucun code de statut HTTP 301 ou 302 n'intervient au niveau du serveur. La redirection est invisible pour les robots des moteurs de recherche, car les bots sont totalement exclus de l'expérience (voir ci-dessous). Pour les moteurs de recherche, votre URL d'origine reste la seule URL qu'ils explorent et indexent.
Les bots et les robots d'exploration sont exclus, et c'est voulu
Mida exclut automatiquement les bots et robots d'exploration connus des expériences de redirection. Lorsqu'un robot de moteur de recherche visite une page couverte par un test d'URL dynamique, il voit l'URL de contrôle d'origine sans redirection, c'est-à-dire la même page que celle que vos vrais visiteurs voient lorsqu'ils sont affectés au groupe de contrôle. Googlebot indexe donc toujours la version canonique de votre page, et vous n'avez jamais à craindre que le robot suive une redirection de test vers l'URL d'une variante. Google approuve explicitement cette approche pour les tests A/B : exclure les robots de la diffusion des variantes n'est pas du cloaking, car vous ne servez pas de contenu trompeur, vous gardez simplement le test réservé aux visiteurs humains réels.
Limitez la durée des tests
Laisser un test de redirection tourner indéfiniment crée une séparation permanente entre deux structures d'URL, ce qui peut perturber les moteurs de recherche avec le temps. La plupart des tests devraient se terminer en 2 à 4 semaines, une fois la signification statistique atteinte. Déployez la version gagnante et arrêtez rapidement le test.
Test d'URL dynamiques ou test A/B basé sur JavaScript
Avant de configurer un test de redirection pour des URL dynamiques, il est utile de comprendre dans quels cas cette approche est la plus adaptée, par rapport à un test A/B classique basé sur JavaScript sur la même URL.
Il est également utile de savoir à quelle fréquence chacune des approches l'emporte. Nous publions les taux de victoire des tests d'URL scindées issus d'expériences réelles menées sur Mida, ainsi que le piège de mesure qui les gonfle discrètement. Lisez ce contenu avant de mettre en ligne un test de redirection. Il existe aussi des analyses par type de page, notamment pour les pages produit et les pages de tarifs.
Utilisez un test de redirection d'URL dynamique lorsque :
- La variante nécessite un modèle de page, une route ou une logique back-end complètement différents.
- Vous avez besoin que l'expérience couvre toute une famille d'URL (des milliers de pages produit ou d'articles) avec une seule configuration.
- Les pages de contrôle et de variante existent déjà sous forme d'URL distinctes et vous souhaitez répartir le trafic entre elles.
Utilisez un test A/B basé sur JavaScript sur la même URL lorsque :
- Vous ne modifiez que des éléments visuels (couleurs, textes, emplacement des boutons, ajustements de mise en page) sur une page existante.
- Vous souhaitez la configuration SEO la plus simple possible (une seule URL canonique, aucune surcharge liée à la redirection).
- Votre site est une application monopage dans laquelle le navigateur n'émet pas de nouvelles requêtes HTTP lors de la navigation.
En règle générale : si la variante que vous souhaitez tester nécessite des pages fondamentalement différentes, utilisez un test de redirection. Si vous modifiez des éléments d'une page existante, un test basé sur JavaScript est plus simple et pèse moins sur le SEO. Vous pouvez en savoir plus sur le split testing sans changer l'URL ici.
Outil de test A/B gratuit
Lancez votre prochain test A/B dans les règles de l'art
Éditeur visuel, script de 15 Ko, natif GA4 et gratuit à vie jusqu'à 100 000 visiteurs mensuels. Aucun développeur requis.
Bonnes pratiques pour les tests de redirection d'URL dynamiques
- Commencez par les structures d'URL à fort trafic : les tests avec caractères génériques fonctionnent mieux lorsque la structure d'URL reçoit assez de visiteurs par jour pour atteindre la signification statistique en quelques semaines. Testez d'abord vos pages les plus visitées pour obtenir des résultats plus rapidement.
- Faites correspondre précisément la structure complète : si votre contrôle est https://shop.example.com/product/*/id/*, assurez-vous que la position des caractères génériques correspond exactement aux bons segments de chemin dans l'URL de la variante. Des caractères génériques mal alignés redirigeront discrètement les visiteurs vers de mauvaises pages.
- Testez un seul changement majeur à la fois : la redirection doit mener vers une version de la page réellement différente : un nouveau modèle, une mise en page différente, une hiérarchie de l'information restructurée. Évitez de créer un test de redirection pour un petit ajustement de texte ; utilisez plutôt un test JavaScript.
- Surveillez la vitesse des pages de variante : votre URL de variante peut être servie par une route différente, avec un profil de chargement différent. Vérifiez qu'elle ne se charge pas sensiblement plus lentement que le contrôle, car la vitesse des pages influence à la fois les conversions et le classement SEO.
- Segmentez par type d'appareil si nécessaire : si votre variante est optimisée pour mobile mais pas pour ordinateur, utilisez la segmentation d'audience dans Mida pour limiter le test au type d'appareil concerné. Lancer une refonte spécifique au mobile sur l'ensemble du trafic diluera vos résultats.
- Calculez d'abord la taille d'échantillon nécessaire : avant le lancement, utilisez un calculateur de taille d'échantillon pour estimer le nombre de visiteurs dont vous avez besoin par variante afin de détecter l'effet attendu. Cela vous évite de faire tourner les tests trop longtemps ou de les arrêter trop tôt.
Erreurs courantes à éviter
Créer une expérience distincte par URL
C'est l'erreur de débutant la plus fréquente. Créer une expérience de redirection distincte pour chaque identifiant produit de votre catalogue épuisera votre quota mensuel d'utilisateurs testés et rendra l'analyse des résultats quasiment impossible. Utilisez toujours des structures avec caractères génériques pour regrouper des familles d'URL dans une seule expérience.
Ne pas définir d'objectif de conversion
Lancer un test de redirection sans objectif défini signifie que vous aurez des données de trafic, mais aucune idée de la variante réellement la plus performante. Configurez toujours au moins un objectif principal (achat, envoi de formulaire, clic sur un bouton) avant la publication. Des objectifs secondaires, comme la profondeur de défilement ou le temps passé sur la page, peuvent compléter l'analyse, mais ne doivent pas être votre seule mesure du succès.
Arrêter les tests trop tôt
Les tests de redirection couvrant de nombreuses URL dynamiques accumulent souvent le trafic rapidement, ce qui peut faire paraître les premiers résultats significatifs alors qu'ils ne le sont pas. Attendez la fin de la durée de test prévue et la confirmation de la signification statistique avant de désigner un gagnant. Interrompre les tests prématurément est ce qu'on appelle le problème du peeking, l'une des sources de faux positifs les plus courantes en expérimentation.
Oublier de terminer le test après le déploiement de la version gagnante
Une fois que vous avez un gagnant et que vous avez mis en place le changement de façon permanente sur votre site, arrêtez l'expérience Mida. Laisser un test de redirection actif après avoir déjà déployé l'URL gagnante crée des redirections inutiles pour tous les visiteurs et continue de répartir un trafic qui devrait tout entier être dirigé vers l'expérience canonique.
Questions fréquentes
Puis-je réaliser un test de redirection d'URL dynamique sur une boutique Shopify ? Oui. Les URL des produits Shopify suivent une structure cohérente (/products/[handle]), ce qui les rend idéales pour les tests de redirection avec caractères génériques. Définissez votre structure de contrôle sur https://yourstore.myshopify.com/products/* et votre variante sur la nouvelle structure d'URL. Assurez-vous que le script de Mida est installé via le thème Shopify ou via un conteneur GTM avant le lancement.
Le test de redirection d'URL dynamique ralentira-t-il mon site ? La redirection de Mida s'effectue dans le navigateur avant le chargement de la page de variante, à l'aide d'un script léger. La redirection elle-même n'ajoute généralement que quelques millisecondes de latence. Le facteur de vitesse le plus pertinent est de savoir si votre page de variante est aussi rapide que votre page de contrôle : analysez les deux avec PageSpeed Insights pour les comparer avant le lancement.
Comment vérifier que mon modèle avec caractère générique correspond bien aux bonnes URL ? Utilisez le mode aperçu intégré de Mida pour visiter une URL précise et confirmer la variante qui vous est attribuée. Vous pouvez aussi ouvrir les outils de développement de votre navigateur : si la redirection fonctionne correctement, vous verrez la page passer de l'URL d'origine à l'URL de la variante. Mida effectue cette opération sous forme de redirection JavaScript à l'aide de window.location.href, vous verrez donc l'URL finale de la variante dans la barre d'adresse et dans l'onglet réseau en tant que document chargé.
Puis-je tester des variations de paramètres de requête avec des tests de redirection d'URL dynamiques ? Oui. Vous pouvez inclure des paramètres de requête dans vos modèles avec caractère générique. Par exemple, tester /search?category=shoes&* face à /search-v2?category=shoes&* couvrira toutes les combinaisons de filtres au sein de cette catégorie. Faites attention à l'ordre des paramètres : normalisez vos modèles pour éviter les trous de couverture lorsque les mêmes paramètres apparaissent dans un ordre différent.
Comment l'attribution des variantes reste-t-elle cohérente d'une visite à l'autre ? Mida enregistre l'attribution de la variante dans un cookie first-party sur le navigateur du visiteur. Même si un utilisateur visite plusieurs URL dynamiques couvertes par la même expérimentation, il verra toujours la même variante. L'attribution se fait au niveau du visiteur et non de l'URL : elle persiste donc d'une page à l'autre au sein de la même famille d'URL.
Le test de redirection d'URL dynamique fonctionne-t-il avec les applications monopage (SPA) ? Les SPA qui utilisent un routage côté client (React Router, Vue Router, etc.) gèrent les URL différemment : la page ne se recharge pas entièrement lors de la navigation, et le navigateur n'émet donc jamais de nouvelle requête HTTP. Dans ces cas, un test de redirection peut ne pas se déclencher correctement. Pour les SPA, un test JavaScript directement dans la page est généralement plus fiable. Consultez le guide Mida sur les SPA pour savoir comment mener des expérimentations sur des applications rendues côté client.
Combien de caractères génériques puis-je utiliser dans un même modèle d'URL ? Vous pouvez utiliser plusieurs caractères génériques dans un même modèle. Par exemple, https://shop.example.com/*/category/*/id/* correspondra aux URL comportant trois segments dynamiques. Chaque position de caractère générique dans le modèle de contrôle correspond à la même position dans le modèle de la variante, ce qui permet de conserver correctement les valeurs dynamiques lors de la redirection.
Conclusion
Le test A/B d'URL dynamiques est une technique puissante qui permet de mener des expérimentations sur l'ensemble de votre catalogue produits, de votre bibliothèque de contenus ou de votre tunnel de paiement, sans créer un test pour chaque URL. La clé consiste à utiliser des modèles avec caractères génériques pour cibler des familles d'URL, à y associer des balises canoniques adaptées sur les pages des variantes pour protéger votre SEO, et à laisser les expérimentations tourner jusqu'à confirmation de la signification statistique.
Avec Mida, la configuration prend quelques minutes, pas des jours. Vous n'avez besoin d'aucune ressource d'ingénierie pour mettre en place des règles de redirection avec caractères génériques, et le même script léger qui gère vos tests A/B standard alimente aussi des expérimentations d'URL dynamiques sur des milliers de pages simultanément.
Prêt à lancer votre première expérimentation d'URL dynamique ? Créez un compte Mida gratuit et démarrez en moins de cinq minutes, sans développeur.