1 19/05/2026 10 min

In IIS un nuovo sito non si “aggiunge” solo con un click: devi allineare quattro cose che spesso vengono confuse tra loro, cioè nome del sito, binding, cartella fisica e identità del pool. Se una sola di queste è fuori posto, il risultato tipico è una pagina vuota, un 403, un 500.19 o un conflitto di binding con un sito già esistente.

La procedura corretta è semplice, ma va fatta nell’ordine giusto. Prima prepari la directory, poi crei il sito, poi assegni il pool applicativo, infine verifichi che DNS, porta e certificato puntino davvero dove devono. In questo modo eviti di “far partire” un sito che in realtà non è raggiungibile o non ha i permessi per leggere i file.

Cosa serve prima di aprire IIS

Prima di entrare in IIS conviene avere già pronti alcuni elementi. La cartella del sito deve esistere, il nome host deve essere deciso, la porta deve essere libera e, se il sito sarà in HTTPS, il certificato deve essere installato nel computer locale. Se lavori in produzione, valuta anche se il sito deve essere isolato in un pool dedicato oppure se può condividere un pool esistente.

Per un sito standard ti basta questo set minimo:

  • una directory fisica, ad esempio C:\Sites\miosito;
  • un nome host, ad esempio www.esempio.local o www.dominio.tld;
  • una porta, di solito 80 per HTTP e 443 per HTTPS;
  • un certificato valido se il sito usa TLS;
  • permessi di lettura per l’identità del pool applicativo sulla cartella del sito.

Se questo pezzo manca, IIS può anche creare il sito, ma il sito non funzionerà davvero. Il controllo dei prerequisiti è il modo più rapido per evitare di inseguire falsi problemi lato applicazione quando il guasto è solo un binding o un ACL sbagliato.

Creare la cartella del sito e preparare i permessi

La directory fisica è il primo punto da mettere in ordine. Crea una cartella dedicata e non usare directory condivise con altri siti, soprattutto se il server ospita più applicazioni. Un percorso separato rende più semplice il backup, il troubleshooting e il rollback.

Se lavori da shell amministrativa, puoi preparare la cartella così:

mkdir C:\Sites\miosito

Il punto delicato non è la creazione della cartella, ma i permessi. Il sito deve poter leggere i file e, se l’applicazione scrive log o cache, deve poter scrivere solo nelle directory necessarie. In IIS l’identità effettiva è spesso quella del pool applicativo, non dell’utente con cui stai facendo login.

Se il pool usa l’identità predefinita, il gruppo IIS AppPool\NOMEPOOL è il riferimento più comune. In alternativa puoi usare un account di servizio dedicato, ma solo se hai un motivo preciso e una gestione credenziali adeguata. Non dare permessi troppo larghi alla cartella “per farla finita”: è il modo più veloce per creare un problema di sicurezza e di manutenzione.

Creare il sito da IIS Manager

Apri IIS Manager, espandi il nodo del server e vai su Sites. Dal pannello azioni scegli Add Website.... Qui definisci i parametri che determinano come IIS identifica il sito e verso quale cartella deve puntare.

Compila i campi con attenzione:

  1. Site name: scegli un nome chiaro, ad esempio miosito o www-dominio. Questo nome è interno a IIS e ti aiuta a distinguerlo dagli altri siti.
  2. Physical path: seleziona la cartella preparata prima, ad esempio C:\Sites\miosito.
  3. Binding: imposta http o https, poi scegli l’indirizzo IP se vuoi limitarlo, la porta e l’host name se usi name-based hosting.
  4. Start Website immediately: lascialo attivo se vuoi verificare subito il sito, ma solo dopo aver controllato che binding e permessi siano corretti.

Il binding è il punto in cui si commettono più errori. Se il server ospita più siti sulla stessa porta, l’host name deve essere univoco e coerente con il DNS. Se invece usi un solo sito sul server, puoi anche partire con un binding semplice su porta 80, ma è comunque meglio definire il nome host già da subito se il sito dovrà stare online con un dominio vero.

