Depuis juillet 2024, Google n’indexe plus que la version mobile des sites web. Un contenu visible uniquement sur desktop, un lien interne absent du rendu mobile ou des données structurées non chargées sur smartphone peuvent disparaître de l’index. L’optimisation mobile ne conditionne plus seulement l’expérience utilisateur, elle détermine ce que Google voit de votre site.
Mobile-only indexing : ce que Google ignore depuis juillet 2024
La distinction entre « mobile-first » et « mobile-only » change la donne pour le référencement. Avant juillet 2024, Google privilégiait la version mobile mais conservait la version desktop comme filet de sécurité. Ce filet n’existe plus.
Concrètement, un maillage interne visible uniquement sur desktop n’est plus indexé. Si votre menu de navigation masque des liens sur mobile pour « alléger l’interface », ces pages perdent leur jus SEO. Le même principe s’applique aux données structurées : un balisage Schema injecté uniquement dans le template desktop ne génère plus de résultats enrichis.
Le piège le plus fréquent concerne les contenus conditionnels. Certains CMS chargent des blocs de texte, des tableaux ou des FAQ uniquement au-delà d’une certaine largeur d’écran. Ces contenus sont devenus invisibles pour l’indexation. Un audit régulier via l’outil d’inspection d’URL de la Google Search Console, en mode mobile, permet de vérifier ce que le robot perçoit réellement.
Core Web Vitals sur mobile : les métriques qui pèsent dans le classement
La Core Update de mars 2026 a renforcé le poids des performances mobiles dans l’algorithme de classement. Deux métriques concentrent l’attention : le LCP (Largest Contentful Paint) et l’INP (Interaction to Next Paint).
| Métrique | Ce qu’elle mesure | Seuil acceptable (Google) | Impact SEO observé post-mars 2026 |
|---|---|---|---|
| LCP | Temps d’affichage du plus grand élément visible | Moins de 2,5 secondes | Les sites dépassant ce seuil sur mobile ont perdu des positions au profit de concurrents plus rapides, sans changement de contenu |
| INP | Réactivité aux interactions utilisateur (remplace FID depuis mars 2024) | Moins de 200 ms | Signal critique : un INP dégradé sur mobile corrèle avec des baisses de classement mesurées après la Core Update |
| CLS | Stabilité visuelle (décalages de mise en page) | Moins de 0,1 | Moins déterminant que LCP et INP, mais reste un facteur de qualité page |
L’INP est le signal le plus sous-estimé côté mobile. Contrairement au LCP qui dépend surtout du serveur et des images, l’INP reflète la lourdeur du JavaScript exécuté après le chargement initial. Un carrousel qui met 400 ms à répondre au swipe, un menu hamburger qui gèle 300 ms avant de s’ouvrir : ces micro-latences dégradent l’INP sans que l’utilisateur identifie le problème consciemment.
LCP mobile : les leviers concrets
Le LCP sur mobile dépend de trois facteurs principaux : le temps de réponse serveur (TTFB), le poids de l’image principale et le temps de rendu CSS. Sur mobile, la bande passante fluctue. Un LCP correct en Wi-Fi peut exploser en 4G.
- Servir les images au format WebP ou AVIF avec des attributs
srcsetadaptés aux petits écrans, pour éviter de charger une image desktop de plusieurs mégaoctets sur un smartphone - Précharger l’image LCP via
<link rel="preload">pour qu’elle soit prioritaire dans la file de téléchargement du navigateur - Réduire le CSS bloquant en extrayant le CSS critique (above-the-fold) et en différant le reste, ce qui accélère le premier rendu
INP mobile : réduire la dette JavaScript
L’INP se dégrade quand le thread principal du navigateur est occupé par du JavaScript au moment où l’utilisateur interagit. Sur mobile, les processeurs sont moins puissants qu’un desktop, ce qui amplifie le problème.
Différer ou supprimer les scripts tiers non critiques (trackers, widgets de chat, A/B testing) améliore l’INP de façon mesurable. Auditer les scripts chargés sur mobile via l’onglet Performance de Chrome DevTools permet d’identifier ceux qui bloquent le thread principal pendant plus de 50 ms.
Responsive design et SEO mobile : les erreurs techniques persistantes
Le design responsive reste la configuration recommandée par Google pour servir du contenu mobile. En revanche, un site responsive n’est pas automatiquement un site optimisé pour le mobile.
Les boutons trop proches restent la première cause de frustration sur mobile. Google recommande une zone de clic minimale de 48 pixels CSS avec un espacement suffisant entre les éléments interactifs. Un formulaire de contact dont les champs et boutons se chevauchent sur un écran de 375 pixels de large génère des erreurs de saisie et des rebonds.
La viewport meta tag (<meta name="viewport" content="width=device-width, initial-scale=1">) semble basique, mais son absence ou sa mauvaise configuration provoque un rendu desktop réduit sur mobile. Google Search Console signale ce problème dans le rapport « Ergonomie mobile ».
Les polices constituent un autre angle mort. Une taille de texte inférieure à 16 pixels sur mobile force le navigateur à zoomer, ce qui décale la mise en page et dégrade le CLS. Utiliser une taille de base de 16 pixels minimum évite le zoom automatique sur iOS.
Audit mobile : les outils et la fréquence adaptée
Un audit ponctuel ne suffit pas. Les Core Web Vitals sont des données de terrain (field data) collectées sur 28 jours glissants via le Chrome User Experience Report. Une dégradation de performance peut mettre quatre semaines à apparaître dans les données, et autant à se corriger après intervention.
- Google Search Console (rapport « Expérience sur la page ») : donne les métriques réelles des utilisateurs mobiles, segmentées par groupes d’URL
- PageSpeed Insights : combine données de terrain et données de laboratoire, utile pour diagnostiquer les causes d’un LCP ou INP dégradé
- Chrome DevTools en mode mobile : permet de simuler un processeur bridé et une connexion 3G/4G pour reproduire les conditions réelles d’utilisation
- L’outil d’inspection d’URL (Search Console) : vérifie ce que Googlebot mobile voit réellement, contenu et liens inclus
Tester sur de vrais appareils reste plus fiable qu’un émulateur. Les performances simulées dans un navigateur desktop ne reproduisent pas les contraintes mémoire et processeur d’un smartphone milieu de gamme, qui représente la majorité du parc.
L’optimisation mobile repose sur un principe simple : ce que Googlebot mobile ne voit pas n’existe pas pour le classement. Depuis la bascule vers le mobile-only indexing et le renforcement des Core Web Vitals dans l’algorithme en mars 2026, la performance technique sur smartphone conditionne directement le positionnement dans les résultats de recherche.
