Quanto tempo ci vuole per fare un sito web professionale?

La domanda «quanto tempo ci vuole per fare un sito web?» arriva quasi sempre subito dopo «quanto costa?». Ed è normale: un sito non è un lavoro astratto. Deve andare online prima dell'apertura, prima della stagione, prima di una campagna, prima di una fiera o semplicemente prima che il vecchio sito continui a perdere richieste.

Il problema è che anche qui una risposta secca rischia di essere ingannevole.

Un sito di cinque pagine con testi già pronti non ha gli stessi tempi di un hotel in quattro lingue. Una landing per una campagna non ha gli stessi tempi di un e-commerce. Un sito nuovo non ha gli stessi tempi di un restyling con cento URL già indicizzati. E un prodotto digitale con account, dashboard e pagamenti non è più soltanto un sito.

La domanda utile non è quindi soltanto quanto ci vuole.

È: quali passaggi devono essere completati prima di poter andare online bene?

La risposta breve: da poche settimane a diversi mesi

Per un sito aziendale ben definito il tempo si misura normalmente in settimane, non in giorni. Anche le guide pubblicate nel 2026 sul mercato italiano descrivono un processo fatto di obiettivi, struttura, contenuti, design, sviluppo, revisioni e test prima della pubblicazione.

Come ordine di grandezza, senza trasformarlo in un listino:

| Tipo di progetto | Tempo indicativo | Dove si concentra il lavoro | | --- | ---: | --- | | Landing page semplice | 1–3 settimane | Copy, design, tracking e test | | Sito aziendale | 3–6 settimane | Architettura, contenuti, design, sviluppo | | Sito multilingua | 5–10 settimane | Lingue, adattamento contenuti, SEO internazionale | | E-commerce | 6–12 settimane | Catalogo, pagamenti, spedizioni, test | | Booking o integrazioni | 6–12+ settimane | Flussi, sistemi esterni, automazioni | | Prodotto web custom | 2–6+ mesi | UX, account, backend, dashboard, API |

Sono fasce per orientarsi, non tempi garantiti. Un progetto può essere più rapido se materiali e decisioni sono pronti. Può allungarsi molto se contenuti, fotografie, traduzioni o integrazioni vengono scoperti strada facendo.

Nel nostro articolo su quanto costa un sito web nel 2027 abbiamo spiegato perché il prezzo dipende dal perimetro. Per il tempo vale esattamente la stessa regola.

Più cose il sito deve fare, più decisioni vanno prese e testate.

La prima settimana spesso non contiene una riga di codice

È una delle parti che sorprende di più chi commissiona un sito per la prima volta.

All'inizio potremmo non sviluppare niente.

Prima dobbiamo capire cosa vendi, chi deve trovare il sito, quali pagine servono, quali contenuti esistono già, quali ricerche vuoi intercettare e cosa deve succedere quando una persona arriva.

Questa fase può sembrare lenta perché non produce ancora una home da mostrare.

In realtà è il modo più veloce per non perdere settimane dopo.

Se il sito parte direttamente dalla grafica, molte domande riemergono quando è più costoso rispondere:

• questa pagina serve davvero?
• questo servizio ha bisogno di una pagina propria?
• il menu deve avere cinque o nove voci?
• il cliente deve chiamare, compilare un form o prenotare?
• serve una versione in inglese?
• il vecchio URL va mantenuto?
• questa campagna deve atterrare sulla home o su una landing dedicata?

Sono decisioni di architettura, non dettagli.

Nella nostra pagina dedicata alla realizzazione di siti web il processo parte infatti da obiettivi e struttura, non dal colore del bottone.

Contenuti pronti: il modo più semplice per guadagnare tempo

Il codice raramente è la prima causa di ritardo.

Molto più spesso il progetto aspetta un testo, una fotografia, il listino aggiornato, l'elenco dei servizi, le traduzioni o una decisione interna.

Succede così: il design della pagina è pronto ma manca il contenuto principale. Si mette del testo provvisorio. Quel testo occupa tre righe. Due settimane dopo arriva la versione reale, che ne occupa dodici. La pagina va riprogettata.

Oppure arriva una fotografia verticale dove il layout prevedeva un orizzontale. O scopriamo che un servizio che sembrava secondario richiede in realtà metà del sito.

Per questo i contenuti non sono qualcosa da «mettere dentro» alla fine.

