# Mes pages ne sont plus indexées par Google

> Une page qui n’apparaît plus dans les résultats a rarement été sanctionnée. Le plus souvent, elle n’a pas été explorée, ou elle a été explorée puis jugée équivalente à une autre. Ce sont deux situations opposées : la première demande de rendre la page accessible, la seconde de la rendre différente.

- Source canonique : [https://allaux.fr/problemes/pages-qui-disparaissent-de-google](https://allaux.fr/problemes/pages-qui-disparaissent-de-google)
- Langue : FR
- Dernière mise à jour : 2026-08-03

## Réponse directe

> Passez l’adresse exacte dans l’Inspection de l’URL de la Search Console : elle dit si la page a été explorée, indexée ou écartée, et pour quel motif. Vérifiez ensuite Réglages > Lecture sur WordPress, où une case cochée pendant la recette bloque tout le site, puis le robots.txt à la racine. Sur PrestaShop, ce fichier se régénère depuis Trafic & SEO et écrase les règles ajoutées à la main.

## Non explorée, ou explorée puis écartée

Un moteur procède en deux temps. Il explore une adresse, c’est-à-dire qu’il la demande au serveur et lit ce qu’elle renvoie. Puis il décide de l’ajouter ou non à son index. La console de recherche distingue clairement ces deux étapes, et le motif indiqué pour chaque page exclue est l’information la plus utile de tout le diagnostic.

Une page non explorée est bloquée par un obstacle technique : instruction interdisant l’exploration, aucun lien menant à elle, erreur serveur au moment du passage, ou budget d’exploration consommé par des milliers d’adresses sans intérêt. Une page explorée mais non indexée pose une autre question : elle est trop proche d’une autre page, elle porte une balise indiquant elle-même qu’une autre version fait référence, ou son contenu est jugé trop mince pour mériter une entrée distincte.

## Ce que je trouve le plus souvent sur une boutique

- Des pages de filtres et de tri générant des milliers d’adresses différentes pour le même contenu, qui absorbent tout le budget d’exploration.
- Une balise canonique pointant vers une autre page, souvent générée automatiquement par un module et jamais vérifiée.
- Des fiches produit reprenant la description du fournisseur, identique sur des dizaines de sites.
- Une instruction bloquant l’exploration héritée d’une préproduction et jamais retirée.
- Un plan de site qui déclare des adresses qui redirigent, ou qui n’existent plus.

## Vérifier page par page

1. **Demander l’adresse exacte au moteur** — L’outil d’inspection d’adresse de la console de recherche donne l’état réel : explorée ou non, indexée ou non, et le motif. C’est la source, pas une estimation.
2. **Comparer avec ce que voit le robot** — Le contenu vu par le robot peut différer de ce que vous voyez, notamment si la page se construit après chargement par un script. Une page dont le texte n’existe qu’après exécution est plus difficile à indexer.
3. **Vérifier la balise canonique** — Elle se lit dans le code de la page. Une canonique qui pointe ailleurs revient à demander soi-même de ne pas être indexé.
4. **Regarder combien d’adresses le site expose** — Si une boutique de quelques centaines de produits déclare des dizaines de milliers d’adresses explorables, le problème n’est pas l’indexation : c’est la multiplication des combinaisons de filtres.

## Bloquer l’exploration n’enlève pas une page de l’index

> Ce sont deux mécanismes différents, souvent confondus. Interdire l’exploration empêche le moteur de lire la page — et donc de voir l’instruction de désindexation qu’elle contient peut-être. Pour retirer une page, il faut au contraire la laisser accessible et lui demander explicitement de ne pas être indexée.

## Continuer sur la bonne page

- **La balise canonique expliquée** — Ce qu’elle déclare vraiment, et les erreurs les plus fréquentes. ([/glossaire/canonical](/glossaire/canonical))
- **Le fichier robots.txt** — Ce qu’il contrôle réellement, et ce qu’il ne contrôle pas. ([/glossaire/robots-txt](/glossaire/robots-txt))
- **Le plan de site** — Ce qu’il doit contenir pour être utile plutôt que contradictoire. ([/glossaire/sitemap](/glossaire/sitemap))
- **URL simplifiées et erreurs 404** — Si les adresses de la boutique elles-mêmes ne répondent plus correctement. ([/prestashop/problemes/url-simplifiees-erreurs-404](/prestashop/problemes/url-simplifiees-erreurs-404))

## FAQ

### Combien de temps faut-il pour qu’une page soit indexée ?

Cela dépend de la fréquence à laquelle le site est exploré, qui dépend elle-même de sa taille et de son historique. Je ne donne pas de délai : demander explicitement l’indexation d’une adresse précise accélère le traitement d’une page, pas de tout un catalogue.

### Mes fiches produit sont indexées, pas mes catégories. Pourquoi ?

Souvent parce que les catégories n’ont pas de texte propre et se distinguent seulement par une liste de produits. Un contenu éditorial spécifique à la catégorie change généralement la situation.

### Faut-il soumettre chaque page manuellement ?

Non, et ce n’est pas tenable sur un catalogue. Un plan de site à jour et une navigation qui mène réellement à chaque page font le travail.

### Un site lent est-il moins bien indexé ?

La vitesse influence le volume de pages explorées dans un temps donné. Sur un grand catalogue, cela devient concret : les pages profondes sont visitées moins souvent.

### Les pages générées par des filtres doivent-elles être indexées ?

Rarement toutes. Quelques combinaisons correspondant à une vraie demande méritent une page ; les milliers d’autres diluent l’exploration et se traitent par une déclaration canonique ou une exclusion.