Analyse post-mortem
Vérifiez les backlinks d’une page avant de finaliser la matrice de redirections
Une matrice de redirections est une liste de promesses sur le chemin que prendra la valeur des liens. Cette analyse post-mortem d’une migration fictive montre quelle promesse a été rompue et ce qu’un évaluateur aurait vérifié en amont.

Le dossier de l’affaire (fictif, à titre illustratif)
Imaginez une petite boutique qui migre d’un ancien site PHP vers un nouveau framework. La boutique, ses URLs et tous les chiffres ici sont fictifs.
L’ancien site comptait 400 URLs et l’équipe a rédigé des redirections pour les 120 qu’elle jugeait importantes, puis a configuré une redirection universelle vers la page d’accueil pour le reste. Le lancement s’est fait sans encombre, et en une semaine, les impressions ont chuté sur des pages dont personne n’avait prévu l’impact.
Rien n’était faux dans les redirections qu’ils avaient rédigées. La perte résidait dans les 280 qu’ils avaient oubliées.
Une hypothèse comme celle-ci ne prouve rien. C’est une répétition, et c’est le rapport de couverture de Search Console et la routine d’évaluation gratuite que vous utiliseriez sur le cas réel.
La chronologie semaine par semaine
Une chronologie hypothétique pour la boutique fictive, et non le compte rendu d’une migration réelle.
- 1
Jour 0 : lancement
La redirection universelle envoie toutes les URLs non mappées vers la page d’accueil. Un crawler de recherche traite beaucoup de ces URLs comme des soft 404, et les pages perdent leur identité propre.
- 2
Jour 3 : le sitemap
Le nouveau sitemap ne liste que les nouvelles URLs, et lastmod est défini à la date de déploiement pour chaque ligne, il n’indique plus quelles pages ont réellement changé.
- 3
Jour 9 : les canonicals
Les nouveaux modèles canonicalisent les variantes de produit vers la page parente. Deux anciennes URLs qui détenaient des liens pointent désormais vers une page qui ne les a jamais reçus.
- 4
Jour 21 : l’audit
Quelqu’un lance enfin toppages sur l’ancien domaine. Six URLs concentrent la majorité des domaines référents, et quatre étaient dans la redirection universelle.