Fanno parte del progetto.

Preparare in anticipo almeno questi materiali riduce molto i tempi:

• elenco definitivo dei servizi;
• messaggi principali;
• fotografie utilizzabili;
• loghi e materiali del brand;
• dati societari e contatti;
• eventuali listini o cataloghi;
• lingue necessarie;
• accessi al vecchio sito, dominio e analytics.

Non significa arrivare con tutto perfetto.

Significa sapere cosa esiste, cosa manca e chi deve produrlo.

Nel progetto Wonder Creators, per esempio, i quattro servizi sono diventati quattro capitoli numerati. Quella scelta non nasce dal codice: nasce dal decidere prima come una persona deve capire l'offerta.

Una volta presa quella decisione, design e sviluppo diventano più veloci, perché non devono più indovinare la struttura.

Il design non è una fase da comprimere fino a sparire

«Facciamo subito il sito e poi sistemiamo la grafica» sembra un modo per guadagnare tempo.

Spesso fa perdere il doppio.

Il design serve a risolvere prima, su uno strumento più veloce da modificare, problemi che in codice costano di più.

Gerarchia, ordine delle sezioni, dimensione dei contenuti, comportamento mobile, form, menu e call to action possono essere verificati prima che diventino componenti.

È molto più semplice spostare un blocco in un progetto grafico che ricostruire una sezione già collegata a dati, animazioni e responsive.

Questo non significa che ogni sito richieda settimane di prototipi.

Significa che la quantità di design deve essere proporzionata al progetto.

Una landing può essere approvata rapidamente. Un sito con molte pagine e componenti diversi richiede un sistema più ampio. Un'app richiede anche stati, errori, conferme, flussi e schermate che non esistono su una semplice home.

Ridurre questa fase ha senso solo se il progetto è davvero semplice.

Il cliente può accelerare il progetto più dell'agenzia

È una frase che può sembrare comoda detta da chi costruisce siti, ma è molto concreta.

Se un feedback arriva in due giorni, il progetto continua.

Se arriva dopo due settimane, quelle due settimane entrano nella data di consegna anche se il lavoro richiesto è identico.

La situazione peggiore è il feedback frammentato.

Una persona chiede di accorciare una sezione. Il giorno dopo un'altra chiede di aggiungere contenuto. Una terza approva una versione diversa via WhatsApp. Nessuno sa quale indicazione sia quella definitiva.

Un processo semplice funziona meglio:

1. una persona raccoglie il feedback;
2. le osservazioni arrivano insieme;
3. ogni fase viene approvata prima di passare alla successiva;
4. ciò che cambia dopo l'approvazione viene trattato come una modifica di perimetro.

Non è burocrazia.

È il modo per evitare di rifare la stessa cosa tre volte.

Le revisioni non sono il problema: lo sono le revisioni senza fine

Un sito deve essere rivisto.

Il primo design non è sacro e il cliente deve poter correggere ciò che non rappresenta l'azienda.

Il problema nasce quando ogni revisione riapre tutte le decisioni precedenti.

Se alla fase di sviluppo si cambia completamente la struttura approvata, non stiamo più correggendo il sito. Stiamo tornando alla fase di architettura.

Lo stesso vale per il copy.

Cambiare una frase è normale. Scoprire a fine progetto che l'azienda vuole parlare a un pubblico completamente diverso significa ripensare molte pagine.

Per questo un calendario realistico non contiene solo ore di lavoro.

Contiene momenti di decisione.

Il mobile richiede tempo perché non è la versione piccola del desktop

Su molti progetti il lavoro mobile viene ancora immaginato come l'ultima rifinitura.

Si costruisce il desktop, poi si «adatta».

Per siti semplici può funzionare. Per progetti con navigazioni, interazioni, tabelle, moduli, prenotazioni o contenuti lunghi può creare un secondo progetto dentro il primo.

Sul telefono cambiano spazio, gesto, priorità e contesto.

Un numero di telefono deve essere toccabile. Una CTA deve essere raggiungibile con un pollice. Una tabella che funziona a 1440 pixel può diventare illeggibile a 375. Un menu che contiene dodici voci può essere un problema completamente diverso.

Per Wonder Creators il telefono era particolarmente importante perché l'azienda vende contenuti social: il pubblico incontra quel tipo di lavoro proprio su uno schermo verticale.

