Pourquoi Google n'indexe pas vos pages : diagnostic complet

Vous avez 12 000 pages dans votre sitemap, mais Search Console en affiche 4 200 comme "indexées". Les 7 800 restantes sont réparties entre "Discovered – currently not indexed", "Crawled – currently not indexed" et une poignée de statuts plus obscurs. Le problème n'est pas que Google "ne veut pas" de vos pages — c'est qu'il existe au moins une dizaine de raisons techniques distinctes pour lesquelles une page ne franchit pas le pipeline d'indexation, et chacune exige un diagnostic différent.

Le pipeline d'indexation : comprendre où ça coince

Avant de chercher la cause, il faut savoir à quelle étape la page est bloquée. Google documente quatre phases principales dans son guide sur le fonctionnement de la recherche : découverte, crawl, rendu, indexation.

Découverte vs. crawl vs. indexation

Discovered – currently not indexed signifie que Google connaît l'URL (via un sitemap, un lien interne, ou une soumission manuelle), mais n'a pas encore jugé utile de la crawler. La page est dans la file d'attente. Ce n'est pas une erreur technique — c'est un signal de priorisation.

Crawled – currently not indexed est plus préoccupant : Google a récupéré le HTML, l'a analysé, et a décidé de ne pas l'inclure dans l'index. Les raisons possibles : contenu trop mince, contenu dupliqué, qualité insuffisante, ou signal technique ambigu (canonical mal configuré, par exemple).

Indexed, not submitted in sitemap est souvent ignoré mais révélateur : des pages que vous n'avez pas déclarées finissent indexées, tandis que celles que vous voulez pousser restent dehors. C'est un indicateur de décalage entre votre architecture de site et ce que Google perçoit comme important.

Lire le rapport de couverture efficacement

Dans Search Console, le rapport "Pages" (anciennement "Couverture") est votre point d'entrée. La méthode :

