Un client m'appelle, un peu paniqué. Son trafic a chuté de 38 % en trois semaines. Je regarde le site sur mon téléphone : le menu s'ouvre, mais la moitié des liens renvoient vers une page blanche. Sur mon ordinateur, tout fonctionne. Voilà, c'est exactement ça, le mobile first : la version sur laquelle vous ne travaillez jamais est souvent celle que Google voit en premier.
La bascule, dans les faits, est déjà loin. Google a annoncé le mobile first indexing en 2016, l'a déployé progressivement, puis a rendu la version mobile totalement prioritaire. Depuis, votre rendu desktop ne sert plus de référence pour le classement. Ce n'est pas une tendance à surveiller, c'est la façon dont l'index fonctionne aujourd'hui. Et pourtant, je vois encore des sites dont la version mobile est un parent pauvre du desktop : contenu tronqué, images manquantes, balises absentes.
Points clés à retenir
- Google indexe et classe votre site à partir de sa version mobile, pas de la version desktop.
- Le contenu que vous masquez sur mobile (onglets, accordéons, faux menus) peut être purement et simplement ignoré.
- Un site responsive mal testé reste un site cassé : la responsivité n'est pas une garantie, c'est un point de départ.
- La vérification se fait page par page, avec la comparaison mobile/desktop et l'inspection d'URL.
- Les trois erreurs qui coûtent le plus : contenu caché, liens absents en mobile, lazy-loading qui bloque le rendu.
- Si le desktop et le mobile divergent, c'est le mobile qui gagne — toujours.
Comprendre ce que le SEO mobile first change concrètement
La plupart des articles que je lis sur le sujet expliquent ce qu'est le mobile first. Presque aucun ne dit ce qui se passe quand votre version mobile est incomplète. C'est pourtant là que tout se joue.
Ce que Google lit vraiment
Le robot d'indexation se présente avec un user-agent mobile. Il charge votre page comme le ferait un smartphone, récupère le HTML, le contenu, les liens internes, les images et les données structurées de cette version-là. Si un élément n'existe que dans votre gabarit desktop, il n'existe pas pour l'indexation. Point.
J'ai vérifié ça sur un site de e-commerce que je suivais. La fiche produit affichait une description longue en desktop. Sur mobile, un script chargeait la même description dans un onglet fermé par défaut. Résultat : Google voyait une page avec un titre, un prix et rien d'autre. La fiche ne se classait sur aucune requête de fond. Le contenu n'était pas pénalisé : il était invisible.
Le problème n'est donc pas un mauvais signal envoyé à Google. C'est l'absence de signal. Une page vide se classe comme une page vide.
La question des usages
La majorité du trafic web passe aujourd'hui par un écran de téléphone. Voilà pourquoi Google a inversé la logique. Mais attention à ne pas faire dire aux chiffres ce qu'ils ne disent pas : avoir du trafic mobile ne signifie pas que tous vos utilisateurs se comportent pareil. Sur certains secteurs — je pense à des outils B2B, à des logiciels de gestion — les décisions se prennent encore devant un écran large. Ça ne change rien à la règle d'indexation. Ça change votre stratégie de contenu.
Une chose que j'ai apprise à mes dépens : optimiser pour le mobile, ce n'est pas rétrécir le desktop. C'est faire en sorte que la version pauvre soit aussi riche que la version confortable. Dans cet ordre-là.
Comment vérifier si votre site est prêt
Pas de discours, une procédure. Je l'applique sur chaque audit, elle prend une à deux heures pour un site de taille moyenne.
Étape 1 : confirmer le mode d'indexation
Avant tout, assurez-vous que votre site n'est pas resté sur une configuration héritée. Dans la Search Console, la plupart des propriétés affichent un rendu mobile par défaut. Si un site a été migré récemment ou traîne une configuration ancienne, vérifiez-le explicitement. Un site qui n'a jamais été audité depuis sa mise en ligne il y a cinq ans mérite ce contrôle.
Étape 2 : comparer mobile et desktop, page par page
Prenez vos dix pages les plus importantes. Ouvrez chacune sur un vrai téléphone et sur un écran large. Notez ce qui disparaît.
- Le texte principal est-il identique ?
- Les liens internes — menu, fil d'Ariane, liens de bas de page — sont-ils tous présents ?
- Les images ont-elles la même source et les mêmes attributs alt ?
- Les balises structurées (titre, description, canonique) sont-elles cohérentes ?
Sur un site client, j'ai trouvé onze liens internes qui n'existaient que dans la version desktop. Onze. La version mobile en proposait quatre. Google suivait quatre liens par page au lieu de quinze. La profondeur de crawl s'était effondrée sans que personne ne s'en aperçoive.
Étape 3 : tester le robots.txt et le rendu
Un piège classique : un robots.txt distinct pour le mobile, hérité d'une ancienne configuration. Si votre robot mobile est bloqué sur des ressources CSS ou JavaScript, Google voit une page non stylée et peut mal évaluer la lisibilité. Vérifiez le fichier tel qu'il est servi à un user-agent mobile.
Pour le rendu, l'inspection d'URL de la Search Console affiche la version que Google a chargée. Comparez-la à ce que vous voyez, vous, sur votre téléphone. L'écart est souvent instructif. Et lancez un audit Lighthouse en mode mobile : il pénalise le temps de rendu, les images non dimensionnées, les scripts qui bloquent l'affichage. Ces signaux comptent, surtout sur une connexion médiocre.
Responsive, dynamic serving ou URL m. séparée : quel cas vous concerne
Il existe trois façons de servir du contenu mobile, et elles ne se comportent pas pareil face à l'indexation. La plupart des guides passent dessus. C'est une erreur, parce que les risques diffèrent totalement.
| Configuration | Principe | Risque principal |
|---|---|---|
| Responsive | Même URL, même HTML, mise en page adaptée par CSS | Contenu masqué en CSS (onglets, accordéons) que Google peut ignorer |
| Dynamic serving | Même URL, HTML différent selon le user-agent | Divergence de contenu entre les deux versions, détectable par erreur |
| URL mobile séparée (m.) | URL distincte pour le mobile | Canonique mal configurée, contenu désynchronisé, liens internes différents |
Le cas des sites en configuration mixte
Voilà la situation la plus pénible à auditer : un site qui mélange. Une partie en responsive, une autre servie depuis une URL m. héritée, souvent sur des sous-domaines oubliés. J'en ai vu un récemment où le blog était en m. et le catalogue en responsive. Les deux équipes ignoraient qu'elles cohabitaient.
Dans ce cas, deux choses à contrôler absolument. D'abord la balise canonique : elle doit pointer vers la version que Google doit indexer, et rester cohérente entre les deux URL. Ensuite, si votre site existe en plusieurs langues, les annotations hreflang doivent être propres sur les deux versions, sinon Google mélange les signaux. Une URL m. mal reliée à sa canonique, c'est une page qui se fait indexer deux fois ou pas du tout.
Mon avis, et je le défends : si vous en avez la possibilité, partez en responsive et n'en bougez plus. La maintenance d'une version mobile séparée coûte plus cher en erreurs qu'elle ne rapporte. J'ai accompagné une migration de m. vers responsive — six semaines de travail, deux mois de stabilisation, et un trafic qui a mis un trimestre à retrouver son niveau. Pas parce que la migration était mauvaise, mais parce qu'on avait laissé traîner des redirections bancales. Chaque configuration a son lot de pièges, la plus simple en a le moins.
Les erreurs qui coûtent le plus
Certaines fautes reviennent tellement souvent que je les vérifie en premier, systématiquement. En voici quatre, par ordre de gravité.
Contenu masqué en mobile
Le contenu placé dans un onglet, un accordéon ou un menu déroulant peut rester indexé si le contenu est bien présent dans le HTML. Mais j'ai vu trop de sites où la technique utilisée chargeait le texte dynamiquement, à l'ouverture. Google obtenait alors une page tronquée. Règle simple : tout ce qui compte doit être dans le HTML servi, pas ajouté après. Vérifiez en désactivant JavaScript dans votre navigateur. Ce que vous voyez encore, c'est probablement ce que Google voit.
Liens et images absents
Le cas du menu hamburger qui ne contient que deux niveaux alors que le desktop en propose quatre. Le crawler suit les liens présents dans le HTML. Si votre navigation mobile en cache la moitié, la moitié de votre site devient plus difficile à découvrir. Sur les images, même logique : un srcset qui pointe vers des fichiers non servis en mobile, et vos images disparaissent de l'index.
Lazy-loading qui bloque
Le chargement différé est utile, mais mal paramétré, il empêche le robot de voir le contenu. Si vos images ou vos blocs se chargent uniquement au scroll, et que le robot ne scrolle pas, ils restent invisibles. Je vérifie toujours l'attribut loading sur les médias du premier écran : ceux-là ne devraient jamais être différés.
Interstitiels intrusifs
Un écran plein qui recouvre le contenu dès l'arrivée sur mobile, et vous dégradez l'expérience et le rendu. Les cas gênants sont connus : une pop-up de consentement qui prend tout l'écran sans bouton de fermeture clair, une publicité interstitielle en pleine lecture. Ce n'est pas une pénalité automatique, mais c'est un signal négatif qui s'ajoute au reste. Et si votre page ne contient qu'un mur d'inscription, Google voit une page sans contenu utile.
Adapter concrètement sa méthode de travail
Le vrai basculement n'est pas technique. Il est mental. Tant que vous concevez sur grand écran et que vous « adaptez après », vous produirez toujours une version mobile dégradée.
Ce que j'ai fini par imposer à mes projets : on dessine d'abord la version téléphone. Pas après, avant. On y met tout ce qui doit être là. Ensuite seulement, on ajoute ce que le grand écran permet de confortablement afficher. Ce renversement change tout, parce qu'il oblige à hiérarchiser dès le départ. Un écran de 6 pouces ne pardonne pas le superflu.
Concrètement, trois habitudes à prendre :
- Valider chaque maquette d'abord sur un gabarit mobile, en réunion, sur un vrai appareil.
- Faire tester le rendu par une personne qui n'utilise jamais l'ordinateur pour naviguer.
- Auditer le rendu mobile à chaque mise en production, pas une fois par saison.
Sur mon dernier projet, cette méthode a fait remonter un problème en deux jours qui aurait mis des mois à apparaître : un formulaire de contact dont le bouton d'envoi était recouvert par une barre fixe. Invisible sur desktop, bloquant sur mobile. Le genre de détail qui coûte des conversions sans qu'aucun rapport ne le signale.
Adapter son SEO au mobile first, au fond, c'est arrêter de traiter le téléphone comme une déclinaison. C'est considérer que c'est là que votre site vit, et que le desktop est le confort bonus. Le jour où vous acceptez ça, les audits deviennent plus simples, parce que vous ne cherchez plus ce qui manque : vous savez déjà que tout doit être là.
