Sur un site SaaS, le statut Search Console « Explorée, actuellement non indexée » (CNCI) est souvent pris comme un problème technique. Alors on se jette sur le robots.txt, on force des soumissions, on clique sur « Demander une indexation » comme si ça allait convaincre Google. Mauvais réflexe.
CNCI, c’est généralement un signal simple : Google a vu l’URL, il l’a crawlée, et il a jugé que ça ne méritait pas une place stable dans l’index. Pas forcément parce que la page est « cassée ». Parce qu’elle est faible, trop proche d’une autre, mal reliée, ou juste inutile à son échelle. Et sur un SaaS qui multiplie les pages features, intégrations, templates, comparatifs, pages locales, c’est presque mécanique.
La bonne approche, c’est un triage. Comme un triage produit après une croissance un peu trop enthousiaste. On classe, on tranche, on consolide, on construit une structure qui prouve l’utilité. Et on mesure sur des lots, pas au doigt mouillé.
CNCI : ce que Google est en train de te dire (sans te l’expliquer)
Quand Search Console te met une URL en « explorée, actuellement non indexée », ça veut dire que Googlebot est passé. Il n’y a pas eu un mur technique évident, sinon tu serais plutôt dans des erreurs de crawl, des redirections foireuses, des 404, des « bloquée par robots.txt » ou des « alternative page avec canonical approprié ».
CNCI, c’est la zone grise. Celle où Google peut techniquement indexer… mais ne veut pas. Dans la vraie vie, sur un SaaS, ça correspond souvent à une page qui ne crée pas assez de différence avec le reste du site. Ou qui n’a pas assez de signaux pour mériter d’être gardée. La nuance est importante : Google ne te doit pas l’indexation, et tu ne peux pas la “forcer” durablement.
Ce statut peut aussi être transitoire. Une URL fraîche, une page qui vient d’être publiée, un site avec un budget crawl limité, une architecture qui fait perdre du temps aux bots, tout ça joue. Mais si tu as des centaines ou milliers d’URLs CNCI qui stagnent, ce n’est plus une phase. C’est un modèle.
Sponsorisé par Le Scribouillard
Besoin de contenu optimisé SEO ?
Utilisez la meilleure plateforme française de création de contenu assistée par IA ! Et générez des articles pour moins de 1€ !
Le cas SaaS typique : tu as produit des pages, pas des preuves d’utilité
Les SaaS ont un super pouvoir et un défaut : ils peuvent générer beaucoup de pages. C’est tentant de créer une landing par feature, une page par intégration, une page par template, une page par use case, une page par industrie. Et si tu fais du programmatic SEO, tu peux démultiplier encore.
Le problème, c’est que l’index de Google n’est pas un disque dur gratuit. Si tes pages se ressemblent, si elles reprennent la même promesse, la même démo, les mêmes blocs “Comment ça marche”, alors Google consolide mentalement tout ça en « contenu répétitif ». Et si en plus ces pages sont peu liées depuis le site (ou juste via un footer ou un sitemap), elles ressemblent à de la surface, pas à une structure.
Autre cas fréquent : la page répond à une intention que personne n’a. Elle existe parce que « ça ferait une page en plus », pas parce que ça capte une demande. Là, CNCI est presque sain. Google évite d’indexer une page qui ne servira à rien.
Le triage qui marche : classifier avant de “réparer”
Je ne commence pas par chercher une cause unique. Je commence par classer les URLs CNCI en familles. Ça change tout parce que tu ne traites pas une intégration fine comme un template vide, ni une page quasi-dupliquée comme une page orpheline.
Sur les SaaS, tu retrouves presque toujours ces gros blocs. Il y a le pSEO qui a été généré trop large (mêmes paragraphes, variations minimes). Il y a les pages proches qui se cannibalisent (deux features qui racontent la même histoire). Il y a les pages sans demande (intention inexistante ou mal ciblée). Et il y a les pages structurellement faibles (trop profondes, mal maillées, pas de liens contextuels, juste un listing).
Ce triage, tu peux le faire proprement en croisant 4 infos simples : le type de page (feature/intégration/template/blog), la profondeur (combien de clics depuis une page forte), les signaux GSC (impressions, requêtes, position), et la similarité (est-ce qu’une autre page couvre déjà le sujet).
Décider « keep / merge / noindex / delete » sans se raconter d’histoires
La décision est rarement “indexer à tout prix”. La décision utile, c’est : est-ce que cette URL doit exister, et si oui sous quelle forme.
Quand une page a un vrai sujet, une vraie intention, et une promesse distincte, je la garde. Mais je la garde en assumant qu’elle doit porter sa part du boulot. Ça veut dire du contenu réellement spécifique (pas juste trois variantes de phrases), des exemples, une preuve produit, une section qui répond aux objections, et surtout des liens internes qui la mettent dans le flux naturel du site.
Quand une page est “correcte” mais trop proche d’une autre, je fusionne. Le merge est souvent le move le plus rentable sur un SaaS : tu rassembles en une page plus épaisse, plus convaincante, plus unique, et tu rediriges proprement l’ancienne URL vers la nouvelle. Tu réduis l’ambiguïté pour Google, tu réduis la cannibalisation, tu simplifies le maillage. Et tu gardes une destination claire.
Quand une page a une utilité produit mais pas une utilité SEO, le noindex est une option saine. Typiquement, des pages de templates très “thin” mais utiles pour des utilisateurs connectés, ou des pages qui existent pour l’UX de navigation mais qui n’ont rien à faire dans Google. Noindex n’est pas un échec. C’est un choix d’architecture.
Et quand une page est juste vide de valeur, je supprime. Pas “un jour”. Maintenant. Une page supprimée, c’est du crawl gaspillé en moins, de la confusion en moins, et une dette en moins. Sur un site qui gonfle, la suppression est une compétence, pas une punition.
Construire des hubs : arrêter de publier des pages isolées
Le maillage interne n’est pas un exercice décoratif. Sur un site SaaS, c’est littéralement la manière dont tu prouves à Google que tes pages ont une place dans une structure logique.
Ce qui marche bien, c’est le modèle “hub”. Une page pilier qui capte l’intention large (par exemple une catégorie d’intégrations, ou un use case majeur), et autour, des pages plus spécifiques. Pas une arborescence pour faire joli, une arborescence qui aide l’utilisateur à choisir et à avancer. Quand tu fais ça proprement, tu donnes à Google des chemins de crawl naturels, et tu montres quelles pages sont centrales.
Le détail qui change la donne, c’est le lien contextuel. Le lien depuis un texte qui explique, avec une ancre qui décrit vraiment la cible, a un poids différent du lien “Voir plus” dans un bloc générique. Si tes pages CNCI ne reçoivent que des liens de navigation automatique, elles ressemblent à des pages posées là “parce que le CMS”.
Autre point très concret : la profondeur. Beaucoup de CNCI viennent de pages à 4 ou 5 clics de la home, planquées derrière des filtres, des pages de listing pauvres, ou des paginations interminables. Si tu veux qu’une page vive, tu la rapproches des pages fortes, ou tu assumes qu’elle ne mérite pas d’être indexée.
Réduire la cannibalisation : canonicals cohérents, pagination saine, taxonomies qui ne s’auto-détruisent pas
Sur les SaaS, la cannibalisation est souvent auto-infligée. Tu as trois pages qui ciblent à peu près la même requête, plus une page catégorie, plus des tags, plus des variantes d’URL générées par des paramètres. Et tout ça se contredit.
Si tu utilises des canonicals, ils doivent raconter une histoire stable. Une page qui canonicalise ailleurs alors qu’elle est censée ranker, c’est un message contradictoire. Une page qui se canonicalise elle-même mais qui est dupliquée par dix variantes, c’est pareil. Ton objectif n’est pas d’être “conforme”. Ton objectif est d’enlever l’ambiguïté sur la version principale.
La pagination et les listings sont un autre piège. Un répertoire d’intégrations avec 40 pages paginées, chacune avec deux lignes de texte, ça génère des URLs crawlées qui ressemblent à du contenu faible. Si ta valeur est dans les pages détail, fais en sorte que le listing serve à les découvrir, pas à fabriquer des centaines de pages candidates à l’index.
Enfin, méfie-toi des taxonomies “WordPress-like” sur un SaaS headless : catégories, tags, collections, tout peut créer des pages de regroupement qui se dupliquent les unes les autres. Si tu veux des pages de hub, fais-les intentionnelles. Sinon, noindex.
Les signaux d’utilité : ce que je renforce quand je veux faire sortir une page de CNCI
Si je décide qu’une page mérite d’être indexée, je ne la “demande” pas à Google. Je la rends difficile à ignorer.
Concrètement, je renforce l’unicité. Une intégration SaaS qui se contente d’un texte générique “Connectez X à Y” ne gagne pas. Une intégration qui explique un workflow précis, les champs, les limites, une capture, un exemple d’automatisation, une section “problèmes fréquents”, ça commence à ressembler à une page utile.
Je renforce aussi les signaux produits. Sur un SaaS, tu as un avantage : tu peux prouver. Des screenshots, une courte vidéo, un snippet de configuration, un extrait d’API, une liste de déclencheurs/actions, une section de pricing liée au cas d’usage. Pas pour “faire du contenu”, pour réduire le doute.
Et je renforce le maillage de manière assumée. Une page qui ne reçoit aucun lien depuis des pages qui rankent déjà, c’est une page que ton propre site ne recommande pas. Tu peux avoir le meilleur texte du monde, si tout est enterré et que personne n’y mène, tu joues contre toi-même.
Mesurer le résultat : Coverage, impressions, et logs (le trio qui évite les mythes)
Le piège classique, c’est de faire 200 changements et de regarder Search Console trois jours après en déclarant victoire ou échec. L’indexation a de l’inertie. Et Google recrawl par vagues.
Je mesure d’abord dans Search Console si le volume CNCI bouge dans la bonne direction sur le segment travaillé. Ensuite je regarde les impressions et les requêtes. Une page peut sortir de CNCI et rester invisible, ce qui veut dire qu’elle est indexée mais pas compétitive. C’est un autre problème, plus “ranking” que “indexing”.
Et si tu veux arrêter de deviner, tu regardes des logs. Les logs te disent ce que Google crawl vraiment, à quelle fréquence, et si tu es en train de brûler ton budget crawl sur des URLs secondaires. Sur un SaaS qui a grandi vite, tu découvres souvent que Google passe trop de temps sur des pages de filtre, des paginations, des variantes, pendant que tes pages business restent sous-crawlées.
Le rythme que je recommande est simple : itérer par lots. Tu prends une famille d’URLs CNCI, tu appliques une stratégie cohérente (merge, prune, noindex, renforcement + hubs), tu laisses le temps au recrawl, tu mesures, puis tu passes au lot suivant. C’est moins satisfaisant que de “tout corriger”, mais c’est comme ça que tu obtiens un signal clair.
Mon avis (assez sec) : si tu as beaucoup de CNCI, ton problème est éditorial et structurel
Oui, il y a des cas techniques. Une page qui renvoie un 200 mais sert un contenu différent selon l’agent, une canonicalisation incohérente, un JS qui masque des sections, une chaîne de redirections, tout ça existe. Mais sur les SaaS, quand CNCI explose, la cause la plus fréquente reste la même : tu as produit plus d’URLs que de valeur.
Le bon move n’est pas de “faire indexer”. Le bon move, c’est de réduire le bruit, consolider ce qui doit l’être, et bâtir une structure de hubs où chaque page a un rôle clair. Google adore les sites où il comprend vite ce qui est central, ce qui est support, et ce qui est inutile. Fais-lui ce cadeau, et CNCI devient beaucoup moins anxiogène.
