Ce qui se transfère, et ce qui se perd
Une redirection permanente transmet l’essentiel du signal d’une ancienne adresse vers la nouvelle. Elle ne transmet pas tout, et surtout elle ne transmet rien si elle est absente ou fausse.
3 pertes reviennent systématiquement.
Les pages oubliées du plan. On cartographie ce que le nouveau site contient, on oublie ce que l’ancien contenait. Les pages sans lien entrant interne, les anciennes pages de campagne, les vieux articles : elles reçoivent souvent des liens externes, et ce sont eux qui se perdent.
Les chaînes de redirections. L’ancienne adresse renvoie vers une deuxième, qui renvoie vers une troisième. Chaque saut dilue le signal et ralentit l’exploration. Une chaîne se corrige en pointant chaque origine directement vers la destination finale.
Les redirections vers l’accueil. C’est le raccourci le plus fréquent et le plus coûteux. Rediriger 400 pages vers la page d’accueil revient à dire à Google que ces 400 pages n’ont pas d’équivalent. Il les traite alors comme des erreurs, et le signal disparaît.
La cartographie des URL, point de départ
Le plan croise toutes les sources au lieu de se limiter à 1 seule.
L’exploration de l’ancien site donne les pages liées en interne. Le sitemap donne ce que le site déclarait. Search Console donne les pages qui reçoivent réellement des impressions, y compris celles que l’exploration ne trouve pas. Les journaux du serveur, quand ils sont disponibles, donnent ce que Google visite vraiment.
Ces 4 listes ne se recouvrent jamais complètement. C’est précisément l’écart entre elles qui contient les pages qu’on allait oublier.
Chaque ancienne adresse reçoit ensuite une destination, et 1 seule. Quand il n’existe pas d’équivalent, la bonne réponse est parfois une page de niveau supérieur, parfois un code 410 assumé. Une page supprimée volontairement ne se camoufle pas en redirection.
Le contrôle avant bascule
Le plan se teste sur l’environnement de recette, pas après la mise en ligne. 4 vérifications.
Chaque origine répond bien en 301, sans suivre la redirection automatiquement. C’est un piège classique : un outil qui suit les redirections par défaut affiche un code 200 et laisse croire que tout fonctionne, alors que l’ancienne adresse répond encore elle-même en 200. Le contrôle doit refuser de suivre.
Aucune destination n’est elle-même une origine. C’est le test qui élimine les chaînes.
Aucune destination ne répond en 404. Une redirection vers une page inexistante est pire qu’aucune redirection.
La recette est fermée à l’indexation. Un environnement de test accessible et indexable crée un duplicata complet du site. Le fichier robots.txt ne suffit pas : une page déjà connue peut rester indexée. Une protection par mot de passe règle le sujet.
Canonicals, sitemap et balisage
3 éléments décident de ce que Google retient après la bascule.
Les balises canoniques doivent pointer vers les nouvelles adresses, en absolu, et jamais vers l’ancien domaine. Une canonique restée sur l’ancien site annule la migration pour la page concernée.
Le sitemap ne doit contenir que les nouvelles adresses, et aucune qui soit elle-même redirigée. Déclarer une URL redirigée dans un sitemap envoie 2 signaux contradictoires.
Les données structurées et les balises de langue se vérifient page par page sur un échantillon, parce qu’elles se cassent silencieusement lors d’un changement de gabarit.
Après la mise en ligne
Une baisse de trafic dans les jours qui suivent est normale, le temps que Google réexplore. Ce qui n’est pas normal, c’est qu’elle dure ou qu’elle s’aggrave.
Les 3 indicateurs à suivre :
Le rapport d’indexation, où les anciennes adresses doivent progressivement passer en « page avec redirection » et les nouvelles en « indexée ». Une accumulation d’erreurs 404 signale des trous dans le plan.
Les impressions par page dans Search Console, comparées aux mêmes pages avant bascule. Une page qui s’effondre seule pointe une redirection fausse, pas un problème global.
Les journaux du serveur, qui montrent ce que Google explore réellement. C’est le seul endroit où l’on voit s’il perd du temps sur d’anciennes adresses.
Le délai de stabilisation dépend de la taille du site et de la fréquence à laquelle Google le visite. Sur un site de quelques centaines de pages, quelques semaines. Sur un site de plusieurs dizaines de milliers, plusieurs mois.
Migration ou refonte
Les 2 mots se confondent dans l’usage, et les projets se mélangent souvent, mais ce ne sont pas les mêmes chantiers.
Une migration change les adresses en gardant le contenu. Le risque est technique et il se traite par le plan de redirections.
Une refonte change le contenu, la structure et parfois le positionnement. Le risque porte alors aussi sur ce que les pages disent, et pas seulement sur l’endroit où elles vivent. Ce chantier est traité sur la page refonte SEO.
Un projet réunit fréquemment les 2. Dans ce cas, la migration se prépare en premier, parce qu’un plan de redirections se construit sur une arborescence arrêtée.
Travailler ensemble
J’interviens à 3 moments : le cadrage, avant que l’arborescence ne soit figée, la recette, où le plan se teste, et le suivi après bascule.
Le moment le plus utile est le premier. Une migration corrigée après la mise en ligne coûte plusieurs fois ce qu’aurait coûté sa préparation, et une partie des pertes ne se rattrape pas.
Je facture 450 € HT par jour. Le volume dépend du nombre d’URL à cartographier et du nombre d’environnements à contrôler. Un cadrage se traite en quelques jours sur un site de taille moyenne.
Je ne garantis pas l’absence de perte. Personne ne le peut, et une garantie de ce type sur une migration devrait vous alerter.
