Comment vérifier l’adaptation mobile après l’arrêt de google mobile friendly test ?

Google a arrêté en décembre 2023 google mobile friendly test ainsi que le rapport « Ergonomie mobile » dans Search Console. La disparition du point d’accès qui permettait auparavant de « tester une fois et déterminer si un site est adapté aux mobiles » ne signifie pas que l’adaptation aux appareils mobiles n’influence plus l’indexation et le classement ; Google utilise toujours principalement Smartphone Googlebot pour explorer les pages web et se base sur le contenu mobile pour l’indexation et l’évaluation.

Ce qui doit réellement être remplacé n’est pas un indicateur vert « Réussi », mais trois types de vérifications : Google peut-il explorer et afficher la page mobile ; les utilisateurs peuvent-ils l’utiliser normalement sur un véritable réseau mobile ; la vitesse et la stabilité de la mise en page nuisent-elles à l’expérience. Aucun outil unique ne peut couvrir ces trois aspects ; l’approche la plus fiable consiste à combiner l’inspection d’URL, PageSpeed Insights et des vérifications sur appareils réels.

Commencez par l’inspection d’URL pour confirmer : la page vue par Google est-elle correcte ?

Dans « Inspection de l’URL » de Google Search Console, saisissez l’URL complète et consultez en priorité la version indexée. Il ne s’agit pas de vérifier si la page s’ouvre sur votre propre ordinateur, mais si la page récemment explorée par Google peut être indexée, si la page canonique attendue a été sélectionnée et si l’exploration utilise Smartphone Googlebot.

Si la page vient d’être modifiée et n’a pas encore été réexplorée, ou si vous suspectez que le résultat lu par Google diffère de celui affiché dans le navigateur, vous pouvez utiliser « Tester l’URL en direct ». Vérifiez principalement les résultats d’exploration et de rendu : si la capture d’écran affiche des zones blanches, l’absence du contenu principal, des fenêtres pop-up masquant le contenu, un affichage désorganisé ou des erreurs, le problème ne concerne généralement pas la « taille de l’écran », mais le chargement des ressources, le rendu front-end ou des restrictions d’accès.

• Dépendance à JavaScript : si le contenu principal visible immédiatement, les paramètres produits ou le contenu de changement de langue dépendent entièrement d’un chargement asynchrone par script, il faut confirmer que Google peut effectivement accéder à ces contenus après le rendu.
• Accessibilité des ressources : si les fichiers CSS, JavaScript, le CDN d’images ou les polices sont bloqués par robots.txt, un WAF, des restrictions géographiques ou une vérification de connexion, Googlebot recevra une page incomplète.
• Cohérence du responsive design : les versions de bureau et mobile ne doivent pas perdre, en raison d’un masquage CSS, les informations essentielles sur les produits, le corps du texte, les liens internes ou les données structurées.
• Codes d’état anormaux : si l’accès mobile est redirigé par erreur, renvoie une erreur 4xx/5xx ou dirige vers une page non pertinente, l’exploration normale sera affectée.

L’inspection d’URL permet de répondre à la question « le moteur de recherche peut-il voir la page », mais ce n’est pas un outil de test de vitesse et elle ne remplace pas les tests d’utilisation. Un résultat d’inspection normal signifie uniquement que la chaîne d’indexation ne présente pas d’obstacle évident.

PageSpeed Insights permet d’identifier les problèmes de performances et de mise en page sur mobile

PageSpeed Insights (PSI) doit servir de point d’entrée pour les vérifications quotidiennes. Après avoir saisi l’URL, veillez à distinguer les « données utilisateurs réelles » des données de laboratoire Lighthouse. Les premières proviennent de l’ensemble de données sur l’expérience utilisateur Chrome répondant aux critères requis et reflètent l’expérience des visites existantes ; les secondes sont exécutées dans un environnement mobile simulé et conviennent pour localiser les problèmes de performances reproductibles sur la page actuelle.

Sur mobile, trois Core Web Vitals méritent une attention particulière : LCP reflète la vitesse d’apparition du contenu principal, INP reflète la réactivité des interactions telles que les clics, l’ouverture de menus et l’envoi de formulaires, et CLS reflète les déplacements d’éléments lors du chargement de la page. Ils ne constituent pas à eux seuls l’ensemble de l’« adaptation mobile », mais révèlent souvent des problèmes affectant les demandes de renseignements et la navigation, tels que des images volumineuses non compressées au-dessus de la ligne de flottaison, un trop grand nombre de scripts de suivi tiers, des bannières de cookies comprimant le contenu, ou des images et contenus intégrés sans dimensions réservées.

