Construire un plan de redirection 301 depuis un crawl
Transformer un crawl en table de redirections 301 : une ligne par ancienne URL, une destination décidée, aucune chaîne et un contrôle avant la bascule.
Par Ismael · Relu le 11 novembre 2026
Publié le 11 novembre 2026
Un plan de redirection 301 se construit à partir d’un crawl, pas d’une intuition. SiteBienfait exporte chaque URL de l’ancien site, associe une destination décidée et vérifie que la redirection répond en un seul saut avant la bascule, sur une préproduction.
Qu’est-ce qu’un plan de redirection 301 ?
C’est une table, avec une ligne par ancienne URL. Chaque ligne porte au minimum : l’ancienne adresse, son code de réponse actuel, la nouvelle adresse ou la décision de suppression, le type de redirection (301 ou 308 pour un déplacement permanent), la raison du choix, la personne qui a validé et l’état du contrôle. Un plugin qui redirige tout vers l’accueil n’est pas un plan : c’est une capture d’écran de l’ancien site qui ne dit rien de la correspondance entre les pages. La table doit rester lisible par un humain, pas seulement par un module.
Pourquoi partir d’un crawl plutôt que d’une liste de pages ?
Parce que le crawl trouve ce que le menu ignore : les anciennes pages de campagne, les PDF, les versions paginées, les doublons de paramètres, les pages orphelines encore liées de l’extérieur. Il donne aussi le code HTTP réel, le titre et la canonical de chaque URL, ce qu’aucun export de CMS ne fournit de façon fiable. Le crawl se lance sur l’ancien site avant tout changement, avec la même autorisation d’exploration que les robots. Le vérificateur de plan de redirections accepte cet export et signale les lignes incomplètes.
Quelles règles appliquer à chaque ligne ?
Trois règles suffisent à éviter la majorité des pertes. D’abord, une ancienne URL vers une seule destination, la plus proche en contenu et dans la même langue. Ensuite, zéro chaîne : la destination finale répond directement, sans repasser par une autre redirection. Enfin, une décision explicite pour les pages sans équivalent, en 410 quand le contenu est supprimé définitivement, en 404 quand il a simplement disparu. Google documente la redirection permanente et son effet de consolidation des signaux (Google, documentation Search Central sur les redirections, consultée le 11 novembre 2026). Rediriger des dizaines de pages différentes vers l’accueil ne respecte aucune de ces règles.
Comment détecter les chaînes et les boucles ?
Le contrôle se fait à l’échelle du site, pas à l’œil. On suit chaque ancienne URL jusqu’à sa destination finale et on compte les sauts : un saut est la norme, deux sauts doivent être corrigés, trois sauts cachent souvent une redirection héritée d’une migration précédente. Une boucle se détecte quand la suite des sauts revient à l’ancienne adresse. Ce test se fait sur la préproduction, avant l’ouverture, puis une seconde fois après la bascule, car un hébergement ou un CDN peut ajouter une redirection invisible dans la configuration.
Que faire des URL sans page équivalente ?
Les supprimer proprement, avec une page d’erreur utile qui propose la navigation principale et une recherche. Une redirection vers une page qui n’a pas de rapport avec la requête d’origine produit un « soft 404 » : l’utilisateur arrive, ne trouve pas ce qu’il cherchait, et repart. La Search Console signale ces cas dans le rapport sur l’indexation des pages (Google, aide Search Console, consultée le 11 novembre 2026). Mieux vaut une page 410 claire qu’une fausse correspondance.
Comment vérifier que le plan fonctionne ?
Sur un échantillon de toutes les familles d’URL — pages de contenu, catégories, PDF, anciennes campagnes — on vérifie le code, la destination et le nombre de sauts. Puis on compare, après bascule, les URL « Page avec redirection » et les 404 dans la Search Console. Le plan est bon quand une URL inconnue de la table se comporte comme prévu : suppression ou page 404, jamais une boucle. Pour la séquence complète des contrôles avant mise en ligne, voir la checklist de migration SEO.
Sources
- Google Search Central, « Redirects and Google Search », documentation consultée le 11 novembre 2026 : developers.google.com/search/docs/crawling-indexing/301-redirects
- Google Search Central, « Move a site with URL changes », documentation consultée le 11 novembre 2026 : developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes
- Aide Search Console, « Rapport sur l’indexation des pages », consultée le 11 novembre 2026 : support.google.com/webmasters/answer/7440203
Le parcours de migration de site de SiteBienfait reprend ces étapes dans l’ordre : crawl, table de décisions, préproduction, bascule et mesure.
Questions fréquentes
01 Combien de redirections 301 faut-il créer pour un site de 300 pages ?
Une ligne par ancienne URL qui a reçu des liens ou des clics, pas une ligne par nouvelle page. Un site de 300 pages en compte souvent moins de 250, et parfois plus quand des campagnes ont créé des URL parallèles.
02 Une chaîne de redirections est-elle acceptable ?
Non. Une redirection doit répondre en un seul saut vers la destination finale. Une chaîne ajoute de la latence et complique le diagnostic quand une cible change.
03 Faut-il rediriger les URL avec des paramètres de suivi ?
Non, sauf si ces URL servent réellement du contenu distinct. Les paramètres de campagne se bloquent ou se canonisent, ils ne se redirigent pas un par un.