Il mobile-first indexing è il sistema con cui Google usa la versione mobile di una pagina, scaricata dal crawler per smartphone, per indicizzarla e posizionarla nei risultati. Vale anche per chi cerca da computer: quello che Google legge è la pagina come la vede un telefono.
Quattro delle dieci guide italiane che abbiamo letto in prima pagina su questo tema parlano ancora della scadenza di marzo 2021 come di una cosa da preparare. La transizione invece si è chiusa tra ottobre 2023 e luglio 2024. Per capire che cosa resta da controllare oggi abbiamo fatto due cose: abbiamo contato con quale Googlebot Google scansiona il nostro sito, e abbiamo scaricato 52 pagine italiane in prima pagina su Google prima come smartphone e poi come desktop, confrontando le due versioni campo per campo.
Cosa significa mobile-first indexing
Mobile-first indexing significa che, per ogni URL, Google scarica e analizza la versione che riceve uno smartphone. Testo, link, dati strutturati, meta tag e immagini che entrano nell'indice sono quelli di quella versione. La documentazione di Google Search Central lo dice in una riga: Google utilizza la versione mobile dei contenuti di un sito, sottoposto a scansione con l'agente per smartphone, per l'indicizzazione e il ranking.
Non esiste un indice separato per i telefoni. L'indice è uno solo, cambia la fonte da cui viene alimentato. Se una frase compare solo nella versione desktop di una pagina, per Google quella frase non esiste, e la pagina non si posiziona per le ricerche che contengono quella frase anche quando l'utente cerca da un PC.
È un meccanismo di indicizzazione, a valle del crawling. Decide quale versione viene letta, non premia le pagine che si vedono meglio sul telefono. Per come le due fasi si incastrano con il ranking c'è la guida su come funzionano i motori di ricerca.
La transizione è finita: le date
Google ci ha messo quasi otto anni a passare tutto il web sotto il crawler mobile. Le tappe, tutte annunciate sul blog di Search Central:
| Quando | Cosa è successo |
|---|---|
| Marzo 2018 | Inizia il rollout sui siti già pronti |
| Maggio 2019 | Annuncio: dal 1° luglio 2019 i nuovi domini sono mobile-first di default |
| Marzo 2020 | Google annuncia il passaggio di tutto il web; la scadenza viene poi rinviata più volte |
| 31 ottobre 2023 | Transizione dichiarata completa; la scansione desktop viene ridotta e i siti che non funzionano su mobile restano per ora sul crawler desktop |
| 5 luglio 2024 | Anche gli ultimi siti passano a Googlebot Smartphone. Un sito il cui contenuto non è accessibile da mobile smette di essere indicizzabile |
L'annuncio del giugno 2024 è firmato da John Mueller e contiene una precisazione che le guide italiane quasi non riportano: Googlebot Desktop non sparisce. Google scrive che lo si può ancora trovare nei log del server, perché viene usato, tra le altre funzioni della ricerca, per le schede prodotto e per Google for Jobs.
Cosa vediamo nei nostri log: il 91% è Googlebot Smartphone
Per vedere quanto pesa ancora il crawler desktop abbiamo letto il log di accesso di visilay.com dal 31 agosto al 30 settembre 2026. Abbiamo tenuto solo le richieste con user agent Googlebot arrivate da indirizzi 66.249.x.x, la rete da cui scansiona Google, e scartato le altre 148: un user agent si falsifica in una riga e una parte di quel traffico era quasi certamente di bot che si spacciano per Google.
| Crawler | Richieste | Quota sul crawler principale |
|---|---|---|
| Googlebot Smartphone | 1.157 | 91,4% |
| Googlebot Desktop | 109 | 8,6% |
| Googlebot-Image | 177 | non conteggiato |
| Altri user agent Google | 9 | non conteggiato |
| Totale da 66.249.x.x | 1.452 |
Il dato più utile è dove va il crawler desktop. Delle sue 109 richieste, 45 riguardavano le sitemap XML e 7 il file robots.txt: quasi la metà (48%). Altre 24 erano la home page. Le altre 33 erano sparse su singole pagine, quasi tutte visitate una volta sola nel mese, contro più di mille richieste da smartphone. Il contenuto che finisce nell'indice lo legge il telefono.
Se vuoi rifare il conto sul tuo sito, il rapporto Statistiche di scansione di Google Search Console divide le richieste per tipo di Googlebot. Il log del server è più preciso, perché mostra anche gli URL. Per riconoscere i bot veri da quelli falsi vale quanto scritto nella guida sui web crawler.
In Italia quasi metà delle visite arriva ancora da desktop
Qui c'è un'asimmetria che spiega molti problemi. Secondo Statcounter, a settembre 2026 in Italia il 51,78% delle pagine viste arriva da smartphone, il 46,61% da desktop e l'1,61% da tablet. Negli Stati Uniti, nello stesso mese, la divisione è quasi identica: 49,1% mobile e 48,47% desktop (Statcounter, Stati Uniti). Le guide americane che aprono con "la maggior parte del traffico è mobile" sono vere solo a metà su entrambe le sponde.
E Google domina la ricerca da telefono: il 97,53% delle ricerche mobile in Italia passa da lì (Statcounter, settembre 2026). Quindi metà degli utenti di un sito italiano lo guarda da un monitor, ma il motore che porta quasi tutte le visite organiche lo legge come uno smartphone. E chi decide come deve essere il sito, di solito, lo approva guardandolo su un portatile.
Il nostro test: 49 pagine italiane lette da smartphone e da desktop
Abbiamo preso i risultati organici e i siti correlati mostrati da Google.it per quattro ricerche commerciali italiane: "impresa di pulizie milano", "commercialista torino", "serramenti in pvc prezzi" e "macchine caffè professionali". Sono 52 pagine tra piccole imprese, studi professionali, portali e grandi e-commerce come Leroy Merlin, Tecnomat e Cimbali. Il 3 ottobre 2026 le abbiamo scaricate due volte, con lo user agent di Chrome su Android e con quello di Chrome su Windows, e abbiamo confrontato l'HTML ricevuto. Tre pagine non hanno risposto (un dominio non risolto, un 404, un errore 500), ne restano 49.
| Cosa abbiamo confrontato | Pagine con la stessa versione su mobile e desktop |
|---|---|
| Redirect verso un URL mobile separato (m.) | 49 su 49: nessun sito usa URL separati |
| Title | 49 su 49 |
| Meta description | 49 su 49 |
| Meta robots e canonical | 49 su 49 |
| Dati strutturati (numero di blocchi e tipi schema.org) | 49 su 49 |
| Numero di parole nel testo della pagina | 40 su 49 |
| Numero di link | 43 su 49 |
| Differenza oltre il 5% in parole o link | 5 pagine su 49 (10%) |
| Pagine che dichiarano Vary: User-Agent | 6 su 49 |
| Pagine senza meta viewport in nessuna delle due versioni | 1 su 49 |
| Pagine senza alcun dato strutturato JSON-LD | 10 su 49 (20%) |
La notizia è che i problemi raccontati nel 2018 non ci sono più. Nessun sito m., nessun title diverso, nessun noindex solo su mobile, nessun dato strutturato che sparisce sul telefono. Il responsive design ha fatto il lavoro che anni di articoli chiedevano di fare a mano.
Le differenze stanno nel corpo della pagina, e nei casi in cui ci sono vanno in tutte e due le direzioni:
- le pagine elenco di Pagine Gialle e Pagine Bianche consegnano allo smartphone meno testo (il 9,8% e il 5,9% di parole in meno) e meno immagini (6 contro 8, 16 contro 35);
- un'impresa di pulizie milanese fa il contrario: la versione mobile ha il 33% di parole in più, probabilmente blocchi pensati per il telefono che su desktop restano esclusi;
- uno studio di commercialisti torinese serve agli smartphone un template diverso, con il viewport fissato a 320 pixel e il 22,7% di link in più;
- il sito di un ordine professionale non ha il meta viewport in nessuna delle due versioni: su un telefono si vede come una pagina desktop rimpicciolita.
Due limiti, perché il test va letto per quello che è. Abbiamo confrontato l'HTML che il server consegna, senza eseguire JavaScript: parte del contenuto mancante sulle pagine elenco potrebbe arrivare dopo il rendering. E abbiamo usato gli user agent di Chrome, non quelli di Googlebot, perché molti firewall bloccano chi si presenta come Googlebot senza arrivare dagli indirizzi di Google. Un sito che riconosce il crawler e gli serve una versione dedicata non lo vediamo.
Cosa deve essere uguale tra mobile e desktop
Le best practice di Google chiedono che la versione mobile sia equivalente a quella desktop su questi punti:
- Contenuto principale. Se il mobile ha meno contenuti, Google avverte di aspettarsi una perdita di traffico. Il testo si può riorganizzare in tab e accordion per risparmiare spazio, purché resti nell'HTML.
- Title e meta description uguali nelle due versioni. La guida ai meta tag spiega quali legge davvero Google.
- Meta robots. Un noindex o un nofollow presente solo su mobile vale per tutta la pagina.
- Dati strutturati presenti su entrambe le versioni, con priorità per Breadcrumb, Product e VideoObject. Dettagli nella guida allo schema markup.
- Immagini della stessa qualità, con URL stabili e lo stesso testo alternativo.
- Lazy loading. Google non carica i contenuti che richiedono un'interazione dell'utente come scorrere, cliccare o digitare. Il testo principale non va caricato al tap.
- Risorse e robots.txt. CSS, JavaScript e immagini necessari al rendering mobile non devono essere bloccati, e le regole devono essere le stesse sulle due versioni.
Nella sezione di risoluzione dei problemi Google elenca sedici errori tipici, da "dati strutturati mancanti" a "la pagina mobile è bloccata da robots.txt". Almeno cinque riguardano solo i siti con URL mobile separati (pagina mobile in errore, frammento # nell'URL, più pagine desktop indirizzate alla stessa pagina mobile, redirect alla home mobile, capacità del server mobile): una configurazione che nel nostro campione non usa più nessuno.
Responsive, dynamic serving o URL separati
Le configurazioni possibili sono tre. Con il responsive design l'URL e l'HTML sono gli stessi per tutti e cambia solo l'impaginazione via CSS: è quella che Google raccomanda. Con il dynamic serving l'URL è lo stesso ma il server consegna un HTML diverso in base al dispositivo, e dovrebbe dichiararlo con l'intestazione Vary: User-Agent. Con gli URL separati esiste un sito m.dominio.it collegato a quello desktop con rel="alternate" e canonical.
Il dynamic serving è in calo anche a livello globale. Il Web Almanac 2024 di HTTP Archive, che analizza milioni di siti, rileva l'intestazione Vary sull'1% delle pagine desktop e sul 2% di quelle mobile, contro il 12% e il 13% del 2022. Nel nostro campione nessun sito usa URL separati. Sei pagine su 49 inviano Vary: User-Agent, ma solo in tre l'HTML ricevuto cambiava davvero; in compenso lo studio torinese con il viewport a 320 pixel cambia template senza dichiararlo. Vary: User-Agent è anche l'intestazione che compare quando un plugin di cache tiene copie separate per telefono e computer. Il rischio sta lì: si svuota la cache, una delle due copie si rigenera con un modulo in meno, e il sito che Google legge non è più quello che il marketing controlla dal portatile.
Come verificare il tuo sito
Il Mobile-Friendly Test e il rapporto Usabilità sui dispositivi mobili di Search Console non esistono più. Oggi la verifica si fa così:
- Controllo URL in Search Console. Il test dal vivo mostra l'HTML che Googlebot Smartphone ha ottenuto e lo screenshot della pagina renderizzata. Cerca dentro l'HTML una frase del testo principale e i tuoi dati strutturati.
- Statistiche di scansione. In Impostazioni, il rapporto per tipo di Googlebot ti dice se il crawler smartphone è davvero quello prevalente, come nel nostro 91,4%.
- Doppia scansione con un crawler. Screaming Frog, Sitebulb o la Site Audit di Ahrefs permettono di scansionare il sito con user agent smartphone e poi desktop. Confronta per ogni URL numero di parole, link interni, title e dati strutturati, come abbiamo fatto nel test.
- Lighthouse in Chrome DevTools per le prestazioni su mobile e per controllare viewport, dimensione dei caratteri e dei pulsanti. È qui che entrano i Core Web Vitals, che Google misura anche sul campo.
Se le versioni non coincidono, la priorità è riportare nella versione mobile tutto il contenuto principale. Questo controllo è uno dei primi passi dell'audit SEO che facciamo prima di un progetto di consulenza SEO, insieme al resto della SEO tecnica.
Mobile-first indexing, mobile-friendly e ranking non sono la stessa cosa
Un sito può essere indicizzato senza problemi con il crawler mobile ed essere scomodo da usare sul telefono: testo minuscolo, pulsanti attaccati, popup che coprono la pagina. Il mobile-first indexing riguarda cosa Google legge. L'esperienza mobile riguarda come la pagina viene usata, ed entra nel ranking attraverso i segnali di page experience, a cominciare dalla velocità misurata sui telefoni.
Per questo "il mio sito è responsive, quindi sono a posto" è vero per l'indicizzazione e non dice niente sul posizionamento. Un caso frequente quando un sito non compare su Google per una ricerca precisa è un testo che sul desktop c'è e sul telefono viene caricato solo dopo un clic. Per la user experience vera serve un'altra analisi.
Domande frequenti
No. Decide quale versione della pagina Google legge, cioè quella per smartphone, non dà punti alle pagine che si vedono meglio sul telefono. L'esperienza mobile pesa sul posizionamento attraverso altri segnali, come i Core Web Vitals misurati sui dispositivi mobili.
Sì, se il contenuto non è accessibile da un dispositivo mobile. Dal 5 luglio 2024 Google scansiona tutti i siti con Googlebot Smartphone e ha scritto che un sito il cui contenuto non è accessibile da mobile non è più indicizzabile. Un sito brutto da vedere sul telefono ma leggibile resta nell'indice.
Sì, ma poco. Google dice che lo usa ancora per alcune funzioni come le schede prodotto e Google for Jobs. Sul nostro sito, a settembre 2026, era l'8,6% delle richieste del crawler principale, e quasi metà riguardava sitemap e robots.txt.
Sì, se sono nell'HTML al caricamento della pagina. Google accetta che su mobile il testo venga raccolto in tab o accordion per risparmiare spazio. Non legge invece i contenuti che si caricano solo dopo un clic, uno scorrimento o una digitazione.
No. Google raccomanda il responsive design, e gli URL separati richiedono rel=alternate, canonical e redirect coerenti per ogni pagina. Nel nostro test su 49 pagine italiane in prima pagina nessuna usava un sito m.
Dal rapporto Statistiche di scansione di Search Console, che divide le richieste per tipo di Googlebot, oppure dai log del server filtrando gli user agent Googlebot provenienti dagli indirizzi di Google. Il Controllo URL mostra l'HTML che Googlebot Smartphone ha ricevuto per una pagina.
Una cosa che nel settore si dice poco
Nel 2026 il problema del mobile-first indexing riguarda soprattutto chi guarda il sito. In Italia quasi metà delle visite arriva da un monitor, e le persone che approvano testi e layout lavorano quasi sempre da lì. Google invece, almeno sul nostro sito, con il crawler desktop guarda quasi solo sitemap e home page. Il risultato è che la versione del sito su cui si discute in riunione è quella che conta meno per l'indicizzazione.
Una regola pratica: ogni modifica a una pagina importante si approva guardandola prima sul telefono, e una volta al mese si confrontano le due versioni con un crawler. Costa un'ora. Nel nostro test title, meta tag e dati strutturati coincidevano ovunque; le eccezioni stavano quasi tutte nel corpo della pagina, cioè proprio nella parte che chi approva dal portatile dà per scontata.
