Découvertes mais non indexées : causes et vérifications
Les sites comptant des milliers d'URL non indexées ont généralement une cause unique et récurrente. Ce tableau liste les causes habituelles dans l'ordre dans lequel nous les vérifierions.
Symptôme, cause probable, première vérification
| Symptôme dans Search Console | Cause probable | Première vérification |
|---|---|---|
| Découvertes, non indexées sur de nombreuses nouvelles URL | Google connaît l'URL mais n'a pas consacré de temps de crawl à celle-ci | Comptez les liens internes pointant vers la page ; les pages profondes sont souvent ignorées |
| Crawlées, non indexées | Page vue et jugée à faible valeur ou en doublon | Comparez avec le classement de la page pour la même requête |
| Google a choisi un canonical différent | Les versions http et https, ou www et non-www, sont toutes deux actives | Récupérez les deux versions et recherchez une redirection 301 |
| Le site de staging apparaît dans les résultats | Le site de staging n'a jamais été bloqué ni authentifié | Recherchez site:staging.votredomaine.com |
| Pic soudain d'URL exclues | Paramètres ou navigation facétée générant des URL | Consultez les URL d'exemple dans le rapport |
| Erreurs Googlebot sur un seul sous-domaine | Pare-feu ou limitation de débit par l'hébergeur ou Cloudflare | Consultez les logs serveur pour les réponses 429 et 403 |
Vérifier une URL telle que Google la voit
Commencez par une seule adresse. Un tableau de causes n'est utile que lorsque vous savez quelle ligne décrit la page que vous examinez.
Commencez par le statut de couverture
Ouvrez le rapport d'inspection de la page dans Search Console et lisez la ligne de statut avant toute autre chose. « Découverte » et « crawlée » sont des verdicts différents, et chacun pointe vers une correction différente.
Ne passez pas une semaine à travailler sur les liens pour une page que Google n'a jamais crawlée. Cet effort est mieux investi ailleurs jusqu'à ce que la ligne de statut indique le contraire.
Sauvegardez le résultat de l'inspection avec sa date. Les états de couverture changent lorsque Google recrawle, donc une note de la semaine dernière vous dit ce qui s'est passé alors, et une inspection fraîche vous dit ce qui se passe maintenant.
Comparez le HTML brut avec la page rendue
Récupérez l'URL avec cURL et recherchez le texte principal dans la réponse. Si les mots n'apparaissent qu'après l'exécution des scripts, le problème est lié au rendu, et non au graphe de liens.
Un titre manquant ou un corps de texte mince dans la réponse brute est un signal rapide, et c'est celui que les gens négligent le plus souvent.
Parcourez la liste dans l'ordre. Un échec sur le premier élément explique souvent le reste, donc inutile de vérifier les autres tant qu'il n'est pas corrigé.
- Titre principal présent dans la réponse
- Texte du corps plus long que quelques phrases
- Liens internes présents sous forme d'ancres brutes
- Balise canonical pointant vers la bonne adresse
Confirmez que le sitemap et le fichier robots sont cohérents
Un sitemap qui liste une URL tandis que robots.txt la bloque envoie des signaux mixtes. Vérifiez les deux fichiers sur l'hôte canonical, car une copie servie depuis un autre hôte peut indiquer quelque chose de différent.
Ces incohérences cassent rarement tout un site. Elles rendent toutefois plus difficiles à lire toutes les autres vérifications.
Vérifiez également les valeurs lastmod si votre sitemap les contient. Des dates qui ne changent jamais, ou qui correspondent toutes à la date de build, informent très peu Google sur ce qui est nouveau.
Où les backlinks interviennent
Un lien provenant d'un autre site est un chemin de découverte. Google le suit, ce qui peut faire passer une page plus rapidement de la file de découverte à celle du crawl.
Cela ne fait pas d'un lien un interrupteur d'indexation. Une page sans liens internes et avec un seul backlink isolé reste un candidat faible, et Google a clairement indiqué qu'il n'indexe pas tout ce qu'il trouve.
Utilisez toppages pour voir quelles URL attirent des liens, puis confirmez que ces URL exactes sont indexées. Une URL liée mais absente de l'index est un signal qui vaut une journée de travail.
En cas de doute, examinez les pages pointant vers l'URL bloquée. Si aucune de ces pages n'appartient à votre propre site, le problème est probablement structurel (interne) plutôt que lié aux liens externes.
Liens provenant de pages peu lues
Un lien provenant d'une page qui n'est jamais crawlée offre peu de matière à Google pour suivre. Vérifiez si la page source est elle-même indexée avant de la compter comme un chemin de découverte.
Les liens morts provenant d'anciennes pages peuvent maintenir une adresse sur la liste pendant un certain temps, mais ils changent rarement le verdict par eux seuls.
Les liens internes font le gros du travail
La majeure partie de la découverte des pages d'un site se fait à l'intérieur du site. Un menu, une liste de catégories et un sitemap font plus pour une nouvelle page qu'un seul lien externe.
Si une page n'a pas de chemin interne, un lien externe est un pansement sur une lacune structurelle, et c'est cette lacune qu'il faut combler.
Comment distinguer la profondeur des liens de leur qualité
Une page découverte mais non crawlée est généralement un problème de priorité. Google connaît l'adresse mais voit peu de raisons de se presser, souvent parce que peu de chemins internes y mènent.
Une page crawlée mais non indexée est un jugement. Google l'a lue et ne la souhaite pas, donc plus de liens ne corrigeront pas un texte mince ou en doublon.
Les frameworks ajoutent une troisième cause. Les sites Next.js et React livrent parfois du texte qui n'apparaît qu'après l'exécution du JavaScript. Récupérez le HTML brut avec cURL et vérifiez si votre texte s'y trouve. Sinon, le rendu côté serveur ou le prerendering sont la solution, et la recette pour maintenir les URL stables s'applique lors du changement de stack.
Bing et Yandex ont leurs propres files d'attente, donc vérifiez Bing Webmaster Tools avant de supposer que le problème vous est exclusif.
Un test utile consiste à examiner la même page sous deux angles. Si son compteur de liens internes est faible et son texte mince, la cause peut être double, et vous devriez corriger les deux avant d'attendre.
Ordre de travail
- Inspectez une URL affectée et notez si elle indique « L'URL est sur Google ».
- Ouvrez le sitemap et confirmez qu'il retourne un HTTP 200 sur l'hôte canonical.
- Vérifiez robots.txt tel que Googlebot le verrait, et non tel que votre navigateur le voit.
- Comptez les liens internes entrants et maintenez les pages importantes à moins de trois clics de la page d'accueil.
- Supprimez les pages de gabarit minces qui n'existent que pour être indexées.
- Attendez quelques semaines après les corrections ; l'indexation ne se stabilise rarement du jour au lendemain.
Travaillez sur une URL bloquée
Utilisez cette séquence pour une seule URL qui est restée dans la file d'attente pendant des semaines. Arrêtez à la première étape qui vous donne une cause.
- 1
Lisez le statut
Notez le statut exact dans Search Console et la date du dernier crawl pour l'URL.
- 2
Comptez les chemins entrants
À partir de votre export de crawl, comptez les liens internes pointant vers la page et notez depuis quelles pages hubs ils proviennent.
- 3
Vérifiez la réponse
Interrogez l'URL et confirmez un statut 200 sur l'hôte canonical, sans chaîne de redirection en travers.
- 4
Décidez, puis attendez
Si la page est mince, améliorez-la. Si elle est simplement enfouie au fond du site, liez-la depuis une page plus forte, puis attendez plusieurs semaines avant de juger.
Quand un saut d'URL exclues est un problème de paramètre ou de sitemap
Une augmentation soudaine d'URL exclues a généralement une cause mécanique. Le travail consiste à trouver le générateur, et non à poursuivre chaque adresse.
Paramètres et chemins facétisés
Un saut soudain remonte souvent à un paramètre de filtre ou de tri qui a commencé à générer de nouvelles adresses. Échantillonnez une douzaine d'URL depuis le rapport et lisez leurs chaînes de requête.
Si les variantes affichent le même contenu, le problème est un doublon. La solution est un canonical ou une règle de paramètre, et non plus de liens.
Surveillez les pages qui sont censées exister. Un filtre peut mériter sa propre adresse lorsque les gens recherchent vraiment cette combinaison. La règle n'est pas de bloquer tous les paramètres, mais de décider quelles combinaisons méritent une adresse.
Un sitemap listant le mauvais hôte
Un sitemap construit pour la version http d'un site, ou pour un hôte qui redirige maintenant, donne à Google une liste qu'il ne fera pas confiance. Ouvrez le fichier et vérifiez les dix premières adresses par rapport à votre hôte canonical.
Corrigez d'abord la liste. Un sitemap propre coûte peu à publier, et il élimine une variable de l'enquête.
Pièges d'hébergement et de blocage des robots
Hostinger, Cloudflare et des couches similaires limitent parfois le débit pour Googlebot tout en servant parfaitement les humains. Le site semble parfait pour vous et instable pour le crawler.
Lisez les logs d'accès bruts pour les réponses 403, 429 et 5xx aux agents utilisateur contenant Googlebot. Vérifiez ces hits par DNS inverse, car beaucoup de scrapers imitent le nom.
Les crawlers IA sont une décision distincte. Bloquer GPTBot ou ClaudeBot dans robots.txt n'affecte pas Googlebot, mais une règle wildcard maladroite peut le faire. Testez le fichier après chaque modification.
Les copies de staging nécessitent des précautions. Lorsqu'une telle copie est le problème, mettez-la derrière un mot de passe et demandez sa suppression dans Search Console. Une balise noindex seule peut être annulée par un déploiement. Consultez la recette sur les redirections avant de consolider les hôtes.
Les limites de débit apparaissent souvent uniquement aux heures de pointe. Une vérification à minuit peut sembler propre tandis que les logs de l'après-midi racontent une autre histoire, donc échantillonnez plus d'une fenêtre avant de décider.
Gardez une note de chaque règle de pare-feu que vous modifiez. Une règle ajoutée pour arrêter un scraper peut aussi bloquer le crawler, et le symptôme peut n'apparaître que plus tard comme une baisse silencieuse de la couverture.
Quelles URL liées vous manquent ?
Cet appel coûte 2 crédits et retourne jusqu'à 1 000 lignes.
curl "https://rankbrainmarketing.link/api.php?action=toppages&q=yourdomain.com&per=1000&key=sk_live_..."Les corrections peuvent prendre des semaines à se manifester. Le statut d'indexation et notre rafraîchissement mensuel des liens ne bougeront pas le même jour, donc comparez des éléments similaires.
Questions sur les pages découvertes
Les backlinks seuls permettront-ils d'indexer une page découverte ?
Pas seuls. Un lien est un chemin de découverte qui peut aider Google à trouver la page plus rapidement. Le fait que la page soit indexée dépend toujours de son contenu et du reste du site.
Combien de temps dois-je attendre après une correction ?
Des semaines, pas des jours. L'indexation ne se stabilise rarement du jour au lendemain, et nos rafraîchissements d'index suivent leur propre rythme mensuel, donc comparez des éléments similaires lorsque vous vérifiez. Notez la date de la correction dans vos notes, afin que l'attente ait un point de départ que vous pouvez indiquer.
Devrais-je demander l'indexation pour chaque URL ?
Non. Demander l'indexation pour quelques pages importantes est raisonnable. Le faire pour des milliers de pages minces ne change pas le jugement que Google porte sur elles.
Le statut découvert-non indexé est-il toujours un problème de budget de crawl ?
Généralement non pour un petit site. Le budget de crawl est surtout important à grande échelle. Pour quelques centaines de pages, les causes plus probables sont la profondeur des liens, le contenu mince ou les doublons.
