Indicizzazione mobile-first

TL;DR — L’indicizzazione mobile-first significa che Google guarda la versione mobile della tua pagina — non quella desktop — per decidere di cosa tratta la pagina e come posizionarla. Non è un «indice mobile» separato e non offre un vantaggio nel posizionamento. La regola fondamentale è semplice: tutto ciò che vuoi far vedere a Google deve essere presente sul sito mobile, perché è quella la versione che Google indicizza.

Cos’è l’indicizzazione mobile-first

Quando Google esegue la scansione del tuo sito, visita principalmente come smartphone — usando un crawler mobile chiamato Googlebot smartphone. Qualunque cosa veda sulla versione mobile della tua pagina è ciò che indicizza e posiziona. Questa è l’indicizzazione mobile-first in una frase: Google usa la versione mobile dei tuoi contenuti per l’indicizzazione e il posizionamento.

Il nome confonde le persone, quindi chiarisco subito due cose:

• Non esiste un “indice mobile” separato. Google ha un indice. L’indicizzazione mobile-first ha solo cambiato quale versione della tua pagina Google guarda — prima il default era desktop, ora è mobile.
• Non è un boost di ranking. Essere in indicizzazione mobile-first non alza le tue posizioni. Cambia solo quale versione dei tuoi contenuti Google legge.

Perché conta: ciò che è su mobile è ciò che conta

Ecco la parte che riguarda davvero il tuo sito. Se qualcosa esiste sulla tua pagina desktop ma non sulla tua pagina mobile — un paragrafo di testo, un’immagine, un link, alcuni dati strutturati — Google potrebbe semplicemente non vederlo, perché sta indicizzando la versione mobile.

Un esempio comune nel mondo reale: un sito mostra l’articolo completo su desktop ma lo riduce su mobile per “mantenere le cose pulite.” Con l’indicizzazione mobile-first, il contenuto tagliato potrebbe non essere mai indicizzato. La soluzione non è complicata — assicurati che le cose importanti siano anche sulla versione mobile.

L’indicizzazione mobile-first non è la stessa cosa di “mobile-friendly”

Questi due concetti vengono confusi di continuo. L’indicizzazione mobile-first riguarda quale versione Google indicizza. L’essere mobile-friendly riguarda quanto è utilizzabile la tua pagina su un telefono — obiettivi di tocco, testo leggibile, nessuno scorrimento orizzontale. Sono idee separate. Una pagina può essere indicizzata mobile-first ed essere comunque scomoda su un telefono, e viceversa. Questo articolo riguarda solo il primo.

Cosa dovresti fare realmente

Per quasi tutti, la risposta è responsive design — un unico set di HTML che si adatta alla dimensione dello schermo. In questo modo le tue versioni mobile e desktop sono lo stesso contenuto per impostazione predefinita, e non devi mantenere due versioni sincronizzate. È anche ciò che Google raccomanda.

Se sei su qualcosa di più vecchio — come un sito mobile separato su URL propri (m.example.com) — funziona ancora, ma è più fragile e richiede più attenzione.

Vuoi il quadro completo — la cronologia verificata, le regole esatte di parità, come Google gestisce la trappola del lazy-load, come si confrontano le opzioni di configurazione e dove Bing differisce? Passa alla scheda Avanzate.

TL;DR — L’indicizzazione mobile-first = Google usa la versione mobile del contenuto di una pagina, indicizzata da Googlebot smartphone, per l’indicizzazione e il posizionamento. Un unico indice, nessuna rinuncia, nessun vantaggio nel posizionamento. La regola operativa è la parità dei contenuti: “only the content shown on the mobile site is used for indexing,” (traduzione) «solo il contenuto mostrato sul sito mobile viene usato per l’indicizzazione», quindi qualsiasi testo, dato strutturato, immagine, testo alternativo o link che vuoi indicizzare deve essere nell’HTML mobile. È distinta dall’ottimizzazione per dispositivi mobili e dall’esperienza di pagina. Il responsive design è la configurazione raccomandata da Google; la pubblicazione dinamica e gli URL separati funzionano ma sono più rischiosi. Attenzione alla trappola del lazy loading attivato da un’interazione. Cronologia: annunciato a novembre 2016 → default per i nuovi siti nel 2019 → ultimo lotto a maggio 2023 → dichiarato completo a ottobre 2023. Bing non ha fatto la stessa scelta — rimane agnostico rispetto al dispositivo con un unico indice.

La definizione, precisamente

La stessa definizione di Google: Google utilizza la versione mobile del contenuto di un sito, indicizzata con l’agente smartphone, per l’indicizzazione e il posizionamento. E nel suo documento sulle best practice mobile-first è ancora più diretto sulla conseguenza: “Only the content shown on the mobile site is used for indexing.” (traduzione) «Solo il contenuto mostrato sul sito mobile viene utilizzato per l’indicizzazione.»

Nella mia guida Ahrefs sull’indicizzazione mobile-first la definisco allo stesso modo — l’indicizzazione mobile-first si riferisce a Google che utilizza la versione mobile del contenuto di un sito per l’indicizzazione e il posizionamento — e aggiungo le due precisazioni che eliminano gran parte della confusione: “There is only one index and you can’t opt out of mobile-first indexing.” (traduzione) «Esiste un solo indice e non puoi disattivare l’indicizzazione mobile-first.» Inoltre non è un vantaggio di posizionamento. Cambia quale versione Google legge, non quanto bene la posiziona.

