Mobile-first indexing : checklist technique complète

Google crawle et indexe votre site avec un user-agent mobile. Depuis mars 2025, il n'y a plus d'exception : tous les sites sont passés au mobile-first indexing. Si la version mobile de vos pages omet du contenu, des liens internes ou des données structurées présentes sur desktop, vous avez un problème d'indexation — pas un problème de responsive design.

Ce que mobile-first indexing signifie réellement (et ce qu'il ne signifie pas)

Mobile-first indexing ne veut pas dire "Google favorise les sites mobiles dans le classement". Cela signifie que Googlebot utilise exclusivement le user-agent smartphone pour découvrir, crawler et indexer vos pages. Le contenu que Googlebot voit sur la version mobile est celui qui entre dans l'index. Point.

Concrètement, Googlebot envoie des requêtes avec cet user-agent :

Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/W.X.Y.Z Mobile Safari/537.36 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)

Si votre serveur détecte cet user-agent et retourne une version allégée de la page — moins de texte, moins de liens internes, pas de structured data — c'est cette version appauvrie qui sera indexée. Pas celle que vous voyez sur votre desktop.

Les trois architectures et leurs risques

Responsive design (une seule URL, même HTML, CSS media queries) : c'est le cas le plus sûr. Le contenu est identique ; seule la présentation change. Mais attention : du contenu masqué via display: none ou des tabs/accordéons JavaScript peut ne pas être rendu par Googlebot si le JS échoue.

Dynamic serving (une seule URL, HTML différent selon le user-agent) : le risque principal est la parité de contenu. Un middleware qui détecte le user-agent et sert un template mobile simplifié peut supprimer des sections entières — FAQ, tableaux comparatifs, blocs de liens internes — sans que personne ne s'en rende compte.

URLs séparées (m.example.com) : le cas le plus dangereux. Vous maintenez deux bases de contenu. La version mobile est souvent un sous-ensemble appauvri de la version desktop. Et les canonical/alternate rel doivent être irréprochables pour éviter les problèmes de contenu dupliqué.

La recommandation officielle de Google depuis des années est le responsive design. Si vous êtes encore sur une architecture m. en 2026, la migration devrait être votre priorité.

Vérifier la parité de contenu entre mobile et desktop

C'est le point le plus critique. Quand on parle de parité, on parle de trois choses distinctes : le contenu textuel, les liens internes, et les données structurées.

Contenu textuel

Chaque élément de contenu visible sur desktop doit être présent dans le DOM de la version mobile. Cela inclut les textes dans les accordéons, les onglets, les sections "lire la suite".

Google a confirmé que le contenu dans les accordéons et les tabs est traité comme du contenu normal, même s'il nécessite une interaction utilisateur pour être affiché. Mais — et c'est un edge case fréquent — si ce contenu est chargé via un appel AJAX au clic (lazy-loaded), Googlebot ne le verra pas. Le contenu doit être dans le DOM initial ou dans le HTML rendu côté serveur.

Voici un pattern problématique courant en React :

// ❌ Problème : le contenu de l'accordéon n'est chargé qu'au clic
function ProductFAQ({ productId }: { productId: string }) {
  const [faqData, setFaqData] = useState(null);
  const [isOpen, setIsOpen] = useState(false);

  const handleClick = async () => {
    if (!faqData) {
      const res = await fetch(`/api/faq/${productId}`);
      setFaqData(await res.json());
    }
    setIsOpen(!isOpen);
  };

  return (
    <div>
      <button onClick={handleClick}>Questions fréquentes</button>
      {isOpen && faqData && (
        <div className="faq-content">
          {faqData.map((item: any) => (
            <div key={item.id}>
              <h3>{item.question}</h3>
              <p>{item.answer}</p>
            </div>
          ))}
        </div>
      )}
    </div>
  );
}

La version corrigée pré-charge les données et inclut le contenu dans le DOM initial :

// ✅ Le contenu est dans le DOM dès le rendu initial (SSR ou SSG)
function ProductFAQ({ faqData }: { faqData: FAQItem[] }) {
  const [isOpen, setIsOpen] = useState(false);

  return (
    <div>
      <button onClick={() => setIsOpen(!isOpen)} aria-expanded={isOpen}>
        Questions fréquentes
      </button>
      {/* Contenu dans le DOM, masqué visuellement par CSS */}
      <div
        className="faq-content"
        style={{ display: isOpen ? 'block' : 'none' }}
      >
        {faqData.map((item) => (
          <div key={item.id}>
            <h3>{item.question}</h3>
            <p>{item.answer}</p>
          </div>
        ))}
      </div>
    </div>
  );
}

