// guide pilier
Mobile-first indexing : ce qu'il faut savoir.
Depuis juillet 2024, Google n'utilise plus que la version mobile de votre site pour le crawl, l'indexation et le ranking. Implications concrètes, vérifications GSC, erreurs critiques à corriger, Core Web Vitals mobiles 2026.
Mobile-first : ce qui a changé en 2024.
Google a annoncé le mobile-first indexing en 2016, déployé progressivement entre 2018 et 2024. La transition est finalisée à 100 % depuis juillet 2024. Conséquence directe : la version desktop de votre site n'est plus utilisée par Google ni pour le crawl, ni pour l'indexation, ni pour le ranking.
// à retenir
Mobile-first n'est plus une option depuis juillet 2024. Si la version mobile manque de contenu vs la version desktop, Google n'indexe que la version mobile (donc la version dégradée). La parité mobile/desktop est devenue obligatoire.
Conséquences concrètes
- Le contenu masqué sur mobile ("lire la suite", accordéons fermés par défaut) reste lu par Google ; en revanche, le contenu littéralement absent de la version mobile est invisible pour Google.
- Les balises meta, structured data, canonical et hreflang doivent être présentes sur la version mobile. Erreurs typiques : structured data injectées en JS desktop only, hreflang absent du template mobile.
- Les liens internes doivent rester crawlables sur mobile. Un menu burger qui cache 200 liens internes derrière un script JS pas exécuté par Googlebot Smartphone = perte de maillage interne.
- Les Core Web Vitals mesurés par Google sont ceux de la version mobile. Optimiser le mobile devient prioritaire sur le desktop.
Vérifier le statut sur Search Console.
Trois vérifications en 5 minutes pour confirmer que le site est bien crawlé en mobile-first et qu'aucun blocage technique ne pénalise.
- 01
URL Inspection : confirmer le bot
Search Console > Inspection de l'URL > coller une URL importante > section "Couverture" > chercher "Exploré en tant que". Doit indiquer Googlebot Smartphone. Si Googlebot Desktop apparaît : problème technique majeur à investiguer (rendu mobile cassé, redirection incorrecte vers desktop, etc.).
- 02
Tester le rendu mobile
Search Console > Inspection de l'URL > Page testée > voir le rendu HTML capturé par Googlebot Smartphone. Vérifier que le contenu principal est présent, que les CSS chargent, que les liens internes sont visibles dans le HTML rendu. Comparer visuellement avec la version desktop pour détecter les écarts.
- 03
Audit Core Web Vitals mobiles
Search Console > Expérience > Signaux web essentiels > sélectionner Mobile. Identifier les URLs en "Médiocre" ou "À améliorer". Compléter avec PageSpeed Insights (mode Mobile) sur les pages prioritaires pour le détail technique.
Les 5 erreurs critiques mobile.
Cinq erreurs qui bloquent ou dégradent significativement l'indexation mobile. Toutes corrigeables en quelques heures de dev.
01 Bloquer CSS, JS ou images dans robots.txt
L'erreur n°1. Sans accès aux CSS, Googlebot ne peut pas vérifier le rendu responsive. Sans JS, le contenu d'une SPA n'est pas vu. Vérifier que /wp-content/, /themes/, /assets/ sont accessibles. Tester via GSC > Inspection URL > "Voir la page testée".
02 Contenu mobile dégradé vs desktop
Sections entières absentes du template mobile, sidebar avec 30 % du contenu retirée, FAQ non rendue sur mobile. Tout ce qui n'est pas dans le HTML mobile est invisible pour Google. Solution : responsive parfaite, ou rendu identique avec adaptations CSS uniquement.
03 Structured data desktop only
JSON-LD ou microdata présents dans le HTML desktop mais retirés sur mobile. Google n'indexant que mobile, ces données sont perdues. Vérifier dans GSC > Pages testées > Données structurées que les schemas sont bien détectés sur la version mobile rendue.
04 Liens internes cachés derrière un menu burger non crawlable
Menu burger qui charge ses items via JS au tap. Si Googlebot ne déclenche pas l'événement tap, il ne voit pas les liens. Solution : liens présents dans le HTML mobile dès le rendu initial, juste masqués visuellement par CSS jusqu'au tap.
05 Interstitiels intrusifs au load
Pop-up newsletter en plein écran, modal d'inscription qui couvre 80 % du viewport, bannière géante de promotion. Google pénalise explicitement les interstitiels intrusifs sur mobile (depuis 2017, confirmé 2026). Exceptions tolérées : bandeaux cookies, alertes légales (alcool, adulte), paywall.
Parité mobile/desktop : 4 axes de vérification.
La parité parfaite n'est plus un plus, c'est la base. Quatre axes à auditer systématiquement.
Contenu textuel
Tous les textes desktop doivent être présents dans le HTML mobile. Le masquage CSS (accordéons, "lire la suite") est OK. La suppression pure du HTML mobile = perte SEO immédiate.
→ diff HTML mobile vs desktop
Métadonnées et structured data
Title, meta description, canonical, hreflang, Open Graph, JSON-LD : tout doit être identique entre mobile et desktop. Vérifier via View Source en mode mobile sur Chrome DevTools.
→ Chrome DevTools mode mobile
Liens internes
Tous les liens internes du desktop doivent être présents dans le HTML mobile (visibles ou masqués). Compter les liens via Chrome DevTools > document.querySelectorAll('a').length en mode mobile vs desktop.
→ count links mobile = desktop
Images avec attributs
Toutes les images doivent avoir leur alt, width, height sur mobile. Le lazy-loading ne doit pas masquer l'attribut alt à Googlebot.
→ alt + dimensions présents
Core Web Vitals mobiles.
Trois métriques mesurées par Google sur la version mobile. Les seuils 2026 sont stricts : un site qui dépasse régulièrement est déclassé sur les requêtes mobiles, surtout commerciales.
LCP
< 2,5 s
Largest Contentful Paint. Temps avant que l'élément principal de la page soit visible.
INP
< 200 ms
Interaction to Next Paint. Réactivité du site aux interactions utilisateur.
CLS
< 0,1
Cumulative Layout Shift. Stabilité visuelle (pas de décalages intempestifs).
Optimisations mobile rapides
- Images responsive avec srcset : ne pas servir une image 1200px à un mobile 375px. Utiliser
<picture>ousrcset. - Format AVIF ou WebP au lieu de JPG/PNG. Gain typique 30-50 % du poids.
- Lazy loading natif :
loading="lazy"sur images below the fold.fetchpriority="high"sur l'image LCP. - CSS critique inline dans le head. Le reste asynchrone via media trick.
- Dimensions explicites sur images, vidéos, iframes :
widthetheighten HTML pour éviter le CLS. - JavaScript minimal bloquant. Splitter les bundles, defer le non-critique. INP < 200 ms exige un main thread libre.
Responsive vs serveur dynamique vs URLs séparées.
Trois configurations techniques pour servir une version mobile. Google les supporte toutes mais avec des préférences claires.
Responsive design
Même HTML, même URL, CSS adapte le rendu via media queries. Le plus simple à maintenir, recommandé par Google. Aucune divergence possible entre mobile et desktop côté contenu.
→ standard 2026
Serveur dynamique
Même URL, HTML différent selon User-Agent détecté côté serveur. Ajouter Vary: User-Agent en header. Risque de mauvaise détection ou de cache CDN qui sert le mauvais HTML.
→ migrer vers responsive
URLs séparées (m.exemple.com)
Deux URLs distinctes pour la même page (desktop et mobile). Configuration historique des années 2010. Maintenance lourde, risque de divergence, complexité du sitemap. À migrer impérativement vers responsive.
→ migration prioritaire
Checklist mobile-first 2026.
12 points à valider sur un audit mobile-first. Cocher les 12 = site conforme aux exigences Google 2026.
[ ]01. "Exploré en tant que Googlebot Smartphone" confirmé dans GSC > URL Inspection
[ ]02. robots.txt autorise CSS, JS, images (pas de Disallow sur /assets/, /themes/, etc.)
[ ]03. Contenu textuel intégral présent dans le HTML mobile (pas de suppression vs desktop)
[ ]04. Title, meta description, canonical identiques entre mobile et desktop
[ ]05. Structured data (JSON-LD) présentes sur le HTML mobile
[ ]06. hreflang présents sur mobile si site multilingue
[ ]07. Liens internes du menu burger présents dans le HTML initial (pas chargés au tap JS)
[ ]08. Images : alt, width, height présents sur mobile
[ ]09. LCP < 2,5 s sur mobile (PageSpeed Insights, mode Mobile)
[ ]10. INP < 200 ms (mesuré sur interactions principales)
[ ]11. CLS < 0,1 (vérifier via DevTools)
[ ]12. Pas d'interstitiel intrusif au load (pop-up plein écran, modal couvrant > 50 % du viewport)
Questions fréquentes.
Mobile-first indexing : qu'est-ce qui a changé en 2024 ?
Google a finalisé en juillet 2024 la transition vers le mobile-first indexing. Concrètement : Google n'utilise plus que la version mobile de votre site pour le crawl, l'indexation et le ranking. La version desktop est ignorée pour ces 3 étapes. Si votre version mobile manque de contenu ou est dégradée par rapport au desktop, Google n'indexera que cette version mobile. La parité mobile/desktop est devenue obligatoire, pas optionnelle. Documentation officielle.
Comment vérifier que mon site est crawlé en mobile-first ?
Search Console > Inspection de l'URL > coller une URL > section "Couverture" > chercher "Exploré en tant que". Si "Googlebot Smartphone" est indiqué, le site est en mobile-first. Si "Googlebot Desktop" : cas extrêmement rare en 2026 (moins de 1 % des sites), généralement indique un problème technique majeur côté mobile (rendu impossible, redirections incorrectes). Tous les nouveaux sites lancés depuis 2019 sont en mobile-first par défaut.
Quelle différence entre responsive design et serveur dynamique ?
Trois configurations possibles techniquement. (1) Responsive design : même HTML, même URL, CSS adapte le rendu selon le viewport. Recommandé par Google, le plus simple à maintenir. (2) Serveur dynamique : même URL, mais HTML différent selon User-Agent détecté. Risque : si la détection rate, mauvais HTML servi. (3) URLs séparées (m.exemple.com) : architecture obsolète, à migrer vers responsive si possible. En 2026, responsive est la norme à 95 %.
Quels sont les seuils Core Web Vitals mobiles en 2026 ?
LCP (Largest Contentful Paint) < 2,5 s : élément principal visible rapidement. INP (Interaction to Next Paint) < 200 ms : réactivité aux interactions utilisateur. CLS (Cumulative Layout Shift) < 0,1 : pas de décalages visuels intempestifs. Mesurer mobile spécifiquement via Chrome DevTools (mode Lighthouse Mobile) et PageSpeed Insights. Les sites qui dépassent ces seuils sont déclassés progressivement, surtout sur les requêtes commerciales mobiles.
Mon site responsive est-il automatiquement mobile-first compatible ?
Pas garanti. Quatre vérifications obligatoires. (1) Le contenu textuel doit être identique entre mobile et desktop (pas de "lire la suite" qui cache 80 % du texte sur mobile). (2) Les balises meta et structured data doivent être présentes sur mobile. (3) Les liens internes doivent rester crawlables (pas de menus burger qui cachent des liens à Googlebot). (4) Les images doivent avoir leurs alt et dimensions sur mobile.
Bloquer CSS et JavaScript en robots.txt impacte-t-il l'indexation mobile ?
Oui, gravement. C'est l'erreur n°1 sur les sites en difficulté d'indexation mobile. Sans accès aux CSS, Googlebot ne peut pas vérifier que le site est responsive. Sans JS, Googlebot ne voit pas le contenu rendu (cas critique pour les SPA). Le robots.txt doit autoriser explicitement /wp-content/, /themes/, /assets/, et tous les répertoires hébergeant CSS/JS/images. Vérifier via Search Console > Inspection URL > "Voir la page testée".
Les pop-ups et interstitiels mobiles sont-ils pénalisés ?
Oui, depuis 2017 et confirmé en 2026. Google pénalise explicitement les interstitiels intrusifs sur mobile : pop-ups qui cachent le contenu principal, bannières surdimensionnées au scroll, modal d'inscription en plein écran. Exceptions tolérées : bandeaux cookies (obligation légale RGPD), pop-ups d'alerte légale (vente alcool, contenu adulte), bannières de connexion sur contenu paywallé. Privilégier les bandeaux discrets en bas d'écran qui n'intrusent pas le scroll.
Faut-il garder la version desktop si Google n'indexe que le mobile ?
Oui, absolument. Google n'indexe plus que le mobile, mais les visiteurs viennent toujours sur les deux versions. Le desktop reste critique pour : (1) l'expérience utilisateur des conversions (45-55 % du trafic e-commerce conversion vient encore du desktop), (2) le SEA / Google Ads où la qualité de la landing page desktop compte, (3) les visiteurs B2B et professionnels (souvent en bureau). Le mot d'ordre : parité parfaite entre mobile et desktop, pas abandon du desktop.
// passer à l'action
Diagnostiquer une URL mobile.
Vérifier en 10 secondes que la version mobile d'une page n'a aucun blocage technique d'indexabilité (rendu sans JS, robots, canonical, etc.).