Googlebot è per lo più il crawler smartphone

Questo è il meccanismo alla base di tutto. Google: “For most sites Google Search primarily indexes the mobile version of the content. As such the majority of Googlebot crawl requests will be made using the mobile crawler, and a minority using the desktop crawler.” (traduzione) «Per la maggior parte dei siti, Google Search indicizza principalmente la versione mobile del contenuto. Di conseguenza, la maggior parte delle richieste di crawling di Googlebot verranno effettuate utilizzando il crawler mobile, e una minoranza utilizzando il crawler desktop.» Esistono due sottotipi — Googlebot Smartphone (“a mobile crawler that simulates a user on a mobile device” (traduzione) «un crawler mobile che simula un utente su un dispositivo mobile») e Googlebot Desktop — ma quello smartphone svolge la maggior parte del lavoro ora.

Google esegue ancora il crawling con lo user-agent desktop a volte, ma la versione che conta per l’indicizzazione è quella mobile.

La parità dei contenuti è la regola n. 1

Se devi ricordare una sola cosa da questa pagina, ricorda questa: ciò che è sul tuo sito mobile è ciò che viene indicizzato. Il documento di Google lo elenca come primo requisito — “Make sure that your mobile site contains the same content as your desktop site” (traduzione) «Assicurati che il tuo sito mobile contenga lo stesso contenuto del tuo sito desktop» — e il dettaglio decisivo è che “only the content shown on the mobile site is used for indexing.” (traduzione) «solo il contenuto mostrato sul sito mobile viene utilizzato per l’indicizzazione.»

John Mueller lo ha detto nel modo più chiaro possibile al Pubcon Pro Virtual 2020: “anything that you want to have indexed, it needs to be on the mobile site,” (traduzione) «qualsiasi cosa tu voglia indicizzare, deve essere sul sito mobile», e “we will only index the mobile content in the future.” (traduzione) «in futuro indicizzeremo solo il contenuto mobile.» Se è solo desktop, pianifica che Google non lo veda.

Una sfumatura utile, però — la parità non significa identico byte per byte. Come l’ho messa nella mia guida Ahrefs sull’indicizzazione mobile-first: “any important content must be present on mobile.” (traduzione) «qualsiasi contenuto importante deve essere presente su mobile.» Puoi avere un layout mobile più snello; semplicemente non puoi eliminare il contenuto, i dati strutturati, le immagini, il testo alternativo o i link che vuoi effettivamente indicizzare.

E un mito da sfatare: il contenuto nascosto/a schede/accordion va bene. Prima del mobile-first, il contenuto nascosto dietro l’interfaccia utente per motivi di UX veniva scontato. Non è più vero — Google non sconta più il contenuto nascosto per migliorare l’esperienza utente. Quindi un accordion mobile che contiene tutto il tuo contenuto va bene; il contenuto è nell’HTML e viene indicizzato.

Gli elementi di parità che contano davvero

Oltre al testo grezzo, il documento delle best practice di Google evidenzia elementi specifici da mantenere equivalenti tra le versioni:

• Dati strutturati. “Make sure that your mobile and desktop sites have the same structured data.” (traduzione) «Assicurati che i siti mobile e desktop contengano gli stessi dati strutturati.» Se il tuo markup è presente solo sul desktop, i tuoi risultati avanzati possono sparire.
• Immagini e testo alternativo. “Make sure that the mobile site has the same alt text for images as the desktop site.” (traduzione) «Assicurati che il sito mobile contenga per le immagini lo stesso testo alternativo del sito desktop.» Rimuovere le immagini o eliminare il testo alternativo sul mobile danneggia Google Immagini.
• Titoli e meta description. “Make sure that the title element and the meta description are equivalent across both versions of your site.” (traduzione) «Assicurati che l’elemento title e la meta description siano equivalenti nelle due versioni del sito.»
• Intestazioni. “Use the same clear and meaningful headings on the mobile site as you do on the desktop site.” (traduzione) «Usa sul sito mobile le stesse intestazioni chiare e significative del sito desktop.» Un template mobile semplificato che elimina gli H2/H3 o li appiattisce in testo semplice indebolisce la struttura della pagina per l’indicizzazione, non solo la sua leggibilità.
• Dati strutturati video. “Use the same video structured data on both your mobile site and desktop site.” (traduzione) «Usa gli stessi dati strutturati video sia sul sito mobile sia sul sito desktop.» Se una pagina contiene markup VideoObject sul desktop, pubblica lo stesso markup sul mobile — altrimenti la versione mobile (quella che Google indicizza effettivamente) lo perde.
• Meta tag robots. “Use the same robots meta tags on the mobile site and the desktop site.” (traduzione) «Usa gli stessi meta tag robots sul sito mobile e sul sito desktop.» Questo è un classico caso di deindicizzazione accidentale: un noindex che esiste solo sul template mobile deindicizzerà la pagina, perché Google indicizza la versione mobile.
• Link interni. Mantieni la navigazione e i link chiave nell’HTML mobile. Non nasconderli dietro interazioni che devono attivarsi prima che i link vengano caricati.

La trappola del lazy-load / interazione utente

