Index mobile-first : contenu mobile, viewport et ergonomie tactile
1. Ce que l’index mobile-first change vraiment
Google a testé l’index mobile-first à partir de 2019 et l’impose à tous les sites depuis juillet 2024. Ce n’est pas l’algorithme de classement qui change, c’est la façon dont Google voit votre site.
| Avant (desktop-first) | Aujourd’hui (mobile-first) | Impact sur les sites B2B |
|---|---|---|
| Exploration de la version desktop pour l’index | Exploration de la version mobile pour l’index | Un tableau desktop masqué sur mobile n’est pas indexé |
| Le mobile n’était qu’une optimisation d’expérience | Le mobile est la seule source d’indexation | Un Schema rendu uniquement sur desktop revient à ne pas l’avoir écrit |
| Un sous-domaine mobile m.example.com était acceptable | Un sous-domaine mobile dédié coûte cher à maintenir | Privilégiez un site responsive unique et abandonnez le sous-domaine m. |
| Transmission du poids des liens sur desktop | Les liens sont aussi évalués sur la version mobile | Un mobile lent pénalise aussi le classement |
Pour savoir si votre site est déjà passé au mobile-first : la page d’accueil de Search Console affiche « Ce site est indexé selon l’index mobile-first ». Si ce message n’apparaît pas, Google vous explore encore avec l’ancienne règle, mais le basculement n’est qu’une question de temps : n’attendez pas.
2. Les quatre contrôles stricts : viewport, contenu, tactile, Schema
La conformité à l’index mobile-first se décompose en quatre points, chacun avec un critère précis.
| Point de contrôle | Critère de conformité | Erreur fréquente | Outil de vérification |
|---|---|---|---|
| viewport | <meta name=”viewport” content=”width=device-width, initial-scale=1″> | width=1200 en dur ou viewport absent | Test de compatibilité mobile |
| Cohérence du contenu | Contenu visible identique sur desktop et mobile | Tableaux et caractéristiques masqués en display:none sur mobile | Comparaison du code source de l’URL mobile |
| Ergonomie tactile | Zone cliquable ≥ 48×48 pixels CSS, espacement ≥ 8px | Boutons de 24px, liens collés les uns aux autres | Simulation mobile dans Chrome DevTools |
| Données structurées | Le code source de la page mobile contient le JSON-LD complet | Schema généré uniquement dans le template desktop | Rich Results Test sur l’URL mobile |
Exemple concret : sur la page produit d’un site de pièces industrielles, la version desktop affiche un tableau de caractéristiques complet (30 lignes), tandis que la version mobile le masque entièrement avec display:none pour « simplifier ». Après le passage à l’indexation mobile-first, les 12 mots-clés longue traîne de cette page produit ont tous chuté au-delà de la 20e page : Google ne voyait sur la version mobile qu’un paragraphe d’introduction, sans savoir quels paramètres caractérisaient le produit. En rendant le tableau défilable horizontalement sur mobile, 8 mots-clés sont revenus dans le top 10 en deux semaines.
La cohérence de contenu ne signifie pas que la mise en page desktop et mobile doit être identique, mais que le texte, les tableaux, les images et le Schema doivent tous être présents. La mise en page peut être repliée, mais jamais supprimée.
III. Responsive, serving dynamique et sous-domaine m.
Google prend officiellement en charge trois approches mobile, mais ne les recommande pas au même degré.
| Approche | Mise en œuvre | Coût de maintenance | Niveau de recommandation |
|---|---|---|---|
| Conception web responsive | Même HTML, adaptation par requêtes média CSS | Faible | À privilégier |
| Serving dynamique | Même URL, HTML différent renvoyé selon l’UA | Moyenne | Acceptable |
| Sous-domaine m. distinct | Modèle séparé sur m.example.com | Élevée | Déconseillé, héritage encombrant |
| Aucune version mobile | Affichage du desktop mis à l’échelle | Non | Interdit, non adapté au mobile |
Point contre-intuitif : un sous-domaine m. distinct semble « maîtrisable », mais il faut en réalité maintenir deux modèles, deux Schema et deux hreflang ; dès qu’ils se désynchronisent, le contenu devient incohérent. Migrer vers le responsive est en soi une migration de site, avec une cartographie 301 à prévoir. Sur un site multilingue, vérifiez aussi que Hreflang et versions multilingues n’est pas cassé par le modèle mobile.
IV. Images, polices et performance : les points spécifiques au mobile
L’indexation mobile-first ne se limite pas à « pouvoir afficher » : Google évalue aussi avec les données de la version mobile Core Web Vitals.
| Poste | Pratique courante sur desktop | À corriger sur mobile |
|---|---|---|
| Images | Une seule grande image | srcset + sizes, adaptés au DPR et à la largeur |
| Polices | Les 3 graisses chargées | Seulement 2 graisses, font-display: swap |
| Navigation | Menu horizontal en haut | Menu hamburger, pour éviter le débordement sur mobile |
| Formulaires | Tous les champs déployés | type adapté au numérique/e-mail, pour éviter le clavier complet |
| Publicités et fenêtres modales | Barre latérale | Pas de pop-up interstitiel masquant le contenu sur mobile |
Deuxième exemple concret : sur le blog d’un site B2B, le LCP mobile restait bloqué à 4,5 secondes, car l’image hero utilisait l’original desktop de 2400 px de large. Après ajout d’un srcset proposant 640 px et 1080 px, le LCP mobile est descendu à 2,1 secondes, sans impact sur le desktop. Cette modification n’a consisté qu’à ajouter deux attributs à la balise img, sans toucher au design.
Les pop-ups sur mobile sont une cible que Google combat spécifiquement : si une page mobile masque son contenu principal par un pop-up interstitiel, elle est signalée comme « non adaptée au mobile ». Les pop-ups Newsletter courants sur les sites B2B doivent devenir une barre en bas d’écran ou disparaître sur mobile.
V. Liste d’autocontrôle et procédure de vérification
| Point de contrôle | Outil | Critère de validation | Fréquence |
|---|---|---|---|
| Test d’adaptation mobile | Test d’adaptation aux mobiles de Google | Tout est validé, aucun avertissement de police trop petite ou de zone de clic trop rapprochée | À lancer une fois après la refonte |
| Cohérence du contenu | Simulation mobile Chrome + affichage du code source | Texte visible identique entre desktop et mobile | Échantillon de 10 pages par trimestre |
| Rendu du Schema sur mobile | Rich Results Test sur l’URL mobile | Identifier tous les types de Schema | Après modification du template |
| Données CrUX mobile | Rapport d’expérience dans Search Console | Les trois CWV mobiles au vert | Mensuel |
| État de l’indexation mobile | Accueil Search Console | Affiche « indexé en priorité sur la version mobile » | Mensuel |
Refonte de l’expérience mobile et Accessibilité du site (WCAG) Il y a beaucoup de recoupements : taille des zones cliquables, contraste, navigation au clavier. Une seule passe profite aux deux.
6. Adapter la rédaction après le passage à l’indexation mobile prioritaire
L’indexation mobile prioritaire n’est pas qu’une question technique : la façon d’écrire doit suivre. Sur ordinateur, on peut empiler de longs tableaux, des paramètres sur plusieurs colonnes, de longs raisonnements. Sur mobile, le visiteur tient son téléphone d’une main et son rythme de lecture n’a rien à voir. Il faut réorganiser le contenu pour une seule colonne en format portrait.
| Élément de contenu | Usage courant sur ordinateur | Usage recommandé sur mobile |
|---|---|---|
| Tableaux longs | Tableaux larges de plus de 8 colonnes | Découper en cartes ou en défilement horizontal, colonnes clés en premier |
| Longueur des paragraphes | Un paragraphe de plus de 200 caractères | 3 à 4 lignes maximum par paragraphe, phrases courtes et retours fréquents |
| Ancre de lien interne | Lien hypertexte sur toute la phrase | Texte du lien sur sa propre ligne, pour faciliter le tap du doigt |
| Graphiques | Graphiques à forte densité de données | Version simplifiée pour mobile, avec la conclusion en texte |
| Bouton d’appel à l’action | Petit bouton dans la navigation en haut | Un grand bouton au milieu et un en bas de l’article |
Rédigez d’abord votre brouillon en une seule colonne pour mobile, puis adaptez-le à l’ordinateur. Le contenu se lira bien des deux côtés, au lieu d’être joli sur ordinateur et entassé sur mobile. Chaque trimestre, prenez dix articles publiés au hasard et regardez-les dans la simulation mobile de Chrome. Si un tableau débordent, qu’un bouton est trop petit ou qu’un lien colle au bord, ajoutez-le à la prochaine série de corrections.
Les formulaires sont l’endroit où l’on perd le plus de conversions sur mobile. Sur ordinateur, on peut aligner une quinzaine de champs d’un coup ; sur mobile, le visiteur saisit d’une seule main et chaque champ supplémentaire fait perdre du monde. Réduisez le formulaire de contact à trois ou quatre champs obligatoires : nom de l’entreprise, e-mail, description du besoin. Le reste se complète après la signature. Les champs comme le numéro de portable, le téléphone ou le pays, que l’on peut déduire de l’e-mail et du domaine de l’entreprise, ne devraient pas être saisis à la main. Chaque point de conversion gagné sur le formulaire mobile fait monter d’un cran le nombre de demandes.
FAQ — Questions fréquentes
Quand Google a-t-il imposé l’indexation mobile prioritaire ?
Masquer du contenu avec display:none sur mobile nuit-il au SEO ?
Faut-il garder le sous-domaine m.example.com ?
Quelle taille minimale pour une zone cliquable ?
Peut-on n’afficher le Schema que sur la version desktop ?
Pourquoi les interstitiels mobiles sont-ils pénalisés ?
Pour conclure
L’indexation mobile-first, ce n’est pas « faire une version mobile » et s’arrêter là : c’est la seule façon dont Google lit votre site. Une version desktop peut être parfaite, si elle est invisible sur mobile, elle n’existe pas.
Trois étapes pour passer à l’action : cette semaine, vérifiez 10 pages clés en simulation mobile dans Chrome DevTools pour confirmer que le contenu est identique sur desktop et mobile ; la semaine suivante, corrigez les trois points bloquants que sont le viewport, les zones cliquables et le rendu du Schema sur mobile ; la troisième semaine, confirmez dans Search Console que le test de compatibilité mobile est validé et que les données CrUX mobile sont conformes.
Une phrase à retenir : l’indexation mobile-first ne vous demande pas de faire une version réduite de votre site desktop, elle vous demande d’admettre que ce que Google voit, c’est ce que le visiteur voit sur son téléphone.