Migrer de Wix vers un site personnalisé sans perdre le SEO

1. Identifier le scénario de migration et ce que signifie « compatible SEO » pour votre site Wix

Si vous remplacez Wix par un développement sur mesure, la première question est simple : changez-vous le design, la plateforme, ou les deux ? La réponse modifie le niveau de risque. Une refonte visuelle, c’est une chose. Un changement complet de plateforme, c’en est une autre. Cet article explique comment migrer de Wix vers un site personnalisé sans perdre le SEO, ce qui signifie que le site doit conserver ses pages indexées, l’alignement avec l’intention de recherche et l’autorité acquise, même si la structure change en dessous.

Voyez cela comme une migration SEO, pas seulement comme une refonte. La nuance est importante, car une refonte peut ignorer les anciennes URL, alors qu’une migration SEO doit les respecter. Si une page se positionne sur « tarifs », « zone de service » ou un nom de produit, cette page a une fonction. Elle ne doit pas disparaître simplement parce que la nouvelle mise en page est plus épurée.

Il existe aussi une différence très concrète entre « nous voulons un meilleur site » et « nous voulons préserver les performances de recherche », notamment lorsqu’il faut préserver le référencement lors d’une migration Wix. L’un est un projet de branding. L’autre est une transition contrôlée. Si le site Wix actuel compte 40 pages indexées, alors 40 pages ont besoin d’un plan, même si seulement 12 d’entre elles ont une vraie valeur commerciale.

Ne commencez pas par dessiner des modèles. Commencez par définir ce qui doit survivre : les positions, les URL indexées, les extraits de recherche et les pages qui génèrent des leads ou des ventes. Petit détail, gros impact. Une jolie page d’accueil ne paie pas les factures si les anciennes pages de services disparaissent de Google.

2. Construire une base de référence SEO avant de toucher au site

Avant tout changement de code, capturez l’état actuel du site Wix dans un seul endroit. Listez les URL indexées, les balises title, les méta descriptions, les H1, les liens internes et les pages de conversion. Ajoutez tout ce qu’il faut pour garder la migration organisée et suivre les changements plus tard. Sans cette base, la migration Wix devient une devinette, et l’improvisation coûte cher.

Extrayez les principales pages d’atterrissage depuis Search Console et Analytics, puis comparez-les aux pages que vous pensez importantes. Ces deux listes sont souvent différentes. Un article de blog rédigé il y a deux ans peut apporter plus de trafic organique que la page d’accueil. Une page de service oubliée peut encore mieux convertir qu’une page plus récente. Les chiffres d’abord, les opinions ensuite.

Capturez aussi les modèles actuels de title et de méta description. Les sites Wix suivent souvent un schéma répété sur de nombreuses pages, et une fois ce schéma perdu, les taux de clic peuvent changer. Même une légère variation de formulation peut compter si la requête est précise. Une page sur les « meubles de cuisine sur mesure » n’est pas l’endroit pour faire dans la poésie.

Enregistrez également la cartographie des liens internes. Quelles pages pointent vers la page contact ? Quels articles de blog renvoient vers la page de service principale ? Quelles pages sont enfouies dans les menus ? Ces liens font partie de la migration SEO, car ils indiquent aux moteurs de recherche quelles pages comptent le plus.

Utilisez un tableau avec au moins ces colonnes : URL actuelle, type de page, source de trafic, balise title, méta description, canonique, indexabilité et nouvelle URL cible. Gardez le fichier lisible. Si quelqu’un d’autre ne peut pas le comprendre en 10 minutes, il est trop confus. C’est aussi le bon moment pour mener un audit SEO avant refonte d’un site Wix afin d’éviter les oublis critiques.

3. Auditer les schémas d’URL, les types de pages et les ressources indexables propres à Wix

Wix comporte des schémas faciles à manquer lors d’une refonte. Les articles de blog peuvent se trouver dans un dossier structuré. Les pages système peuvent vivre sous des chemins que vous n’avez pas choisis. Les pages générées par des applications, les formulaires et les pages d’événements peuvent aussi devenir indexables si elles ont été exposées aux moteurs de recherche. C’est souvent là qu’une migration Wix déraille.

Vérifiez soigneusement la structure actuelle des URL. Repérez les slashs finaux, les chemins en minuscules ou en majuscules, les URL paramétrées et les segments système inhabituels. Si un article se trouve à /post/ et un autre à /blog/titre-de-l-article, n’imaginez pas que le nouveau CMS reproduira cela automatiquement. Ce ne sera pas le cas.

Les URL des images comptent aussi. Une construction sur mesure peut remplacer les chemins d’images, mais si ces fichiers sont indexés ou intégrés dans de nombreuses pages, des références d’images cassées peuvent créer du bruit et ralentir la récupération. C’est pareil pour les PDF, les fichiers téléchargeables et les ressources de galerie. Un seul fichier cassé peut affecter plusieurs pages à la fois.

