Deux dates suffisent à comprendre le sujet
Deux dates ont changé le sujet. Le 4 décembre 2023, Google a retiré le test mobile-friendly et le rapport Ergonomie mobile. Le 5 juillet 2024, il a achevé le passage de tout l'index au robot smartphone. Conséquence pratique : il n'y a plus de badge à décrocher, et ce que votre version mobile ne contient pas n'existe pour personne. La priorité n'est plus l'affichage, c'est la parité de contenu.
Deux dates qui ont changé la question
Beaucoup de contenus sur le sujet, y compris récents, décrivent un monde qui n'existe plus. Voici ce qui s'est réellement passé.
| Date | Ce qui a changé | La conséquence pour vous |
|---|---|---|
| 4 décembre 2023 | Retrait du test mobile-friendly, de son API et du rapport Ergonomie mobile de la Search Console | Plus de verdict binaire. Google renvoie vers PageSpeed Insights et Lighthouse, qui mesurent au lieu de juger. |
| 12 mars 2024 | INP remplace FID parmi les signaux Web essentiels | La réactivité se mesure sur toutes les interactions, plus seulement sur la première. Le mobile est le terrain où l'écart se voit le plus. |
| 5 juillet 2024 | Fin de la bascule vers l'indexation mobile, les derniers sites encore explorés en version bureau passant au robot smartphone | Il n'existe plus une seule exception. La version mobile est la source unique de l'index. |
Ce que le retrait du test signifie exactement demande une précision, parce que les deux lectures fausses circulent. Non, mobile-friendly n'est pas devenu sans importance : Google l'a explicitement maintenu dans ses recommandations d'expérience de page. Et non, il ne reste pas un signal isolé qu'on pourrait optimiser à part : il a été absorbé dans des mesures plus larges, la performance et l'accessibilité.
Le vrai risque : la parité de contenu
C'est le poste de perte le plus coûteux du sujet, et il est invisible depuis un ordinateur. Google indexe ce que le robot smartphone reçoit. Tout ce qui n'y figure pas est perdu, y compris pour les recherches faites sur un écran large.
Les recommandations officielles se résument à quatre exigences, et chacune casse d'une façon différente.
- Le même contenu. Le texte, les titres, les images et les vidéos doivent être présents dans la version mobile. C'est le cas classique du site qui allège sa page mobile pour la rendre plus rapide et supprime en même temps la moitié de ce qui la faisait se positionner.
- Les mêmes métadonnées. Titre et méta description équivalents entre les deux versions.
- Les mêmes données structurées. Un balisage présent uniquement en version bureau ne produit plus aucun résultat enrichi.
- Un contenu réellement accessible au robot. Rien ne doit dépendre d'une action de l'utilisateur pour exister dans le HTML.
Replier n'est pas masquer. Un texte placé dans un accordéon ou un onglet est bien dans le HTML : il est indexé normalement, et cela n'a rien de pénalisant. Ce qui pose problème, c'est le contenu chargé au clic par une requête JavaScript, ou tout bonnement absent de la version mobile. La distinction est simple à vérifier : affichez le code source de la page mobile et cherchez votre texte. S'il y est, tout va bien.
Les critères qui restent, avec leurs seuils
Puisqu'il n'y a plus d'outil qui les récite, autant les avoir sous la main. Ce sont ceux que je contrôle systématiquement.
| Critère | Le seuil | Ce que je vois casser |
|---|---|---|
| Balise viewport | width=device-width, initial-scale=1 | Absente sur les vieux thèmes, ou assortie d'un maximum-scale qui interdit le zoom, ce qui est aussi un défaut d'accessibilité |
| Taille du corps de texte | 16 px minimum sur mobile | Du 13 ou 14 px hérité d'une maquette bureau, illisible sans zoom |
| Cibles tactiles | 24 × 24 px CSS au minimum selon le critère WCAG 2.2 2.5.8 (niveau AA) ; 48 × 48 px avec 8 px d'écart dans les contrôles Lighthouse | Des menus dont les entrées se touchent, et des icônes de partage collées les unes aux autres |
| Pas de défilement horizontal | Aucun élément plus large que la fenêtre | Un tableau, une image ou un bloc de code à largeur fixe. Le tableau se règle avec un conteneur en overflow-x: auto |
| Interstitiels | Rien qui masque le contenu à l'arrivée depuis la recherche | Les fenêtres de consentement mal conçues, qui recouvrent la page entière et se ferment mal au pouce |
Le Flash, qu'on lit encore dans des listes de critères, est un sujet clos depuis fin 2020, date à laquelle Adobe a arrêté le support et où les navigateurs ont retiré le lecteur. Si votre page en contient encore, le problème n'est pas mobile, il est que plus personne ne peut la lire.
Les Core Web Vitals se mesurent sur mobile
C'est là que se joue l'essentiel du travail aujourd'hui, et les valeurs de terrain qui comptent sont celles collectées sur des visiteurs mobiles, avec leurs appareils et leurs réseaux réels, pas les scores de laboratoire obtenus sur une machine de bureau.
| Métrique | Ce qu'elle mesure | Seuil « bon » | Ce qui la dégrade sur mobile |
|---|---|---|---|
| LCP | Le délai d'affichage du plus gros élément visible | 2,5 s ou moins | Une image d'en-tête non dimensionnée pour mobile, un CSS bloquant, un serveur lent. Voir PHP et le temps de réponse. |
| INP | La réactivité à l'ensemble des interactions | 200 ms ou moins | Du JavaScript qui monopolise le fil principal. Les processeurs de téléphones milieu de gamme encaissent beaucoup moins bien qu'un ordinateur. |
| CLS | Les déplacements de mise en page pendant le chargement | 0,1 ou moins | Des images sans width et height, des polices qui provoquent un ressaut, des bannières insérées après coup. |
Le passage de FID à INP le 12 mars 2024 a mécaniquement fait chuter beaucoup de sites qui étaient au vert. FID ne mesurait que le délai de la première interaction, INP prend l'ensemble et retient les plus mauvaises. Un site avec un menu ou un filtre lourd en JavaScript passait à travers l'ancien indicateur et ne passe plus. Voir les Core Web Vitals pour le détail des optimisations.
Comment tester, maintenant que l'outil n'existe plus
Quatre moyens, du plus proche de la vérité au plus commode.
- 1. L'inspection d'URL de la Search Console
C'est le seul endroit qui montre le HTML réellement reçu par le robot smartphone, avec la capture du rendu. Si votre texte n'y est pas, il n'est pas indexé, et aucune autre mesure ne compte. C'est mon premier réflexe sur un site dont les positions ont chuté après une refonte.
- 2. PageSpeed Insights, section données de terrain
Les Core Web Vitals de vos vrais visiteurs mobiles sur 28 jours, quand le site a assez de trafic. Les scores de laboratoire affichés en dessous sont utiles pour diagnostiquer, pas pour évaluer : ils viennent d'une simulation.
- 3. Lighthouse en mode mobile
Il signale les cibles tactiles trop petites, le texte trop fin, le viewport manquant et les problèmes de contraste. C'est le remplaçant fonctionnel du test retiré, en plus détaillé.
- 4. Un vrai téléphone, en 4G
Non négociable, et ce n'est pas un conseil de principe. Le mode appareil des outils de développement simule une taille d'écran, pas un processeur lent, pas une latence réseau, pas un pouce. La moitié des problèmes d'interface que je remonte à un client se voient en trente secondes sur un téléphone et sur aucun émulateur.
Les erreurs que je vois le plus souvent
Le sous-domaine mobile oublié. Les vieilles configurations avec un m. distinct sont un piège permanent : contenus qui divergent, canoniques mal posées, redirections qui envoient toutes les pages vers l'accueil mobile. Un site responsive supprime le problème plutôt qu'il ne le gère.
La version mobile allégée. Retirer du contenu pour gagner en vitesse revient à retirer ce qui vous positionne. La bonne réponse est de charger moins d'octets, pas moins de texte.
Le menu qui masque tout. Une navigation dépliante mal conçue peut recouvrir le contenu principal ou piéger le défilement. C'est aussi le premier endroit où les cibles tactiles sont trop rapprochées.
La bannière de consentement. Elle arrive avant tout le reste, elle décale la mise en page, et sa croix de fermeture fait souvent moins de 24 pixels. Elle dégrade le CLS et l'expérience du même geste.
Les images non dimensionnées. Deux attributs, width et height, suppriment l'essentiel du CLS. C'est la correction la plus rentable de toute la liste. Voir l'optimisation des images.
Questions fréquentes
Sources
- Google Search Central, indexation mobile-first : exigences de parité entre versions mobile et bureau.
- Google Search Central, « Mobile-first indexing has landed ». L'annonce de la dernière étape, publiée le 3 juin 2024, fixe au 5 juillet 2024 le passage au robot smartphone des derniers sites encore explorés en version bureau.
- web.dev, « Interaction to Next Paint becomes a Core Web Vital on March 12 » : remplacement de FID par INP le 12 mars 2024.
- W3C, WCAG 2.2, critère 2.5.8 Target Size (Minimum) : seuil de 24 × 24 pixels CSS et ses exceptions.
- Retrait du test mobile-friendly, de son API et du rapport Ergonomie mobile : annonce Google du 4 décembre 2023.