UrlEdge
Torna al blog
5 maggio 2026 UrlEdge Editorial7 min read

Smart Redirect Routing: geo, dispositivo, A/B test e regole condizionali

Un link di campagna può dover cambiare destinazione in base a paese, dispositivo, lingua, UTM, peso del test e fallback. Ecco come progettare questa logica senza nasconderla nel codice.

Mappa di routing editoriale in cui un link si divide per paese, dispositivo, A/B test e fallback all'edge

Un redirect è semplice solo quando ogni clic deve arrivare alla stessa pagina. Nelle campagne reali, soprattutto tra ecommerce, app, QR code, email, affiliazioni e landing page locali, quasi mai è così.

Un visitatore dall'Italia può dover vedere una pagina con spedizioni e IVA corrette. Un clic dalla Svizzera o dalla Spagna può richiedere un altro storefront. Un iPhone deve andare verso Universal Link, App Store o web mobile; Android verso Android App Link, Google Play o fallback. Un test A/B deve mantenere la stessa variante. E UTM, coupon e ID partner non devono sparire nel passaggio.

Lo Smart Redirect Routing trasforma un link pubblico in una policy di instradamento, non in un semplice campo "destination".

UrlEdge pubblica questa policy all'edge: paese, dispositivo, lingua, query, header, cookie, campagna, split A/B e fallback possono vivere nella stessa regola, con analytics e rollback. Il punto non è complicare i redirect. Il punto è rendere governabile la logica che decide dove finiscono i clic.

Nelle aziende italiane la logica spesso finisce sparsa:

  • redirect geografico in CDN
  • redirect mobile nel tema Shopify, WooCommerce, Magento o headless
  • A/B test lato client
  • UTM gestiti dalla landing
  • fallback concordato in chat
  • regole vecchie in Nginx, plugin o pannello hosting

Quando cambia una campagna o un catalogo, diventa difficile capire quale livello ha deciso la destinazione.

Smart redirect routing policy with geo, device, experiment, and fallback branches

Una policy utile chiarisce:

DomandaPerché conta
Quale sorgente entra?Dominio, path, wildcard, regex, slug di campagna, QR o URL pubblica
Quale contesto conta?Paese, dispositivo, lingua, OS, browser, query, header, cookie
Quale condizione vince?Sicurezza, campagna esatta, dispositivo, paese, test, fallback
Quale destinazione riceve?Store, app store, landing, supporto, blocco o fallback
Come si divide il traffico?Pesi A/B, rollout graduale, varianti campagna o canary
Cosa va preservato?Path, query, UTM, ID affiliato, coupon, sub ID
Come si torna indietro?Snapshot precedente, destinazione fallback, pausa campagna, owner

Questa logica deve essere leggibile prima del go-live.

Geo routing: locale quando serve davvero

Il redirect geografico ha senso quando il mercato cambia davvero la destinazione.

ScenarioComportamento migliore
Ecommerce internazionaleCatalogo, valuta, spedizione e disponibilità corretti
Campagne per paeseItalia, Svizzera, Francia o Spagna su landing approvate
Prodotto non disponibileWaitlist, rivenditore locale o messaggio chiaro
Vincoli legaliAllowed, blocked e fallback espliciti
Supporto e documentazioneLingua locale solo se il contenuto esiste

Cloudflare Workers espone metadati della richiesta tramite request.cf, incluso il paese. Questo aiuta, ma non decide la strategia. Per SEO, evita comportamenti simili a cloaking e mantieni chiara l'intenzione canonica.

Device routing: app, web, QR e social browser

Molti clic arrivano da Instagram, TikTok, WhatsApp, email o QR code. Lo stesso URL deve comportarsi bene in contesti diversi.

Device and geography decision map for app, store, web, and regional destinations

