Come si fa

Caricare un sito web sul server dal Mac

5 min di lettura

Caricare un sito web è di gran lunga il motivo più comune per cui qualcuno tocca ancora l’FTP. È anche il punto in cui capitano gli errori più evitabili: file nella cartella sbagliata, un sito rotto visibile al mondo per dieci minuti, o un .env pieno di credenziali del database parcheggiato in una cartella pubblica.

Prima di tutto, trova la web root

Quando ti connetti finisci nella home del tuo account, che di solito non è quello che il server web pubblica. Cerca una di queste:

CartellaHosting tipico
public_htmlcPanel, la maggior parte degli hosting condivisi
httpdocsPlesk
wwwAlcune configurazioni VPS, pannelli più datati
/var/www/htmlApache/nginx predefiniti su un server gestito in proprio
htdocsXAMPP, alcuni hosting storici

La verifica è semplice: la cartella che contiene l’index.html o l’index.php che i tuoi visitatori già vedono è la web root. Carica un file chiamato test.txt e prova https://tuodominio.it/test.txt. Se si apre, l’hai trovata. Poi cancellalo.

Salva quel percorso nelle impostazioni del sito, così ogni sessione si apre già lì. In Upstream è il campo del percorso remoto sul sito.

Cosa caricare — e cosa non caricare mai

Carica il risultato della build, non la tua cartella di lavoro. Per un generatore di siti statici o un bundler significa il contenuto di dist/, build/, _site o public, non la radice del progetto.

Cose che non dovrebbero mai arrivare su un server pubblico:

  • .git/ — l’intera storia del progetto, comprese tutte le credenziali che ci siano mai finite dentro con un commit. https://tuodominio.it/.git/config è uno dei primi percorsi che provano gli scanner automatici.
  • node_modules/ — migliaia di file, nessuno dei quali serve a runtime per un sito statico, e il caricamento diventa venti volte più lungo.
  • .env e i file di configurazione con credenziali vere.
  • .DS_Store — innocuo, ma rivela la struttura delle tue cartelle, ed è ovunque su un Mac.
  • Le source map in produzione, se preferisci non pubblicare codice sorgente leggibile.

Un file .syncignore risolve la questione in modo permanente, invece di richiedere vigilanza:

.git/
node_modules/
.DS_Store
.env
*.map

Upstream applica le esclusioni su entrambi i lati, quindi un file escluso non viene né caricato né riscaricato.

Non caricare direttamente sopra un sito in produzione

Copiare 400 file sopra un sito attivo significa che per tutta la durata i visitatori vedono un misto di vecchio e nuovo — un file HTML nuovo che punta a un bundle CSS non ancora arrivato. Su una connessione lenta quella finestra dura minuti.

Due modi per evitarlo:

Carica in una cartella di staging, poi scambia. Metti la nuova build in public_html_new, verificala, poi rinomina le cartelle. Lo scambio è una sola rinomina, di fatto istantanea.

Carica prima le risorse, l’HTML per ultimo. Le risorse statiche di solito hanno un hash del contenuto nel nome e si aggiungono soltanto, quindi possono arrivare in anticipo senza rompere niente. Carica CSS, JS e immagini, poi l’HTML che li richiama. Le pagine vecchie continuano a funzionare fino al momento in cui vengono sostituite.

I permessi, in breve

La regola che copre quasi ogni caso:

  • Cartelle: 755 — il proprietario può scrivere, tutti possono entrare e leggere.
  • File: 644 — il proprietario può scrivere, tutti possono leggere.
  • Script che devono essere eseguiti: 755.
  • Mai 777. Significa che chiunque sul server può modificare il file. È la “soluzione” tradizionale agli errori di permessi ed è il modo in cui un hosting condiviso diventa l’hosting di malware di qualcun altro.

I file di configurazione con dei segreti stanno meglio a 600, dove la configurazione lo consente.

Tieni presente che i permessi sono un concetto POSIX: valgono per FTP, FTPS e SFTP su un server Unix, ma un server FTP ospitato su Windows potrebbe ignorarli del tutto.

Verifica prima di andartene

Apri il sito in una finestra privata — non nel tuo browser abituale, che è pieno di risorse in cache pronte a nasconderti un file mancante. Controlla una pagina che hai cambiato, una che non hai toccato e una risorsa che doveva essere sostituita. Poi guarda le date nel pannello remoto: un file con la data di ieri non è stato caricato.

Passo per passo

  1. Compila il sito in locale e verifica che la cartella di output sia davvero quella che intendi pubblicare.
  2. Connettiti in SFTP se il tuo hosting offre SSH, altrimenti in FTPS. Salva il sito in modo che il percorso remoto si apra sulla web root.
  3. Aggiungi un .syncignore che escluda .git/, node_modules/, .DS_Store e ogni file che contenga credenziali.
  4. Carica prima le risorse e l’HTML per ultimo — oppure carica in una cartella di staging e rinominala al posto giusto.
  5. Controlla i permessi: 755 per le cartelle, 644 per i file, mai 777.
  6. Verifica in una finestra di navigazione privata, e controlla le date nel pannello remoto per individuare ciò che non è stato trasferito.

Domande frequenti

Dove vanno caricati i file del sito?

Nella web root — public_html sugli hosting con cPanel, httpdocs su Plesk, /var/www/html su un tipico server gestito in proprio. La cartella giusta è quella che contiene il file index che i tuoi visitatori già vedono.

Perché il sito mostra “Index of /” invece della mia pagina?

In quella cartella non c’è nessun file index, quindi il server ne sta elencando il contenuto. O il file si chiama in un altro modo, o è finito una cartella più in basso, oppure si chiama Index.html su un server che distingue maiuscole e minuscole e si aspetta index.html.

Devo caricare node_modules?

No. Per un sito statico non serve niente di quello che c’è dentro a runtime. Per un’applicazione Node le dipendenze si installano sul server con npm install, non si caricano.

Perché il mio CSS non si è aggiornato?

O il file non è stato trasferito — controlla la sua data sul server — oppure il browser ti sta servendo una copia dalla cache. Prova in una finestra privata prima di dare per scontato che il caricamento sia fallito.

Che permessi devo usare?

755 per le cartelle, 644 per i file, 755 per gli script che devono essere eseguiti. Evita del tutto 777: permette a qualsiasi utente sul server di scrivere nel tuo file.

È sicuro caricare sopra un sito già online?

Funziona, ma durante il caricamento i visitatori possono vedere un misto incoerente di file vecchi e nuovi. Caricare in una cartella di staging e rinominarla al posto giusto elimina completamente quella finestra.

Upstream — il client FTP, FTPS e SFTP nativo per macOS

Una coda di trasferimento che puoi mettere in pausa, riprendere e riordinare, sincronizzazione delle cartelle con anteprima dry-run, modifica remota live e credenziali nel Keychain di macOS. Gratis, senza abbonamento.