Il mobile non è un formato. È il tuo sito.
Apri Google Analytics di qualsiasi sito, oggi: nella stragrande maggioranza dei casi, la maggior parte del traffico arriva da smartphone. Google indicizza i siti in modalità mobile-first ormai da anni — significa che quello che il motore di ricerca legge, valuta e posiziona è la versione mobile del tuo sito, non quella desktop.
Eppure, la maggior parte dei siti viene ancora progettata così: si disegna il desktop, si sviluppa il desktop, e poi — alla fine — si “sistema il mobile”. Le colonne diventano una colonna sola, i blocchi si impilano uno sotto l’altro, il menù si comprime in un hamburger generico. Fatto.
Il risultato? Una pagina lunga tre chilometri, dove l’utente scrolla, scrolla, scrolla, si perde e se ne va. E dove Google misura tempi di caricamento e metriche di interazione che penalizzano il posizionamento.
In questo articolo spieghiamo perché il responsive tradizionale non è più sufficiente, cosa controllare concretamente nella versione mobile di un sito, e come lavoriamo noi: riscrivendo la struttura per il mobile, con interazioni, gerarchie e ottimizzazioni pensate come quelle di un’app.
Responsive vs progettato per mobile: la differenza che nessuno ti spiega
Chiariamo subito i termini.
Un sito responsive adatta il layout alla dimensione dello schermo. Le colonne si restringono, gli elementi si riposizionano, i font si scalano. È lo standard minimo dal 2015 circa — se un sito oggi non è responsive, non è un sito.
Un sito progettato per mobile è un’altra cosa. Non si limita a ridisporre gli stessi elementi: ripensa la gerarchia dei contenuti, le interazioni e la navigazione in funzione di come le persone usano davvero uno smartphone. Con il pollice, in verticale, spesso di fretta, spesso con una connessione non perfetta.
La differenza è la stessa che passa tra tradurre un testo parola per parola e riscriverlo per un pubblico diverso. Il primo approccio è tecnicamente corretto. Il secondo funziona.
Il problema del “blocco sotto blocco”
Il responsive fatto in automatico — quello che generano i page builder e i temi preconfezionati — produce quasi sempre lo stesso risultato: ogni sezione del desktop diventa un blocco impilato verticalmente.
Tre colonne di servizi? Tre blocchi in fila. Una griglia di sei card? Sei card una sotto l’altra. Un confronto affiancato? Due tabelle in sequenza, dove il confronto — che era il punto — sparisce.
Su desktop l’utente abbraccia la pagina con lo sguardo. Su mobile vede una porzione di schermo alla volta: se per arrivare al contenuto che gli interessa deve attraversare dieci schermate di scroll, nella maggior parte dei casi non ci arriva. E ogni contenuto che l’utente non raggiunge è un contenuto che non esiste.
Cosa controllare nella versione mobile del tuo sito: la checklist
Prima di parlare di come lavoriamo noi, ecco i punti che chiunque può (e dovrebbe) verificare sul proprio sito. Prendi il tuo smartphone, apri il tuo sito e fatti queste domande.
1. Velocità: quanto ci mette a diventare usabile?
Non “a caricarsi” — a diventare usabile. Google misura i Core Web Vitals proprio su mobile: LCP (quanto ci mette il contenuto principale ad apparire), INP (quanto reattiva è la pagina quando l’utente interagisce), CLS (quanto “salta” il layout durante il caricamento).
Un test su PageSpeed Insights in modalità mobile dice tutto. Se il punteggio mobile è drasticamente più basso di quello desktop — e succede quasi sempre — il problema non è la connessione dell’utente: è il codice.
2. Navigazione: il menù è un elenco o un’interfaccia?
Il classico hamburger che si apre su una lista piatta di voci funziona per un sito con cinque pagine. Per tutto il resto, serve una navigazione strutturata: livelli annidati, categorie che si espandono, schermate dedicate per le sezioni principali. L’utente deve capire dove si trova e dove può andare — senza scrollare un elenco infinito.
3. Gerarchia dei contenuti: cosa vede l’utente nei primi due secondi?
La prima schermata mobile è il tuo biglietto da visita. Se è occupata da un’immagine decorativa gigante, un claim generico e metà di un pulsante, hai sprecato il momento di massima attenzione. Il messaggio chiave, la proposta di valore e l’azione principale devono stare above the fold — o subito sotto.
4. Tap target e leggibilità: si usa con un pollice?
Pulsanti troppo piccoli, link troppo vicini, testi sotto i 16px, form con dieci campi da compilare in verticale: sono tutti attriti che su desktop si notano poco e su mobile uccidono la conversione. Ogni elemento interattivo deve essere comodamente raggiungibile e toccabile con il pollice, senza zoom e senza errori.
5. Contenuti: sono ripensati o solo impilati?
Le tabelle di confronto sono ancora confrontabili? Le gallerie si sfogliano o si scrollano all’infinito? I testi lunghi sono organizzati o sono un muro? Se la risposta è “impilati”, il sito è responsive ma non è progettato per mobile.
6. Interazioni: la pagina risponde come un’app o come un documento?
Quando l’utente tocca, si aspetta una risposta immediata: un accordion che si apre, una modal che appare, un toggle che cambia stato. Se ogni azione richiede un caricamento di pagina o — peggio — non dà nessun feedback, l’esperienza percepita è quella di un sito vecchio. Anche se il design è nuovo.
Come progettiamo noi la versione mobile: HTML riscritto, non riadattato
Ed eccoci al punto. Quando sviluppiamo un sito — sempre con tema WordPress custom, mai con page builder — la versione mobile non è un output automatico del responsive. È una progettazione a sé, che parte da Figma con layout dedicati e arriva a un HTML che, dove serve, è strutturalmente diverso da quello desktop.
Non è un dettaglio tecnico. È la differenza tra adattare e progettare.
Contenuti che si aprono, non che si impilano
Dove il desktop mostra tutto in griglia, il mobile lavora per progressive disclosure: mostra l’essenziale e lascia che sia l’utente ad approfondire.
- Accordion per contenuti lunghi e strutturati: l’utente vede i titoli, apre solo ciò che gli interessa, la pagina resta corta e leggibile.
- Toggle e tab per contenuti alternativi: invece di due sezioni in sequenza, una sola area che cambia al tocco.
- Modal e overlay per approfondimenti, form e dettagli: il contenuto appare sopra la pagina quando serve, senza costringere a navigare avanti e indietro.
Il risultato è una pagina mobile che non è una colonna infinita di blocchi, ma un’interfaccia densa e navigabile — dove ogni schermata ha un senso compiuto.
Menù che diventano navigazione, non elenchi
Sui nostri progetti il menù mobile è un componente progettato: livelli annidati che si aprono in schermate strutturate, sezioni con gerarchie visive chiare, accessi rapidi alle azioni principali. L’utente non scorre una lista — attraversa un’architettura. Come farebbe in un’app.
Ottimizzazioni in stile app
Progettare il mobile come un’app significa anche curare tutto quello che non si vede:
- Asset dedicati: immagini servite nel formato e nella dimensione giusta per lo schermo, non le stesse del desktop ridimensionate dal browser.
- Codice condizionale: script e stili che servono solo su desktop non vengono caricati su mobile — e viceversa.
- Transizioni e feedback: animazioni leggere che confermano ogni interazione, per un’esperienza fluida e “nativa”.
- Priorità di caricamento: prima il contenuto che l’utente vede, poi tutto il resto.
Tutto questo è possibile per un motivo preciso: il codice è nostro. Scriviamo l’HTML, il CSS e il JavaScript da zero, quindi possiamo decidere che una sezione su mobile abbia una struttura diversa, un comportamento diverso, un peso diverso. Con un page builder, questo livello di controllo semplicemente non esiste: il markup lo genera il tool, uguale per tutti, su tutti i dispositivi.
Il confronto in sintesi
| Responsive automatico | Mobile progettato (il nostro approccio) | |
|---|---|---|
| Layout | Blocchi desktop impilati in colonna | HTML riscritto e strutturato per mobile |
| Navigazione | Hamburger con lista piatta | Menù annidati con schermate strutturate |
| Contenuti lunghi | Scroll infinito | Accordion, tab, toggle, modal |
| Interazioni | Assenti o ereditate dal desktop | Feedback immediati, in stile app |
| Peso della pagina | Stesso codice del desktop | Asset e script dedicati, caricamento prioritario |
| Core Web Vitals | Spesso penalizzati su mobile | Ottimizzati dove Google misura davvero |
| Esperienza percepita | “Il sito visto da telefono” | Un prodotto pensato per il telefono |
Perché tutto questo conta anche per la SEO
Vale la pena ripeterlo: Google valuta la versione mobile del tuo sito. Non è un’opinione, è il funzionamento dichiarato dell’indicizzazione mobile-first.
Questo significa che ogni scelta di design mobile è anche una scelta SEO:
- Una pagina mobile leggera migliora i Core Web Vitals, che sono un fattore di ranking.
- Una navigazione chiara riduce la frequenza di rimbalzo e aumenta le pagine per sessione — segnali di qualità che Google legge.
- Contenuti organizzati in accordion e tab restano perfettamente indicizzabili (Google legge il contenuto anche se è chiuso di default), ma diventano fruibili per le persone. E i contenuti che le persone usano sono quelli che convertono.
Un sito che su mobile è solo “una versione compressa del desktop” paga due volte: in posizionamento e in conversioni. E di solito nessuno se ne accorge, perché il sito “visto dal computer dell’ufficio” sembra perfetto.
Conclusione
La versione mobile non è un adattamento: è il modo in cui la maggior parte delle persone — e Google — vede il tuo sito. Trattarla come un output automatico del responsive significa consegnare a utenti e motori di ricerca la versione peggiore del tuo lavoro.
Noi la trattiamo come un progetto: layout dedicati in fase di design, HTML riscritto dove serve, interazioni e ottimizzazioni pensate come quelle di un’app. Perché un sito che funziona davvero è un sito che funziona lì dove viene usato.
Vuoi capire come si comporta il tuo sito su mobile — sul serio, non a occhio? Facciamo volentieri un’analisi insieme. Senza impegno, con la chiarezza che ci piace avere con chiunque voglia capire davvero come funziona questo mestiere.
