Une position n'est pas un nombre unique. Posez la question au même site, pour la même requête, sur les mêmes 90 jours, et le mobile et le bureau ne seront pas d'accord. Dans nos propres données Search Console, l'écart a atteint 11,4 positions sur une requête, et le sens s'inversait selon la requête : tantôt le mobile rankait mieux, tantôt le bureau.
Ce n'est pas un bug de données et ce n'est pas une raison d'acheter un tracker de positions mobile. C'est une propriété de la façon dont Google construit une page de résultats, et elle reste invisible tant que vous lisez une moyenne mélangée.
Cet article traite de ce qui cause réellement la séparation, de ce à quoi ressemblaient nos propres chiffres, et d'un court workflow Claude Code qui sépare les deux pour que vous arrêtiez de prendre des décisions de bureau sur du trafic mobile.
L'idée fausse
L'hypothèse que la plupart des équipes portent, généralement sans la formuler, est qu'une position est une propriété de la page. Vous êtes 8e sur une requête, donc vous êtes 8e. Les trackers de positions renforcent cette hypothèse parce qu'ils utilisent par défaut un seul appareil et impriment un nombre par mot-clé.
La conséquence pratique est une habitude de reporting : quelqu'un relève une position bureau, l'inscrit dans un tableur, et tout ce qui suit la traite comme la vérité sur la visibilité.
La réalité plus utile
Deux faits, tous deux documentés par Google, brisent le modèle du nombre unique.
Fait un : ce qui est classé, c'est votre page mobile. La documentation Search Central de Google le dit directement : « Google utilise la version mobile du contenu d'un site, explorée avec l'agent smartphone, pour l'indexation et le classement. » Votre HTML de bureau n'est pas l'entrée principale, même lorsque la personne qui cherche est sur un ordinateur portable.
Fait deux : la page de résultats est construite pour l'appareil qui se trouve devant elle. La documentation d'aide de Search Console elle-même le dit sans détour, et cela vaut deux lectures : « Les résultats de recherche sont spécifiques à l'heure, au lieu, à l'appareil et à l'historique récent de la personne qui effectue la recherche. »
Mettez les deux ensemble : la position que vous avez notée est un échantillon d'une distribution qui se décale selon l'appareil. Le nombre n'est pas faux. Il est simplement bien plus étroit que l'usage qu'on en fait.
Pourquoi le mythe se propage si facilement
Quatre choses ordinaires maintiennent le modèle du nombre unique en vie.
- Les trackers sont réglés sur le bureau par défaut. Récupérer une SERP bureau coûte moins cher et se stocke plus simplement, donc elle devient la colonne par défaut. Le changement d'appareil existe dans beaucoup d'offres, ce qui est différent d'être activé par défaut.
- Search Console mélange les appareils. Le rapport Performances par défaut fait la moyenne entre mobile, bureau et tablette. Il faut ouvrir l'onglet « Appareils », ou appeler l'API avec device comme dimension, pour voir la séparation. Rien dans la vue par défaut ne vous avertit qu'un mélange est en cours.
- Le suivi de positions mobile est vendu comme une option. Quand un fournisseur liste « tracker de positions mobile » comme fonctionnalité, l'implication est que le rapport standard couvre déjà tout. Il couvre une tranche.
- L'effet est invisible sur de petits échantillons. Si vous regardez dix requêtes et qu'elles concordent toutes, le problème paraît théorique. Il devient visible au niveau de la requête, sur les requêtes ayant assez d'impressions pour être moyennées.
Ce que nos propres 90 jours ont montré
Nous avons extrait notre propre propriété Search Console, 90 jours se terminant le 11 septembre 2026, avec query et device comme dimensions.
Appareil | Impressions | Clics | CTR | Position moyenne |
|---|---|---|---|---|
Bureau | 34 028 | 375 | 1,10 % | 34,4 |
Mobile | 7 147 | 69 | 0,97 % | 30,8 |
Tablette | 156 | 0 | 0,00 % | 40,8 |
Même propriété, même fenêtre, trois histoires différentes. Notez que la position moyenne mobile est meilleure alors que le CTR mobile est pire.
Deux choses dans ce tableau méritent attention.
La première est le signal inversé. La position moyenne mobile était meilleure que celle du bureau (30,8 contre 34,4), et pourtant le CTR mobile était pire (0,97 % contre 1,10 %). Une meilleure position avec un taux de clics moins bon est normal sur mobile : les pages de résultats sont plus hautes, la mise en page diffère, et le haut de la page est encombré de fonctionnalités. Quiconque n'aurait rapporté que la position aurait déclaré le mobile plus fort et aurait manqué entièrement l'écart de clics.
La seconde est le piège qu'il y a à lire des moyennes à l'échelle du site. Ces deux lignes résument des mixes de requêtes différents. Le bureau porte 82 % de nos impressions parce que notre audience est constituée de praticiens SEO à leur bureau, et le mobile porte un ensemble différent et plus petit de requêtes. Les moyennes à l'échelle du site cachent cela. C'est la jointure par requête qui rend le nombre exploitable.
Nous avons donc fait la jointure. Sur 130 requêtes ayant au moins 20 impressions, 85 avaient des données sur les deux appareils. Voici les six plus grandes divergences.
Requête | Position mobile | Position bureau | Écart |
|---|---|---|---|
auditoria seo on page | 64,5 | 53,1 | 11,4 (bureau meilleur) |
perplexity seo checking tool | 20,5 | 31,1 | 10,6 (mobile meilleur) |
geo seo | 92,9 | 85,4 | 7,5 (bureau meilleur) |
auspia | 5,4 | 1,6 | 3,8 (bureau meilleur) |
perplexity referral traffic | 11,2 | 12,0 | 0,9 (bureau meilleur) |
amazon echo keywords | 13,9 | 13,8 | 0,1 (égalité) |
L'écart va dans les deux sens. « Le mobile ranke moins bien » est aussi faux que « une position est une position ».
Le sens s'inverse. C'est le constat qui devrait changer votre habitude opérationnelle : vous ne pouvez pas corriger la divergence entre appareils par une règle empirique, parce qu'il n'existe pas de sens constant à corriger. Vous devez la mesurer requête par requête.
Que faire à la place : séparer, joindre, seuil, décider
Quatre étapes, environ 20 minutes une fois le workflow en place.
Étape 1 : extraire query et device ensemble. Dans Search Console, ouvrez Performances, ajoutez l'onglet « Appareils » à côté de « Requêtes », puis exportez sur 90 jours. Via l'API, demandez les dimensions ["query","device"] avec une limite de lignes assez élevée pour contenir votre ensemble de requêtes. L'API accepte une limite de lignes bien au-delà de ce dont un site de taille moyenne a besoin, donc demandez haut et coupez en local.
Si vous produisez déjà un rapport de positions hebdomadaire, cela devient une dimension supplémentaire sur quelque chose que vous possédez déjà, et non un nouveau classeur. Le contrat de rapport de notre workflow de rapport de positions hebdomadaire lui réserve une place.
Étape 2 : joindre sur la clé de requête. Une ligne par requête, avec une colonne mobile et une colonne bureau. Les lignes qui n'existent que sur un appareil sont un constat en soi : elles signifient que la requête génère des impressions sur une surface et pas sur l'autre.
Étape 3 : appliquer un seuil avant de regarder. Cinq positions est un seuil de départ exploitable. En dessous, vous lisez du bruit. Au-dessus, vous avez une requête où les deux surfaces sont réellement en désaccord.
Étape 4 : décider par classe de requête, pas par requête. Les requêtes à enjeu financier se corrigent en premier. Les requêtes de comparaison divergent généralement parce que la mise en page de la SERP diffère, pas parce que votre page est faible. Les requêtes de marque qui divergent ne sont presque jamais un problème SEO. Les requêtes informationnelles peuvent attendre.
Le workflow Claude Code qui fait la séparation
La partie répétable est mécanique : extraire, joindre, appliquer le seuil, résumer. C'est exactement la forme de tâche qui appartient à un agent, et non à votre semaine.
Enregistrez ceci comme fichier d'instructions que Claude Code peut lire, et pointez-le vers la propriété que vous possédez :
Extrais les données Search Console de la propriété <property> sur les 90 derniers jours.
Utilise les dimensions : query, device. Ne garde que les requêtes ayant au moins 20 impressions.
Joins le mobile contre le bureau sur la clé de requête.
Pour chaque requête présente sur les deux appareils, calcule la différence absolue de position moyenne.
N'affiche que les lignes dont la différence est de 5.0 ou plus, triées par impressions totales décroissantes.
Pour chaque ligne affiche : requête, position mobile, position bureau, écart, quel appareil est meilleur,
impressions mobile, impressions bureau.
Termine par deux lignes de synthèse :
1. Nombre de requêtes où le mobile est meilleur, et nombre où le bureau est meilleur.
2. La requête unique ayant le plus grand écart, et ses impressions totales.
Ne suggère pas de corrections. N'écris pas de recommandations de contenu.
Enregistre la sortie sous mobile-desktop-gap-YYYY-MM-DD.md dans le dossier de travail.Trois choix délibérés dans cette instruction méritent d'être conservés si vous l'adaptez.
Elle fixe un plancher d'impressions, parce qu'une requête à quatre impressions mobiles produit une position moyenne qui ne veut rien dire. Elle interdit les suggestions de correction, parce que la décision dépend de la classe de requête et du contexte business, et qu'un agent qui devine là-dessus produit des âneries assurées. Et elle enregistre dans un fichier daté pour que vous puissiez comparer la séparation du mois prochain à celle de ce mois-ci, ce qui est la seule façon de voir si une correction a fonctionné.
Le prompt est neutre en forme vis-à-vis de l'agent. Codex exécute la même instruction via ses propres conventions de fichiers, et l'étape de relecture est identique.
Garde-fous
- En dessous d'environ 20 impressions, arrêtez. Les positions moyennes sur une poignée d'impressions sautent de deux chiffres d'elles-mêmes. Le seuil du prompt existe pour cette raison.
- La tablette n'est pas le mobile. Notre ligne tablette comptait 156 impressions et zéro clic. Regrouper la tablette avec le mobile aurait dégradé les chiffres mobiles pour des raisons qui n'ont rien à voir avec la recherche mobile.
- Cet article porte sur la mesure, pas sur l'éligibilité. Savoir si Google peut voir votre contenu mobile est un problème différent, avec des contrôles différents. Nous avons couvert le versant audit dans Indexation mobile-first en 2026.
- Une meilleure position peut être un moins bon résultat. Dans nos propres données, le mobile rankait mieux et cliquait moins. Position et taux de clics doivent se lire ensemble.
- Ne courez pas après chaque écart. Un écart de 6 positions sur une requête à 30 recherches mensuelles n'est pas un projet. Classez la liste par impressions et laissez la queue tranquille.
- Les positions profondes se comportent différemment. Si une requête se situe au-delà de la position 100 sur les deux appareils, corrigez d'abord le problème de profondeur. Nous avons mesuré jusqu'où vont réellement les résultats Google dans notre test de profondeur de vérification de position.
Point de vue Auspia : la divergence entre appareils est un problème de mesure avant d'être un problème de classement. La plupart des équipes n'ont jamais regardé, parce que le rapport par défaut cache la séparation. Une fois la séparation visible, la plupart des écarts se révèlent explicables et la poignée intéressante mérite une correction.
Questions fréquentes
Google classe-t-il séparément les pages mobile et bureau ? En pratique, oui. Google indexe la version mobile de votre contenu, et la page de résultats servie à un téléphone diffère de celle servie à un ordinateur portable. Les deux positions proviennent des mêmes systèmes sous-jacents, mais ce n'est pas le même nombre.
Pourquoi mon tracker de positions diffère-t-il de Search Console ? Parce qu'ils mesurent des choses différentes. Un tracker récupère une SERP en direct à un endroit et sur un appareil. Search Console fait la moyenne des impressions sur tous les appareils, tous les pays et toute la plage de dates. Les deux peuvent avoir raison et ne pas concorder.
Qu'est-ce qu'un tracker de positions mobile et en ai-je besoin ? Un tracker de positions mobile récupère la SERP smartphone pour un ensemble de mots-clés. Il vaut son prix si vous avez besoin des positions de concurrents ou de localisations que vous ne voyez pas dans vos propres données. Si vous avez seulement besoin de la visibilité mobile de votre propre site, Search Console la fournit déjà, ventilée par appareil, sans frais.
Combien d'impressions avant que la position par appareil soit fiable ? Environ 20 est le plancher pratique pour une lecture approximative ; à partir de 100, le nombre cesse de bouger d'une semaine à l'autre. En dessous de 20, gardez la requête dans la liste mais n'agissez pas dessus.
Claude Code peut-il lire Search Console directement ? Oui, via l'API Search Console avec un compte de service ou des identifiants OAuth. Le workflow ci-dessus suppose que cette connexion existe. Notre guide de l'agent SEO traite des tâches de classement qui valent la peine d'être confiées à un agent et de celles qui n'en valent pas la peine.
Dois-je corriger la page mobile si le mobile ranke moins bien ? Regardez d'abord la SERP. Si la page de résultats mobile porte plus de vidéo, plus de packs locaux, ou un mix différent de types de pages, la correction relève du format de contenu et non de la qualité de la page. Si la forme de la SERP correspond et que la page est correcte, traitez-le comme un problème de parité de contenu et auditez-le contre les contrôles mobile-first.
Auteur : Marcus Ellery, expérimentateur croissance derrière plus de 150 tests SEO chez Auspia. Il écrit sur les données de référence, les tests contrôlés et la différence entre une métrique qui bouge et une métrique qui signifie quelque chose.
