Collega un dominio GoDaddy a GitHub Pages passo dopo passo

Collegare un dominio registrato su GoDaddy a GitHub Pages è un cambio semplice solo in apparenza: il punto critico non è “puntare il DNS”, ma far combaciare correttamente zona DNS, record dell’apice, www, verifica del dominio e abilitazione HTTPS. Se salti un passaggio, il risultato tipico è una pagina non raggiungibile, un redirect che non converge oppure un certificato che resta fermo su stato di attesa.

© TrgtKLS • Tech, Sicurezza e Strumenti & guide per Webmaster — https://trgtkls.it — tutti i diritti riservati.

Qui sotto trovi una procedura lineare, pensata per ridurre errori operativi. Il caso d’uso è questo: hai un repository GitHub Pages già pubblicato e vuoi usare un dominio tipo example.com comprato su GoDaddy, con o senza prefisso www. L’obiettivo è arrivare a un setup pulito, con DNS minimale, redirect coerente e HTTPS attivo su GitHub Pages.

1. Decidi il nome canonico prima di toccare il DNS

La prima scelta tecnica è semplice: quale hostname vuoi usare come indirizzo principale del sito? In pratica hai due opzioni sane:

• Dominio apex: example.com
• Subdominio: www.example.com

GitHub Pages gestisce bene entrambi, ma conviene sceglierne uno come canonico e usare l’altro solo come alias. Nella maggior parte dei casi, la combinazione più ordinata è: example.com come dominio principale e www.example.com come redirect verso l’apice, oppure il contrario se vuoi un setup più tradizionale orientato al subdominio.

Se non decidi questo subito, finisci facilmente con due URL entrambi raggiungibili ma non coerenti nei link, nel certificato e nelle condivisioni social. La scelta va fatta prima della configurazione DNS, non dopo.

2. Imposta il dominio personalizzato nel repository GitHub Pages

Prima di cambiare i record su GoDaddy, dichiara il dominio nel repository GitHub Pages. Questo passaggio serve a GitHub per associare il sito al nome host corretto e per preparare la generazione del certificato TLS.

Vai in Settings del repository, poi Pages, quindi nel campo Custom domain inserisci il dominio scelto. Se vuoi usare example.com, scrivi quello. Se preferisci www.example.com, scrivi quello. Salva la modifica.

Dopo il salvataggio, GitHub crea o aggiorna un file chiamato CNAME nel branch pubblicato, oppure ti chiede di gestirlo manualmente. Quel file deve contenere una sola riga con il dominio canonico. Esempio:

example.com

Se usi un workflow con build automatica, controlla che il file non venga sovrascritto a ogni deploy. In caso contrario, GitHub Pages perde l’associazione e il dominio può tornare a uno stato non coerente.

3. Configura i record DNS su GoDaddy

Qui si gioca la parte delicata. GoDaddy di solito ospita la zona DNS del dominio, quindi devi aprire la gestione DNS del dominio e impostare i record corretti. Non servono record complicati: per GitHub Pages bastano quelli giusti, senza inventarsi CNAME sull’apice dove non è previsto.

Se il tuo dominio principale è example.com, configura i record A dell’apice verso gli IP di GitHub Pages. Al momento, la configurazione standard prevede questi quattro indirizzi IPv4:

185.199.108.153
185.199.109.153
185.199.110.153
185.199.111.153

Per il sottodominio www, crea invece un record CNAME che punti al dominio GitHub Pages del repository, cioè al nome fornito da GitHub, in genere nella forma username.github.io.

Schema pratico:

• A per @ o per il root del dominio verso gli IP GitHub Pages
• CNAME per www verso username.github.io

Se invece hai scelto www.example.com come dominio canonico, allora il CNAME è quello principale e puoi usare un redirect lato DNS o lato GitHub per l’apice. Ma, in pratica, l’approccio più robusto resta: apex con A record e www come CNAME.

Su GoDaddy, presta attenzione a due dettagli che generano errori frequenti:

