Record A DNS per WordPress - Guida completa senza errori

Un record A nel DNS è il punto in cui il nome del dominio incontra l’indirizzo IPv4 del server. Se quel collegamento è sbagliato, il sito non si apre, il `www` può puntare altrove e una migrazione WordPress sembra fallire anche quando il CMS non c’entra nulla. In questo articolo spiego come funziona davvero questo record, quando va creato o aggiornato, quali differenze contano rispetto ad AAAA e CNAME, e come impostarlo senza creare disservizi.

Che cosa fa un record A nel DNS e perché conta per WordPress

Io parto sempre da una distinzione semplice: il record A traduce un nome, come example.it, in un indirizzo IPv4 del server che deve rispondere. È il meccanismo base che permette al browser di trovare il sito senza che l’utente debba digitare un IP numerico. In pratica, il record A è il cartello stradale del dominio.

Il punto chiave è questo: WordPress non ha bisogno di un record speciale, ha bisogno che il dominio arrivi al server giusto. Quando questo passaggio è solido, il resto della configurazione diventa molto più lineare. Ed è proprio qui che conviene distinguere il record A dagli altri tipi di record, perché confonderli crea gli errori più costosi.

Record A, AAAA e CNAME non fanno la stessa cosa

Prima di cambiare un record A, io chiarisco sempre che cosa non fa. Molti problemi nascono da una sovrapposizione mentale tra record diversi, ma in DNS ogni tipo ha una funzione precisa.

La regola pratica che uso è questa: A per l’IPv4, AAAA per l’IPv6, CNAME per i sottodomini, alias solo se il provider lo supporta davvero. Nei siti WordPress moderni il caso più comune è dominio radice con record A e www come CNAME verso il dominio principale, oppure un secondo record A se l’infrastruttura lo richiede. Se poi il sito deve rispondere anche su reti IPv6, il record A non basta da solo.

Questa distinzione è importante perché evita una trappola frequente: credere che “un record DNS valga l’altro”. Non è così. Ogni tipo ha regole diverse, e il record sbagliato può funzionare per caso oggi e rompersi alla prima modifica di hosting. Da qui si passa al momento operativo: quando conviene toccarlo davvero.

Quando aggiornare il record A su un sito WordPress

Il record A si modifica quando cambia l’indirizzo del server che ospita il sito. Sembra banale, ma nella pratica i casi sono molti più di quelli che i non tecnici immaginano.

• Migrazione di hosting: il sito passa da un server a un altro e l’IP pubblico cambia.
• Passaggio a un nuovo ambiente: ad esempio da staging a produzione, quando il dominio deve puntare al server definitivo.
• Cambio di infrastruttura: CDN, reverse proxy o bilanciatori possono richiedere una revisione dei record.
• Disaster recovery: si sposta il traffico su un server di backup dopo un guasto.
• Riorganizzazione del dominio: si decide che il sito principale risponde su www oppure sul dominio nudo.

In questi casi io non guardo solo l’IP finale. Guardo anche il TTL, cioè il tempo per cui i resolver possono tenere in cache il valore vecchio. Durante una migrazione imposto spesso un TTL di 300 secondi nelle ore precedenti al cambio; quando tutto è stabile, torno più volentieri su valori come 3600 o 14400 secondi, se il provider e il traffico lo consentono. Non è una garanzia di aggiornamento immediato, ma riduce il tempo in cui una cache può trattenere il vecchio indirizzo.

La propagazione, infatti, non è un interruttore. Nella pratica molte reti vedono il cambio in pochi minuti, spesso tra 5 e 30 minuti, ma alcune cache possono conservarlo fino alla scadenza del TTL precedente e, in casi meno lineari, anche più a lungo. Questo spiega perché due persone possano vedere risultati diversi a pochi minuti di distanza.

Come impostarlo senza interrompere il sito

Quando devo intervenire su un DNS, seguo sempre una sequenza precisa. Non perché il pannello sia complicato, ma perché gli errori di ordine fanno più danni degli errori di sintassi.

1. Recupero l’IPv4 pubblico del server di destinazione, non un IP interno come 192.168.x.x o 10.x.x.x.
2. Decido quale host sarà canonico: il dominio nudo, il www oppure entrambi con una logica di redirect ben definita.
3. Creo o modifico il record A del dominio radice, di solito identificato come @ o lasciato vuoto nel campo nome.
4. Configuro www in modo coerente, spesso con un CNAME verso il dominio principale oppure con un secondo A se il provider lo preferisce.
5. Imposto un TTL ragionevole: basso durante la transizione, più alto quando il sito è stabile.
6. Salvo e verifico da più punti di rete, non solo dal mio browser già in cache.

Se il pannello mostra anche un’opzione di proxy o CDN, la valuto con attenzione. In quei casi il record A continua a esistere, ma il traffico può passare attraverso un livello intermedio che nasconde l’IP origin. È utile per sicurezza e caching, ma cambia il modo in cui si leggono i test: il DNS può essere corretto e il sito può comunque sembrare lento se il problema sta nel server origin o nel proxy.

