SEO per dispositivi mobili nel 2026: posizionarsi in un indice mobile-first

In sintesi: Dal luglio 2024 l’indicizzazione mobile-first è attiva al 100%. La pagina che Google indicizza e posiziona è la tua versione mobile, scansionata con l’agente Googlebot Smartphone. Il controllo che quasi nessuno fa: apri Google Search Console, dividi le query principali per dispositivo e cerca quelle che si posizionano molto peggio su mobile rispetto a desktop. In quel divario si nasconde traffico che stai perdendo.

Indicizzazione mobile-first in un minuto

Nel giugno 2024 Google ha annunciato l’ultimo step di una migrazione durata anni: dal 5 luglio 2024 i siti ancora scansionati con Googlebot desktop passano a Googlebot Smartphone. I contenuti non accessibili da mobile non sono più indicizzabili. Fine della storia.

Cosa significa in pratica: Google utilizza la versione mobile del tuo contenuto, scansionata con l’agente smartphone, per indicizzazione e ranking. Per la ricerca, la pagina mobile è la versione canonica. I ranking desktop derivano dall’indicizzazione mobile.

Un’ulteriore distinzione utile: “mobile-friendly” non dice nulla sul posizionamento. Indica solo che non subisci la penalità per interstitial. Sono due cose diverse, e confonderle è l’errore alla base di molte guide SEO mobile.

Diagramma che mostra Googlebot Smartphone che scansiona una pagina mobile, la quale diventa la versione indicizzata e posizionata per tutti gli utenti, compresi quelli desktop — Flusso dell’indicizzazione mobile-first: Googlebot renderizza la pagina mobile, quel DOM viene indicizzato e i ranking risultanti valgono per tutti gli utenti — anche su desktop.

Il controllo che quasi nessuno esegue: il gap di ranking mobile vs desktop

Ho ignorato la dimensione Dispositivo in Google Search Console per più tempo di quanto ammetta volentieri. È lì, a un clic dal report predefinito, e l’ho trattata come una nota a piè di pagina per anni. Errore. In SEOJuice, quando facciamo audit mobile sui nuovi siti, la comparazione per dispositivo è quasi sempre la prima cosa che fa emergere un gap che il proprietario non conosceva.

Ecco come procedere. Apri GSC, vai su Risultati di ricerca, clicca “Nuovo”, aggiungi un filtro di confronto e scegli “Dispositivo: Mobile vs Desktop”. Vedrai la Posizione media affiancata per le stesse query. Ordina per le query con delta mobile negativo più alto: quelle in cui la posizione mobile è sensibilmente peggiore di quella desktop.

Un piccolo gap uniforme su tutte le query è rumore. I SERP mobile hanno layout diverso e la posizione può variare di 1-2 slot solo per l’impaginazione su schermi più piccoli. Quello che cerchi è un caso specifico: una query in cui sei #4 su desktop e #9 su mobile. Quel pattern segnala un problema proprio sulla versione mobile di quella pagina. Contenuti e link sono gli stessi. L’esecuzione mobile no. Velocità, contenuto mancante o un errore di rendering ti costano posizioni su quella query ed è invisibile se non guardi lo split per dispositivo.

Questo audit è gratuito, richiede dieci minuti e indica subito quali pagine necessitano di interventi specifici per mobile. La maggior parte dei siti non lo esegue mai. Chi lo fa trova di solito almeno una query ad alto volume con un gap di 3-5 posizioni di cui non aveva idea.

Grafico a barre che confronta la posizione media desktop e mobile per lo stesso set di query, con una query evidenziata che mostra un grande gap di ranking mobile — Il gap di posizione mobile-vs-desktop in GSC. Piccoli scarti uniformi sono normali differenze di layout; un ampio gap su una query specifica segnala un problema nella pagina mobile da diagnosticare.

Mobile Core Web Vitals: stesse soglie, test più duro

Correzione che manda in confusione molti SEO, perché varie guide autorevoli lo riportano ancora male: i tre Core Web Vitals attuali sono LCP (Largest Contentful Paint, buono ≤ 2,5 s), INP (Interaction to Next Paint, buono ≤ 200 ms) e CLS (Cumulative Layout Shift, buono ≤ 0,1). Le soglie si applicano al 75° percentile dei dati field reali.

INP ha sostituito FID (First Input Delay) il 12 marzo 2024. Come ha scritto il team Chrome: «Dopo anni di lavoro, siamo pronti a rendere INP un Core Web Vital stabile. È un passo avanti significativo nel misurare la reattività, colmando molte lacune di FID.» FID è stato rimosso dagli strumenti Chrome entro settembre 2024. Se una guida cita ancora FID come Core Web Vital, è indietro di oltre due anni. Conta perché FID e INP misurano cose diverse: FID catturava solo il ritardo prima che il browser gestisse l’input, INP misura tutta la latenza dell’interazione fino al paint successivo. Più severo e rappresentativo.

