SEO mobile-first: come Google indicizza oggi (e cosa cambia per WordPress)

Mobile-first indexing è diventato l'indice predefinito di Google da fine 2020, ma lo slogan 'mobile-first' crea ancora un malinteso diffuso. Non significa 'il sito deve essere responsive'. Significa che Google usa la versione mobile del tuo sito come fonte primaria per capire contenuti, parole chiave, struttura e qualità. Se il mobile ha meno contenuti del desktop, o se è più lento, o se nasconde sezioni con CSS, Google valuta il tuo sito sulla base di ciò che vede sul mobile — non sul desktop. E la maggior parte dei siti WordPress ha un mobile peggiore del desktop, anche quando è 'responsive'.

La differenza è sottile ma decisiva. Un sito responsive adatta il layout al viewport del dispositivo. Ma mobile-first indexing riguarda i contenuti, non il layout. Se sul desktop hai una sidebar con link strategici, un widget con i contatti, una sezione FAQ estesa, e sul mobile li nascondi con display:none per pulizia visiva, Google non li vede — perché Google non esegue il display:none, lo legge nel CSS e lo ignora. Contenuti nascosti per ragioni di UX sono contenuti che non esistono, per l'indicizzazione.

I contenuti nascosti: il primo errore mobile

L'errore più comune e più costoso è nascondere contenuti sul mobile pensando che 'tanto ci sono nel DOM'. Ci sono, ma Google li ignora se sono display:none. Le accordion chiusa di default, i tab che nascondono sezioni, i menu che nascondono link importanti per il SEO, le sezioni 'leggi di più' che richiedono un click — tutti contenuti che il crawler mobile non vede. Se nascondi la tua FAQ sul mobile, per Google non esiste.

<!-- MAI: contenuto nascosto con display:none per ragioni di UX mobile -->
<div class="faq-section" style="display:none">
  <h2>Domande frequenti</h2>
  <!-- Google mobile-first non indicizza questo -->
</div>

<!-- BENE: accordion accessibile che mostra il contenuto, solo lo nasconda visivamente -->
<details class="faq-section">
  <summary>Domande frequenti</summary>
  <div class="faq-content">
    <h2>Domande frequenti</h2>
    <!-- Google vede il contenuto anche se l'accordion è chiusa -->
  </div>
</details>

Core Web Vitals: il mobile pesa doppio

I Core Web Vitals (LCP, INP, CLS) sono misurati sugli utenti reali e pesati in modo diverso per mobile e desktop. La soglia 'good' per il mobile è più severa — un LCP di 2.5 secondi è 'good' su desktop ma 'needs improvement' su mobile su alcune reti. La ragione è che il mobile ha reti più lente, CPU meno potente, e i contenuti si caricano in condizioni reali peggiori del test di laboratorio. Un sito che fa 90/100 su Lighthouse desktop può facilmente fare 60/100 sul mobile field data.

# Misura i Core Web Vitals reali dal field data di Chrome UX Report
# (tramite PageSpeed Insights API)
curl -s "https://www.googleapis.com/pagespeedonline/v5/runPagespeed?url=https://miosito.com&strategy=mobile" \
  | jq '.loadingExperience.metrics'

# Le metriche che interessano:
# - LARGEST_CONTENTFUL_PAINT_MS (LCP)
# - INTERACTION_TO_NEXT_PAINT (INP)
# - CUMULATIVE_LAYOUT_SHIFT_SCORE (CLS)

# Confronta con desktop
# Il gap tra mobile e desktop field data è il segnale più chiaro
# di un sito non ottimizzato per mobile-first

I contenuti duplicati tra mobile e desktop

Un problema meno noto ma penalizzante è il contenuto duplicato tra versioni mobile e desktop. Se hai un sito con URL separati per mobile (m.miosito.com) o se servisci contenuti diversi per user-agent, Google potrebbe vedere due versioni del tuo sito con contenuti uguali — e filtrare una delle due. La soluzione standard è usare un sito responsive con URL unici e canonical corretti, ma se hai una versione mobile separata devi assicurarti che i canonical e i redirect siano corretti:

<!-- Nel caso di URL mobile separati (m.miosito.com) -->
<!-- Desktop deve puntare al mobile -->
<link rel="alternate" media="only screen and (max-width: 640px)" 
      href="https://m.miosito.com/pagina/" />

<!-- Mobile deve puntare al desktop -->
<link rel="canonical" href="https://www.miosito.com/pagina/" />

Il JavaScript che funziona solo su desktop

L'ultimo errore subdolo è il JavaScript che funziona sul desktop ma si rompe sul mobile. Caroselli che su mobile non scrollano, menu che non si aprono, bottoni che non rispondono al tap. Il crawler mobile di Google esegue JavaScript (rendering come Chrome) e se un contenuto è generato via JS e il JS non funziona sul mobile, Google non vede quel contenuto. Non è un problema di UX, è un problema di indicizzazione.

// Test rapido: disabilita JavaScript nel browser (o usa un dispositivo reale)
// e naviga il tuo sito mobile. Se contenuti spariscono, Google non li vede.

// Per testare cosa vede il crawler:
// 1. Chrome DevTools > Rendering > Emulate CSS media > print
// 2. Disabilita JS e ricarica: cosa vedi? È quello che vede Googlebot mobile.

// Soluzione: contenuti critici NON devono dipendere da JS per essere visibili.
// Se una sezione è caricata via fetch/AJAX, renderla lato server (SSR)
// o fallback con <noscript> con contenuti equivalenti.

Mobile-first indexing non è un'allerta da aggiungere al sito, è un modo di pensare l'indicizzazione. La domanda giusta non è 'il mio sito è responsive?', ma 'se lo guardo solo dal mobile, perdo contenuti?'. Se la risposta è sì — per contenuti nascosti, per JS che non funziona, per sezioni rimosse — stai perdendo posizioni su Google nella maggior parte del tuo traffico reale. Un audit SEO tecnico che misura il field data mobile è il modo più rapido di capirlo.