Filtrez par sitemap spécifique pour isoler un segment (catégorie produit, blog, pages locales).
Examinez les statuts "Not indexed" un par un — chaque raison a sa propre logique de résolution.
Croisez avec les données de crawl stats (Paramètres > Statistiques d'exploration) pour vérifier si le taux de crawl est le goulot d'étranglement.

Un site e-commerce de 15 000 pages produit avec un budget crawl limité peut voir Google explorer 800 pages/jour. À ce rythme, un renouvellement complet du catalogue (2 000 nouvelles fiches/mois) crée un retard structurel : les nouvelles pages entrent dans la file "Discovered" plus vite que Google ne les consomme.

Les blocages techniques au niveau du crawl

Le problème le plus fréquent — et le plus facilement corrigeable — est un blocage pur et simple de l'accès de Googlebot aux pages.

Robots.txt : le blocage silencieux

Un Disallow trop large dans le robots.txt est la cause n°1 des problèmes d'indexation sur les sites qui ont subi des migrations ou des refontes. Le piège classique : un environnement de staging avec un Disallow: / qui se retrouve en production.

# Erreur fréquente après migration — robots.txt de staging oublié
User-agent: *
Disallow: /

# Ce que vous vouliez probablement :
User-agent: *
Disallow: /staging/
Disallow: /admin/
Disallow: /api/
Allow: /

Sitemap: https://www.monaventure-outdoor.fr/sitemap.xml

Vérifiez toujours avec l'outil de test robots.txt dans Search Console. Pour un diagnostic plus large, Screaming Frog permet de scanner toutes vos URLs et de flagger celles bloquées par robots.txt — configurez-le en mode "respecter robots.txt" puis comparez avec un crawl en mode "ignorer robots.txt". La différence entre les deux résultats vous donne la liste exacte des pages bloquées.

Pour un guide détaillé sur la configuration, consultez notre guide complet du robots.txt.

Réponses HTTP : 5xx, timeouts, et soft 404

Googlebot a une tolérance limitée aux erreurs serveur. Quelques 503 sporadiques ne posent pas de problème, mais si votre serveur renvoie des 5xx de manière récurrente sur un segment d'URLs, Google réduit la fréquence de crawl pour l'ensemble du site. C'est documenté dans les recommandations de Google sur les codes HTTP.

Le cas pernicieux est le soft 404 : votre serveur renvoie un 200, mais le contenu de la page est une page d'erreur ("Produit non disponible", "Aucun résultat", page quasi-vide). Google détecte ces pages et les traite comme des 404, mais sans vous le dire clairement. Pour les identifier :

# Utiliser curl pour vérifier le code HTTP et la taille de la réponse
# Les soft 404 ont souvent une taille de réponse anormalement petite
for url in $(cat urls-to-check.txt); do
  status=$(curl -o /dev/null -s -w "%{http_code}|%{size_download}" "$url")
  echo "$url | $status"
done

# Exemple de sortie révélatrice :
# https://www.monaventure-outdoor.fr/produit/tente-2p-alpine | 200|48230
# https://www.monaventure-outdoor.fr/produit/sac-couchage-x3 | 200|1847  ← soft 404 probable
# https://www.monaventure-outdoor.fr/produit/gourde-isotherme | 200|47891

Une page produit qui fait 1 847 octets alors que les autres font 48 000+ octets, c'est un soft 404. Le correctif : renvoyez un vrai 404 ou un 410 (Gone) pour les produits supprimés, et assurez-vous que les pages de catégorie sans résultats servent un noindex ou un contenu substantiel.

Le crawl budget en pratique

Le crawl budget est un non-sujet pour un site de 500 pages. Il devient critique au-delà de 50 000 URLs crawlables, ou dès que votre rapport de statistiques d'exploration montre un plafonnement du nombre de requêtes/jour.

Les causes fréquentes de gaspillage de crawl budget :

Pages à paramètres non canonicalisées : /produit/chaussure?color=rouge&size=42 × 200 combinaisons pour chaque produit. Résultat : 3 millions d'URLs pour 15 000 produits.
Facettes de filtrage indexables : chaque combinaison de filtre génère une URL distincte.
Pages de pagination infinies sans noindex ou sans lien rel="next" (même si Google ne l'utilise plus comme signal de pagination, ça reste un indicateur de structure).

La solution passe par une combinaison de canonicaux bien configurés, de directives robots.txt ciblées, et d'un sitemap.xml qui ne contient que les pages à indexer.

Les blocages au niveau du rendu : le piège JavaScript

C'est le problème le plus sous-estimé sur les architectures modernes. Google exécute le JavaScript, mais pas toujours, pas immédiatement, et pas complètement.

Le décalage entre crawl et rendu

Google utilise une architecture en deux passes : le crawl initial récupère le HTML brut, puis le contenu est mis en file d'attente pour le rendering (exécution JS via un Chromium headless). Ce deuxième passage peut survenir des heures, voire des jours après le crawl initial. Pendant ce délai, Google indexe ce qu'il voit dans le HTML brut — et si votre contenu principal est injecté par JavaScript, il indexe potentiellement une page vide.

Pour vérifier ce que Google voit réellement sur vos pages, suivez notre guide de test du rendu Google. La méthode rapide :

// Script pour comparer le HTML initial et le DOM rendu
// Exécutez dans Chrome DevTools > Console

// 1. Contenu visible dans le HTML source (View Source)
const initialHTML = document.documentElement.innerHTML;

// 2. Pour voir ce que le HTML brut contient (avant JS) :
// curl -s https://www.monaventure-outdoor.fr/categorie/tentes | grep -c '<h1>'
// Si ça retourne 0, votre H1 dépend de JavaScript

// 3. Vérifiez les meta tags critiques dans le HTML source
fetch(window.location.href)
  .then(r => r.text())
  .then(html => {
    const parser = new DOMParser();
    const doc = parser.parseFromString(html, 'text/html');
    
    console.log('=== HTML brut (avant JS) ===');
    console.log('Title:', doc.querySelector('title')?.textContent || 'ABSENT');
    console.log('Meta description:', 
      doc.querySelector('meta[name="description"]')?.content || 'ABSENT');
    console.log('Canonical:', 
      doc.querySelector('link[rel="canonical"]')?.href || 'ABSENT');
    console.log('H1:', doc.querySelector('h1')?.textContent || 'ABSENT');
    console.log('Nombre de liens internes:', 
      doc.querySelectorAll('a[href^="/"]').length);
  });

Si le title, le H1, ou la meta description sont absents du HTML brut, vous avez un problème de rendu. Google finira peut-être par les voir après le rendering, mais "peut-être" et "finira" ne sont pas des stratégies d'indexation. Pour en savoir plus sur les solutions, consultez notre article sur le prerendering et les implications du dynamic rendering.

Scénario réel : migration SPA vers SSR

Un e-commerce outdoor (15 000 fiches produit, 800 pages catégories) fonctionnait sur une SPA React avec client-side rendering pur. Situation avant migration :

15 800 URLs soumises dans le sitemap
3 200 indexées (20 %)
9 400 en statut "Discovered – currently not indexed"
3 200 en statut "Crawled – currently not indexed"
Trafic organique : 12 000 sessions/mois

Après migration vers Next.js avec SSR (Server-Side Rendering), les résultats sur 8 semaines :

Semaine 1-2 : le nombre de pages crawlées/jour passe de 400 à 1 800 (visible dans les stats d'exploration Search Console)
Semaine 3-4 : les pages "Discovered – currently not indexed" passent de 9 400 à 4 100
Semaine 6-8 : 11 200 pages indexées (71 %), trafic à 34 000 sessions/mois

Le facteur déterminant n'était pas que Google "ne pouvait pas" rendre le JS — c'est que la file d'attente de rendu créait un délai tel que Google ne jugeait pas prioritaire de traiter ces pages. Le passage en SSR a éliminé cette dépendance.

Les directives contradictoires : quand vous bloquez l'indexation sans le savoir

C'est la catégorie de problèmes la plus frustrante car elle est invisible sans audit systématique.

Meta robots, X-Robots-Tag, et leurs interactions

Une page peut être bloquée à l'indexation par trois mécanismes distincts, et ils ne se comportent pas de la même façon :

<meta name="robots" content="noindex"> dans le HTML — le plus courant.
X-Robots-Tag: noindex dans les headers HTTP — utilisé pour les PDF, images, et parfois ajouté par le CDN ou le reverse proxy sans que l'équipe SEO le sache.
robots.txt Disallow — empêche le crawl, donc Google ne voit même pas les directives meta robots.

Le piège de l'interaction : si robots.txt bloque l'accès ET que vous avez un noindex dans la page, Google ne verra jamais le noindex (puisqu'il ne crawle pas la page). Résultat paradoxal : la page peut rester indexée si elle l'était avant l'ajout du Disallow, car Google n'a aucun moyen de savoir que vous avez ajouté un noindex. C'est une subtilité que beaucoup de professionnels ignorent.

<!-- Vérifiez TOUS les signaux d'indexation sur une page -->

<!-- 1. Meta robots dans le <head> -->
<meta name="robots" content="noindex, nofollow">

<!-- 2. Meta robots spécifique à Googlebot (prioritaire sur le générique) -->
<meta name="googlebot" content="noindex">

<!-- 3. Canonical qui pointe ailleurs (indexation déplacée) -->
<link rel="canonical" href="https://www.monaventure-outdoor.fr/autre-page/">

<!-- 4. Dans les headers HTTP (invisible dans le HTML) : -->
<!-- X-Robots-Tag: noindex -->
<!-- Vérifiable avec : curl -I https://www.monaventure-outdoor.fr/ma-page/ -->

Pour un audit complet des balises meta robots et de leurs variantes, consultez notre guide meta robots noindex/nofollow.

Canonicaux mal configurés

Le canonical est un signal, pas une directive. Google peut le suivre ou l'ignorer. Mais un canonical qui pointe vers la mauvaise page est un signal puissant de "ne m'indexe pas moi, indexe cette autre URL".

Les cas classiques de canonicaux destructeurs :

Canonical vers HTTP au lieu de HTTPS : <link rel="canonical" href="http://www.monaventure-outdoor.fr/produit/tente/"> alors que le site est en HTTPS. Google peut ignorer ce canonical, ou le suivre et créer une confusion.
Canonical vers une page 404 : après une migration, les canonicaux n'ont pas été mis à jour. La page canonique n'existe plus.
Canonical auto-référent absent : sans canonical explicite, Google choisit la version canonique qu'il préfère. Avec des paramètres d'URL, ça peut être la version avec ?utm_source=newsletter.

Screaming Frog, en mode "crawl", vous donne la colonne "Canonical Link Element 1" pour chaque URL. Exportez, filtrez les canonicaux qui ne pointent pas vers eux-mêmes, et vérifiez chacun. Notre guide définitif des canonicaux couvre les edge cases en détail.

La qualité du contenu comme facteur de non-indexation

Google le dit explicitement dans sa documentation : toutes les pages découvertes ne méritent pas d'être indexées. Le statut "Crawled – currently not indexed" est souvent un jugement de qualité, pas un problème technique.

Le seuil de qualité pour l'indexation

Google n'indexe pas une page si elle n'apporte pas de valeur ajoutée par rapport à ce qui est déjà dans l'index. C'est le critère le plus flou, mais les signaux sont cohérents :

Contenu thin : fiches produit avec uniquement un titre, un prix, et une photo. Pas de description, pas d'avis, pas de spécifications techniques. Google a des milliards de pages à gérer — une fiche produit de 50 mots ne passe pas le filtre.
Contenu dupliqué intra-site : 200 pages de villes pour un service de plomberie avec le même texte et juste le nom de la ville qui change. Google en indexe 3 et ignore les 197 autres.
Contenu dupliqué inter-site : descriptions produits copiées du fournisseur, utilisées par 400 revendeurs. Google choisit une seule version canonique — rarement la vôtre si vous n'avez pas la plus forte autorité de domaine.

La cannibalisation de contenu est un cas particulier : plusieurs pages de votre propre site ciblent la même intention de recherche. Google hésite, indexe tantôt l'une tantôt l'autre, et parfois déclasse les deux.

Audit de contenu systématique

Pour un site de 10 000+ pages, l'approche manuelle ne tient pas. Voici la méthode :

Exportez la liste complète des URLs indexées depuis Search Console (Performance > Pages).
Exportez la liste des URLs du sitemap.
La différence entre les deux = vos pages non indexées.
Crawlez ces pages avec Screaming Frog et extrayez : word count, nombre de liens internes entrants, présence de H1, meta description, title tag.
Les pages avec < 300 mots, 0 liens internes entrants, et pas de title unique sont vos candidates à la suppression, la fusion, ou l'enrichissement.

L'architecture de liens internes : le facteur invisible

Une page sans lien interne est une page orpheline. Google peut la découvrir via le sitemap, mais le sitemap est un signal faible comparé au maillage interne. Si votre page n'est reliée par aucun lien depuis d'autres pages du site, Google interprète ça comme un signal de faible importance.

Détecter les pages orphelines

# Avec Screaming Frog CLI (ou l'interface graphique)
# 1. Crawlez votre site complet
# 2. Exportez le rapport "Inlinks" pour chaque URL
# 3. Identifiez les pages avec 0 inlinks (hors sitemap)

# Approche rapide avec un sitemap et un crawl :
# Extraire les URLs du sitemap
curl -s https://www.monaventure-outdoor.fr/sitemap.xml | \
  grep -oP '<loc>\K[^<]+' > sitemap-urls.txt

# Comparer avec les URLs trouvées par crawl
# (exportées depuis Screaming Frog : Internal > HTML > Export)
comm -23 <(sort sitemap-urls.txt) <(sort crawled-urls.txt) > orphan-pages.txt

# orphan-pages.txt contient les URLs présentes dans le sitemap
# mais non découvertes par le crawl = pages orphelines

Sur un site e-commerce, les pages orphelines typiques sont :

Les fiches produit retirées de la navigation mais encore dans le sitemap.
Les pages de blog anciennes, délistées des archives mais jamais redirigées ni supprimées.
Les landing pages de campagnes passées, sans lien depuis la structure principale.

La résolution est binaire : soit la page a de la valeur et vous la reliez au maillage interne (lien depuis une page catégorie, depuis un article de blog connexe, depuis le footer ou une sidebar), soit elle n'en a pas et vous la supprimez proprement (301 ou 410).

Le poids du maillage interne dans la priorisation du crawl

Google le confirme dans sa documentation sur le crawl budgeting : les pages avec davantage de liens internes sont crawlées plus fréquemment. Ce n'est pas un facteur de ranking direct, mais c'est un facteur d'indexation.

Un test simple : prenez 50 pages en statut "Discovered – currently not indexed" et ajoutez un lien interne contextuel depuis une page bien crawlée (votre homepage, une page catégorie de premier niveau, un article de blog populaire). Suivez le statut dans Search Console sur 2-3 semaines. Dans la majorité des cas, ces pages passent en "Indexed" sans autre modification.

Le workflow de diagnostic complet

Pour synthétiser, voici l'ordre de diagnostic à suivre quand une page n'est pas indexée :

Étape 1 : Vérifier l'accessibilité. La page est-elle bloquée par robots.txt ? Renvoie-t-elle un 200 ? Le temps de réponse est-il inférieur à 2 secondes ? Utilisez l'outil d'inspection d'URL dans Search Console ET un curl -I pour confirmer côté serveur.

Étape 2 : Vérifier les directives. Y a-t-il un noindex dans le HTML ou dans les headers HTTP ? Le canonical pointe-t-il vers la bonne URL ? La page est-elle dans le sitemap ? Consultez notre guide des meta tags SEO pour la checklist complète.

Étape 3 : Vérifier le rendu. Le contenu principal est-il visible dans le HTML brut, ou dépend-il de JavaScript ? L'outil "Test en direct" de Search Console vous montre le HTML rendu tel que Google le voit. S'il manque du contenu, c'est un problème de rendu.

Étape 4 : Vérifier la qualité. La page a-t-elle un contenu unique et substantiel ? Est-elle en concurrence avec d'autres pages de votre site sur la même requête ? Est-elle liée depuis le reste du site ?

Étape 5 : Vérifier la priorisation. Si tout est techniquement correct, le problème est que Google ne considère pas la page comme prioritaire. Solutions : renforcer le maillage interne, améliorer le contenu, et s'assurer que le sitemap ne contient que les pages que vous voulez réellement indexées (un sitemap de 50 000 URLs dont 30 000 sont des pages de filtrage dilue le signal).

Chacune de ces étapes peut être automatisée. Un outil de monitoring comme Seogard détecte en continu les régressions — un noindex ajouté par erreur lors d'un déploiement, un canonical cassé après une migration, un temps de réponse serveur qui se dégrade — avant que ces problèmes n'affectent votre couverture d'indexation.

Au-delà du diagnostic ponctuel

Les problèmes d'indexation ne sont pas des événements ponctuels. Ils reviennent à chaque déploiement, chaque migration, chaque modification de template. Le site qui indexait 90 % de ses pages en janvier peut tomber à 60 % en mars parce qu'un développeur a ajouté un noindex conditionnel mal paramétré sur le template de fiches produit. L'enjeu n'est pas de faire un audit une fois par an — c'est de mettre en place une surveillance continue qui attrape ces régressions dans les heures qui suivent le déploiement, pas trois semaines plus tard quand le trafic a déjà chuté.