Smart Redirect Routing : géo, appareil, A/B test et règles conditionnelles

Une redirection paraît simple tant que tout le monde doit arriver sur la même page. Dès qu'une campagne devient sérieuse, ce n'est presque plus le cas.

Un clic depuis la France peut devoir aller vers une offre en euros, un clic depuis le Canada vers une page française différente, et un clic depuis la Suisse vers une page qui explique la disponibilité. Un iPhone doit parfois ouvrir l'app ou l'App Store, alors qu'un desktop doit rester sur le site web. Les liens Google Ads, Meta, emailing, QR code ou affiliation doivent conserver leurs UTM. Un test A/B doit garder la même variante pour un visiteur. Et si aucune règle ne correspond, le fallback doit être choisi, pas subi.

Le Smart Redirect Routing consiste à transformer un lien public en politique de routage contrôlée.

Avec UrlEdge, cette politique est publiée à l'edge. Elle peut combiner pays, appareil, langue, query, header, cookie, campagne, pondération A/B et fallback, avec analytics et rollback. L'objectif n'est pas d'ajouter de la complexité. L'objectif est d'éviter que la logique post-clic vive en morceaux dans le CMS, le CDN, le serveur, un script A/B et une feuille de recette.

Le lien n'est que la partie visible

Dans les équipes françaises, on voit souvent la logique se disperser :

• une redirection géographique dans le CDN
• une redirection mobile dans WordPress, PrestaShop, Shopify ou le front headless
• un test A/B côté client
• une règle UTM dans la landing page
• un fallback connu seulement par l'agence ou le growth manager

Tout tient jusqu'au jour où l'on change une offre, une app, une campagne paid ou une arborescence de site. La question n'est alors plus "où rediriger ?", mais "quelle règle a gagné, qui l'a validée, que conserve-t-on, et comment revient-on en arrière ?"

Une politique de routage doit répondre à ces questions :

Cette logique mérite une console, une recette et un historique. Pas une succession de petites exceptions invisibles.

La géolocalisation doit servir l'intention

Une redirection géolocalisée n'est pas utile parce qu'elle est possible. Elle est utile quand le visiteur a réellement une meilleure destination.

Les informations pays peuvent être disponibles à l'edge. Cloudflare Workers expose par exemple des métadonnées via request.cf, dont le pays. Cela suffit pour beaucoup de scénarios, mais ne remplace pas une décision éditoriale et SEO.

Le piège SEO consiste à forcer chaque visiteur vers une version locale sans possibilité claire de revenir au global, ou à montrer un comportement différent aux robots. Si la page globale répond bien à l'intention, gardez-la. Si une page locale est meilleure, documentez canonical, fallback et comportement crawler.

Le routage par appareil ne concerne pas seulement les apps

Les recherches autour de "redirection mobile desktop" ou "redirection par appareil" cachent plusieurs besoins : app install, QR code, webview social, desktop handoff, page mobile plus légère, ou fallback quand l'app n'est pas installée.

Exemples de politique :

Depuis la fin de Firebase Dynamic Links, beaucoup d'équipes doivent reprendre cette couche en main. UrlEdge peut gérer la redirection par appareil et les fallback ; l'ouverture native de l'app dépend toujours de la configuration Universal Links et Android App Links.

Les A/B tests par redirection sont utiles quand la destination change

Un A/B test par redirect est pertinent lorsque l'expérience testée est une destination différente :

• deux landing pages
• offre régionale contre offre globale
• nouveau pricing envoyé à une fraction du trafic
• canary release d'un nouveau front
• rotation de pages partenaire ou affiliation

Ce n'est pas un remplacement d'outil d'expérimentation produit. Si vous avez besoin d'événements fins, de segments complexes et de variantes UI dans la même app, utilisez une plateforme dédiée. UrlEdge intervient avant le rendu de la page, au niveau du trafic.

Les règles de base :

Google recommande, pour les tests de site, d'éviter le cloaking et d'utiliser des redirections temporaires quand l'URL originale envoie vers une variante. Cela cadre bien avec des règles 302 pondérées.

Les conditions doivent avoir un ordre

Le danger n'est pas d'avoir trop peu de conditions. Le danger est de ne pas savoir laquelle gagne.

Un ordre mal pensé crée des incidents discrets : la variante A/B prend du trafic exclu, une règle mobile efface un ID affilié, une règle pays envoie une campagne paid vers une page sans UTM.

Les paramètres font partie du routage

Dans la pratique, beaucoup d'erreurs viennent des query strings.

Les équipes acquisition ont besoin de utm_source, utm_medium, utm_campaign, click IDs, codes promo, IDs affiliés et sub IDs. Les équipes app peuvent transmettre un contexte d'invitation. Les équipes e-commerce peuvent utiliser devise, locale, produit ou collection.

La redirection est le moment où l'attribution est conservée ou perdue. Elle doit donc faire partie de la politique de routage.

Recetter la matrice avant le trafic

Chaque condition ajoute des chemins possibles. La recette doit tester le comportement, pas seulement la syntaxe.

À vérifier :

• France, Belgique, Suisse, UE, fallback global
• iOS, Android, desktop, tablette, appareil inconnu
• URL avec et sans UTM
• paid, affiliation, organique, QR
• première visite et visiteur qui revient sur un A/B test
• statut final des destinations
• nombre de hops
• ordre des règles et fallback
• analytics par pays, appareil, règle, action et destination
• rollback vers le dernier snapshot validé

Le bon niveau de confiance : pour une URL source et un contexte donné, l'équipe sait prédire la destination avant de publier.

Où UrlEdge intervient

UrlEdge est utile quand une redirection a plusieurs destinations, plusieurs owners et un risque business.

• Smart Redirect Routing pour gouvernance, publication, analytics et rollback
• Geo Redirects pour pays et régions
• Device Targeting pour app, stores, mobile, tablette et desktop
• A/B Testing pour splits pondérés et rollouts
• Advanced Redirect Rules pour wildcard, regex et conditions
• UTM Builder pour préserver l'attribution
• Redirect Checker pour la recette
• Broken Link Monitor quand les destinations peuvent changer après lancement

FAQ

Qu'est-ce que le Smart Redirect Routing ?

C'est le fait d'envoyer une même URL publique vers différentes destinations selon le pays, l'appareil, la langue, les paramètres, la campagne, la pondération A/B et le fallback.

Est-ce la même chose qu'une redirection géolocalisée ?

Non. La géolocalisation est une condition. Le smart routing combine géo, appareil, langue, query, header, cookie, split A/B et fallback dans une seule règle gouvernée.

Faut-il utiliser 301 ou 302 pour un A/B test ?

Pour un test, utilisez en général 302, car l'expérience est temporaire. Réservez 301 aux mouvements durables.

UrlEdge remplace-t-il une plateforme d'expérimentation ?

Non. Il convient aux tests de destinations, campagnes et canary releases. Les tests produit profonds et l'analyse événementielle restent le rôle d'outils dédiés.

Références

• Cloudflare Docs: URL forwarding and redirect execution order
• Cloudflare Workers Docs: Request and cf metadata
• Google Search Central: A/B testing best practices for Search
• Google Search Central: Redirects and Google Search