Test d'optimisation mobile : comment vérifier votre site maintenant que l'outil de Google a disparu

En bref : Google a retiré son test d'optimisation mobile (Mobile-Friendly Test), l'API Mobile-Friendly Test et le rapport Mobile Usability de la Search Console le 1er décembre 2023. Le mobile n'est pas devenu moins important : Google explore et indexe les sites uniquement avec son robot smartphone, et un contenu inaccessible sur téléphone n'est pas indexable. Pour tester un site aujourd'hui, vérifiez les bases (balise viewport, images qui s'adaptent, texte lisible, zones tactiles) avec un outil de vérification rapide et Lighthouse, regardez la page sur de vrais téléphones et confirmez que la version mobile contient le même contenu que le bureau.

Pendant des années, « test d'optimisation mobile » voulait dire une seule chose : coller une URL dans l'outil de Google et obtenir la bannière verte « La page est adaptée aux mobiles ». Cet outil n'existe plus, et de nombreux guides y renvoient encore. Cet article explique ce qui s'est passé, ce que Google attend aujourd'hui des pages mobiles, comment les tester avec des outils qui fonctionnent encore, dont notre test d'optimisation mobile gratuit, et comment corriger chaque problème.

Ce qui est arrivé au Mobile-Friendly Test de Google

Dans un article d'avril 2023 sur l'expérience de page, Google a annoncé : « Also starting December 1, 2023, we'll be retiring Search Console's 'Mobile Usability' report, the Mobile-Friendly Test tool and Mobile-Friendly Test API. » La raison invoquée n'était pas que le mobile cessait d'compter. Google notait que de nombreuses ressources solides pour évaluer l'ergonomie mobile étaient apparues, « including Lighthouse from Chrome ».

Depuis décembre 2023, il n'existe donc plus de verdict officiel de Google (réussite ou échec) sur l'adaptation au mobile. Les outils tiers, Lighthouse et vos propres tests comblent ce vide.

Pourquoi le mobile décide toujours de la façon dont vous êtes indexé

Deux annonces comptent plus que l'outil retiré :

1. L'indexation mobile d'abord (mobile-first indexing) est terminée. En octobre 2023, Google a écrit que « the trek to Mobile First Indexing is now complete » (annonce). Sa page de bonnes pratiques définit ce que cela signifie : « Google uses the mobile version of a site's content, crawled with the smartphone agent, for indexing and ranking. »
2. L'exploration desktop a pris fin pour la Recherche. En juin 2024, Google a déclaré : « After July 5, 2024, we'll crawl and index these sites with only Googlebot Smartphone », et « If your site's content is not accessible at all with a mobile device, it will no longer be indexable » (annonce).

Conséquence pratique : ce que votre version mobile affiche est votre page aux yeux de Google. Un texte masqué sur mobile, une section manquante ou un titre différent dans le modèle mobile, voilà ce qui est indexé.

L'expérience de page ajoute une seconde couche. Les recommandations de Google sur l'expérience de page demandent « Does your content display well on mobile devices? » et affirment que ses systèmes de classement principaux « look to reward content that provides a good page experience », tout en soulignant qu'il n'existe pas de signal unique d'expérience de page.

Ce que « mobile-friendly » signifie concrètement

Il n'y a plus de liste de contrôle officielle, mais la documentation de Google et web.dev couvrent l'essentiel :

Google recommande le design web adaptatif (responsive) « because it's the easiest design pattern to implement and maintain ». Une seule URL, un seul document HTML, des CSS qui s'adaptent : les problèmes de parité disparaissent en grande partie.

Comment tester l'adaptation au mobile aujourd'hui

Utilisez plusieurs outils, car chacun voit une partie différente du tableau :

