Comment migrer depuis un autre créateur de site sans casse
Comment migrer depuis un autre créateur de site sans casse
Une migration se fait en quatre temps : on récupère les contenus de l'ancien site, on reconstruit les pages sur le nouvel outil, on bascule le nom de domaine une fois le résultat validé, puis on met en place les redirections. Le contenu se transfère toujours, la mise en page jamais.
Que peut-on réellement transférer d'un outil à l'autre ?
Moins de choses qu'on ne l'imagine, et c'est vrai dans les deux sens. Chaque créateur de site enregistre les pages dans son propre format interne : il n'existe pas de fichier universel qu'on exporte d'un côté pour l'importer de l'autre.
Ce qui voyage sans problème, ce sont les éléments qui vous appartiennent en propre : vos textes, vos photos, vos tarifs, votre nom de domaine, vos comptes chez des services tiers. Ce qui ne voyage pas, ce sont les objets propres à l'ancien outil : gabarits, blocs maison, extensions installées.
| Élément | Se transfère | Comment procéder |
|---|---|---|
| Textes des pages | Oui | Copier dans un document avant de commencer |
| Images et logos | Oui | Télécharger les fichiers d'origine, pas les versions compressées |
| Nom de domaine | Oui | Changer la configuration chez le bureau d'enregistrement |
| Adresses des pages | Oui, si vous les recréez | Reprendre les mêmes chemins, sinon rediriger |
| Mise en page et gabarits | Non | Se redécrit sur le nouvel outil |
| Extensions et modules | Non | Chercher l'équivalent en intégration |
| Base de clients et comptes | Selon le service | Dépend de l'endroit où les données sont stockées |
| Historique de statistiques | Non, sauf compte externe | Un compte Google Analytics conservé garde son historique |
La ligne la plus importante est celle des adresses de pages. C'est elle qui décide si votre référencement survit ou non à l'opération, et c'est aussi celle que les gens oublient le plus souvent.
Par où commencer une migration ?
Par un inventaire écrit, avant de toucher à quoi que ce soit. Listez toutes les pages de l'ancien site avec leur adresse exacte et leur rôle. Vingt minutes de tableur ici évitent trois jours de rattrapage plus tard, quand on découvre une page oubliée qui recevait du trafic.
Repérez ensuite les pages qui comptent vraiment. Sur la plupart des sites, une poignée d'adresses concentre la majorité des visites : l'accueil, une ou deux pages de prestation, parfois un article. Ces pages méritent une reconstruction soignée, le reste peut attendre.
Récupérez enfin les fichiers sources. Les images affichées sur un site sont souvent des versions redimensionnées : cherchez les originaux dans vos dossiers plutôt que de les extraire de l'ancien site, sinon vous repartez avec des visuels dégradés qui se verront sur les grands écrans.
Ne coupez rien tant que le nouveau site n'est pas prêt. Les deux versions peuvent coexister sans problème : l'ancienne sur votre domaine, la nouvelle sur une adresse en .zugo.run que vous êtes seul à connaître.
Comment reconstruire les pages sans tout refaire à la main ?
En décrivant le site voulu plutôt qu'en recopiant l'ancien. C'est le point qui change tout par rapport à une migration classique : vous n'avez pas à replacer chaque bloc, vous décrivez la structure et le contenu, et la construction produit une première version complète.
Une description utile ressemble à ceci : le métier, les pages attendues, le ton visuel, l'action principale de chaque page. Comptez 6 crédits pour une construction simple, 12 crédits pour une plateforme multipage couvrant les trois premières pages, puis 3 crédits par page supplémentaire.
Vient ensuite la phase de rapprochement avec l'ancien site : ouvrez les deux côte à côte et corrigez les écarts par modifications successives, 3 crédits l'unité. C'est plus rapide que de tout décrire d'emblée, parce que vous voyez enfin ce qui manque au lieu de l'imaginer.
Comptez une soirée pour un site vitrine de quatre à cinq pages dont les textes existent déjà, et davantage si vous en profitez pour réécrire. Les méthodes de formulation sont détaillées dans comment écrire un bon prompt.
Comment basculer le nom de domaine sans coupure ?
En ne le déplaçant qu'à la fin. Tant que le nouveau site n'est pas validé sur son adresse provisoire, votre domaine continue de pointer vers l'ancien, et vos visiteurs ne voient aucune différence. C'est le filet de sécurité de toute l'opération.
Le jour de la bascule, vous modifiez la configuration chez votre bureau d'enregistrement pour faire pointer le domaine vers le nouveau projet. La propagation prend de quelques minutes à quelques heures selon le fournisseur, et pendant ce laps de temps une partie des visiteurs voit encore l'ancienne version.
Choisissez donc un moment creux : un mardi matin plutôt qu'un vendredi soir, et jamais la veille d'une opération commerciale. Gardez l'abonnement de l'ancien outil actif pendant deux à quatre semaines après la bascule, le temps d'être certain que rien n'a été oublié.
Le détail des étapes de branchement figure dans puis-je utiliser mon propre nom de domaine. Si vous préférez héberger sur votre propre compte, le déploiement vers Vercel est également possible.
Que deviennent le référencement et les liens existants ?
Ils survivent si les adresses survivent. Une page qui garde exactement le même chemin garde sa position acquise. Une page qui change d'adresse sans redirection perd tout, et les liens pointant vers elle depuis d'autres sites tombent dans le vide.
La règle est donc simple : reprenez les mêmes chemins d'URL partout où c'est possible, et mettez en place une redirection pour chaque adresse que vous décidez de changer. Cette liste de correspondances se prépare à partir de l'inventaire fait au début.
Attendez-vous à une variation de positions pendant quelques semaines, même en faisant tout correctement. Les moteurs revisitent progressivement, comparent, réévaluent. Une baisse temporaire n'est pas un échec, mais une baisse qui dure trois mois signale un problème d'adresses ou de contenu perdu.
Conservez surtout le même compte Google Analytics : votre historique de fréquentation continue sans rupture et vous pouvez comparer l'avant et l'après sur les mêmes bases. Le sujet plus large est traité dans un site créé par IA est-il bon pour le SEO.
Quand vaut-il mieux ne pas migrer ?
Quand votre site repose sur quelque chose que le nouvel outil ne fait pas. Un catalogue de plusieurs milliers de références avec une gestion de stock reliée à votre logiciel de caisse, par exemple, s'accommode mal d'une reconstruction par description.
Il faut aussi être honnête sur les forces des autres outils. Les plateformes installées depuis longtemps disposent d'écosystèmes d'extensions très fournis, et une fonction obtenue là-bas en installant un module se rebâtit ici par modifications successives. Si votre site vit de trois extensions spécialisées, l'équation n'est pas la même.
Enfin, un produit complexe porté par une équipe reste un projet de développement. Zugo accélère la mise au point et couvre les intégrations courantes (Supabase, Stripe, GitHub, Vercel, Resend, domaine, Google Analytics), mais il ne remplace pas une équipe sur une application métier lourde, et les jeux qu'il produit sont en 2D dans le navigateur.
Pour un site vitrine, une boutique simple, un site de prestation de services ou une application interne, la migration se justifie largement. Le plan Free et ses 5 crédits suffisent à reconstruire une page d'accueil pour comparer avant de décider, et tout se lance depuis zugo.dev.