ContestoPolicy di destinazione
iOSUniversal Link se pronto, altrimenti App Store o web mobile
AndroidAndroid App Link, altrimenti Google Play o web mobile
DesktopLanding web, signup o QR per handoff mobile
TabletSpesso sito desktop, salvo app tablet dedicata
Browser in-appBridge page se il webview rompe il deep link
Dispositivo sconosciutoDestinazione web stabile

Dopo Firebase Dynamic Links, questa parte non può restare improvvisata. UrlEdge può gestire redirect e fallback per dispositivo; l'apertura nativa dell'app richiede comunque Universal Links e Android App Links corretti.

A/B test via redirect: quando cambia la destinazione

Lo split via redirect è adatto quando si testano destinazioni:

  • landing A contro landing B
  • offerta locale contro offerta globale
  • nuovo pricing su una piccola quota
  • rollout canary di un nuovo frontend
  • pagine partner o affiliate rotation

Non sostituisce una piattaforma di experimentation completa. È un traffic splitter all'edge.

A/B redirect split and staged rollout controlled before the page renders

DecisioneDefault consigliato
Status code302 o 307 per test temporanei
StickinessStessa variante durante la finestra di test
SEONessuna esperienza diversa per i crawler
CanonicalIntenzione chiara se le varianti hanno URL separati
DurataChiudere il test, non lasciarlo vivo per mesi
RolloutAumentare peso solo con monitoraggio pulito

Google consiglia di evitare cloaking nei test e usare redirect temporanei verso le varianti. Questo si allinea con regole 302 e split ponderati.

Le condizioni hanno bisogno di priorità

Un ordine pratico:

PrioritàCondizioneEsempio
1Sicurezza o legalePaese non servito verso pagina chiara
2Override campagna?campaign=partner usa landing approvata
3Dispositivo o OSiOS, Android e desktop hanno fallback diversi
4Paese o linguaItalia, Svizzera, UE o globale
5Peso A/BSolo traffico idoneo entra nel test
6FallbackTutti gli altri raggiungono una destinazione stabile

Se l'ordine è sbagliato, il test può prendere traffico escluso, una regola mobile può perdere un ID affiliato, o una regola paese può mandare paid traffic su una pagina senza UTM.

Query e UTM fanno parte della rotta

Una policy seria decide cosa fare con i parametri:

PolicyQuando usarla
Preservare tuttoFonte affidabile e attribuzione completa
AllowlistUTMs, click ID e affiliati senza rumore
Aggiungere defaultUniformare campagna o canale
Rimuovere tuttoDestinazione sensibile o link pubblico rischioso
RiscrivereParametro che decide path o destinazione

L'attribuzione può rompersi prima che analytics veda la visita. Per questo il redirect è parte del sistema di misurazione.

Testare la matrice prima del traffico

Rule QA and rollback workflow for smart redirect routing

Prima del lancio controlla:

  • Italia, UE, Svizzera e fallback
  • iOS, Android, desktop, tablet e sconosciuto
  • URL con e senza UTM, coupon e affiliati
  • paid, organic, email, QR e social
  • prima visita e ritorno nel test A/B
  • status finale, hop e loop
  • priorità, fallback e rollback
  • analytics per paese, dispositivo, regola e destinazione

Il criterio è semplice: dato un URL e un contesto, il team sa prevedere la destinazione.

Dove entra UrlEdge

FAQ

Che cos'è lo Smart Redirect Routing?

È il routing di una stessa URL verso destinazioni diverse in base a paese, dispositivo, lingua, parametri, campagna, pesi A/B e fallback.

È uguale a un redirect geografico?

No. Il redirect geografico è una condizione. Lo smart routing combina più condizioni in una regola governata.

A/B test via redirect: 301 o 302?

Di solito 302, perché il test è temporaneo. I codici permanenti servono per cambiamenti permanenti.

Riferimenti

Crea regole di smart routing all'edge

Instrada clic per paese, dispositivo, lingua, parametri, pesi A/B e fallback senza nascondere la logica nel sito.

Esplora lo smart routing

Articoli correlati

Visualizza tutto