1. Une vérification rapide des bases. Notre test d'optimisation mobile gratuit contrôle la balise viewport, les images responsives, le favicon et la langue de la page en environ 20 secondes (détails ci-dessous).
2. Lighthouse dans Chrome. Lancez-le depuis DevTools avec le paramètre mobile. Depuis Lighthouse 13 (octobre 2025), la vérification du viewport se trouve dans l'insight « Optimize viewport for mobile », et l'ancien audit de lisibilité de la taille de police a été supprimé sans remplacement.
3. Le mode appareil de Chrome DevTools. Faites glisser la largeur à partir de 320 px et repérez les barres de défilement horizontales, les éléments qui se chevauchent et le texte qui déborde de son bloc.
4. De vrais téléphones. Utilisez au moins un petit téléphone Android et un iPhone. Essayez le menu, les formulaires et le paiement avec votre pouce.
5. Inspection d'URL de la Search Console. Le test en direct affiche une capture d'écran de la page telle que Googlebot Smartphone la rend, ainsi que le HTML rendu, ce qui permet de confirmer que le contenu qui vous importe est bien là.
6. Données de vitesse en conditions réelles. Les Core Web Vitals des visiteurs sur téléphone, issus du Chrome User Experience Report. Notre guide des Core Web Vitals explique comment les lire.

Comment fonctionne le test d'optimisation mobile de Searvia

Le test d'optimisation mobile gratuit lance notre audit complet de site (38 contrôles) et place les quatre contrôles mobiles en haut. Saisissez un domaine ou l'adresse d'une page : l'outil récupère cette page (la page d'accueil si vous ne saisissez qu'un domaine), en suivant les redirections, et lit le HTML envoyé par votre serveur sans exécuter JavaScript.

Quelques précisions sur la façon de juger :

• Le contrôle du viewport est en échec et non en simple avertissement, car une page sans balise viewport est cassée sur tous les téléphones, pas seulement un peu moins bonne.
• Pour les favicons, le repli sur /favicon.ico ne compte que s'il renvoie un vrai fichier, et non une page d'erreur HTML.
• Le contrôle de la langue affiche les deux premières lettres du code : en-GB apparaît donc comme « en ».

Le rapport complet comprend aussi la section vitesse, où le contrôle des Core Web Vitals lit les LCP, INP et CLS au 75e percentile pour les visiteurs sur téléphone, à partir des données réelles de Chrome : pour la page saisie lorsque Chrome dispose de suffisamment de données, sinon pour l'ensemble du site.

Ce qu'il ne fait pas : il n'affiche pas la page dans un navigateur de la taille d'un téléphone, donc il ne peut pas voir le débordement horizontal, les tailles de police, l'espacement des zones tactiles ou les pop-ups. C'est le rôle de Lighthouse, du mode appareil et des vrais téléphones. Voyez l'outil de vérification comme un triage de cinq minutes, et les tests manuels comme l'inspection.

Comment lire les résultats

• Viewport en échec : corrigez-le en premier ; rien d'autre sur la page n'a d'importance tant que la mise en page ne tient pas dans l'écran.
• Avertissement sur les images responsives : les téléphones téléchargent des images de taille desktop. Ce n'est pas cassé, mais c'est plus lent, surtout sur les réseaux mobiles.
• Avertissements favicon ou langue : de petites corrections rapides qui améliorent votre apparence dans les résultats Google et la façon dont les lecteurs d'écran traitent la page.
• « Too few images to judge » : neutre. Avec moins de trois images, la proportion n'est pas significative.

Comment corriger chaque problème

« The page has no mobile viewport tag. »

1. Ajoutez cette ligne dans le <head> de chaque modèle :

<meta name="viewport" content="width=device-width, initial-scale=1">

1. N'ajoutez pas user-scalable=no ni une valeur faible de maximum-scale. web.dev les déconseille « because they can prevent the user from zooming ».
2. Vérifiez qu'il n'y a qu'une seule balise viewport. Un thème et un plugin peuvent chacun en imprimer une ; la seconde peut remplacer la première.
3. Rechargez sur un téléphone. Si la page affiche maintenant une mise en page desktop serrée au lieu d'une mise en page minuscule, le viewport fonctionne et le CSS a besoin de règles responsives (voir ci-dessous).

Rendre la mise en page adaptative

Une balise viewport indique seulement au navigateur d'utiliser la largeur de l'écran. Le CSS doit encore s'adapter :

