Ce qu'il faut retenir
Google indexe la version mobile de vos pages. La règle qui en découle tient en un mot : parité. Même texte, mêmes titres, mêmes liens internes, mêmes données structurées, mêmes images sur mobile et sur ordinateur. Le responsive est la façon la plus simple d'y arriver parce qu'il n'y a qu'un seul contenu à maintenir. Un contenu replié dans un accordéon compte normalement ; un contenu retiré de l'affichage mobile ne compte pas.
Le responsive design consiste à servir un seul code HTML et à adapter sa présentation à la largeur de l'écran, au moyen de règles de style conditionnelles. Cela relève de l'intégration, ce qui explique pourquoi la question « le responsive aide-t-il le SEO » n'appelle aucune réponse directe.
La question qui compte vraiment vient juste après. Que se passe-t-il si la version mobile de mon site ne contient pas la même chose que la version ordinateur ?
L'indexation mobile-first
Google explore et indexe désormais la version mobile des pages, la version ordinateur étant passée au second plan. Cette bascule est achevée depuis plusieurs années, et elle entraîne une seule conséquence, qui se paie cher.
Ce que le robot ne voit pas sur mobile n'existe pas. Un paragraphe présent sur ordinateur et absent sur mobile n'est pas indexé. Un lien interne affiché uniquement sur grand écran ne transmet rien. Une donnée structurée posée seulement sur la version ordinateur n'est pas prise en compte.
La quasi-totalité des problèmes que je rencontre sur ce sujet viennent de là, et ils passent inaperçus parce que la personne qui vérifie le site le fait depuis son ordinateur.
Les trois façons de servir un site sur mobile
| Technique | Principe | Risque principal |
|---|---|---|
| Responsive | Un seul code, une seule adresse, la présentation s'adapte à la largeur | Aucun risque de désynchronisation, c'est son intérêt majeur |
| Service dynamique | Une seule adresse, mais le serveur renvoie un code différent selon l'appareil | Deux contenus à maintenir, et un écart qui s'installe sans qu'on le voie |
| Site mobile séparé | Deux adresses distinctes, reliées par des balises de correspondance | Deux sites, deux jeux de balises, et un système de correspondance à ne jamais casser |
Je ne recommande la troisième option à personne aujourd'hui, et la deuxième seulement quand une contrainte technique forte l'impose. Google les traite pourtant correctement toutes les deux. Le problème vient de l'écart qu'elles rendent possible entre deux versions, et cet écart finit toujours par s'installer.
Les cinq points de parité à vérifier
- Le texte. Le même sur les deux versions, dans le même ordre. Un résumé sur mobile et un développement sur ordinateur est le cas le plus fréquent et le plus coûteux.
- Les titres. Même hiérarchie, sans saut de niveau. Certains gabarits changent la structure des titres selon la largeur d'écran, ce qui déstructure la page pour le robot.
- Les liens internes. Un menu réduit sur mobile qui supprime des entrées prive les pages concernées de leurs liens entrants. Un menu replié dans un bouton, en revanche, ne pose aucun problème tant que les liens sont présents dans le code.
- Les données structurées. Elles doivent figurer dans la version mobile. C'est une erreur classique quand les deux versions sont générées séparément.
- Les images et leurs attributs. Mêmes visuels, mêmes textes alternatifs. Une image décorative peut être retirée, une image porteuse d'information ne le peut pas.
Replier n'est pas retirer. Un contenu placé dans un onglet ou un accordéon reste présent dans le code servi, il est donc indexé et compte normalement. Un contenu chargé au moment seulement où l'utilisateur ouvre l'onglet ne sera jamais vu. Les deux se ressemblent à l'écran et se distinguent dans le code source, ce qui règle à peu près la moitié des questions qu'on me pose sur le sujet.
Comment tester le rendu mobile
Il existe trois façons de vérifier une version mobile, et elles ne répondent pas à la même question.
L'inspection d'URL de la Search Console montre le HTML que Google a réellement récupéré et rendu. C'est la seule source qui répond à la question de l'indexation. Toute vérification sérieuse commence par là.
Le mode responsive d'un navigateur renseigne sur la mise en page, pas sur l'indexation. Il est utile pour repérer un débordement ou un texte illisible, il ne dit rien de ce que voit le robot.
Les captures automatisées demandent une précaution que peu de gens connaissent, et qui m'a coûté une demi-journée avant que je ne la comprenne. Selon le système d'exploitation et le facteur d'échelle de l'affichage, une fenêtre de navigateur demandée à 390 pixels de large peut être rendue à 500 pixels. Toutes les captures produites dans ces conditions sont alors fausses, et elles montrent une mise en page qui n'existe sur aucun téléphone. Le contrôle consiste à mesurer la largeur effectivement rendue plutôt qu'à faire confiance à la largeur demandée.
Une seconde précaution vaut pour tous les tests automatisés, celle de vérifier que la feuille de style a bien été chargée avant la capture. Une page dont le style n'est pas arrivé déborde de partout, et le rapport signale un problème de mise en page qui n'existe pas.
Les symptômes qui trahissent un défaut de parité
Aucun rapport ne signale un défaut de parité en tant que tel. Il arrive toujours déguisé en autre chose, et quatre symptômes reviennent régulièrement.
| Ce que vous observez | Ce que ça désigne le plus souvent |
|---|---|
| Des pages indexées sans description, ou avec un extrait qui ne correspond pas | Le contenu principal n'est pas dans la version mobile servie |
| Des résultats enrichis qui disparaissent sans raison | Les données structurées manquent sur la version mobile |
| Des pages profondes qui perdent leurs positions alors que l'accueil se porte bien | Le menu mobile ne contient plus les liens vers ces pages |
| Un écart entre le texte visible à l'écran et le texte indexé | Un contenu chargé après interaction plutôt que présent dans le code |
Ces quatre symptômes se vérifient tous de la même façon, en comparant le HTML rendu par la Search Console au HTML que vous obtenez en consultant la page sur un vrai téléphone. C'est fastidieux sur un gros site, mais c'est décisif sur les vingt pages qui comptent.
Ce qui compte vraiment sur mobile
Une fois la parité assurée, le sujet devient celui de l'expérience, et il se mesure avec les signaux Web essentiels, relevés sur le trafic mobile réel de votre site.
Trois défauts spécifiquement mobiles reviennent dans mes audits. Les images servies à leur taille d'origine, qui font transiter deux mégaoctets pour un affichage de 350 pixels de large. Les zones cliquables trop rapprochées, qui produisent des clics ratés et des retours immédiats. Et les bandeaux de consentement mal calibrés, qui recouvrent le contenu et retardent l'affichage de l'élément principal.
Aucun de ces trois points ne concerne le responsive à proprement parler. Ils tiennent à l'attention qu'on porte, ou non, à la version que la majorité de vos visiteurs consulte et que Google prend pour référence.
Questions fréquentes
Sources
- Google, « Indexation mobile first »
https://developers.google.com/search/docs/crawling-indexing/mobile/mobile-sites-mobile-first-indexing?hl=fr - Google, « Bonnes pratiques pour les sites mobiles »
https://developers.google.com/search/docs/crawling-indexing/mobile/mobile-sites-mobile-first-indexing?hl=fr#best-practices - Les écarts de rendu des captures automatisées ont été constatés lors de contrôles menés sur mes propres projets. Consulté le 27 août 2026.