Migrer de Wix ou Squarespace vers WordPress sans perdre son référencement

Wix et Squarespace font très bien ce pour quoi ils sont conçus : mettre en ligne un site correct, vite, sans développeur. Le problème n'apparaît pas au lancement mais deux ou trois ans plus tard, quand on veut faire quelque chose que la plateforme ne prévoit pas — et qu'on découvre qu'on ne peut pas.

La migration vers WordPress est alors une opération banale techniquement, mais qui comporte un point de rupture : si les redirections sont ratées, vous repartez de zéro en référencement. C'est la seule partie qui ne se rattrape pas après coup.

Les vraies raisons de quitter une plateforme fermée

Les motifs invoqués sont souvent le prix ou le référencement. Ce sont rarement les bons. L'abonnement d'une plateforme reste inférieur au coût d'un site sur mesure pendant plusieurs années, et Wix a beaucoup progressé côté technique — un site Wix bien fait se classe correctement.

Les raisons qui tiennent sont ailleurs. On migre quand on bute sur une limite fonctionnelle : connecter le site à un logiciel métier, gérer un catalogue avec des règles de prix particulières, créer un espace client, automatiser un traitement. Et on migre quand on veut posséder ce qu'on a construit.

Il existe une troisième raison, moins avouable et parfaitement légitime : le coût de sortie augmente avec le temps. Un site de vingt pages se migre en quatre semaines ; le même site cinq ans plus tard, avec deux cents pages, un blog et une boutique, se migre en trois mois. Si la limite fonctionnelle est identifiée et que la décision est prise, la repousser d'un an la rend simplement plus chère.

Les redirections : la seule étape irrattrapable

Chaque plateforme a sa propre convention d'URL. Wix produit souvent des adresses en /post/mon-article, Squarespace en /blog/mon-article, WordPress en /mon-article. Toute adresse qui change sans redirection perd la totalité de sa valeur acquise.

La méthode est simple mais ne souffre aucune approximation : exporter la liste complète des URLs existantes avant de toucher à quoi que ce soit, la confronter aux nouvelles adresses, puis écrire une redirection 301 pour chaque correspondance. Une par une, sans regroupement paresseux vers la page d'accueil.

• Exportez les URLs depuis Search Console et depuis l'ancien sitemap — les deux listes diffèrent toujours
• Chaque ancienne adresse pointe vers la page équivalente, jamais vers l'accueil
• Une redirection vers l'accueil est traitée par Google comme une page supprimée : vous perdez tout
• Conservez les redirections au moins un an, idéalement pour toujours

Ce qui ne se migre pas automatiquement

Les outils d'import récupèrent le texte et les images. Ils ne récupèrent presque jamais le reste, et c'est ce reste qui prend le temps.

• La mise en forme : les blocs propriétaires de la plateforme n'ont pas d'équivalent, tout est à refaire
• Les formulaires et leurs destinataires
• Les redirections déjà en place sur l'ancien site — souvent oubliées, et leur perte casse des liens entrants anciens
• Les balises title et meta descriptions, si elles avaient été personnalisées
• Les avis et contenus intégrés depuis des services tiers

Comptez l'essentiel du temps de migration sur ces éléments, pas sur le transfert du contenu lui-même. C'est ce qui explique l'écart entre les devis à 800 € et ceux à 6 000 € : les premiers migrent le texte, les seconds migrent le site.

L'inventaire des URLs, la première heure du projet

Une migration commence par une liste, pas par une maquette. Tant que vous ne savez pas combien d'adresses existent et lesquelles reçoivent du trafic, tout devis reste un pari. Cette liste demande une à trois heures sur un site de cinquante pages, et c'est le seul moment du projet où elle est encore facile à obtenir : une fois l'ancien site éteint, elle ne se reconstitue plus.

