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 o di una fiera, o semplicemente prima che il vecchio sito continui a perdere richieste.

Anche qui, però, 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 quelli di un e-commerce, un sito nuovo non ha quelli di un restyling con cento URL già indicizzati. E un prodotto digitale con account, dashboard e pagamenti non è più soltanto un sito.

Più che quanto ci vuole, conviene quindi chiedersi quali passaggi vanno completati prima di poter andare online bene. È da lì che nasce un calendario credibile.

Quanto tempo ci vuole per fare un sito web: le fasce

Per un sito aziendale ben definito il tempo si misura in settimane, non in giorni, perché il processo passa da obiettivi, struttura, contenuti, design, sviluppo, revisioni e test prima della pubblicazione. Come ordine di grandezza, senza trasformarlo in un listino:

Sono fasce per orientarsi, non tempi garantiti. Un progetto può essere più rapido se materiali e decisioni sono pronti, e allungarsi molto se contenuti, fotografie, traduzioni o integrazioni vengono scoperti strada facendo. Nella guida su quanto costa un sito web nel 2027 spieghiamo perché il prezzo dipende dal perimetro; per il tempo vale la stessa regola, perché più cose il sito deve fare, più decisioni vanno prese e testate.

Prendiamo due aziende che dicono entrambe «mi serve un sito nuovo». La prima è uno studio professionale con 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. Qui il lavoro è lineare: si definisce la struttura, si scrivono i testi, si approva il design e si sviluppa.

La seconda è una struttura ricettiva con 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. Le pagine visibili non sono molte di più, ma ogni lingua va controllata, il booking testato, gli URL vecchi mappati, le conversioni tracciate e la versione mobile verificata dove una persona apre una camera, controlla una tariffa e prenota. Dire «sono entrambi siti da dieci pagine» non descrive il lavoro: il tempo cresce con le decisioni che dipendono l'una dall'altra.

La prima settimana spesso non contiene codice

È una delle cose che sorprendono 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 sembra lenta perché non produce ancora una home da mostrare, ma è 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, e 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?
• la campagna deve atterrare sulla home o su una landing dedicata?

Sono decisioni di architettura, non dettagli. Per questo nella nostra realizzazione di siti web il processo parte da obiettivi e struttura, non dal colore del bottone.

Contenuti pronti: il modo più semplice per guadagnare tempo

Se ci chiedi cosa rallenta la realizzazione di un sito web, la risposta raramente è il codice. 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 di una pagina è pronto ma manca il contenuto principale, si mette un testo provvisorio di tre righe, due settimane dopo arriva quello reale che ne occupa dodici, e la pagina va riprogettata. Oppure arriva una foto verticale dove il layout prevedeva un orizzontale, o si scopre che un servizio che sembrava secondario richiede metà del sito.

I contenuti, quindi, non sono qualcosa da «mettere dentro» alla fine: fanno parte del progetto. Non serve scrivere tu il sito né arrivare con tutto perfetto, ma sapere cosa esiste, cosa manca e chi deve produrlo. Prima dell'avvio aiuta avere una cartella con:

• elenco aggiornato di servizi e prodotti, con eventuali listini o cataloghi;
• messaggi principali;
• logo e file del brand in formato utilizzabile;
• fotografie originali, con diritti d'uso chiari;
• contatti, orari, sedi e dati societari;
• lingue necessarie;
• accessi a dominio, hosting, sito esistente, Search Console e Analytics;
• elenco dei software da collegare;
• il nome della persona che approva il progetto.

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

Nel progetto Wonder Creators i quattro servizi sono diventati quattro capitoli numerati. Quella scelta non nasce dal codice ma dal decidere prima come una persona deve capire l'offerta, e una volta presa, design e sviluppo diventano più veloci perché non devono più indovinare la struttura.

Il design non va compresso fino a sparire

«Facciamo subito il sito e poi sistemiamo la grafica» sembra un modo per guadagnare tempo, e 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 si verificano prima che diventino componenti. Spostare un blocco in un progetto grafico è molto più semplice che ricostruire una sezione già collegata a dati, animazioni e responsive.

Questo non significa che ogni sito richieda settimane di prototipi: la quantità di design va proporzionata al progetto. Una landing si approva rapidamente, un sito con molte pagine e componenti diversi richiede un sistema più ampio, un'app richiede anche stati, errori, conferme e flussi che su una semplice home non esistono. Ridurre questa fase ha senso solo se il progetto è davvero semplice.

