Une migration, c’est rarement une partie de plaisir. On surveille les URLs, on croise les doigts, on attend que Google repasse. Et pendant ce temps, le maillage interne continue de travailler, parfois contre nous. Les pages 404 focalisent l’attention, c’est compréhensible, mais les vrais dégâts se jouent ailleurs : une redirection qui rebondit trois fois, une boucle entre deux versions d’une même page, un lien raccourci qui traîne depuis des années. La chasse aux incohérences commence là, dans les circuits invisibles du site.
Les chaînes de redirection, ces poids morts du maillage
Quand on migre un site, on met en place des redirections 301 pour ne pas perdre l’autorité acquise. Une redirection bien faite en conserve environ 90 %, ce qui reste très correct. Le souci, c’est que les migrations s’empilent : on redirige vers une URL, qui pointe elle-même vers une autre, qui a changé de structure entre-temps. Au bout de trois hops, chaque saut ajoute entre 100 et 500 millisecondes de latence. Multiplié par des dizaines de liens internes, le budget de crawl s’évapore.
Google, de son côté, suit un maximum de dix redirections avant d’abandonner. Au-delà, la page n’est pas indexée, et le lien interne qui menait vers elle devient une impasse. Ce qui est pervers, c’est que ces chaînes ne se voient pas à l’œil nu : l’URL affichée dans le code source semble valide, mais elle traverse quatre ou cinq étapes avant d’atterrir. Vérifier la cohérence du maillage après une migration commence par cartographier ces chemins, pas seulement les destinations finales.
Un outil comme Screaming Frog fait ça très bien, mais un simple crawl ne suffit pas si on ne regarde pas les hops. Il faut remonter chaque lien interne, noter le nombre de sauts, et repérer ceux qui dépassent la barre des trois. C’est fastidieux, et c’est précisément pour ça que peu de monde le fait correctement.
Les configurations circulaires, plus fréquentes qu’on ne le croit
L’erreur ERR_TOO_MANY_REDIRECTS n’est pas une légende urbaine. Elle apparaît quand deux pages se renvoient la balle, ou quand le serveur, le CDN et le CMS se contredisent sur la destination d’une URL. Un réglage de cache qui force le HTTPS, un plugin qui impose une barre oblique finale, une règle dans le .htaccess qui réécrit tout : les sources de boucles sont nombreuses et rarement documentées.
Pendant une migration, ces configurations circulaires explosent. L’ancien domaine pointe vers le nouveau, le nouveau vers une version sans www, qui renvoie vers l’ancien par une règle héritée. Le maillage interne, lui, continue de distribuer des liens vers ces URL piégées. Résultat : le crawl s’arrête net sur certaines branches du site, et l’autorité transférée se dissout dans le vide. C’est un gaspillage silencieux, bien plus coûteux qu’une 404 qu’on finit toujours par corriger.
Le plus efficace reste de tester chaque type de page après la migration : une page de catégorie, un article, une fiche produit, la home. Pas en cliquant, mais en vérifiant les en-têtes HTTP et le nombre de réponses intermédiaires. Une boucle se repère en quelques secondes avec curl ou un plugin d’inspection réseau, pour peu qu’on ait le réflexe de le faire avant que Google ne passe.
Le cas méconnu des liens raccourcis dans le contenu
Les liens raccourcis ont envahi les anciens articles, les newsletters, les signatures de forum. Après une migration, ils constituent un angle mort du maillage interne : ils ne sont pas toujours crawlis comme des liens classiques et ils masquent leur destination réelle. Sur ce point, voir aussi notre article sur thérapeutes, comment attirer des liens vers votre site web ?.
Selon des recherches de Palo Alto Networks, les liens raccourcis servent de vecteur de phishing dans un cas sur dix sur les domaines récemment enregistrés. Le risque n’est donc pas seulement technique, il est aussi sécuritaire.
Imaginons un vieux billet de blog qui contient un raccourci vers une page du site. Après la migration, ce raccourci pointe toujours vers l’ancienne URL, qui redirige vers la nouvelle. Si la chaîne est propre, ça passe.
Mais si le raccourci a été détourné, ou si le service qui le gérait a fermé, le lien interne devient une porte ouverte vers un domaine inconnu. Votre maillage distribue alors de l’autorité vers l’extérieur sans que vous le sachiez.
bloodsnow.fr illustre bien la complexité de ces infrastructures discrètes : les services de raccourcissement, les proxys et les redirections en cascade y sont légion. Un audit post-migration devrait inclure une extraction systématique de tous les liens sortants, pas seulement ceux qui pointent vers le site lui-même.
Quelles vérifications mener pendant la fenêtre critique
La fenêtre critique post-migration dure quelques semaines, mais certaines vérifications méritent d’être répétées sur plusieurs mois. D’abord, il est conseillé de garder les redirections actives pendant au moins un an. Les moteurs de recherche ne reviennent pas sur toutes les pages au même rythme, et les signets des utilisateurs, les partages sur les réseaux sociaux ou les backlinks externes continuent d’arriver sur les anciennes URL.
Les angles morts du maillage interne à surveiller
- Une redirection qui passe par plus de trois étapes avant d’aboutir : le jus se dilue et le crawl ralentit, surtout sur les sites volumineux.
- Deux pages qui se renvoient l’une vers l’autre en boucle, souvent à cause d’une règle de CDN mal configurée.
- Un lien raccourci dans un ancien article pointerait-il vers un domaine qui n’existe plus ?
- Les URL en HTTP pur, les versions sans www, les variantes avec ou sans barre oblique : chaque doublon interne crée une redirection inutile.
- Les liens vers des ancres ou des paramètres d’URL qui n’ont pas été repris dans la nouvelle arborescence.
Ce qui complique l’affaire, c’est que ces problèmes n’apparaissent pas dans les rapports classiques de pages 404. Une redirection qui fonctionne mais qui ajoute quatre hops est invisible dans la Search Console. Elle n’apparaît pas non plus dans un test de page classique, parce que le rendu final est correct. Seule une vérification dédiée au maillage et aux en-têtes HTTP permet de la repérer.
Un transfert d’autorité qui se joue dans les détails
La migration d’un site est une opération de confiance : on transfère des années de signaux vers de nouvelles URL, et chaque maillon compte. Une chaîne de redirection excessive ou une boucle mal résolue ne détruit pas le site, mais elle rogne l’autorité transmise. Un lien interne qui traverse cinq hops finit par arriver, certes, mais avec moins de force qu’un lien direct.
Sur des centaines de pages, l’addition fait mal. Poser un regard chirurgical sur le maillage interne, en plus de la chasse aux 404, c’est protéger ce que la migration était censée conserver. Et si votre site comptait déjà quelques boucles avant même de migrer, combien en avez-vous hérité sans le savoir ?