Pourquoi une règle de motif n’est pas une matrice
Une règle unique qui envoie tout ce qui se trouve sous un dossier vers la page d’accueil est tentante. Elle ne prend qu’une ligne de configuration. Elle semble terminée. Elle jette aussi par-dessus bord la seule chose que les anciennes URLs portaient : la liste des endroits où les gens avaient fait des liens.
La redirection universelle masque la perte
Supposons que votre ancien site comptait 400 URLs et qu’une redirection universelle envoie les 280 URLs non mappées vers la page d’accueil. Chacune de ces anciennes adresses renvoie désormais la même page. Un crawler de lecture de ce motif comme un ensemble de soft 404, donc les liens pointant vers ces URLs n’ont pas de destination claire.
La redirection universelle est silencieuse. Rien ne plante le jour du lancement, et les tableaux de bord affichent toujours un site sain jusqu’à ce que quelqu’un demande quelles pages recevaient des liens auparavant.
Les motifs conviennent à la longue traîne, pas aux sommets
Un motif est acceptable une fois que les URLs importantes sont gérées une par une. Placez les vingt premières par domaines référents dans la matuelle à la main, une étape chacune, et laissez ensuite une règle couvrir les pages vers lesquelles personne ne fait de liens.
Cet ordre est important car un motif ne peut pas distinguer une page à valeur d’une page vide. Il voit un chemin, pas un nombre de domaines référents.
Gardez le fichier court et le test strict
De longues listes de redirections sur un serveur statique peuvent devenir difficiles à lire. Gérez les URLs importantes avec des lignes explicites et la longue traîne avec une seule règle, afin que le fichier reste assez court pour être examiné.
Que la règle vive dans un fichier de serveur web, une configuration de framework ou un plugin, le test est le même. Demandez chaque ancienne URL et vérifiez le statut et la destination. Si vous testez dix URLs échantillons et que huit renvoient un 301 vers la bonne page, les deux autres renvoient un 200 sur une page qui n’est pas l’ancienne, et c’est l’erreur à traquer avant le lancement.
Ce qu’un évaluateur aurait chiffré en amont
| Ancienne URL | Domaines référents (exemple) | Redirection au jour du lancement | Risque de perte chiffré |
|---|---|---|---|
| /guides/sizing | 46 | Redirection universelle vers la page d’accueil | Élevé : la page est l’actif |
| /blog/2019-review | 31 | Mappée, une étape | Faible |
| /p/12-red-boot | 9 | Canonical vers la page parente | Moyen : la page parente hérite, la variante est perdue |
| /about.php | 4 | Redirection universelle vers la page d’accueil | Faible |
Canonicals, sitemaps et hreflang : les signaux discrets
Avant de vérifier les backlinks d’une page, vérifiez que les signaux sont cohérents. Une redirection n’est qu’une des plusieurs indications qui disent aux moteurs de recherche où se trouve une page. La balise canonical, le sitemap et tout jeu hreflang doivent pointer dans la même direction. Sinon, ils s’annulent. La référence terrain montre quel appel retourne la liste des sources à vérifier.
Les canonicals doivent correspondre à la redirection
Si l’ancienne URL redirige vers la page X, mais que la page X se canonicalise vers la page Y, les signaux sont désormais en désaccord sur quelle page est la véritable. Une redirection déplace les visiteurs, tandis qu’un canonical est une indication sur la version préférée, donc une incohérence rend le résultat difficile à prédire.
Vérifiez les canonicals sur les vingt destinations principales après le lancement. Chacune s’indique-t-elle elle-même, ou la page qu’elle a remplacée ? L’une d’elles indique-elle par erreur la page d’accueil ?
Un sitemap doit lister ce qui est en ligne
Le sitemap est la liste que vous remettez aux moteurs de recherche, il doit donc contenir les destinations en ligne et non les anciennes adresses qui redirigent désormais. Un nouveau sitemap qui ne liste que les nouvelles URLs peut discrètement faire disparaître les pages que vous avez le plus besoin de faire crawler.
Soyez prudent avec lastmod. Si chaque ligne porte la date de déploiement, le champ cesse de dire la vérité sur quelles pages ont changé, et le fichier perd sa valeur en tant que signal de changement.
Hreflang uniquement lorsque la langue change vraiment
Hreflang vaut la peine d’être ajouté lorsque des pages existent en plusieurs langues ou régions, et chaque ensemble doit renvoyer à chaque autre membre. Un site monolingue qui ajoute un jeu hreflang génère du bruit sans aucun sens supplémentaire.
Lorsque vous ajoutez hreflang lors d’une migration, vérifiez que chaque URL alternative renvoie vers une page en ligne et que chaque page de l’ensemble liste toutes les autres.
Ce que les preuves soutiennent, et ce qu’elles ne soutiennent pas
Un 301 direct est la base. Google a indiqué depuis 2016 que les redirections 3xx ne perdent plus de PageRank, donc une matrice propre en une seule étape n’est pas là où la valeur fuit.
La fuite est l’incohérence : une redirection qui pointe vers une page non liée peut être traitée comme un soft 404, et un canonical qui ne correspond pas à la redirection envoie des signaux mixtes. Personne en dehors de Google ne peut mesurer la perte avec précision, c’est pourquoi vous comptez les domaines qui font des liens et traitez le nombre comme l’exposition plutôt que comme une prévision.
Avant le déménagement, lancez toppages pour l’ancien domaine (2 crédits) et refdomains sur le même domaine (2 crédits). Après le déménagement, répétez les deux une fois que le rafraîchissement mensuel est effectué et comparez les deux lectures. Notre index peut avoir besoin d’un cycle pour remarquer le changement. Ne paniquez pas au jour 10. Gardez le premier rapport comme votre photo avant.
Une mise en garde pratique. Une matrice de redirections qui semble ordonnée dans un tableur peut toujours échouer sur le serveur, testez donc les 20 premières avec un crawler tel que Screaming Frog et confirmez que chacune renvoie un unique 301 vers une page en ligne.
Triez les anciennes URLs par domaines référents, pas par le trafic. Mappez les 20 premières à la main, une étape chacune, vers l’équivalent le plus proche. Seulement ensuite laissez un motif gérer la longue traîne, et ne pointez jamais la longue traîne vers la page d’accueil par défaut.