• non lasciare record confliggenti già presenti, come vecchi A record o CNAME duplicati;
• non usare proxy, forwarding o servizi di mascheramento che alterano il comportamento DNS senza che tu lo sappia.

Se nel pannello DNS vedi record preesistenti che puntano a un vecchio host, rimuovili o disattivali. L’obiettivo è avere una zona semplice e leggibile, non una collezione di record storici che si contraddicono.

4. Verifica la propagazione prima di aspettarti il certificato

Dopo aver salvato i record su GoDaddy, non andare subito a premere refresh sul browser per cinque minuti. Prima verifica la risoluzione DNS da terminale. Questo ti dice se il problema è ancora nella propagazione o se hai già un errore di configurazione.

Controlla l’apice con dig o nslookup:

dig +short example.com A

Atteso: uno o più degli IP GitHub Pages. Se ottieni IP diversi, il record non è ancora corretto o stai leggendo una cache non aggiornata. Per il subdominio:

dig +short www.example.com CNAME

Atteso: username.github.io. Se non compare nulla, il CNAME non è ancora stato propagato o non è stato scritto correttamente nella zona DNS.

Se vuoi una verifica più completa, usa anche:

dig example.com +trace

Questo ti aiuta a capire se il problema è nei nameserver autoritativi di GoDaddy, nella cache del resolver o in un record scritto male. È uno dei controlli più utili quando il dominio “sembra giusto” ma non risolve ancora come dovrebbe.

5. Attendi la generazione del certificato HTTPS su GitHub Pages

Una volta che il DNS punta correttamente a GitHub Pages, GitHub avvia la richiesta del certificato TLS per il dominio personalizzato. Questo non è immediato: può richiedere da pochi minuti a più tempo, a seconda della propagazione e dello stato del repository.

Nel pannello Settings > Pages controlla lo stato del dominio. In condizioni normali, vedrai il dominio verificato e la possibilità di abilitare Enforce HTTPS. Se il pulsante è disattivato o compare un errore, quasi sempre la causa è una di queste:

• il DNS non punta ancora agli IP giusti;
• il CNAME del www non è coerente;
• esiste un conflitto tra record vecchi e nuovi;
• il file CNAME non coincide con il dominio configurato nel pannello.

Una volta che il certificato è pronto, attiva Enforce HTTPS. Questo evita di lasciare il sito esposto in chiaro e forza l’uso del canale cifrato. Se il toggle non compare, non forzare soluzioni alternative: torna prima ai controlli DNS e di associazione dominio.

6. Scegli il redirect corretto tra apex e www

Se hai configurato sia example.com sia www.example.com, devi decidere quale dei due deve fare da ingresso unico. Il comportamento desiderato è semplice: uno dei due hostname deve essere canonico, l’altro deve reindirizzare in modo pulito.

Con GitHub Pages, il pattern più comune è:

• example.com come dominio principale;
• www.example.com come alias che punta allo stesso sito.

Se vuoi il comportamento opposto, puoi farlo, ma devi evitare che entrambi restino indipendenti. Un sito statico con due host “equivalenti” crea problemi di canonicalizzazione, SEO e coerenza dei link condivisi. Meglio una sola scelta netta.

Se il tuo tema o il tuo sito genera link assoluti, controlla che puntino al dominio canonico e non al vecchio username.github.io. È un dettaglio che spesso emerge dopo il passaggio in produzione, non durante la configurazione iniziale.

7. Testa il sito con controllo HTTP e catena di redirect

Quando DNS e HTTPS sono attivi, non limitarti a “aprire il sito nel browser”. Verifica la risposta HTTP e la catena di redirect, così vedi subito se il setup è coerente.

curl -I https://example.com

Atteso: HTTP/2 200 o un redirect pulito verso il dominio canonico, seguito da un 200 finale. Se vedi una sequenza infinita di redirect, c’è un conflitto tra record, configurazione Pages o redirect esterni impostati altrove.

Controlla anche il sottodominio:

