Tutto cio che facciamo per costruire siti marketing e prodotti veloci, misurabili, SEO-ready e accessibili, scritto per intero. Come definiamo il perimetro, come scegliamo lo stack, come applichiamo i budget di performance, come l'analytics viene integrata dal primo giorno e come si svolge l'incarico dall'audit al lancio. Nessun contenuto di riempimento, nessun segreto trattenuto.
Questa guida e lunga perche le decisioni che determinano se un sito performa, si posiziona e converte vengono prese presto, prima che venga scritto qualsiasi codice. La maggior parte di queste decisioni e anche invisibile a chi paga per il progetto, ed e cosi che ci si ritrova con un sito bellissimo che ottiene 38 su Lighthouse e non ha nessun tracking analytics su cosa succede dopo che qualcuno clicca la CTA dell'hero. Quello che segue e come ragioniamo su ciascuna di queste decisioni, nell'ordine in cui le prendiamo.
Definire il perimetro e un esercizio diagnostico, non commerciale. Il risultato di un buon processo di scoping e un documento abbastanza preciso da non lasciare dubbi su cosa e incluso e cosa non lo e, e abbastanza chiaro da far sapere a chi paga esattamente cosa avra alla fine di ogni sprint. Qualsiasi cosa vaga in un perimetro e una futura disputa in attesa di manifestarsi.
Definiamo il perimetro in tre passaggi. Il primo passaggio e l'audit tecnico gratuito: cosa esiste adesso, cosa non va e quali sono i vincoli. Il secondo passaggio e un brief scritto che copre i deliverable, i criteri di accettazione per ciascuno, i budget di performance target, gli eventi analytics che tracceremo e i criteri di lancio. Il terzo passaggio e il piano degli sprint: il lavoro suddiviso in finestre di due settimane, ognuna delle quali si conclude con qualcosa che puoi testare e approvare.
La stima segue naturalmente dal brief. Se il brief e preciso, la stima e precisa. Se non lo e, non facciamo supposizioni; facciamo le domande che lo rendono preciso prima che cambi denaro di mano. E cosi si evita il classico schema in cui un progetto a prezzo fisso si trasforma in una serie di ordini di modifica perche il perimetro originale era un paragrafo di copy commerciale.
Cosa contiene un documento di perimetro. Deliverable per tipo di pagina e componente, criteri di accettazione per ciascun deliverable, budget di performance (obiettivi LCP, CLS, INP), eventi analytics e destinazioni, integrazioni di terze parti, supporto browser e dispositivo, standard di accessibilita (WCAG 2.1 AA per impostazione predefinita), ambiente di deployment e documentazione di handover. Se non e nel perimetro, non e nel prezzo.
Le stime sono in intervalli di tempo, non in numeri singoli. Forniamo un caso migliore e un caso realistico, spieghiamo cosa determina la differenza e costruiamo il piano degli sprint dal caso realistico. Gonfiare un progetto con buffer artificiali non e onesto; dire che un progetto da cinque settimane richiedera tre non e utile.
Ogni incarico inizia con un audit tecnico di cio che hai gia, perche la cosa piu costosa nello sviluppo web e costruire nella direzione sbagliata. L'audit risponde a due domande prima che venga scritto qualsiasi perimetro: cosa c'e effettivamente di sbagliato nel sito o progetto attuale, e quanto varrebbe correggerlo?
L'audit copre cinque livelli:
Il risultato e un report scritto con ogni problema categorizzato per impatto (critico, alto, medio, basso), l'URL o il componente specifico in cui si verifica e la correzione. Lo esaminiamo in una breve chiamata e tieni il report indipendentemente da come procedi.
La scelta dello stack e un esercizio di corrispondenza con i vincoli. Lo stack giusto e quello che si adatta al modello di contenuto, alle competenze del team, ai requisiti di performance e alla traiettoria di crescita. Non e il framework piu nuovo, non quello che piace di piu al lead developer e non quello che produce la demo piu impressionante.
La decisione principale riguarda se il sito e statico, server-rendered o una full client-side application e se e coinvolto un CMS. Ecco la panoramica pratica:
| Approccio | Ideale per | Trade-off |
|---|---|---|
| Sito statico (HTML, CSS, JS minimale) | Landing page, siti marketing a bassa variazione, documentazione | Caricamento piu veloce possibile, hosting semplicissimo; non adatto a contenuti dinamici o funzionalita autenticate |
| Static site generator (Eleventy, Hugo, Astro) | Siti ricchi di contenuti con aggiornamenti poco frequenti, blog, knowledge hub | Ottima baseline di performance, si abbina bene a un headless CMS; il build time cresce con il volume di contenuti |
| Framework server-rendered (Next.js, Nuxt, SvelteKit) | Siti marketing con personalizzazione, pagine di prodotto, e-commerce | SEO solida per impostazione predefinita, strategie di rendering flessibili; piu infrastruttura da gestire |
| Headless CMS con frontend | Siti in cui i team non tecnici pubblicano contenuti di frequente | Migliore separazione delle responsabilita; aggiunge una dipendenza e un costo mensile per la piattaforma CMS |
| Prodotto completo (SPA o app server-rendered) | Funzionalita di prodotto autenticate, dashboard, strumenti con stato | Massima flessibilita; maggiore complessita, build piu lungo, richiede un trattamento SEO attento per le pagine pubbliche |
La scelta tra un static site generator e un framework server-rendered e quella su cui i team sbagliano piu spesso. Se il sito e principalmente contenuto marketing con aggiornamenti poco frequenti e senza personalizzazione, un generatore statico superera sempre un framework server-rendered e costera molto meno da ospitare e mantenere. Consigliamo un framework quando il contenuto e dinamico, il team necessita di rendering per utente o il sito deve crescere verso funzionalita di prodotto nel tempo.
Facciamo questa raccomandazione per iscritto come parte del perimetro, con il ragionamento e i trade-off, cosi la decisione e esplicita e documentata. Non promuoviamo uno stack particolare perche e quello che conosciamo meglio; promuoviamo quello che si adatta al problema.
Un budget di performance e un insieme di vincoli concordati per iscritto prima che venga committata la prima riga di codice. Senza uno, le prestazioni vengono sempre sacrificate a favore delle funzionalita perche il costo di aggiungere uno script di terze parti o un'immagine non ottimizzata e invisibile finche qualcuno non esegue Lighthouse e trova un punteggio di 42.
Lavoriamo con tre soglie Core Web Vitals di Google:
fetchpriority="high". Correggere l'immagine hero da sola sposta la maggior parte dei siti dal fallimento al superamento di LCP.Applicazione del budget di performance. Impostiamo le soglie Lighthouse CI nella pipeline di deployment cosi qualsiasi commit che peggiora un punteggio Core Web Vitals blocca il deploy finche non viene corretto. Questo previene il degrado lento che trasforma un sito veloce in uno lento nel corso di dodici mesi di aggiunte di funzionalita.
Oltre ai tre Core Web Vitals, definiamo un budget per il peso totale della pagina, la dimensione del bundle JavaScript, il numero di risorse render-blocking e il numero di script di terze parti consentiti nelle pagine critiche per le performance. Ognuno e scritto nel perimetro cosi tutti quelli che lavorano al progetto conoscono il vincolo prima di proporre qualcosa che lo violerebbe.
Gli script di terze parti meritano attenzione speciale. Analytics, widget di chat, strumenti di A/B testing e pixel marketing sono individualmente piccoli; collettivamente aggiungono regolarmente da due a quattro secondi al tempo di caricamento e introducono layout shift. Usiamo un pattern a facciata per gli strumenti non critici: carichiamo un segnaposto leggero che carica lo script completo solo quando l'utente interagisce con esso. Il widget di chat si carica quando l'utente clicca il pulsante della chat, non al caricamento della pagina.
Un build SEO-ready non e una checklist da applicare alla fine. E un insieme di decisioni strutturali prese prima che venga scritto qualsiasi contenuto. L'errore piu grande che i team commettono e costruire un sito, lanciarlo e poi chiedere a un consulente SEO di risolvere i problemi, a quel punto correggerli significa rielaborare l'architettura sottostante piuttosto che aggiungere un meta tag.
Ogni pagina necessita di un singolo H1, una gerarchia di heading logica (H2 per le sezioni, H3 per le sottosezioni), elementi landmark per navigazione, contenuto principale e footer, e testo alternativo descrittivo su ogni immagine. Queste sono le cose da cui dipendono sia Googlebot che gli screen reader per comprendere la pagina, e non costano nulla fare bene la prima volta.
Googlebot e in grado di eseguire il rendering di JavaScript, ma lo fa in una seconda ondata che puo richiedere giorni per le pagine non ancora autorevoli. Per le pagine pubbliche che devono posizionarsi, il server-side rendering o la generazione statica sono piu sicuri di una pura applicazione client-side. Se il tuo prodotto e una single-page application, le pagine marketing e le landing page dovrebbero essere renderizzate staticamente anche se il prodotto autenticato non lo e.
Includiamo dati strutturati su ogni tipo di pagina dal primo giorno, usando i tipi che corrispondono al contenuto. Il rollout segue una mappa standard:
| Tipo di schema | Dove va | Cosa sblocca |
|---|---|---|
| Organization | In tutto il sito (di solito nel footer o nell'head) | Pannello di conoscenza del brand, logo nei risultati di ricerca |
| BreadcrumbList | Ogni pagina con una gerarchia di navigazione | Percorso breadcrumb nel risultato di ricerca |
| WebSite con SearchAction | Homepage | Sitelinks search box per query di brand |
| FAQPage | Pagine con una sezione FAQ autentica | Accordion FAQ espandibile nel risultato |
| Article | Post del blog e guide | Data di pubblicazione, autore e indicizzazione migliorata |
| Product | Pagine prodotto o pricing dove applicabile | Prezzo e disponibilita nel risultato |
| SoftwareApplication | Pagine di prodotto SaaS | Dati di valutazione e piattaforma nel risultato |
Ogni blocco di dati strutturati viene validato con il Rich Results Test di Google prima del lancio e monitorato in Search Console dopo. Schema non valido e peggio di nessuno schema: produce un avviso di azione manuale se Google lo trova fuorviante.
Ogni pagina necessita di un tag canonical auto-referenziale che punta al suo URL preferito. Se il sito ha versioni in piu lingue o locale, ogni pagina necessita di un set completo di annotazioni hreflang, incluso un hreflang auto-referenziale e un x-default. hreflang mancante o errato e uno degli errori piu comuni e costosi sui siti internazionali: Google spesso indicizza la versione nella lingua sbagliata per ogni mercato, il che divide i segnali di ranking e diluisce l'autorita tra le versioni.
I titoli restano sotto 60 caratteri. Le meta description restano sotto 155. Entrambe vengono scritte prima del lancio, non auto-generate dalla prima frase del testo. Sono la prima cosa che un ricercatore vede nel risultato e determinano se qualcuno clicca, indipendentemente dalla posizione di ranking.
L'accessibilita non e un esercizio di conformita. E uno standard di qualita del build. Un sito inaccessibile agli utenti da tastiera ha la navigazione rotta per gli utenti avanzati. Un sito con scarso contrasto cromatico fallisce alla luce del sole, non solo per gli utenti con disabilita visive. Un sito senza label ARIA appropriate e piu difficile da analizzare per Google, non solo per gli utenti di screen reader.
Lavoriamo con WCAG 2.1 AA su ogni build. Le pratiche che contano di piu in un tipico sito marketing o prodotto digitale:
I test automatici intercettano circa il 30-40% delle violazioni WCAG. Il resto richiede test manuali. Eseguiamo scansioni automatiche a ogni commit usando axe-core e facciamo un controllo manuale da tastiera e screen reader su ogni tipo di pagina prima del lancio.
L'analytics e quasi sempre un ripensamento nei progetti web. Il sito viene lanciato, qualcuno aggiunge Google Analytics tramite un plugin CMS e tre mesi dopo l'azienda non ha idea di cosa stia davvero guidando le conversioni perche gli eventi non sono mai stati configurati per rispondere alle domande che contano.
Configuriamo l'analytics prima che il primo sprint finisca, con gli eventi mappati sulle domande di business, non su cio che e facile tracciare. La configurazione segue un brief scritto durante il perimetro:
Su misurazione e privacy. Implementiamo l'analytics in conformita con i requisiti GDPR e ePrivacy: gestione del consenso prima che si attivi qualsiasi tracking, IP anonimizzato per impostazione predefinita, impostazioni di conservazione dei dati riviste al lancio e nessuna informazione personale identificabile nei parametri degli eventi. Fare questo bene fin dall'inizio e molto piu economico che adattare un livello di consenso conforme su un sito che ha tracciato tutto per dodici mesi.
Dopo il lancio, eseguiamo un QA pass del tracking: ogni evento si attiva sul trigger corretto, nessun evento duplicato, nessun evento mancante e i dati nella piattaforma analytics corrispondono al comportamento atteso degli utenti. Richiede mezza giornata e previene mesi di lavoro basato su dati errati.
Un sistema di componenti e la differenza tra un sito che resta coerente mentre cresce e uno che sviluppa dodici stili di pulsante leggermente diversi su diciassette pagine perche ognuna e stata costruita indipendentemente. E anche la differenza tra un sito in cui un team non tecnico puo pubblicare nuovi contenuti in sicurezza e uno in cui ogni nuova pagina richiede a un ingegnere di copiare e incollare il markup sperando di non rompere nulla.
Costruiamo ogni sito con una libreria di componenti documentata. Il perimetro copre quali componenti sono necessari e quante varianti ciascuno richiede. L'implementazione copre tre aspetti:
Per i siti marketing, costruiamo il sistema di componenti in qualsiasi framework specificato nel perimetro, o in plain HTML e CSS per i siti statici. Per i prodotti digitali, adottiamo per impostazione predefinita un pattern di componenti headless dove lo strato visivo e separato dalla logica di business, cosi il design system puo essere aggiornato senza toccare il codice applicativo.
La scelta del CMS e una decisione di flusso di lavoro, non tecnologica. Il CMS giusto e quello che permette alle persone che aggiorneranno effettivamente il sito di farlo senza aprire un ticket, rompere il layout o dover capire il codebase.
Le principali opzioni con cui lavoriamo e quando consigliamo ciascuna:
Le migrazioni CMS meritano attenzione separata. Spostare contenuti da una piattaforma a un'altra e quasi sempre piu complicato di quanto sembri: redirect per gli URL che cambiano, contenuti che non si mappano bene nel nuovo schema, immagini da ricaricare e metadati SEO da preservare. Pianifichiamo le migrazioni nel perimetro, costruiamo gli script di import prima di toccare il sito live e verifichiamo ogni redirect prima del giorno del lancio.
Un sito marketing o prodotto moderno tipicamente si connette a cinque-quindici servizi esterni al lancio: analytics, CRM, email marketing, assistenza clienti, elaborazione pagamenti, gestione form e cio di cui il prodotto stesso ha bisogno. Ogni integrazione e un potenziale punto di fallimento, un rischio per le performance e una superficie di privacy. Le trattiamo con lo stesso rigore del codice applicativo.
La checklist di integrazione che eseguiamo prima di aggiungere qualsiasi servizio di terze parti:
La gestione dei form e un'area comune in cui le cose vanno storte. Utilizziamo un handler lato server o un servizio di form (Formsubmit, Netlify Forms o una funzione serverless) piuttosto che esporre un indirizzo email o una chiave API di email transazionale nel client. I campi honeypot, il rate limiting e reCAPTCHA sono standard; la scelta tra di loro dipende dal volume di invii e dalla sensibilita dei dati.
Per i prodotti digitali con la propria API, scriviamo un contratto API prima che venga scritto qualsiasi codice frontend o backend. Il contratto copre endpoint, strutture di request e response, autenticazione, codici di errore e paginazione. Lo sviluppo frontend e backend puo poi procedere in parallelo rispetto al contratto concordato, piuttosto che in sequenza, il che e come si mantiene alta la velocita degli sprint in un prodotto digitale.
La sicurezza in un sito marketing o prodotto digitale non e glamour, ma le basi sono non negoziabili. Gli errori che causano le violazioni sono quasi sempre quelli ovvi: segreti esposti nel codice client-side, nessuna Content Security Policy, dipendenze con vulnerabilita note e nessuna applicazione di HTTPS.
La checklist di sicurezza che eseguiamo prima del lancio su ogni incarico:
L'hosting e dove performance, affidabilita e sicurezza si uniscono. La scelta dell'hosting deve seguire dalla scelta dello stack: un sito statico non ha bisogno di un server; un'applicazione server-rendered si. Scegliere l'hosting sbagliato per lo stack porta a complessita e costi non necessari.
Per siti statici e siti costruiti con static site generator, adottiamo per impostazione predefinita un host CDN-first (Netlify, Vercel o Cloudflare Pages). Ogni pagina viene servita come file pre-costruito da una location edge vicina al visitatore, senza round-trip al server per l'HTML iniziale. I tempi di caricamento che richiederebbero due-tre secondi da un server single-region scendono sotto il mezzo secondo da un CDN edge. La differenza di costo tra un host CDN e un server e spesso zero per i volumi di traffico delle startup e scaleup.
Per applicazioni server-rendered e prodotti digitali, valutiamo i requisiti infrastrutturali rispetto al traffico previsto e al budget. Un prodotto piccolo con poche migliaia di utenti al mese non ha bisogno di un cluster Kubernetes; ha bisogno di un VPS ben configurato o di una piattaforma gestita come Railway o Render con impostazioni di autoscaling ragionevoli.
Ogni pipeline di deployment che configuriamo include ambienti di anteprima: deployment isolati e pubblicamente accessibili di ogni pull request o branch, con un URL unico generato automaticamente. Gli ambienti di anteprima permettono all'intero team (designer, redattori, QA, fondatori) di rivedere e approvare le modifiche prima che vengano unite al main. Permettono anche di individuare le regressioni prima che raggiungano il sito live, perche l'anteprima esegue lo stesso build di produzione.
La pipeline di deployment viene eseguita a ogni commit al branch main: build, lint, unit test, controllo Lighthouse CI rispetto ai budget di performance e deployment. Se un passaggio fallisce, il deployment e bloccato. Non e opzionale; e come si previene l'accumulo lento di debito tecnico che trasforma un sito performante in uno lento.
Il build che viene consegnato al lancio non e quello che gira tra due anni. Scalare un sito o prodotto riguarda principalmente le decisioni prese presto: un sistema di componenti che rende facile aggiungere pagine in modo coerente, un CMS che consente ai team non tecnici di pubblicare senza supporto ingegneristico, una lista di dipendenze che non cresce senza governance e un codebase che i nuovi ingegneri possono navigare senza un orientamento di tre giorni.
Le pratiche che influenzano maggiormente la manutenibilita nel lungo periodo:
Il vero costo del debito tecnico in un progetto web non e il codice che deve essere sostituito. E il tempo speso a lavorare attorno a codice che nessuno capisce ma tutti hanno paura di toccare. Il momento migliore per prevenirlo e durante il build iniziale. Il secondo momento migliore e uno sprint dedicato al debito tecnico, che possiamo definire separatamente se il codebase lo ha gia accumulato.
Ogni incarico segue la stessa struttura: audit, perimetro, build in sprint, lancio e handover. La struttura e la stessa che costruiamo una landing page o un prodotto completo; le dimensioni di ogni fase si adattano al perimetro.
Le fasi in ordine:
Poiche gestiamo lavoro di crescita e SEO per le stesse aziende per cui costruiamo, l'handover puo transitare in un incarico continuativo o restare come progetto una tantum. Entrambe le opzioni vanno bene. Il sito che costruiamo e tuo, il codice e tuo e la documentazione e scritta in modo che tu possa gestirlo autonomamente.
Quanto dura un progetto tipico? Una landing page richiede tipicamente da quattro a sei settimane dal sign-off del perimetro al lancio, inclusi contenuti, QA e deployment. Un sito marketing completo richiede da otto a dodici settimane. Un prodotto digitale dipende dal perimetro ma lo strutturiamo in sprint fissi di due settimane cosi vedi software funzionante alla fine di ciascuno.
Lavorate con lo stack esistente? Si, se l'audit ci dice che lo stack attuale e solido. Consigliamo un cambio solo quando quello attuale e un vero vincolo a cio che devi fare, e spieghiamo il ragionamento prima che qualsiasi lavoro inizi.
Quanto costa? L'audit e gratuito. Il progetto viene definito dopo l'audit perche il perimetro giusto dipende da cio che troviamo e da cio che vuoi realizzare. Scriviamo il perimetro e il prezzo nell'accordo prima che qualsiasi lavoro inizi.
Potete occuparvi anche di SEO e crescita dopo il progetto? Si. Gestiamo SEO, contenuti e link building per le stesse aziende per cui costruiamo siti. Il build che consegniamo e gia SEO-ready; il lavoro di crescita si costruisce sopra di esso. Non c'e alcun passaggio a un'altra agenzia.
Cosa succede se abbiamo bisogno di modifiche dopo che il perimetro e stato definito? Le modifiche fuori dal perimetro concordato vengono definite come voce separata con un prezzo separato, prima che qualsiasi lavoro su di esse inizi. Non assorbiamo modifiche fuori perimetro in silenzio per poi fatturarle alla fine.
Questo e il metodo completo. Quando vuoi applicarlo al tuo sito o al tuo prossimo progetto, il passo successivo e un audit gratuito: risultati reali sui tuoi dati Lighthouse e di campo reali, in circa una settimana, senza alcun impegno.
Un audit tecnico gratuito del tuo sito o progetto. Risultati reali sui tuoi dati Lighthouse e di campo reali. Un perimetro fisso per sistemare cio che conta. Risultati in una settimana.
Richiedi un audit gratuito