Perché i punteggi CWV mobile falliscono spesso quando quelli desktop passano: i test lab simulano un dispositivo Android di fascia media su 4G con throttling CPU. Il tuo MacBook con Chrome DevTools non è quel dispositivo. Una pagina che sul portatile renderizza in 1,8 s può arrivare a 3,2 s su un Moto G reale con segnale 4G. Stesso codice, stesso hosting. La penalità di throttling fa divergere i punteggi mobile.

(Aggiungo: i moltiplicatori di throttling di Chrome DevTools sono cambiati tra versioni, e i dati field CrUX possono differire dalle metriche lab in entrambe le direzioni a seconda del mix di dispositivi degli utenti. Usa i dati field di PageSpeed Insights, scheda mobile, come segnale primario. I test lab servono a intercettare regressioni, meno come verità assoluta.)

Dove controllare i dati field mobile: PageSpeed Insights estrae dati CrUX segmentati per dispositivo. Il report Core Web Vitals di Search Console mostra il bucket mobile separato dal desktop. Una pagina “buona” nel bucket desktop e “scarsa” in quello mobile necessita di ottimizzazioni mirate. La nostra guida all’audit Core Web Vitals spiega come leggere e agire su ogni metrica. Per il contesto su Lighthouse, come Lighthouse calcola il punteggio SEO illustra la traduzione delle metriche lab nell’audit.

Riferimento soglie Core Web Vitals che mostra LCP buono a 2,5 s o meno, INP buono a 200 ms o meno, CLS buono a 0,1 o meno, etichettato come dati field mobile al 75° percentile — Soglie Core Web Vitals attuali, valutate al 75° percentile dei dati field. INP ha sostituito FID il 12 marzo 2024. Fonte: web.dev

Rendering mobile, parità e la trappola JS/SPA

Google è esplicito sulla parità di contenuto: «Solo il contenuto mostrato sul sito mobile viene usato per l’indicizzazione.» Differenze di design ok. Accordion, sezioni collassabili, tab: il contenuto dietro di essi viene comunque indicizzato. Non viene indicizzato ciò che manca del tutto dal DOM mobile o che richiede un’interazione utente per comparire. Se il template desktop mostra dettagli prodotto in una sidebar che su mobile collassa e non viene mai renderizzata nel DOM mobile, quel contenuto non esiste per l’indice.

Il caso SPA è più sottile. Google elabora le app JavaScript in tre fasi: crawling, rendering, indicizzazione. Le pagine finiscono in coda per il rendering; la documentazione spiega che “possono restare in coda qualche secondo, ma anche di più”, poi un headless Chromium le renderizza. Su una CPU mobile con throttling, un’hydration lenta si somma al ritardo di coda. Se il crawl mobile di Googlebot arriva alla tua SPA e il contenuto principale appare al 4-5° secondo, la snapshot renderizzata rischia di essere incompleta. In sviluppo non vedi nulla: sul tuo pc l’hydration dura meno di un secondo.

Il test: in Search Console, ispeziona l’URL sospetto. Clicca “Testa URL attivo”, poi “Visualizza pagina testata” e passa alla scheda HTML. Quello è l’HTML catturato da Googlebot. Confrontalo con ciò che vedi nel browser. Se nel view di ispezione mancano parti di body, il problema è il rendering. Le opzioni (rendering server-side, generazione statica, prerender sopra la piega) sono nel nostro SPA SEO guide.

Viewport, tap target e interstitial intrusivi

Meccaniche di base. Verificale una volta; non perderci sonno.

Tag viewport: <meta name="viewport" content="width=device-width, initial-scale=1"> nel <head>. Senza, i browser mobile renderizzano a larghezza desktop e zoomano. Trenta secondi se manca.

Tap target: Bottoni e link dovrebbero essere almeno 48 px CSS di altezza e larghezza, con spazio adeguato. Lighthouse segnala target troppo piccoli o ravvicinati (la soglia WCAG è più bassa, ma 48 px è la sicurezza per passare Lighthouse). Questione di bounce rate, non di ranking diretto.

Interstitial intrusivi: Google ha un segnale di declassamento per le pagine che mostrano un popup full-screen all’ingresso su mobile prima di accedere al contenuto. Popup exit-intent, banner cookie obbligatori e overlay ritardati di qualche secondo vanno bene. Un full-screen “iscriviti prima di leggere” al caricamento no.

Checklist di audit mobile-vs-desktop

La versione di riferimento del gap audit. La colonna Sintomo è ciò che osservi in GSC o analytics; il resto spiega diagnosi e fix.

