Se hai cercato "ospitare un file HTML online", probabilmente non vuoi una lezione sull'architettura cloud. Hai un file index.html, forse un file style.css, forse alcune immagini, e vuoi inviare a qualcuno un link che funzioni.
Questo è un problema diverso da "scegliere un provider di web hosting". Il primo lavoro è più piccolo: mettere i file online nella giusta forma, assicurarsi che il browser possa caricarli e mantenere aperto un percorso per un dominio personalizzato in seguito.
Cosa conta come sito HTML?
Ai fini dell'hosting, un sito HTML è solitamente uno di questi:
| Tipo di progetto | Cosa carichi | Esempi comuni |
|---|---|---|
| Pagina a file singolo | index.html | Pagina curriculum, pagina evento, prototipo rapido |
| Cartella statica | index.html, CSS, JS, immagini | Portfolio, sito per piccole imprese, landing page |
| Output di build | dist, build, out, public | Vite, esportazione statica React, Astro, esportazione statica Next.js |
| Archivio ZIP | Una cartella compressa contenente i file del sito | Trasferimento del cliente, esportazione generata dall'intelligenza artificiale, modello scaricato |
La parte importante è la radice. Un normale host statico prevede un file index.html al livello superiore della cartella caricata. Se il tuo ZIP si apre in my-site/index.html, carica la cartella o assicurati che la piattaforma comprenda quella struttura nidificata.
Il percorso più veloce: carica i file finiti
Per un piccolo sito statico, il primo percorso di caricamento è solitamente il meno doloroso:
- Metti
index.htmlnella radice della tua cartella. - Conserva gli asset collegati in cartelle prevedibili come
css,js,imagesoassets. - Carica la cartella o ZIP.
- Apri il link HTTPS generato.
- Fai clic su ogni pagina e percorso della risorsa.
- Prendi in gestione il progetto o aggiungi un dominio personalizzato una volta che sai che vale la pena conservare il link.
Quest'ultimo passaggio è importante. Molti piccoli siti iniziano come lavori usa e getta: un'anteprima cliente, un progetto scolastico, una bozza di landing page, un modello generato da uno strumento IA. Richiedere la configurazione completa dell'account prima del primo URL aggiunge attrito nel momento sbagliato.
Su DeployPages puoi partire dall'area di caricamento della homepage, pubblicare i file statici e poi decidere se mantenere il progetto sotto un account. Per una procedura dettagliata più specifica, consulta la guida alla pubblicazione di HTML.
Controlla i percorsi dei file prima di incolpare l'host
La maggior parte dei problemi "il mio file HTML è danneggiato online" provengono da percorsi che funzionavano localmente ma falliscono su un vero URL.
Le anteprime locali possono nascondere errori. Il tuo browser potrebbe caricare un file dal tuo computer anche quando il sito pubblicato non può. Prima del caricamento, controlla questi modelli:
| Modello locale | Modello pubblicato più sicuro | Perché |
|---|---|---|
C:\Users\you\Desktop\logo.png | ./images/logo.png | Un browser pubblicato non può leggere il tuo disco rigido. |
/Users/you/site/style.css | ./style.css | I percorsi assoluti del computer si interrompono online. |
file:///.../script.js | ./script.js | file:// URL esiste solo sulla tua macchina. |
href="/about.html" | href="./about.html" per le anteprime delle cartelle | I link relativi alla radice dipendono dalla radice pubblicata. |
Se il sito ha più pagine, aprile ciascuna dall'URL pubblicato anziché controllare solo la home page. La navigazione è il luogo in cui solitamente vengono visualizzati per primi i percorsi errati.
Quando un caricamento nel browser è meglio di Git
Git è la risposta giusta quando un progetto ha uno sviluppo attivo, una revisione e ripetute modifiche alla produzione. Non è sempre il primo passo giusto.
Il caricamento tramite browser è migliore quando:
- Hai ricevuto una cartella statica da un designer, cliente, generatore o strumento IA.
- Hai bisogno di un link prima di decidere se il progetto merita un repository.
- Stai pubblicando una pagina unica, un sito di eventi, un curriculum o un progetto di classe.
- Vuoi testare un output di build generato prima di collegare CI.
- La persona che pubblica la pagina non è la persona che scrive il codice.
Questo è il motivo per cui la pubblicazione drag-and-drop continua a comparire nelle piattaforme serie. La documentazione di Netlify Drop descrive direttamente il caso d'uso della cartella o dello ZIP, inclusi progetti da strumenti di generazione codice con IA. Cloudflare Pages documenta anche il caricamento diretto per asset precompilati da computer locale, sia con CLI sia con percorsi drag-and-drop.
Il segnale del mercato è chiaro: le persone continuano a cercare un modo semplice per caricare i file del sito e ottenere un URL.
Cosa caricare dagli strumenti comuni
Diversi strumenti denominano la cartella finale in modo diverso:
| Strumento o pila | Carica questo |
|---|---|
| HTML semplice/HTML/CSS | La cartella contenente index.html |
| Vite | dist dopo npm run build |
| Create React App | build dopo npm run build |
| Astro | dist dopo npm run build |
| Esportazione statica Next.js | out dopo l'esportazione |
| Modello HTML scaricato | La cartella dei modelli decompressa con index.html nella root |
| Sito statico generato con IA | La cartella esportata, non la trascrizione del prompt |
Se non sei sicuro di quale sia la cartella giusta, cerca quella che contiene un file index.html più asset compilati. Le cartelle sorgente come src di solito non sono ciò che pubblichi.
Cosa rende affidabile un link HTML ospitato?
Un link usa e getta può essere semplice. Un link che invii a clienti, investitori o recruiter richiede più attenzione.
Controlla:
- HTTPS per impostazione predefinita, non un link
http://non sicuro. - Un URL di anteprima stabile, così le persone possono riaprirlo.
- Facile sostituzione quando carichi una versione fissa.
- Un percorso verso un dominio personalizzato.
- Un modo per tornare indietro se il nuovo caricamento è peggiore di quello vecchio.
- Statistiche di base, perché indovinare se qualcuno ha aperto il link diventa presto poco pratico.
DeployPages segue questo percorso: prima caricamento rapido, poi domini personalizzati, distribuzione globale, statistiche e ripristino di una versione precedente quando la pagina diventa più di un test.
Una semplice lista di controllo pre-caricamento
Prima di caricare, dedica due minuti a questo:
- Apri la cartella localmente e conferma che
index.htmlè al livello più alto. - Rinomina i file con spazi o caratteri insoliti se vengono richiamati dall'HTML.
- Dove possibile, usa nomi file in minuscolo.
Logo.PNGelogo.pngnon sono la stessa cosa su molti sistemi di produzione. - Cerca
file://,localhoste il nome utente del tuo computer in HTML. - Comprimi la cartella solo dopo aver controllato la struttura principale.
- Dopo la pubblicazione, esegui il test su un telefono, non solo sul laptop di sviluppo.
Questa lista di controllo rileva più problemi reali rispetto a un altro giro di confronto tra fornitori.
Quando andare oltre un semplice caricamento
Continua a utilizzare i caricamenti diretti se il sito è per lo più statico e gli aggiornamenti sono occasionali. Passa a CLI o pubblicazioni basate su Git quando il sito presenta modifiche frequenti, un passaggio build che altre persone devono riprodurre o un processo di squadra relativo alla revisione.
DeployPages supporta il flusso basato sul caricamento senza intrappolare il progetto lì. Inizia dal browser per il primo link. Passa alle pubblicazioni CLI quando il progetto ha una build ripetibile. Aggiungi un dominio dopo l'approvazione del contenuto.
Questo ordine corrisponde al modo in cui si realizzano molti progetti reali. La prima cosa di cui hai bisogno non è una pipeline. È un link che funziona.