Ce que signifie réellement l’indexation mobile-first
L’indexation mobile-first est un changement fondamental dans la façon dont Google traite et classe les sites. Depuis juillet 2024, Google a rendu l’indexation mobile-first standard pour tous les sites, indépendamment du nombre d’utilisateurs mobiles qu’ils servent. Cela signifie que Google utilise principalement la version mobile de votre contenu pour indexer les pages et déterminer les classements, plutôt que la version bureau. Google explore votre site en utilisant un agent utilisateur smartphone – spécifiquement un navigateur Chrome sur mobile – et évalue ce qu’il trouve comme la version définitive pour l’indexation. Votre version bureau n’est plus la source principale. Si vous avez des versions mobiles et bureau séparées, Google regarde le mobile en premier, deuxièmement et toujours.
L’implication pratique est claire : si votre version mobile diffère de votre version bureau de manière importante – que ce soit le contenu, la structure, les métadonnées ou les fonctionnalités – Google classera probablement en fonction de ce qu’il voit sur mobile. L’un de nos clients, un torréfacteur de café spécialisé vendant de l’équipement en ligne, l’a découvert à ses dépens. Ils avaient investi des années pour construire une expérience bureau robuste avec des spécifications détaillées, des outils de comparaison et des avis clients. Cependant, leur site mobile était une version minimaliste qui supprimait la fonction de comparaison pour économiser le temps de chargement et réduisait les descriptions à un seul paragraphe. Quand Google a changé vers l’indexation mobile-first, leur visibilité de recherche a chuté rapidement en trois mois. Les classements pour leurs requêtes d’équipement de haute valeur se sont effondrés car Google classait la version mobile allégée, qui manquait de profondeur. Ils ont dû reconstruire leur expérience mobile pour la parité avec le bureau pour se rétablir.
Pourquoi Google est passé au mobile-first
La décision de Google d’adopter l’indexation mobile-first reflète la réalité de comment les gens recherchent aujourd’hui. Pour la plupart des sites, la majorité du trafic provient de périphériques mobiles. Les utilisateurs font de plus en plus de recherches sur les téléphones en se déplaçant, en faisant du shopping ou en faisant des recherches. L’utilisation du bureau reste importante pour certains démographiques et secteurs, mais en tant que part du trafic total, le mobile a dominé pendant des années. Google a reconnu que l’indexation basée sur les versions bureau créait une mauvaise correspondance entre ce que l’algorithme voyait et ce que les chercheurs expérimentaient réellement. L’entreprise a aussi remarqué que beaucoup de sites n’entretenaient pas la parité des fonctionnalités entre mobile et bureau, ce qui signifie que le contenu critique manquait des versions mobiles.
Il y a aussi une raison pratique secondaire : l’exploration mobile est beaucoup plus efficace que de maintenir des budgets d’exploration distincts pour les deux versions. Quand Google ne doit explorer que la version mobile d’un site, il peut allouer ses ressources d’exploration plus efficacement. Cela profite aux propriétaires de sites en réduisant le trafic d’exploration requis et en permettant à Google d’explorer plus profondément. Une entreprise B2B vendant des outils de gestion de projet est venue nous voir après avoir remarqué un comportement de classement incohérent sur leur site. Ils exploitaient à la fois un site responsive principal et un ancien sous-domaine m-dot qui était toujours indexé. Google explorait les deux versions séparément, ce qui signifiait que le budget d’exploration était divisé entre deux versions presque identiques. Une fois qu’ils ont consolidé tout en design responsive, leur efficacité d’exploration s’est améliorée et ils ont pu classer les nouvelles pages plus rapidement. L’architecture d’exploration simplifiée signifiait que Google pouvait dédier son budget à explorer les sections plus profondes de leur documentation.
Les trois façons de servir du contenu mobile
Le design responsive
Le design responsive est l’approche recommandée par Google et le chemin le plus sûr pour presque tous les sites. Avec le design responsive, un seul fichier HTML sert tous les appareils – bureau, tablette et mobile. La mise en page s’ajuste en fonction de la taille de l’écran en utilisant des requêtes multimédias CSS et des systèmes de grille flexibles. Le contenu, la structure HTML, les métadonnées et les fonctionnalités restent identiques quel que soit le type d’appareil. Du point de vue de Google, il n’y a pas de version mobile ou bureau – il y a simplement une version qui adapte sa présentation. Cela élimine la complexité de maintenir des URL séparées ou de servir différents flux de contenu. La documentation officielle de Google recommande spécifiquement le design responsive. Quand correctement mis en œuvre, le design responsive ne nécessite pas de balises rel=canonical spéciales, pas d’attributs rel=alternate et pas de règles de redirection. Google explore simplement l’URL unique et indexe tout ce qu’il trouve.
Un détaillant de commerce électronique vendant de l’équipement de plein air a effectué la transition vers le design responsive après avoir exécuté des URL m-dot séparées pendant cinq ans. Leur configuration initiale avait créé des années de dette technique : ils maintenaient deux basés de code complètes, deux flux de gestion de contenu distincts et deux ensembles d’analyses. Chaque fois qu’ils mettaient à jour les produits, ajoutaient des fonctionnalités ou corrigeaient des bogues, l’équipe de développement devait implémenter les modifications deux fois. Le trafic mobile représentait 68 % de leurs visiteurs totaux, mais Google regardait toujours la version bureau comme source principale. Une fois qu’ils ont migré vers un design entièrement responsive, ils ont éliminé la duplication immédiatement. Une base de code, un flux d’analysé, un seul endroit pour effectuer des modifications. Google pouvait maintenant voir exactement ce que ses visiteurs mobiles voyaient, et parce que le design était réfléchi plutôt qu’un compromis allégé, les classements se sont améliorés. Le trafic organique a augmenté en deux mois car Google pouvait enfin classer l’expérience complète qu’ils livraient aux utilisateurs réels.
Le serving dynamique
Le serving dynamique signifie que votre serveur détecte le type d’appareil et envoie du HTML différent aux navigateurs mobiles et bureau, même si les deux requêtes vont à la même URL. Le serveur utilise les informations dans la requête HTTP – généralement l’en-tête User-Agent – pour déterminer le contenu à retourner. Si un agent utilisateur pour smartphone arrive, le serveur envoie du HTML mobile. Si un agent pour bureau arrive, le serveur envoie du HTML pour bureau. Google peut explorer les deux versions si vous annotez correctement votre configuration avec des balises rel=alternate, qui indiquent à Google que les deux versions existent. Cependant, le serving dynamique est considérablement plus complexe à mettre en œuvre et à maintenir que le design responsive, et il introduit plus de possibilités d’erreurs. Vous devez vous assurer que le crawleur de Google voit la version mobile correcte, que les versions maintiennent la parité du contenu, et que vos balises rel=alternate sont correctes.
Nous avons travaillé avec une publication d’actualités qui avait choisi le serving dynamique des années auparavant et construit un système complexe autour. Leur expérience mobile était optimisée pour la livraison rapide de titres et de corps d’articles, tandis que la version bureau incluait du contenu supplémentaire de barre latérale, des widgets d’articles connexes et des mises en page publicitaires. Le problème a émergé progressivement : leur version mobile avait moins de liens internes, des balises de schéma manquantes qui n’existaient que sur le bureau, et des hiérarchies de titres différentes. Google ne pouvait pas déterminer de manière fiable quelle version faire confiance. Les classements ont commencé à fluctuer de manière incohérente, et ils ne pouvaient pas comprendre pourquoi la même requête les classerait différemment. Après audit de leur configuration, nous avons trouvé que leurs balises rel=alternate étaient incomplètes. La surcharge de maintenance du maintien de deux versions était devenue si importante que les petites incohérences étaient inévitables. Ils ont finalement décidé de migrer vers le design responsive. La migration a pris trois mois, mais a éliminé le travail de maintenance quotidienne de maintenir deux basés de code alignées.
Les URL mobiles séparées
Les URL mobiles séparées utilisent généralement une structure de sous-domaine m-dot (m.exemple.com) ou un chemin /mobile/. Cette approche sert des fichiers HTML complètement séparés pour les utilisateurs mobiles et bureau. Quand un utilisateur mobile visite votre site, il est redirigé vers la version mobile ; les utilisateurs de bureau voient la version bureau. Chaque version est essentiellement son propre site Web avec ses propres URL, contenu et structure. Si vous choisissez cette approche, vous devez implémenter des balises rel=canonical sur la version mobile pointant vers l’équivalent bureau, et des balises rel=alternate sur le bureau pointant vers la version mobile. Cela indique à Google que les deux versions représentent le même contenu. Google explorera les deux versions mais indexera finalement la version bureau sauf si vous spécifiez autrement. Pour l’indexation mobile-first, si vous utilisez une configuration m-dot, vous devez vous assurer que la version mobile a une balise rel=canonical se pointant elle-même, indiquant que Google doit indexer la version mobile comme principale.
Une agence immobilière spécialisée dans les annonces de propriétés de luxe avait construit leur site en utilisant l’approche m-dot il y a plus d’une décennie. Leur version bureau était riche en fonctionnalités avec des cartes de propriété, des galeries de photos, des calculatrices hypothécaires et des informations sur les quartiers. La version mobile ne montrait que des photos et des détails basiques pour réduire l’utilisation des données. Quand l’indexation mobile-first est devenue obligatoire, leur trafic de recherche organique pour les requêtes de propriété a considérablement baissé car Google indexait maintenant la version mobile minimaliste, pas la version bureau détaillée. La version mobile manquait des informations sur les quartiers. Ils ont aussi découvert que leur configuration rel=canonical était incorrecte – les pages mobiles pointaient vers des URL de bureau, mais Google était incapable d’associer correctement les versions. Leurs options étaient de corriger la configuration ou de migrer vers le design responsive. Après avoir analysé les coûts, ils ont choisi le design responsive car ils pouvaient assurer la parité parfaite sans maintenance continue. La migration a pris du temps, mais maintenant Google voit le même contenu que les utilisateurs mobiles voient réellement, et les classements se sont rétablis en six semaines.
La parité de contenu : la règle non négociable
La parité de contenu signifie que votre version mobile doit contenir le même texte, les mêmes informations et les mêmes fonctionnalités que votre version bureau. Google traite le contenu identique sur tous les appareils comme un signal que votre site fonctionne correctement. Le contenu manquant sur mobile est immédiatement interprété par l’algorithme de classement de Google comme une erreur technique ou une suppression intentionnelle. Si votre version mobile est plus mince – moins de descriptions, d’avis manquants, d’explications simplifiées – les classements de Google refléteront le contenu de la version mobile, pas celui du bureau. Ce n’est pas une préférence ; c’est une exigence. Selon la documentation de Google, le contenu qui apparaît sur le bureau mais pas sur mobile ne sera pas indexé et ne contribuera pas aux classements. La même règle s’applique à l’inverse : si vous ajoutez du contenu uniquement sur mobile qui n’existe pas sur le bureau, il sera toujours indexé uniquement s’il respecte les critères de Google.
Un détaillant en ligne vendant de l’équipement technique a découvert ce principe par une expérience douloureuse. Leur site mobile manquait des spécifications de produits qui apparaissaient dans un tableau détaillé sur le bureau. Le tableau lui-même était responsive et aurait dû s’afficher sur mobile, mais pour diverses raisons de conception, ils l’avaient caché en utilisant display:none CSS. Ils ont supposé que tant que le contenu était en HTML, Google le trouverait. En réalité, le crawleur de Google lit ce qui est réellement rendu, et si CSS masque le contenu, Google le traite comme non destiné aux utilisateurs mobiles. Leurs pages de produits avaient un classement médiocre pour les requêtes de spécifications car ce tableau était invisible à Google lors de l’exploration. Une fois qu’ils ont supprimé la règle display:none et rendu les spécifications visibles sur mobile – bien que stylisées de manière plus compacte – ces requêtes ont commencé à générer du trafic à nouveau en un mois.
Les données structurées et les métadonnées sur mobile
Les données structurées – également appelées balisage de schéma – et les métadonnées comme les titres de méta et les descriptions doivent être présentes et identiques sur les versions mobiles et bureau. Le balisage de schéma est JSON-LD ou Microdata qui aide les moteurs de recherche à comprendre de quoi parle votre page. Si vous vendez des produits, le schéma indique à Google le nom du produit, le prix, la notation et la disponibilité. Si vous exploitez un restaurant, le schéma indique à Google vos heures, votre localisation et vos avis. Google utilise largement ces données structurées pour le classement, et c’est particulièrement important pour l’indexation mobile-first. Si votre version mobile a un schéma incomplet ou manquant, Google aura moins de compréhension. Les titres de méta et les descriptions doivent être identiques. Certains anciens sites ont des titres de méta séparés pour les versions mobiles (‘Acheter des chaussures’ sur le bureau mais ‘Chaussures’ sur mobile), mais cela crée une incohérence. Restez avec une version de chaque élément de métadonnées.
Une entreprise B2B SaaS vendant des logiciels comptables a réalisé que sa version mobile avait un balisage de schéma incomplet. Leurs pages bureau incluaient un schéma pour SoftwareApplication avec des niveaux de tarification, des listes de fonctionnalités et des évaluations d’utilisateurs. Sur mobile, pour réduire la taille du code, ils avaient inclus seulement le minimum. Ils ont aussi remarqué que le test des résultats enrichis de Google montrait des niveaux différents d’exhaustivité entre les versions. Cette incohérence a confus le système de classement de Google. Lorsqu’ils ont ajouté un schéma complet à la version mobile – correspondant exactement au bureau – Google a reconnu les pages plus confidemment, et ils ont commencé à se classer pour plus de requêtes longue traîne. La solution nécessitait uniquement d’ajouter le même balisage de schéma au mobile ; il était déjà en HTML sur le bureau, donc ils se sont assurés que les deux versions l’incluaient.
Images et vidéos dans un monde mobile-first
Les images et vidéos doivent être présentes sur mobile avec la même qualité et pertinence que sur le bureau. L’indexation mobile-first de Google signifie que le crawleur évalue vos images et vidéos telles que vues par les utilisateurs mobiles. Si vous avez supprimé des images du mobile pour réduire l’utilisation des données, Google n’aura pas ces images pour comprendre le contenu visuel. Le texte alternatif devient encore plus critique sur mobile car les images sont cruciales pour l’engagement, et le texte alternatif aide Google à comprendre le contenu de l’image. Assurez-vous que vos images mobiles ont des attributs alt descriptifs qui correspondent au contenu des images elles-mêmes. Les balises vidéo doivent être présentes sur mobile avec un balisage de schéma approprié indiquant la durée, la miniature et la description. Si vous incorporez des vidéos via des iframes, assurez-vous que les iframes se chargent correctement sur les navigateurs mobiles – certaines implémentations retardent le chargement des iframes vidéo.
Un détaillant de mode en ligne avec lequel nous avons travaillé avait pris une décision intéressante : pour améliorer la vitesse des pages mobiles, ils chargeraient les images de produits avec paresse quand un utilisateur ferait défiler près d’elles. Cela était fait pour le bureau et le mobile. Cependant, ils avaient défini un seuil élevé pour le chargement rapide sur mobile – les images sous la limite ne se chargeraient pas jusqu’à ce que les utilisateurs fassent défiler à moins de 50 pixels d’elles. Combiné à la vitesse d’exploration rapide de Google et au rendu JavaScript, cela signifiait que Google ne pouvait souvent pas voir les images car il explorait trop rapidement. Les images existaient dans le code mais ne se rendaient pas à temps. Ils ont abaissé la distance de chargement rapide sur mobile et se sont assurés que les images au-dessus de la limite se chargeaient avec impatience. Ce petit ajustement a permis à Google de voir immédiatement toutes les images, ce qui a amélioré leur visibilité. La cohérence du texte alternatif s’est aussi améliorée car maintenant chaque image était visible.
Le lazy loading bien fait et mal fait
Le lazy loading est une optimisation des performances qui reporte le chargement des images, vidéos et parfois d’autres contenus jusqu’à ce qu’un utilisateur fasse défiler près d’elles ou indique l’intérêt par une interaction. Utilisé correctement, le lazy loading améliore le temps de chargement initial, ce qui profite à la fois à l’expérience utilisateur et aux métriques des Core Web Vitals. Cependant, le lazy loading crée un risque spécifique pour l’indexation mobile-first : si le contenu est chargé avec paresse et que le crawleur de Google n’attend pas assez longtemps, Google ne verra pas le contenu. Le crawleur de Google exécute JavaScript et attendra que le contenu dynamique se charge, mais il y a des limites. Le crawleur n’attend pas indéfiniment – il a une période d’expiration. Si votre lazy loading est agressif, Google peut passer avant de le voir. Le contenu principal au-dessus de la limite ne doit jamais être chargé avec paresse. C’est le contenu qui apparaît dans la fenêtre d’affichage initiale quand un utilisateur atterrit sur la page. Si ce contenu est chargé avec paresse, les utilisateurs sur des connexions lentes verront un espace vide, et Google ne le verra peut-être pas du tout. Économisez le lazy loading pour le contenu ci-dessous la limite.
Une plateforme de blog hébergeant des milliers d’articles a découvert des problèmes avec leur implémentation de lazy loading quand elle a migré vers l’indexation mobile-first. Leurs pages d’articles étaient remplies d’images en ligne dans tout le texte, et ils avaient mis en œuvre un lazy loading agressif. Images sous les premiers paragraphes n’étaient pas chargées en affichage initial. Le crawleur de Google est rapide – il charge la page mais attend brièvement les ressources initiales. Le seuil de lazy loading du blog était défini de sorte que seules les images du premier affichage étaient chargées immédiatement. Le reste attendait un événement de défilement qui ne viendrait jamais. En conséquence, Google indexait des articles sans la plupart de leurs images. Les lecteurs recevaient aussi des expériences tronquées, mais le passage à l’indexation mobile-first a révélé le problème car Google utilisait maintenant le mobile comme version principale. Ils ont ajusté leur stratégie : les images dans les premiers 1500 pixels se chargeaient avec impatience, tandis que les images plus loin utilisaient le lazy loading basé sur l’observateur d’intersection. Cela équilibrait les performances et la visibilité.
Comment vérifier si votre site est indexé en mobile-first
Google n’a pas fourni d’étiquette explicite dans la Search Console disant « votre site est indexé en mobile-first », mais vous pouvez le déduire de plusieurs signaux. Ouvrez Google Search Console et regardez le rapport Couverture. Cliquez sur n’importe quelle page indexée et regardez le bouton « Afficher la page indexée ». Google montrera le HTML rendu. Si vous cliquez dessus pour une URL de page mobile sur un domaine m-dot, Google montrera la version rendue mobile. Sur les sites responsive, Google rend la page telle qu’elle apparaît sur un appareil mobile. Comparez ce que Google rend avec ce que vous voyez quand vous visitez la page sur votre téléphone – ils doivent être identiques ou très proches. S’il y a des différences majeures, quelque chose empêche Google de rendre la page correctement. Une autre façon de vérifier est d’utiliser l’outil Inspection URL. Tapez une URL de page et Google montrera ce qu’il voit lors de l’exploration avec les agents utilisateurs de bureau et mobiles.
Une petite entreprise de fabrication vendant des pièces industrielles voulait vérifier son statut d’indexation mobile-first. Ils ont utilisé l’outil Inspection URL et ont découvert quelque chose de préoccupant : quand Google explorait leur site avec un agent utilisateur mobile, des sections entières de leur tableau de prix ne se rendaient pas. Le tableau était construit avec CSS Grid d’une manière qui fonctionnait bien sur le bureau, mais sur mobile, la grille s’effondrait et le contenu disparaissait. Google montrait un espace vide où le prix devait être. Ils ne s’étaient pas rendus compte qu’il y avait un conflit dans leurs requêtes multimédias CSS. Une fois qu’ils ont corrigé le design responsive du tableau de prix pour qu’il s’affiche correctement sur mobile, Google pouvait voir et indexer les informations de tarification. Cette seule correction a amélioré leurs classements pour les requêtes comme « tarification de gros » car maintenant les informations étaient visibles à Google et aux utilisateurs mobiles.
Erreurs mobile-first courantes et comment les corriger
L’erreur la plus courante est d’avoir du contenu différent sur mobile et sur le bureau. Cela inclut les paragraphes manquants, les descriptions de produits, les avis, les informations de tarification ou les tableaux de spécifications. Auditez votre site systématiquement en visitant plusieurs pages représentatives sur les navigateurs de bureau et mobiles, ou en utilisant des outils qui affichent une vue fractionnée. Faites une liste de tout contenu qui apparaît dans une version mais pas dans l’autre. Si le contenu est masqué par CSS, Google peut toujours le voir s’il est en HTML, mais la meilleure pratique est de rendre tout le contenu visible. Si vous devez masquer du contenu pour des raisons de conception, assurez-vous que ce n’est pas du contenu critique. Une autre erreur courante est l’utilisation de fragments d’URL (symboles de dièse) pour la navigation. Un fragment comme /products#shoes ne crée pas une nouvelle page du point de vue de Google – c’est toujours juste /products. Utilisez plutôt des chemins d’URL appropriés : /products/shoes est mieux que /products#shoes car il crée une page distincte et crawlable.
Une troisième erreur courante est de ne pas mettre à jour les balises meta robots ou les valeurs rel=canonical lors de la mise en œuvre de l’indexation mobile-first. Si vous passez du desktop-first au mobile-first, assurez-vous que les balises meta robots sur vos pages mobiles permettent à Google de les explorer et les indexer. Certains sites ont d’anciennes balises meta robots comme ‘noindex’ qui n’ont jamais été supprimées. Vérifiez aussi que les balises rel=canonical ont du sens dans votre architecture. Pour les sites responsive, vous n’avez besoin d’aucun rel=canonical – Google reconnaît le design responsive unique. Mais si vous avez des URL m-dot séparées, le rel=canonical sur la page mobile devrait pointer vers lui-même si vous voulez que le mobile soit indexé, ou pointer vers le bureau si vous voulez que le bureau soit canonique. Quatrièmement, de nombreux sites ne testent pas complètement leur expérience mobile. Ouvrez votre site sur des appareils mobiles réels de différentes tailles et vitesses de connexion. Les outils de test modernes comme le test Mobile-Friendly de Google vous diront si votre site est responsive, mais ne détecteront pas les problèmes de contenu. Utilisez des appareils réels ou une émulation fidèle dans Chrome DevTools. Cinquièmement, consultez vos données Google Analytics ou Google Search Console pour voir comment le trafic mobile par rapport au bureau se comporte. Si votre trafic mobile est inférieur à ce qui était attendu, il peut y avoir un problème de contenu ou d’utilisabilité.
AMP en 2026 : est-ce que ça vaut encore le coup
Accelerated Mobile Pages (AMP) est un cadre créé par Google pour construire des pages Web mobiles qui se chargent extrêmement rapidement en limitant certaines fonctionnalités et en optimisant le code. L’adoption d’AMP a culminé autour de 2018-2019 quand il y avait la perception que Google favorisait les pages AMP. Cependant, Google a clarifié plusieurs fois qu’AMP n’est pas un facteur de classement. La présence ou l’absence d’AMP ne fournit pas d’avantage de classement. Bien que les pages construites avec AMP puissent se charger plus rapidement, l’avantage de vitesse seul ne se traduit pas par de meilleurs classements sauf si les Core Web Vitals s’améliorent. Les mesures des Core Web Vitals – Largest Contentful Paint, First Input Delay et Cumulative Layout Shift – peuvent être atteintes avec un design responsive régulier tout aussi facilement qu’avec AMP. En 2026, l’adoption d’AMP est estimée à moins d’un pour cent. La grande majorité des sites utilisant AMP maintiennent des versions AMP et non-AMP en double, ce qui crée une charge de maintenance continue et des problèmes potentiels de synchronisation. AMP est toujours utilisé par certains éditeurs de nouvelles car les temps de chargement exceptionnellement rapides améliorent l’engagement, mais pour les objectifs de SEO, il n’y a aucune raison de mettre en œuvre AMP. Si vous avez déjà des pages AMP et qu’elles fonctionnent bien, il n’y a pas de besoin urgent de les supprimer, mais les nouveaux sites ne devraient pas choisir AMP pour des raisons de SEO.
Une publication de nouvelles technologiques exécutait toujours des versions AMP de chaque article aux côtés de leurs versions responsive régulières. La moitié de leur budget allait à la publication et à la maintenance de deux versions, plus à la gestion des balises, des métadonnées et des redirections. Ils craignaient que l’abandon d’AMP ne nuise à leurs classements de recherche. Après avoir consulté notre équipe et la documentation de Google, ils ont pris la décision de retirer AMP entièrement. La migration a pris deux mois. Pendant la transition, ils se sont assurés que les URL AMP avaient les redirections 301 appropriées, maintenant toute autorité de classement gagnée. Après la fin du retrait, leur trafic organique n’a pas diminué – sinon, il s’est stabilisé et légèrement amélioré car tout leur effort de développement pouvait maintenant se concentrer sur rendre la seule version responsive aussi rapide que possible. Ils n’avaient plus à diviser les ressources d’ingénierie. Leurs temps de chargement sur le site responsive étaient en fait plus rapides que leurs versions AMP précédentes car ils avaient mis en œuvre des techniques d’optimisation modernes. Le résultat : si vous envisagez AMP pour le SEO, ne le faites pas. Investissez plutôt dans un design responsive.
Core Web Vitals et performance mobile
Les Core Web Vitals sont un ensemble de métriques que Google utilise pour mesurer l’expérience utilisateur sur les pages : Largest Contentful Paint (LCP) mesure le temps qu’il faut pour que le plus grand élément visible se charge, First Input Delay (FID) mesure la réactivité de la page à l’interaction de l’utilisateur, et Cumulative Layout Shift (CLS) mesure la stabilité de la mise en page pendant le chargement. Ces métriques affectent considérablement l’expérience utilisateur. Si une page prend huit secondes pour afficher son contenu principal, c’est une mauvaise expérience. Si cliquer sur un bouton ne répond pas pendant trois secondes, c’est frustrant. Si la mise en page change pendant que vous essayez de cliquer, c’est perturbant. Google utilise les Core Web Vitals comme facteur de classement, bien que pas aussi lourdement que la pertinence du contenu et les liens. John Mueller a déclaré que les Core Web Vitals ne sont pas des « facteurs de classement géants » – ce qui signifie qu’elles ne feront pas ou ne briseront pas vos classements seules, mais c’est une partie de l’algorithme. La distinction importante pour l’indexation mobile-first est que Google mesure les Core Web Vitals sur la version mobile de votre site. Si votre version mobile est lente, vos Core Web Vitals seront mauvaises et cela peut affecter les classements. Inversement, si vous avez optimisé votre version mobile pour la vitesse, vous gagnez un avantage de classement. Pour vérifier vos Core Web Vitals, visitez Google Search Console et regardez le rapport Core Web Vitals.
Un site de commerce électronique vendant de l’électronique grand public a découvert que leur Largest Contentful Paint mobile prenait 4,2 secondes – bien au-dessus du seuil ‘bon’ de Google de 2,5 secondes. Le coupable était des images héroïques non optimisées qui servaient des images de haute résolution au mobile. Les utilisateurs mobiles sur des connexions 4G plus lentes téléchargeaient des images de 800 Ko qui auraient dû être 150 Ko. Ils ont mis en œuvre la diffusion d’images adaptatives en utilisant l’élément picture et les attributs srcset, ainsi les utilisateurs mobiles ont reçu des images de taille appropriée. Ils ont aussi déplacé les scripts au-dessus de la limite pour charger après que le contenu principal soit visible. Ces modifications ont ramené leur LCP à 1,8 secondes. De plus, ils ont découvert que leur site avait des changements de mise en page causés par des images fictives qui ne réservaient pas d’espace vertical. Ils ont ajouté des attributs de largeur et de hauteur explicites à toutes les images, empêchant le changement. Ces optimisations ont amélioré leurs Core Web Vitals, et en deux mois, leur trafic organique a augmenté d’environ huit pour cent. L’amélioration provient du meilleur classement et aussi des taux de rebond plus faibles.
Le SEO mobile au-delà de l’indexation
L’indexation mobile-first consiste fondamentalement à déterminer quelle version de votre site Google utilise pour le classement, mais le SEO mobile s’étend bien au-delà de l’indexation. Il englobe tout le parcours utilisateur mobile : découverte via la recherche, arrivée sur votre site et conversion ou engagement. Un site peut être correctement indexé mobile-first mais ne pas convertir efficacement les utilisateurs mobiles. L’utilisabilité mobile est extrêmement importante. Votre navigation doit être claire et conviviale au pouce – les boutons et les liens doivent mesurer au moins 48 pixels pour que les utilisateurs ne tapent accidentellement pas la mauvaise chose. Les formulaires doivent minimiser le nombre de champs sur mobile, en divisant les formulaires plus longs en plusieurs étapes si nécessaire. Les écrans mobiles sont petits, alors chaque pixel compte. Évitez les interstitiels intrusifs – les pop-ups qui couvrent le contenu au chargement sont particulièrement dommageables sur mobile car ils occupent l’écran entier. Google pénalise activement les pages avec des interstitiels trop agressifs, alors évitez-les entièrement ou utilisez-les rarement pour des objectifs légitimes comme la vérification de l’âge ou le consentement aux cookies. La vitesse de chargement mobile est critique. La recherche montre que les utilisateurs mobiles sont moins patients que les utilisateurs de bureau – si une page prend plus de trois secondes à charger, beaucoup de utilisateurs mobiles partiront. C’est en partie une question de métriques des Core Web Vitals, mais aussi de vitesse perçue réelle. Optimisez les images, chargez paresseusement le contenu ci-dessous la limite correctement, minifiez CSS et JavaScript, et utilisez un réseau de livraison de contenu.
Pensez à l’indexation mobile-first comme la fondation, mais le SEO mobile comme le bâtiment. La fondation doit être solide – votre contenu doit être là, vos métadonnées doivent être correctes, et Google doit pouvoir l’explorer et l’indexer. Mais ensuite, vous construisez sur cette fondation en garantissant que les utilisateurs mobiles ont une excellente expérience : des temps de chargement rapides, une navigation claire, des formulaires faciles, un texte lisible sans zoom. Un guide long ou une critique de produit conçue pour la lecture sur le bureau peut avoir 3 000 mots, mais sur mobile, ces mêmes 3 000 mots ont besoin d’une mise en forme soignée. Utilisez des sous-titres partout pour diviser le texte. Utilisez des paragraphes courts – deux ou trois phrases chacun. Utilisez les listes à puces avec parcimonie. Évitez les longs blocs de texte. Ces choix de mise en forme n’affectent pas l’indexation de Google, mais ils affectent considérablement si les utilisateurs mobiles liront votre contenu ou rebondiront aux résultats de recherche. Le SEO mobile signifie aussi être stratégique à propos des extraits en vedette, des résultats enrichis et d’autres fonctionnalités SERP. Ces types de résultats peuvent générer un trafic important sur mobile si votre contenu est optimisé pour eux. Un guide pratique formaté avec des rubriques appropriées et des listes est plus susceptible d’être sélectionné pour un extrait en vedette. Une page de produit avec un balisage de schéma approprié et des avis est plus susceptible d’apparaître dans le carrousel de produits de Google. Ces fonctionnalités SERP sont particulièrement précieuses sur mobile car elles occupent plus d’espace vertical.