Préparez le plan de redirections avant de publier les nouvelles adresses. Chaque ancienne URL doit recevoir une décision justifiée : destination équivalente, maintien ou retrait. Une redirection générale vers l'accueil ne remplace pas cette analyse et peut décevoir la personne qui cherchait un contenu précis.
Construire l'inventaire des anciennes adresses
Rassemblez les URL connues par le contenu, les sitemaps, les liens internes et les outils de suivi auxquels vous avez accès. Conservez l'origine de chaque liste et les limites de couverture. Un export incomplet ne doit pas être présenté comme l'historique entier du site.
La documentation Google sur les changements d'URL fournit des repères pour préparer un déplacement. Votre travail consiste ensuite à établir les correspondances propres aux contenus, avec un contrôle du comportement réellement publié.
Donner une décision à chaque ligne
Votre registre peut contenir : ancienne adresse, intention du contenu, nouvelle adresse, motif, réponse attendue et résultat du test. Ajoutez un responsable lorsqu'une décision dépend encore de la rédaction. Une ligne vide doit rester visible comme travail non terminé.
Si deux anciens articles sont regroupés, vérifiez que la nouvelle page répond encore à leurs besoins. Si aucun contenu équivalent n'existe, documentez le retrait au lieu de créer une destination artificielle. Les adresses conservées doivent aussi être recensées pour éviter une règle trop large qui les détournerait.
Exemple fictif : regrouper deux guides complémentaires
Imaginons deux anciens guides sur la préparation d'une réservation, réunis dans une page qui couvre effectivement les deux étapes. Le registre nomme cette destination commune et explique le regroupement. Une ancienne page de recrutement supprimée ne doit pas recevoir la même destination au seul motif qu'elle appartenait au site.
Après publication, testez chaque ancienne adresse sans suivre automatiquement la redirection, relevez la réponse et sa destination, puis contrôlez le trajet complet. Vérifiez également une URL inconnue : elle ne doit pas devenir un accueil affiché avec succès par un mécanisme de repli trop large.
Ce scénario est fictif. Il montre pourquoi la pertinence du contenu et le résultat HTTP doivent apparaître dans deux colonnes distinctes du registre.
Vérifier les signaux et les usages après bascule
Contrôlez que les liens internes utilisent les nouvelles adresses lorsque cela correspond à la décision. Examinez les URL canoniques, les sitemaps et les boutons. Une redirection correcte peut coexister avec un gabarit qui continue à publier les anciennes références.
Vérifiez les paramètres utiles au parcours, sans supposer qu'ils peuvent tous être supprimés ou tous conservés. Un paramètre de langue et un identifiant sensible ne demandent pas la même décision. Testez les cas réellement présents dans l'application.
Conservez les preuves et surveillez les anomalies après publication. Le guide pour analyser une baisse de clics dans Search Console aide à comparer les pages et les périodes, sans attribuer automatiquement toute variation à la refonte.
Questions fréquentes
Peut-on rediriger toutes les anciennes pages vers l'accueil ?
Cela évite de prendre les décisions de contenu, mais ne répond pas forcément à l'intention du visiteur. Recherchez une destination pertinente ou documentez le retrait de la page.
Faut-il tester les redirections une seule fois ?
Contrôlez la mise en ligne, puis les modifications ultérieures qui touchent les règles ou les routes. Le registre permet de rejouer les mêmes cas lors d'un changement d'hébergement ou de structure.
Une refonte garantit-elle le maintien des positions ?
Non. Le contrôle technique réduit les erreurs évitables, mais ne garantit pas un résultat de classement. Distinguez la qualité de la migration des évolutions de demande et de concurrence.
Sources
Documentation consultée lors de la relecture du 10 septembre 2026.