Wix permet aussi des fonctionnalités qui paraissent mineures mais se comportent comme de vraies pages. Pensez aux widgets de réservation, aux avis, aux listes d’événements ou aux pages d’espace membre. Si l’une d’elles était indexable, le nouveau site doit décider pour chacune : la conserver, la fusionner ou la retirer. Pas d’entre-deux.

C’est le pont entre la planification et l’exécution. Un audit d’URL propre vous dit quelles parties de la migration Wix sont classiques et lesquelles sont des pièges. Si vous sautez cette étape, le premier signe de problème peut être une chute de trafic deux semaines après le lancement.

4. Associer chaque page Wix importante à son équivalent sur le nouveau site

Chaque page Wix importante doit avoir un plan de remplacement un-à-un. Pas un-vers-plusieurs. Pas « on verra plus tard ». Chaque page doit avoir une URL cible, une correspondance de contenu, une correspondance de métadonnées et un plan de maillage interne. Si l’ancienne page était bien positionnée, la nouvelle doit avoir une succession claire.

Utilisez un tableau de correspondance avec au minimum cinq champs : ancienne URL, nouvelle URL, objectif de la page, remarques sur le contenu et action de redirection. Ce tableau devient le document de travail de la migration Wix. C’est aussi le moyen le plus simple de repérer les pages dupliquées, fusionnées ou oubliées par erreur.

Certaines pages doivent être fusionnées. Un ensemble de pages de service trop légères peut devenir une seule page plus solide sur le nouveau site. D’autres doivent être scindées. Une page « services » trop large peut devenir trois pages ciblées. La décision dépend de l’intention de recherche, pas des préférences esthétiques.

Soyez strict avec les pages retirées. S’il n’existe pas de remplacement utile, n’imposez pas une fausse correspondance qui brouille les utilisateurs. Une mauvaise redirection peut être pire qu’un plan de retrait propre. Les moteurs de recherche n’ont pas besoin de vingt pages quasi identiques pour être satisfaits.

C’est à cette étape que la migration SEO devient contrôlée. Sans elle, le nouveau site peut sembler complet tout en cassant discrètement le lien entre les anciens classements et les nouveaux contenus.

5. Préserver les signaux SEO on-page pendant le développement sur mesure

Le développement sur mesure doit reprendre les signaux qui fonctionnent déjà : les titres, la structure du contenu, les données structurées, les textes alternatifs et le contexte des liens internes. Si l’ancienne page Wix avait une structure H2 claire et un bloc FAQ utile, la nouvelle page ne devrait pas la remplacer par six paragraphes marketing génériques. Les moteurs de recherche lisent la structure, pas l’ambiance.

Gardez une logique de titres proche de l’intention d’origine. Si la page Wix répondait à une requête précise dès les 100 premiers mots, la nouvelle page doit faire de même. Si la page contenait un tableau comparatif de produits, conservez ce tableau ou remplacez-le par un format tout aussi utile. Un seul mauvais choix peut faire chuter la pertinence.

Les données structurées méritent de l’attention. Un site personnalisé facilite l’ajout de balisage structuré, mais cela ne signifie pas qu’il faut jeter l’ancien balisage à la légère. Si la page Wix utilisait le schéma Article, LocalBusiness, Product ou FAQ, comparez la nouvelle implémentation avant le lancement. Les changements de modèle peuvent modifier la manière dont les moteurs de recherche interprètent la page.

Le texte alternatif ne doit pas se transformer en bourrage de mots-clés. Gardez-le descriptif, précis et lié à l’image. Si l’image montre une vitrine ou une équipe, dites-le simplement. L’objectif est l’accessibilité et le contexte, pas de glisser des expressions dans chaque nom de fichier.

Le contexte des liens internes compte plus que beaucoup d’équipes ne le pensent. Si une page de service renvoyait auparavant vers deux articles connexes et une page de contact, conservez ces liens dans le nouveau modèle personnalisé. Les moteurs de recherche suivent ces chemins. Les utilisateurs aussi. Deux clics peuvent faire la différence entre un lead et un rebond.

6. Gérer les redirections, les balises canoniques et l’indexation au moment du lancement

La phase de lancement est celle où la plupart des erreurs de migration SEO apparaissent. Chaque ancienne URL Wix qui change doit être redirigée en 301 vers la meilleure destination possible. Pas en 302. Pas vers la page d’accueil par défaut. Une vraie redirection au niveau de la page. Si une page n’a pas d’équivalent, redirigez-la vers la page la plus pertinente ou retirez-la volontairement.

