# Une redirection 302 oubliée à la place d’une 301, pendant six mois

> Une simple confusion de code HTTP lors d'une migration de page a dilué la valeur de référencement de la nouvelle URL pendant six mois avant d'être repérée.

- Auteur : WordPress Développement
- Publié le : 2021-11-02
- Mis à jour le : 2021-11-02
- Catégorie : SEO & GEO
- URL : https://www.wpmoderne.fr/seo/redirection-302-oubliee-place-301-six-mois/

## L’essentiel

- Une redirection 302 signale un déplacement temporaire, jamais définitif
- wp_redirect() utilise 302 par défaut, il faut préciser le code
- Le correctif seul ne suffit pas, il faut aussi resoumettre l'URL

`wp_redirect( $nouvelle_url )`. Cette ligne de code, en apparence anodine, a silencieusement dilué la valeur de référencement d'une page migrée pendant six mois entiers. La cause : cette fonction WordPress utilise par défaut un code de statut HTTP 302, signalant une redirection temporaire, là où une migration définitive de page exige un code 301.

Ce cas de débogage détaille le symptôme observé, le diagnostic qui a permis de remonter à la cause, le correctif appliqué, et surtout la mesure de prévention qui évite qu'un tel oubli ne se reproduise sur un futur projet. Il ne traite pas du cas plus large d'un plan de redirections en masse lors d'une refonte complète.

## Symptôme

Une page produit avait été renommée dans le cadre d'une réorganisation de catalogue, passant de `/produits/ancien-nom/` à `/produits/nouveau-nom/`. La redirection semblait fonctionner parfaitement du point de vue utilisateur : taper l'ancienne URL menait bien vers la nouvelle page, sans erreur visible. Pourtant, six mois plus tard, l'ancienne URL restait indexée par Google au lieu de la nouvelle, et la nouvelle page peinait à accumuler la popularité de liens que l'ancienne possédait pourtant depuis des années.

## Diagnostic

> L'essentiel à retenir : Une redirection 302 signale un déplacement temporaire, jamais définitif ; wp_redirect() utilise 302 par défaut, il faut préciser le code ; Le correctif seul ne suffit pas, il faut aussi resoumettre l'URL

Une inspection des en-têtes HTTP avec un simple outil en ligne de commande a révélé le problème :

```
curl -I https://exemple.fr/produits/ancien-nom/

HTTP/1.1 302 Found
Location: https://exemple.fr/produits/nouveau-nom/
```

Le code 302 explique tout : ce statut signifie « déplacement temporaire », ce qui indique aux moteurs de recherche de continuer à considérer l'URL d'origine comme la référence légitime, en attendant un retour éventuel à la normale. Le code fautif, retrouvé dans un module maison de gestion des anciennes URL, ressemblait à ceci :

```
add_action( 'template_redirect', function() {
    $anciennes_urls = array(
        '/produits/ancien-nom/' => '/produits/nouveau-nom/',
    );
    $chemin = $_SERVER['REQUEST_URI'];
    if ( isset( $anciennes_urls[ $chemin ] ) ) {
        wp_redirect( home_url( $anciennes_urls[ $chemin ] ) );
        exit;
    }
} );
```

## Correctif

La fonction `wp_redirect()` accepte un second paramètre pour préciser le code de statut HTTP. Pour une migration définitive, il fallait utiliser explicitement le code 301, ou recourir à la fonction dédiée `wp_safe_redirect()` avec ce même paramètre :

```
add_action( 'template_redirect', function() {
    $anciennes_urls = array(
        '/produits/ancien-nom/' => '/produits/nouveau-nom/',
    );
    $chemin = $_SERVER['REQUEST_URI'];
    if ( isset( $anciennes_urls[ $chemin ] ) ) {
        wp_safe_redirect( home_url( $anciennes_urls[ $chemin ] ), 301 );
        exit;
    }
} );
```

Après ce correctif, une resoumission manuelle de la nouvelle URL via l'outil d'inspection a accéléré la prise en compte du changement, plutôt que d'attendre un nouveau passage naturel du robot.

## Ce que révélait le rapport de couverture

Le rapport de la Search Console signalait cette page sous la catégorie « Page avec redirection », une information technique correcte mais peu explicite pour qui ne sait pas déjà que le code de statut renvoyé pose problème. C'est en croisant cette information avec le résultat de la commande `curl -I` que le diagnostic a pu être posé avec certitude, plutôt qu'en se fiant à la seule catégorie affichée dans le rapport.

## Prévention

- Vérifier systématiquement le code HTTP renvoyé après toute mise en place de redirection, avec `curl -I` ou un outil équivalent
- Ne jamais utiliser `wp_redirect()` sans préciser explicitement le code pour une redirection permanente
- Documenter dans le code une raison claire à chaque redirection temporaire, pour distinguer un oubli d'un choix volontaire

> Notre règle depuis ce cas : toute redirection ajoutée en code doit préciser explicitement son code de statut, jamais laisser la valeur par défaut décider à la place du développeur.

## En résumé

Un code de statut HTTP mal choisi peut passer totalement inaperçu du point de vue de l'expérience utilisateur, tout en modifiant profondément la façon dont les moteurs de recherche traitent le transfert de popularité entre deux URL. Vérifier le code exact renvoyé par une redirection, plutôt que de se fier à son seul comportement visible, aurait permis d'éviter six mois de dilution du référencement sur ce projet.