Google explore et indexe désormais exclusivement la version mobile d’un site. Ce n’est plus un signal parmi d’autres : la version mobile est la seule version indexée. Toute divergence entre le rendu desktop et le rendu mobile crée un angle mort pour le robot d’exploration, et donc pour le classement.
INP remplace FID : ce que ce changement implique pour l’indexation mobile
Depuis mars 2024, Google a remplacé le First Input Delay (FID) par Interaction to Next Paint (INP) comme Core Web Vital. La différence technique est significative : FID ne mesurait que la latence de la première interaction utilisateur, tandis qu’INP couvre l’ensemble des interactions sur la durée d’une session.
Pour un site mobile, cela signifie qu’un menu déroulant lent en milieu de page ou un formulaire de contact qui bloque le thread principal pénalise désormais le score global. Le seuil « satisfaisant » est fixé sous 200 ms, mesuré au 75e percentile des visites mobiles réelles.
Nous observons que beaucoup de sites passaient les anciens critères FID sans difficulté, mais échouent sur INP. Un carrousel JavaScript lourd, un accordion qui recalcule le layout à chaque clic, un champ d’autocomplétion mal optimisé : autant d’éléments qui n’affectaient pas FID mais qui dégradent INP. L’audit de réactivité mobile ne peut plus se limiter au chargement initial.
Core Web Vitals mobiles : les trois seuils à respecter
- LCP (Largest Contentful Paint) sous 2,5 secondes : le plus grand élément visible du viewport mobile doit s’afficher rapidement. Les images non dimensionnées ou les polices web bloquantes sont les causes les plus fréquentes de dépassement.
- INP sous 200 ms : toute interaction (tap, scroll dans un composant, saisie) doit produire un retour visuel dans ce délai. Les event listeners JavaScript lourds sur mobile sont la première source de blocage.
- CLS (Cumulative Layout Shift) sous 0,1 : les décalages de mise en page, souvent provoqués par des publicités ou des images sans attributs width/height, pénalisent d’autant plus sur mobile où le viewport est étroit.
Ces trois métriques sont évaluées exclusivement sur la version mobile dans le cadre de l’indexation orientée mobile. Un site avec d’excellents scores desktop mais des Core Web Vitals dégradés sur mobile subit un désavantage actif de classement.
Parité de contenu mobile-desktop : le piège d’indexation le plus sous-estimé
L’indexation orientée mobile repose sur un principe strict : si un élément n’existe pas sur la version mobile, Google ne le voit pas. Nous recommandons de traiter la parité de contenu comme un audit technique à part entière, distinct de l’audit responsive classique.
Les cas de divergence les plus fréquents ne sont pas les blocs de texte masqués. Ce sont les données structurées, les liens internes et les métadonnées. Un balisage Schema.org présent uniquement dans le template desktop, un maillage interne généré par une sidebar absente sur mobile, des balises meta différentes selon le user-agent : chacun de ces écarts crée une perte d’information pour le robot mobile de Google.
Éléments à auditer en priorité
Le contenu principal (texte, headings, images avec attributs alt) doit être strictement identique entre les deux versions. Mais au-delà du contenu visible, les données structurées doivent figurer dans le DOM mobile. Un fil d’Ariane en Schema.org rendu uniquement côté desktop disparaît de l’index.
Les images méritent une attention particulière. Une image en lazy loading agressif sur mobile, qui ne se charge que bien au-delà du viewport, peut ne jamais être vue par le crawler. Le robot de Google exécute JavaScript, mais avec des limites de rendu. Une image conditionnée à un scroll profond risque de ne pas être indexée.
Responsive design et configurations alternatives : impact réel sur le crawl budget
Google documente trois configurations pour la compatibilité mobile : responsive design, diffusion dynamique (dynamic serving) et URLs mobiles séparées. En pratique, le responsive design reste la configuration la plus fiable pour l’indexation, parce qu’elle élimine le risque de désynchronisation entre deux versions.
La diffusion dynamique, où le serveur envoie un HTML différent selon le user-agent, fonctionne à condition que l’en-tête HTTP Vary soit correctement configuré. Sans cette indication, le cache de Google peut servir la mauvaise version à l’indexation. C’est un défaut silencieux : aucun message d’erreur dans la Search Console, mais une indexation partielle.
Les URLs mobiles séparées (m.example.com) posent un problème de crawl budget. Google doit explorer deux ensembles d’URLs, et les balises canonical/alternate entre les deux versions doivent être symétriques. Une erreur courante consiste à pointer le canonical mobile vers la page desktop sans que la page desktop contienne la balise alternate correspondante. Le résultat : Google ignore la version mobile ou, dans certains cas, désindexe des pages.
Vitesse de chargement mobile et signaux d’expérience page
La vitesse de chargement sur mobile n’agit pas uniquement comme signal de classement direct. Elle conditionne aussi la capacité du crawler à explorer un volume suffisant de pages dans le temps alloué. Un site dont les pages mobiles mettent plusieurs secondes à répondre verra son crawl budget consommé plus rapidement, avec moins de pages explorées par session.
Les leviers techniques prioritaires restent la compression des ressources (images en format WebP ou AVIF, minification CSS/JS), la mise en cache côté serveur, et la réduction des chaînes de redirections. Sur mobile, chaque redirection ajoute une latence perceptible sur les connexions cellulaires, et le crawler de Google la subit aussi.
Un point souvent négligé : les éléments tiers. Les scripts de tracking, les widgets de chat, les pixels publicitaires chargés de manière synchrone sur mobile peuvent bloquer le rendu et dégrader à la fois le LCP et l’INP. Nous recommandons de charger ces ressources en asynchrone ou de les différer après l’événement DOMContentLoaded.
La compatibilité mobile, au sens où Google l’entend en 2026, dépasse largement le simple test « mobile-friendly ». Elle englobe la réactivité mesurée par INP, la parité complète des signaux entre versions, et la performance de crawl. Un site techniquement responsive mais lent, incomplet côté données structurées ou mal configuré en canonical ne tire aucun bénéfice de son adaptabilité visuelle. L’indexation mobile récompense la rigueur technique, pas l’apparence.