Sintomo	Causa probabile	Dove controllare	Fix
Query molto peggio su mobile che su desktop	Pagina mobile lenta o CWV mobile non superati	Split dispositivo GSC, poi PageSpeed Insights scheda mobile	Ottimizza LCP/INP sul template mobile di quel tipo di pagina
Traffico mobile giù, desktop stabile	Gap di parità — meno contenuti visibili su mobile	Ispezione URL → Visualizza pagina testata → scheda HTML	Servi tutto il contenuto su mobile; rimuovi nascondimenti condizionali che eliminano il body copy
Pagina indicizzata ma body vuoto nel crawl	Ritardo di hydration SPA o contenuto gated	HTML renderizzato in Ispezione URL vs pagina live	Renderizza server-side o prerender i contenuti critici; rimuovi gate di interazione in load
Buon bounce desktop, alto bounce mobile	Tap target piccoli, interstitial d’ingresso, leggibilità scarsa	Audit Lighthouse mobile, poi test manuale su telefono	Target 48 px, rimuovi interstitial di ingresso, aumenta base font
CWV “buoni” su desktop, “scarsi” su mobile	Comportamento previsto da dispositivo throttled	CrUX in report CWV di Search Console, bucket mobile	Ottimizza per Android medio su 4G; riduci risorse blocking

Keyword e differenze SERP su mobile

I SERP mobile mostrano meno risultati organici above the fold, più local pack e più intent “near me”. Gli utenti mobile cercano di più local e transazionale. Se hai pagine local che si posizionano bene su desktop ma non convertono su mobile, verifica se un map pack spinge il tuo risultato organico fuori dallo schermo. È un problema di layout SERP; la soluzione è l’ottimizzazione locale.

Triaging SEO mobile in 20 minuti

In ordine di impatto. Falli una volta e saprai dove concentrare il tempo.

Audit del gap in GSC. Risultati di ricerca, confronto dispositivo, ordina per delta mobile negativo maggiore. Segna ogni query con gap ≥ 3 posizioni e annota gli URL.
PageSpeed Insights sulle pagine in gap. Esegui gli URL segnati nella scheda mobile. Guarda prima i dati field CrUX, poi i lab. Nota quali tra LCP, INP o CLS falliscono.
Ispezione URL e HTML renderizzato. Per le pagine a maggior traffico in gap, specialmente se usi React, Vue o Angular SPA, verifica che il body sia presente nell’HTML renderizzato. Se manca, risolvi il rendering prima — la velocità è secondaria.
Tre fix meccanici. Controlla che il meta viewport esista, verifica i tap target in Lighthouse e assicurati che non parta un interstitial di ingresso su mobile. Un’ora per verificarlo su tutto il sito, facile da delegare.

Obiettivo: capire quale problema hai prima di spendere tempo a risolvere quello sbagliato. La nostra checklist di SEO hygiene copre la superficie tecnica più ampia se vuoi un sweep completo dopo questo triage.

I dispositivi mobili generano circa metà del traffico web mondiale — 50–52 % nei dati StatCounter di maggio 2026 (solo mobile 50,3 %, mobile+tablet 51,8 %). Qualunque cifra si usi: la versione mobile del sito è la principale superficie commerciale ed è l’unica che Google posiziona.

Esegui un audit SEO gratuito per vedere i gap mobile-vs-desktop e quali problemi mobile ti costano ranking.

Domande frequenti

Che cos’è l’indicizzazione mobile-first?

L’indicizzazione mobile-first significa che Google scansiona e indicizza il tuo sito con l’agente Googlebot Smartphone e il contenuto della pagina mobile viene usato per il ranking. Il rollout è completo: da luglio 2024 vale per il 100 % dei siti indicizzati. Il contenuto presente solo nella versione desktop è invisibile a Google.

Google posiziona mobile e desktop separatamente?

C’è un solo indice, costruito dalla tua pagina mobile. Il layout SERP cambia per dispositivo, quindi la posizione media può variare di uno-due slot. Un ampio gap per query (es. #4 desktop vs #9 mobile) segnala di solito un problema specifico della pagina mobile.

Come controllo i miei ranking mobile?

Google Search Console → Risultati di ricerca → clic “Nuovo” → Confronto dispositivo → Mobile vs Desktop visualizzando la Posizione media. Ordina per il delta mobile negativo più grande. I rank tracker che supportano la segmentazione per dispositivo offrono la stessa vista a livello keyword, utile per monitorare nel tempo.

La velocità della pagina mobile è un fattore di ranking?

Sì. I Core Web Vitals mobile (LCP, INP e CLS) alimentano i segnali di esperienza pagina e, dato che la pagina mobile è quella indicizzata, la velocità mobile influisce sui ranking per tutti gli utenti. Il test a dispositivo throttled usato da Google fa sì che la stessa pagina spesso abbia punteggi peggiori su mobile anche senza differenze di codice.

Letture correlate:

Our powerful suite of automation tools for SEO

Learn, discover, and get inspired by our content