Page avec redirection : erreur ou normal ? (Search Console)

Dans le rapport « Indexation des pages » de la Google Search Console, « Page avec redirection » n'est pas un défaut à réparer. C'est l'inverse : l'URL listée renvoie vers une autre, et Google indexe la destination — exactement ce qu'on attend d'une redirection.

Le statut devient intéressant seulement quand la redirection ne fait pas ce qu'on croit. Et si la chaîne s'allongeait à chaque déplacement, de A vers B vers C ? Et si une page stratégique redirigeait vers l'accueil au lieu de son équivalent ? Et si vos liens internes pointaient encore, par centaines, vers d'anciennes URLs redirigées ?

Trois cas où une redirection, parfaitement normale en apparence, coûte du budget de crawl et des positions.

Que signifie « Page avec redirection » ?

Ce statut signifie que l'URL listée renvoie vers une autre adresse (une réponse HTTP 3xx). Google ne l'indexe donc pas sous cette URL : il suit la redirection et indexe la page de destination. Dans la grande majorité des cas, c'est le comportement attendu, pas une anomalie.

C'est même le signe que votre redirection fonctionne. Quand vous déplacez une page, la consolidez vers une autre, ou passez en HTTPS, l'ancienne URL doit renvoyer vers la nouvelle. Google la voit, la marque « Page avec redirection » et indexe la cible à sa place.

La seule question utile n'est donc pas « comment faire disparaître ce statut », mais « la redirection mène-t-elle où elle devrait, et proprement ? ».

Quand c'est normal : rien à faire

La plupart des URLs de ce rapport sont là pour de bonnes raisons. Ces redirections sont saines et n'appellent aucune action :

• HTTP vers HTTPS. http://votre-site.com renvoie vers https://votre-site.com. Indispensable, et chaque ancienne URL apparaîtra ici.
• Avec ou sans www. Vous avez choisi une version canonique du domaine ; l'autre redirige vers elle.
• Slash final. /produit et /produit/ ne doivent exister qu'en une seule version ; la seconde redirige.
• Migration ou refonte. Après un changement d'URLs, les anciennes adresses redirigent vers les nouvelles. Elles resteront listées un moment, c'est normal.
• Consolidation de doublons. Deux pages au contenu proche fusionnées en une seule, avec une redirection de l'ancienne vers la version retenue.

Le point commun : la redirection mène vers la bonne page, en un seul saut. Tant que c'est le cas, il n'y a rien à corriger.

Quand la redirection pose problème

Le statut mérite votre attention dans quatre situations. Aucune n'est visible au simple libellé « Page avec redirection » : il faut regarder où mène la redirection, et comment.

• La chaîne de redirection. L'URL A redirige vers B, qui redirige vers C, qui redirige vers D. Chaque saut ralentit le chargement, consomme du budget de crawl et dilue un peu les signaux transmis. Google finit par suivre, mais préfère explicitement les redirections directes.
• La boucle de redirection. A renvoie vers B, qui renvoie vers A. La page devient inatteignable, pour Googlebot comme pour vos visiteurs. C'est une vraie erreur, à corriger en priorité.
• La cible non pertinente. Une page stratégique redirige vers la page d'accueil ou une catégorie parente, au lieu de son équivalent réel. Vous perdez la page et son potentiel : Google indexe une destination qui ne répond pas à la même intention. C'est le cas le plus coûteux et le plus discret.
• La redirection par erreur. Une page qui devait rester en ligne redirige à cause d'une règle trop large ou d'un reste de migration. Elle disparaît de l'index sans que vous l'ayez voulu.

Comprendre les codes de redirection : 301, 302, 303, 307, 308

Tous les statuts 3xx ne se valent pas, et le code choisi change la façon dont Google traite la page. Réponse directe : un déplacement définitif se signale avec un 301 (ou un 308) ; un déplacement temporaire avec un 302 (ou un 307).

