Refonte et migration de site : un site neuf, plus rapide et lisible sur mobile, sans perdre le référencement ni les données

Que recouvre une refonte avec migration, et qu'est-ce qui n'en fait pas partie ?

Deux chantiers se cachent derrière ce service, et ils se mènent ensemble. La refonte change ce que le visiteur voit et ressent : la maquette, la navigation, la vitesse, la lecture sur téléphone, le contraste, les formulaires. La migration change ce qui est sous le capot : le logiciel qui fait tourner le site (le CMS), le nom de domaine, le serveur, le protocole. Une refonte sans migration existe, une migration sans refonte aussi, mais la plupart des demandes combinent les deux, parce qu'un site qu'on redessine est souvent un site qu'on veut sortir d'une plateforme qui ne convient plus.

Les cas les plus fréquents sont connus : un site WordPress devenu ingérable qu'on reconstruit sur mesure en Laravel, ou l'inverse, un site sur mesure dont plus personne ne sait modifier le code et qu'on ramène vers WordPress ; une boutique Wix ou Shopify qu'on rapatrie sur WordPress et WooCommerce pour maîtriser ses coûts et ses moyens de paiement ; un changement de nom de domaine après une fusion ou un changement de marque ; un hébergeur trop lent ou trop cher qu'on quitte ; un site encore servi en HTTP qu'on passe enfin en HTTPS.

Dans chacun de ces cas, le travail commence par ce qui existe déjà : l'inventaire des adresses, du trafic, des contenus qui rapportent et des données à reprendre. C'est la différence avec une création. Si vous n'avez pas encore de site, la bonne porte est un site vitrine professionnel ou un site e-commerce. Si le site actuel tient debout et ne souffre que de pages mal optimisées, un audit SEO complet coûte moins cher qu'une refonte et suffit parfois.

Le service ne recouvre pas non plus le référencement des mois suivants, qui relève du référencement naturel, ni la maintenance courante du nouveau site, qui relève d'un contrat de maintenance et support. Il prend fin quand le nouveau site est en ligne, que les anciennes adresses répondent toutes par une redirection ou un code d'erreur voulu, que les données sont contrôlées et que trois mois de suivi ont confirmé que Google a bien suivi le déménagement.

Pourquoi l'inventaire des URL et du trafic décide-t-il de tout le reste ?

Google ne classe pas un site, il classe des pages, chacune à son adresse. Chaque adresse a accumulé des signaux au fil des années : des liens venus d'autres sites, des clics, une place dans les résultats pour certaines recherches. Une refonte qui change l'adresse d'une page sans dire à Google où elle est partie efface ces signaux. L'inventaire sert à ne rien oublier, et il doit être fait avant de toucher au site, tant que l'ancien est encore en ligne et lisible.

Le guide de migration de Google Search Central, mis à jour le 11 septembre 2026, cite trois sources pour retrouver les anciennes adresses : les sitemaps, les journaux du serveur et la Search Console. S'y ajoutent une exploration complète du site par un robot, l'outil de statistiques, la liste des liens entrants et, pour une boutique, l'export du catalogue. Croiser ces sources fait remonter les pages que plus aucun menu n'affiche mais que des clients atteignent encore depuis un vieil article, une affiche ou un message WhatsApp transféré.

Chaque adresse reçoit ensuite des chiffres : visites des douze derniers mois, clics et impressions dans Google, nombre de sites qui la citent, conversions quand elles sont mesurées. Ce tri fait apparaître les contenus qui rapportent. Ce sont souvent quelques dizaines de pages sur plusieurs centaines, et ce ne sont pas toujours celles que l'entreprise croit : une fiche pratique écrite en 2019, une page de tarifs, un article sur une démarche administrative. Ces pages-là gardent leur texte, leur adresse si possible, et leurs titres, sauf raison solide.

Reste la décision page par page. Une page utile garde son adresse, ou en reçoit une nouvelle avec une redirection permanente. Deux pages qui se concurrencent sont fusionnées, et les deux anciennes adresses pointent vers la page fusionnée. Une page sans visite ni lien, ou dont le contenu n'a plus de raison d'être, peut disparaître : le guide de Google recommande alors de renvoyer un code 404 ou 410 pour les contenus supprimés, plutôt que de les rediriger vers une page sans rapport.

