Key Takeaways
| Punto chiave | Cosa devi sapere |
|---|---|
| Mobile-first indexing | Google indicizza la versione mobile del sito, non quella desktop |
| Velocità di caricamento | Sotto i 3 secondi è il minimo, sotto 2 è quello che vuoi davvero |
| Core Web Vitals | LCP, INP e CLS sono i tre numeri da tenere d’occhio ogni settimana |
| Design responsive | Un solo sito che si adatta a ogni schermo, niente versioni separate |
| Contenuti mobile | Paragrafi corti, frasi brevi, titoli scansionabili in 2 secondi |
| Strumenti gratis | PageSpeed Insights, Search Console e il test mobile-friendly bastano per partire |
| Errore più comune | Pop-up invadenti che coprono il contenuto su smartphone |
Cosa vuol dire davvero ottimizzare il sito per la ricerca mobile
Te lo dico subito senza giri di parole: ottimizzare il sito per la ricerca mobile vuol dire fare in modo che Google capisca, ami e premi la versione del tuo sito che si vede sullo smartphone. Non quella che vedi tu sul tuo MacBook da 16 pollici mentre lavori. Quella che vedono i tuoi clienti veri, mentre sono in metro o in fila al supermercato.
Quanti utenti arrivano dal mobile oggi? Su quasi tutti i progetti che seguiamo in Dominanza Digitale, siamo tra il 65% e l’82% di traffico da smartphone. Su alcuni e-commerce di moda arriviamo al 90%. Nel 2026 chi pensa ancora “il desktop è dove succedono le cose” sta guardando un mondo che non esiste più.
Ma cosa cambia tra un sito ottimizzato e uno che non lo è? Tre cose, secondo la mia esperienza:
- La velocità con cui carica la prima schermata (il famoso LCP)
- Il modo in cui i pulsanti rispondono al tocco (niente più caccia al link grande 8 pixel)
- La lettura senza zoom (se devo pinch-to-zoom, ho già perso)
Una piccola anedotto: l’anno scorso un cliente nel settore arredamento ci chiamò perché aveva perso il 40% di traffico organico in due mesi. Aprivamo il sito da iPhone, e il banner cookie copriva metà schermo per 8 secondi. Otto. Secondi. Abbiamo cambiato solo il modo in cui il banner appariva e il traffico è tornato in tre settimane.
L’ottimizzazione mobile non è una checklist da spuntare una volta sola, è una cosa che va guardata ogni mese almeno. Google cambia gli algoritmi, gli utenti cambiano abitudini, e il tuo sito deve seguire. Su questo blog parliamo spesso di come questi cambiamenti impattano i risultati reali dei nostri clienti.
Una domanda che mi fanno sempre: “Ma serve un sito separato per il mobile, tipo m.miosito.it?”. Risposta secca: no. Quella roba è del 2014, lasciamola lì. Oggi si fa tutto con un sito unico responsive, e ti spiego perché nei prossimi paragrafi.
Mobile-first indexing: come Google legge il tuo sito dallo smartphone
Dal 2019 Google ha ufficialmente cambiato modo di lavorare. Prima guardava il sito desktop, poi quello mobile. Adesso fa il contrario, e dal 2023 ha praticamente smesso di guardare il desktop per i siti nuovi. Questo si chiama mobile-first indexing, e se il tuo sito non è pronto, sei tagliato fuori.
Cosa succede in pratica? Il bot di Google (Googlebot Smartphone, si chiama proprio così) viene sul tuo sito fingendo di essere un Pixel con Chrome aggiornato. Legge tutto quello che vede su quello schermo. Se nascondi contenuto in versione mobile pensando “tanto su desktop si vede”, quel contenuto per Google non esiste piu. Punto.
Ho visto siti perdere il 60% del traffico per questo motivo esatto. Avevano un menu accordion su mobile dove il contenuto importante era dentro tab che Google non riusciva a renderizzare bene. Risultato? Tutte quelle parole chiave sparite dall’indice.
| Cosa controllare | Come controllarlo | Frequenza |
|---|---|---|
| Contenuto identico su mobile e desktop | Ispeziona URL su Search Console | Mensile |
| Dati strutturati presenti su mobile | Test rich results di Google | Mensile |
| Tag canonical coerenti | Screaming Frog o SiteBulb | Trimestrale |
| Robots.txt non blocca CSS/JS | Test mobile-friendly | Una volta dopo ogni release |
| Hreflang corretti su mobile | Search Console > Targeting | Trimestrale |
Una cosa che mi fa rabbia vedere: sviluppatori che bloccano CSS e JavaScript nel robots.txt “per sicurezza”. Google deve poter caricare quei file, altrimenti vede il sito come una pagina HTML grezza degli anni ’90. E ti penalizza, giustamente.
Un altro errore che vedo spesso: testi diversi tra mobile e desktop. Magari sul desktop hai 2.000 parole con dettagli tecnici, sul mobile ne mostri 400 perché “sennò scrolla troppo”. Errore. Mostrale tutte e 2.000, magari dentro sezioni espandibili ben fatte (con tag corretti, non con display:none che nasconde davvero), così Google le vede e gli utenti scelgono se leggerle.
Ti faccio un consiglio che vale oro: apri il tuo sito da uno smartphone vero, non da DevTools. Naviga come farebbe un cliente. Senti quanto è lento, vedi cosa è scomodo. Quella è l’esperienza che Google misura.
Velocità di caricamento: il fattore che fa la differenza
Ti faccio una domanda diretta: quanto ci mette il tuo sito a caricare la prima schermata su uno smartphone con connessione 4G? Se la risposta è “non lo so”, abbiamo già un problema. Se è “circa 5 secondi”, abbiamo un problema piu grosso.
La velocità mobile non è un nice-to-have, è il fattore più importante secondo i dati che vediamo ogni giorno nei progetti di SEO. Google lo dice apertamente: ogni secondo in più di caricamento significa il 20% di conversioni in meno. Questo numero non viene da una tesi accademica, viene da uno studio di Deloitte su milioni di sessioni.
Cosa rallenta un sito su mobile? Le cause sono quasi sempre le stesse:
- Immagini pesanti senza compressione (un JPG da 2MB nel 2026 è imperdonabile)
- JavaScript che blocca il rendering (script di terze parti tipo chat, pixel, analytics caricati male)
- Font caricati in modo sbagliato (3 font diversi, 4 pesi ciascuno = 600KB di font)
- CSS non critico nel head (tutto il CSS viene caricato prima che la pagina si veda)
- Hosting scarso (sì, serve un hosting decente, non possiamo farci niente)
Un trucco pratico: usa il formato WebP o AVIF per le immagini. Risparmi il 30-50% di peso senza perdere qualità visibile. La maggior parte dei CMS moderni lo fa in automatico, ma controlla sempre, perche sui siti vecchi spesso non è attivato.
| Tempo di caricamento | Conversion rate medio | Bounce rate medio |
|---|---|---|
| 1-2 secondi | 100% (baseline) | 9% |
| 3 secondi | 87% | 32% |
| 4 secondi | 70% | 50% |
| 5+ secondi | 50% | 65%+ |
Una mia esperienza concreta: cliente nel settore beauty, sito WordPress lentissimo, LCP a 4.8 secondi. Abbiamo fatto solo tre cose: cambiato hosting (da quello da 4 euro al mese a uno serio), attivato la cache a livello server e convertito le immagini in WebP. LCP sceso a 1.6 secondi, traffico organico +34% in 60 giorni. Niente magia, solo basi tecniche fatte bene.
Per chi non sa da dove partire, il nostro team performance parte sempre dall’audit di velocità prima di toccare qualsiasi altra cosa. Se la base è marcia, ogni altra strategia frana.
Design responsive: la base tecnica che non puoi ignorare
Cos’è il responsive design? In due parole: un sito unico che si adatta automaticamente a qualsiasi schermo, dal Galaxy Fold piegato al monitor 4K dell’ufficio. Niente versioni separate, niente domini m. davanti al sito principale, niente app camuffate da siti.
Perché è importante? Perché Google preferisce siti responsive da quasi 10 anni e perché manutenere due siti separati è una pessima idea anche dal punto di vista pratico. Doppio lavoro, doppi bug, doppi costi.
Quali sono i pilastri di un buon responsive? Vediamoli:
- Meta viewport tag nell’head di ogni pagina (
<meta name="viewport" content="width=device-width, initial-scale=1">) - Media queries CSS per cambiare layout sotto certe larghezze
- Immagini fluide con
max-width: 100% - Griglie flessibili (CSS Grid o Flexbox, niente tabelle per il layout)
- Touch target di almeno 48×48 pixel (i pulsanti devi poterli toccare con il pollice)
Ho visto un cliente proporre un sito “mobile-friendly” fatto con tabelle HTML annidate. Anno 2024. Ho dovuto spiegare con calma che eravamo arrivati al CSS Grid, ormai. Il punto è che molti sviluppatori freelance lavorano ancora con metodi vecchi, e se non controlli te ne accorgi solo quando il traffico crolla.
Una domanda comune: “Devo progettare prima per desktop o per mobile?”. Risposta: mobile-first, sempre. Si parte dal layout mobile, poi si aggiungono elementi per gli schermi più grandi. È più facile aggiungere che togliere, e ti costringe a tenere solo le cose veramente essenziali.
Il team creative di Dominanza lavora sempre con questo approccio. Si parte da wireframe a 375 pixel di larghezza (iPhone SE base), e solo dopo si pensa alle versioni tablet e desktop. Risultato: siti che funzionano davvero su smartphone, non versioni desktop ridotte a forza.
Una cosa che molti dimenticano: testa il sito anche su Android economici. Gli iPhone sono potenti, gli Samsung S24 pure. Ma il tuo cliente medio in Italia magari ha un Android da 200 euro con 3GB di RAM. Su quello dispositivo il tuo sito deve funzionare ugualmente bene. Chrome ha un emulatore di throttling che simula CPU lenta, usalo.
Core Web Vitals e l’esperienza utente su mobile
I Core Web Vitals sono tre numeri che Google misura per capire quanto è gradevole usare il tuo sito. Da marzo 2024 hanno cambiato uno di questi (FID è diventato INP), e da maggio 2026 le soglie sono ancora più severe rispetto a prima.
Quali sono questi tre numeri?
| Metrica | Cosa misura | Valore “buono” | Valore “scarso” |
|---|---|---|---|
| LCP (Largest Contentful Paint) | Quanto ci mette a caricare l’elemento principale | < 2.5 secondi | > 4 secondi |
| INP (Interaction to Next Paint) | Quanto risponde velocemente al tocco | < 200 ms | > 500 ms |
| CLS (Cumulative Layout Shift) | Quanto si muovono gli elementi mentre carica | < 0.1 | > 0.25 |
L’LCP è il piu facile da ottimizzare: comprimi le immagini, usa un CDN, pre-carica l’immagine principale con <link rel="preload">. In una settimana di lavoro tecnico vedi risultati concreti.
L’INP è più subdolo. Misura quanto rispondono i tap dell’utente. Se hai JavaScript che blocca il main thread (analytics, chat, banner cookie mal scritti), ogni tap dell’utente sembra in ritardo. Il fix? Carica gli script di terze parti dopo, mai sincroni nel head, e rivedi qualunque event listener pesante.
Il CLS è quello che fa più danno all’esperienza utente percepita. Hai presente quando stai per cliccare un pulsante e all’ultimo si sposta perché si carica una pubblicità sopra? Quello è CLS. Soluzione: dichiara sempre width e height su immagini e iframe, riserva spazio per contenuti che caricano dopo (ads, embed), evita di iniettare contenuto sopra a contenuto già visibile.
Una storia vera: progetto B2B nel settore industriale, ottimo contenuto, link decenti, traffico fermo da mesi. Apriamo Search Console: tutti gli URL nella categoria “scarsi” per Core Web Vitals. CLS a 0.4 a causa di un banner promozionale. Lo togliamo, ridisegnamo il modo in cui gli ads si caricano, riserviamo spazio fisso. Risultato in 90 giorni: posizioni medie da pagina 2 a top 5 su 80% delle keyword strategiche.
I Core Web Vitals si misurano direttamente in Search Console nella sezione “Esperienza”, oppure con Tag come l’AI di Dominanza che integra dati di RUM (Real User Monitoring) con analisi predittive. Il vantaggio? Vedi i problemi prima che diventino crolli di posizionamento.
Un consiglio da expert: non guardare solo il “Lab data” di PageSpeed Insights. Guarda il “Field data” di CrUX (Chrome User Experience Report). Quello rappresenta gli utenti veri, l’altro è una simulazione.
Contenuti scritti pensando allo schermo piccolo
Scrivere per mobile non è uguale a scrivere per desktop. Lo schermo è 6 volte più piccolo, l’utente ha meno pazienza, il pollice ha meno precisione. Devi adattarti, altrimenti la gente esce dopo 3 secondi.
Cosa funziona davvero su mobile?
- Paragrafi corti: 2-3 righe massimo, mai blocchi di testo lunghi
- Frasi brevi: 15-20 parole è il punto dolce, oltre si perde l’attenzione
- Sottotitoli ogni 200-300 parole: l’utente scansiona, non legge
- Liste puntate quando hai 3+ elementi correlati
- Bold strategico: 1-2 parole chiave per paragrafo, non frasi intere
- Domande dirette: rompono il ritmo e fanno fermare l’occhio
Hai notato come sto scrivendo questo articolo? Frasi corte. Paragrafi piccoli. Domande sparse. Non è uno stile, è una scelta strategica per il mobile.
Una cosa che non funziona: i blocchi di testo da 500 parole senza pause. Su desktop si leggono, su mobile sono un muro. L’utente scrolla via senza nemmeno provarci.
Quando lavoriamo sui contenuti dei casi studio dei nostri clienti, partiamo sempre dalla domanda: “Come si legge questo dal pollice di un utente in metropolitana?”. Se la risposta è “male”, riscriviamo.
Un altro punto sottile: i font. Su mobile, sotto i 16 pixel di font-size il testo è scomodo per la maggior parte delle persone. Sotto i 14 è proprio illeggibile. Vedo ancora siti con testo a 12 pixel “perché entra di più nello schermo”. Sbagliato. Meglio meno testo leggibile che molto testo invisibile.
E gli spazi bianchi? Sembrano spreco ma non lo sono. Lo spazio tra paragrafi, il padding ai lati del contenuto, l’altezza delle righe (line-height: 1.6 minimo): tutto questo aiuta la lettura. Un sito troppo “denso” su mobile stanca dopo poche righe.
Ultimo consiglio sui contenuti: usa la voce attiva. “Abbiamo aumentato il traffico” suona meglio di “Il traffico è stato aumentato”. Su mobile, dove l’attenzione vola via, la voce attiva ti aiuta a tenere ancorato il lettore alla frase.
Strumenti gratuiti per testare la SEO mobile del tuo sito
Buona notizia: per fare un audit serio della SEO mobile non ti serve spendere niente. Gli strumenti migliori sono gratis, e li uso ogni giorno anche sui progetti enterprise.
Quali sono i fondamentali?
| Strumento | Cosa fa | Quando usarlo |
|---|---|---|
| PageSpeed Insights | Misura Core Web Vitals e dà suggerimenti | Settimanale per pagine chiave |
| Google Search Console | Mostra indicizzazione mobile e problemi UX | Quotidiano |
| Lighthouse (in Chrome DevTools) | Audit completo con punteggio 0-100 | Prima/dopo ogni release |
| Mobile-Friendly Test | Verifica usabilità di una singola pagina | Quando lanci una pagina nuova |
| Test Rich Results | Controlla dati strutturati su mobile | Per template nuovi |
| CrUX Dashboard | Dati di utenti reali sui Core Web Vitals | Mensile per trend |
Una nota importante su PageSpeed Insights: il punteggio “Performance” da 0 a 100 è solo una sintesi. I valori che contano per Google sono i Core Web Vitals nella sezione “Field Data”, quelli misurati su utenti veri. Un sito può avere 95/100 in lab e fallire i Core Web Vitals nel campo, perche le condizioni reali sono peggiori.
Lo uso così: testo la stessa pagina 3 volte a distanza di 5 minuti, faccio la media. PageSpeed varia parecchio tra una sessione e l’altra, una sola misurazione non è affidabile.
Search Console è il vero gioiello per chi fa SEO seriamente. Nella sezione “Esperienza > Esperienza sulla pagina” vedi quali URL hanno problemi di Core Web Vitals raggruppati per tipologia. Se 200 pagine hanno LCP scarso e tutte usano lo stesso template, sai dove intervenire.
Il team SEO di Dominanza usa anche Screaming Frog per crawlare il sito e simulare Googlebot Smartphone. Ti accorgi subito se ci sono pagine che restituiscono codici 404 al bot mobile ma non al desktop, errore più comune di quanto pensi.
Un trucco poco conosciuto: Chrome DevTools ha un emulatore di rete che simula 3G, 4G lenta, offline. Apri DevTools > Network > Throttling > Slow 4G, ricarica la pagina, e vedi cosa prova un utente in zona con segnale debole. Quell’esperienza è quella di milioni di italiani fuori dalle grandi città.
Per chi vuole andare oltre, esistono tool a pagamento come Calibre, SpeedCurve o DebugBear, ma per iniziare i tool gratuiti coprono il 90% delle esigenze. Se hai bisogno di un audit professionale facci sapere, ma prima prova questi strumenti da solo, vedrai che impari tantissimo.
Errori frequenti che fanno crollare il posizionamento mobile
Negli anni che faccio SEO ho visto sempre gli stessi errori ripetersi. Sono questi che bruciano traffico più di qualsiasi update algoritmico.
Errore numero 1: pop-up invadenti. Quel pop-up newsletter che copre il 70% dello schermo appena entri sul sito? Google lo punisce dal 2017. Eppure lo vedo ancora ovunque. Soluzione: pop-up piccoli in basso, attivati dopo 30 secondi o sull’intent di uscita, mai all’arrivo.
Errore numero 2: contenuto nascosto in tab che Google non vede. Hai presente quei tab “Descrizione | Specifiche | Recensioni” sui prodotti e-commerce? Se sono fatti male, Google legge solo il primo. Il resto del contenuto è invisibile per il ranking. Devi usare HTML standard con <details> e <summary>, o JavaScript che renderizza tutto subito.
Errore numero 3: link troppo vicini. Il pollice medio è grande circa 50 pixel. Se i tuoi link sono distanti meno di 8 pixel uno dall’altro, l’utente clicca quello sbagliato il 30% delle volte. Distanza minima tra elementi cliccabili: 8 pixel, ma 12-16 sono meglio.
Errore numero 4: contenuto diverso tra mobile e desktop. Lo abbiamo già detto, ma vale la pena ripeterlo. Se nascondi metà del testo “perché è troppo lungo per il mobile”, Google considera quella metà come inesistente.
Errore numero 5: ignorare i 404 mobile. Alcune pagine vanno in errore solo da smartphone (problemi di JavaScript, redirect mal configurati). Search Console le mostra, ma molti SEO le ignorano. Risultato: paginate che spariscono dall’indice.
| Errore | Impatto stimato sul traffico | Difficoltà di fix |
|---|---|---|
| Pop-up invadenti | -15% / -30% | Bassa |
| Tab non indicizzati | -20% / -50% sul prodotto | Media |
| Link troppo vicini | -10% conversion rate | Bassa |
| Contenuto nascosto | -25% / -40% | Media |
| 404 solo mobile | -5% / -15% | Variabile |
Un caso reale che ricordo bene: cliente nel settore travel, traffico organico in calo del 35% in tre mesi senza apparente motivo. Audit completo: scopriamo che dopo un aggiornamento del CMS il menu mobile usava JavaScript con innerHTML non eseguito da Googlebot. Tutto il sito navigabile da utenti, ma per Google esisteva solo la home. Ripristinato il menu in HTML semantico, traffico tornato in 6 settimane.
Altro errore comune che vedo nei progetti italiani: non testare mai su iPhone vecchi. Un iPhone 8 con iOS aggiornato è ancora usato da molti, ma ha CPU più lenta. Se il tuo sito su quel dispositivo carica in 7 secondi, stai escludendo una fetta di mercato. Per problemi più sofisticati, vale la pena guardare i casi studio di performance marketing e capire come l’ottimizzazione mobile si lega al ROI reale.
L’ultima cosa che voglio dirti: la SEO mobile non è un progetto con inizio e fine. È un processo continuo. Ogni release del sito può rompere qualcosa, ogni update di Chrome può cambiare le regole del gioco. Il monitoraggio costante è quello che separa chi cresce da chi sta fermo.
Domande Frequenti (FAQ)
Quanto tempo ci vuole per vedere risultati dopo aver ottimizzato il sito per mobile? Dai 30 ai 90 giorni in media. Google deve ricrawlare le pagine ottimizzate, valutarle e aggiornare le posizioni. Sui Core Web Vitals i risultati arrivano più veloci, sui contenuti riformattati ci vuole un po’ di pazienza.
Devo avere un’app mobile oltre al sito ottimizzato? No, non per la SEO. Le app non vengono indicizzate da Google nello stesso modo del sito web. Un sito mobile veloce e ben fatto copre il 95% delle esigenze di un’azienda media.
AMP serve ancora nel 2026? No. Google ha tolto i benefici di ranking di AMP nel 2021. Se il tuo sito è già veloce con responsive standard, AMP è inutile e aggiunge complessità.
Quanto pesa la velocità mobile rispetto ad altri fattori SEO? Pesa tanto, ma non è tutto. Diciamo che la velocità è una condizione necessaria ma non sufficiente. Senza velocità non vai in alto, ma serve anche contenuto di qualità, link e architettura del sito ben fatti. Per approfondire come questi fattori si integrano, dai un’occhiata al nostro blog sul performance marketing.
Il mio sito si vede bene su iPhone ma male su Android, perchè? Spesso è un problema di font o CSS specifici di WebKit (il motore di Safari) che non funzionano allo stesso modo su Chrome Android. Testa sempre su entrambe le piattaforme, non solo su iOS.
Posso usare Wix o Squarespace per avere un sito mobile-friendly? Sì, le piattaforme moderne producono siti responsive di base. Ma il livello di ottimizzazione avanzata che ti serve per competere sulla SEO è limitato. Per progetti seri, WordPress con tema su misura o sviluppo custom danno più controllo.
Quanti utenti mobile ha un sito italiano medio? Tra il 60% e il 85% del traffico totale, dipende dal settore. E-commerce moda e food: 80%+. B2B industriale: 50-60%. Local business: 75%+. Comunque, il mobile è sempre la maggioranza.
Quanto costa un audit SEO mobile professionale? Dipende dalla dimensione del sito. Per un sito sotto le 100 pagine, un audit serio parte da 800-1.500 euro. Per progetti più grandi si va su tariffe customizzate. Se vuoi un preventivo specifico per il tuo caso, la pagina contatti è il punto di partenza.
Un sito vecchio si può ottimizzare o devo rifarlo da zero? Nel 70% dei casi si può ottimizzare senza rifarlo. L’altro 30% sono siti talmente vecchi (HTML tabellare, niente responsive, CMS abbandonati) che conviene ricominciare. Un audit tecnico iniziale ti dice subito in quale categoria sei.
Cosa controllo per primo se il traffico mobile cala all’improvviso? Tre cose, in ordine: 1) Search Console, sezione “Esperienza” e “Copertura” per problemi tecnici nuovi, 2) Core Web Vitals per peggioramenti di velocità, 3) eventuali update di Google annunciati nelle ultime 4 settimane. Nel 90% dei casi la causa è in una di queste tre aree.
