La réponse en bref
Le SEO d’une refonte dépend de la préservation des destinations utiles et d’une décision explicite pour chaque changement d’URL. Inventoriez le site actuel, associez chaque URL utile à la destination pertinente la plus proche, mettez en place des redirections permanentes directes, harmonisez liens internes et signaux canoniques, puis validez et surveillez le site en production.
- Avant le lancement, prenez une décision au niveau de chaque page ayant des utilisateurs, des liens, un classement ou une valeur commerciale.
- Utilisez des redirections permanentes directes côté serveur pour les déplacements définitifs et évitez les redirections non pertinentes vers l’accueil.
- Mettez à jour liens internes, URL canoniques, hreflang et sitemap afin qu’ils pointent directement vers les URL finales.
- Attendez-vous à des variations temporaires dans la recherche et surveillez les groupes de pages par rapport au plan de migration, sans promettre de stabilité.
Sur cette page
La réponse directe
Un SEO réussi lors d’une refonte organise le transfert des destinations, des contenus et des signaux de recherche. Le livrable central n’est pas une liste de contrôle générique. C’est un plan vérifié qui indique ce qu’il advient de chaque ancienne URL, pourquoi la décision est appropriée, comment elle sera mise en œuvre et comment elle sera testée en production.
Conservez une URL lorsqu’elle représente toujours la même page utile. Lorsqu’une page déménage, envoyez-la directement vers le remplacement pertinent le plus proche au moyen d’une redirection permanente côté serveur. Si le contenu a réellement disparu sans remplacement approprié, renvoyez un véritable code 404 ou 410 plutôt que de pousser le visiteur vers un accueil sans rapport.
Google conseille de planifier la correspondance des URL, d’utiliser des redirections permanentes côté serveur, d’actualiser les références internes et externes, de soumettre le nouveau sitemap et d’effectuer un suivi dans Search Console. Google avertit aussi que les classements peuvent fluctuer pendant la nouvelle exploration et indexation. Une migration limite les pertes évitables, mais personne ne peut garantir des classements ou un trafic inchangés.
- Inventoriez les URL actuelles et recueillez les preuves avant de modifier le site.
- Attribuez à chaque ancienne URL un résultat vérifié.
- Dirigez les redirections directement vers les destinations finales.
- Harmonisez liens internes et annotations de recherche avec les nouvelles URL.
- Validez en production et surveillez par groupe de pages.
Établissez un inventaire des URL fondé sur des preuves
Commencez avant que designers ou développeurs ne renomment les rubriques. Croisez une exploration du site public avec les sitemaps XML, les pages d’entrée des outils analytiques, les rapports de performance et d’indexation de Search Console, les backlinks importants, les destinations de campagnes, les fichiers téléchargeables et les liens hors ligne connus. Aucune source n’est complète à elle seule.
Consignez les preuves commerciales autant que les données de recherche. Une page d’assistance technique peu visitée peut éviter des appels, soutenir une vente ou recevoir des liens depuis un manuel produit. Un article très fréquenté peut attirer un public inadéquat et apporter peu à l’entreprise. La décision doit refléter la fonction, pas seulement le trafic.
Attribuez à chaque URL un responsable éditorial et un statut. Les issues habituelles sont: conserver, améliorer sur place, déplacer, fusionner, retirer avec un remplacement pertinent ou supprimer sans remplacement. Figez l’inventaire validé avant le lancement afin que des décisions tardives ne contournent pas silencieusement le plan de redirection.
- URL actuelle, code d’état, URL canonique et indexabilité
- Type de page, sujet, langue et responsable
- Activité d’entrée organique et requêtes représentatives
- Liens entrants, campagnes et références hors ligne
- Rôle commercial, parcours de conversion et résultat proposé
| Preuve | Ce qu’elle révèle | Décision qu’elle éclaire | Limite |
|---|---|---|---|
| Exploration du site | URL accessibles, codes d’état, liens et annotations | Inventaire technique et changements de liens internes | Peut manquer des URL orphelines ou bloquées |
| Search Console | Requêtes, pages, indexation et clics depuis la recherche | Demande de recherche et pages à préserver | Ne décrit pas tous les visiteurs ni toute la valeur commerciale |
| Données analytiques | Parcours d’entrée et résultats mesurés | Priorité commerciale et comparaison après lancement | Dépend du bon fonctionnement du consentement et du suivi |
| Backlinks et dossiers commerciaux | Références externes, campagnes et usage opérationnel | Conservation des redirections et priorité de prise de contact | Les listes sont rarement complètes |
Décidez de la destination de chaque ancienne URL
La destination doit répondre à la raison pour laquelle une personne utilisait l’ancienne page. Faites correspondre sujet, intention, langue et fonction commerciale. Une page de service abandonné peut mener au service successeur s’il répond au même besoin. Un événement expiré sans information durable devrait normalement renvoyer une erreur plutôt que rediriger vers l’index des événements par simple commodité.
Une fusion exige un jugement éditorial. Plusieurs pages minces peuvent pointer vers une nouvelle page complète si celle-ci reprend réellement leurs informations utiles. Notez dans le plan la section ou le contenu requis, puis vérifiez sa présence avant d’activer la redirection. Une redirection techniquement valable peut autrement décevoir le visiteur.
Pour une entreprise B2B lausannoise fictive, imaginons que /en/audit-old/ et /en/risk-review/ deviennent un seul service d’évaluation des risques. Les deux URL peuvent pointer vers la page fusionnée après intégration de leurs questions distinctes. Une offre d’emploi supprimée ne doit pas y mener. Elle doit renvoyer 404 ou 410, sauf s’il existe une destination carrière appropriée.
- Conservez l’URL si la fonction et la langue de la page restent stables.
- Faites pointer une page déplacée vers son équivalent le plus proche, pas simplement vers sa rubrique parente.
- Ne fusionnez que si la destination reprend les contenus utiles.
- Renvoyez 404 ou 410 lorsqu’aucune page pertinente ne remplace l’ancienne.
- Maintenez les variantes linguistiques dans le bon parcours linguistique.
| Situation de l’ancienne page | Résultat recommandé | Preuve requise | Validation |
|---|---|---|---|
| Même fonction et même contenu | Conserver l’URL existante | L’URL reste adaptée à la nouvelle structure | Réponse 200 et URL canonique prévue conservée |
| Même fonction, nouvelle URL | Redirection permanente vers la page équivalente | La destination répond au même besoin | Un seul saut vers une réponse 200 |
| Plusieurs pages deviennent une | Rediriger chacune vers la page fusionnée | Les informations pertinentes sont présentes | Contenu et ancres vérifiés manuellement |
| Aucun remplacement | Renvoyer 404 ou 410 avec une page d’erreur utile | Le responsable confirme le retrait | Bon code HTTP et navigation utile |
| Changement temporaire de campagne | N’utiliser une réponse temporaire que si l’original reviendra | Condition temporaire documentée | L’original demeure l’URL de recherche visée |
Spécifiez les redirections et les signaux de recherche
Google recommande des redirections permanentes côté serveur, comme 301 ou 308, lorsque le déplacement ne sera pas annulé. Redirigez directement vers l’URL finale. Google peut suivre les chaînes, mais elles ajoutent de la latence et des points de défaillance. Lorsque l’équipe contrôle les deux URL, la condition pratique de validation est un seul saut.
Ne redirigez pas de nombreuses URL sans rapport vers l’accueil. Selon Google, ces redirections groupées non pertinentes peuvent troubler les utilisateurs et être traitées comme des erreurs 404 logicielles. Une page d’erreur personnalisée utile peut proposer navigation et ressources populaires, mais une URL supprimée doit toujours renvoyer le bon code 404.
Les redirections ne sont qu’un signal. Actualisez les liens internes pour que visiteurs et robots ne passent pas par elles. Modifiez les URL canoniques, références hreflang, URL des données structurées, navigation, liens de campagne et profils. Inscrivez les nouvelles URL canoniques dans le sitemap. Google qualifie redirections et rel=canonical de signaux forts de canonicalisation, et la présence dans le sitemap de signal plus faible: la cohérence compte.
- Utilisez 301 ou 308 pour un déplacement réellement permanent.
- Pointez directement vers une destination finale active.
- Supprimez chaînes, boucles et règles groupées non pertinentes.
- Actualisez liens internes et annotations au lieu de dépendre indéfiniment des redirections.
- Soumettez le plan de redirection à une gestion des changements.
| Signal | État attendu en production | Exemple d’échec |
|---|---|---|
| Redirection | L’ancienne URL atteint la destination finale la plus proche en un saut | L’ancienne URL traverse deux anciennes structures |
| URL canonique | La nouvelle page désigne son URL finale indexable | L’URL canonique désigne encore la préproduction ou l’ancien domaine |
| Liens internes | Navigation et contenu utilisent les URL finales | Chaque clic déclenche une redirection |
| Sitemap | Contient les nouvelles URL canoniques et indexables | Contient des URL redirigées ou bloquées |
| Hreflang | Les variantes linguistiques sont réciproques et finales | Les variantes pointent vers d’anciennes URL ou des redirections |
Préparez le nouveau site avant le lancement
Testez le nouveau site tant qu’il reste privé, tout en préparant les contrôles d’indexation de production avant la mise en ligne. Google avertit expressément les équipes qui bloquent toute exploration ou ajoutent noindex pendant le développement de préparer le bon fichier robots de production et la liste des pages dont noindex doit être retiré.
Explorez la préproduction avec des URL proches de la production ou une correspondance fiable. Vérifiez que chaque destination existe, que les contenus clés ont migré, que titres et intertitres sont intentionnels, que les URL canoniques ne pointent pas vers la préproduction et que les variantes multilingues forment des ensembles réciproques complets. Validez les données structurées par rapport au contenu visible et examinez les gabarits sur mobile.
Vérifiez avant le lancement l’accès Search Console aux propriétés anciennes et nouvelles, puis préservez la méthode de validation. Préparez sitemap, règles de redirection, plan DNS ou de déploiement, surveillance et critères de retour arrière. Si la refonte modifie à la fois domaine, structure d’URL, CMS et contenu, documentez le risque combiné et attribuez clairement les responsabilités.
- Retirez les noindex et blocages d’exploration accidentels en production.
- Confirmez la propriété Search Console des anciens et nouveaux sites lorsque nécessaire.
- Validez chaque destination du plan d’URL approuvé.
- Testez URL canoniques, hreflang et données structurées sur des gabarits représentatifs.
- Préparez à l’avance l’exploration de production et un échantillon de redirections critiques.
Validez la migration en production
La production est un nouvel environnement de test. Dès la mise en ligne, explorez le site final et échantillonnez les redirections de chaque type de règle et groupe de pages. Vérifiez codes d’état, contenu des destinations, saut unique, hôte canonique, indexabilité, liens internes, accessibilité du sitemap et transmission réelle des formulaires.
Priorisez selon le risque. Contrôlez d’abord l’accueil, les services à forte valeur, les principales pages d’entrée organiques, les pages dotées de backlinks importants, les variantes linguistiques et les campagnes. Utilisez l’inspection d’URL sur des exemples pour voir la réponse et le rendu reçus par Google. Soumettez le sitemap dans Search Console et examinez les erreurs, en gardant à l’esprit que cette soumission est une indication, pas une garantie d’indexation.
Google recommande de conserver les redirections aussi longtemps que possible, généralement au moins un an, afin de laisser aux signaux et anciens liens le temps d’être transférés. Envisagez de les garder indéfiniment lorsque d’anciens favoris, documents ou liens externes restent utilisés. Conservez le plan pour éviter qu’un futur déploiement ne supprime des règles actives.
- Effectuez une exploration complète de la production et comparez-la à l’inventaire approuvé.
- Testez des anciennes URL représentatives issues des journaux ou d’un jeu de migration fixe.
- Inspectez le rendu et les URL canoniques choisies dans Search Console.
- Soumettez le nouveau sitemap et examinez son état de traitement.
- Archivez règles, décisions et preuves de test pour la maintenance.
Surveillez les décisions, pas seulement le trafic
La visibilité peut fluctuer pendant une migration importante, le temps que Google explore et indexe à nouveau les URL. Google indique qu’un site moyen peut attendre quelques semaines ou davantage avant de voir apparaître les nouvelles URL, et qu’un grand site peut prendre plus longtemps. Considérez ce délai comme un contexte, pas comme une échéance de rétablissement.
Surveillez si la migration se comporte comme prévu: anciennes URL encore demandées, erreurs de redirection, nouvelles 404, traitement du sitemap, groupes de pages indexés, sélection canonique, requêtes représentatives et résultats commerciaux. Comparez des groupes équivalents plutôt qu’un total global, car saisonnalité, campagnes et demande peuvent évoluer indépendamment de la refonte.
Analysez les exceptions à partir du plan. Si une ancienne page de service perd en visibilité, vérifiez d’abord redirection, pertinence de la destination, contenu, URL canonique, liens internes et réponse rendue. Un tableau de bord ne remplace pas ce diagnostic au niveau de l’URL. Consignez la correction et retestez-la.
- Chaque jour juste après le lancement: erreurs, redirections critiques, formulaires et santé du serveur.
- Régulièrement pendant le retraitement: indexation, sitemap, exceptions canoniques et groupes de pages clés.
- Au point de contrôle convenu: demande de recherche, résultats des pages d’entrée et anciennes URL non résolues.
- Après les versions ultérieures: confirmez que redirections et annotations restent intactes.
Transformez la migration en cahier des charges responsabilisant
Votre cahier des charges doit attribuer l’inventaire, les décisions éditoriales, l’implémentation des redirections, les annotations techniques, Search Console, la validation en production et le suivi. Demandez qui approuve le plan d’URL et qui peut le modifier. Les tâches réparties vaguement entre agence, marketing et informatique se perdent souvent aux interfaces.
Intégrez les preuves à la définition du travail terminé. Le prestataire doit livrer le plan d’URL final, la configuration ou l’export des redirections, les résultats d’exploration, la liste des exceptions et le transfert du suivi. La validation doit reposer sur les réponses observées en production, pas sur l’affirmation qu’une extension SEO est installée.
Un nouveau concept de page d’accueil peut clarifier la hiérarchie révisée avant de figer URL et gabarits. Il doit rester distinct de la promesse de migration: le concept couvre l’orientation de l’accueil et les priorités, tandis que réalisation, hébergement et prestations récurrentes nécessitent leur propre périmètre et devis.
- Responsable nommé pour chaque livrable de migration
- Plan d’URL approuvé avec justification et historique des modifications
- Critères techniques de validation et preuves de production
- Conditions d’escalade et de retour arrière en cas de défaillance critique
- Période de suivi, format de transfert et responsabilité de conservation des redirections
VOS QUESTIONS, NOS RÉPONSES
Questions fréquentes
Qu’est-ce que le SEO lors d’une refonte de site?
C’est la planification et la validation nécessaires pour préserver les destinations utiles dans les moteurs de recherche lorsque le site change. Cela couvre inventaire des URL, décisions éditoriales, redirections, liens internes, signaux canoniques, sitemaps, contrôles d’indexation et suivi après lancement.
Chaque ancienne URL doit-elle rediriger vers le nouvel accueil?
Non. Chaque URL déplacée doit pointer vers le remplacement pertinent le plus proche. Google avertit que rediriger de nombreuses URL sans rapport vers une destination non pertinente peut troubler les utilisateurs et être traité comme une erreur 404 logicielle.
Quelle redirection utiliser pour une migration permanente?
Google recommande une redirection permanente côté serveur, par exemple 301 ou 308, lorsque le déplacement ne sera pas annulé. Dirigez chaque ancienne URL vers la destination finale et évitez les chaînes lorsque possible.
Combien de temps conserver les redirections de migration?
Google recommande de les maintenir aussi longtemps que possible, généralement au moins un an. Les conserver davantage peut continuer d’aider les personnes utilisant d’anciens favoris, documents et liens externes.
Une migration correcte empêche-t-elle toute variation de classement?
Non. Selon Google, des fluctuations peuvent survenir pendant la nouvelle exploration et indexation du site. Une bonne planification réduit les erreurs évitables, sans garantir des classements, un trafic ou des prospects inchangés.
Que doit livrer une agence après la migration?
Demandez le plan d’URL approuvé, le relevé des redirections implémentées, les preuves d’exploration en production, la liste des exceptions non résolues, les contrôles Search Console et sitemap, le plan de suivi et un responsable clairement désigné pour le transfert.
POUR ALLER PLUS LOIN
