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 visitatoriDa impostare come dominio personalizzatoRecord DNS necessariNote
www.example.comwww.example.comCNAME su www verso <username>.github.io, più record A sull'apexConfigurazione consigliata da GitHub. example.com viene reindirizzato a www.
example.comexample.comRecord A sull'apex (oppure un solo ALIAS/ANAME), più un CNAME su wwwwww.example.com viene reindirizzato all'apex.
blog.example.comblog.example.comCNAME su blog verso <username>.github.ioNon 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

  1. 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.
  2. Controlla cosa ha fatto GitHub nel tuo repo. Se pubblichi da un branch, GitHub fa il commit di un file CNAME nella root di quel branch. Se pubblichi con un workflow GitHub Actions personalizzato, nessun file CNAME viene creato e quello eventualmente presente viene ignorato.
  3. 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.
  4. Crea i record DNS presso il tuo provider DNS (vedi la sezione successiva).
  5. Aspetta la propagazione. GitHub parla di un massimo di 24 ore. Puoi controllare lo stato da terminale con dig www.example.com +noall +answer.
  6. 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

TipoHostValore
CNAMEwww<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)

TipoHostValore
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 @:

TipoHostValore
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:

  1. Torna su Settings > Pages.
  2. Cerca un segno di spunta accanto al dominio: significa che il controllo DNS è andato a buon fine.
  3. 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 (dig mostra i quattro IP oppure il tuo CNAME <username>.github.io)
  • [ ] Nessun record A, AAAA, ALIAS o ANAME superfluo sull'apex
  • [ ] Il CNAME di www punta 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.

  1. Apri le impostazioni del tuo profilo (non quelle del repository), poi Pages nella barra laterale.
  2. Clicca su Add a domain, inserisci il dominio e conferma.
  3. Crea il record TXT che GitHub ti mostra. L'host avrà una forma simile a _github-pages-challenge-USERNAME.example.com.
  4. Controlla che sia visibile con dig _github-pages-challenge-USERNAME.example.com +nostats +nocomments +nocmd TXT.
  5. 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 CNAME nel 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

Umair Ali Sadaqat

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 gratis

Nessuna carta di credito richiesta · Parla con il team vendite

Correlati: Blog

Prodotto

Per chi è

Funzionalità

Risorse

Azienda

Mappa del sito