GitHub Pages: cos'è e come pubblicare un sito gratis

Se hai un repository su GitHub, hai già a disposizione un modo gratuito per mettere online un sito: non serve un hosting, non serve una carta di credito, e la pubblicazione avviene inviando codice come faresti normalmente. È GitHub Pages. In questo articolo trovi come si usa, per cosa è adatto e — soprattutto — cosa non può fare.

Cos'è

GitHub Pages è un servizio di hosting per siti statici integrato in GitHub: pubblica i file di un repository come sito web, gratuitamente, con certificato HTTPS incluso.

La parola chiave è statici: HTML, CSS, JavaScript, immagini. Il server consegna i file così come sono, senza eseguire codice.

L'indirizzo predefinito è nomeutente.github.io/nome-repository.

Come si attiva

Nella forma più semplice sono tre passaggi:

1. Nelle impostazioni del repository, sezione Pages
2. Scegli il ramo da pubblicare (di solito main) e la cartella (la radice, oppure /docs)
3. Salva

Nel giro di un minuto il sito è online. Da quel momento, ogni invio su quel ramo aggiorna il sito automaticamente.

Se il tuo file principale si chiama index.html ed è nella radice, non serve altro.

Con un generatore di siti

Se il sito va costruito prima — perché usi un generatore statico — il flusso passa attraverso un'automazione:

1. Invii il codice sorgente
2. Una GitHub Action costruisce il sito
3. Il risultato viene pubblicato

GitHub offre modelli già pronti per i generatori più diffusi, quindi nella pratica si tratta di scegliere un file di configurazione e adattarlo.

Un dettaglio che fa perdere tempo a tutti: se il sito sta in una sottocartella (utente.github.io/progetto), va configurato il percorso base nel generatore. Altrimenti tutti i collegamenti a CSS e immagini puntano alla radice del dominio e il sito appare senza stili — il classico "in locale funziona, online è tutto bianco".

Il dominio personalizzato

Si può usare un proprio dominio, gratuitamente e con HTTPS.

Nelle impostazioni Pages indichi il dominio, e nel pannello DNS del tuo registrar aggiungi i record che GitHub indica: un CNAME verso il tuo indirizzo GitHub per un sottodominio, oppure dei record A verso i loro indirizzi per il dominio nudo.

Due accortezze:

La propagazione richiede tempo — da minuti a qualche ora. Se non funziona subito, spesso basta aspettare.

Attiva "Enforce HTTPS" dopo che il certificato è stato emesso. Viene generato automaticamente, ma può richiedere un po' dopo la configurazione del dominio.

Il quadro generale è in come collegare un dominio al sito.

Per cosa è adatto

I casi in cui è la scelta giusta:

Documentazione di un progetto. È l'uso per cui è nato e resta il migliore: la documentazione vive nello stesso repository del codice, si aggiorna insieme a lui.

Portfolio e sito personale. Gratis, affidabile, con dominio proprio. Per un portfolio da developer è più che sufficiente.

Landing page e siti vetrina senza parti dinamiche.

Blog con generatore statico.

Dimostrazioni di progetti — la versione funzionante accanto al codice.

I limiti da conoscere

Questa è la parte che evita di scoprire i problemi a metà progetto.

Solo siti statici. Niente PHP, niente database, niente codice eseguito sul server. Se ti serve un modulo di contatto che invia email, va appoggiato a un servizio esterno.

Il repository deve essere pubblico, salvo piani a pagamento. Sui repository privati la pubblicazione è una funzione dei piani superiori.

Ci sono limiti di dimensione e traffico. Indicativamente il sito non deve superare qualche gigabyte e c'è una soglia mensile di banda, con l'indicazione che il servizio è pensato per progetti personali e documentazione — non per applicazioni commerciali ad alto traffico. I numeri esatti vanno verificati sulla documentazione ufficiale perché cambiano.

Nessuna intestazione HTTP personalizzata. Non puoi impostare regole di sicurezza avanzate o controllare finemente la cache.

Nessun reindirizzamento lato server. Se un giorno cambi la struttura degli URL, non puoi impostare dei 301 veri — cosa che conta parecchio in caso di migrazione di un sito.

Nessuna funzione serverless. Se ti serve eseguire anche solo un po' di logica lato server, serve altro.

Le alternative

Vale la pena conoscerle, perché in diversi casi convengono:

Cloudflare Pages, Netlify, Vercel — sono anch'essi gratuiti per progetti personali, ma aggiungono le cose che a Pages mancano: funzioni serverless, intestazioni personalizzate, reindirizzamenti, anteprime automatiche per ogni proposta di modifica, e in alcuni casi statistiche.

Il confronto pratico:

	GitHub Pages	Piattaforme moderne
Siti statici	✓	✓
Funzioni serverless	✗	✓
Reindirizzamenti	✗	✓
Intestazioni personalizzate	✗	✓
Anteprime per PR	✗	✓
Repository privati (gratis)	✗	✓
Integrazione con GitHub	Nativa	Ottima

Quando conviene comunque GitHub Pages: documentazione di progetto, siti che non cresceranno, e la voglia di non aggiungere un altro servizio da collegare.

Quando conviene passare ad altro: se prevedi funzioni dinamiche, se il repository deve restare privato, o se ti serve controllo su reindirizzamenti e intestazioni.

Il quadro completo delle opzioni gratuite è in mettere online un sito a costo zero.

In sintesi

GitHub Pages pubblica siti statici direttamente da un repository, gratuitamente e con HTTPS. Si attiva in tre clic, e da lì in poi ogni invio aggiorna il sito.

È perfetto per documentazione, portfolio, siti vetrina e blog statici — ed è nato esattamente per il primo di questi casi.

I limiti da conoscere prima: solo statico, repository pubblico salvo piani a pagamento, niente reindirizzamenti né intestazioni personalizzate, nessuna funzione serverless.

Se uno di questi limiti tocca il tuo progetto, le piattaforme moderne offrono lo stesso servizio gratuito con parecchie cose in più. Se invece ti serve mettere online la documentazione o un portfolio, Pages fa il lavoro senza aggiungere nessun servizio da gestire.