Per CDA Servizi Auto, invece, il mobile è critico per un altro motivo: chi cerca il soccorso stradale può essere fermo in strada e deve chiamare subito.

Stesso principio, due motivi completamente diversi.

Un sito multilingua moltiplica più dei testi

Aggiungere una lingua non significa duplicare una pagina e premere «traduci».

Ogni versione deve avere URL, metadata, navigazione, testi e collegamenti coerenti.

Poi ci sono le revisioni.

Chi controlla l'inglese? Chi approva il tedesco? Le offerte sono identiche in tutti i mercati? Le parole usate dai clienti sono le stesse?

Un progetto in due lingue non dura esattamente il doppio, perché design e sviluppo vengono riutilizzati. Ma il lavoro editoriale aumenta in modo significativo.

Lo stesso vale per immagini con testo incorporato, PDF, email automatiche, form e messaggi di conferma.

Per questo abbiamo dedicato un intero approfondimento a come progettare un sito in più lingue, che fa parte dello stesso cluster di questa guida.

Booking, pagamenti e gestionali cambiano il calendario

Una pagina «Camere» può essere sviluppata rapidamente.

Un sistema di prenotazione è un'altra cosa.

Bisogna sapere da dove arrivano le disponibilità, come vengono sincronizzate, cosa succede dopo l'invio, chi riceve la conferma, se c'è un pagamento, quali email partono e come vengono gestite cancellazioni e modifiche.

A volte il sito deve solo collegarsi a un booking engine esistente.

A volte deve dialogare con un gestionale.

A volte il sistema va costruito.

Queste tre frasi possono sembrare uguali in un brief — «serve la prenotazione online» — ma producono tempi completamente diversi.

Per Punta Falcone Resort il booking diretto fa parte della promessa del sito: non è una funzione aggiunta in fondo, è uno degli obiettivi principali.

Nel settore hotel e resort questo punto pesa ancora di più perché il sito deve spesso convivere con OTA, channel manager, stagionalità e più lingue.

Rifare un sito può richiedere più tempo che crearne uno nuovo

Sembra controintuitivo.

Se il sito esiste già, non dovrebbe esserci meno da fare?

Non sempre.

Un sito esistente porta con sé URL indicizzati, contenuti, backlink, analytics, form, integrazioni e abitudini degli utenti.

Prima di sostituirlo dobbiamo capire cosa conservare.

Una pagina vecchia può sembrare inutile e ricevere ancora traffico da Google. Un URL può avere link da altri siti. Un modulo poco elegante può essere collegato al gestionale interno.

Cancellare tutto e ripartire è veloce solo fino al giorno del lancio.

Dopo può diventare molto costoso.

Nel nostro approfondimento su quando conviene rifare un sito web entriamo proprio in questa differenza: aggiornamento, restyling e rifacimento completo non sono la stessa cosa.

I test finali non sono tempo perso

Quando il sito sembra finito, non è ancora finito.

Va provato.

Form, link, menu, responsive, cookie banner, pagamenti, email, analytics, redirect, sitemap, metadata, immagini, errori 404.

Su un sito multilingua vanno verificati anche cambio lingua e corrispondenza fra le versioni.

Su un e-commerce si simula un ordine.

Su un booking si simula una prenotazione.

Su un sito con chiamate si prova il numero da telefono.

Saltare questa fase può far guadagnare due giorni e perdere le prime richieste dopo il lancio.

La data di consegna dovrebbe sempre contenere un piccolo margine per questo controllo, soprattutto quando il sito deve essere online prima di una campagna o di una stagione.

Il lancio non dovrebbe essere fissato il giorno prima della campagna

Se una campagna Ads parte lunedì, pubblicare il nuovo sito domenica sera è una pessima idea.

Anche quando tutto è stato testato in staging, dopo il passaggio possono emergere problemi con dominio, DNS, cache, email, tracking o servizi esterni.

Meglio avere qualche giorno per verificare.

Lo stesso vale per hotel e attività stagionali.

Se la stagione comincia a maggio, il sito non dovrebbe essere consegnato il 30 aprile. Deve avere il tempo di essere controllato, indicizzato, misurato e corretto prima che ogni giorno perso valga prenotazioni vere.

Per chi lavora in Sardegna questo calendario conta molto.