• Donnez aux images et aux vidéos max-width: 100%; height: auto; pour qu'elles ne débordent jamais.
• Utilisez des largeurs flexibles (pourcentages, fr, min()) plutôt que des largeurs fixes en pixels pour les conteneurs.
• Ajoutez des media queries là où le design casse, et non à des largeurs d'appareils précises. web.dev : « Design the content to fit on a small screen size first, then expand the screen until a breakpoint becomes necessary. »
• Placez les tableaux larges dans un conteneur défilant plutôt que de laisser la page défiler latéralement.

« N of M images use srcset. »

Proposez plusieurs tailles et laissez le navigateur choisir, comme décrit sur MDN :

<img
  src="/img/boots-800.jpg"
  srcset="/img/boots-480.jpg 480w, /img/boots-800.jpg 800w, /img/boots-1600.jpg 1600w"
  sizes="(max-width: 600px) 100vw, 50vw"
  alt="Brown leather hiking boots on a wet rock"
  width="800" height="600">

srcset liste les fichiers et leurs largeurs ; sizes indique au navigateur la largeur que l'image aura à l'écran. Pour les images de taille fixe comme les logos, utilisez des descripteurs x (logo.png, logo@2x.png 2x). WordPress ajoute automatiquement srcset aux images insérées via l'éditeur ; la plupart des CDN d'images peuvent générer les tailles pour vous. Ajoutez aussi width et height, afin que le navigateur réserve l'espace et que la mise en page ne saute pas.

« No favicon was found. »

1. Créez une icône carrée. Google exige un ratio 1:1, d'au moins 8 × 8 px, et recommande plus de 48 × 48 px (consignes sur les favicons).
2. Ajoutez-la dans le head de la page d'accueil :

<link rel="icon" href="/favicon.ico" sizes="48x48">
<link rel="icon" href="/favicon.svg" type="image/svg+xml">
<link rel="apple-touch-icon" href="/apple-touch-icon.png">

1. Gardez l'URL stable et assurez-vous que le fichier robots.txt ne bloque pas le fichier ; Google doit pouvoir explorer à la fois la page d'accueil et l'icône. Google prend en charge un favicon par nom d'hôte.

« The page does not declare its language. »

Définissez la langue sur l'élément racine :

<html lang="fr">

Utilisez un code BCP 47 valide tel que en, en-GB, pt-BR ou tr. L'attribut lang permet aux lecteurs d'écran de prononcer correctement le texte et il est requis par le critère « Language of Page » des WCAG (MDN). Une précision : Google indique détecter la langue d'une page à partir du texte lui-même, et non de lang, il s'agit donc d'une correction d'accessibilité et de navigateur plus que de classement.

Au-delà des quatre contrôles

Une fois les bases validées, passez en revue les points qu'aucun outil automatique ne couvre entièrement :

• Parité du contenu. Comparez mobile et desktop pour une même URL : texte principal, titres, images avec le même texte alternatif, données structurées, balise title, meta description et balises meta robots. Google les énumère toutes dans ses bonnes pratiques pour l'indexation mobile d'abord.
• Chargement différé (lazy loading). Google prévient : « Don't lazy-load primary content upon user interaction. » Googlebot ne clique pas sur « Lire la suite » et ne fait pas défiler les carrousels.
• Zones tactiles. Des boutons et liens d'environ 48 × 48 px avec de l'espace entre eux. Lighthouse signale les cibles de moins de 48 × 48 px lorsqu'elles chevauchent leurs voisines.
• Taille du texte. Un texte courant lisible sans zoom. Lighthouse n'audite plus la taille de police : vérifiez donc sur un vrai téléphone.
• Pop-ups. Les bannières de cookies et formulaires de newsletter qui couvrent le contenu sur un petit écran relèvent de la question des interstitiels intrusifs de Google.
• Vitesse sur téléphone. Les processeurs et réseaux des téléphones sont plus lents ; consultez les données de terrain mobile séparément du desktop.

Si vous gérez un site mobile séparé

