Migrations web

On entend partout qu'une migration provoque « forcément » une perte de trafic. C'est faux. Modestos Siotos le démontre chez Moz : migrer sans perte est possible (ouvre un nouvel onglet), voire avec croissance — à condition que chaque étape soit bien planifiée et exécutée. Reste une réalité : une migration correcte nuit à court terme, aide à long terme (ouvre un nouvel onglet), le temps que les moteurs comprennent les changements.

Soyez donc réaliste sur les délais : une étude relayée par Search Engine Journal a relevé qu'il faut environ 17 mois pour récupérer (ouvre un nouvel onglet) le trafic. La cause des pertes durables, selon Semrush, n'est presque jamais la migration elle-même mais des problèmes évitables et non détectés (ouvre un nouvel onglet) : redirections manquantes, blocages de crawl ignorés.

Pour la plupart des migrations, l'objectif premier doit être la rétention du trafic actuel (ouvre un nouvel onglet) et des revenus ; anticiper de la croissance reste secondaire. Fixer des cibles mesurables dès le départ permet de juger l'impact post-lancement et d'éviter les attentes irréalistes.

Dès que les URL de l'ancien et du nouveau site diffèrent — changement de domaine, de sous-domaine, HTTP vers HTTPS, restructuration (ouvre un nouvel onglet) — il faut des redirections 301 permanentes pour faire indexer les nouvelles URL et transférer les signaux. Les 302 ralentissent l'indexation et le transfert ; meta refresh et JavaScript sont à éviter (ouvre un nouvel onglet). Une 301 côté serveur signale aux moteurs que la ressource a bougé de façon permanente et que l'autorité SEO doit être transférée (ouvre un nouvel onglet) vers la nouvelle URL.

Le mapping se fait redirection par redirection : chaque ancienne URL a une destination finale (ouvre un nouvel onglet) précise sur le nouveau domaine. Une page disparue est redirigée vers l'option la plus proche. C'est ce qui transfère tous les signaux et l'historique accumulés par chaque page. Pointez chaque 301 directement vers la version canonique des pages (ouvre un nouvel onglet) cibles (www/non-www, slash final) ; conserver le même schéma d'URL évite les changements superflus et les sauts vers une version non canonique. Voir aussi la gestion du contenu dupliqué.

L'erreur classique : rediriger toutes les pages orphelines vers la page d'accueil. Google traite ces redirections en masse comme des soft 404 (ouvre un nouvel onglet) qui ne transmettent aucune valeur SEO. À défaut d'équivalent exact, redirigez vers la page catégorie parente. Et pour un contenu sans aucun équivalent, mieux vaut servir un code 410 (ouvre un nouvel onglet) (retrait permanent) plutôt qu'une redirection trompeuse vers l'accueil du blog.

Imposez un content-freeze sur l'ancien site bien avant la date : ce point de coupure garantit qu'aucune page nouvelle n'est oubliée (ouvre un nouvel onglet) dans le mapping. Choisissez aussi un creux de trafic : ne lancez jamais près d'un pic saisonnier (ouvre un nouvel onglet), car en cas de problème vous n'auriez pas le temps de corriger. Un commerçant évitera septembre/octobre pour ne pas risquer la période pré-Noël.

Pour un grand site, déplacez le contenu section par section, par tranches (ouvre un nouvel onglet), en commençant par les segments les moins importants : cela réduit le risque et facilite le diagnostic après chaque étape. L'occasion aussi de revoir l'architecture du site.

L'environnement de test ne doit jamais apparaître dans les SERP. Protégez-le par mot de passe et tag noindex (ouvre un nouvel onglet) sur chaque page — blocages temporaires à retirer avant la mise en ligne. Attention au piège : bloquer le staging via robots.txt est déconseillé. Si un Disallow: / passe en production (ouvre un nouvel onglet) (et ça arrive souvent), il empêche le crawl, démote les mots-clés et finit par désindexer les pages. Préparez plutôt le robots.txt définitif sur staging.

Ne lancez jamais sans avoir testé les redirections sur staging : crawlez la liste complète pour détecter boucles, chaînes, réponses 4xx/5xx (ouvre un nouvel onglet), incohérences protocole/hôte. Le fait qu'une URL redirige ne garantit pas qu'elle redirige vers la bonne page. Juste avant la bascule, benchmarkez l'ancien site (ouvre un nouvel onglet) : classements, vitesse, crawl final et données Search Console (limitées à 90 jours), pour comparer ensuite et diagnostiquer vite.

Pour un changement de domaine ou de sous-domaine, l'outil Change of Address de Search Console prévient Google du déménagement (ouvre un nouvel onglet) pour qu'il intègre le changement plus vite. Il exige d'être propriétaire des deux sites et d'avoir les 301 en place. À ne pas utiliser pour un passage HTTP vers HTTPS, www, quelques URL ou un simple changement d'hébergement. Soumettez ensuite les sitemaps de l'ancien et du nouveau site (ouvre un nouvel onglet) : cela aide Google à découvrir les redirections et à suivre l'indexation comme la désindexation.

Après une migration de domaine, tous les liens internes doivent pointer vers le nouveau domaine (ouvre un nouvel onglet) directement, sans transiter par des redirections depuis l'ancien. C'est une étape souvent oubliée qui dilue l'équité et alourdit inutilement le crawl.

En plus du crawl complet du nouveau site, faites un list crawl des anciennes pages les plus performantes pour repérer celles qui n'ont pas été 301-redirigées (ouvre un nouvel onglet) vers leur nouvelle URL, ou qui renvoient une erreur, une cible non pertinente, une boucle ou une chaîne. La fonction « redirect & canonical chains » révèle une destination canonicalisée ailleurs (ouvre un nouvel onglet) — cause fréquente de non-récupération des positions.

Aucun rank tracker n'était en place avant la migration ? On reconstitue les anciens classements depuis les données historiques d'outils tiers (ouvre un nouvel onglet) : exporter les pages classées et leurs requêtes/positions à une date antérieure, puis comparer aux URL qui se classent maintenant pour isoler les termes à forte chute. Sans accès à l'ancienne version, la Wayback Machine compare la config (ouvre un nouvel onglet) : contenu, HTML, anciennes métadonnées, canonicalisation, meta robots et liens internes d'avant la migration.