Dopo aver confermato, IIS crea il sito e lo inserisce nell’elenco dei siti gestiti. Se il nome host o la porta sono già occupati, la creazione può essere accettata ma il sito non risponderà correttamente finché non risolvi il conflitto.

Assegnare un Application Pool dedicato

Un sito nuovo dovrebbe quasi sempre avere un pool dedicato. Condividere il pool con altri siti è comodo solo finché non devi isolare un crash, un consumo anomalo di memoria o un aggiornamento applicativo. Un pool separato semplifica il riavvio del solo sito interessato e riduce il blast radius se qualcosa va storto.

Puoi creare il pool da Application Pools con Add Application Pool.... Scegli un nome coerente con il sito e seleziona la versione CLR giusta. Se l’applicazione è ASP.NET classico, la versione del runtime va scelta con attenzione; se invece è un sito statico o un’app moderna che non usa il runtime .NET Framework di IIS, spesso ha senso usare No Managed Code.

Una volta creato il pool, torna sul sito, apri Basic Settings... e assegna quel pool al sito. A quel punto IIS eseguirà il sito con l’identità del pool, e questa identità deve avere accesso alla directory del contenuto.

Se vedi un errore di accesso, il controllo più rapido è questo: il pool esiste, è avviato e l’account del pool ha permessi almeno di lettura sulla cartella del sito. In molti casi il sito “sembra” rotto, ma è solo una ACL mancante.

Configurare il binding HTTP e HTTPS

Il binding dice a IIS quando deve rispondere a una richiesta. In HTTP il caso più semplice è porta 80 + host name. In HTTPS devi aggiungere anche il certificato, e il controllo qui non è solo estetico: se il certificato non corrisponde al nome host o non è associato al binding giusto, il browser mostrerà avvisi o il traffico non partirà come previsto.

Per aggiungere o modificare un binding entra nelle impostazioni del sito e apri Bindings.... Da lì puoi:

  • aggiungere un binding http su porta 80;
  • aggiungere un binding https su porta 443;
  • associare un certificato SSL/TLS al binding HTTPS;
  • definire un host name specifico per il virtual hosting.

Se il sito è pubblico, oggi ha poco senso lasciare HTTP come unica esposizione. In molti scenari conviene mantenere HTTP solo per redirect verso HTTPS. La logica di redirect può stare nell’applicazione, in IIS o davanti al server con un reverse proxy, ma il punto operativo resta lo stesso: il sito deve rispondere in modo coerente su entrambi i canali, senza loop o conflitti di binding.

Con HTTPS, verifica anche il certificato nel Server Certificates. Se il certificato non è presente nel computer locale, il binding non potrà usarlo. Se il certificato è installato ma il nome host non coincide, il browser potrebbe segnalare mismatch. Questi problemi non si risolvono “rinfrescando” IIS: vanno corretti a livello di certificato e binding.

Verificare il sito con un controllo minimo ma serio

Dopo la creazione non limitarti a vedere il pallino verde in IIS. Un sito può risultare avviato e continuare a non servire contenuti correttamente. Il controllo migliore è una richiesta reale dal server o da una macchina che raggiunge il DNS previsto.

Dal server prova a fare una richiesta locale:

curl -I http://localhost

Se il sito usa un host name specifico, verifica anche quel nome:

curl -I http://www.esempio.local

Il risultato atteso è un codice 200, 301 o 302 a seconda della logica del sito. Un 403 indica spesso permessi o document root non corretti. Un 404 può voler dire che la root del sito non contiene il file iniziale atteso, come index.html o default.aspx. Un 500 o 500.19 punta invece a un problema di configurazione, modulo mancante o web.config non valido.

Se il problema compare solo dall’esterno, controlla il DNS e il firewall. Se compare anche in locale, il problema è quasi certamente nel sito, nel pool o nei permessi. Questa distinzione ti fa risparmiare tempo e ti evita di toccare componenti che non c’entrano nulla.

Gestire il file `web.config` senza farsi male