Aucune source ne suffit à elle seule, et c'est précisément ce que la plupart des migrations ratent. Le sitemap ne contient que ce que la plateforme a bien voulu y déclarer. Search Console ne remonte que les pages ayant reçu au moins une impression. Un crawler ne trouve que ce qui est lié depuis une autre page. Les orphelines — anciennes pages de campagne, PDF, pages de remerciement — n'apparaissent que dans les journaux du serveur ou dans l'archive du web.

Le livrable est une feuille de calcul à quatre colonnes : ancienne adresse, trafic sur douze mois, nouvelle adresse, statut. Elle sert de cahier des charges pendant le projet, de recette au moment de la bascule et de preuve trois mois plus tard, quand quelqu'un affirme qu'« on a perdu du trafic » sans pouvoir dire sur quelles pages.

Toutes les URLs ne méritent pas une redirection, et c'est un arbitrage qu'il vaut mieux poser tôt. Les pages de test, les doublons de pagination et les contenus volontairement supprimés gagnent à renvoyer un code 410, qui indique à Google que la suppression est délibérée et accélère le nettoyage de l'index. Rediriger par principe trois cents pages sans valeur disperse l'exploration au lieu de la concentrer.

Ce qu'on perd exactement sans redirection

« On perd le référencement » est une formule vague qui ne dit pas ce qui disparaît. Trois choses distinctes disparaissent, et elles ne se récupèrent pas au même rythme — deux d'entre elles ne se récupèrent d'ailleurs pas du tout.

Les liens entrants d'abord : chaque lien qui pointait vers une page devenue introuvable cesse de transmettre quoi que ce soit. Ce sont souvent des liens de dix ans, obtenus par un article de presse ou un annuaire professionnel, impossibles à refaire. La position ensuite : l'URL sort de l'index, généralement entre deux et huit semaines après le premier passage en 404. Les signets enfin, les liens dans les signatures d'e-mails, les QR codes imprimés sur des plaquettes et le lien de votre fiche Google Business Profile, qui continuent d'envoyer des visiteurs sur une page d'erreur pendant des années.

Le traitement le plus coûteux n'est pas la 404, c'est la redirection globale vers la page d'accueil. Elle donne l'illusion du travail fait, puisqu'aucun lien ne casse visiblement, alors que Google l'assimile à une page supprimée et que le visiteur atterrit sur un site qu'il doit reparcourir pour retrouver ce qu'il cherchait. Le taux de rebond de ces arrivées frôle les 100 %.

Une exception raisonnable existe malgré tout. Quand l'ancien site comptait des centaines de pages sans équivalent — un blog abandonné, un catalogue disparu — rediriger vers la page de catégorie la plus proche vaut mieux que vers l'accueil, et un 410 franc vaut mieux que les deux si le contenu ne reviendra jamais. Ce qui compte est la cohérence, pas l'uniformité.

Récupérer le contenu quand il n'y a pas d'export

Squarespace produit un export XML partiel. Wix exporte les articles de blog et rien d'autre. Les constructeurs de sites inclus chez certains hébergeurs n'exportent parfois rien du tout. Dans ces cas, la question n'est plus « comment exporter » mais « combien de temps pour ressaisir », et cette question se chiffre.

La méthode qui tient est un crawl du site existant, qui produit pour chaque page le titre, la meta description, les intertitres, le corps de texte et la liste des images. La ressaisie dans WordPress se fait ensuite page par page : comptez cinq à huit minutes pour une page simple, quinze à vingt-cinq pour une page composée de blocs mis en page. Quarante-cinq pages simples représentent donc environ cinq heures de travail, pas deux jours — à condition d'avoir extrait le texte d'un coup au lieu de naviguer page par page.

Les images demandent une attention à part. Celles publiées sur la plateforme ont été redimensionnées et recompressées pour son propre affichage ; les récupérer telles quelles fige définitivement une qualité moyenne. Si les originaux existent quelque part — un disque externe, un Drive, le photographe — c'est le moment de les reprendre. Sinon, actez la perte et budgétez une séance photo dans l'année plutôt que de la découvrir six mois plus tard.