Feedback e revisioni: dove si perdono le settimane

Detto da chi costruisce siti può sembrare comodo, ma è concreto: il cliente può accelerare il progetto più dell'agenzia. 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. Il caso 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, e nessuno sa quale indicazione sia quella definitiva.

Decidere in anticipo chi approva evita il classico giro in cui marketing, titolare, commerciale e amministrazione danno quattro risposte diverse alla stessa schermata. In pratica funziona un processo semplice:

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.

Le revisioni in sé non sono il problema. Il primo design non è sacro, e devi poter correggere ciò che non rappresenta l'azienda; il problema nasce quando ogni revisione riapre tutte le decisioni precedenti. Se in fase di sviluppo si cambia completamente la struttura approvata, non si sta più correggendo il sito: si torna all'architettura. Lo stesso vale per i testi: 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 contiene, oltre alle ore di lavoro, momenti di decisione.

Aiuta anche 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 si mescolano, le priorità cambiano di continuo e il calendario diventa fragile.

Il mobile non è la versione piccola del desktop

Su molti progetti il lavoro mobile viene ancora immaginato come l'ultima rifinitura: si costruisce il desktop, poi lo si «adatta». Per siti semplici può funzionare; per progetti con navigazioni, interazioni, tabelle, moduli, prenotazioni o contenuti lunghi rischia di creare un secondo progetto dentro il primo. Sul telefono cambiano spazio, gesto, priorità e contesto: un numero di telefono deve essere toccabile, una call to action raggiungibile con un pollice, una tabella leggibile a 1440 pixel può diventare illeggibile a 375, e un menu da dodici voci è un problema completamente diverso.

Per Wonder Creators il telefono era particolarmente importante perché l'azienda vende contenuti social, e il pubblico incontra quel tipo di lavoro proprio su uno schermo verticale. Per CDA Servizi Auto 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.

Lingue e integrazioni: dove il calendario si allunga

Aggiungere una lingua non significa duplicare una pagina e premere «traduci». Ogni versione deve avere URL, metadata, navigazione, testi e collegamenti coerenti, e poi va rivista: chi controlla l'inglese, chi approva il tedesco, se le offerte sono identiche in tutti i mercati, se i clienti usano le stesse parole. Un progetto in due lingue non dura il doppio, perché design e sviluppo si riutilizzano, ma il lavoro editoriale cresce in modo significativo, anche su immagini con testo incorporato, PDF, email automatiche, form e messaggi di conferma. Ne abbiamo scritto per esteso in come progettare un sito in più lingue.

Con booking, pagamenti e gestionali il calendario cambia ancora. Una pagina «Camere» si sviluppa rapidamente; un sistema di prenotazione richiede di sapere da dove arrivano le disponibilità, come si sincronizzano, cosa succede dopo l'invio, chi riceve la conferma, se c'è un pagamento, quali email partono e come si gestiscono cancellazioni e modifiche. A volte il sito deve solo collegarsi a un booking engine esistente, a volte dialogare con un gestionale, a volte il sistema va costruito. In un brief sono tre casi che si scrivono allo stesso modo, «serve la prenotazione online», e 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

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, e prima di sostituirlo bisogna 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. Nella guida su quando rifare un sito web distinguiamo aggiornamento, restyling e rifacimento completo, che non sono la stessa cosa e non hanno gli stessi tempi.

Test e lancio: mai il giorno prima della campagna

Quando il sito sembra finito, va ancora provato: form, link, menu, responsive, cookie banner, pagamenti, email, analytics, redirect, sitemap, metadata, immagini ed errori 404. Su un sito multilingua si verificano il cambio lingua e la corrispondenza fra le versioni, su un e-commerce si simula un ordine, su un booking una prenotazione, su un sito che vive di chiamate si prova il numero da telefono. Saltare questa fase fa guadagnare due giorni e può far perdere le prime richieste dopo il lancio.

Anche la data di pubblicazione va scelta con margine. Se una campagna Ads parte lunedì, pubblicare il nuovo sito domenica sera è una pessima idea: anche con tutto testato in staging, dopo il passaggio possono emergere problemi con dominio, DNS, cache, email, tracking o servizi esterni. 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 pochi mesi molto più intensi degli altri, quindi il progetto va pianificato al contrario: si parte dalla data in cui il sito deve essere stabile, non da quella in cui si vuole cominciare.