Molti siti IIS moderni dipendono da web.config. Questo file può contenere rewrite, autorizzazioni, handler e altre impostazioni che incidono direttamente sul comportamento del sito. Se il sito non parte dopo il deploy, spesso il problema non è IIS in sé ma una direttiva malformata o un modulo non installato sul server.

Quando ricevi un errore di configurazione, il primo posto da guardare è il log dell’applicazione e l’event viewer, oltre al contenuto di web.config. Se il sito è nuovo, tieni il file minimo indispensabile e aggiungi le regole una alla volta. È il modo più semplice per capire quale direttiva introduce il problema.

Un esempio tipico è il rewrite verso HTTPS. Se l’applicazione o il sito usa redirect, evita di costruire regole duplicate in più livelli, altrimenti rischi loop o redirect inutili. La logica deve stare in un solo punto ben definito.

Un esempio pratico di sito statico

Supponiamo di voler pubblicare un sito statico chiamato miosito. La cartella è C:\Sites\miosito, il dominio è www.miodominio.tld e il sito deve rispondere in HTTPS. La sequenza operativa è questa:

  1. crei la cartella e copi i file del sito;
  2. assegni i permessi di lettura al pool applicativo;
  3. crei un nuovo sito in IIS con binding https e host name www.miodominio.tld;
  4. colleghi il certificato corretto al binding;
  5. assegni un application pool dedicato con No Managed Code se il sito è solo statico;
  6. verifichi con curl -I https://www.miodominio.tld o dal browser.

Se il sito restituisce una pagina vuota, non partire subito dal codice applicativo. Prima controlla se esiste un file di default come index.html o se il sito è configurato per servire un’altra pagina iniziale. In IIS il problema “non vedo nulla” è spesso solo un default document mancante.

Errori tipici e come leggerli

Ci sono alcuni segnali che tornano spesso quando si aggiunge manualmente un sito. Un 403.14 indica spesso che non c’è un documento predefinito e la directory browsing è disattivata. Un 500.19 di solito segnala un problema nel file di configurazione o un modulo mancante. Un 503 può dipendere dal pool fermo o in crash. Un errore di binding, invece, spesso non genera una vera pagina di errore ma semplicemente rende il sito irraggiungibile sulla porta o sul nome host sbagliato.

Quando il sintomo è ambiguo, guarda sempre l’evento più vicino al tentativo di apertura del sito. In Windows, Event Viewer e i log di IIS sono il primo punto da consultare. Se il pool non parte, se la cartella è inaccessibile o se il modulo richiesto non è installato, la traccia compare quasi sempre lì prima che nel browser.

In un contesto gestito bene, ogni nuovo sito dovrebbe avere anche una nota operativa: nome del sito, path fisico, pool associato, binding, certificato usato e chi ha i permessi di modifica. Non è burocrazia: è il minimo per fare troubleshooting veloce quando tra qualche mese qualcuno dovrà capire come è stato creato il sito.

Controlli finali prima di considerare il sito pronto

Prima di chiudere il lavoro, fai una verifica finale ordinata. Non basta che la home si apra una volta. Devi controllare che il sito risponda con il nome giusto, sul protocollo giusto e con i permessi giusti. Se c’è un redirect da HTTP a HTTPS, verifica che non ci sia un loop. Se c’è un certificato, verifica che sia quello atteso e che la catena sia corretta.

  • Il sito compare in IIS come Started.
  • Il pool applicativo è avviato e non si arresta subito dopo il lancio.
  • curl -I restituisce il codice atteso.
  • Il binding mostra host, porta e certificato corretti.
  • La cartella del sito è leggibile dal pool e scrivibile solo dove serve.

Se tutto torna, il sito è pronto per il deploy dei contenuti o dell’applicazione. Se invece uno di questi punti fallisce, correggi il singolo elemento prima di toccarne altri. È il modo più pulito per evitare di introdurre variabili inutili mentre stai ancora cercando il problema originale.

Assunzione: il server usa una versione recente di Windows Server con IIS già installato e accesso amministrativo locale.