A Olbia e in Gallura una grossa parte delle attività lavora su mesi molto più intensi degli altri. Il progetto va quindi pianificato al contrario: si parte dalla data in cui deve essere stabile, non dalla data in cui si vuole cominciare.

Come andare online prima senza fare un sito peggiore

La strada corretta non è comprimere tutto.

È ridurre il perimetro.

Se il budget o il tempo sono limitati, possiamo scegliere una prima versione più piccola ma completa.

Per esempio:

• partire con italiano e inglese, aggiungendo le altre lingue dopo;
• lanciare cinque pagine forti invece di quindici vuote;
• collegare un booking esistente invece di costruirne uno nuovo;
• rimandare un'area riservata;
• pubblicare il catalogo senza e-commerce e attivare la vendita in una seconda fase;
• partire con il sito aziendale e aggiungere il cluster SEO dopo.

È il principio del prodotto minimo utile, non del prodotto incompleto.

Una pagina mancante si può aggiungere.

Un sito lanciato male deve essere corretto mentre le persone lo stanno già usando.

Un calendario realistico per un sito aziendale

Un esempio semplice può essere questo.

Settimana 1 — obiettivi e architettura.
Brief, analisi del sito precedente, sitemap, pagine e materiali.

Settimana 2 — contenuti e wireframe.
Testi principali, struttura delle pagine, priorità mobile.

Settimana 3 — design.
Home, pagine tipo, componenti, revisione e approvazione.

Settimane 4–5 — sviluppo.
Frontend, CMS, form, SEO tecnica, responsive.

Settimana 6 — contenuti, test e lancio.
Inserimento finale, analytics, redirect, controllo dispositivi e pubblicazione.

Non è una legge.

È un modo per rendere visibile cosa occupa il tempo.

Un sito più piccolo può comprimere alcune fasi. Un progetto con lingue, booking o molte integrazioni può allungarle.

La parte importante è che ogni fase abbia un risultato approvabile.

Cosa chiedere prima di accettare una data di consegna

Una promessa tipo «sito pronto in dieci giorni» non è automaticamente sbagliata.

Va capita.

Chiedi:

• cosa deve fornire il cliente?
• i testi sono inclusi?
• il design è originale o parte da un tema?
• quante revisioni sono previste?
• quando devono arrivare fotografie e materiali?
• chi gestisce le traduzioni?
• il tempo include test e pubblicazione?
• eventuali integrazioni sono già state verificate?
• cosa succede se manca un materiale?
• la data è di consegna o di effettiva messa online?

La stessa scadenza può descrivere due progetti molto diversi.

Tempo, costo e qualità sono collegati, ma non in modo lineare

Pagare di più non rende automaticamente un sito più veloce.

Aggiungere persone a un progetto non dimezza necessariamente il tempo, perché molte attività dipendono l'una dall'altra.

Non puoi sviluppare correttamente una pagina prima di sapere cosa deve contenere. Non puoi tradurre un testo che cambia ogni giorno. Non puoi testare un'integrazione che il fornitore esterno non ha ancora attivato.

Il modo più efficace per ridurre i tempi è togliere incertezza.

Brief chiaro.

Materiali disponibili.

Una persona che decide.

Revisioni ordinate.

Integrazioni definite.

È molto meno spettacolare di «lavoriamo 24 ore su 24», ma funziona meglio.

Un esempio concreto: cosa cambia fra un sito semplice e uno complesso

Prendiamo due aziende che dicono entrambe «mi serve un sito nuovo».

La prima è uno studio professionale. Ha cinque servizi, una persona che approva i contenuti, fotografie già pronte e nessuna integrazione oltre al form contatti. Le pagine sono home, studio, servizi, approfondimenti e contatti. In questo caso il lavoro è lineare: si definisce la struttura, si scrivono i testi, si approva il design e si sviluppa.

La seconda è una struttura ricettiva. Ha camere e appartamenti diversi, quattro lingue, booking engine, transfer, esperienze, newsletter, pixel pubblicitari, fotografie da selezionare e un vecchio sito con pagine che ricevono traffico da Google. Anche se il numero delle pagine visibili non è molto più alto, il progetto contiene molte più dipendenze.

Ogni lingua va controllata. Il booking va testato. Gli URL vecchi vanno mappati. Le conversioni vanno tracciate. La versione mobile va verificata nei punti in cui una persona apre una camera, controlla una tariffa e prenota.

Dire «sono entrambi siti da dieci pagine» non descrive il lavoro.

