Verifica del traffico: come assicurarsi che i link portino al dominio corretto

Cosa si considera una transizione verso il dominio corretto

Il traffico arriva sul dominio corretto quando l'utente, dopo tutti i reindirizzamenti, apre una pagina sull'host di destinazione. Non basta controllare l'indirizzo inserito nella descrizione dello stream, nel profilo o nella pubblicità: il link può passare attraverso un accorciatore, un tracker, un vecchio dominio, una landing page intermedia o un georedirect.

Controlla non solo il nome del dominio, ma anche la sua variante: con e senza www, HTTP e HTTPS, dominio principale e sottodominio. Gli indirizzi site.example, www.site.example e promo.site.example possono appartenere allo stesso progetto, ma per il browser, l'analytics e i log sono host diversi.

Apri il link come lo apre il pubblico

Passa al link dal luogo reale in cui è pubblicato: dalla descrizione della diretta, dal profilo, dal messaggio fissato, dal post o dall'annuncio. Dopo il caricamento della pagina controlla la barra degli indirizzi. È importante l'URL rimasto nel browser, non l'indirizzo iniziale della pubblicazione.

• Confronta l'host finale con il dominio della landing page.
• Controlla il percorso: il link può portare al dominio corretto, ma a una sezione obsoleta.
• Assicurati che la transizione da mobile non finisca su un sottodominio tecnico.
• Confronta il risultato per il link con e senza tag UTM.
• Verifica se i parametri della campagna si sono conservati dopo tutti i passaggi.

Limite della verifica manuale: mostra un solo scenario — il tuo browser, dispositivo, regione e set di cookie. Per una parte del pubblico le regole possono funzionare diversamente.

Controlla l'intera catena di redirect nel browser e tramite curl

Per la verifica tecnica usa curl con i parametri -I e -L: il comando mostrerà le intestazioni delle risposte e seguirà i reindirizzamenti. Cerca gli stati 301, 302, 307, 308 e le intestazioni Location. Indicano verso quale indirizzo il server dirige l'utente a ogni passaggio.

Per la verifica in un browser reale apri gli strumenti per sviluppatori, vai alla scheda Network e attiva Preserve log. Poi apri il link originale. Nell'elenco delle richieste sono visibili i redirect, il documento finale e le richieste che vengono eseguite dopo il caricamento della pagina.

1. Attiva Preserve log affinché l'elenco non si svuoti dopo il reindirizzamento.
2. Se necessario, disattiva la cache del browser.
3. Apri il link originale dalla pubblicazione o incollalo in una nuova scheda.
4. Trova le risposte con stato 3xx.
5. Confronta il Request URL di ogni passaggio con il valore Location.
6. Controlla il dominio e l'URL dell'ultimo documento con stato 200.

Quando il vecchio dominio nella catena è normale e quando è un errore

Un vecchio dominio nella catena non indica sempre un problema. Dopo un trasferimento è normale un percorso del tipo old-site.example/stream → site.example/stream: il vecchio indirizzo riceve la richiesta e reindirizza permanentemente l'utente alla pagina equivalente del nuovo sito. Il dominio finale è corretto, il percorso è conservato e i tag UTM non sono scomparsi.

È un bug la situazione in cui old-site.example/stream porta alla home del nuovo sito, a un'altra landing page o lascia l'utente sul vecchio dominio. Un problema separato si verifica se dopo il redirect scompare la stringa dopo il punto interrogativo: l'utente arriva sulla pagina giusta, ma l'analytics perde utm_source, utm_medium e utm_campaign.

Controlla non solo il dominio finale, ma anche il percorso con i parametri. Una transizione verso site.example senza la pagina o i tag necessari può distorcere i dati della campagna tanto quanto una transizione verso un host estraneo.

Tieni conto dei redirect JavaScript e dei parametri del link

curl è comodo per le risposte del server, ma non sempre vede i reindirizzamenti avviati da uno script dopo il caricamento della pagina. DevTools nel browser aiuta a notare questo scenario: prima si apre una pagina intermedia, poi lo script cambia l'indirizzo o invia l'utente su un altro dominio.

In Network controlla non solo il documento principale, ma anche il momento in cui l'indirizzo cambia dopo il suo caricamento. Se i tag UTM sono scomparsi, confronta l'URL originale, il valore Location e la stringa finale nella barra degli indirizzi. Così puoi capire a quale passaggio la regola di redirect ha scartato i parametri.

Limite del passaggio di tutti i parametri senza verifica: sul dominio di destinazione possono finire valori tecnici superflui. Per i link importanti vale la pena definire in anticipo quali tag, codici promozionali e parametri di affiliazione devono essere conservati.

Controlla i browser integrati nelle app

I social network, i messenger e le piattaforme di streaming spesso aprono il link non nel browser principale del dispositivo, ma in uno integrato. Tale browser può trasmettere un user-agent diverso, limitare gli script, non salvare i cookie o gestire i redirect in modo differente.