// Les données sont chargées côté serveur (Next.js App Router)
export async function generateStaticParams() { /* ... */ }

Pour comparer systématiquement le DOM mobile et desktop, la méthode la plus fiable est d'utiliser Screaming Frog en mode rendu JavaScript, en faisant deux crawls : un avec le user-agent Googlebot desktop, un avec Googlebot mobile. Exportez les deux datasets et comparez le word count, le nombre de liens internes, et la présence des balises <h1> à <h3> par URL. Sur un site de 8 000 pages, cela prend environ 45 minutes de crawl par passe (avec un crawl rate raisonnable de 3 URLs/seconde).

Pour des comparaisons plus fines entre le rendu SSR et le rendu CSR, cet article sur les divergences SSR/CSR détaille la méthodologie complète.

Liens internes

C'est le piège le plus fréquent. Beaucoup de sites desktop utilisent des mega menus avec des centaines de liens internes. Sur mobile, ce mega menu est remplacé par un hamburger menu simplifié qui ne contient que les catégories de premier niveau.

Résultat : des dizaines de pages profondes perdent leurs liens internes entrants depuis la navigation. Pour Googlebot mobile, ces pages deviennent plus difficiles à découvrir et à crawler. L'impact sur le crawl budget est direct — sujet que nous détaillons dans l'article sur les mega menus et le crawl budget.

Vérifiez la distribution des liens internes entre les deux versions. Si votre menu desktop contient 120 liens et votre menu mobile 25, vous avez un delta de 95 liens internes sur chaque page du site. Multipliez par 8 000 pages et vous comprenez l'impact sur la structure de liens interne.

Données structurées

Toutes les balises <script type="application/ld+json"> présentes sur desktop doivent être identiques sur mobile. Pas "similaires" — identiques. Même chose pour les microdonnées itemscope si vous les utilisez encore.

Un cas typique : un site e-commerce injecte les données Product structured data uniquement via un composant qui n'est rendu que sur desktop. La version mobile affiche bien le prix et les avis, mais le JSON-LD est absent du HTML.

Utilisez le test de résultat enrichi de Google (search.google.com/test/rich-results) en mode mobile pour vérifier chaque template.

Diagnostiquer les problèmes de rendu mobile avec les bons outils

Search Console : l'inspection d'URL en mode mobile

L'outil "Inspection d'URL" de la Search Console affiche le HTML rendu tel que Googlebot le voit. Depuis le passage complet au mobile-first, ce rendu est celui du user-agent mobile. Regardez deux choses :

Le HTML rendu : cliquez sur "Afficher la page testée" > "HTML". Cherchez-y vos contenus critiques (descriptions produit, FAQ, liens internes de navigation).
La capture d'écran : elle montre le rendu visuel. Si des éléments se chevauchent, débordent de l'écran ou sont trop petits pour être tapés, Google le voit aussi.

Si vous constatez des écarts entre ce que vous attendez et ce que Google voit, il y a probablement un problème de rendu JavaScript ou de serving conditionnel. L'article sur les rapports Search Console souvent ignorés couvre d'autres checks utiles dans la console.

Chrome DevTools : simuler Googlebot mobile

La méthode la plus rapide pour un diagnostic ponctuel :

