QUADERNO BEGHÈ · 15/09/2026
Sito che invecchia: hosting, DNS e prestazioni
Un sito che invecchia si riconosce da tre cose misurabili: la scelta tra www e dominio nudo non è ancora consolidata, i tempi di risposta sono più lenti di quelli dichiarati dal fornitore, e il pannello di controllo mostra segnali di trascuratezza. Non serve cambiare tutto subito: serve decidere una configurazione, misurarla e tenere un registro delle misure nel tempo.
Come si sceglie www o dominio senza www senza perdere traffico?
La regola è una sola: una delle due forme deve reindirizzare in modo permanente verso l'altra, con un codice 301, e il reindirizzamento deve valere per ogni pagina, non solo per la home. Se il sito risponde sia su `esempio.it` sia su `www.esempio.it` con lo stesso contenuto e senza redirect, i motori di ricerca vedono due indirizzi distinti e il segnale si divide. Non è un danno immediato, ma è un peso che si accumula.
La scelta tra le due forme è in gran parte indifferente. Conta la coerenza: se il sito è nato senza www, si tiene il dominio nudo; se i link esterni e i materiali a stampa usano www, si tiene www. Cambiare forma dopo anni è possibile, ma va fatto una volta sola, con redirect 301 da tutte le vecchie URL, mappa dei reindirizzamenti aggiornata e controllo dei link interni. Un cambio fatto a metà, con alcune pagine che rispondono su entrambe le forme, è peggio dell'indecisione iniziale.
Il punto tecnico che sfugge più spesso è il DNS. Il record che punta al server e quello che punta alla forma scelta devono essere coerenti tra loro, e il certificato HTTPS deve coprire entrambe le forme, altrimenti il redirect porta l'utente su un avviso di connessione non sicura. Chi gestisce più siti su hosting condiviso incontra spesso questo nodo, insieme ai limiti del pannello del fornitore: su questo terreno, le note di Ondiz su hosting e sicurezza descrivono casi concreti di migrazione e di configurazione, utili come termine di confronto prima di prendere decisioni.
Come si misurano davvero le prestazioni di un sito?
Le prestazioni non si misurano con una sola prova. Si misurano con tre strumenti che rispondono a domande diverse.
Il primo è il tempo di risposta del server, cioè quanto passa tra la richiesta e il primo byte ricevuto. Si legge con gli strumenti per sviluppatori del browser, nella scheda di rete, oppure con un semplice comando da terminale ripetuto più volte. Va misurato in momenti diversi della giornata, perché un hosting condiviso cambia comportamento quando gli altri siti sullo stesso server lavorano di più.
Il secondo è la misura di laboratorio: PageSpeed Insights e Lighthouse danno un punteggio su una pagina specifica, in condizioni controllate. Sono utili per individuare i problemi, non per giudicare il sito nel suo insieme. Un punteggio alto su una pagina vuota non dice nulla su una pagina di archivio con cinquanta immagini.
Il terzo è la misura reale, quella degli utenti che visitano il sito. È la più importante e la più trascurata. Richiede di raccogliere i tempi effettivi di caricamento per un periodo sufficiente, distinguendo tra connessioni veloci e lente, e tra visitatori abituali e occasionali.
A queste si aggiungono due verifiche che riguardano il fornitore più che il sito. La prima è la compressione: il server deve inviare i testi compressi, e questo si controlla dalle intestazioni della risposta. La seconda è la presenza di una rete di distribuzione dei contenuti, utile solo se il pubblico è distribuito geograficamente; per un sito locale è spesso un costo senza effetto misurabile.
Un registro scritto, con data, ora e valori, vale più di qualsiasi giudizio a memoria. Dopo qualche settimana si vede se il fornitore è stabile o se i tempi peggiorano senza che nulla sia cambiato nel sito.
Quali segnali indicano un hosting condiviso da abbandonare?
I segnali si dividono in tre gruppi: quelli che si vedono dal pannello, quelli che si vedono dal sito e quelli che si vedono dalle comunicazioni del fornitore.
Dal pannello: versioni del software del server ferme da anni, nessuna indicazione sui backup, impossibilità di esportare i dati senza chiedere assistenza, limiti di traffico o di spazio comunicati solo dopo il superamento.
Dal sito: pagine che a volte rispondono e a volte no, errori di connessione al database che compaiono e scompaiono, tempi di risposta che raddoppiano nelle ore di punta, certificato HTTPS che scade senza avviso, caselle di posta che finiscono in elenchi di posta indesiderata senza motivo apparente.
Dalle comunicazioni: risposte vaghe sulle cause di un guasto, nessun registro degli incidenti, richieste di pagamento per funzioni che dovrebbero essere incluse, silenzio quando si chiede quali misure di sicurezza siano attive.
Un caso a parte è la compromissione. Un sito WordPress che viene modificato senza intervento dell'amministratore, file nuovi nella cartella dei temi, pagine indicizzate che non appartengono al sito, sono tutti segnali che il problema può essere nel sito o nel server. Prima di cambiare fornitore conviene capire da dove è entrata la modifica, altrimenti il problema si sposta con il sito.
Quando conviene migrare e come si prepara il passaggio
La migrazione conviene quando i segnali sono più di uno e si ripetono nel tempo. Un singolo guasto non giustifica il trasloco; tre guasti in un mese con risposte vaghe sì.
La preparazione richiede quattro passaggi. Il primo è l'inventario: elenco delle pagine, dei database, delle caselle di posta, dei sottodomini e di tutto ciò che dipende dal fornitore attuale. Il secondo è la copia completa, verificata aprendo i file e non solo contando i byte. Il terzo è la riduzione del tempo di vita dei record DNS, da fare almeno un giorno prima del passaggio, così il cambio di indirizzo si propaga in fretta. Il quarto è la prova sul nuovo server, con il sito raggiungibile da un indirizzo temporaneo prima che il dominio venga spostato.
Il giorno del passaggio si cambiano i record DNS e si controlla che il redirect tra www e dominio nudo funzioni anche sul nuovo server. Nei giorni successivi si verificano i moduli, le caselle di posta, i certificati e le prestazioni, con lo stesso registro usato prima.
Cosa resta da controllare dopo il trasloco
Dopo la migrazione il lavoro non è finito. Restano tre controlli da fare a distanza di una settimana e di un mese.
Il primo riguarda i redirect: le vecchie URL devono continuare a portare alle pagine giuste, senza catene di passaggi multipli. Il secondo riguarda le prestazioni: il nuovo fornitore va misurato con gli stessi strumenti usati per il vecchio, altrimenti il confronto non ha valore. Il terzo riguarda la sicurezza: le versioni del software, i certificati e le caselle di posta vanno verificati di nuovo, perché un fornitore nuovo non è automaticamente un fornitore attento.
Un sito che invecchia non torna giovane con un solo intervento. Torna leggibile quando la configurazione è decisa, le misure sono registrate e il fornitore è scelto per quello che fa, non per quello che promette.
Per continuare
Questa pagina si legge insieme a una fonte, a una scheda o a una pagina di contesto. Il percorso suggerito mantiene visibili i passaggi e non chiude ciò che le fonti lasciano aperto.