Pourquoi Google découvre vos pages mais refuse de les indexer ?

Que signifie réellement « découvertes mais non indexées » ?

Ce statut Search Console recouvre deux scénarios distincts que beaucoup de praticiens confondent. Premier cas : Google a repéré l'URL — via un sitemap, un lien interne, un backlink — mais n'a jamais envoyé Googlebot récupérer le HTML. Second cas : Googlebot a bien crawlé la page, mais après analyse, le moteur a décidé de ne pas l'intégrer à l'index.

La nuance est capitale. Dans le premier scénario, le problème est en amont du rendu : crawl budget insuffisant, robots.txt bloquant, URL jugée non prioritaire. Dans le second, c'est une question de qualité ou de duplication perçue — Google a vu le contenu et l'a écarté.

Martin Splitt insiste sur un point technique : si Google n'a jamais récupéré le HTML, JavaScript n'est pas en cause. Le rendu JS intervient après le fetch initial — donc si Googlebot ne télécharge même pas la page, chercher un bug côté hydratation React est une perte de temps.

Quand ce statut devient-il problématique ?

Sur un site de 10 000 URLs, en avoir 500 découvertes mais non indexées n'est pas anormal. Google n'indexe pas tout par principe — il priorise selon sa perception de la valeur. Pages de pagination profonde, filtres produits redondants, contenus minces générés automatiquement : autant de candidats naturels à ce statut.

Ça coince quand des pages stratégiques — fiches produits phares, contenus piliers, landing pages — restent bloquées des semaines. Là, il faut creuser : pourquoi Google juge-t-il ces URLs non prioritaires ou non pertinentes ? Le signal peut venir d'un manque de liens internes, d'une profondeur de clic excessive, ou d'une cannibalisation avec des pages déjà indexées.

Comment identifier la cause racine ?

Search Console ne distingue pas clairement les deux sous-cas — c'est à vous de croiser les données. Allez dans l'onglet Exploration, filtrez par statut HTTP 200, et vérifiez la dernière date de crawl. Si elle est vide ou très ancienne, Google n'a jamais ou rarement crawlé. Si elle est récente mais l'indexation reste bloquée, c'est un rejet qualité.

Utilisez aussi les logs serveur — ils ne mentent pas. Cherchez les URLs concernées : si Googlebot ne les a jamais requêtées, le souci est architectural ou lié au budget. Si le bot passe régulièrement mais n'indexe pas, le problème est éditorial ou technique côté rendu.

• Découverte sans crawl = crawl budget, profondeur, robots.txt, absence de liens internes forts
• Crawl sans indexation = contenu dupliqué, thin content, canonical mal positionné, qualité perçue insuffisante
• JavaScript n'est pas en cause si Google n'a jamais fetch le HTML de base
• Ce statut n'est pas un bug — c'est un arbitrage explicite de Google
• L'échelle compte : 5 % d'URLs dans ce statut sur un gros site e-commerce est banal, 50 % sur un blog de 100 pages est un red flag

Cette déclaration est-elle cohérente avec les observations terrain ?

Oui, et c'est même l'un des rares points où Google est transparent. On observe effectivement deux profils d'URLs dans ce statut : celles jamais visitées (souvent des pages profondes, filtres, variantes) et celles crawlées puis écartées. La précision de Splitt sur JavaScript mérite qu'on s'y arrête — il coupe court à une excuse fréquente des devs front.

Mais soyons honnêtes : Google ne dit pas combien de temps il faut attendre avant de s'inquiéter. Une page découverte peut rester des mois dans ce statut sans que ça pose problème — ou révéler un problème structurel dès la première semaine. L'absence de seuils chiffrés rend le diagnostic opaque. [À vérifier] sur des volumes importants : Google applique-t-il des quotas implicites par secteur ou type de site ?

Quelles nuances faut-il apporter face à ce statut ?

Première nuance : ce n'est pas parce qu'une page est découverte mais non indexée qu'elle est interdite d'indexation à jamais. Un renforcement du maillage interne, un boost de popularité externe, ou une mise à jour de contenu peuvent débloquer la situation. Google réévalue constamment ses priorités — mais il ne le fait pas en temps réel.

Deuxième nuance : toutes les URLs ne méritent pas l'index. Un site e-commerce avec 50 000 références et 200 000 variantes couleur-taille doit arbitrer ce qu'il veut indexer. Canonicaliser agressivement, bloquer en robots.txt, ou noindexer certaines combinaisons est souvent plus sain que de supplier Google d'indexer du contenu redondant.