Ouvrez Chrome DevTools (F12)
Activez le Device Mode (Ctrl+Shift+M)
Sélectionnez "Nexus 5X" comme device (c'est le device de référence de Googlebot)
Dans l'onglet Network, cochez "Disable cache"
Dans le menu à trois points > More tools > Network conditions, remplacez le user-agent par celui de Googlebot mobile

Cela vous donne une approximation du rendu. Ce n'est pas identique au rendu de Googlebot (qui utilise une version headless de Chrome avec des spécificités), mais cela détecte les problèmes les plus flagrants. Pour aller plus loin, consultez nos astuces avancées avec Chrome DevTools pour le SEO.

Screaming Frog : crawl comparatif desktop vs mobile

Voici la configuration pour un crawl mobile-first dans Screaming Frog :

Configuration > User-Agent : sélectionnez "Googlebot Smartphone"
Configuration > Spider > Rendering : activez "JavaScript" avec le moteur Chromium
Configuration > Spider > Crawl : limitez à vos templates principaux via des regex d'inclusion si le site est volumineux

Lancez un premier crawl en Googlebot Smartphone, exportez en CSV. Lancez un second en Googlebot Desktop, exportez. Comparez ces colonnes par URL :

Word Count (parité de contenu)
Inlinks (parité de liens internes)
Structured Data (parité des données structurées)
H1, H2 Count (structure de heading)
Indexability (mêmes pages indexables dans les deux versions)

Un script Python rapide pour automatiser la comparaison :

import pandas as pd

mobile = pd.read_csv('crawl_mobile.csv', usecols=['Address', 'Word Count', 'Inlinks', 'Indexability'])
desktop = pd.read_csv('crawl_desktop.csv', usecols=['Address', 'Word Count', 'Inlinks', 'Indexability'])

merged = mobile.merge(desktop, on='Address', suffixes=('_mobile', '_desktop'))

# Pages où le contenu mobile est significativement plus court
merged['word_delta'] = merged['Word Count_desktop'] - merged['Word Count_mobile']
content_gaps = merged[merged['word_delta'] > 100].sort_values('word_delta', ascending=False)

# Pages où les liens internes diffèrent fortement
merged['link_delta'] = merged['Inlinks_desktop'] - merged['Inlinks_mobile']
link_gaps = merged[merged['link_delta'] > 10].sort_values('link_delta', ascending=False)

# Pages indexables sur desktop mais pas sur mobile
indexability_issues = merged[
    (merged['Indexability_desktop'] == 'Indexable') &
    (merged['Indexability_mobile'] != 'Indexable')
]

print(f"Pages avec écart de contenu > 100 mots : {len(content_gaps)}")
print(f"Pages avec écart de liens internes > 10 : {len(link_gaps)}")
print(f"Pages indexables desktop mais pas mobile : {len(indexability_issues)}")

content_gaps.to_csv('content_parity_issues.csv', index=False)
link_gaps.to_csv('link_parity_issues.csv', index=False)
indexability_issues.to_csv('indexability_issues.csv', index=False)

Scénario concret : migration d'un e-commerce de 15K pages

Voici un cas réaliste. Un site e-commerce de vêtements — 15 000 pages produit, 200 pages catégorie, 50 pages de contenu éditorial — tourne sur une architecture dynamic serving. Le backend Django détecte le user-agent et sert des templates différents pour mobile et desktop.

Le diagnostic

Un crawl Screaming Frog comparatif révèle :

2 300 pages produit ont un word count mobile inférieur de 150+ mots au desktop. Cause : le tableau des caractéristiques techniques (<table class="specs">) est supprimé du template mobile pour "gagner de la place".
180 pages catégorie perdent entre 40 et 90 liens internes sur mobile. Cause : la sidebar desktop affiche des liens vers les sous-catégories et les filtres populaires. Sur mobile, cette sidebar est purement supprimée (pas repliée — supprimée du DOM).
Toutes les pages produit perdent le JSON-LD Product. Le bloc <script type="application/ld+json"> est inclus dans un partial Django chargé uniquement dans le template desktop : {% include "partials/structured_data.html" %} est absent du template product_mobile.html.

L'impact mesuré

Après investigation dans la Search Console, les résultats enrichis (prix, disponibilité, avis) ont progressivement disparu des SERPs sur 4 mois — période pendant laquelle Google a basculé l'indexation du site vers mobile-first. Le trafic organique a baissé de 23% sur les pages produit, non pas à cause d'une pénalité, mais parce que :

La perte des résultats enrichis a réduit le CTR d'environ 15-20% (les snippets avec prix et étoiles attirent mécaniquement plus de clics).
Le contenu indexé étant plus pauvre (pas de tableau de spécifications), les pages se positionnent moins bien sur les requêtes longue traîne liées aux caractéristiques techniques.
La perte de liens internes sur mobile réduit le PageRank interne vers les sous-catégories, affectant leur crawl et leur indexation.

La correction

La solution retenue : migration vers un responsive design unique. Plus de dynamic serving, un seul template par type de page. Le tableau de spécifications est affiché dans un accordéon sur mobile (contenu dans le DOM, masqué par CSS). La sidebar est transformée en section horizontale scrollable en haut de la page catégorie sur mobile. Le JSON-LD est inclus dans le template de base, indépendamment du device.

Temps de correction : 3 semaines de développement, 1 semaine de QA, déploiement progressif par template. Récupération du trafic perdu en environ 6 semaines après le re-crawl complet par Google.

Ce type de régression silencieuse — où le contenu disparaît sans qu'aucune alerte ne se déclenche — est exactement ce qui justifie un monitoring SEO continu plutôt que des audits trimestriels. Un outil comme Seogard aurait détecté la disparition du structured data et la chute du word count dès le premier crawl post-changement.

Performance mobile : au-delà du responsive

Avoir un contenu paritaire ne suffit pas si vos pages mettent 8 secondes à se charger sur mobile. Google utilise les Core Web Vitals mesurés sur les sessions mobiles réelles (données CrUX) comme signal de classement.

LCP mobile : le goulot d'étranglement le plus fréquent

Le Largest Contentful Paint sur mobile est presque toujours plus élevé que sur desktop, pour trois raisons : bande passante plus faible, CPU moins puissant, et images souvent surdimensionnées.

Vérifiez votre config d'images responsive :

<!-- ❌ Image unique en pleine résolution -->
<img src="/images/product-hero-1920x1080.jpg" alt="Robe en lin naturel">

<!-- ✅ Images responsive avec srcset et sizes -->
<img
  src="/images/product-hero-800x450.webp"
  srcset="
    /images/product-hero-400x225.webp 400w,
    /images/product-hero-800x450.webp 800w,
    /images/product-hero-1200x675.webp 1200w,
    /images/product-hero-1920x1080.webp 1920w
  "
  sizes="(max-width: 768px) 100vw, (max-width: 1200px) 80vw, 1200px"
  alt="Robe en lin naturel"
  width="1920"
  height="1080"
  loading="eager"
  fetchpriority="high"
>

L'attribut fetchpriority="high" sur l'image LCP est sous-utilisé. Il indique au navigateur de prioriser le téléchargement de cette ressource, ce qui réduit le LCP de 100-300ms sur des connexions 4G selon les tests documentés sur web.dev.

Pour un suivi continu de ces métriques, Lighthouse CI est l'approche la plus robuste en intégration continue.

Le viewport meta tag

Basique mais toujours source d'erreurs. Si cette balise est absente ou mal configurée, Google considère que la page n'est pas adaptée au mobile :

<!-- La seule valeur correcte -->
<meta name="viewport" content="width=device-width, initial-scale=1">

<!-- ❌ Problématique : empêche le zoom (accessibilité + signal négatif) -->
<meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1, user-scalable=no">

Le user-scalable=no et maximum-scale=1 ne sont pas des signaux négatifs directs pour le classement, mais ils sont flaggés dans Lighthouse comme des problèmes d'accessibilité. Et un site qui bloque le zoom sera moins bien noté sur le rapport "Expérience sur la page" de la Search Console.

Ressources bloquées par robots.txt

Un piège classique : votre fichier robots.txt bloque des fichiers CSS ou JavaScript nécessaires au rendu mobile. Si Googlebot ne peut pas charger votre framework CSS responsive, il voit la page sans mise en forme — et peut considérer que le contenu n'est pas mobile-friendly.

Vérifiez avec l'outil d'inspection d'URL de la Search Console. Dans la section "Plus d'informations" > "Ressources de la page", cherchez les ressources marquées comme bloquées. Les CDN tiers (polices, CSS frameworks) sont les coupables les plus fréquents.

Configuration serveur : les pièges du dynamic serving

Si vous servez un contenu différent selon le user-agent (dynamic serving), vous devez envoyer le header HTTP Vary: User-Agent. Sans ce header, les caches intermédiaires (CDN, proxy) peuvent servir la version desktop à Googlebot mobile, ou inversement.

# Configuration Nginx pour dynamic serving
server {
    listen 443 ssl;
    server_name shop.example.fr;

    # Détection mobile via user-agent
    set $mobile_rewrite do_not_perform;

    if ($http_user_agent ~* "(android|bb\d+|meego).+mobile|avantgo|bada\/|blackberry|blazer|compal|elaine|fennec|hiptop|iemobile|ip(hone|od)|iris|kindle|lge |maemo|midp|mmp|mobile.+firefox|netfront|opera m(ob|in)i|palm( os)?|phone|p(ixi|re)\/|plucker|pocket|psp|series(4|6)0|symbian|treo|up\.(browser|link)|vodafone|wap|windows ce|xda|xiino") {
        set $mobile_rewrite perform;
    }

    location / {
        # Header Vary obligatoire pour le cache
        add_header Vary "User-Agent";

        if ($mobile_rewrite = perform) {
            # Servir le template mobile
            proxy_pass http://backend_mobile;
            break;
        }

        proxy_pass http://backend_desktop;
    }
}

Deux points importants :

Le header Vary: User-Agent est essentiel. Sans lui, Cloudflare ou Fastly pourraient cacher la version desktop et la servir à tous les user-agents pendant la durée du TTL. C'est documenté dans les recommandations Google sur le mobile-first indexing.
Les regex de détection user-agent doivent inclure le user-agent Googlebot mobile. Testez explicitement que votre condition matche "Googlebot/2.1" combiné avec "Mobile". Un mauvais regex est une cause fréquente de serving incorrect.

Cela dit, la recommandation reste de migrer vers du responsive design pur. Le dynamic serving est une source constante de bugs et de régressions SEO difficiles à détecter — surtout lors des déploiements. Un déploiement mal préparé peut casser la logique de serving sans que personne ne s'en aperçoive pendant des jours.

Checklist mobile-first : les vérifications à automatiser

Voici les vérifications à intégrer dans votre pipeline CI/CD ou votre routine de monitoring. Chaque point est un signal binaire — ça passe ou ça casse.

Vérifications de parité

Le word count de chaque template en user-agent mobile est ≥ 95% du word count desktop
Le nombre de liens internes dans la navigation est identique (± 5%) entre mobile et desktop
Tous les blocs <script type="application/ld+json"> présents sur desktop sont présents sur mobile
Les balises <h1> sont identiques entre les deux versions
Les balises canonical, hreflang, et meta robots sont identiques
Les images ont des attributs alt identiques dans les deux versions

Vérifications techniques

La balise <meta name="viewport"> est présente et correctement configurée
Aucune ressource CSS/JS critique n'est bloquée par robots.txt
Le temps de réponse serveur (TTFB) en user-agent mobile est < 800ms
Le LCP mobile est < 2.5s sur les templates principaux
Les éléments interactifs ont une zone de tap ≥ 48x48px
Pas de contenu qui déborde horizontalement (pas de scrollbar horizontal)

Vérifications de configuration

Le header Vary: User-Agent est envoyé si le site utilise du dynamic serving
Les redirections mobile (si existantes) fonctionnent dans les deux sens (desktop → mobile ET mobile → desktop)
Les pages m. ont des balises rel="canonical" qui pointent vers la version desktop, et les pages desktop ont des balises rel="alternate" media="only screen and (max-width: 640px)" qui pointent vers la version mobile

L'automatisation de ces checks dans votre pipeline CI/CD est la meilleure assurance contre les régressions. Nous détaillons l'implémentation dans l'article sur l'automatisation des checks SEO en CI/CD.

Pour les vérifications continues post-déploiement, la configuration des alertes SEO avec les bons seuils est critique. Une chute de 20% du word count sur un template détectée en 24h est récupérable. La même chute détectée 3 mois plus tard lors d'un audit trimestriel a déjà causé des dégâts durables.

Les edge cases à ne pas ignorer

Les lazy-loaded iframes : si vous intégrez des vidéos YouTube ou des widgets tiers via des iframes lazy-loaded, vérifiez que le placeholder contient du contenu textuel pertinent. Googlebot ne chargera pas forcément l'iframe sur la version mobile s'il juge que le viewport ne l'atteint pas. Pour les pages qui reposent sur le infinite scroll, le problème est amplifié.

Les interstitiels mobile : les pop-ups qui couvrent le contenu principal sur mobile sont un signal négatif explicite depuis janvier 2017. Google ne pénalise pas les interstitiels liés aux cookies (obligation légale), mais un interstitiel marketing qui recouvre 80% de l'écran mobile va impacter votre classement.

Les pages AMP : si vous avez encore des pages AMP couplées à des pages canoniques non-AMP, sachez que Google indexe la version canonical (non-AMP). Assurez-vous que la canonical est elle-même mobile-friendly. L'AMP a été en grande partie abandonné comme format prioritaire par Google, mais les implementations legacy restent une source de confusion dans les rapports Search Console.

Le contenu conditionnel par géolocalisation : si vous servez du contenu différent en fonction de l'IP (variante de dynamic serving), assurez-vous que le contenu servi à Googlebot — qui crawle depuis des IP américaines — est représentatif de votre contenu cible. C'est particulièrement pertinent si votre structure d'URL utilise des sous-répertoires de langue.

Le mobile-first indexing n'est plus une migration à planifier — c'est l'état par défaut. La question n'est pas "quand est-ce que ça arrive" mais "est-ce que mon site sert exactement le même contenu, les mêmes liens, les mêmes données structurées à Googlebot mobile qu'à Googlebot desktop". Si vous n'avez pas fait ce diagnostic récemment, lancez un crawl comparatif cette semaine. Et pour éviter que ce type de divergence ne se réinstalle silencieusement après chaque déploiement, un monitoring continu avec Seogard vous alerte dès qu'une parité de contenu est rompue — avant que l'impact SEO ne soit visible dans vos dashboards de trafic.