# Architecture d’un plan de redirection : du tableur au fichier .htaccess

> Un tableur de 800 lignes hérité d'un client ne suffit pas à écrire un fichier .htaccess fiable. Voici l'architecture intermédiaire qui évite les erreurs de conversion.

- Auteur : Clément Hadrot
- Publié le : 2020-11-26
- Mis à jour le : 2020-11-26
- Catégorie : SEO & GEO
- URL : https://wpmoderne.dev.wordpress-developpement.fr/seo/architecture-plan-redirection-tableur-htaccess/

## L’essentiel

- Un tableau brut ne se convertit jamais directement et sans risque en règles serveur
- Trier par spécificité décroissante évite les conflits entre règles
- Séparer redirections exactes et redirections par motif limite les faux positifs

Un client transmet un tableur de 800 lignes contenant l'historique de toutes les redirections accumulées depuis la création du site, sans ordre ni structure claire : certaines lignes datent d'une migration de 2017, d'autres d'une correction ponctuelle faite l'an dernier par un prestataire différent. La demande semble simple : « transformez ça en fichier .htaccess ». En pratique, une conversion ligne à ligne sans étape intermédiaire produit presque toujours des conflits de règles invisibles à l'œil nu.

Voici l'architecture utilisée pour transformer ce type de tableur en un fichier de règles fiable, avec les étapes de tri et de validation qui évitent les pièges classiques de ce genre de conversion.

## Étape 1 : normaliser le tableur avant toute conversion

La première étape ne touche pas encore au code serveur. Elle consiste à nettoyer le tableur lui-même : supprimer les doublons, repérer les lignes où la source et la destination sont identiques (des redirections fantômes qui ne servent à rien), et surtout, repérer les chaînes de redirection où la destination d'une ligne est la source d'une autre ligne du même tableur.

```
Source                          Destination
/ancien-produit-a/       ->    /produit-a-nouveau/
/produit-a-nouveau/      ->    /catalogue/produit-a/
```

Ce type de chaîne, une fois repéré, doit être aplati avant conversion : la première ligne doit pointer directement vers `/catalogue/produit-a/`, sans passer par l'étape intermédiaire.

## Étape 2 : classer les règles par type

Toutes les redirections ne se ressemblent pas structurellement. Le tableur mélangeait trois catégories bien distinctes, qu'il faut séparer avant de générer le fichier final :

- **Redirections exactes** : une URL précise vers une autre URL précise, sans variation possible.
- **Redirections par motif** : un ensemble d'URL partageant un préfixe commun, à rediriger vers un nouveau préfixe équivalent (toute une ancienne arborescence de catégorie, par exemple).
- **Redirections conditionnelles** : dépendant d'un paramètre de requête ou d'un sous-domaine, à traiter séparément car elles nécessitent des drapeaux Apache spécifiques.

> L'essentiel à retenir : Un tableau brut ne se convertit jamais directement et sans risque en règles serveur ; Trier par spécificité décroissante évite les conflits entre règles ; Séparer redirections exactes et redirections par motif limite les faux positifs

## Étape 3 : l'arborescence de traitement retenue

Pour ce projet, l'architecture finale du fichier de règles a été organisée selon la structure suivante, des règles les plus spécifiques vers les plus génériques :

```
.htaccess
├── Bloc 1 : redirections exactes (les plus spécifiques, testées en premier)
│   ├── /ancien-produit-a/ -> /catalogue/produit-a/
│   └── ... (612 lignes exactes)
├── Bloc 2 : redirections par motif (préfixes d'arborescence)
│   ├── ^ancienne-categorie/(.*)$ -> /catalogue/$1
│   └── ... (14 blocs de motif)
├── Bloc 3 : redirections conditionnelles
│   └── règles avec [QSA] pour préserver les paramètres de requête utiles
└── Règles de réécriture natives de WordPress (toujours en dernier, [L])
```

L'ordre est essentiel : Apache applique les règles dans l'ordre du fichier et s'arrête à la première correspondance marquée `[L]`. Placer une règle par motif générique avant une règle exacte plus spécifique ferait que la règle exacte ne soit jamais atteinte, un bug silencieux qui ne se détecte qu'en testant individuellement chaque URL du tableur d'origine.

## Étape 4 : générer le fichier depuis le tableur nettoyé

Une fois le tableur trié par catégorie et par ordre de spécificité, la génération du fichier `.htaccess` devient mécanique. Pour les redirections exactes, la syntaxe reste simple :

```
Redirect 301 /ancien-produit-a/ https://exemple.fr/catalogue/produit-a/
```

Pour les redirections par motif, une règle de réécriture avec capture de groupe évite de dupliquer une ligne par produit :

```
RewriteRule ^ancienne-categorie/(.*)$ /catalogue/$1 [R=301,L]
```

## Étape 5 : valider chaque bloc avant mise en production

Un script de test simple, qui parcourt le tableur d'origine et interroge chaque source avec `curl -o /dev/null -s -w "%{http_code} %{redirect_url}\n"`, permet de vérifier que chaque ligne du tableur initial atterrit bien sur la destination attendue, sans passer par un environnement de production. Cette validation a permis de repérer trois règles par motif qui se chevauchaient partiellement, un conflit invisible dans le tableur mais réel une fois converti en expressions régulières.

## Notre verdict

Un tableur de redirections, aussi complet soit-il, n'est jamais directement convertible en fichier serveur sans étape de tri intermédiaire. L'architecture en blocs ordonnés par spécificité, du plus exact au plus générique, avec une validation systématique avant mise en production, transforme un exercice risqué en processus reproductible pour la prochaine migration.