Una modalità di errore specifica e comune. Google: “Don’t lazy-load primary content upon user interaction. Google won’t load content that requires user interactions (for example, swiping, clicking, or typing) to load.” (traduzione) «Non caricare in lazy loading il contenuto principale in seguito a un’interazione dell’utente. Google non carica contenuti che richiedono interazioni dell’utente, come scorrere, fare clic o digitare.» Se il tuo contenuto principale appare solo dopo che l’utente tocca «carica altro», scorre un carosello o fa clic su una scheda che recupera contenuto su richiesta, Googlebot non attiverà quell’interazione — quindi il contenuto non viene visto. Carica il contenuto primario allo scroll o includilo nell’HTML iniziale.

La cronologia verificata

L’indicizzazione mobile-first ha richiesto circa sette anni dall’inizio alla fine. Le tappe datate:

• Novembre 2016 — Google ha annunciato per la prima volta l’indicizzazione mobile-first e ha iniziato i test.
• 2018 — è iniziato il rollout ampio dopo il periodo di test.
• 2019 — il mobile-first è diventato il default per i nuovi siti: i domini scoperti dopo questa data sono stati indicizzati mobile-first dall’inizio.
• Marzo 2020 — Google ha annunciato che avrebbe convertito tutto il web entro settembre 2020. Come ha detto Mueller, Google sarebbe “switching to mobile-first indexing for all websites starting September 2020.” (traduzione) «passata all’indicizzazione mobile-first per tutti i siti web a partire da settembre 2020».
• Luglio 2020 — quella scadenza è stata prorogata. Google: “we’ve decided to extend the timeframe to the end of March 2021.” (traduzione) «abbiamo deciso di estendere il periodo fino alla fine di marzo 2021».
• Maggio 2023 — l’ultimo lotto è stato migrato: “the last batch of sites eligible for mobile-first indexing have been moved over.” (traduzione) «l’ultimo lotto di siti idonei all’indicizzazione mobile-first è stato trasferito». In pratica, è qui che il rollout è terminato.
• Ottobre 2023 — Google l’ha dichiarato completo: “the trek to Mobile First Indexing is now complete.” (traduzione) «il percorso verso l’indicizzazione mobile-first è ora completo». (Mueller.)

Ci sono due modi validi per indicare quando il passaggio è stato completato, e vale la pena distinguerli: il rollout è effettivamente terminato con l’ultimo lotto in maggio 2023, mentre Google l’ha dichiarato ufficialmente completo in ottobre 2023. Un “very small set of sites which do not work on mobile devices at all” (traduzione) «insieme molto piccolo di siti che non funzionano affatto sui dispositivi mobili» viene semplicemente indicizzato con il Googlebot desktop — questa è un’eccezione gestita da Google, non un’impostazione che scegli tu. (Le informazioni di indicizzazione sul crawler usato in Search Console sono state rimosse poco dopo l’annuncio di ottobre 2023, poiché non c’era più una combinazione da segnalare.) Per i siti che non sono effettivamente accessibili su un dispositivo mobile, il rischio pratico ora è non essere indicizzabili.

Configurazione: responsive vs. dynamic serving vs. URL separate

Ci sono tre modi per servire il mobile, e Google ha una preferenza chiara:

• Responsive design (consigliato). Un URL, un HTML, il layout si adatta tramite CSS. Google “recommends Responsive Web Design because it’s the easiest design pattern to implement and maintain.” (traduzione) «raccomanda il responsive web design perché è il modello progettuale più facile da implementare e mantenere». La parità è praticamente automatica perché c’è una sola versione.
• Pubblicazione dinamica. Stesso URL, ma il server restituisce HTML diverso in base allo user-agent. Funziona, ma è soggetto a errori: è facile che desktop e mobile vadano fuori sincrono, il che rompe la parità esattamente nei modi sopra descritti.
• URL separati (m-dot). HTML diverso su URL diversi (es. m.example.com). È il meno raccomandato dei tre e il più difficile da mantenere. Se lo usi, la guida di Google: “For separate URLs, set desktop versions as canonical with an alternate link to the mobile version,” (traduzione) «Per gli URL separati, imposta le versioni desktop come canoniche con un link alternativo alla versione mobile», e controlla i tuoi link hreflang tra gli URL separati. L’URL mobile deve servire il contenuto completo e importante — perché è quello che viene indicizzato.

Come verificare se il tuo sito è indicizzato con mobile-first indexing

A questo punto praticamente ogni sito normale lo è. Per confermare una pagina specifica, usa Search Console → URL Inspection / Page indexing e guarda il valore “Crawled as” — “Googlebot smartphone” significa che viene indicizzato in modalità mobile-first. (Come notato, Google ha rimosso il reporting più ampio sulle informazioni del crawler dopo aver dichiarato il rollout completo, perché non esiste più una divisione significativa.)

Bing fa mobile-first indexing? No.

Questo è l’aspetto cross-engine che quasi nessuno copre, e conta se ti interessa più di Google. Bing non è passato al mobile-first indexing come ha fatto Google. Mantiene un unico indice indipendente dal dispositivo invece di indicizzare la versione mobile specificamente. James Murray di Microsoft Bing ha spiegato il ragionamento: “we think it’s more useful to have an integrated view and to be more device agnostic,” (traduzione) «riteniamo più utile avere una visione integrata ed essere più indipendenti dal dispositivo», e “we want to give you the same index and then personalise to you as the user.” (traduzione) «vogliamo offrirti lo stesso indice e poi personalizzarlo per te come utente».

