Une page « non indexée » n’est pas forcément en panne. Une ancienne URL redirigée ou un doublon peut être exclu normalement. Pour une page commerciale que vous souhaitez retrouver sur Google, partez du motif précis dans Search Console, du code HTTP et de la version canonique retenue. Voici une grille pour savoir quoi contrôler avant de réécrire le texte.
Code HTTP et statut Search Console : deux informations différentes
Un code HTTP décrit la réponse du serveur. Le rapport Search Console ajoute des motifs liés à l’exploration ou à l’indexation. Une réponse 200 ne garantit donc pas une présence sur Google, et « Explorée, actuellement non indexée » n’est pas un code HTTP. Comparez toujours le rapport historique à un test de la page actuelle.
La documentation Google sur les codes HTTP explique leur traitement. Le tableau suivant donne des pistes de diagnostic : elles ne remplacent pas la lecture des journaux du serveur et du résultat réellement obtenu par Googlebot.
| Code | Ce que la réponse indique | À contrôler |
|---|---|---|
| 200 | Contenu renvoyé, indexation non garantie | Rendu, directives et contenu |
| 301 / 308 | Redirection permanente | Destination finale pertinente |
| 302 / 307 | Redirection temporaire | Intention réellement temporaire |
| 401 | Authentification requise | Accès public si souhaité |
| 403 | Accès refusé | Pare-feu et règles de sécurité |
| 404 | Ressource introuvable | Lien cassé ou suppression voulue |
| 410 | Ressource retirée | Absence de remplacement pertinent |
| 429 | Trop de requêtes | Limitation et capacité serveur |
| 500 | Erreur interne du serveur | Journaux applicatifs |
| 502 | Passerelle en erreur | Service amont |
| 503 | Service indisponible | Maintenance ou surcharge |
Les erreurs persistantes côté serveur et les réponses 429 peuvent ralentir l’exploration. Corrigez leur cause avec l’hébergeur ou le développeur ; ne remplacez pas une panne par une redirection vers l’accueil. Pour un 403, vérifiez précisément la règle qui bloque l’accès au lieu de désactiver globalement le pare-feu.
Les motifs de non-indexation à reconnaître
Le rapport officiel sur l’indexation des pages détaille ces motifs. Les libellés peuvent varier avec la langue et l’interface ; les lignes ci-dessous les résument. L’action dépend surtout du rôle de la page et de votre volonté de la rendre indexable.
| Motif | Interprétation | Première action proposée |
|---|---|---|
| Détectée, non indexée | Connue, pas encore explorée | Examiner découverte et disponibilité |
| Explorée, non indexée | Lue, pas retenue dans l’index | Comparer contenu et doublons |
| Page avec redirection | Renvoie ailleurs | Inspecter la cible |
| Erreur de redirection | Chaîne ou destination défectueuse | Chercher boucle ou cible invalide |
| Bloquée par robots.txt | Exploration interdite | Contrôler la règle |
| Exclue par noindex | Exclusion explicite | Confirmer si elle est voulue |
| Autre page canonique correcte | Variante correctement regroupée | Ne rien forcer si attendu |
| Doublon sans canonical choisie | Google retient une autre version | Comparer les URL |
| Google choisit une autre canonical | Choix différent du vôtre | Examiner les deux pages |
| Soft 404 | Contenu perçu comme une erreur | Vérifier rendu et statut |
404, 410 et soft 404 : ne pas tout rediriger
Google recommande une redirection permanente lorsque le contenu a réellement déménagé vers un équivalent. S’il a été supprimé sans remplacement pertinent, 404 ou 410 reste approprié. Une soft 404 est différente : le serveur peut annoncer un succès alors que le contenu ressemble à une erreur ou à une page vide. Le guide Google sur les erreurs d’exploration aide à distinguer ces situations.
Exemple fictif : /ancien-service devient /nouveau-service avec la même offre. Une 301 vers la nouvelle page est cohérente. À l’inverse, un ancien script WordPress supprimé ne doit pas renvoyer vers une prestation commerciale. Pour préparer la migration de votre site, associez chaque ancienne URL utile à une destination pertinente et laissez les suppressions sans équivalent renvoyer un vrai statut de retrait.
Diagnostiquer une URL dans Search Console
Ouvrez l’outil d’inspection d’URL et collez l’adresse exacte. Notez la dernière exploration, la récupération de la page, l’autorisation d’indexation et la canonical lorsqu’elle est indiquée. Lancez ensuite le test en direct. Il décrit la version accessible maintenant, pas une garantie d’indexation ni une preuve que tous les problèmes sont résolus.
Dans l’affichage de la page testée, examinez le HTML et le rendu disponibles. Une page qui fonctionne dans votre navigateur peut dépendre d’une session connectée ou de ressources non accessibles au robot. Si une correction vient d’être déployée, comparez sa date à celle de la dernière exploration avant de conclure que Google l’a ignorée.
Contrôle technique complémentaire, sur une URL que vous gérez : curl -sS -D - -o /dev/null https://exemple.fr/page. Cette commande effectue une requête GET et affiche les en-têtes ; examinez le statut, Location et X-Robots-Tag. Avec -L, curl suit les redirections : regardez chaque réponse, pas seulement la dernière. Sous Windows PowerShell, utilisez curl.exe et remplacez /dev/null par NUL. Ce contrôle ne reproduit pas le rendu de Google.
Corriger noindex et robots.txt au bon endroit
Une directive noindex peut venir du HTML ou d’un en-tête HTTP. Pour que Google la lise, la ressource doit rester accessible à l’exploration. Ne considérez donc pas un blocage robots.txt comme une solution équivalente pour retirer une page de l’index. La documentation Google de noindex précise cette distinction.
Si une page de service est exclue par erreur, cherchez le réglage à l’origine du noindex : modèle, extension SEO, environnement de préproduction ou configuration serveur. Corrigez la version publique concernée, pas toutes les exclusions du site. Les espaces privés et certaines pages techniques peuvent légitimement rester non indexables.
Vérifier la canonical et les pages qui se ressemblent
Les recommandations Google sur les URL canoniques distinguent les signaux forts, comme les redirections et les annotations canonical, de signaux plus faibles comme le sitemap. Alignez les liens internes et la version déclarée, puis comparez le choix de Google. Une canonical constitue un signal ; ce n’est pas un ordre garantissant le résultat.
Exemple fictif : /prestation et /prestation?source=email affichent le même contenu. Il peut être normal de ne retrouver que la version principale. En revanche, une page consacrée à une offre différente ne doit pas être regroupée arbitrairement sur l’accueil. Pour organiser les pages de services, comparez ce que chaque page permet réellement au visiteur de comprendre et de faire.
Après la correction : vérifier, puis suivre
Refaites le test en direct après déploiement. Demandez l’indexation lorsqu’elle est pertinente, ou utilisez la validation de correction proposée pour le problème concerné. N’envoyez pas la même demande en boucle. Conservez URL finale, cause, intervention et date du contrôle : le rapport n’est pas mis à jour instantanément et Google ne garantit pas l’indexation.
Notre ordre de traitement conseillé : accès aux pages commerciales prioritaires, erreurs serveur et redirections, directives et canonical, puis utilité du contenu et maillage. Ce tri évite de réécrire des pages dont le problème est un pare-feu ou un mauvais statut HTTP. Il ne vise pas à faire disparaître toutes les exclusions légitimes.
Litus diagnostique et corrige les blocages utiles à traiter
Litus peut analyser vos exemples d’URL, leurs réponses serveur et les rapports Search Console, puis proposer les corrections : redirections, directives d’indexation, canonical, sitemap ou maillage. Notre accompagnement en référencement naturel distingue ce qui relève de votre site de ce qui dépend de la décision de Google. Aucune promesse de première place ou d’indexation sous 24 heures.
Faire analyser mes pages non indexées par Litus
Transmettez l’adresse du site, quelques URL concernées et le motif affiché. Pour travailler dans Search Console, privilégiez une invitation avec les droits nécessaires plutôt que le partage de votre compte Google. Vous recevez un périmètre d’intervention et des priorités ; les corrections sont vérifiées après déploiement.
