Une refonte de site internet peut améliorer l’expérience utilisateur, simplifier l’administration et mieux soutenir les objectifs commerciaux. Mal préparée, elle peut aussi supprimer des pages utiles, casser des parcours, perdre des données ou dégrader la visibilité organique.
Pour réduire ces risques, il faut auditer l’existant, définir précisément le périmètre, intégrer le SEO dès la conception, tester le nouveau site avant la bascule et suivre ses performances après le lancement. L’objectif n’est pas seulement de produire un site plus moderne, mais de protéger le capital numérique déjà constitué.
La première question à se poser est donc simple : le site doit-il réellement être entièrement refondu, ou certains problèmes peuvent-ils être corrigés par des améliorations ciblées ?
Faut-il vraiment refondre le site ?
Distinguer relooking, refonte et migration
Un relooking, parfois appelé redesign, concerne principalement l’apparence du site : couleurs, typographies, composants visuels ou mise en page. Une refonte va plus loin. Elle peut modifier l’arborescence, les parcours, les contenus, les fonctionnalités et le socle technique.
La migration désigne quant à elle un changement d’environnement : nouvelles URL, nouveau nom de domaine, nouveau CMS, nouvel hébergement ou nouvelle infrastructure. Une refonte peut inclure une migration, mais les deux opérations ne sont pas synonymes.
Cette distinction est importante, car les risques ne sont pas les mêmes. Modifier uniquement le design ne demande pas le même niveau de préparation qu’un changement simultané de CMS, d’URL et de structure éditoriale.
Identifier les problèmes à résoudre
Une refonte doit répondre à des difficultés précises. Elle peut être pertinente lorsque le site ne représente plus correctement l’offre, que les parcours sont devenus confus, que l’administration est trop contraignante ou que le socle technique limite les évolutions.
D’autres signaux peuvent justifier une transformation plus profonde :
- un CMS ou des composants qui ne sont plus correctement maintenus ;
- une dette technique importante ;
- un affichage mobile insuffisant ;
- des temps de chargement problématiques ;
- une arborescence difficile à comprendre ;
- des contenus impossibles à faire évoluer efficacement ;
- des fonctionnalités devenues inadaptées ;
- une baisse de visibilité qui nécessite un diagnostic plus large.
L’âge du site ne constitue pas, à lui seul, une raison suffisante. Un site ancien peut encore remplir correctement ses objectifs. À l’inverse, un site récent peut nécessiter une reprise importante si son architecture ou son développement ne répondent pas aux besoins.
Choisir entre optimisation ciblée et refonte complète
La réponse dépend de la nature et du nombre de problèmes identifiés. Une identité visuelle datée avec une architecture saine peut être corrigée par une refonte graphique ciblée. Des parcours ou contenus mal structurés appellent plutôt une refonte UX et éditoriale.
Un CMS bloquant ou une dette technique importante peuvent justifier une refonte technique. Une refonte complète devient pertinente lorsque l’offre, les parcours, l’architecture, les contenus et le socle doivent évoluer ensemble.
À l’inverse, quelques problèmes isolés peuvent être intégrés dans un plan d’amélioration continue. Un site bien positionné, mais difficile à administrer, ne doit pas être reconstruit sans inventaire préalable. Il peut être préférable de préserver ses URL et ses contenus performants tout en remplaçant son socle technique.
Cadrer les objectifs, le périmètre et les responsabilités
Définir les objectifs et les données de référence
Une demande comme « moderniser le site » est trop vague pour piloter une refonte. Le projet doit être rattaché à des objectifs business, utilisateurs, SEO et techniques.
Ces objectifs peuvent concerner les demandes de contact, les ventes, le chiffre d’affaires e-commerce, la qualité des parcours, l’autonomie éditoriale, la visibilité organique ou la stabilité technique.
Avant le lancement du projet, il faut sauvegarder les données qui serviront de référence :
- clics et impressions dans Google Search Console ;
- sessions et conversions dans Google Analytics 4 ;
- performances des principaux types de pages ;
- pages indexées ;
- erreurs techniques ;
- ventes, formulaires ou autres actions importantes ;
- utilisation des principales fonctionnalités.
Il n’existe pas d’objectif chiffré universel. Chaque cible doit partir de la situation actuelle, des moyens disponibles et des enjeux propres au site.
Définir ce qui est inclus et ce qui ne l’est pas
Le périmètre doit préciser les pages, langues, fonctionnalités, contenus, intégrations et données concernés. Il doit également indiquer qui prend en charge la formation, la maintenance et le suivi après la mise en ligne.
Pour limiter les dérives, classez les demandes en trois catégories :
- indispensables au lancement ;
- utiles mais reportables ;
- hors périmètre.
Cette hiérarchisation facilite les arbitrages lorsque de nouvelles idées apparaissent en cours de projet. Elle permet aussi de comparer plus justement les devis, qui n’incluent pas toujours les mêmes livrables.
Attribuer les rôles
Une refonte implique souvent une direction, un chef de projet, un consultant SEO, des développeurs, une équipe UX/UI, des rédacteurs, un responsable e-commerce et différents prestataires techniques.
Chaque sujet doit avoir un responsable et un validateur clairement identifiés. Il faut notamment attribuer la gestion des redirections, du tracking, des contenus, des données, des tests et de la décision finale de mise en ligne.
Un formulaire, par exemple, ne peut pas être considéré comme terminé parce qu’il s’affiche correctement. Il faut aussi vérifier la réception des messages, les erreurs de saisie, la protection antispam, le consentement et le suivi des conversions.
Auditer le capital existant avant de le modifier
Inventorier les URL, les contenus et les performances
L’audit doit recenser les URL accessibles, les pages indexées, les contenus présents dans les sitemaps et les ressources qui génèrent du trafic, des conversions ou des liens externes.
Il faut également inventorier les PDF, les images, les vidéos, les balises, les données structurées, les liens internes et les erreurs déjà présentes sur le site. Une page peu visitée peut rester stratégique si elle génère des leads, reçoit des backlinks ou répond à un besoin saisonnier.
Classer chaque contenu
Chaque page doit recevoir une décision explicite :
- conserver lorsque l’URL et le contenu restent utiles ;
- améliorer lorsque le sujet reste pertinent, mais mérite d’être enrichi ;
- fusionner lorsque plusieurs pages répondent à la même intention ;
- supprimer lorsque le contenu n’a plus d’utilité ;
- rediriger lorsqu’une URL supprimée dispose d’une destination réellement équivalente.
Aucune suppression ne doit être décidée uniquement à partir du nombre de sessions. Les conversions, la saisonnalité, les backlinks, le maillage interne et le rôle de la page dans le parcours doivent aussi être examinés.
Inventorier les fonctionnalités et les données
Pour un site classique, l’inventaire doit couvrir les formulaires, la recherche, les espaces membres, les emails, le CRM, les outils de mesure, les scripts de consentement, les API et les automatisations.
Pour un e-commerce, il faut également vérifier le catalogue, les variantes, les catégories, les filtres, les stocks, les comptes clients, les commandes, les promotions, le panier, le paiement, les taxes, les livraisons et les flux marchands.
Le cas de l’accompagnement de la refonte et du passage sous WordPress de Dweho illustre l’intérêt d’associer les enjeux de structure et de contenu au changement de socle technique, sans réduire le projet à une simple migration de CMS.
Concevoir l’arborescence et les contenus avec le SEO
Associer chaque page à un besoin utilisateur
Chaque future page doit répondre à une intention précise, s’adresser à une audience identifiée et conduire vers une action cohérente. Il ne s’agit pas de créer une page pour chaque variante proche d’un mot-clé, mais de construire une architecture compréhensible pour les utilisateurs et les moteurs de recherche.
Le référencement ne doit donc pas être ajouté une fois les maquettes et le développement terminés. Il faut au contraire intégrer le SEO dès la conception du site.
Définir les URL, la navigation et le maillage interne
Lorsque les URL existantes sont cohérentes et performantes, leur conservation limite les changements inutiles. Les nouvelles conventions doivent rester courtes, descriptives et stables.
La réflexion doit également couvrir les menus, les fils d’Ariane, la profondeur de navigation, les liens contextuels, la pagination, les filtres et les éventuelles versions linguistiques. Une architecture créée uniquement à partir du menu principal risque de laisser certaines pages importantes isolées.
Préparer la reprise des contenus
Chaque contenu doit être marqué comme repris, réécrit, enrichi, fusionné, archivé ou supprimé. Cette décision doit être prise suffisamment tôt pour que la production éditoriale reste compatible avec le planning technique.
Repousser la migration des contenus à la fin du projet crée souvent des retards et des incohérences entre les maquettes validées et les textes réellement disponibles.
Commencer le mapping des anciennes et nouvelles URL
Le mapping d’URL associe chaque ancienne adresse à son traitement futur. Il doit préciser l’ancienne URL, son importance, la décision prise, sa destination éventuelle, le responsable et le résultat du test.
Si trois pages proches sont fusionnées, chacune doit être redirigée vers la nouvelle page consolidée. Les rediriger vers la page d’accueil uniquement pour éviter une erreur 404 ne constitue pas une solution pertinente.
Transformer les exigences SEO en critères de développement
Choisir le CMS et le socle selon les besoins
Le choix entre WordPress, Shopify, PrestaShop ou un autre CMS doit partir des besoins réels : autonomie de publication, gestion des métadonnées, contrôle des URL, catalogue, langues, intégrations, rôles utilisateurs, sécurité et maintenabilité.
Aucune technologie n’est universellement adaptée. Un CMS simple à administrer peut devenir limitant pour un projet très spécifique, tandis qu’un développement complexe peut créer une dépendance inutile pour un site éditorial classique.
Protéger correctement la préproduction
La préproduction est l’environnement sur lequel le nouveau site est développé et testé avant sa mise en ligne. Elle doit être protégée contre les accès non autorisés et contre une indexation accidentelle.
Une authentification limite l’accès au site. Une directive noindex demande aux moteurs de ne pas indexer une page lorsqu’ils peuvent l’explorer. Le fichier robots.txt pilote principalement le crawl, mais ne constitue ni une protection de sécurité ni une garantie de non-indexation.
Pour bien distinguer ces mécanismes, il est utile de comprendre le rôle du fichier robots.txt. Le retrait des protections temporaires doit aussi faire partie de la checklist de lancement.
Définir les critères d’acceptation
Une consigne comme « optimiser le site pour le SEO » n’est pas vérifiable. Elle doit être traduite en critères précis : balises Title et H1 modifiables, codes HTTP corrects, balises canoniques cohérentes, sitemap propre, redirections testables et pages importantes présentes dans un HTML exploitable.
Chaque exigence doit préciser le résultat attendu, la méthode de test, l’environnement concerné, le responsable et la gravité d’un éventuel échec.
Recetter le nouveau site avant la bascule
Tester les parcours fonctionnels
La recette consiste à vérifier que le site répond aux besoins définis. Elle doit couvrir la navigation, la recherche, les filtres, les formulaires, les comptes utilisateurs, les emails, les téléchargements et les intégrations.
Sur un e-commerce, un paiement affiché comme validé ne suffit pas. Il faut contrôler la commande, le paiement chez le prestataire, la mise à jour du stock, les emails envoyés et la remontée des données dans les outils de mesure.
Réaliser la recette SEO
La recette SEO comprend un crawl complet de la préproduction, puis une comparaison avec l’inventaire initial. Les équipes doivent contrôler les codes HTTP, les balises, les canoniques, les directives d’indexation, les sitemaps, les données structurées, les liens cassés et les redirections.
Tester le tracking et les conversions
Les événements et conversions doivent être testés avant la mise en ligne. Il faut vérifier le gestionnaire de balises, le consentement, les données e-commerce, les doublons de pages vues et la continuité des accès à Google Analytics 4 et Google Search Console.
Formaliser la décision go/no-go
Les anomalies doivent être classées comme bloquantes, majeures, mineures ou temporairement acceptées. Le projet doit préciser qui peut autoriser la mise en production et qui peut la reporter.
Un problème de paiement, un blocage global de l’indexation ou une perte importante de données ne doit pas être traité comme une simple correction à planifier après le lancement.
Préparer le plan de retour arrière
Le plan de retour arrière, ou rollback, décrit la procédure à suivre si le nouveau site doit être retiré rapidement. Il comprend une sauvegarde vérifiée, une version précédente disponible, les configurations nécessaires et les interlocuteurs à mobiliser.
Organiser la mise en ligne et la migration SEO
Préparer la fenêtre de mise en production
La bascule doit être planifiée sur une période adaptée à l’activité du site. L’ordre des opérations, les accès, les responsables et les tests après déploiement doivent être connus avant le lancement.
Lorsque la refonte implique un changement de serveur, il faut également préparer le changement d’hébergement sans rupture, avec des sauvegardes, des tests et une gestion rigoureuse des DNS.
Déployer et tester les redirections
Chaque ancienne URL supprimée doit être redirigée directement vers une destination équivalente et utile. Les chaînes de redirections doivent être limitées, les liens internes mis à jour et les erreurs 404 surveillées.
Les recommandations de Google pour déplacer un site avec changement d’URL préconisent notamment de préparer le mapping, de tester les redirections et d’éviter les redirections massives vers une destination sans rapport.
Vérifier les signaux de production
Immédiatement après la bascule, il faut vérifier que le crawl n’est pas bloqué, que les directives noindex temporaires ont été retirées, que les canoniques pointent vers la production et que le sitemap contient les URL attendues.
Les formulaires, paiements, emails, certificats HTTPS et outils de mesure doivent également être testés dans l’environnement réel.
Distinguer les scénarios de migration
Les contrôles diffèrent selon que le projet conserve les mêmes URL, change d’URL sur le même domaine, adopte un nouveau domaine, remplace le CMS ou change d’hébergement.
Lorsque cela est possible, mieux vaut éviter de cumuler plusieurs transformations majeures au même moment. Cette précaution facilite l’identification de l’origine d’un éventuel problème.
Surveiller et corriger après le lancement
Effectuer les contrôles immédiats
Dans les heures qui suivent la mise en ligne, contrôlez la disponibilité du site, les codes HTTP, les redirections, le tracking, les formulaires, les paiements, les emails et les pages stratégiques.
Suivre les jours et semaines suivants
Le suivi doit ensuite porter sur les erreurs d’exploration, les URL indexées, les impressions, les clics, les conversions, les erreurs 404 et les performances des principaux gabarits.
Il est préférable de segmenter les données par type de page, répertoire, appareil, canal ou objectif. Une baisse limitée aux pages produits sur mobile peut rester invisible dans une analyse du trafic global.
Comparer avec les données de référence
Les résultats du nouveau site doivent être comparés avec les données sauvegardées avant la refonte. Les variations temporaires ne doivent pas être ignorées, mais elles ne prouvent pas non plus automatiquement qu’une erreur a été commise.
L’analyse doit distinguer les fluctuations liées au retraitement des URL des problèmes techniques, éditoriaux ou fonctionnels réellement observables.
Organiser le backlog post-lancement
Chaque anomalie doit être enregistrée avec son impact, sa priorité, son responsable et sa méthode de validation. Le lancement ne met pas fin au projet : il ouvre une phase de surveillance, de correction et d’amélioration.
La checklist avant de déclarer la refonte terminée
- Stratégie : les objectifs, le périmètre et les responsabilités sont validés.
- Contenus et SEO : chaque URL a reçu une décision et le mapping a été testé.
- Développement : les fonctionnalités, les performances et les critères techniques sont conformes.
- Tracking : les événements, conversions et données e-commerce remontent correctement.
- Déploiement : les sauvegardes, redirections, DNS et protections temporaires ont été vérifiés.
- Suivi : les données de référence, alertes et responsables post-lancement sont disponibles.
Lorsque le périmètre est complexe ou que les responsabilités restent floues, un regard conjoint sur le SEO et le développement permet de détecter les risques avant qu’ils ne deviennent coûteux à corriger.
Échanger avec Vale Tudo sur le cadrage de votre refonte permet de faire relire le périmètre, les actifs à préserver, les spécifications techniques et le plan de mise en ligne.
Questions fréquentes sur la refonte d’un site internet
Quelle différence entre une refonte, un relooking et une migration de site ?
Le relooking modifie surtout l’apparence. La refonte repense plus largement les parcours, les contenus, les fonctionnalités ou la technique. La migration correspond à un changement d’URL, de domaine, de CMS, d’hébergement ou d’infrastructure.
Comment savoir si une refonte complète est vraiment nécessaire ?
Une refonte complète se justifie lorsque plusieurs éléments structurants sont devenus inadaptés. Si les problèmes sont isolés, une amélioration ciblée peut être plus rapide, moins risquée et plus économique.
Une refonte fait-elle forcément perdre du trafic SEO ?
Non. Une perte n’est pas automatique, mais aucune conservation totale ne peut être garantie. Les risques augmentent lorsque les URL, les contenus ou les règles d’indexation sont modifiés sans audit, mapping ni suivi.
Faut-il conserver toutes les anciennes URL ?
Il faut conserver les URL utiles lorsqu’elles restent cohérentes. Une URL supprimée doit être redirigée vers une destination réellement équivalente. En l’absence d’alternative pertinente, une erreur 404 ou 410 peut être plus appropriée.
Quels éléments font varier le prix d’une refonte ?
Le budget dépend notamment du volume de pages, du design, des développements spécifiques, des contenus, du CMS, des langues, des intégrations, des données à migrer, de la recette et du suivi après lancement.
Combien de temps dure un projet de refonte ?
La durée dépend du périmètre, du nombre d’intervenants, des validations, des contenus et des fonctionnalités. Un calendrier fiable ne peut être établi qu’après le cadrage et l’inventaire de l’existant.
Le site actuel peut-il rester en ligne pendant la refonte ?
Oui, dans la plupart des cas. Le nouveau site est développé sur un environnement distinct. Il faut toutefois prévoir la synchronisation des contenus ou des données et organiser une fenêtre de bascule.
Que faut-il tester en priorité lors de la refonte d’un e-commerce ?
Les tests doivent couvrir le catalogue, les variantes, la recherche, les filtres, les stocks, les comptes, le panier, le paiement, les promotions, les livraisons, les emails, les flux tiers et le tracking.