• Crawlez d'abord : titres, meta descriptions, H1 et corps de texte en une seule extraction
• Récupérez chaque image à la plus grande taille disponible, et renommez-les au passage
• L'archive du web dépanne pour les pages supprimées récemment mais encore liées ailleurs
• Le texte des formulaires, des e-mails de confirmation et des pages de remerciement se perd systématiquement : listez-les à part

C'est aussi le bon moment pour décider de ne pas tout reprendre. Sur un site de deux cents pages, un tiers ne reçoit aucune visite depuis un an. Les migrer coûte plusieurs jours et n'apporte rien ; les supprimer proprement, en 410, allège le site et concentre l'exploration de Google sur ce qui travaille. Une migration est la seule occasion où ce tri se fait sans discussion : six mois plus tard, plus personne n'ose y toucher.

Le calendrier réaliste d'une migration

Un délai annoncé de dix jours pour migrer un site vitrine est un délai de développement, pas un délai de projet. L'écart vient des allers-retours de validation, de la disponibilité du client pour relire quarante pages et de la recette des redirections, qui ne se comprime pas : elle consiste à vérifier des lignes une par une.

Sur un site de quinze à vingt pages, la séquence tenable est la suivante : une semaine d'inventaire et de maquette, deux semaines de construction et de reprise du contenu, une semaine de recette, de redirections et de bascule. Quatre semaines calendaires, dont une dizaine de jours de travail effectif. Sur une boutique, la reprise du catalogue, des comptes clients et de l'historique de commandes ajoute deux à quatre semaines à elle seule.

• Semaine 1 : inventaire des URLs, export Search Console, arbitrage sur les pages à supprimer
• Semaines 2 et 3 : construction sur un sous-domaine fermé à l'indexation, reprise du contenu
• Semaine 4 : table de redirections testée ligne à ligne, relecture client, bascule un mardi matin
• Semaines 5 à 10 : surveillance des 404, de l'indexation et des positions, corrections au fil de l'eau

Deux règles de bon sens font gagner des jours. La première : geler le contenu de l'ancien site pendant la phase de reprise, faute de quoi vous migrez une version périmée et rejouez les modifications deux fois. La seconde : basculer un mardi matin, jamais un vendredi soir. Les vingt-quatre heures qui suivent une bascule sont celles où l'on découvre les oublis, et il faut quelqu'un de disponible pour les corriger.

Le choix de la période compte plus qu'on ne le croit. Un site de plombier ne se migre pas en janvier, un site d'école de voile pas en mai, une boutique pas en novembre. La baisse de deux à six semaines qui suit toute bascule est indolore en creux d'activité et coûteuse en pleine saison ; c'est souvent le seul argument qui déplace réellement une date de mise en ligne.

Les sept jours qui suivent la bascule

La bascule n'est pas la fin du projet, c'est le début de la seule phase où les erreurs se réparent encore à coût nul. La plus fréquente, et de loin, est le fichier robots.txt de préproduction resté en place, ou la case « demander aux moteurs de recherche de ne pas indexer ce site » de WordPress restée cochée. Le site est parfait et invisible, parfois pendant trois semaines, avant que quelqu'un s'en aperçoive.

• Jour 0 : vérifier l'indexation autorisée, le certificat, la redirection www et le passage en HTTPS
• Jour 0 : tester dix redirections prises au hasard dans la table, dont les cinq pages les plus visitées
• Jour 1 : soumettre le nouveau sitemap dans Search Console et demander l'indexation de la page d'accueil
• Jour 1 : envoyer un formulaire de test et vérifier que l'e-mail arrive, y compris dans les indésirables
• Jour 7 : relever le rapport des pages en 404 et compléter la table de redirections
• Jour 30 : comparer impressions et positions à la même période l'an passé, pas au mois précédent