Les balises canoniques doivent pointer vers la version préférée de chaque page, en particulier si le nouveau site crée des chemins alternatifs, des vues filtrées ou des reliquats de préproduction. Les URL dupliquées sont fréquentes pendant une migration Wix, car les anciens et les nouveaux chemins peuvent coexister pendant un certain temps. Si vous ne contrôlez pas les canoniques, vous multipliez les signaux dupliqués.

Les directives robots demandent le même soin. Une balise noindex de préproduction restée sur une page en production peut bloquer l’indexation pendant des jours. Une règle disallow oubliée peut laisser les moteurs crawler des chemins inutiles. Petites erreurs, gros retard. La checklist de lancement doit inclure la mise à jour du sitemap, la vérification des canoniques et la validation des redirections avant la mise en ligne.

Mettez à jour les sitemaps XML pour n’y inclure que les URL finales en ligne. Si le sitemap liste encore les anciennes pages Wix, les moteurs de recherche peuvent continuer à revenir sur des chemins morts. Cela ralentit la découverte des nouvelles pages et donne une impression de transition brouillonne.

Un lancement sans redirections n’est pas une migration. C’est une rupture. Si l’ancienne page avait des positions, du trafic ou des backlinks, la redirection est le pont. Enlevez ce pont et tout le reste devient plus difficile à récupérer.

7. Tester la migration en ligne avec un crawler, pas seulement dans un navigateur

Après le lancement, testez le site avec un crawler, pas seulement dans Chrome. Les navigateurs cachent des problèmes. Les crawlers les trouvent. Une page peut sembler parfaite pour un humain et quand même renvoyer le mauvais code de statut, passer par deux redirections ou exposer une canonique en double.

Commencez par les URL les plus importantes de votre base de référence. Vérifiez que chacune renvoie bien un code 200, se résout en un seul saut si possible et correspond aux métadonnées prévues. Puis recherchez les erreurs 404, 500, les boucles de redirection et les pages bloquées par les règles robots. C’est dans cette partie d’une migration Wix qu’un petit oubli de QA peut rester caché pendant des semaines.

Vérifiez aussi la correspondance des métadonnées. Les titles et les descriptions doivent être présents sur les pages prioritaires, et non vides ou copiés depuis la page d’accueil. Un aperçu dans le navigateur ne vous dira pas si la méta description a été omise. Un crawler, oui.

Examinez aussi les liens internes après le lancement. Si l’ancien pied de page Wix renvoie encore vers des chemins retirés, les utilisateurs tomberont sur des pages cassées et les crawlers perdront du temps. Idem pour les boutons, les liens d’images et les modules d’articles connexes. Un site personnalisé introduit souvent de nouveaux modèles, et chaque modèle mérite au moins un passage de crawl.

Si possible, comparez côte à côte les exports de crawl avant et après le lancement. L’objectif n’est pas la perfection dès le premier jour. L’objectif est la détection rapide. Un rapport de crawl avec 5 chemins cassés est utile. Attendre que 50 soient indexés ne l’est pas.

8. Surveiller la récupération SEO après le lancement et corriger vite les points de rupture

Les premières semaines après la mise en ligne déterminent si la transition se stabilise rapidement ou si elle dérive. Surveillez chaque jour l’indexation, les impressions, les positions et le trafic des pages d’entrée, puis moins souvent une fois la tendance stabilisée. Si une page clé perd en visibilité, vérifiez d’abord les redirections, les canoniques et le contenu de la page avant de toucher à autre chose.

Les liens internes cassés sont fréquents après une refonte, surtout lorsque l’ancienne navigation Wix est remplacée par une nouvelle bibliothèque de composants. Cherchez les liens manquants dans les menus, les pieds de page, les blocs de contenu associé et les boutons. Un lien manquant sur une page à fort trafic peut réduire la circulation du crawl vers le reste du site.

Surveillez aussi les erreurs noindex. Une règle de préproduction, une condition de modèle ou un en-tête copié peut empêcher des pages importantes d’entrer dans l’index. Cette erreur est plus courante que les équipes ne veulent l’admettre. Quelques minutes pour la créer, des jours pour la repérer.

Gardez un œil sur les changements de métadonnées qui semblent anodins. Une balise title réécrite peut modifier le comportement des clics. Une introduction plus courte peut affaiblir la pertinence. Une FAQ supprimée peut réduire la couverture longue traîne. Rien de tout cela ne veut dire que le site personnalisé est mauvais. Cela veut dire que la migration SEO nécessite des ajustements.

À un moment donné, le site cesse d’évoluer et les données se stabilisent. C’est alors que vous pouvez considérer la migration SEO comme achevée. D’ici là, le travail reste en cours. Le nouveau site personnalisé n’est vraiment terminé que lorsque les anciennes URL Wix, les nouvelles pages et les données de recherche s’accordent toutes sur l’emplacement de chaque page.