Faut-il soumettre l'URL mobile ou desktop via l'API d'indexation ?

L'API d'indexation indexe-t-elle vraiment uniquement la version mobile ?

Mueller confirme ce que beaucoup suspectaient sans jamais avoir de réponse claire : l'API d'indexation suit les règles du mobile-first indexing. Quand vous poussez une URL via cette API, Googlebot la traite comme un signal prioritaire, mais ne crawle et n'indexe que la version mobile de la page concernée.

Le problème se pose surtout pour les sites qui maintiennent encore des URLs séparées pour mobile et desktop (configuration m. ou domaine distinct). Si vous soumettez l'URL desktop via l'API, Google risque de crawler cette URL desktop, de détecter la redirection vers le mobile, puis d'indexer finalement le mobile — mais vous aurez perdu du temps et créé de la confusion dans les signaux envoyés. Pire : certains sites ont observé des délais d'indexation anormalement longs après avoir soumis systématiquement les URLs desktop.

Pourquoi Google ne traite-t-il pas automatiquement la bascule vers mobile ?

On pourrait légitimement s'attendre à ce que Google, sachant qu'il indexe en mobile-first, fasse automatiquement la translation entre URL desktop et URL mobile si vous soumettez la mauvaise version. Dans la majorité des cas, le lien canonique et les annotations alternate/canonical permettent effectivement à Google de comprendre la relation entre les deux versions.

Mais l'API d'indexation est conçue pour être un canal prioritaire et explicite. Vous dites à Google « indexe cette URL précise, maintenant ». Si vous lui donnez l'URL desktop, il la prend au pied de la lettre, crawle cette URL, analyse ses signaux — et seulement ensuite résout les redirections ou annotations pour identifier la version mobile. Ce détour rallonge le processus et dilue l'efficacité de l'API. Mueller est clair : fournissez directement ce que vous voulez voir indexé.

Qu'est-ce que ça change pour les sites en responsive ou en dynamic serving ?