Certains sites anciens servent les téléphones depuis une adresse différente, comme m.example.com, ou envoient un HTML différent aux téléphones depuis la même URL (diffusion dynamique). Google prend toujours en charge les deux, mais ils compliquent la parité, et ses bonnes pratiques ajoutent des règles supplémentaires pour les URL séparées :

• Le statut d'erreur doit être le même sur les deux versions : une page qui renvoie 404 sur desktop ne doit pas renvoyer 200 sur mobile, et inversement.
• La version mobile ne doit pas utiliser de fragments d'URL (#) pour le contenu.
• Les règles robots.txt doivent correspondre, afin que Googlebot puisse explorer les mêmes sections sur les deux hôtes.
• Les pages desktop pointent vers leurs versions mobiles avec rel="alternate", et les pages mobiles renvoient vers elles avec rel="canonical".
• hreflang doit être configuré séparément pour chaque version.

Si vous prévoyez de toute façon une refonte, passer à un design responsive sur une seule URL supprime toute cette catégorie de problèmes. Notre outil gratuit lit la version que votre serveur envoie à son propre robot ; sur un site en diffusion dynamique, testez donc séparément la version téléphone avec Lighthouse ou l'inspection d'URL.

Exemple pratique (hypothétique)

L'exemple suivant est hypothétique, ce ne sont pas des données réelles. Cobble & Crumb, une boulangerie inventée dotée d'un site codé à la main en 2016, voit la plupart de ses visites arriver depuis des téléphones et peu de commandes suivre. Le test d'optimisation mobile indique :

• Viewport mobile, échec : aucune balise viewport.
• Images responsives : 1 image sur 14 utilise srcset.
• Favicon : réussi.
• Langue de la page, avertissement : pas d'attribut lang.

Le propriétaire ajoute la balise viewport et lang="en", puis ouvre le site sur un téléphone : le texte est désormais à taille normale, mais le conteneur de 960 px de large fixe force un défilement latéral. Un développeur remplace la largeur fixe par max-width: 960px; width: 100%, ajoute max-width: 100% aux images, empile le menu de trois colonnes en une seule colonne sous 600 px et agrandit les boutons de commande à 48 px de haut. Les photos de produits reçoivent un srcset avec des versions de 480, 800 et 1600 px. Un second passage valide le viewport et la langue, les images responsives passent désormais avec 13 sur 14, et l'insight viewport de Lighthouse est propre. Il reste le travail sur le contenu : la mise en page mobile avait masqué les horaires d'ouverture, qui sont remis sur la page.

Une checklist mobile de 30 minutes

1. Lancez le test d'optimisation mobile et corrigez d'abord une balise viewport manquante.
2. Ouvrez vos cinq pages principales sur un vrai téléphone. Cherchez le défilement latéral, le texte minuscule et les boutons difficiles à toucher.
3. Lancez Lighthouse en mode mobile sur les mêmes pages.
4. Comparez le contenu mobile et desktop pour chaque modèle de page.
5. Ajoutez srcset aux grandes images, un favicon et l'attribut lang.
6. Vérifiez les Core Web Vitals sur téléphone et corrigez le modèle le plus lent.

Comment Searvia vous aide à rester prêt pour le mobile

Le test d'optimisation mobile gratuit vérifie les bases sur votre page d'accueil, ou sur toute page que vous saisissez, en environ 20 secondes, sans inscription, avec 34 autres contrôles couvrant l'apparence dans la recherche, l'exploration, la préparation à la recherche IA, la vitesse et la sécurité.

Pour un suivi continu, un compte Searvia gratuit ajoute le suivi de la vitesse des pages : scores de laboratoire et données réelles d'utilisateurs Chrome pour vos pages les plus visitées, revérifiés chaque semaine, avec des corrections classées par temps estimé gagné. L'audit de site explore chaque page à la recherche des problèmes qui nuisent autant au mobile qu'au desktop, comme les titres manquants, les liens cassés et le contenu pauvre. Pour le reste de la checklist technique, consultez notre guide d'audit SEO technique.