Il mobile-first indexing indica il modo in cui Google utilizza principalmente la versione mobile di una pagina per indicizzarne i contenuti e valutarla nei risultati di ricerca. Non significa che esista un secondo “indice mobile”, né che avere un layout responsive produca automaticamente un vantaggio di ranking.
Oggi c’è anche un punto temporale importante da chiarire: il passaggio al mobile-first indexing è terminato. Google ne ha annunciato il completamento nel 2023 e, dal luglio 2024, per Search utilizza Googlebot Smartphone per il crawling e l’indicizzazione dei siti.
La domanda quindi non è più “come preparo il sito al mobile-first indexing?”, come si legge ancora in molte vecchie guide. La domanda utile è un’altra:
il contenuto che Google recupera e rende come smartphone contiene realmente tutto ciò che serve per comprendere, indicizzare e valutare la pagina?
In questa guida vediamo come funziona il mobile-first indexing oggi, quali differenze contano tra desktop e mobile e soprattutto come verificare un sito WordPress senza confondere indicizzazione, responsive design, velocità e Core Web Vitals.
Cos’è il mobile-first indexing di Google
Nel mobile-first indexing Google utilizza la versione mobile del contenuto come riferimento per indicizzazione e ranking.
È questo il punto centrale della documentazione ufficiale sul mobile-first indexing.
Se il sito utilizza un normale responsive design, spesso non esistono davvero due pagine separate. L’URL e l’HTML possono essere gli stessi, mentre CSS e layout adattano la visualizzazione al viewport.
In altre configurazioni, invece, desktop e mobile possono ricevere HTML differente oppure utilizzare URL distinti. È soprattutto in questi casi che le differenze fra le versioni diventano più rischiose.
Per capire come questa fase si inserisce nel processo complessivo puoi partire dalla guida sull’indicizzazione Google: crawling, rendering, indexing e ranking sono collegati, ma non sono la stessa cosa.
Google usa la versione mobile per indicizzazione e ranking
Mobile-first non significa semplicemente che Google “guarda se il sito è bello sul telefono”.
Il meccanismo riguarda quale contenuto Google recupera e usa come base.
Immagina una pagina che su desktop contenga:
- descrizione completa del prodotto;
- link alle categorie correlate;
- recensioni;
- immagini con ALT descrittivi;
- dati strutturati;
- informazioni tecniche.
Se sul mobile una parte di questi elementi scompare realmente dall’HTML reso a Google, la versione utilizzata per l’indicizzazione può offrire meno informazioni.
Il problema quindi non è il monitor più piccolo. È la perdita di contenuto o segnali nella versione che Google usa.
Questo vale anche per elementi meno visibili all’utente, come metadata, direttive robots e structured data.
Non esiste un indice mobile separato
L’espressione “mobile-first index” può far pensare a due database:
indice desktop + indice mobile
Non è il modello corretto.
Google continua a gestire il proprio indice della Ricerca; mobile-first descrive il modo con cui viene recuperato e utilizzato il contenuto della pagina.
Questa distinzione elimina anche un altro equivoco: non devi “farti inserire nell’indice mobile”. Devi assicurarti che il contenuto importante sia disponibile quando Google accede al sito come smartphone.
Mobile-first indexing oggi: la transizione è già terminata
Il mobile-first indexing non è una novità alla quale Google sta ancora gradualmente trasferendo i siti.
Il progetto è iniziato molti anni fa ed è ormai diventato il funzionamento normale della Ricerca.
Il completamento del rollout nel 2023
Il 31 ottobre 2023 Google ha annunciato il completamento della migrazione al mobile-first indexing.
Nello stesso annuncio ha spiegato che le informazioni sull’indexing crawler presenti in precedenza nelle impostazioni di Search Console non erano più necessarie, perché i siti funzionanti su mobile venivano ormai principalmente scansionati dal crawler mobile.
Puoi leggere l’annuncio ufficiale sul completamento del mobile-first indexing.
Questo rende obsolete molte guide che suggeriscono ancora di controllare se il proprio dominio “è stato trasferito” al mobile-first indexing.
Oggi quella verifica non è più il centro della diagnosi.
Cosa è cambiato dal 5 luglio 2024 con Googlebot Smartphone
Google ha effettuato un ulteriore passaggio nel luglio 2024.
Dal 5 luglio 2024, per la normale attività di Search, Google ha dichiarato di effettuare crawling e indexing dei siti con Googlebot Smartphone. Se il contenuto di un sito non è accessibile affatto da un dispositivo mobile, può quindi non essere indicizzabile.
La modifica è spiegata nell’annuncio finale sul crawling con Googlebot Smartphone.
Questo non significa che Googlebot Desktop sia scomparso dall’infrastruttura di Google. Può ancora comparire nei log per alcune funzionalità specifiche.
Se vuoi approfondire user-agent, differenze fra Smartphone e Desktop e comportamento del crawler, trovi una guida separata su Googlebot e la scansione di un sito.
Per questa pagina basta ricordare il principio operativo:
per Search devi progettare il contenuto assumendo che Google lo recuperi come smartphone.
Mobile-first indexing e mobile-friendly non sono la stessa cosa
Qui nasce una delle confusioni più frequenti.
Mobile-first indexing e mobile-friendly rispondono a due domande differenti.
Mobile-first indexing:
quale versione del contenuto utilizza Google come base per crawling, indicizzazione e ranking?
Mobile usability:
quanto è semplice per una persona utilizzare quella pagina da smartphone?
Sono concetti collegati, ma non intercambiabili.
Un sito può essere indicizzabile senza essere progettato bene per mobile
Google specifica che non è obbligatorio avere una “versione mobile” separata per poter comparire nella Ricerca.
Allo stesso tempo, dal 2024 il contenuto deve essere effettivamente accessibile con un dispositivo mobile perché Google possa recuperarlo normalmente per Search.
Puoi quindi avere una pagina tecnicamente raggiungibile da smartphone ma scomoda da utilizzare: testo troppo piccolo, menu difficile da usare, elementi che escono dal viewport o interazioni progettate male.
Quella pagina può avere un problema serio di esperienza mobile senza che il problema coincida automaticamente con il meccanismo di mobile-first indexing.
Vale anche il contrario: una pagina apparentemente gradevole su smartphone può nascondere problemi di indicizzazione se Google non riesce a recuperare alcune risorse o se il contenuto reso è incompleto.
Perché accessibilità mobile e user experience vanno valutate separatamente
La diagnosi corretta parte quindi da due controlli.
Il primo è tecnico:
Googlebot Smartphone riesce a recuperare e rendere il contenuto necessario?
Il secondo riguarda l’utente:
una persona riesce a leggere, navigare e interagire bene con la pagina da uno schermo piccolo?
Una pagina può superare bene il primo controllo e fallire il secondo.
Separare i due livelli evita di trattare qualsiasi problema mobile come “problema di mobile-first indexing”.
Cosa deve essere equivalente tra mobile e desktop
Google non richiede che desktop e mobile abbiano un layout identico.
Puoi cambiare colonne, navigazione, dimensioni, ordine visivo e modalità con cui alcuni blocchi vengono presentati. Puoi anche utilizzare tab e accordion per gestire meglio lo spazio.
Ciò che conta è che il contenuto primario e i segnali importanti restino equivalenti.
Contenuti, title, meta robots e dati strutturati
Se desktop e mobile servono versioni differenti, controlla innanzitutto:
- contenuto principale;
- heading importanti;
title;- meta description;
- direttive
robots; - link rilevanti;
- dati strutturati.
Un caso particolarmente pericoloso è avere un noindex nella versione mobile ma non nella desktop.
Con il mobile-first indexing non puoi ragionare pensando che Google userà comunque la configurazione desktop: se quella direttiva compare nella versione che Google utilizza, può impedirne l’indicizzazione.
Lo stesso vale per i dati strutturati.
Se una pagina prodotto possiede markup Product completo su desktop e ne è priva nella versione mobile, stai servendo a Google una rappresentazione differente della stessa pagina.
Immagini, ALT, link e risorse necessarie al rendering
Anche immagini e risorse fanno parte del problema.
Google raccomanda che le immagini importanti siano disponibili su mobile con qualità adeguata e ALT coerenti. CSS, JavaScript e altre risorse necessarie al rendering non dovrebbero essere bloccate se Google deve utilizzarle per comprendere la pagina.
Qui è utile distinguere ancora una volta visualizzazione e contenuto.
Un’immagine può essere ridimensionata o sostituita con una variante ottimizzata per il viewport. Questo è normale.
Diventa invece un problema quando un’immagine rilevante, il relativo testo alternativo o un collegamento importante esistono soltanto sul desktop e scompaiono realmente dal contenuto mobile.
Lazy loading e contenuti caricati dopo un’interazione
Il lazy loading è utile, ma va implementato con criterio.
Google avverte in particolare di non rendere il contenuto primario dipendente da un’interazione dell’utente per essere caricato.
Se una parte essenziale compare soltanto dopo uno swipe, un clic o un’altra azione che Google non esegue durante il rendering, quel contenuto potrebbe non essere recuperato.
Questo punto è diverso dall’usare un accordion.
Puoi avere un testo presente nell’HTML/rendering e mostrarlo visivamente solo quando l’utente apre una sezione. Il problema nasce quando l’interazione è necessaria per effettuare la richiesta che crea il contenuto che prima non esisteva.
La domanda utile durante un audit è quindi:
il contenuto è già disponibile a Google oppure viene generato solo dopo un’azione?
Responsive design, dynamic serving o URL mobile separati
Google supporta tre configurazioni principali per i siti mobile:
| Configurazione | URL | HTML | Considerazione principale |
|---|---|---|---|
| Responsive design | stesso | stesso | layout adattato tramite CSS |
| Dynamic serving | stesso | può cambiare | HTML variabile secondo user-agent |
| URL separati | differenti | differente | relazione corretta fra desktop e mobile |
Google raccomanda il responsive web design perché normalmente è la configurazione più semplice da implementare e mantenere.
Non significa che le altre due siano vietate.
Perché Google raccomanda il responsive design
Con un normale responsive design hai lo stesso URL e lo stesso documento HTML di base.
Di conseguenza diminuiscono le occasioni in cui mobile e desktop possono divergere accidentalmente su:
- testo;
- metadata;
- canonical;
- structured data;
- link;
- direttive robots.
Non è il responsive design in sé a “migliorare il ranking”.
Il vantaggio è soprattutto architetturale e operativo: mantenere una sola rappresentazione logica della pagina riduce la complessità.
Il dynamic serving, invece, può essere necessario in alcuni progetti ma introduce una variabile ulteriore: il server deve riconoscere correttamente il client e servire la versione prevista. Cache, CDN e user-agent detection devono essere coerenti.
Canonical e alternate quando esistono URL desktop e mobile differenti
I siti con URL mobile separati — il classico esempio è m.example.com — richiedono più attenzione.
Desktop e mobile devono essere collegati correttamente e ciascuna pagina desktop dovrebbe avere una controparte mobile realmente equivalente.
Una configurazione in cui molte pagine desktop vengono reindirizzate alla sola homepage mobile è particolarmente problematica: Google potrebbe non trovare una versione mobile equivalente dei singoli contenuti.
Vanno inoltre verificati:
rel="canonical";rel="alternate";- eventuali
hreflang; - status HTTP;
- redirect;
- robots.txt;
- corrispondenza uno-a-uno fra URL.
Su un nuovo progetto, se non esistono esigenze particolari che richiedono URL separati, sceglierei normalmente il responsive design.
Come verificare il mobile-first indexing del sito oggi
Non esiste più la necessità di controllare se Google “ha attivato” il mobile-first indexing sul dominio.
La verifica utile è osservare cosa Google può effettivamente recuperare dalla pagina.
Controllo URL, rendering e Googlebot Smartphone
Per un singolo URL partirei da Google Search Console.
Lo strumento Controllo URL permette di analizzare ciò che Google conosce della pagina e di eseguire un test live.
Dopo un test live puoi anche osservare la pagina renderizzata e verificare se elementi importanti risultano presenti.
Controlla soprattutto:
- se l’URL è accessibile;
- se può essere indicizzato;
- quali risorse non vengono caricate;
- se il rendering contiene il contenuto principale;
- se link e immagini importanti compaiono;
- se il risultato differisce in modo sostanziale da ciò che ti aspetti.
Non limitarti allo screenshot.
Una pagina può sembrare visivamente corretta ma avere nell’HTML reso metadata, link o structured data differenti. Quando il problema è tecnico, confrontare il contenuto renderizzato può essere più utile del semplice colpo d’occhio.
Crawl Stats e log del server
Per analisi più ampie puoi utilizzare il report Crawl Stats di Search Console.
Il report mostra la cronologia delle richieste effettuate da Google e può aiutarti a individuare problemi di disponibilità, risposte server e tipologie di crawler.
I log del server permettono di scendere ancora più in profondità.
Sono particolarmente utili quando vuoi sapere:
- quali URL Googlebot ha realmente richiesto;
- con quale user-agent;
- quale status HTTP ha ricevuto;
- quanto spesso viene scansionata una determinata area;
- se il crawler incontra errori o redirect inattesi.
Per un piccolo sito non serve trasformare ogni controllo mobile in una log analysis. Se però stai diagnosticando un problema sistematico o una configurazione complessa, i log possono eliminare molte ipotesi.
Lighthouse dopo il ritiro del Mobile-Friendly Test
Qui bisogna correggere una best practice ormai obsoleta.
Il Mobile-Friendly Test di Google e il report Mobile Usability di Search Console sono stati ritirati il 1° dicembre 2023. La vecchia indicazione di “inserire l’URL nel Mobile-Friendly Test” non è quindi più attuale.
Google ha indicato strumenti come Lighthouse fra le alternative utili per analizzare aspetti dell’esperienza mobile.
Puoi approfondire il funzionamento nella guida a Google Lighthouse.
Attenzione però: Lighthouse non sostituisce Search Console per verificare l’indicizzazione.
I due strumenti rispondono a domande diverse:
Search Console / URL Inspection → cosa riesce a recuperare e conosce Google
Lighthouse → quali problemi tecnici e di esperienza emergono durante un test della pagina
Questa separazione è molto più utile del cercare un unico “test mobile” che dia un verdetto complessivo.
Gli errori mobile che possono impedire a Google di vedere il contenuto
Quando una pagina desktop funziona ma la versione mobile perde contenuto, la diagnosi dovrebbe iniziare dalle differenze concrete fra ciò che viene servito.
noindex, robots.txt e risorse bloccate
Un errore evidente è utilizzare direttive robots differenti.
Se la versione mobile riceve:
<meta name="robots" content="noindex">
mentre quella desktop no, la configurazione può impedire l’indicizzazione della pagina.
Un altro problema nasce quando CSS, JavaScript, immagini o endpoint necessari vengono bloccati e Google non riesce a renderizzare correttamente il contenuto.
Non significa che ogni file JavaScript debba essere necessariamente accessibile. Il criterio è funzionale: Google deve poter recuperare ciò che gli serve per elaborare la pagina.
Contenuti mancanti e dati strutturati differenti
Il problema più comune non è necessariamente un blocco tecnico evidente.
Può essere una differenza editoriale.
Per esempio:
desktop → 1.500 parole di contenuto, FAQ, tabella, link e schema;
mobile → introduzione corta e pulsante “mostra altro” che recupera il resto solo dopo il clic.
In questo caso l’interfaccia può apparire intenzionalmente più pulita, ma Google potrebbe ricevere una versione informativamente impoverita.
Ridurre l’ingombro sullo schermo è corretto.
Ridurre ciò che Google può recuperare non lo è.
Errori, redirect e pagine mobile non equivalenti
Con URL separati devi inoltre controllare che la pagina mobile corrispondente:
- restituisca uno status valido;
- non generi un errore quando il desktop risponde
200; - non reindirizzi indiscriminatamente alla homepage;
- non utilizzi URL non indicizzabili come sostituto della pagina desktop;
- mantenga una relazione coerente con canonical e alternate.
Questi problemi sono meno frequenti sui moderni siti WordPress responsive, ma possono ancora emergere in infrastrutture legacy, multisito, proxy, personalizzazioni server-side o sistemi di cache basati sul dispositivo.
Mobile-first indexing, Core Web Vitals e ranking: cosa cambia davvero
Il mobile-first indexing viene spesso inserito nello stesso contenitore insieme a responsive design, velocità, Core Web Vitals e ranking.
La relazione esiste, ma non è quella di una singola catena causale.
L’indicizzazione è un meccanismo, non un “bonus SEO”
Google ha chiarito fin dalle prime fasi del mobile-first indexing che il concetto riguarda il modo con cui raccoglie il contenuto.
Essere responsive non assegna quindi un “mobile-first bonus”.
Allo stesso modo:
Googlebot Smartphone → pagina indicizzata → ranking migliore
non è una formula valida.
Il crawler recupera la pagina. Successivamente entrano in gioco indicizzazione e sistemi di ranking.
Per un quadro più ampio su questa distinzione puoi consultare la guida ai fattori di ranking Google.
Il motivo per cui il mobile-first indexing è importante per la SEO è più concreto: se Google riceve una versione incompleta o tecnicamente difettosa della pagina, parte da informazioni peggiori per elaborarla.
Dove entrano prestazioni e page experience
Le prestazioni appartengono a un altro livello.
Google conferma nella propria documentazione sulla page experience che i Core Web Vitals vengono utilizzati dai sistemi di ranking. Allo stesso tempo specifica che non esiste un unico “page experience signal” e che ottenere valori perfetti non garantisce le prime posizioni.
Quindi non è corretto scrivere:
una pagina mobile più veloce invia un segnale positivo e ottiene automaticamente ranking migliori.
La formulazione utile è:
buone prestazioni migliorano l’esperienza reale; i Core Web Vitals fanno parte dei segnali utilizzati dai sistemi di ranking, ma il loro miglioramento non produce un incremento di posizione predeterminato.
Se devi diagnosticare le prestazioni puoi usare la guida a PageSpeed Insights e l’approfondimento sui Core Web Vitals.
Mobile-first indexing, però, rimane un problema differente.
Mobile-first indexing su WordPress: checklist pratica
Su un moderno sito WordPress responsive, nella maggior parte dei casi non devi costruire una “versione mobile per Google”.
Devi evitare che tema, page builder, plugin, cache o personalizzazioni producano una versione mobile informativamente diversa.
Tema, page builder e contenuti condizionali
Quando utilizzi Elementor, Divi, Gutenberg o altri builder, controlla gli elementi impostati come “nascondi su mobile”.
Nascondere visivamente un blocco tramite CSS non equivale necessariamente a rimuoverlo dal documento.
Il problema nasce quando una funzione condizionale impedisce proprio la generazione dell’HTML o recupera il contenuto soltanto in seguito.
Durante un audit verifica quindi:
- sezioni nascoste per device;
- menu mobile e link interni;
- tab e accordion;
- contenuto dinamico;
- widget caricati via JavaScript;
- immagini responsive;
- dati strutturati generati dai plugin;
- eventuali template distinti per dispositivo.
Non serve che desktop e mobile appaiano identici. Serve che Google non perda informazioni materiali passando alla visualizzazione smartphone.
Cache, CDN e controllo della versione servita a Googlebot
La cache può rendere il problema meno evidente.
Un plugin o una CDN possono creare cache distinte per mobile e desktop. Se la logica basata sullo user-agent funziona male, Googlebot Smartphone potrebbe ricevere una variante non prevista.
Controlla quindi cosa succede realmente sulla risposta HTTP e non soltanto cosa mostra il tuo browser dopo avere effettuato login a WordPress.
Questo è particolarmente importante se utilizzi:
- cache mobile separata;
- edge caching;
- HTML differente per device;
- redirect basati sullo user-agent;
- ottimizzazioni che rimuovono componenti su smartphone.
Se il sito usa responsive design puro e lo stesso HTML per tutti, questa classe di problemi si riduce molto.
Cosa verificare dopo modifiche importanti al sito
Dopo un redesign, un cambio di tema o una modifica importante del sistema di caching, userei questo ordine:
- apri le pagine principali da smartphone e verifica il normale funzionamento;
- confronta contenuti e link fra desktop e mobile;
- esegui un test live con Controllo URL;
- guarda la versione renderizzata da Google;
- controlla eventuali risorse non caricate;
- verifica title, robots e structured data;
- usa Lighthouse per i problemi di esperienza e performance;
- controlla PageSpeed/Core Web Vitals separatamente se l’obiettivo riguarda le prestazioni.
Se il sito è complesso, aggiungi server log e Crawl Stats.
La checklist serve a trovare una differenza concreta, non a ottenere un punteggio “mobile-first”.
Conclusione
Il mobile-first indexing oggi non è qualcosa da attivare o una transizione alla quale prepararsi: è il normale modo con cui Google Search utilizza il contenuto mobile del sito.
Per un normale WordPress responsive la gestione è spesso semplice. Se stesso URL e stesso HTML contengono testi, link, metadata e dati strutturati completi, il rischio di creare due versioni incoerenti si riduce molto.
L’attenzione deve aumentare quando entrano in gioco HTML condizionale, URL mobile separati, dynamic serving, JavaScript che carica contenuti dopo un’interazione, cache differenziate o configurazioni che mostrano a Googlebot Smartphone una pagina diversa da quella desktop.
Il controllo più importante non è quindi chiedersi se “il sito è mobile-first”.
È verificare:
Googlebot Smartphone riesce a recuperare la versione completa e corretta della pagina?
Poi, separatamente, puoi valutare usabilità, performance e Core Web Vitals.
Se durante questi controlli emergono differenze di rendering, indicizzazione, performance o architettura che richiedono interventi coordinati, il passo successivo è una vera ottimizzazione tecnica del sito, non l’ennesimo test mobile eseguito alla cieca.