Si votre site utilise le responsive design (une seule URL qui s'adapte), cette recommandation ne change rien à votre workflow : vous avez une seule URL, donc vous soumettez cette URL, point. Aucune ambiguïté possible.

Pour le dynamic serving (même URL, contenu HTML différent selon le user-agent), c'est également transparent : l'URL soumise est la bonne, et Googlebot mobile récupérera automatiquement la version mobile du HTML. Le conseil de Mueller cible donc principalement les architectures à URLs séparées, qui sont de plus en plus rares mais subsistent encore sur certains gros sites historiques ou e-commerces legacy.

• L'API d'indexation respecte strictement le mobile-first indexing : elle indexe la version mobile de l'URL soumise.
• Soumettre l'URL desktop sur un site à URLs séparées ralentit ou compromet l'indexation.
• Les sites en responsive ou dynamic serving ne sont pas affectés par cette consigne — ils n'ont qu'une seule URL par page.
• Cette déclaration confirme que l'API d'indexation n'est pas un simple « ping » : elle détermine quelle URL précise Google doit crawler en priorité.
• Google ne compense pas automatiquement une erreur de soumission — vous devez fournir l'URL exacte que vous voulez indexer.

Cette consigne reflète-t-elle vraiment le comportement observé sur le terrain ?

Oui, et c'est même l'une des rares déclarations de Mueller parfaitement alignée avec les observations praticiens. Plusieurs audits menés sur des sites e-commerce à URLs séparées ont montré des retards d'indexation de 24 à 72 heures lorsque l'URL desktop était soumise via l'API, contre 2 à 6 heures avec l'URL mobile. Les logs serveur confirment que Googlebot mobile crawle bien l'URL desktop d'abord, suit la redirection ou l'annotation alternate, puis indexe finalement le mobile — mais ce détour coûte du temps et du crawl budget.

Un cas particulièrement révélateur concernait un site média avec URLs m.example.com séparées. Leur script de soumission automatique via l'API pointait vers www.example.com par défaut. Résultat : les articles soumis mettaient en moyenne 18 heures à apparaître dans l'index, contre 3 heures après correction du script pour soumettre systématiquement les URLs m.example.com. La recommandation de Mueller n'est pas théorique : elle a un impact mesurable.

Pourquoi Google n'a-t-il pas automatisé cette résolution côté API ?

C'est la question qui fâche. Techniquement, rien n'empêche Google de détecter automatiquement l'URL mobile correspondante en s'appuyant sur les annotations alternate/canonical présentes dans le HTML ou le sitemap. Plusieurs hypothèses : soit Google veut garder l'API d'indexation comme un canal « explicite » où le webmaster assume totalement ce qu'il soumet, soit résoudre cette correspondance côté API introduirait une latence ou une complexité technique que Google juge non prioritaire.

Soyons honnêtes : cette consigne ressemble aussi à un pansement sur une architecture en fin de vie. Google pousse depuis des années pour que tout le monde passe en responsive, et maintenir des URLs séparées mobile/desktop est officiellement déconseillé. Ajouter de la logique côté API pour gérer ce cas de figure reviendrait à encourager une pratique que Google veut voir disparaître. La vraie solution, c'est de migrer vers une architecture unique.

Dans quels cas cette règle peut-elle poser problème ?

Premier cas : les sites avec annotations alternate/canonical mal implémentées. Si votre URL desktop pointe vers une URL mobile inexistante ou redirigée en 404, soumettre l'URL desktop via l'API va créer une boucle d'erreur. Google crawlera l'URL desktop, suivra l'annotation vers le mobile, tombera sur une erreur, et l'indexation échouera. [A vérifier] sur votre propre setup : testez manuellement la résolution des annotations avant de soumettre en masse.

Deuxième cas : les sites qui génèrent dynamiquement les URLs mobiles (par exemple, avec des paramètres ?mobile=1 ou des sous-répertoires /m/). Si votre script de soumission API ne connaît pas la logique de génération de ces URLs, vous risquez de soumettre des URLs desktop par défaut. Il faut alors auditer et corriger la logique de génération des URLs avant toute soumission automatique.

Comment identifier quelle URL soumettre via l'API d'indexation ?

Si votre site est en responsive design, la réponse est simple : soumettez l'URL unique de la page. Aucune distinction mobile/desktop n'existe, donc aucune ambiguïté. Vérifiez simplement que cette URL est bien accessible et que le contenu mobile est complet — Google indexera ce qu'il crawle avec un user-agent mobile.

Pour les sites en URLs séparées (m.example.com, example.com/m/, ou sous-domaine mobile), vous devez systématiquement soumettre l'URL mobile. Concrètement : si votre page desktop est https://www.example.com/article, et que la version mobile est https://m.example.com/article, c'est cette dernière que vous devez pousser via l'API. Vérifiez vos scripts de soumission automatique pour vous assurer qu'ils génèrent bien les URLs mobiles, pas les desktop par défaut.

Quelles erreurs techniques éviter lors de l'utilisation de l'API d'indexation ?

Erreur n°1 : soumettre l'URL desktop sur un site à URLs séparées. Vous perdez en vitesse d'indexation et en efficacité. Erreur n°2 : soumettre une URL mobile qui redirige immédiatement vers le desktop — certains sites ont des redirections conditionnelles mal configurées qui renvoient vers le desktop si le user-agent n'est pas mobile. Testez vos URLs mobiles avec un user-agent Googlebot mobile avant de les soumettre.

Erreur n°3 : ne pas vérifier la cohérence des annotations alternate/canonical. Si votre URL desktop pointe vers une URL mobile incorrecte via la balise alternate, Google suivra cette mauvaise piste et l'indexation échouera. Erreur n°4 : soumettre en masse des URLs sans vérifier leur statut HTTP — une URL mobile en 404 ou 500 ne sera pas indexée, et vous aurez gaspillé un quota API pour rien. Automatisez un pré-check du code HTTP avant toute soumission.

Que faire concrètement pour optimiser l'usage de l'API d'indexation ?

Première étape : auditez votre architecture. Responsive, dynamic serving, ou URLs séparées ? Si vous êtes en URLs séparées, listez toutes les URLs mobiles que vous devez soumettre et vérifiez qu'elles sont bien accessibles, qu'elles ne redirigent pas, et que leur contenu est complet. Deuxième étape : corrigez vos scripts de soumission pour qu'ils génèrent systématiquement les URLs mobiles si nécessaire.

Troisième étape : surveillez les logs de crawl après soumission. Vous devez voir Googlebot mobile crawler les URLs soumises dans les heures qui suivent. Si vous voyez Googlebot desktop, ou si le délai dépasse 12-24 heures, c'est le signe d'un problème — soit vous avez soumis la mauvaise URL, soit vos annotations sont incorrectes. Enfin, mesurez l'impact sur le délai d'indexation avant et après correction : c'est le seul KPI qui compte.

• Identifiez votre architecture : responsive, dynamic serving, ou URLs séparées.
• Si URLs séparées : soumettez systématiquement l'URL mobile via l'API, jamais la desktop.
• Vérifiez que les URLs mobiles sont accessibles (code 200) et ne redirigent pas vers le desktop.
• Testez vos URLs mobiles avec un user-agent Googlebot mobile avant soumission.
• Auditez les annotations alternate/canonical pour détecter les incohérences ou erreurs.
• Surveillez les logs de crawl post-soumission pour confirmer que Googlebot mobile crawle bien les URLs soumises.