Il dettaglio che vedo sbagliare più spesso è il campo nome host. Alcuni pannelli vogliono solo @ per il dominio radice, altri vogliono il nome completo, altri ancora separano chiaramente host e valore. Un record formalmente salvato non significa che sia stato configurato bene. Io controllo sempre la coppia nome-valore, perché lì si gioca la differenza tra un sito online e un errore difficile da decifrare.

Gli errori che vedo più spesso

• Uso di un IP privato: il record punta a un indirizzo non raggiungibile dalla rete pubblica.
• Conflitto tra A e CNAME sullo stesso host: in DNS standard non dovrebbero coesistere sul medesimo nome.
• Dimenticare il www: il dominio radice funziona, ma il sottodominio principale no, o viceversa.
• Confondere DNS e web server: il record è corretto, ma il virtual host, il certificato o il redirect non sono allineati.
• Aspettarsi una propagazione istantanea: il vecchio valore è ancora in cache e sembra che nulla sia cambiato.
• Ignorare l’IPv6: il sito risponde bene in IPv4 ma ha un comportamento incoerente su reti che usano AAAA.
• Toccare il record sbagliato: cambiare l’A del sito quando il problema reale riguarda MX, SPF o un altro record di posta.

Io aggiungo sempre un controllo semplice: se il dominio non risponde, verifico prima che l’IP pubblico sia giusto e che il server stia effettivamente servendo quel dominio, poi passo al resto. È un ordine banale, ma riduce moltissimo i tempi morti. Spesso non serve rifare il sito; serve correggere un solo indirizzo o un solo alias.

Impatto reale su velocità, affidabilità e SEO

Il record A, da solo, non rende un sito più veloce. Questa è una semplificazione che sento spesso e che in pratica non regge. La velocità percepita dipende molto di più da CDN, caching, performance del server, compressione e ottimizzazione del frontend. Il DNS incide soprattutto sulla prima risoluzione del nome e sulla rapidità con cui il browser trova il server giusto, quindi il suo ruolo è di base, non di ottimizzazione profonda.

Sull’affidabilità, invece, il peso è reale. Se il record A punta all’IP sbagliato, il sito è irraggiungibile. Se punta a un server che non risponde, il visitatore vede un errore anche se tutto il resto dell’infrastruttura è sano. Nei casi più maturi si usano più record A o una logica di bilanciamento, ma solo quando c’è un’infrastruttura preparata a gestirli. Mettere due IP “per sicurezza” senza un disegno preciso non crea ridondanza magica.

Per la SEO, l’effetto è indiretto ma non trascurabile. Un motore di ricerca non premia un record A “migliore”, ma penalizza downtime, risposte lente, errori di risoluzione e cambi di destinazione non coerenti. Se durante una migrazione il sito rimane instabile per ore, il problema non è teorico: è la continuità del servizio. Io considero il DNS un pezzo della qualità operativa del sito, non un trucco per il posizionamento.

La conseguenza pratica è semplice: il record A va trattato come parte della catena di pubblicazione, insieme a hosting, HTTPS, redirect e caching. Quando questi elementi sono allineati, il sito resta raggiungibile e la migrazione passa quasi inosservata all’utente finale. Ed è proprio lì che si vede se la configurazione è stata pensata bene.

Quando un record A non basta e serve un’alternativa

Ci sono situazioni in cui insistere sul solo record A è una scelta povera. Non perché il record sia sbagliato, ma perché il problema richiede un livello in più di astrazione.

Nei siti WordPress cresciuti, questo passaggio fa una differenza enorme. Se l’infrastruttura cambia spesso, il DNS non deve diventare il punto debole del progetto. Io preferisco spostare la complessità dove ha senso: nel bilanciamento, nel proxy o nel provider DNS, non in una sequenza infinita di record aggiornati a mano.

In altre parole, il record A è perfetto quando il rapporto tra dominio e server è chiaro e stabile. Quando invece l’architettura diventa dinamica, conviene usare strumenti che rappresentino quella dinamica in modo più pulito. È un cambio di prospettiva che evita molte correzioni successive.

Il controllo finale che evita il classico errore da migrazione

Prima di considerare chiuso il lavoro, io faccio sempre una verifica essenziale: il dominio principale e il www devono risolvere dove mi aspetto, il server deve servire il sito corretto e il certificato HTTPS deve corrispondere a quel nome. Se uno di questi tre punti manca, il problema può sembrare DNS ma in realtà sta più in alto o più in basso nella catena.

• Controllo la risoluzione da più reti, non solo dalla mia connessione locale.
• Verifico che il vecchio server non stia ancora rispondendo in modo ambiguo durante il passaggio.
• Rivedo i redirect tra dominio nudo e www, perché spesso è lì che si crea confusione.
• Se ho abbassato il TTL, lo rialzo quando la migrazione è stabile.
• Pulisco cache applicative e CDN solo dopo aver confermato che il record A è corretto.

Il punto, alla fine, è questo: un record A sembra un dettaglio, ma è uno di quei dettagli che decidono se un sito WordPress resta affidabile oppure no. Se lo gestisci con metodo, il DNS smette di essere un ostacolo e diventa una parte prevedibile della manutenzione. Se vuoi un sito sempre raggiungibile, io partirei proprio da qui.