curl -I https://www.example.com

Se il certificato non è ancora pronto, potresti vedere un errore TLS o un certificato non ancora valido per il dominio personalizzato. In quel caso non è il sito a essere rotto: è solo incompleto il ciclo di provisioning del certificato.

8. Risolvi i problemi tipici senza complicare il setup

Il vantaggio di GitHub Pages è che il setup corretto è molto essenziale. Di conseguenza, quasi tutti i guasti derivano da pochi errori ripetuti. Vale la pena riconoscerli subito.

Problema: il dominio non risolve. Verifica che i nameserver del dominio siano davvero quelli di GoDaddy e che la zona DNS sia quella attiva. Se hai cambiato nameserver di recente, la propagazione può essere ancora in corso.

Problema: il dominio risolve ma GitHub non vede il custom domain. Controlla il campo Custom domain in Pages e il contenuto del file CNAME. Devono coincidere.

Problema: HTTPS non si abilita. Di solito il DNS non è ancora allineato oppure ci sono record confliggenti. Rimuovi i duplicati e ripeti il check con dig.

Problema: il sito carica ma mostra asset rotti. Questo non è un problema di DNS: è quasi sempre un problema di path assoluti, base URL errata o link hardcoded al vecchio dominio. Correggi i riferimenti nel tema, nei file HTML o nella pipeline di build.

9. Esempio pratico di configurazione minima

Supponiamo di avere il dominio example.com e il repository GitHub Pages associato all’utente mario. La configurazione minima pulita è questa:

• in GitHub Pages imposti example.com come custom domain;
• nel DNS di GoDaddy crei quattro record A per @ verso gli IP GitHub Pages;
• crei un record CNAME per www verso mario.github.io;
• attendi la propagazione e poi abiliti Enforce HTTPS.

Se vuoi un controllo rapido dell’esito, i tre segnali da osservare sono questi:

1. dig +short example.com A restituisce gli IP GitHub Pages;
2. dig +short www.example.com CNAME restituisce il target GitHub;
3. curl -I https://example.com restituisce 200 o redirect coerente, con TLS valido.

10. Cosa non fare se vuoi evitare ticket inutili

Alcune scorciatoie sembrano comode ma poi consumano tempo in debugging. Evita di:

• mettere un CNAME sull’apice del dominio se il provider non lo supporta in modo nativo;
• tenere record vecchi “per sicurezza” senza sapere quali siano davvero attivi;
• forzare redirect esterni quando GitHub Pages può gestire l’alias in modo nativo;
• attivare HTTPS prima che il DNS sia coerente;
• cambiare più variabili insieme, perché poi non sai quale modifica ha risolto o rotto il flusso.

Il principio operativo è quello classico dei cambi controllati: una modifica alla volta, verifica immediata, poi passo successivo. In un setup statico come questo, il tempo perso non è nel DNS in sé, ma nel non sapere quale layer sta fallendo.

11. Checklist finale da usare in produzione

Prima di considerare chiuso il lavoro, fai questa verifica finale:

1. Il dominio scelto è stato definito come canonico.
2. Il campo Custom domain in GitHub Pages contiene lo stesso nome.
3. Il file CNAME è presente e corretto nel branch pubblicato.
4. I record DNS su GoDaddy sono puliti e senza conflitti.
5. dig restituisce i target attesi.
6. curl -I mostra risposta HTTP corretta e redirect coerente.
7. HTTPS è attivo e forzato.

Se uno solo di questi punti non torna, non serve “aspettare ancora un po’” a caso: torna al layer corrispondente. DNS, Pages, certificato e redirect sono separati, ma devono allinearsi tutti insieme per avere un dominio funzionante e stabile.

Con questa sequenza, il collegamento tra GoDaddy e GitHub Pages resta semplice, ripetibile e facile da diagnosticare. Il vantaggio vero non è solo mettere online un sito statico: è farlo senza introdurre complessità inutile nel percorso di accesso, nel certificato o nella gestione futura del dominio.