• 301 — Permanent. La cible devient la version canonique et hérite des signaux. C'est le code par défaut d'un déplacement définitif.
• 302 — Temporaire. Google garde l'URL d'origine comme canonique, utile si vous comptez rétablir la page. Google précise qu'un 302 maintenu longtemps finit par être traité comme un 301.
• 308 — Permanent, peu connu. Équivalent du 301, à une différence près : il préserve la méthode HTTP (un envoi de formulaire POST reste un POST, là où un 301 peut le transformer en GET). Côté référencement, Google le traite comme un 301.
• 307 — Temporaire, peu connu. Équivalent du 302 qui préserve lui aussi la méthode. Google le traite comme un 302 pour la canonique.
• 303 — See Other. Force une requête GET après un envoi de formulaire. Rare en SEO, mais utile à reconnaître.

Un cas à part sème souvent la confusion : le « 307 interne » lié à HSTS. Quand votre site impose le HTTPS via HSTS, le navigateur force lui-même http:// vers https:// au moyen d'un 307 généré localement — ce n'est pas une vraie redirection serveur. Il apparaît dans les outils de développement, mais il n'a rien à corriger : ne le confondez pas avec une redirection à nettoyer.

Le coût caché : les URLs redirigées encore maillées

Voici le point que presque personne ne traite, et qui pèse pourtant sur les gros sites. Une redirection peut être parfaitement propre et vous coûter quand même, si vous continuez à pointer vers l'ancienne URL.

Chaque lien interne vers une adresse redirigée force Google et vos visiteurs à passer par un saut inutile. Sur le crawl, c'est du budget dépensé pour atteindre une page qui n'existe plus que pour rediriger. Et un sitemap qui liste encore d'anciennes URLs redirigées envoie à Google un signal contradictoire : vous lui soumettez des pages que vous lui demandez par ailleurs de quitter.

La règle est simple : une fois une redirection en place, mettez à jour vos liens internes et votre sitemap pour pointer directement vers l'URL finale. La redirection reste comme filet de sécurité pour les liens externes que vous ne contrôlez pas, mais votre propre site, lui, ne doit plus passer par elle.

Maintenant que vous savez distinguer la redirection saine du vrai problème, encore faut-il repérer les secondes parmi les premières — sur l'ensemble de vos URLs.

Identifier les pages concernées sur la liste que vous analysez

C'est là que la Search Console montre sa limite : son outil d'inspection d'URL ne traite qu'une seule URL à la fois. Pour savoir, page par page, vers quelle cible elle redirige, si elle forme une chaîne et si vous la liez encore, vous inspectez, vous lisez, vous passez à la suivante. Sur quelques pages, c'est jouable. Sur des centaines, repérer la chaîne qui s'allonge ou la page stratégique mal redirigée devient impraticable.

C'est le mur qu'IndexProbe fait sauter. IndexProbe est la version en masse de l'outil d'inspection d'URL de Google : il interroge l'API officielle de la Search Console pour inspecter, en une seule analyse, la liste d'URLs que vous lui fournissez (import CSV, sitemap, copier-coller). Pour chaque page, il affiche son statut d'indexation, l'URL de destination de la redirection, le segment et les liens internes reçus.

Voir, pour chaque URL, sa cible de redirection et les chaînes qui se forment, sur toute votre liste, aucun rapport natif de la GSC ne le donne.

Ce que vous en tirez dépend de la liste que vous apportez. IndexProbe n'explore pas votre site pour découvrir des URLs : il inspecte celles que vous lui donnez, et celles-là seulement.

• Une sélection de pages stratégiques (vos pages clés, votre sitemap des pages à indexer). Toute page importante qui ressort « Page avec redirection » alors qu'elle devait être indexée est un signal immédiat : une redirection par erreur, ou une cible qui n'est pas la bonne.
• Un export complet de vos URLs (sitemap entier, export de crawl…). La segmentation par type de pages montre où les redirections se concentrent, et le croisement avec les liens internes révèle les anciennes URLs redirigées que votre maillage continue de pointer.