Il punto chiave: l’igiene della parità dei contenuti ti aiuta ancora su Bing, ma Bing non ha annunciato un passaggio all’indicizzazione della versione mobile — tratta l’indice come agnostico rispetto al dispositivo.

Miti comuni, corretti

• “Esiste un indice mobile separato.” No — c’è un solo indice. Il mobile-first indexing cambia solo quale versione Google considera.
• “È un boost di ranking.” No — riguarda quale contenuto viene indicizzato/classificato, non un bonus.
• “È la stessa cosa di mobile-friendly.” No — concetti diversi. Questo riguarda l’indicizzazione; l’essere mobile-friendly riguarda l’usabilità/esperienza della pagina.
• “Puoi fare opt-out / rimanere indicizzato su desktop.” No. (I siti che davvero non funzionano su mobile sono un’eccezione gestita da Google, non un’impostazione.)
• “I contenuti nascosti/a tab/accordion non contano.” Obsoleto — Google non sconta più i contenuti nascosti per l’UX.
• “Il contenuto mobile deve essere identico al desktop.” No — deve contenere lo stesso contenuto importante, non essere identico byte per byte.
• “Riguarda solo i risultati di ricerca mobile.” No — la versione mobile viene usata per l’indicizzazione e il ranking sia nei risultati desktop che mobile.
• “Anche Bing fa mobile-first indexing.” No — Bing rimane agnostico rispetto al dispositivo.

Per capire dove si colloca nel quadro più ampio — crawling, rendering e indice stesso — consulta l’hub sull’indicizzazione. Le regole di parità qui sono anche il motivo per cui l’index bloat e i problemi di crawling emergono a valle: se Google non può vedere il tuo contenuto su mobile, non può indicizzarlo bene in primo luogo.

Riepilogo AI

Una sintesi della versione Advanced:

• L’indicizzazione mobile-first = Google utilizza la versione mobile del contenuto di una pagina, sottoposta a scansione da Googlebot smartphone, per l’indicizzazione e il posizionamento. Un unico indice, nessuna rinuncia, nessun vantaggio nel posizionamento — cambia solo quale versione Google legge.
• Googlebot è ora principalmente il crawler per smartphone — la maggior parte delle richieste di crawl usa il crawler mobile, una minoranza quello desktop.
• La parità dei contenuti è la regola n. 1: “only the content shown on the mobile site is used for indexing.” (traduzione) «Solo il contenuto mostrato sul sito mobile viene utilizzato per l’indicizzazione.» Mantieni testo, dati strutturati (inclusi i dati strutturati video), immagini + testo alternativo, intestazioni, titoli/meta description, meta tag robots e link interni equivalenti su mobile. Mueller: “anything that you want to have indexed, it needs to be on the mobile site.” (traduzione) «qualsiasi cosa tu voglia indicizzare deve essere sul sito mobile.»
• Parità ≠ identità. Il contenuto importante deve essere su mobile, ma non deve essere identico byte per byte. Il contenuto nascosto/a schede ora va bene — Google non lo penalizza più.
• Trappola del lazy-load: Google non attiva interazioni (swipe/click/tipo) per caricare il contenuto. Carica il contenuto primario allo scroll o nell’HTML iniziale.
• Non è mobile-friendliness — quello è un concetto separato di usabilità/esperienza di pagina.
• Configurazioni: il responsive design è consigliato; la pubblicazione dinamica funziona ma è fragile; gli URL separati (m-dot) sono meno consigliati (imposta il canonical desktop e il link alternate alla versione mobile, controlla hreflang).
• Cronologia: annunciato a novembre 2016 → predefinito per i nuovi siti nel 2019 → passaggio dell’intero web entro settembre 2020 (annunciato a marzo 2020) → scadenza estesa a marzo 2021 → ultimo lotto a maggio 2023 → dichiarato completo a ottobre 2023. Un piccolo insieme di siti solo desktop rimane sottoposto a scansione con il crawler desktop.
• Verificalo tramite il valore «Sottoposta a scansione come: Googlebot smartphone» in Search Console.
• Bing non è passato — mantiene un unico indice indipendente dal dispositivo.

Documentazione ufficiale

Documentazione di fonte primaria dai motori di ricerca.

Google

• Best practice per l’indicizzazione mobile-first — il documento canonico: la checklist di parità (contenuti, dati strutturati, immagini/alt, titoli/descrizioni, meta robots), la regola del lazy loading e il confronto tra responsive design, pubblicazione dinamica e URL separati. Inizia qui.
• Googlebot — il crawler che fa il lavoro: Googlebot Smartphone vs. Desktop, e perché la maggior parte delle richieste di crawl sono mobile.
• Scansione e indicizzazione — l’hub per il tema più ampio di scansione e indicizzazione in cui si inserisce.
• Annuncio dell’indicizzazione mobile-first per l’intero web (marzo 2020) — l’annuncio del passaggio dell’intero web entro settembre 2020.
• Prepararsi all’indicizzazione mobile-first, con un po’ di tempo in più (luglio 2020) — l’estensione della scadenza a marzo 2021.
• L’indicizzazione mobile-first è arrivata (ottobre 2023) — l’annuncio ufficiale del completamento.

Bing / Microsoft

