C’est pas une histoire inventée. C’est une mise en prod qui s’est mal passée. Le site est tombé, les anciennes URLs ont disparu dans la nature, et personne n’avait prévu de plan de redirection. Zéro. Nada. Le genre de situation où tu regardes ton écran et tu te demandes si reconvertir en barista c’est vraiment si compliqué.
Le problème concrètement : le nouveau site avait une structure d’URLs complètement différente. Toutes les anciennes adresses renvoyaient en 404. Pages produits, articles de blog, fiches catégories… partis. Et côté SEO, c’est pas juste douloureux, c’est catastrophique.
D’abord, on respire
Panique inutile. Ce qui est cassé peut se réparer, à condition de ne pas faire de bêtises supplémentaires dans le stress.
La première chose, c’est ouvrir la Google Search Console. Pas pour pleurer devant les erreurs, mais pour avoir une liste propre de toutes les URLs indexées côté Google. Export CSV, on garde ça au chaud.
Ensuite, la Wayback Machine. Si l’ancien site a été crawlé (et il l’a probablement été), vous pouvez y retrouver des URLs que vous n’auriez même pas pensé à chercher. C’est votre filet de sécurité historique.
Le SQL qui sauve la mise
La vraie opération de sauvetage, elle s’est passée en base de données.
L’ancien site tournait sous WordPress. Toutes les URLs des articles, des pages, des produits… elles sont dans la table wp_posts, dans le champ guid et dans post_name. Un SELECT bien ciblé et vous avez votre liste complète en 30 secondes.
SELECT ID, post_title, post_name, guid, post_type, post_status
FROM wp_posts
WHERE post_status = 'publish'
AND post_type IN ('post', 'page', 'product')
ORDER BY post_type, post_name;Résultat : un tableau propre avec tous les slugs publiés. Vous exportez en CSV, vous ouvrez dans un tableur, et vous commencez à construire votre table de correspondance ancien slug > nouveau slug.
Si vous aviez aussi des catégories ou des taxonomies à récupérer, c’est la table wp_terms et wp_term_taxonomy qu’il faut aller chercher.
Construire les redirections sans se noyer
Une fois la liste en main, il faut implémenter les 301. Deux options selon votre config.
Si vous êtes sur Apache, vous écrivez les règles directement dans le .htaccess. Une ligne par redirection, propre et rapide pour les petits volumes.
Si vous avez des centaines de redirections, passez par un plugin dédié comme Redirection ou Yoast (si vous l’avez déjà). L’import CSV est prévu pour ça, vous n’avez pas à tout taper à la main.
Dans tous les cas, la règle d’or : on ne laisse pas une URL populaire en 404 plus de 24h. Chaque heure qui passe, c’est du jus SEO qui part en fumée.
Ce qu’on aurait dû faire avant
Soyons honnêtes, tout ça s’évite. Pas entièrement, mais largement.
Avant toute migration ou mise en prod qui touche aux URLs, il faut crawler l’ancien site avec Screaming Frog ou Sitebulb. Vous obtenez la liste complète des URLs vivantes, vous la croisez avec la nouvelle arborescence, et vous préparez le fichier de redirections avant de basculer.
C’est deux heures de travail. Deux heures qui évitent une nuit blanche de récupération de crise.
Un autre réflexe simple : faire un dump SQL de la table wp_posts la veille de la migration. Juste au cas où. Ça prend trois minutes et ça peut sauver des heures.
La leçon
Les redirections, c’est pas une option post-migration. C’est une étape à part entière du projet, au même titre que les tests ou la sauvegarde.
Quand un site change de structure, Google ne fait pas le lien tout seul. C’est vous qui lui expliquez où sont passées les pages. Si personne ne le fait, il considère que ces pages n’existent plus. Et reconstruire une autorité SEO perdue, ça prend des mois.
La bonne nouvelle : avec les bons outils et un peu de SQL, même une catastrophe de mise en prod se rattrape. Ça a pris une nuit. Mais ça s’est rattrapé.