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.

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.
Il link è solo l'ingresso
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.

Una policy utile chiarisce:
| Domanda | Perché 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.
| Scenario | Comportamento migliore |
|---|---|
| Ecommerce internazionale | Catalogo, valuta, spedizione e disponibilità corretti |
| Campagne per paese | Italia, Svizzera, Francia o Spagna su landing approvate |
| Prodotto non disponibile | Waitlist, rivenditore locale o messaggio chiaro |
| Vincoli legali | Allowed, blocked e fallback espliciti |
| Supporto e documentazione | Lingua 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.

| Contesto | Policy di destinazione |
|---|---|
| iOS | Universal Link se pronto, altrimenti App Store o web mobile |
| Android | Android App Link, altrimenti Google Play o web mobile |
| Desktop | Landing web, signup o QR per handoff mobile |
| Tablet | Spesso sito desktop, salvo app tablet dedicata |
| Browser in-app | Bridge page se il webview rompe il deep link |
| Dispositivo sconosciuto | Destinazione 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.

| Decisione | Default consigliato |
|---|---|
| Status code | 302 o 307 per test temporanei |
| Stickiness | Stessa variante durante la finestra di test |
| SEO | Nessuna esperienza diversa per i crawler |
| Canonical | Intenzione chiara se le varianti hanno URL separati |
| Durata | Chiudere il test, non lasciarlo vivo per mesi |
| Rollout | Aumentare 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à | Condizione | Esempio |
|---|---|---|
| 1 | Sicurezza o legale | Paese non servito verso pagina chiara |
| 2 | Override campagna | ?campaign=partner usa landing approvata |
| 3 | Dispositivo o OS | iOS, Android e desktop hanno fallback diversi |
| 4 | Paese o lingua | Italia, Svizzera, UE o globale |
| 5 | Peso A/B | Solo traffico idoneo entra nel test |
| 6 | Fallback | Tutti 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:
| Policy | Quando usarla |
|---|---|
| Preservare tutto | Fonte affidabile e attribuzione completa |
| Allowlist | UTMs, click ID e affiliati senza rumore |
| Aggiungere default | Uniformare campagna o canale |
| Rimuovere tutto | Destinazione sensibile o link pubblico rischioso |
| Riscrivere | Parametro 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

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
- Smart Redirect Routing per policy, pubblicazione, analytics e rollback
- Geo Redirects per paesi e regioni
- Device Targeting per app, store, mobile, tablet e desktop
- A/B Testing per split e rollout
- Advanced Redirect Rules per wildcard, regex e condizioni
- UTM Builder per preservare l'attribuzione
- Redirect Checker per QA
- Broken Link Monitor per destinazioni che cambiano
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 routingArticoli correlati
Visualizza tutto
Redirect API e regole as code: CI/CD per modifiche URL più sicure
Le regole di redirect sono configurazione di traffico in produzione. Devono essere revisionate, validate, provate in staging, pubblicate, monitorate e reversibili.

Geo redirect per ecommerce: store locali, valuta, lingua e fallback sicuri per SEO
I geo redirect aiutano i clienti a raggiungere lo store giusto, ma se sono troppo aggressivi possono nascondere pagine locali a utenti e crawler.