• Bing: nessun indice mobile separato (intervista a James Murray) — perché Bing è rimasto indipendente dal dispositivo invece di passare all’indicizzazione mobile-first.

Citazioni dalla fonte

Dichiarazioni ufficiali di Google e Bing. Ogni link è un deep link che salta al passaggio citato nella pagina di origine.

Google — cosa significa l’indicizzazione mobile-first

• “Only the content shown on the mobile site is used for indexing.” (traduzione) «Solo il contenuto mostrato sul sito mobile viene utilizzato per l’indicizzazione.» — Documentazione di Google Search Central. Vai alla citazione
• “For most sites Google Search primarily indexes the mobile version of the content. As such the majority of Googlebot crawl requests will be made using the mobile crawler, and a minority using the desktop crawler.” (traduzione) «Per la maggior parte dei siti, Google Search indicizza principalmente la versione mobile del contenuto. Di conseguenza, la maggior parte delle richieste di crawling di Googlebot verrà effettuata con il crawler mobile e una minoranza con il crawler desktop.» Vai alla citazione
• “a mobile crawler that simulates a user on a mobile device.” (Googlebot Smartphone) (traduzione) «un crawler mobile che simula un utente su un dispositivo mobile.» Vai alla citazione

Google — parità dei contenuti

• “Make sure that your mobile site contains the same content as your desktop site.” (traduzione) «Assicurati che il tuo sito mobile contenga lo stesso contenuto del tuo sito desktop.» Vai alla citazione
• “Make sure that your mobile and desktop sites have the same structured data.” (traduzione) «Assicurati che il tuo sito mobile e desktop abbiano gli stessi dati strutturati.» Vai alla citazione
• “Make sure that the mobile site has the same alt text for images as the desktop site.” (traduzione) «Assicurati che il sito mobile abbia lo stesso testo alternativo per le immagini del sito desktop.» Vai alla citazione

“…the title element and the meta description are equivalent across both versions of your site.” (traduzione) «…l’elemento title e la meta description sono equivalenti nelle due versioni del sito.» Vai alla citazione

• “Use the same clear and meaningful headings on the mobile site as you do on the desktop site.” (traduzione) «Usa le stesse intestazioni chiare e significative sul sito mobile come fai sul sito desktop.» Vai alla citazione
• “Use the same video structured data on both your mobile site and desktop site.” (traduzione) «Usa gli stessi dati strutturati video sia sul sito mobile che su quello desktop.» Vai alla citazione
• “Use the same robots meta tags on the mobile site and the desktop site.” (traduzione) «Usa gli stessi meta tag robots sul sito mobile e sul sito desktop.» Vai alla citazione

Google — la trappola del lazy-load e la configurazione

• “Don’t lazy-load primary content upon user interaction. Google won’t load content that requires user interactions (for example, swiping, clicking, or typing) to load.” (traduzione) «Non caricare in lazy-load il contenuto primario in seguito all’interazione dell’utente. Google non caricherà contenuti che richiedono interazioni dell’utente (ad esempio, scorrimento, clic o digitazione) per essere caricati.» Vai alla citazione
• Google “recommends Responsive Web Design” come il pattern più semplice da implementare e mantenere. (traduzione) «raccomanda il Responsive Web Design» Vai alla citazione
• “Separate URLs: Serves different HTML to each device, and on separate URLs.” (traduzione) «URL separati: fornisce HTML diverso a ciascun dispositivo, e su URL separati.» Vai alla citazione

John Mueller, Google — l’avvertimento chiave (Pubcon Pro Virtual 2020, tramite la copertura di Search Engine Journal)

• “we will only index the mobile content in the future.” (traduzione) «indicizzeremo solo il contenuto mobile in futuro.» Vai alla citazione
• “anything that you want to have indexed, it needs to be on the mobile site.” (traduzione) «qualsiasi cosa tu voglia indicizzare, deve essere sul sito mobile.» Vai alla citazione

John Mueller, Google — la tempistica (tramite la copertura verbatim di Search Engine Land)

• “the trek to Mobile First Indexing is now complete.” (traduzione) «il percorso verso l’indicizzazione mobile-first è ora completo.» (ottobre 2023) Vai alla citazione
• “a very small set of sites which do not work on mobile devices at all” (traduzione) «un insieme molto piccolo di siti che non funzionano affatto sui dispositivi mobili» rimane indicizzato dal Googlebot desktop. Vai alla citazione
• “the last batch of sites eligible for mobile-first indexing have been moved over.” (traduzione) «l’ultimo lotto di siti idonei all’indicizzazione mobile-first è stato trasferito.» (maggio 2023) Vai alla citazione
• “we’ve decided to extend the timeframe to the end of March 2021.” (traduzione) «abbiamo deciso di estendere il periodo fino alla fine di marzo 2021.» (luglio 2020) Vai alla citazione
• “switching to mobile-first indexing for all websites starting September 2020.” (traduzione) «passaggio all’indicizzazione mobile-first per tutti i siti web a partire da settembre 2020.» (annunciato a marzo 2020) Vai alla citazione

James Murray, Microsoft Bing — perché Bing non è passato

• “we think it’s more useful to have an integrated view and to be more device agnostic.” (traduzione) «pensiamo che sia più utile avere una visione integrata ed essere più agnostici rispetto al dispositivo.» Vai alla citazione
• “we want to give you the same index and then personalise to you as the user.” (traduzione) «vogliamo darti lo stesso indice e poi personalizzarlo per te come utente.» Vai alla citazione