💡 Vous voulez savoir vers quoi redirigent vos URLs, lesquelles forment des chaînes et lesquelles sont encore maillées ? IndexProbe inspecte votre liste d'URLs et vous donne la réponse en une analyse. Tester IndexProbe en accès anticipé →

Corriger selon le cas

Une fois vos pages triées, la correction dépend du problème. La plupart des redirections n'en demandent aucune ; concentrez-vous sur les quatre cas suivants.

1. Chaîne de redirection. Remplacez la cascade par une redirection directe de l'URL de départ vers l'URL finale. A ne doit plus passer par B et C : A renvoie directement vers D.
2. Boucle de redirection. Identifiez les deux règles qui se renvoient l'une à l'autre et corrigez celle qui est en trop, pour que la chaîne se termine sur une vraie page en 200.
3. Cible non pertinente. Faites pointer la redirection vers l'équivalent réel de la page (le produit qui remplace, la catégorie la plus proche), pas vers l'accueil par défaut.
4. Maillage et sitemap. Mettez à jour vos liens internes et votre sitemap pour viser l'URL finale, sans passer par la redirection. Et vérifiez le code : un déplacement définitif doit être un 301 (ou 308), pas un 302/307.

Vérifier que la correction a fonctionné

Après vos corrections, confirmez à l'échelle. Réinspectez vos URLs et comparez deux analyses dans le temps : les chaînes doivent être résorbées (un seul saut), les pages stratégiques mal redirigées doivent désormais viser la bonne cible — ou être réindexées si elles ne devaient pas rediriger du tout.

C'est la boucle complète : comprendre que la redirection est souvent normale, repérer chaînes, boucles et cibles non pertinentes, corriger en direct, vérifier.

Questions fréquentes

« Page avec redirection », est-ce grave ? Pas en soi. Dans la majorité des cas, c'est une redirection normale (HTTPS, www, slash, migration) et Google indexe correctement la cible. Cela devient un problème en cas de chaîne, de boucle, de cible non pertinente, ou d'une page redirigée par erreur.

Pourquoi ma page apparaît-elle en « Page avec redirection » ? Parce que cette URL renvoie vers une autre adresse. Google n'indexe pas l'URL source, mais sa destination. Vérifiez vers quelle page elle redirige et en combien de sauts : si la cible est la bonne et le saut unique, il n'y a rien à faire.

Faut-il utiliser une redirection 301 ou 302 ? Pour un déplacement définitif, utilisez un 301 (ou un 308, qui préserve la méthode HTTP) : la cible devient canonique. Pour un déplacement temporaire, un 302 (ou un 307) : Google garde l'URL d'origine. Un 302 laissé en place longtemps finit traité comme un 301.

Qu'est-ce qu'une chaîne de redirection et pourquoi la corriger ? C'est une suite de redirections (A vers B vers C). Chaque saut ralentit le chargement, consomme du budget de crawl et dilue les signaux. La correction consiste à rediriger directement l'URL de départ vers l'URL finale, en un seul saut.

Le « 307 » que je vois est-il un problème ? Pas forcément. Si votre site utilise HSTS, le navigateur force lui-même HTTP vers HTTPS via un 307 généré localement : ce n'est pas une vraie redirection serveur et il n'y a rien à corriger. Un 307 renvoyé par le serveur, lui, est une redirection temporaire classique.

Comment vérifier ce statut sur un grand nombre d'URLs ? L'inspecteur d'URL de la Search Console ne traite qu'une URL à la fois. Pour trier à l'échelle, un outil comme IndexProbe inspecte la liste d'URLs que vous lui fournissez (CSV, sitemap) et affiche, pour chacune, le statut, la cible de redirection et les liens internes reçus.

---

Arrêtez de suivre vos redirections une URL à la fois. IndexProbe se branche sur l'API officielle de la Search Console et inspecte votre liste d'URLs en une seule analyse : statut d'indexation, cible de redirection, segment, liens internes. Vous repérez en quelques minutes les chaînes, les boucles et les cibles non pertinentes, et vous vérifiez vos corrections d'une analyse à l'autre.

Tester IndexProbe en accès anticipé →