Page avec redirection dans Search Console : quand elle cache un problème

Dans Search Console, « Page avec redirection » signifie que Google a demandé une URL, que le serveur l'a envoyé ailleurs, et que Google prend en compte la destination pour son index plutôt que l'URL que vous voyez dans la liste. La plupart du temps, c'est une redirection qui fait exactement ce pour quoi vous l'avez mise en place, après un passage au HTTPS, un choix entre www et domaine nu, ou un changement d'URL. Cela devient un problème lorsque la destination est mauvaise ou non indexée, ou lorsque votre propre sitemap, vos liens et vos balises canoniques continuent d'envoyer Google vers l'ancienne adresse.

Ce que signifie cet état selon Google

La documentation de Google sur le Rapport sur l'indexation des pages (consultée en octobre 2026) le décrit comme « une URL non canonique qui redirige vers une autre page », ajoute que cette URL « ne sera pas indexée », et précise que la cible « pourra être indexée ou non, selon ce que Google pense de cette URL cible ».

Cette formulation a deux conséquences :

• L'état concerne l'URL source, jamais la destination. Voir http://example.com/pricing dans la liste ne vous dit rien sur l'indexation de https://www.example.com/pricing. La destination se vérifie séparément.
• Le type de redirection compte. La documentation de Google sur les redirections (consultée en octobre 2026) les classe en 2 groupes. Les redirections permanentes (HTTP 301 et 308, une balise meta refresh ou un en-tête HTTP refresh réglé sur 0 seconde, et une redirection JavaScript via location) servent de signal indiquant que la cible doit être canonique, et c'est la cible qu'affichent les résultats de recherche. Les redirections temporaires (302, 303, 307, ainsi qu'un meta refresh ou un HTTP refresh différé) sont suivies, mais ne servent pas de signal : les résultats affichent alors l'URL source. Une redirection JavaScript n'est vue que si Google parvient à effectuer le rendu de la page.

Il s'agit d'un état différent d'« Erreur liée à des redirections », que Google utilise pour les redirections qu'il n'a pas pu mener à terme : une boucle, une chaîne trop longue, une URL de redirection dépassant la longueur maximale d'une URL, ou une URL incorrecte ou vide dans la chaîne.

D'où viennent les URL qui redirigent

Sur un site sain, les sources normales produisent l'essentiel des URL de cette liste :

1. Normalisation du protocole et de l'hôte. De http:// vers https://, et du domaine nu vers www ou l'inverse.
2. Normalisation de la barre oblique finale. De /blog vers /blog/, selon un réglage par défaut de la plateforme ou du serveur.
3. Migrations et changements d'URL. Un nouveau domaine, une nouvelle structure de chemins, un produit renommé. WordPress, par exemple, envoie une 301 de l'ancien slug d'un article vers son nouveau permalien lorsque vous modifiez le slug.
4. Pages retirées et regroupées dans une page qui leur succède. Un ancien guide fusionné dans un plus récent.

Les schémas problématiques viennent tous de votre propre site :

1. Votre sitemap liste des URL qui redirigent. Sur 29 sites externes dont SEOReport a récupéré les pages du sitemap entre mai et octobre 2026, 6 (21 %) listaient dans leur sitemap XML des URL qui redirigent ailleurs.
2. Vos liens internes, balises canoniques ou annotations hreflang citent l'ancienne URL. Templates de navigation, anciens liens dans le corps des pages et balises canoniques codées en dur en http:// continuent de fournir à Google l'adresse qui redirige.
3. La redirection mène au mauvais endroit. Les consignes de Google sur les migrations de site (consultées en octobre 2026) avertissent que rediriger de nombreuses anciennes URL vers une seule page sans rapport, comme la page d'accueil, « pourrait être traité comme une erreur soft 404 ».
4. La redirection est une chaîne, ou temporaire alors qu'elle devrait être permanente. Plusieurs étapes pour atteindre la destination, ou une 302 laissée en place après un déménagement qui ne sera jamais annulé.

Dans cet échantillon, les redirections étaient le plus fréquent des 3 signaux contradictoires. Chacune demande à Google d'indexer une URL dont vous lui avez déjà dit qu'elle n'était pas la vraie.

Est-ce un problème ? Laisser, corriger ou surveiller

flowchart TD
    A["URL listée en Page avec redirection"] --> B{"Vouliez-vous la rediriger ?"}
    B -->|non| C["Supprimer la redirection ou rétablir la page"]
    B -->|oui| D{"La destination est-elle le bon remplacement ?"}
    D -->|non| E["Rediriger vers l'équivalent le plus proche, ou renvoyer 404 ou 410"]
    D -->|oui| F{"Une seule étape, et permanente ?"}
    F -->|non| G["Réduire à une seule 301 ou 308"]
    F -->|oui| H{"Votre sitemap, un lien ou une canonique cite-t-il l'ancienne URL ?"}
    G --> H
    H -->|oui| I["Mettre à jour chaque référence vers l'URL finale"]
    H -->|non| J{"La destination est-elle indexée ?"}
    I --> J
    J -->|oui| K["Laisser"]
    J -->|non| L["Vérifier l'état propre de la destination"]

Comment confirmer la cause en jeu

Commencez par le filtre de sitemap. En haut du Rapport sur l'indexation des pages, faites passer le filtre de « Toutes les pages connues » à « Toutes les pages envoyées », puis rouvrez « Page avec redirection ». Toute URL encore listée est une URL qui redirige et qu'un de vos sitemaps a envoyée. Le tableau d'exemples est limité à 1 000 lignes : sur un grand site, testez donc aussi le sitemap directement (voir ci-dessous).

Inspectez quelques URL. La documentation de Google sur l'inspection d'URL précise que le résultat indexé reflète l'URL saisie, et non sa cible de redirection. Deux champs désignent l'origine du problème : « Page de provenance » montre une page que Google a pu utiliser pour découvrir l'URL, et « Sitemaps » montre tout sitemap qui la liste. Si la page de provenance est sur votre site, vous avez un lien interne à mettre à jour. Si elle est sur un autre site, la redirection fait son travail.

Retracez vous-même les étapes. La même documentation indique que le test en ligne (« Tester l'URL en ligne ») suit les redirections sans le signaler et n'affiche pas l'URL finale testée. Un terminal montre chaque étape :

curl -sIL http://example.com/old-page | grep -iE '^(HTTP/|location)'

Une seule 301 ou 308 suivie d'un seul 200, c'est une redirection propre. Deux lignes de redirection ou plus, c'est une chaîne, et une 302 ou 307 sur un déménagement définitif doit être changée.

Inspectez la destination séparément. Collez l'URL finale dans l'outil d'inspection d'URL. Si elle n'est pas indexée, le problème se situe sur cette page, et son propre état vous indique où chercher : une destination qui porte un noindex est traitée dans URL marquée "noindex", et une destination que Google a récupérée mais laissée de côté dans Explorée, actuellement non indexée.

Trouver lesquels de vos fichiers citent encore l'ancienne URL

Search Console montre un échantillon des sources de découverte. Vos propres fichiers les montrent toutes. Testez chaque URL listée dans votre sitemap et affichez celles qui ne répondent pas 200 :

curl -s https://www.example.com/sitemap.xml \
  | grep -o '<loc>[^<]*</loc>' | sed -e 's/<loc>//' -e 's/<\/loc>//' -e 's/&amp;/\&/g' \
  | while read -r url; do
      code=$(curl -s -o /dev/null -w '%{http_code}' "$url")
      [ "$code" != "200" ] && echo "$code $url"
    done

Une 301, 302, 307 ou 308 dans la sortie correspond à une entrée qui redirige. Si le fichier est un index de sitemaps, exécutez la même boucle sur chaque sitemap enfant qu'il liste, et décompressez d'abord tout fichier .xml.gz. Vérifiez ensuite les templates communs à toutes les pages, car un seul lien d'en-tête se répète sur chaque URL :

curl -s https://www.example.com/ \
  | grep -oE '(href|content)="[^"]+"' \
  | grep -E 'http://|//example\.com'

Remplacez le dernier motif par l'ancien protocole, hôte ou chemin que vous avez abandonné. Sur WordPress, les anciennes URL absolues se trouvent généralement dans le contenu des articles, et WP-CLI peut les compter avant toute modification :

wp search-replace 'http://example.com' 'https://www.example.com' --dry-run

Lorsque vous l'exécutez pour de bon, faites d'abord une sauvegarde de la base de données et ajoutez --skip-columns=guid, pour que les GUID des articles conservent leur valeur d'origine.

Comment corriger chaque cause

Entrées de sitemap. Régénérez le sitemap à partir des seules URL finales : chaque entrée doit répondre 200 et se déclarer elle-même canonique. La documentation de Google sur les sitemaps (consultée en octobre 2026) demande d'y inclure les URL que vous voulez voir dans les résultats de recherche, ce qui n'est pas le cas d'une URL qui redirige. La documentation de Google sur la canonicalisation ajoute que chaque page listée dans un sitemap est proposée comme URL canonique. Notre guide des sitemaps XML couvre le reste d'un sitemap propre.

Liens internes, balises canoniques et hreflang. Mettez-les à jour vers l'URL de destination. La documentation de Google sur la canonicalisation (consultée en octobre 2026) recommande de créer des liens vers l'URL canonique plutôt que vers un doublon, et une balise canonique qui cite une URL qui redirige demande à Google de regrouper les signaux sur une adresse qui ne contient pas la page. Le guide des balises canoniques explique comment ces signaux se combinent, et Page en double sans URL canonique sélectionnée par l'utilisateur traite le cas où les variantes d'hôte et de protocole ne sont pas redirigées du tout.

Mauvaise destination. Faites pointer chaque ancienne URL vers son équivalent le plus proche. Lorsqu'une page n'a pas de remplaçante, un code 404 ou 410 est la réponse honnête, et il évite le traitement en soft 404 que Google décrit pour les redirections vers des pages sans rapport.

Chaînes et redirections temporaires. Écrivez une seule règle qui mène directement de l'URL d'entrée à l'URL finale, en 301 ou 308. Chaînes de redirections : comment elles apparaissent et comment les aplatir déroule un exemple à 4 étapes, et le guide des redirections et de la normalisation des URL traite ensemble les règles de protocole, d'hôte et de barre oblique.

Conservez les redirections elles-mêmes. Les consignes de Google sur les migrations de site recommandent de conserver les redirections le plus longtemps possible, en général au moins 1 an. Les liens externes et les favoris continuent d'arriver sur les anciennes URL bien après que vos propres références ont été nettoyées.

Comment vérifier la correction

1. Relancez la boucle sur le sitemap. Elle ne doit rien afficher.
2. Relancez le traçage sur un échantillon d'anciennes URL : une seule étape permanente, puis 200, sur la bonne page.
3. Renvoyez le sitemap dans le rapport Sitemaps de Search Console pour demander à Google de le relire.
4. Surveillez le filtre « Toutes les pages envoyées ». Les URL qui redirigent doivent en sortir une fois que Google a relu votre sitemap et les a réexplorées. La documentation de Google sur la nouvelle exploration indique que l'exploration peut prendre de quelques jours à quelques semaines, selon le calendrier de Google et non le vôtre.
5. N'utilisez « Valider la correction » que pour les redirections que vous avez supprimées. La validation réexplore les URL concernées pour vérifier si chacune présente toujours le problème, et une redirection volontaire redirige toujours, par définition. La documentation de Google indique que la validation prend généralement jusqu'à 2 semaines environ, et parfois beaucoup plus.

Search Console vous dit quelles URL redirigent. Un diagnostic SEOReport complet audite le site lui-même et nomme les redirections que vous ne devriez pas annoncer : les URL qui redirigent parmi les pages listées dans votre sitemap, chacune avec sa destination, une cible canonique de la page d'accueil ou des cibles de versions linguistiques qui redirigent, et chaque étape lorsque l'adresse que vous soumettez en compte plusieurs. Il ne teste pas les redirections des liens internes : pour ceux-ci, effectuez la vérification des templates ci-dessus.

Questions fréquentes

Les URL qui redirigent finiront-elles par quitter le rapport ?

Elles peuvent rester longtemps dans la vue « Toutes les pages connues », car Google continue de réexplorer les URL qu'il connaît déjà, y compris celles vers lesquelles d'autres sites font des liens. C'est le bon état final lorsque la redirection est voulue et que la destination est indexée. Ce qui doit diminuer, c'est le nombre de ces URL envoyées par votre propre sitemap.

Ma page d'accueil est listée en Page avec redirection. Est-ce grave ?

En général, l'URL listée est une variante comme http://example.com/, qui redirige vers votre adresse préférée https://www.example.com/. Inspectez l'URL préférée de la page d'accueil : si elle est indexée, la variante se comporte correctement. Si l'URL préférée elle-même apparaît dans la liste, votre page d'accueil redirige vers un endroit imprévu, et il faut corriger.

Faut-il utiliser une balise canonique plutôt qu'une redirection ?

Utilisez une redirection lorsque l'ancienne URL ne doit plus afficher sa propre page à personne. Utilisez une balise canonique lorsque les deux URL doivent continuer à fonctionner, par exemple une vue filtrée de la même liste de produits. Une URL qui reste accessible avec une balise canonique pointant ailleurs est généralement signalée en « Autre page avec balise canonique correcte » lorsque Google accepte cette URL canonique, ce qui ne demande aucune action.