Checklist di audit per la parità mobile-first

Esegui questa verifica sul tuo HTML mobile (visualizza il sorgente della versione mobile, oppure usa l’HTML renderizzato di URL Inspection), poiché è quella la versione che Google indicizza:

• Stesso contenuto. Il contenuto completo e importante è presente su mobile — non ridotto “per pulizia”. Tutto ciò che vuoi indicizzare è nell’HTML mobile.
• Stessi dati strutturati. Lo stesso markup è presente su entrambe le versioni, con riferimento agli stessi URL della pagina stessa.
• Stesse immagini + testo alt. Nessuna immagine rimossa su mobile; il testo alt corrisponde alla versione desktop (questo influisce su Google Immagini).
• Stessi title e meta description. title e meta description equivalenti su entrambe le versioni.
• Stessi heading. Il mobile mantiene la stessa struttura di heading chiara e significativa (H2/H3) del desktop — non appiattita in testo semplice.
• Stessi dati strutturati video. VideoObject (o altro markup video) presente su desktop è presente anche su mobile.
• Stessi meta tag robots. Nessun noindex/nofollow accidentale nel template mobile (una classica deindicizzazione accidentale).
• Stessi link interni. Navigazione e link chiave sono nell’HTML mobile — non nascosti dietro interazioni che devono attivarsi prima che i link vengano caricati.
• Nessun contenuto bloccato da interazioni. Il contenuto principale viene caricato allo scroll o nell’HTML iniziale, non solo dopo un tap/swipe/digitazione.
• Contenuto nascosto/a schede è OK — accordion e tab vanno bene purché il contenuto sia nell’HTML (Google non penalizza più il contenuto nascosto dall’UX).
• (Solo per URL separati) Il desktop è impostato come canonico con un link alternate al mobile; hreflang corretto tra le versioni; l’URL mobile serve il contenuto completo.
• Verificato in Search Console — “Crawled as: Googlebot smartphone.”

I modelli mentali

1. Il mobile è la fonte di verità. Qualunque cosa sia nel tuo HTML mobile è ciò che Google indicizza e classifica. Il contenuto solo desktop è, ai fini dell’indicizzazione, invisibile. Fai un audit sulla versione mobile, non su quella che guardi di solito sul tuo laptop.

2. Parità, non identità. Non serve una corrispondenza byte per byte — servono tutti gli elementi importanti su mobile: contenuto, dati strutturati, immagini + alt, title/descrizioni, meta robots, link interni. Un layout più snello va bene; la mancanza di sostanza no.

3. Indicizzazione ≠ vantaggio nel posizionamento e ≠ ottimizzazione per dispositivi mobili. L’indicizzazione mobile-first cambia quale versione Google legge — non alza il posizionamento, e non è la stessa cosa dell’essere utilizzabile su un telefono. Tieni separate queste tre idee e la maggior parte della confusione scompare.

4. Non far interagire Google. Googlebot non scorre, non clicca e non digita per rivelare contenuti. Se il contenuto appare solo dopo un’azione dell’utente, trattalo come non indicizzato. Caricalo allo scroll o nell’HTML iniziale.

5. Scegli la configurazione che rende la parità automatica. Il design responsive significa una sola versione, quindi la parità è gratuita. Il dynamic serving e URL separati significano due versioni da tenere sincronizzate — ogni elemento di parità sopra diventa qualcosa che può andare alla deriva silenziosamente. Scegli responsive a meno che tu non abbia un motivo valido per non farlo.

Indicizzazione mobile-first — cheat sheet

La regola fondamentale: Google indicizza il tuo HTML mobile. “Only the content shown on the mobile site is used for indexing.” (traduzione) «Solo il contenuto mostrato sul sito mobile viene utilizzato per l’indicizzazione.» Se non è su mobile, supponi che non venga indicizzato.

Indicizzazione mobile-first vs. mobile-friendliness

Confronto configurazioni

Per URL separati: imposta il desktop come canonico, aggiungi un link alternate all’URL mobile, mantieni hreflang corretto e assicurati che l’URL mobile serva il contenuto completo.

Checklist di parità (mantieni l’equivalente su mobile)

• Contenuto · dati strutturati (incl. video) · immagini + testo alt · intestazioni · titoli + meta description · tag meta robots · link interni.

Insidie

• noindex che viene servito solo su mobile → deindicizzazione accidentale.
• Contenuto nascosto dietro tap/swipe/digitazione → non caricato da Googlebot.
• Tagliare contenuti “lunghi” su mobile → il contenuto tagliato potrebbe non essere indicizzato.

Cronologia: annunciato a novembre 2016 → predefinito per i nuovi siti nel 2019 → ultimo lotto a maggio 2023 → dichiarato completo a ottobre 2023.

Altri motori: Bing non è passato — un unico indice indipendente dal dispositivo.

Problemi comuni

Modalità di errore reali che emergono una volta che un sito è indicizzato con mobile-first indexing, con la probabile causa e la soluzione.

Contenuto che si posizionava su desktop improvvisamente non viene indicizzato

Sintomo: Una pagina (o una sua sezione) che appariva nei risultati di ricerca smette di comparire, anche se l’URL restituisce ancora 200 e la versione desktop sembra invariata.

