Mobile
Google indexe la version mobile de votre site. Si du contenu, des liens ou des données structurées n’existent que sur le desktop, ils n’existent pratiquement pas.
Pourquoi ce module existe
Section courte, enjeu élevé : la parité entre les deux versions n’est pas facultative.
Module E 9 actions n° 79 à 87 sur 410
-
079
Servir une seule mise en page responsive ; vérifier qu’elle passe l’ergonomie mobile de la Search Console sans défilement horizontal
- Comment
- Servez le même HTML à tous les appareils et adaptez la mise en page en CSS (media queries, grilles fluides).
- Vérifiez à 320, 360, 390, 768 et 1024 px qu’aucun élément ne dépasse : document.documentElement.scrollWidth doit égaler la largeur de la fenêtre.
- Contenez les éléments larges (tableaux, blocs de code) dans un conteneur overflow-x: auto.
- Si vous avez encore un site m. séparé, planifiez sa fusion vers le responsive avec des 301.
- À éviter
- Une largeur fixe (width: 1200px) sur un conteneur
- Des images sans max-width: 100%
- Un tableau de prix qui fait défiler toute la page horizontalement
- Vérifier
- Chrome DevTools → mode appareil à 360 px sur chaque gabarit : aucune barre de défilement horizontale.
- Lighthouse → « Le contenu est dimensionné correctement pour la fenêtre d’affichage » réussi.
-
080
Servir un contenu principal, des données structurées et des liens IDENTIQUES sur mobile et sur desktop (index mobile-first)
- Comment
- Comparez la version mobile et la version ordinateur de vos gabarits : texte principal, titres, images, liens internes, données structurées.
- Tout ce qui manque sur mobile n’existe pas pour Google : réintégrez-le, quitte à le replier.
- Vérifiez que les balises meta (robots, canonical, hreflang) sont identiques sur les deux versions.
- Contrôlez aussi le JSON-LD : il doit être présent dans le HTML mobile.
- À éviter
- Retirer les liens du pied de page ou les descriptions produit sur mobile pour « alléger »
- Des données structurées ajoutées seulement dans le gabarit ordinateur
- Des images en lazy-load qui ne se chargent jamais pour le robot mobile
- Vérifier
- Search Console → Inspection de l’URL → HTML rendu (Googlebot smartphone) : texte, liens et JSON-LD de la version ordinateur y sont.
- Crawlez avec un user-agent mobile puis ordinateur : même nombre de mots et de liens internes par page.
-
081
Poser <meta name="viewport" content="width=device-width, initial-scale=1">
- Comment
- Ajoutez dans le <head> de chaque page : <meta name="viewport" content="width=device-width, initial-scale=1">.
- Ne bloquez pas le zoom : pas de user-scalable=no ni de maximum-scale=1.
- Vérifiez que la balise n’est présente qu’une fois (thème et plugin l’ajoutent parfois tous les deux).
- Placez-la tôt dans le <head>.
- À éviter
- Ajouter user-scalable=no : les personnes malvoyantes ne peuvent plus zoomer
- Deux balises viewport contradictoires
- Une largeur fixe (width=1024)
- Vérifier
- Affichez le code source : une seule balise viewport, avec width=device-width, initial-scale=1.
- Lighthouse → Accessibilité : le contrôle portant sur user-scalable="no" est réussi.
-
082
Faire des cibles tactiles d’au moins 48 × 48 px, espacées d’au moins 8 px
- Comment
- Donnez à chaque lien et bouton isolé une zone cliquable d’au moins 48 × 48 px (padding, pas seulement la taille de l’icône).
- Espacez les cibles voisines d’au moins 8 px.
- Pour les icônes (réseaux sociaux, fermer, panier), agrandissez la zone avec du padding ou un pseudo-élément.
- Les liens dans une phrase peuvent rester à la taille du texte ; ce sont les cibles isolées qui comptent.
- À éviter
- Des icônes de 16 px collées les unes aux autres dans l’en-tête
- Un pied de page où les liens sont empilés à 12 px d’écart
- Réduire le padding des boutons sur mobile pour gagner de la place
- Vérifier
- Lighthouse → « Les éléments tactiles sont suffisamment grands » réussi.
- Sur un vrai téléphone, touchez chaque lien du menu et du pied de page avec le pouce : aucun mauvais clic.
-
083
Supprimer les interstitiels et pop-ups plein écran qui couvrent le contenu au chargement mobile (fuite : rétrogradation MobileInterstitials)
- Comment
- Repérez toute fenêtre modale ou surcouche qui couvre le contenu principal au chargement.
- Remplacez-la par : un petit bandeau en haut ou en bas (pas en plein écran)
- un appel à l’action intégré dans le contenu
- une fenêtre modale qui demande une action du visiteur (un clic) pour apparaître, et non un déclenchement automatique
- · Si vous avez besoin d’un bandeau de consentement aux cookies, faites-en une petite barre en bas, pas une surcouche plein écran.
- Si vous avez besoin d’une invitation à installer une application, différez-la jusqu’à ce que le visiteur ait passé du temps sur le site et montré de l’engagement (défilement, deux pages ou plus).
- La pénalité précise de Google vise les interstitiels plein écran que le visiteur doit fermer avant d’accéder au contenu principal. À proscrire complètement.
- À éviter
- Une modale plein écran « abonnez-vous à notre newsletter » dès la première visite (pénalité Google et exaspération du visiteur)
- Un consentement cookies qui recouvre toute la page (obligation légale, mais un petit bandeau suffit)
- Un bandeau d’installation d’application qui occupe plus de 30 % de l’écran sur mobile
- Vérifier
- Ouvrez le site sur un téléphone. Aucune surcouche plein écran ne doit apparaître automatiquement.
- DevTools → Lighthouse → « Évite les interstitiels intrusifs » doit passer.
-
084
Supprimer aussi les interstitiels intrusifs sur les pages d’atterrissage desktop
- Comment
- Recensez ce qui apparaît automatiquement sur ordinateur : modale newsletter, pop-up de sortie, publicité plein écran, mur d’inscription.
- Supprimez les surcouches qui masquent le contenu principal à l’arrivée depuis une recherche.
- Remplacez-les par un bloc intégré dans la page ou un petit bandeau latéral qui ne cache pas le texte.
- Si vous gardez une modale, déclenchez-la après une action du visiteur (clic, fin de lecture), jamais à l’arrivée.
- À éviter
- Tester seulement le mobile en pensant que l’ordinateur n’est pas concerné
- Une pop-up de sortie qui se déclenche dès que la souris approche de la barre d’onglets
- Un mur « désactivez votre bloqueur de publicité » sur la page d’atterrissage
- Vérifier
- Ouvrez 5 pages d’atterrissage en navigation privée sur ordinateur : rien ne couvre le contenu dans les 10 premières secondes.
- Search Console → Actions manuelles : aucune.
-
085
Garantir un texte courant d’au moins 16 px sur mobile ; aucune lecture ne doit exiger de zoomer
- Comment
- Fixez la taille du texte courant à au moins 16 px (1rem) sur mobile.
- Utilisez un interligne de 1,4 à 1,6 et une largeur de ligne raisonnable.
- Vérifiez les petits textes (légendes, mentions, notes) : pas en dessous de ~12 px, et jamais pour du contenu essentiel.
- Unités relatives (rem) pour que le réglage de taille du navigateur soit respecté.
- À éviter
- Un corps de texte à 14 px sur mobile
- Des tailles en px fixes qui ignorent les préférences du visiteur
- Un texte gris clair sur fond blanc qui oblige à zoomer autant qu’une petite taille
- Vérifier
- DevTools → mode appareil à 360 px → Computed sur un paragraphe : font-size ≥ 16px.
- Lighthouse → « Le document utilise des tailles de police lisibles » réussi.
-
086
Ne pas cacher le contenu clé derrière des accordéons mobiles que Google peut pondérer plus faiblement ; le garder dans le DOM
- Comment
- Gardez le contenu important dans le HTML initial, même replié : <details><summary> ou un accordéon dont le contenu est présent dans le DOM et caché en CSS.
- Ne chargez pas le contenu de l’onglet ou de l’accordéon par une requête au clic.
- Laissez ouvert par défaut le bloc le plus important (description principale, réponse à la question).
- Évitez de replier les titres H2 principaux derrière des boutons.
- À éviter
- Charger le texte d’un accordéon en AJAX au clic : il n’existe pas pour le robot
- Replier toute la description produit sur mobile
- Utiliser display:none déclenché uniquement sur mobile pour des blocs entiers de contenu
- Vérifier
- Search Console → Inspection de l’URL → HTML rendu : le texte des accordéons y figure.
- Recherchez sur Google une phrase exacte tirée d’un accordéon replié : la page doit sortir.
-
087
Tester la vraie vitesse mobile en 4G bridée (onglet mobile de PageSpeed Insights), pas seulement sur desktop
- Comment
- Lancez PageSpeed Insights et lisez l’onglet Mobile en premier (4G lente et CPU ralenti simulés).
- Reproduisez localement : DevTools → Performance, réseau « Fast 4G » ou « Slow 4G », CPU ×4 ou ×6.
- Testez sur un vrai téléphone Android d’entrée de gamme via un partage de connexion lent.
- Priorisez les corrections qui améliorent le mobile, même si l’ordinateur est déjà vert.
- À éviter
- Se rassurer avec le score ordinateur
- Tester sur un iPhone récent en Wi-Fi fibre
- Comparer des mesures faites dans des conditions différentes d’une fois à l’autre
- Vérifier
- PageSpeed Insights mobile : LCP, INP et CLS de terrain au vert pour la page et l’origine.
- Votre test en 4G lente sur un téléphone d’entrée de gamme affiche le contenu principal en moins de 3 secondes.
Continuer
Module suivant
← Module D / 30 actions
Vitesse et Core Web Vitals
La vitesse est un signal mesuré, pas une opinion : Google lit les données Chrome de vrais visiteurs. Ces actions visent les trois métriques qui…
Module F / 22 actions →
HTML on-page
Titles, headings, meta descriptions : les éléments qu’un crawler lit en premier et qu’un internaute lit dans la page de résultats. Petites…