Que dit Google des redirections, et comment éviter les chaînes ?

La page Redirections et recherche Google, mise à jour le 5 mai 2026, range les codes 301 et 308 parmi les redirections permanentes : Google y voit le signal que la page de destination devient la page de référence, celle qu'il affichera. Les codes 302, 303 et 307 sont temporaires, et la page d'origine reste alors indexée. La même page recommande les redirections côté serveur comme le meilleur moyen d'envoyer à la bonne page à la fois Google et les visiteurs, et ne garde la redirection en JavaScript qu'en dernier recours.

Le guide de migration ajoute deux règles chiffrées. Une redirection doit mener directement à sa destination : trois sauts au plus dans l'idéal, moins de cinq en dernier recours. Et les redirections doivent rester en place aussi longtemps que possible, en général au moins un an. Sur un site qui a déjà connu une refonte, c'est là que les ennuis se cachent : l'adresse de 2016 renvoie vers celle de 2020, qui renvoie vers celle de 2023. Le plan de redirections réécrit ces chaînes pour que chaque ancienne adresse, quelle que soit son époque, aille en un seul saut vers la page actuelle.

En pratique, les redirections sont écrites dans la configuration du serveur (Apache, Nginx) ou dans le routage de l'application, pas dans une extension qui ajoute une requête à la base de données à chaque visite. Pour un changement de domaine, l'ancien domaine garde un hébergement minimal dont le seul rôle est de rediriger chaque adresse vers son équivalent, chemin compris. Rediriger tout l'ancien domaine vers l'accueil du nouveau est la faute la plus fréquente, et la plus coûteuse.

Comment se sert-on de l'outil Changement d'adresse de la Search Console ?

Quand le nom de domaine change, Google propose un outil dédié dans la Search Console. Son aide officielle pose trois conditions : être propriétaire validé de l'ancienne et de la nouvelle propriété avec le même compte Google, avoir mis en place des redirections 301 de l'ancien site vers le nouveau, et travailler sur des propriétés de niveau domaine, pas sur un chemin comme exemple.com/boutique. Avant d'accepter la demande, l'outil vérifie la propriété et contrôle les redirections de quelques pages.

Trois limites évitent bien des surprises. L'outil ne migre aucun sous-domaine du domaine indiqué, pas même www : chaque variante se déclare à part. Il ne sert ni au passage de HTTP à HTTPS, ni au passage de www à sans www, ni aux déplacements de pages à l'intérieur d'un même domaine. Enfin, ses effets ont une durée : selon la même aide, le signal transmis reste actif pendant 180 jours, les redirections doivent être conservées au moins 180 jours, plus longtemps si l'ancien site reçoit encore des visites, et l'ancien domaine doit rester à vous pendant au moins un an pour qu'un tiers ne le rachète pas.

L'outil ne remplace donc pas les redirections : il les complète. Le jour de la bascule, une fois les 301 actives et testées, la demande part depuis la propriété de l'ancien domaine. Le nouveau sitemap est envoyé dans la propriété du nouveau domaine. Ensuite commence l'attente : le guide de Google prévient que la visibilité peut fluctuer temporairement pendant une migration, et qu'il faut en général quelques semaines pour que la majorité des pages d'un site de petite ou moyenne taille soient prises en compte.

Comment préserver les balises, les données structurées et les contenus qui rapportent ?

Une page qui se classe bien doit son rang à un ensemble : son texte, son titre, ses intertitres, ses liens internes, ses images et ce que Google sait d'elle grâce aux données structurées. La refonte peut changer la présentation de tout cela, pas le fond, sauf décision prise en connaissance de cause. Chaque page qui rapporte est donc reprise avec sa balise title, sa description, son titre principal, son texte et ses images, puis seulement améliorée là où l'audit a relevé une faiblesse.