Causa probabile: Il contenuto è stato tagliato, compresso o rimosso dal template mobile — spesso una riprogettazione “mantieni il mobile pulito” che ha eliminato un paragrafo, un blocco FAQ o una descrizione di categoria che solo il layout desktop renderizza.

Soluzione + verifica: Visualizza il sorgente della versione mobile (o usa l’URL Inspection di Search Console → Tested Page → View Crawled Page) e conferma che il testo mancante sia effettivamente presente nell’HTML mobile, non solo in quello desktop. Se è assente, aggiungilo al template mobile — Google indicizza ciò che è nell’HTML mobile, senza eccezioni.

Una pagina è stata deindicizzata dopo una riprogettazione

Sintomo: Un URL precedentemente indicizzato scompare dal report di copertura di Search Console (“Excluded by noindex tag”) poco dopo un cambio di template, senza che fosse intenzionale una deindicizzazione.

Causa probabile: Un tag meta robots noindex è presente nel template mobile ma non in quello desktop (o viceversa) — una classica deindicizzazione accidentale quando i due template si disallineano.

Soluzione + verifica: Confronta l’output <meta name="robots"> su mobile vs. desktop per l’URL interessato (visualizza il sorgente su entrambi, o usa curl con un user-agent mobile vs. desktop). Esegui l’URL attraverso Search Console → URL Inspection per confermare “Indexing allowed? Yes” una volta rimosso il tag fuori posto.

I rich results scompaiono dopo un aggiornamento del sito

Sintomo: I rich results (stelle delle recensioni, snippet FAQ, breadcrumb) che apparivano prima di una riprogettazione smettono di comparire, anche se la pagina continua a posizionarsi.

Causa probabile: I dati strutturati sono nel template desktop ma non sono stati portati nel template mobile — Google legge solo l’HTML mobile, quindi il markup che vive solo su desktop è invisibile.

Soluzione + verifica: Esegui l’HTML renderizzato mobile attraverso il Schema Validator o il Rich Result Eligibility Checker e conferma che lo stesso JSON-LD (o microdati) appaia lì come su desktop.

Le immagini smettono di apparire in Image Search

Sintomo: Le immagini che apparivano in Google Image Search per una pagina scompaiono silenziosamente, o le nuove immagini non compaiono mai lì.

Causa probabile: Il template mobile elimina completamente l’immagine (ad es. passa a un layout più leggero senza di essa) o rimuove/accorcia il testo alt rispetto al desktop.

Soluzione + verifica: Confronta i tag <img> e gli attributi alt dell’HTML mobile renderizzato con la versione desktop per la stessa pagina. Se non corrispondono, riporta il testo alt mobile in linea con quello desktop.

Una sezione carosello/tab/“load more” non viene mai indicizzata

Sintomo: Il contenuto che vive in un carosello, un pulsante “load more” o una tab che carica contenuto al clic non compare mai nei risultati di ricerca, non importa quanto importante sia il contenuto.

Causa probabile: Il contenuto si carica solo dopo un’interazione dell’utente (swipe, clic, tap, digitazione). Googlebot non esegue queste interazioni, quindi non vede mai contenuto che è nascosto dietro di esse — questo è diverso da un semplice accordion/tab dove il contenuto è già nell’HTML e solo visivamente nascosto.

Correzione e verifica: Visualizza l’HTML iniziale renderizzato della pagina (“Visualizza pagina indicizzata” di Search Console, o visualizza sorgente con JavaScript abilitato) senza toccare l’interfaccia utente, e conferma che il contenuto sia presente. Se appare solo dopo un’interazione con la pagina, spostalo per il caricamento allo scroll o incorporalo nell’HTML iniziale.

Script e snippet

Strumenti per verificare da soli la parità mobile/desktop, senza aspettare che Search Console rilevi una discrepanza.

Recupera l’HTML mobile vs. desktop con curl (mac/Linux)

Confronta ciò che vede Googlebot smartphone con una scansione desktop, usando le rispettive stringhe user-agent, e ne evidenzia le differenze.

URL="https://example.com/your-page/"

curl -s -A "Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/W.X.Y.Z Mobile Safari/537.36 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" "$URL" > mobile.html

curl -s -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" "$URL" > desktop.html

diff mobile.html desktop.html

Esegui questo prima/dopo una riprogettazione per individuare contenuti, dati strutturati o tag noindex che esistono solo su una versione. Nota: questo recupera l’HTML grezzo — se il tuo contenuto è iniettato da JavaScript lato client, abbinalo a uno strumento di rendering (o al Render Gap del sito) piuttosto che affidarti solo a curl.

Stessa verifica in PowerShell (Windows)

$url = "https://example.com/your-page/"
$mobileUA = "Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/W.X.Y.Z Mobile Safari/537.36 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
$desktopUA = "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"

Invoke-WebRequest -Uri $url -UserAgent $mobileUA -OutFile mobile.html
Invoke-WebRequest -Uri $url -UserAgent $desktopUA -OutFile desktop.html

Compare-Object (Get-Content mobile.html) (Get-Content desktop.html)

Regex: estrai i tag meta robots dall’HTML salvato

Verifica se le direttive robots mobile e desktop corrispondono, una volta salvate entrambe le versioni con gli snippet curl/PowerShell sopra.

