Vous avez soumis votre sitemap, Google l’a accepté, et pourtant certaines pages refusent d’apparaître dans les résultats. Le réflexe courant consiste à accuser l’algorithme, à attendre quelques jours de plus, puis à soumettre de nouveau le fichier en espérant un déblocage miraculeux. Le problème se situe presque toujours ailleurs, dans une URL précise qui échoue à l’un des contrôles que le robot effectue avant d’indexer. Un sitemap accepté signifie que le fichier a été lu, rien de plus, et cette confusion coûte des heures de diagnostics inutiles.
Un sitemap accepté, un fichier lu, pas des pages indexées
La distinction paraît technique, elle change tout dans la méthode de diagnostic. Quand Search Console affiche le statut « Réussi » à côté de votre sitemap, l’outil confirme simplement qu’il a récupéré le fichier, qu’il l’a compris et qu’il en a extrait les adresses.
Aucune vérification n’est faite sur le contenu réel de chaque page à ce moment-là, et c’est logique : le sitemap n’est qu’une déclaration d’intention, pas une preuve de qualité. Si vous cherchez des méthodes de contrôle plus larges, le site wezko.fr rassemble plusieurs protocoles d’audit qui complètent bien celui décrit ici.
Une page peut donc figurer dans un sitemap validé et rester invisible pendant des semaines. Google la découvre, la met en file d’attente, puis abandonne si un obstacle se présente au moment du crawl. Le fameux « bug de Google » invoqué sur les forums existe, bien sûr, mais il représente une part infime des cas réels. Dans la grande majorité des situations, une URL est bloquée par un paramètre que le webmaster a lui-même posé, parfois sans le savoir, souvent en installant une extension ou en changeant un réglage serveur.
Le taux d’indexation, calculé autrement que ce que l’on croit
Search Console ne donne pas ce chiffre directement, il faut le construire. Rendez-vous dans Indexation puis Pages, et remplacez le filtre « Toutes les pages connues » par le sitemap à analyser. Vous obtenez alors deux compteurs : les pages « dans l’index » et les pages « non indexées ». Le taux d’indexation réel du sitemap se calcule en divisant le premier par la somme des deux, ce qui donne une lecture honnête de ce qui fonctionne vraiment.
La même procédure existe dans Bing Webmaster Tools, avec une logique identique. Ce calcul reste imparfait, parce qu’il mélange des pages anciennes et des adresses ajoutées la veille, mais il donne un ordre de grandeur utile pour repérer une chute brutale. Un sitemap de mille URL dont seules deux cents apparaissent dans l’index mérite clairement un audit page par page. Le compteur brut affiché sans filtre, lui, ne veut rien dire.
Les quatre faux amis qui bloquent une URL
Avant de conclure à un dysfonctionnement, prenez chaque adresse du sitemap et faites-la passer par quatre contrôles dans cet ordre. Cette séquence correspond au cheminement du robot : accès, autorisation, consigne, puis choix de la version à indexer. Un seul échec suffit à écarter la page, et corriger l’élément fautif débloque généralement l’indexation en quelques jours.
Ce qu’il faut vérifier sur chaque adresse
Ouvrez l’URL dans un outil qui affiche les entêtes de réponse, pas seulement le rendu visuel. Le navigateur masque beaucoup de choses, et une redirection invisible à l’œil se repère immédiatement dans la réponse serveur. Passez ensuite sur la racine du site pour consulter le fichier robots.txt, puis inspectez le code source de la page elle-même. Sur ce point, voir aussi notre article sur backlinks naturels tutoriels.
- Le code HTTP renvoyé doit être 200 : toute autre valeur signifie que la page n’est pas accessible correctement, et Google ne peut pas l’indexer dans ces conditions.
- Une URL bloquée par robots.txt et pas encore indexée ne le sera jamais, puisque le robot n’a pas l’autorisation de la crawler du tout.
- La balise meta robots contient-elle un noindex ou un none ? Dans ce cas la page est bien explorée, mais volontairement écartée de l’index, et aucune relance ne changera la donne.
- Et l’entête HTTP X-Robot-Tag, souvent oublié parce qu’invisible dans le code source ? Un noindex posé côté serveur produit exactement le même effet que la balise.
- Enfin, quelle URL canonique est déclarée ? Si elle pointe vers une adresse différente, la page sera probablement indexée sous cette autre adresse, et votre sitemap pointe alors vers la mauvaise version.
L’ordre des vérifications compte
Commencer par le noindex quand la page renvoie une erreur serveur fait perdre du temps, puisque le robot n’atteint même pas le code HTML. Le contrôle du statut HTTP passe en premier, systématiquement. Franchement, cette discipline évite de tourner en rond pendant une heure sur une balise absente alors que l’adresse répond en erreur depuis le début.
Le cas de la canonique et du doublon silencieux
Une page parfaitement accessible, sans noindex, peut malgré tout ne jamais apparaître sous l’adresse que vous attendez. Sa balise canonique désigne une autre version, souvent une adresse sans paramètre ou une version de test restée dans le code. Google suit cette indication et indexe la page cible, pas celle du sitemap. Du point de vue de votre rapport, l’URL est invisible ; du point de vue de Google, elle a été fusionnée avec une autre.
Ce scénario arrive fréquemment après une refonte ou un changement de CMS, quand une balise canonique absolue a été codée en dur dans le gabarit. Pour le vérifier, comparez l’adresse déclarée dans le sitemap avec la valeur de la balise sur la page. Si les deux diffèrent, le problème est identifié, et il n’a rien à voir avec une décision de l’algorithme.
Un dernier point mérite l’attention : le sitemap accepté peut aussi contenir des adresses obsolètes, supprimées depuis, qui renvoient une erreur. Ces entrées polluent les compteurs et faussent le taux d’indexation. Nettoyer le fichier régulièrement, en retirant ce qui n’existe plus, fait remonter artificiellement le ratio mais rend surtout la lecture beaucoup plus claire.
Une page qui bloque se répare, elle ne s’attend pas
Un sitemap accepté ne garantit jamais l’indexation, et confondre les deux notions conduit à des semaines d’attente stérile. Chaque URL invisible doit passer les quatre contrôles dans l’ordre : statut HTTP, autorisation robots, consigne noindex, canonique déclarée. La correction vient ensuite presque toujours d’un réglage local, extension, entête serveur ou balise codée en dur. Le bug de Google existe, mais il arrive loin derrière ces quatre causes. Combien de vos adresses restent invisibles simplement parce que personne n’a jamais ouvert leur code source ?