Le suivi du trafic mérite une précaution méthodologique. Comparer au mois précédent mène à des conclusions fausses, parce que la saisonnalité se mélange à l'effet de la migration : une bascule fin août produit mécaniquement une hausse en septembre, y compris quand les redirections sont mauvaises. La comparaison utile est celle avec la même période un an plus tôt, sur les impressions plutôt que sur les clics — les impressions réagissent en premier et se lisent deux semaines plus tôt.

Gardez enfin l'ancien site accessible en lecture pendant un mois, sur une adresse technique fermée à l'indexation. C'est l'assurance la moins chère du projet : le jour où l'on découvre au bout de trois semaines qu'une page de tarifs n'a pas été reprise, on la retrouve en deux minutes au lieu de la réécrire de mémoire.

Combien de temps et à quel coût

Pour un site vitrine de dix à vingt pages : deux à quatre semaines, entre 3 000 et 7 000 €, redirections et recette comprises. Pour une boutique : quatre à huit semaines et 8 000 à 20 000 €, la migration du catalogue et de l'historique de commandes étant le poste principal.

Prévoyez une baisse de trafic de deux à six semaines après la bascule, même avec des redirections parfaites : Google doit recrawler et réattribuer. Une baisse qui dure au-delà de trois mois signale un problème de redirection, pas un phénomène normal.

FAQ — Migration vers WordPress

Va-t-on perdre son référencement en migrant ?

Pas si les redirections 301 sont faites adresse par adresse. Une baisse de deux à six semaines est normale, le temps que Google recrawle l'ensemble et réattribue la valeur aux nouvelles adresses. Une baisse durable au-delà de trois mois révèle des redirections manquantes ou pointant toutes vers l'accueil.

Peut-on exporter son contenu depuis Wix ?

Partiellement. Wix permet d'exporter les articles de blog, mais pas les pages ni la mise en forme, qui reposent sur des blocs propriétaires. En pratique, le texte se récupère et la structure se reconstruit. C'est une contrainte à intégrer au budget dès le départ.

Combien de temps garder les anciennes redirections ?

Le plus longtemps possible. Google finit par transférer la valeur en quelques mois, mais les liens entrants et les favoris pointent vers les anciennes adresses pendant des années. Une redirection ne coûte rien à conserver : gardez-les indéfiniment.

Faut-il changer de nom de domaine en même temps ?

Non, surtout pas. Changer de plateforme et de domaine simultanément rend impossible de savoir d'où vient un problème si le trafic baisse. Migrez d'abord, stabilisez pendant deux ou trois mois, puis changez de domaine si c'est vraiment nécessaire.

Comment retrouver la liste complète de ses anciennes URLs ?

En croisant quatre sources, jamais une seule : le sitemap XML de l'ancien site, l'export des pages de Search Console sur seize mois, un crawl complet du site, et les pages de destination d'Analytics. Chacune rate ce que les autres trouvent — les orphelines n'apparaissent souvent que dans Analytics ou dans les journaux du serveur. Faites-le avant de toucher à quoi que ce soit : une fois l'ancien site éteint, la liste est définitivement perdue.

Peut-on migrer soi-même un petit site vitrine ?

Pour cinq à dix pages sans formulaire complexe ni boutique, oui, à condition de traiter les redirections sérieusement. C'est la seule partie où l'improvisation coûte cher, et elle demande d'accéder au fichier de configuration du serveur ou à une extension de redirection. Comptez deux à trois week-ends pour un premier site, et gardez l'ancien accessible un mois : c'est ce qui distingue une migration ratée d'une migration corrigeable.

Sources

• Google — Migrations de site avec changement d'URL — procédure officielle et rôle des redirections 301
• Google — Redirections et recherche Google — types de redirection et transfert de signaux
• Google — Déplacer un site avec changement d'URL — périmètre réel de l'export
• Google — Outil d'inspection d'URL — vérifier l'indexation et les redirections après bascule
• Google — Créer et envoyer un sitemap — soumettre le nouveau plan de site le jour de la bascule