Les recommandations de diagnostic de PSI doivent être évaluées selon les fonctions réelles de la page ; il ne convient pas de rechercher mécaniquement un score parfait. Les scripts multilingues, outils de service client, validations de formulaires, cartes et vidéos courants sur les sites de commerce extérieur augmentent tous le coût de chargement. L’ordre de traitement le plus utile consiste à garantir d’abord la disponibilité du contenu essentiel au-dessus de la ligne de flottaison et du point d’entrée des demandes de renseignements, puis à compresser les images et différer les scripts non essentiels, et enfin à évaluer si les composants tiers non nécessaires doivent être supprimés.

Le mode appareil du navigateur ne sert qu’au préfiltrage ; les appareils réels restent indispensables

La barre d’outils des appareils de Chrome DevTools permet de changer rapidement la largeur d’écran, la densité de pixels et la limitation du réseau ; elle convient pour vérifier les points de rupture lors d’une refonte : la navigation se replie-t-elle correctement, les tableaux débordent-ils horizontalement, les boutons sont-ils tronqués, les coordonnées de contact fixes en bas de page masquent-elles les formulaires. Son avantage est son efficacité ; sa limite est qu’elle ne peut pas simuler complètement les navigateurs de différents systèmes, l’apparition du clavier, les fenêtres de demande d’autorisation et les fluctuations réelles du réseau.

Les pages impliquant des demandes de renseignements, des commandes ou le téléchargement de documents doivent faire l’objet d’un test complet du parcours sur les navigateurs mobiles courants : arriver depuis une page de destination de recherche, changer de langue, ouvrir les détails d’un produit, cliquer sur WhatsApp, l’e-mail ou le formulaire, puis vérifier après l’envoi que le message de confirmation et la notification par e-mail fonctionnent correctement. De nombreuses pages sont « adaptées » visuellement, mais le champ de saisie de l’indicatif pays ne peut pas ouvrir le clavier numérique, le code de vérification est masqué par un bouton flottant ou le téléversement de pièce jointe échoue ; ce type de problème ne sera pas automatiquement identifié par l’ancien mobile friendly test.

Ne confondez pas « responsive design » et « conformité mobile »

Le CSS responsive résout les problèmes d’adaptation de la mise en page aux dimensions de l’écran, mais ne résout pas automatiquement l’expérience mobile. Les risques courants incluent : de grandes images de bureau simplement réduites entraînant un chargement trop lent au-dessus de la ligne de flottaison ; des tableaux de spécifications produits difficiles à lire sur téléphone ; une hiérarchie de menus trop profonde ; de petites polices et des liens densément espacés provoquant des touches accidentelles ; des fenêtres pop-up ou publicités couvrant le contenu principal ; et la conservation d’un trop grand nombre d’animations et de vidéos en lecture automatique sur mobile.

Pour les pages dépendant du trafic naturel de Google, il convient également de vérifier que les signaux de contenu des versions mobile et bureau sont cohérents. Si, pour être plus « épurée », la version mobile supprime les modèles de produits, descriptions d’applications, FAQ, fils d’Ariane et liens vers des produits associés, les informations que Google peut lire lors de l’indexation à partir de la version mobile diminueront également. La bonne pratique n’est pas de simplement masquer les informations, mais d’améliorer la lecture par des sections repliables, une navigation par ancres, des paragraphes courts et des tableaux défilables horizontalement, tout en conservant le contenu essentiel explorable.

Intégrez les vérifications au processus de publication plutôt que de corriger après une anomalie d’indexation

Après chaque changement de thème, modification de la navigation, intégration de scripts marketing, ajout de pages multilingues ou ajustement du CDN, il convient de contrôler par sondage la page d’accueil, les pages produits principales, les pages de contenu et les pages de destination avec formulaire. Confirmez d’abord la mise en page dans le mode appareil du navigateur, utilisez ensuite PSI pour consulter les performances mobiles et les décalages de mise en page, puis effectuez enfin un test d’URL en direct dans Search Console pour les URL importantes. Si une page est déjà indexée mais que son trafic ou ses impressions sont anormaux, déterminez ensuite l’étendue du problème en combinant l’état « Indexation des pages », l’heure d’exploration et les informations sur la page canonique dans Search Console.

Après l’arrêt de google mobile friendly test, le travail de vérification passe d’un contrôle ponctuel « conforme/non conforme » à une validation continue. Pour l’exécution opérationnelle, l’essentiel n’est pas de trouver un bouton de remplacement exactement identique, mais de distinguer les trois types de problèmes que sont le rendu, les performances et le parcours de conversion : si Google ne peut pas voir la page, traitez d’abord l’exploration et les ressources ; si la page s’ouvre lentement, traitez d’abord le contenu au-dessus de la ligne de flottaison et les scripts ; si les utilisateurs ne peuvent pas effectuer l’action, revenez au parcours sur appareil réel pour corriger chaque point.