Le guide de migration de Google fixe quelques exigences techniques sur le nouveau site. Chaque page de destination porte une balise canonique qui se désigne elle-même. Les annotations hreflang, sur un site en plusieurs langues, sont réécrites avec les nouvelles adresses. Les liens internes pointent directement vers les nouvelles adresses, au lieu de traverser des redirections. Le fichier robots.txt ne bloque pas les anciennes adresses : Google doit pouvoir les explorer pour découvrir leurs redirections.

La documentation de Google sur l'indexation mobile, mise à jour le 20 février 2026, rappelle que Google indexe et classe la version mobile des pages, explorée par son robot pour smartphone. Le nouveau site doit donc offrir sur téléphone le même contenu, les mêmes titres, les mêmes données structurées et les mêmes textes alternatifs d'images que sur ordinateur. La même page conseille de garder les mêmes adresses d'images lors d'une migration, faute de quoi le trafic venu de la recherche d'images peut baisser le temps que Google les retrouve.

Les données structurées méritent un contrôle à part. Fil d'Ariane, produit avec son prix et sa disponibilité, article avec sa date, organisation avec son adresse : si l'ancien site les déclarait, le nouveau doit les déclarer aussi, et sans erreur. Elles sont vérifiées sur la préproduction, puis à nouveau sur le site en ligne, avec les outils de test de Google.

Pourquoi la migration des données se prépare-t-elle comme une opération comptable ?

Une boutique ne se résume pas à ses fiches produits. Elle porte l'historique des commandes, les comptes clients, les adresses de livraison, les avis, les bons de réduction en cours, parfois des abonnements. Un site de contenus porte des centaines d'articles, leurs catégories, leurs auteurs, leurs images et les documents joints. Chaque type de donnée a sa propre méthode d'export, sa propre limite et son propre contrôle. Avant le premier import, chaque ensemble est donc compté : nombre de produits, de variantes, de commandes, de clients, d'articles, de médias.

Le même comptage est refait après chaque import sur la préproduction, et les écarts sont expliqués un par un : doublons supprimés volontairement, produits archivés, comptes de test. On contrôle aussi quelques fiches au hasard, de bout en bout : la commande n° 1 284 a-t-elle le bon client, les bons articles, le bon total, le bon statut ? La documentation de Shopify met en garde contre un détail que l'on retrouve partout : trier un fichier d'export dans un tableur peut dissocier les variantes et les adresses d'images de leur produit. Les fichiers sont donc traités par script, jamais retouchés à la main.

Les mots de passe posent un problème particulier. Ils sont stockés chiffrés par chaque plateforme, selon sa propre méthode, et l'aide de Shopify indique qu'on ne peut pas les migrer depuis une autre boutique : les clients doivent recréer le leur. Entre deux sites WordPress, ou vers un site sur mesure qui sait relire le format d'origine, ils peuvent souvent être conservés. Quand ce n'est pas possible, un message clair aux clients, envoyé au bon moment, évite une vague de demandes au service client.

Préproduction, bascule DNS et retour arrière : comment éviter la coupure ?

Le nouveau site ne se construit jamais sur le site en ligne. Il vit sur une adresse de préproduction, protégée par mot de passe pour que ni Google ni un client ne tombe dessus, avec une copie récente des vraies données. Les paiements y tournent en mode test, les courriels partent vers une boîte de contrôle, et les automatisations qui écrivent ailleurs (CRM, ERP, tableur) sont coupées. C'est sur cette copie que se font la recette, les essais de migration et la répétition générale de la bascule.

Quand la bascule passe par un changement d'hébergeur, le DNS se prépare à l'avance. La page de Google sur le changement d'hébergement, mise à jour le 31 décembre 2025, conseille de réduire la durée de vie (TTL) des enregistrements DNS au moins une semaine avant, à quelques heures, pour que les caches se mettent à jour vite. Elle recommande de garder l'ancien hébergement actif jusqu'à ce que son trafic tombe à zéro, et prévient que l'exploration de Google ralentit un temps après le changement avant de reprendre.