<meta\s+name=["']robots["']\s+content=["']([^"']+)["']

Il gruppo di acquisizione 1 è la stringa della direttiva (es. index, follow o noindex). Esegui questo contro mobile.html e desktop.html separatamente e confronta i valori acquisiti — una discrepanza è un rischio di deindicizzazione accidentale.

Console DevTools: elenca immagini + testo alt nella pagina corrente

Incolla nel pannello Console (F12 → Console) mentre visualizzi il rendering mobile (usa la barra degli strumenti dispositivo di DevTools per simulare un telefono) per individuare immagini senza testo alt.

[...document.querySelectorAll('img')].map(img => ({
  src: img.currentSrc || img.src,
  alt: img.alt || '(missing alt)'
}));

Bookmarklet: vai direttamente a URL Inspection per la pagina corrente

Trascina questo nella barra dei segnalibri; cliccandolo su una qualsiasi delle tue pagine apre URL Inspection di Search Console per quell’URL esatto, dove puoi controllare “Crawled as”.

javascript:(function(){window.open('https://search.google.com/search-console/inspect?resource_id=&id='+encodeURIComponent(location.href));})();

Dovrai scegliere la proprietà giusta in Search Console dopo che si apre (il bookmarklet non trasporta il tuo ID proprietà/risorsa).

Test di validazione

Prova che una correzione di parità mobile-first ha effettivamente avuto effetto, non solo che hai fatto la modifica.

Conferma che Google sta indicizzando la pagina come mobile

Test da eseguire: Search Console → URL Inspection, inserisci l’URL, controlla il campo “Crawled as” sulla versione live/indicizzata.

Risultato atteso: “Crawled as: Googlebot smartphone.”

Interpretazione del fallimento: Se mostra “Googlebot desktop” per una pagina normale, l’URL è una delle rare eccezioni che Google indicizza con desktop (o la pagina non è stata ancora ri-indicizzata dopo la tua correzione) — richiedi l’indicizzazione per forzare una nuova verifica.

Finestra di monitoraggio: Immediata una volta che URL Inspection restituisce un risultato; concedi qualche giorno se hai appena richiesto l’indicizzazione.

Trigger di rollback: N/D — questa è una diagnostica di sola lettura, non una modifica da annullare.

Conferma che i dati strutturati sono arrivati nell’HTML mobile

Test da eseguire: Esegui l’URL renderizzato mobile attraverso il Schema Validator (o il report Rich Results di Search Console per la proprietà).

Risultato atteso: Gli stessi tipi e campi di dati strutturati che hai aggiunto al desktop appaiono nell’output renderizzato mobile, senza errori di parsing.

Interpretazione del fallimento: Markup mancante o con errori significa che il JSON-LD è stato inviato solo nel template desktop, o un bug di templating lo ha eliminato su mobile.

Finestra di monitoraggio: Immediata per la verifica del validatore; 1–2 settimane per il rich result corrispondente per riapparire in Search Console/risultati live.

Trigger di rollback: Se la modifica al template mobile ha causato una rottura più ampia del rendering (layout, altro markup), annulla la modifica al template e rifai il diff.

Conferma che non ci sia noindex errato nel template mobile

Test da eseguire: Recupera l’HTML renderizzato mobile (curl con user-agent Googlebot smartphone, o “Visualizza pagina indicizzata” di Search Console) e controlla il tag <meta name="robots">; in alternativa usa l’HTTP Status Checker del sito per confermare che la pagina stessa restituisca 200 piuttosto che essere bloccata.

Risultato atteso: index, follow (o assente, che per impostazione predefinita è indicizzabile) sia su mobile che su desktop.

Interpretazione del fallimento: Un noindex presente solo su mobile significa che Google deindicizzerà la pagina anche se la versione desktop sembra a posto — questa è la causa accidentale di deindicizzazione più comune sui siti mobile-first.

Finestra di monitoraggio: Immediata per il controllo del tag; 1–4 settimane perché la pagina riappaia nel report di copertura di Search Console se era già stata rimossa.

Trigger di rollback: Se la rimozione del tag è stata essa stessa un errore (la pagina doveva rimanere noindexed), riaggiungilo e riverifica.

Conferma che il contenuto troncato/caricato lazy è ora indicizzabile

Test da eseguire: Con JavaScript abilitato e senza interagire con la pagina (nessun clic, tocco o swipe), visualizza l’HTML iniziale renderizzato — “View Crawled Page” di Search Console è la proxy più vicina a ciò che Googlebot vede realmente.

Risultato atteso: Il contenuto primario in questione è presente in quell’HTML renderizzato senza alcuna interazione.

Interpretazione del fallimento: Se il contenuto appare solo dopo che clicchi/tocchi/scorri per rivelarlo, Googlebot non lo vedrà ancora — la correzione (caricare allo scroll o nell’HTML iniziale) non ha ancora avuto effetto.

Finestra di monitoraggio: Immediata per il controllo del rendering; 2–4 settimane perché il contenuto compaia nella copertura dell’indice di Search Console o nei risultati di ricerca site:.

Trigger di rollback: Se lo spostamento del comportamento di caricamento ha rotto l’UX o le prestazioni della pagina, ripristina e trova un approccio di caricamento allo scroll invece di uno basato sull’interazione.

Mettiti alla prova: indicizzazione mobile-first

Cinque domande rapide sull’indicizzazione mobile-first. Scegli una risposta per ciascuna, poi controlla.

Cronologia modifiche