Un calendario realistico per un sito aziendale

Un esempio semplice, per rendere visibile cosa occupa il tempo in un sito aziendale:

1. Settimana 1: obiettivi e architettura. Brief, analisi del sito precedente, sitemap, pagine e materiali.
2. Settimana 2: contenuti e wireframe. Testi principali, struttura delle pagine, priorità mobile.
3. Settimana 3: design. Home, pagine tipo, componenti, revisione e approvazione.
4. Settimane 4–5: sviluppo. Frontend, CMS, form, SEO tecnica, responsive.
5. Settimana 6: contenuti, test e lancio. Inserimento finale, analytics, redirect, controllo sui dispositivi e pubblicazione.

Non è una legge. Un sito più piccolo può comprimere alcune fasi, un progetto con lingue, booking o molte integrazioni può allungarle; la cosa importante è che ogni fase abbia un risultato approvabile.

Quando si chiede quanto dura la realizzazione di un sito web, conviene anche distinguere il tempo di lavoro dal tempo di calendario. Il team può aver bisogno di venti giornate effettive, ma il progetto occupa sei settimane perché fra una fase e l'altra servono approvazioni, materiali e test. È normale: il calendario misura le dipendenze, non solo le ore davanti al computer. Per lo stesso motivo pagare di più o aggiungere persone non dimezza i tempi: non puoi sviluppare una pagina prima di sapere cosa deve contenere, tradurre un testo che cambia ogni giorno o testare un'integrazione che il fornitore esterno non ha ancora attivato.

Il modo più efficace per ridurre i tempi è togliere incertezza: un brief chiaro, materiali disponibili, una persona che decide, revisioni ordinate, integrazioni definite. È meno spettacolare di «lavoriamo 24 ore su 24», ma funziona meglio. Anche la piattaforma scelta pesa meno di contenuti, decisioni e integrazioni; il confronto fra le opzioni è in WordPress o sito su misura.

Andare online prima senza fare un sito peggiore

Capita che un'apertura venga anticipata, che una campagna debba partire o che una fiera non si sposti. La strada corretta non è comprimere tutte le fasi ma ridurre il perimetro: costruire una prima release più piccola e completa, invece di una versione rotta del progetto intero. Per esempio si può:

• partire con italiano e inglese e aggiungere le altre lingue dopo;
• lanciare cinque pagine forti invece di quindici vuote;
• pubblicare le pagine commerciali principali e lasciare gli approfondimenti alla seconda fase;
• collegare un booking engine già disponibile invece di costruirne uno nuovo;
• rimandare un'area riservata;
• pubblicare il catalogo senza e-commerce e attivare la vendita in un secondo momento;
• partire con il sito aziendale e aggiungere il cluster SEO dopo.

Quello che non comprimeremmo sono test, sicurezza, responsive e migrazione degli URL importanti, cioè le parti invisibili che proteggono il lancio. È il principio del prodotto minimo utile, che è diverso dal prodotto incompleto: una pagina mancante si aggiunge, mentre un sito lanciato male va corretto quando le persone lo stanno già usando.

Cosa chiedere prima di accettare una data di consegna

Una promessa come «sito pronto in dieci giorni» non è automaticamente sbagliata, ma va capita. Prima di accettarla chiedi:

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

La stessa scadenza può descrivere due progetti molto diversi. Per questo una data seria dovrebbe dichiarare da cosa dipende: se i testi arrivano entro una certa settimana, se il booking viene attivato, se le revisioni si chiudono nei tempi concordati. È questa trasparenza a evitare che ogni giorno di progetto fermo, in attesa di un accesso o di una decisione, diventi «ritardo dell'agenzia». Funziona meglio un calendario condiviso, con le responsabilità visibili da entrambe le parti.

Quanto tempo serve davvero al tuo sito?

Dipende meno dal numero di pagine di quanto sembri, e più da quante decisioni vanno 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, definiamo tempi e costi insieme al perimetro, e non promettiamo una data prima di sapere cosa deve esserci dentro.

Se stai pianificando un sito per il 2027, raccontaci il progetto: con pagine, lingue, contenuti e integrazioni davanti, una data smette di essere una promessa e diventa un calendario.