Vérifier la nouvelle matrice avant sa mise en ligne
Une matrice de redirections n’est qu’un tableur jusqu’à ce qu’un crawler l’ait visitée. Les vérifications ci-dessous sont peu coûteuses à exécuter, et elles capturent les erreurs qu’un examen visuel ne voit jamais.
Lisez chaque code de statut, pas seulement la page
Demandez chaque ancienne URL et lisez le statut qu’elle renvoie. Un unique 301 vers une page en ligne est ce que vous voulez. Un 302 là où un 301 est attendu, ou une chaîne de trois étapes, laisse le résultat au hasard.
Screaming Frog et les crawlers similaires peuvent exécuter toute la liste et exporter les codes dans un tableau. Triez par statut et traitez d’abord tout ce qui n’est pas un 301 ou un 200.
Recherchez les chaînes de redirection
Une chaîne se forme lorsqu’une redirection pointe vers une page qui redirige à nouveau, souvent après un changement de slash de fin ou de préfixe de langue. Chaque étape supplémentaire est une chance de plus que le signal soit perdu et que la visite ralentisse.
Supprimez les chaînes en pointant la première redirection directement vers l’adresse finale. C’est une petite modification par URL et cela supprime toute une classe de surprises.
Comparez le sitemap avec la matrice
Exportez le sitemap et la liste des redirections, puis vérifiez qu’aucune entrée du sitemap n’est aussi une source de redirection. Chaque entrée du sitemap doit être une destination en ligne, et chaque ancienne adresse doit être absente du sitemap.
Faites de même avec les liens internes de votre modèle principal. Un lien qui pointe encore vers une ancienne adresse ajoute une étape pour chaque visiteur, et il indique aux crawlers que l’ancienne adresse compte encore.
Questions sur les 404, les plugins et les sitemaps
Une page 404 dédiée est-elle indispensable, ou la redirection vers la page d’accueil est-elle acceptable ?
Une page 404 dédiée est la réponse honnête à une adresse manquante. Elle indique à un visiteur et à un crawler que rien n’existe là. Rediriger chaque erreur vers la page d’accueil est le motif dont le dossier de l’affaire met en garde, car les liens qui pointaient vers les pages manquantes perdent leur cible.
Ai-je besoin d’un plugin de migration, ou puis-je écrire les redirections moi-même ?
Un plugin peut générer une longue liste rapidement, ce qui aide pour la longue traîne. Lisez ce qu’il écrit, cependant, car un plugin ne sait pas quelles anciennes URLs ont gagné des liens. Vérifiez les vingt premières à la main quel que soit l’outil que vous utilisez.
Si une page est manquante du sitemap, quelqu’un la trouvera-t-il ?
Parfois, par les liens internes et externes. Une page vers laquelle d’autres sites font des liens est trouvée par ces liens, tandis qu’un sitemap aide un crawler à découvrir des pages qu’il pourrait ne pas atteindre rapidement. Gardez le sitemap complet pour chaque page qui devrait être trouvée.
Chaque page a-t-elle besoin d’une balise canonical ?
Chaque page indexable doit indiquer une adresse préférée. La balise pointe vers la page elle-même lorsque cette page est la version préférée, et vers son remplacement lorsqu’une redirection l’a déplacée. Sans canonical, le choix est laissé au moteur de recherche.