È lo stesso motivo per cui un preventivo serio non dovrebbe usare il numero di pagine come unica unità di misura.

Il tempo aumenta quando aumentano le decisioni che dipendono l'una dall'altra.

Cosa preparare prima del kickoff per guadagnare una settimana vera

Se vuoi accorciare i tempi senza tagliare qualità, la preparazione prima dell'avvio è il punto più efficace.

Puoi arrivare con una cartella semplice che contiene:

• logo e file del brand in formato utilizzabile;
• fotografie originali e diritti d'uso chiari;
• elenco aggiornato di servizi e prodotti;
• accessi a dominio, hosting e sito esistente;
• accesso a Search Console e Analytics, se esistono;
• contatti, orari, sedi e dati societari;
• lingue necessarie;
• elenco di software da collegare;
• una persona che approva il progetto.

Non serve scrivere tu il sito.

Serve evitare che il team scopra alla quarta settimana che il dominio è intestato a un ex fornitore o che il booking engine richiede credenziali che nessuno trova.

Anche il feedback può essere preparato.

Decidere in anticipo chi approva evita il classico giro in cui marketing, titolare, commerciale e amministrazione danno quattro risposte diverse alla stessa schermata.

Un'altra cosa utile è separare desideri e requisiti.

«Mi piacerebbe un'animazione nella hero» è un desiderio.

«Il gestionale deve ricevere ogni richiesta con il codice della sede» è un requisito.

Se i due livelli vengono mescolati, le priorità cambiano continuamente e il calendario diventa fragile.

Cosa succede se il progetto deve uscire prima della data ideale

Capita.

Un'apertura viene anticipata.

Una campagna deve partire.

Una fiera non si sposta.

In quel caso la soluzione migliore è costruire una prima release coerente.

Non una versione rotta del progetto completo.

Per esempio, si può pubblicare con le pagine commerciali principali e lasciare gli approfondimenti alla seconda fase. Si può partire con due lingue invece di quattro. Si può usare temporaneamente un booking engine già disponibile e rimandare un'integrazione più sofisticata.

Quello che non comprimerei sono test, sicurezza, responsive e migrazione degli URL importanti.

Sono proprio le parti invisibili che proteggono il lancio.

Una release più piccola può crescere.

Una release fragile crea lavoro mentre il sito è già davanti ai clienti.

Un ultimo criterio utile è distinguere tempo di lavoro e tempo di calendario.

Il team può aver bisogno di venti giornate effettive, ma il progetto può occupare sei settimane perché fra una fase e l'altra servono approvazioni, materiali e test. È normale. Il calendario non misura soltanto quante ore qualcuno passa davanti al computer: misura anche le dipendenze.

Per questo una data seria dovrebbe sempre dichiarare da cosa dipende. Se i testi arrivano entro una certa settimana, se il booking viene attivato, se le revisioni vengono chiuse nei tempi concordati.

Questa trasparenza evita una cosa molto comune: considerare «ritardo dell'agenzia» qualunque giorno in cui il progetto è fermo in attesa di un accesso o di una decisione.

Il modo più corretto di pianificare è quindi avere un calendario condiviso, con responsabilità visibili da entrambe le parti.

Cosa rallenta la realizzazione di un sito web? Brief incompleto, contenuti mancanti, approvazioni lente, integrazioni e cambi di perimetro. Per questo chiedere quanto dura la realizzazione di un sito web ha senso solo insieme a dimensione del progetto, materiali disponibili e numero di persone coinvolte nelle decisioni.

Quanto tempo serve davvero al tuo sito?

La risposta dipende meno dal numero di pagine di quanto sembri.

Dipende da quante decisioni devono essere prese, quanti contenuti vanno prodotti e quanti sistemi devono lavorare insieme.

Un sito piccolo e ben preparato può andare online rapidamente.

Un progetto apparentemente semplice può bloccarsi per settimane se ogni elemento arriva in ritardo.

Per questo, quando prepariamo un preventivo, tempi e costi vengono definiti insieme al perimetro. Non promettiamo una data prima di sapere cosa deve esserci dentro.

Se stai pianificando un sito per il 2027, puoi partire dalla guida su quanto costa un sito web e poi raccontarci il progetto. Con pagine, lingue, contenuti e integrazioni davanti, una data smette di essere una promessa e diventa un calendario.