La fenêtre de bascule est choisie au moment où le site reçoit le moins de visites, ce que les statistiques montrent heure par heure. Pour une boutique, les commandes sont gelées quelques minutes ou quelques heures sur l'ancien site, le temps de la dernière synchronisation, avec un message clair aux visiteurs. Si le site doit être indisponible pendant ce temps, il répond par un code 503 : la documentation de Google sur les codes HTTP, mise à jour le 5 mars 2026, indique que les erreurs 5xx l'invitent à ralentir temporairement l'exploration, et que les adresses indexées ne sont retirées que si l'erreur persiste.

Le retour arrière est écrit avant la bascule, avec ses conditions : paiement qui échoue, données incomplètes, erreur de redirection massive. L'ancien site reste intact sur son serveur, sa base n'est pas effacée, et l'ancienne zone DNS est sauvegardée. Revenir en arrière consiste alors à rétablir les anciens enregistrements et à reporter dans l'ancien site les commandes prises entre-temps. Une bascule qui n'a pas de chemin de retour n'est pas une bascule préparée.

Que surveille-t-on pendant les semaines qui suivent la bascule ?

Les premiers jours servent à repérer ce qui a échappé à la recette. Le rapport d'indexation de la Search Console fait apparaître les adresses en erreur 404 que l'inventaire n'avait pas trouvées : vieux liens dans des courriels, documents imprimés, profils sur des annuaires. Chacune reçoit sa redirection si elle a une destination légitime. Le rapport des sitemaps montre combien d'adresses nouvelles sont découvertes et indexées, et la baisse des anciennes adresses dans l'index confirme que Google suit les redirections.

Ensuite viennent les positions et les clics. Le rapport sur les performances compare, requête par requête et page par page, la période d'après à la même période d'avant. Une baisse temporaire est attendue, Google le dit lui-même ; une baisse qui s'installe sur une page précise signale un problème précis : redirection vers une page moins pertinente, texte trop raccourci, balise canonique erronée. C'est là que le plan de redirections, tenu ligne par ligne, permet de corriger vite.

Le suivi dure trois mois. Pendant ce temps, les sites qui citaient vos anciennes adresses sont contactés pour mettre leurs liens à jour, comme le recommande le guide de Google, en commençant par ceux qui envoient du trafic. Vos profils sur les réseaux sociaux, votre fiche Google Business Profile, vos signatures de courriel et vos campagnes publicitaires reçoivent la nouvelle adresse. L'ancien hébergement est résilié quand ses journaux ne montrent plus de visites, jamais avant.

Que gagne-t-on à refondre : vitesse, mobile, accessibilité, sécurité ?

La vitesse se mesure, et la refonte se fixe des objectifs chiffrés. Selon l'article de web.dev sur les signaux web essentiels, publié par Google et mis à jour le 31 octobre 2024, une page offre une bonne expérience quand l'affichage de son plus grand élément (LCP) survient en 2,5 secondes au plus, que sa réponse aux interactions (INP) reste sous 200 millisecondes et que sa stabilité visuelle (CLS) ne dépasse pas 0,1, au 75e centile des visites. Ces trois seuils servent de critères de recette, mesurés sur téléphone.

L'accessibilité profite à tout le monde, à commencer par les visiteurs qui lisent en plein soleil sur un petit écran. Les règles WCAG 2.2 du W3C, recommandation du 12 décembre 2024, demandent un contraste d'au moins 4,5 pour 1 pour le texte courant et de 3 pour 1 pour les grands textes, des cibles tactiles d'au moins 24 pixels CSS de côté au niveau AA, et une alternative textuelle pour chaque image porteuse d'information. Une refonte est le meilleur moment pour les appliquer : les reprendre sur un site existant coûte bien plus cher.

La sécurité, enfin, a changé de statut. Le blog de sécurité de Google a annoncé le 28 octobre 2025 qu'avec Chrome 154, en octobre 2026, le réglage « Toujours utiliser des connexions sécurisées » serait activé par défaut : Chrome demandera la permission de l'utilisateur avant le premier accès à tout site public sans HTTPS. Un site encore en HTTP affiche donc désormais un avertissement avant même d'apparaître. Le passage en HTTPS fait partie de chaque refonte, redirections comprises.