Apri il link direttamente dall'app della piattaforma in cui è pubblicato. Poi ripeti il test tramite la voce «Apri nel browser», se disponibile. Confronta il dominio finale, il percorso, i tag UTM e il comportamento del modulo, del pagamento o dell'autenticazione.

Limite della verifica nel browser integrato: non tutte le app permettono di vedere la catena tecnica delle richieste. È comunque importante, perché è spesso così che passa il pubblico da mobile.

Confronta le transizioni da regioni e condizioni diverse

Se il sito utilizza georedirect, CDN o versioni diverse delle landing page, ripeti la verifica tramite VPN, proxy o un dispositivo remoto nella regione desiderata. Confronta il dominio finale, il percorso, i parametri URL e il contenuto della landing page.

Controlla non solo il paese, ma anche la lingua del browser, l'autenticazione, i cookie e il tipo di dispositivo. Queste condizioni possono influire sul percorso: ad esempio, un utente di una regione viene inviato a un sottodominio locale, mentre un visitatore senza cookie viene inviato a una landing page generica.

Limite di VPN e proxy: non riproducono sempre completamente le condizioni di uno spettatore reale. La geolocalizzazione può essere determinata da più segnali, quindi questo test conferma un possibile problema, ma non copre tutto il pubblico.

Conferma il dominio in Yandex Metrica e GA4

In Yandex Metrica consulta i report per pagine di ingresso e URL delle pagine. Filtra i dati per indirizzo completo o dominio desiderato, poi aggiungi un segmento per tag UTM, sorgente o campagna. Così puoi vedere su quale host sono iniziate le visite dopo una specifica pubblicazione.

In GA4 per questa verifica usa la dimensione Hostname insieme alla landing page, alla sorgente di sessione e alla campagna. Confronta quante sessioni sono arrivate sul dominio principale, sul vecchio indirizzo e sui sottodomini importanti. Se il tag è installato su più host, il report mostra rapidamente la commistione di traffico.

Limite dell'analytics: i contatori non registrano una parte delle visite a causa di blocker, JavaScript disattivato o chiusura della pagina prima del caricamento del tag. Inoltre i dati non aiutano per un dominio in cui il contatore non è affatto installato.

Verifica le richieste nei log del server

I log del server confermano quali richieste sono realmente arrivate all'infrastruttura del sito. Per la verifica servono campi con ora, Host, URL, codice di risposta, user-agent e referer, se viene trasmesso. Cerca le richieste nel periodo di lancio del link e osserva separatamente le richieste al vecchio dominio e a quello di destinazione.

Le risposte 301, 302, 307 e 308 indicheranno che il server ha reindirizzato l'utente. Le richieste con stato 200 verso l'host di destinazione confermeranno che la pagina è stata servita dal dominio corretto. Se nei log ci sono transizioni verso il vecchio host, ma non ci sono richieste verso quello nuovo, controlla le regole di redirect e possibili errori di connessione.

Limite dei log: contengono bot, scanner e richieste tecniche. Il referer spesso manca nelle transizioni da app e messenger, quindi non sempre sarà possibile ricostruire la sorgente di una visita specifica.

Separa il dominio principale e i sottodomini nei report

La landing page, l'area personale, il pagamento e la knowledge base possono trovarsi su sottodomini diversi. Se li raccogli in un unico report senza segmenti, potresti non notare che il link dallo stream porta a promo.site.example invece che al sito principale, oppure a checkout.site.example prima della conoscenza dell'offerta.

Crea un segmento separato per l'host di destinazione e lascia un report generale per tutti i domini del progetto. Il primo aiuterà a controllare il traffico in ingresso, il secondo a vedere il percorso dell'utente tra landing page, pagamento e area personale.

Limite di un filtraggio troppo rigido: dal report può scomparire una normale transizione tra sottodomini e il funnel apparirà interrotto.

Checklist di verifica del link prima della pubblicazione

• Aprire il link dal luogo in cui lo vedrà il pubblico.
• Controllare il dominio finale, il percorso e i parametri nella barra degli indirizzi.
• Esaminare la catena 3xx e le intestazioni Location tramite curl o Network.
• Assicurarsi che il vecchio dominio conservi il percorso e i tag UTM durante il redirect.
• Ripetere la transizione nel browser integrato dell'app.
• Verificare un'altra regione, se vengono usate regole geografiche.
• Confrontare Hostname e landing page in analytics dopo il lancio.
• Confermare le richieste all'host corretto tramite i log del server.

Dopo il cambio di dominio, CDN, landing page o regole di redirect verifica sia i link nuovi che quelli vecchi. Le vecchie descrizioni degli stream, i video e i post fissati possono continuare a portare il pubblico su un percorso obsoleto.