Dominio personalizzato GitHub Pages: configurazione di DNS, CNAME e HTTPS
Come collegare un dominio personalizzato a GitHub Pages: record DNS per apex e www, funzione del file CNAME, verifica del dominio e attivazione dell'HTTPS.
Domande frequenti
Quali indirizzi IP uso per il dominio apex su GitHub Pages?
La documentazione di GitHub (verificata a novembre 2026) indica quattro record A per l'host apex (@): 185.199.108.153, 185.199.109.153, 185.199.110.153 e 185.199.111.153. Se vuoi supportare anche l'IPv6, aggiungi quattro record AAAA: 2606:50c0:8000::153, 2606:50c0:8001::153, 2606:50c0:8002::153 e 2606:50c0:8003::153. GitHub consiglia di mantenere i record A insieme ai record AAAA. Confronta i valori con la documentazione prima di incollarli, perché GitHub può modificarli.
Serve un file CNAME nel mio repository?
Solo se pubblichi da un branch. In quel caso, salvando il dominio personalizzato in Settings > Pages, GitHub crea automaticamente un file CNAME nella root del branch sorgente. Se invece pubblichi con un workflow GitHub Actions personalizzato, secondo GitHub nessun file CNAME viene creato e quello eventualmente presente viene ignorato e non è necessario.
Perché la casella Enforce HTTPS è disattivata (grigia)?
GitHub indica che possono servire fino a 24 ore prima che l'opzione diventi disponibile dopo l'aggiunta del dominio. Il certificato viene emesso automaticamente, quindi le cause più comuni di una casella bloccata sono un DNS non ancora propagato oppure record superflui, come altri record A, AAAA, ALIAS o ANAME sull'apex, o un CNAME su www che punta altrove rispetto a GitHub. GitHub precisa inoltre che il dominio deve essere lungo meno di 64 caratteri. Se si blocca, clicca su Remove accanto al dominio, riscrivilo e salva di nuovo.
Meglio usare il dominio apex o www?
GitHub consiglia www. Secondo la documentazione, i sottodomini www sono il tipo di dominio personalizzato più stabile, perché non risentono delle modifiche agli indirizzi IP dei server di GitHub. Qualunque dei due imposti come dominio personalizzato, GitHub reindirizza l'altro verso di esso, purché il DNS di entrambi punti a GitHub Pages.
Quanto tempo ci vuole perché il dominio personalizzato di GitHub Pages funzioni?
GitHub indica che la propagazione delle modifiche DNS può richiedere fino a 24 ore. In pratica molti record si risolvono prima, ma conviene aspettare un giorno intero prima di pensare che ci sia un problema.
È sicuro usare un record DNS wildcard con GitHub Pages?
GitHub sconsiglia vivamente i record wildcard come *.example.com. Secondo la documentazione, ti espongono a un rischio immediato di domain takeover, anche se hai verificato il dominio. Crea invece record per i singoli sottodomini che usi davvero.
In breve: nel tuo repository vai su Settings > Pages, inserisci il dominio in Custom domain e salva. Poi, dal tuo provider DNS, punta www a <username>.github.io con un record CNAME e punta il dominio senza prefisso (example.com) a GitHub con quattro record A. Quando GitHub ha finito di emettere il certificato, spunta Enforce HTTPS. Si tratta di un'impostazione del repository più qualche record DNS. La maggior parte dei ritardi dipende dalla propagazione del DNS, che secondo GitHub può richiedere fino a 24 ore.
Tutto quello che segue è stato verificato sulla documentazione ufficiale di GitHub a novembre 2026. I valori DNS sono la parte che più facilmente cambia, quindi controllali nella documentazione GitHub Pages sui domini personalizzati prima di incollarli.
Scegli prima il tipo di dominio
| Dove vuoi che arrivino i visitatori | Da impostare come dominio personalizzato | Record DNS necessari | Note |
|---|---|---|---|
www.example.com | www.example.com | CNAME su www verso <username>.github.io, più record A sull'apex | Configurazione consigliata da GitHub. example.com viene reindirizzato a www. |
example.com | example.com | Record A sull'apex (oppure un solo ALIAS/ANAME), più un CNAME su www | www.example.com viene reindirizzato all'apex. |
blog.example.com | blog.example.com | CNAME su blog verso <username>.github.io | Non servono record sull'apex. |
Secondo la documentazione di GitHub, i sottodomini www sono la scelta più stabile perché non risentono dei cambi di indirizzo IP dei server di GitHub. Se non hai un motivo preciso per usare il dominio senza prefisso, scegli www. Se stai ancora valutando un registrar, il nostro confronto tra registrar di domini copre le alternative, mentre quanto costa un dominio spiega i prezzi di rinnovo.
Passo dopo passo: collegare il dominio
- Aggiungi il dominio su GitHub. Apri il repository, clicca su Settings, poi su Pages (nella sezione "Code, planning, and automation"). Se la scheda Settings non è visibile, cercala nel menu a tendina "More". Inserisci il dominio nel campo Custom domain e clicca su Save.
- Controlla cosa ha fatto GitHub nel tuo repo. Se pubblichi da un branch, GitHub fa il commit di un file
CNAMEnella root di quel branch. Se pubblichi con un workflow GitHub Actions personalizzato, nessun file CNAME viene creato e quello eventualmente presente viene ignorato. - Rimuovi i record DNS predefiniti. Se il tuo provider DNS ha creato automaticamente un record di parcheggio o predefinito per l'host che stai per usare, eliminalo prima.
- Crea i record DNS presso il tuo provider DNS (vedi la sezione successiva).
- Aspetta la propagazione. GitHub parla di un massimo di 24 ore. Puoi controllare lo stato da terminale con
dig www.example.com +noall +answer. - Attiva Enforce HTTPS non appena l'opzione diventa disponibile (vedi sotto).
L'ordine conta meno di quanto pensi
Puoi creare i record DNS prima o dopo aver salvato il dominio su GitHub. Il rischio è lasciare il DNS puntato a GitHub Pages mentre il dominio non è associato ad alcun repository. GitHub avverte che configurare il DNS senza aggiungere il dominio a GitHub potrebbe permettere a qualcun altro di ospitare un sito su uno dei tuoi sottodomini. Salva prima il dominio su GitHub, poi configura il DNS.
I record DNS
www o qualsiasi sottodominio: un solo CNAME
| Tipo | Host | Valore |
|---|---|---|
| CNAME | www | <username>.github.io |
Usa il tuo nome utente o il nome dell'organizzazione, senza il nome del repository. GitHub precisa espressamente di non puntare il CNAME all'indirizzo univoco *.pages.github.io mostrato nelle impostazioni del repository.
Dominio apex: quattro record A (verificati a novembre 2026)
| Tipo | Host | Valore |
|---|---|---|
| A | @ | 185.199.108.153 |
| A | @ | 185.199.109.153 |
| A | @ | 185.199.110.153 |
| A | @ | 185.199.111.153 |
IPv6 facoltativo, se lo vuoi, come record AAAA su @:
| Tipo | Host | Valore |
|---|---|---|
| AAAA | @ | 2606:50c0:8000::153 |
| AAAA | @ | 2606:50c0:8001::153 |
| AAAA | @ | 2606:50c0:8002::153 |
| AAAA | @ | 2606:50c0:8003::153 |
GitHub consiglia di aggiungere i record A anche se aggiungi i record AAAA, perché l'adozione dell'IPv6 non è ancora uniforme. Se il tuo provider DNS supporta i record ALIAS o ANAME, puoi usarne uno solo che punti a <username>.github.io al posto dei record A e AAAA.
Due errori da evitare:
- Record superflui sull'apex. Secondo GitHub, altri record A, AAAA, ALIAS o ANAME su
@, oppure un CNAME su www che punta altrove, possono impedire la generazione del certificato HTTPS. - Puntare un sottodominio all'apex. GitHub avverte che questo causa problemi nell'attivazione dell'HTTPS e può impedire al sottodominio di raggiungere il tuo sito. Punta i sottodomini a
<username>.github.io.
Alcuni provider usano @ per l'host apex, altri vogliono che lasci il campo vuoto o che scriva il dominio completo. È una particolarità del provider, non un'impostazione di GitHub.
Attivare l'HTTPS
GitHub emette i certificati per i domini personalizzati tramite Let's Encrypt. Dopo che il DNS si risolve correttamente:
- Torna su Settings > Pages.
- Cerca un segno di spunta accanto al dominio: significa che il controllo DNS è andato a buon fine.
- Spunta Enforce HTTPS.
GitHub indica che l'opzione può impiegare fino a 24 ore per diventare disponibile. Se non compare dopo alcuni minuti dal salvataggio, il rimedio suggerito da GitHub è cliccare su Remove accanto al dominio personalizzato, riscriverlo e cliccare di nuovo su Save. Inoltre il dominio deve essere lungo meno di 64 caratteri perché il certificato possa essere creato.
Se la casella resta disattivata, passa in rassegna questa lista:
- [ ] Il DNS dell'host punta a GitHub (
digmostra i quattro IP oppure il tuo CNAME<username>.github.io) - [ ] Nessun record A, AAAA, ALIAS o ANAME superfluo sull'apex
- [ ] Il CNAME di
wwwpunta a<username>.github.io, non all'apex né a un indirizzo pages.github.io - [ ] Il dominio in Settings > Pages corrisponde esattamente a quello scritto nel DNS
- [ ] Hai rimosso e riaggiunto il dominio una volta
Verificare il dominio (caldamente consigliato)
La verifica impedisce ad altri account GitHub di rivendicare il tuo dominio se il tuo sito Pages dovesse mai essere scollegato. GitHub elenca i domain takeover come possibili quando elimini il repository, quando il tuo piano di fatturazione viene declassato o dopo qualsiasi modifica che scollega il dominio mentre resta configurato per GitHub Pages senza essere verificato.
- Apri le impostazioni del tuo profilo (non quelle del repository), poi Pages nella barra laterale.
- Clicca su Add a domain, inserisci il dominio e conferma.
- Crea il record TXT che GitHub ti mostra. L'host avrà una forma simile a
_github-pages-challenge-USERNAME.example.com. - Controlla che sia visibile con
dig _github-pages-challenge-USERNAME.example.com +nostats +nocomments +nocmd TXT. - Tornato su GitHub, usa il menu accanto al dominio, scegli Continue verifying, poi Verify.
Secondo GitHub può essere immediato oppure richiedere fino a 24 ore. Lascia il record TXT al suo posto anche dopo la verifica. Evita inoltre i record wildcard come *.example.com: GitHub avverte che comportano un rischio di takeover anche quando il dominio è verificato.
Problemi comuni
- 404 sul dominio personalizzato, ma il sito funziona su github.io. Il dominio non è mai stato salvato in Settings > Pages, oppure il DNS non si è ancora propagato. Controlla entrambe le cose.
- Il dominio si azzera a ogni deploy. Se pubblichi da un branch, il file
CNAMEnel branch sorgente deve contenere il tuo dominio. Una build che svuota la root del branch, o un deploy che omette il file, può eliminarlo. Passare a un workflow Actions personalizzato rende il file superfluo. - L'apex funziona, www no (o viceversa). Servono record per entrambi gli host. Ricorda che GitHub reindirizza l'host abbinato solo se anche il suo DNS punta a GitHub Pages.
- Il certificato non arriva mai. Segui la checklist qui sopra, cercando per prima cosa eventuali record superflui.
Se preferisci non gestire il DNS da solo
GitHub Pages è ideale per i siti statici che già tieni in un repository. Se ti serve soprattutto avere un sito online con il tuo dominio, i domini personalizzati di We.Inc ti guidano nello stesso passaggio DNS direttamente dentro il builder, e la guida alla connessione del dominio lo spiega per qualsiasi provider. Il piano gratuito di We.Inc ti permette di pubblicare fino a tre siti da template già pronti; il builder AI che crea un sito a partire da un prompt parte dal piano Starter a $20 al mese. Puoi registrarti qui.
Inizia gratis · Nessuna carta di credito richiesta
Fondatore di We.Inc
Umair è il fondatore di We.Inc. Scrive di creazione di siti web con l’IA, agenzie e gestione di uno studio web.
Pronto a creare qualcosa di grande?
Unisciti a 15,000+ aziende che usano We.Inc per lanciare, crescere e automatizzare, tutto da un'unica piattaforma.
Inizia gratisNessuna carta di credito richiesta · Parla con il team vendite
Correlati: Blog
- Gmail con dominio personalizzato
- DKIM su GoDaddy
- Valutazione domini GoDaddy
- Reindirizzamento dominio GoDaddy
- Record MX GoDaddy
- Nameserver GoDaddy
- Record TXT GoDaddy
- Vibe coding con Google AI Studio
Prodotto
Per chi è
- Per le agenzie
- Per i freelance
- Per i provider di hosting
- Per le piattaforme SaaS
- Per le startup
- Servizi finanziari
- Soluzioni per la sanità
Funzionalità
Risorse
- Blog
- Centro assistenza
- Strumenti gratuiti per le aziende
- Free UI Components
- Template
- Raccolte di template
- Esempi di siti
- Guide
- Confronti
- Alternative
- I migliori
- Recensioni
- Guide ai prezzi
- Casi d'uso
- Glossario e guide
- Integrazioni
- Sviluppatori
- Benchmark
- Windows App