Mobile money, connexion, données personnelles : que change le contexte local ?

En Afrique francophone, une boutique encaisse souvent par mobile money à travers un agrégateur, que le comparatif FedaPay, Kkiapay et CinetPay aide à choisir. Chacun connaît l'adresse du site par ses clés et ses adresses de notification. Une migration de domaine ou de plateforme impose de les mettre à jour, de générer si besoin de nouvelles clés, puis de rejouer un paiement réel de faible montant après la bascule. Côté connexion, la plupart des visiteurs arrivent par le réseau mobile : pages légères, images compressées, polices limitées et cache bien réglé comptent davantage qu'un effet visuel.

La migration déplace des données personnelles : fichiers clients, commandes, comptes, messages reçus par formulaire. Au Bénin, l'article 426 de la loi n° 2017-20 portant code du numérique impose au responsable du traitement et à son sous-traitant des mesures techniques et organisationnelles contre la perte, l'altération ou l'accès non autorisé, notamment lors des transmissions sur un réseau, et cite le chiffrement et la capacité à rétablir les données après un incident. L'article 391 n'autorise un transfert vers un État tiers que si l'Autorité constate un niveau de protection équivalent : le pays du nouvel hébergeur compte.

En Europe, le RGPD encadre le même chantier. L'article 28, présenté par la CNIL, exige un contrat avec le sous-traitant qui fixe l'objet, la durée, la nature et la finalité du traitement, et qui prévoit la suppression ou la restitution des données à la fin de la prestation. L'article 32 demande des mesures de sécurité adaptées, dont le chiffrement et les moyens de rétablir l'accès aux données en cas d'incident. Concrètement : copies de base chiffrées, transferts par des canaux sécurisés, copies de travail effacées après la recette.

La facturation et la langue suivent vos clients. Les devis et factures sont établis en francs CFA pour les clients d'Afrique de l'Ouest et du Centre, en euros, en francs suisses ou en dollars canadiens ailleurs. Le site reste en français, avec une version anglaise quand vos clients la demandent ; dans ce cas, chaque langue garde ses propres adresses, ses balises hreflang et son propre suivi.

Pourquoi confier la refonte et la migration de votre site à Richard SALANON ?

Richard SALANON est consultant en digitalisation et développeur logiciel, basé à Cotonou, au Bénin. Il crée des sites, des applications web et mobiles, des automatisations et des intégrations d'intelligence artificielle, déploie Odoo et Dolibarr, et forme les équipes à ces outils, pour des entreprises d'Afrique francophone, d'Europe et du Canada.

Il exerce depuis plus de 6 ans, a été formé à EPITECH (promotion 2022), revendique plus de 50 projets livrés et a mené des missions au Bénin, en Côte d'Ivoire, au Togo, au Sénégal, au Burkina Faso, au Mali, au Niger, au Tchad, au Gabon, en RD Congo, en France, en Belgique, en Suisse et au Canada. Développeur autant que concepteur de sites, il écrit lui-même les scripts de migration, les redirections dans la configuration du serveur et les gabarits du nouveau site, sans sous-traiter la partie technique qui décide du résultat.

Il a appliqué cette méthode à son propre site. En septembre 2026, il a migré son site de son ancien sous-domaine vers richardsalanon.com, avec des redirections 301 écrites adresse par adresse et une demande dans l'outil Changement d'adresse de la Search Console. Il connaît donc de l'intérieur ce que demande un changement de domaine : l'inventaire, les variantes de domaine à déclarer une à une, l'attente pendant que Google suit les redirections. Il développe aussi Wapy, un assistant WhatsApp à intelligence artificielle, et il est co-fondateur d'Audyxa.

Sa façon de travailler tient en engagements vérifiables : inventaire avant toute décision, préproduction protégée, plan de redirections remis ligne par ligne, retour arrière écrit avant la bascule, suivi des erreurs et de l'indexation après la bascule, et tous les accès à votre nom. Il répond sous 24 heures. Votre équipe peut ensuite suivre la formation visibilité Google pour lire la Search Console elle-même. Son parcours est détaillé sur la page Richard SALANON.