Troisième nuance : Splitt écarte JavaScript pour les pages jamais crawlées, mais il ne dit rien sur les pages crawlées puis rejetées. Or, un rendu JS défaillant — timeout, erreurs console bloquantes, contenu chargé après 5 secondes — peut très bien produire un HTML vide ou pauvre côté Googlebot, donc un rejet qualité. La piste JS reste valable dans ce second scénario.

Dans quels cas cette règle ne s'applique-t-elle pas ?

Si vous utilisez du lazy loading agressif ou du rendu conditionnel basé sur l'user-agent, vous pouvez techniquement servir un HTML vide à Googlebot même après fetch. Dans ce cas précis, Splitt a raison sur le principe — Google a bien récupéré du HTML — mais le problème reste côté front. C'est un edge case, mais il existe.

Autre exception : les pages bloquées par robots.txt ou X-Robots-Tag n'apparaissent normalement pas dans « découvertes mais non indexées » — elles basculent dans « Exclue par robots.txt » ou « Exclue par balise noindex ». Si vous en voyez quand même, c'est souvent un lag de mise à jour de Search Console, ou une découverte via sitemap alors que le crawl est bloqué.

Que faut-il faire concrètement face à ce statut ?

Première étape : priorisez les URLs stratégiques. Exportez la liste Search Console, croisez-la avec votre liste de pages à fort potentiel (fiches produits best-sellers, contenus piliers, landing SEA). Si ces pages sont absentes de l'index, c'est un chantier urgent. Si ce sont des filtres ou variantes mineures, c'est normal — voire souhaitable.

Deuxième étape : déterminez si Google a crawlé ou non. Vérifiez les logs serveur ou la date de dernière exploration dans Search Console. Pour les pages jamais crawlées, renforcez le maillage interne, réduisez la profondeur de clic, ajoutez-les au sitemap, boostez leur PageRank interne via des liens depuis des pages fortes. Pour les pages crawlées mais rejetées, auditez le contenu : duplication, thin content, balises canonical incorrectes, qualité éditoriale faible.

Troisième étape : si le volume d'URLs découvertes explose soudainement, vous avez probablement un problème de facettes ou de pagination mal gérée. Google découvre des milliers de combinaisons inutiles — nettoyez via robots.txt, paramètres d'URL dans Search Console (fonctionnalité obsolète mais encore pertinente conceptuellement), ou canonicales strictes.

Quelles erreurs éviter ?

Ne submettez pas en masse via « Demander une indexation » — c'est inefficace et vous brûlez votre quota pour rien. Google a déjà fait son choix ; forcer la main ne change rien si les signaux de qualité ou de priorité sont absents. Utilisez cette fonction uniquement pour des pages stratégiques après correction.

N'ignorez pas les signaux de qualité. Si Google crawle mais n'indexe pas, c'est rarement un caprice — il détecte du contenu dupliqué, mince ou sans valeur ajoutée. Enrichir, différencier, ou supprimer est souvent plus rentable que de s'acharner à indexer.

Ne confondez pas découverte et priorité. Votre sitemap contient peut-être 10 000 URLs, mais si votre site a un Domain Rating de 20 et zéro backlink, Google n'indexera jamais tout. C'est une question de crawl budget et de confiance — travaillez la popularité externe avant de réclamer l'indexation de chaque page.

Comment vérifier que votre site est conforme ?

Analysez le ratio URLs indexées / URLs soumises. Un taux sous 60 % sur un site bien structuré doit alerter — soit vous avez trop d'URLs inutiles, soit vous avez un problème de confiance ou de qualité. Segmentez par type de page : fiches produits, catégories, blog, pages institutionnelles. Si une catégorie entière est systématiquement rejetée, c'est un pattern à investiguer.

Vérifiez la cohérence entre sitemap, maillage interne et canoniques. Une URL canonicalisée vers une autre ne devrait pas apparaître dans le sitemap — c'est un signal contradictoire qui gaspille du crawl budget. Utilisez Screaming Frog ou Oncrawl pour croiser ces données et repérer les incohérences.

• Exporter la liste « Découvertes mais non indexées » depuis Search Console
• Croiser avec les logs serveur pour distinguer crawl/non-crawl
• Auditer le contenu des pages crawlées mais non indexées (duplication, thin content)
• Renforcer le maillage interne des pages stratégiques jamais crawlées
• Nettoyer le sitemap : retirer les canonicalisées, les noindex, les redirections
• Surveiller l'évolution mensuelle du ratio indexé/découvert par typologie de page