Mettere online un sito statico non chiude il lavoro. Subito dopo arriva la domanda più utile: qualcuno ha aperto il link?
Conta anche capire da dove arrivano le visite, quali pagine vengono aperte, se il sito viene visto da telefono o desktop, quali paesi compaiono e se immagini, PDF, video o font pesanti stanno già consumando troppa banda.
Per questa prima lettura non serve sempre installare una soluzione di analisi completa. Spesso bastano statistiche chiare, legate al progetto appena pubblicato.
Parti dalla domanda che il sito deve rispondere
Le statistiche diventano confuse quando ogni numero sembra importante allo stesso modo.
Un sito statico ha spesso uno scopo preciso. Può essere un portfolio online, un curriculum online, una landing page, un'anteprima cliente, una documentazione, un progetto scolastico, un sito generato con IA o una pagina con PDF. Ogni caso richiede una lettura diversa.
| Tipo di sito | Prima domanda | Dati da guardare |
|---|---|---|
| Portfolio online | Il link è arrivato a clienti o recruiter? | Visitatori, referrer, pagine principali, dispositivi |
| Landing page | Quale canale porta traffico? | Referrer, link UTM, pagine principali, paesi |
| Curriculum online | La pagina è leggibile da telefono? | Dispositivi, browser, pagine viste |
| Anteprima cliente | La versione giusta è stata aperta? | Visite recenti, paesi, dispositivi, pagine |
| Documentazione | Le persone arrivano alla pagina corretta? | Pagine principali, referrer, percorsi inattesi |
| Sito con immagini o PDF | Il peso dei file si vede già? | Banda, pagine principali, dimensione delle risorse |
Se non sai cosa il sito deve dimostrare, una dashboard non può decidere al posto tuo. Vedrai una linea salire o scendere, ma non saprai se correggere un percorso, riscrivere il testo, condividere meglio il link o collegare un dominio.
Visite e visitatori non sono la stessa cosa
Le visite o pagine viste indicano quante volte una pagina è stata caricata. I visitatori danno un'idea di quante persone, browser o sessioni diverse hanno raggiunto il sito.
Entrambi i numeri sono utili, ma non raccontano la stessa storia.
Nei primi giorni, tu, il team, un cliente o un docente potete aprire e ricaricare più volte lo stesso link. Le pagine viste crescono, ma il pubblico reale non cresce allo stesso modo. Può succedere anche l'opposto: poche visite, ma provenienti da referrer e dispositivi diversi. Per un portfolio, un curriculum o un prototipo, questo segnale può già bastare.
| Indicatore | Aiuta a capire | Errore comune |
|---|---|---|
| Pagine viste | Attività per URL | Scambiare test interni per interesse reale |
| Visitatori | Portata approssimativa | Leggerli come persone esatte |
| Pagine principali | URL aperti davvero | Guardare solo la pagina iniziale |
| Banda | Peso dei file e pressione sul piano | Accorgersi tardi che una pagina è pesante |
Gli strumenti usano nomi diversi. In Google Analytics 4, page_view è un evento inviato quando una pagina viene caricata. Strumenti più leggeri come Plausible o Cloudflare Web Analytics mostrano spesso pagine viste, visitatori, referrer, paesi, dispositivi e browser in modo più diretto.
Il nome esatto conta meno della lettura insieme. Pagine viste, visitatori, referrer e pagine principali spiegano meglio il lancio rispetto a un solo numero isolato.
In DeployPages, le statistiche di progetto mostrano pagine viste, visitatori stimati, banda, pagine principali, referrer, paesi, dispositivi, browser, sistemi operativi e visite recenti. Per un sito statico appena pubblicato, questo primo livello è spesso sufficiente.
I referrer mostrano se la distribuzione ha funzionato
Molti piccoli lanci non falliscono per colpa della pagina. Falliscono perché poche persone hanno visto il link, o perché è stato condiviso nel posto sbagliato.
I referrer aiutano a separare questi casi.
| Cosa vedi | Cosa può significare | Prossimo passo |
|---|---|---|
| Molto direct | E-mail, chat, QR code, link copiato o referrer assente | Usare UTM alla prossima condivisione |
| Un social domina | Il post o una ricondivisione ha funzionato | Guardare pagine e dispositivi di quel traffico |
| Compare traffico da ricerca | La pagina viene trovata oltre il primo invio | Controllare title, description e dominio |
| Domini interni o cliente | C'è traffico di revisione | Non confonderlo con risposta pubblica |
| Referrer strani | Rumore, bot o visite poco utili | Non cambiare la pagina per quel segnale |
Se la stessa pagina finisce in una newsletter, su LinkedIn, in un messaggio, in un QR code e in un link in bio, prepara URL leggibili. Il generatore UTM aiuta a definire source, medium e campaign prima di pubblicare.
Non serve un'attribuzione perfetta. Serve evitare la domanda che arriva sempre dopo: da dove veniva questo accesso?
Dispositivi e browser indicano dove testare
Un sito statico viene spesso costruito su un computer e aperto su telefono.
Un portfolio ordinato su desktop può diventare una lista troppo lunga su mobile. Una landing page può mostrare il pulsante principale su uno schermo grande e spingerlo troppo in basso su un telefono. Un curriculum HTML può sembrare corretto in Chrome desktop e risultare stretto in Safari mobile.
I dati su dispositivo, browser e sistema operativo non scelgono il design per te. Dicono dove testare prima.
Se la maggior parte delle visite arriva da mobile, apri il link reale su un telefono prima di rifare la pagina. Se Safari iOS compare spesso, controlla immagini, video, font e aree toccabili lì. Se un cliente rivede il sito da un browser meno recente, evita che la revisione diventi una discussione di compatibilità.
Questa informazione è più utile di un generico "mobile first". Parla del sito che hai appena pubblicato.
Le pagine principali rompono le ipotesi
Chi pubblica pensa spesso a un punto di ingresso. Chi visita può usarne un altro.
Qualcuno condivide un URL interno. Un QR code punta a una pagina di campagna. Un vecchio documento conserva un link precedente. La ricerca trova prima un articolo. Un sito generato con IA può lasciare visibile un percorso di test.
Guarda le pagine principali soprattutto dopo:
- una nuova pubblicazione;
- il passaggio dal link di anteprima a un dominio personalizzato;
- una migrazione da GitHub Pages, un vecchio portfolio o una documentazione;
- campagne con link diversi per e-mail, social, QR code o annunci;
- modifiche a
index.html, navigazione o percorsi dei file; - pubblicazione di PDF, immagini o download.
Una pagina interna in cima non è per forza un problema. Forse è il vero ingresso migliore. Il problema è quando compaiono percorsi vecchi, download rotti o pagine non pronte per il pubblico.
La banda diventa un problema se la guardi tardi
La banda sembra meno interessante delle visite, ma nei siti statici può diventare il segnale più pratico di costo e prestazioni.
Immagini grandi, PDF, video di sfondo, font pesanti e screenshot esportati senza compressione sembrano innocui quando tre persone aprono l'anteprima. Cambia tutto quando il link entra in una campagna, in un portfolio, in un QR stampato o in un post che inizia a circolare.
Controlla la banda se:
- il sito usa molte foto, screenshot o immagini prodotto;
- PDF, menu, presentazioni o media sono nello stesso progetto;
- una campagna può creare un picco breve;
- il progetto si avvicina ai limiti del piano;
- il pubblico arriva soprattutto da mobile.
La banda non ti dice automaticamente quale file pesa troppo. Funziona come avviso. Dopo bisogna controllare dimensioni delle immagini, compressione, lazy loading, video, font e posizione dei file grandi.
Prima statistiche integrate, poi analisi più profonda
Google Analytics, Plausible, Matomo, Fathom, Simple Analytics e PostHog possono avere senso. La domanda è quando aggiungerli.
Subito dopo la pubblicazione, le domande sono spesso semplici:
- Il link si apre?
- Da dove arrivano le visite?
- Quali URL vengono aperti?
- Il traffico è più mobile o desktop?
- I paesi sono coerenti con il pubblico previsto?
- La banda è normale?
Le statistiche integrate funzionano bene per questo primo livello perché sono collegate al progetto pubblicato. Carichi una cartella, ottieni un link HTTPS, lo condividi e leggi la risposta iniziale senza modificare i file statici per inserire un altro script.
Uno strumento di analisi più completo serve quando devi misurare clic sui pulsanti, funnel, conversioni, test A/B, campagne a pagamento, utenti autenticati, eventi di prodotto o e-commerce.
Separare questi livelli rende la scelta più chiara. Le statistiche di pubblicazione rispondono se il sito viene visto. L'analisi di prodotto risponde cosa fanno le persone dopo essere arrivate.
Privacy, GDPR e script esterni
In Italia, le statistiche di un sito web possono toccare cookie, strumenti di tracciamento, informativa privacy e consenso. Non è un dettaglio da lasciare alla fine.
Una statistica di lancio non è la stessa cosa di una configurazione completa di tracciamento.
| Livello | Domanda principale | Esempi |
|---|---|---|
| Statistiche di pubblicazione | Il link pubblico è stato aperto? | Pagine viste, referrer, dispositivi, paesi, banda |
| Analisi marketing o prodotto | Cosa fa l'utente dentro il sito? | Eventi, conversioni, segmenti, test A/B, pubblicità |
DeployPages offre la prima lettura legata al progetto. Questo non sostituisce una verifica dell'informativa privacy. Se aggiungi Google Analytics, pixel pubblicitari, heatmap, chat, moduli esterni o altri script, controlla quali dati vengono raccolti, cosa viene salvato nel browser, quali terze parti ricevono dati e quale informativa serve.
Il punto non è spaventare chi pubblica una pagina piccola. Il punto è evitare che un sito semplice carichi strumenti che nessuno ha configurato o spiegato.
Una routine semplice per la prima settimana
Non devi guardare le statistiche tutto il giorno. Per un sito statico, poche verifiche bastano.
| Momento | Cosa guardare | Perché |
|---|---|---|
| Prima ora | Apertura pagina, 404, immagini e script | Correggere prima di condividere di più |
| Primo giorno | Referrer, dispositivi, pagine principali | Vedere se distribuzione e layout coincidono con il pubblico |
| Prima settimana | Trend, paesi, banda, pagine ancora attive | Decidere se migliorare, mantenere o sostituire |
| Dopo una nuova versione | Pagine principali e visite recenti | Verificare che un URL utile non sia stato rotto |
| Dopo il dominio | Direct, ricerca, URL precedenti | Vedere se il dominio sostituisce il link di test |
L'obiettivo non è produrre report per abitudine. L'obiettivo è sapere il prossimo passo: correggere un percorso, comprimere un'immagine, cambiare link condiviso, collegare un dominio o aggiungere un'analisi più profonda.
Dove entra DeployPages
DeployPages tratta le statistiche come parte del flusso di pubblicazione.
Puoi pubblicare una cartella statica, uno ZIP, un build front-end, un sito generato con IA, una pagina con PDF o un portfolio. Poi, nel progetto, puoi controllare pagine viste, visitatori stimati, referrer, pagine principali, paesi, dispositivi, browser, sistemi, banda e visite recenti.
Lo stesso progetto può crescere verso dominio personalizzato, protezione tramite password, ripristino di una versione precedente, pubblicazione via CLI e statistiche.
Per molti siti statici, questo ordine è più naturale: prima pubblicare, poi leggere segnali reali, poi decidere se il progetto merita dominio, ottimizzazione, team o uno strumento di analisi più profondo.