Migrer de Webflow vers Sanity sans perdre ses positions Google

Comment ne pas perdre ses positions Google avec les redirections 301 ?

Une ancienne URL Webflow doit répondre par une redirection 301 vers son équivalent Sanity. Une par ancienne page, sans exception. Sur une migration Webflow vers Sanity, c'est le geste qui porte l'essentiel du risque SEO - et il se pose avant la mise en ligne, pas après. Une page retirée sans redirection sort de l'index, et la faire revenir prend ensuite des semaines.

Pourquoi lister toutes les URL avant la migration ?

Un slug, c'est le bout d'adresse qui suit le domaine : /blog/mon-article. Sauf que sur un site Webflow, il n'y a pas que les slugs de ton CMS. Il y a aussi les pages statiques, les pages de catégories, les tags, les paginations d'archive et parfois de vieilles URL avec paramètres que Google a indexées au fil des campagnes.

Tu pars donc d'un fichier à deux colonnes : ancienne_url → nouvelle_url. Le point de départ, tu l'as déjà : c'est l'inventaire produit à l'étape où tu exportes le contenu Webflow. Tu y ajoutes une colonne d'URL absolue, et le tour est joué.

Ce qu'il faut recenser :

• Les pages statiques : accueil, à propos, contact, mentions légales.
• Les items de chaque collection du CMS (articles, produits, auteurs, catégories).
• Les pages de liste et d'archive générées par Webflow.
• Les paginations (/blog/page/2), si elles reçoivent du trafic.
• Les URL avec paramètres encore visibles dans Search Console.

Sur un site de 40 pages, le fichier fait 40 lignes. Sur un blog de 300 articles, il en fait 300. C'est du travail mécanique, pas un chantier : le tout est de le faire avant la bascule, pas trois semaines après.

Où poser les règles de redirection, hébergeur ou CDN ?

Point à ne pas rater : Sanity ne sert pas les pages de ton site. Le CMS stocke le contenu, un point c'est tout. Les redirections se déclarent là où le front est réellement servi, c'est-à-dire chez ton hébergeur ou sur ton CDN.

Un fichier de départs ressemble à ça :

# _redirects (Netlify) : ancienne URL, nouvelle URL, code
/ancien-article            /blog/nouveau-slug              301
/ancienne-page-service     /services/offre-nouvelle        301
/tarifs                    /offres/tarifs                  301

Le CDN travaille avant l'application : quand la redirection est posée au bon endroit, elle répond en quelques millisecondes et ne dépend ni d'une page rendue, ni d'un script. C'est la méthode recommandée par Google, qui préfère les redirections côté serveur aux solutions JavaScript ou aux balises meta.

Comment traiter les slugs modifiés ?

Trois cas, trois réponses :

1. Le slug n'a pas changé. Rien à faire. C'est la situation à viser, et c'est une consigne que tu peux mettre noir sur blanc dans le brief donné à Claude Code : ne pas toucher aux adresses existantes sans raison.
2. Le slug a changé. Une redirection 301 vers la nouvelle adresse, en un seul saut. Si l'article a été déplacé d'une catégorie à une autre, on redirige vers la nouvelle catégorie, pas vers la racine.
3. La page n'existe plus. On redirige vers la page la plus proche et la plus utile pour le visiteur : la catégorie parente, la page de service équivalente. S'il n'existe vraiment aucun équivalent, un code 410 est plus honnête qu'un renvoi vers l'accueil.

Ce qu'il ne faut pas faire : envoyer toutes les vieilles URL vers la page d'accueil. Google traite ce réflexe comme une soft 404 - la page répond bien, mais elle n'a rien à voir avec ce que le visiteur cherchait. Le signal se perd, et le visiteur aussi.

Quelles erreurs de redirection reviennent le plus souvent ?

• La chaîne de redirections. A → B → C. Google finit par suivre, mais chaque saut dilue le signal et ajoute un aller-retour réseau. Vise A → C directement.
• La redirection vers une page morte. La règle existe, la cible renvoie un 404. Ça arrive dès qu'une URL change après la rédaction du fichier : vérifie chaque cible après la bascule, avec un crawl ou un simple test par lots.
• Le 302 posé par défaut. Un 302 dit « c'est temporaire ». Pour un changement définitif, c'est un 301 (ou un 308), sinon la nouvelle adresse n'est pas consolidée comme adresse de référence.
• Les redirections supprimées trop tôt. Le trafic vers les anciennes URL ne s'arrête pas à la mise en ligne. Google recommande de garder les redirections en place durablement - six mois minimum, davantage si des visites arrivent encore sur les anciennes adresses.
• L'oubli du changement d'adresse. Si ton domaine ne change pas (le cas le plus courant d'une migration Webflow → Sanity), l'outil Changement d'adresse de Search Console ne s'applique pas : il sert aux changements de domaine ou de sous-domaine. Les 301 suffisent, mais elles doivent être complètes.

Comment faire réindexer son site après la migration ?

Le jour de la mise en ligne, tu soumets le nouveau sitemap, tu vérifies que le robots.txt n'exclut rien, tu fais inspecter tes pages stratégiques, puis tu attends. La réindexation d'un site après migration n'a rien d'un interrupteur : Google traite le changement de façon progressive, sur des semaines. Compte 90 jours comme fenêtre d'observation avant de juger quoi que ce soit.

Que faire dans Search Console le jour de la mise en ligne ?

Une demi-heure suffit, à condition de suivre l'ordre :

• Vérifier la propriété du domaine (elle est déjà validée si le domaine ne change pas).
• Générer puis soumettre le sitemap XML. Attention : Sanity ne produit pas de sitemap, il ne fait que stocker du contenu. C'est ton front qui doit le générer au build, par exemple via une route dédiée comme dans Next.js.
• Ouvrir le robots.txt en ligne et vérifier qu'aucun Disallow: / ne traîne depuis l'environnement de préproduction. C'est l'erreur qui coûte le plus cher, et la plus discrète.
• Vérifier qu'aucune balise noindex n'a survécu dans les gabarits du nouveau front.
• Inspecter une dizaine d'anciennes URL pour confirmer que la 301 est bien détectée.
• Demander l'exploration des 10 à 20 pages qui pèsent le plus dans ton trafic, sans en attendre de miracle : Google précise noir sur blanc qu'une demande de réexploration ne garantit pas une indexation immédiate.

Combien de temps avant de retrouver ses positions ?

Personne ne peut te donner une date. Ce que Google documente, c'est que l'exploration d'un site migré prend de quelques jours à plusieurs semaines, et que la transition est progressive. Dans la pratique, on observe souvent cette séquence :

• Semaines 1 et 2. Le trafic bouge dans tous les sens. Les impressions baissent parfois avant de remonter : c'est normal, et ce n'est pas un signal d'alarme.
• Mois 1 à 3. Les nouvelles URL prennent le relais sur les anciennes. Les positions se recalent, souvent en commençant par les pages les mieux maillées.
• 90 jours. C'est la fenêtre honnête pour comparer avant / après et tirer une conclusion.

Ce qui allonge le délai : une refonte éditoriale faite en même temps, un maillage interne pauvre entre les nouvelles pages, quelques redirections manquantes, ou un front beaucoup plus lent que l'ancien. D'où un conseil simple : ne pas empiler migration technique, refonte de contenu et nouveau design sur la même semaine. Tu ne saurais plus ce qui a cassé quoi.

Quels signaux surveiller dans les semaines qui suivent ?

Rythme de lecture raisonnable : un coup d'œil à J+7 pour vérifier que rien ne casse, une vraie analyse à J+30, un bilan à J+90. Les conclusions tirées au bout de trois jours n'ont aucune valeur statistique.

Comment repérer les pages qui ne reviennent pas ?

Le rapport « Pages » est ton meilleur outil, à condition de le croiser avec le fichier d'inventaire d'URL produit avant la migration.

• Filtre les erreurs 404 et les soft 404 : chaque URL qui recevait du trafic avant et qui n'existe plus indique une redirection oubliée.
• Regarde les « Explorée, actuellement non indexée » : souvent une page orpheline, sans lien interne vers elle.
• Compare, page par page, les impressions sur 28 jours avant et après. Une page qui perd tout son trafic sans erreur visible mérite un coup d'œil à ses liens entrants.
• Vérifie que le sitemap soumis contient bien les pages concernées : un sitemap qui liste d'anciennes URL renvoie Google vers des 301 en boucle.

Le guide complet de Google sur les migrations de site avec changement d'URL reste la référence à garder ouverte pendant cette période.

Webflow ou Sanity : lequel choisir ?

Il n'y a pas de meilleur CMS dans l'absolu, seulement un meilleur cas d'usage. Webflow gagne quand l'équipe publie seule et que le site reste une vitrine. Sanity gagne quand le contenu doit alimenter plusieurs supports, passer par des workflows de validation ou vivre plus longtemps que le design. Les limites de Webflow sont détaillées plus haut dans ce guide : ici, on tranche.

Les deux grilles tarifaires bougent régulièrement : Webflow a simplifié ses plans en cours d'année, Sanity facture par siège au-delà du plan gratuit. Vérifie les pages officielles avant de poser un budget sur la table.

Site vitrine : Webflow, la plupart du temps

Cinq à trente pages, une équipe qui met à jour ses textes et ses photos toute seule, pas de développeur sous la main : Webflow fait le travail, avec un coût mensuel prévisible et zéro plomberie à surveiller. Passer à Sanity dans ce contexte n'apporte rien, sauf si la vitrine doit demain se brancher sur un CRM, un espace client ou une application - auquel cas la question ne se pose plus au niveau du site, mais du système d'information.

Blog et site éditorial : Sanity prend l'avantage dès que le volume monte

Un ou deux rédacteurs, une publication par semaine : Webflow suffit largement. Plusieurs auteurs, des relectures, des contenus réutilisés dans une newsletter ou sur LinkedIn, des archives qui grossissent depuis des années : Sanity reprend la main. Le Studio gère les rôles, les brouillons et les validations, et le même contenu alimente plusieurs supports sans copier-coller.

Le vrai critère de décision n'est pas l'outil, c'est l'accès à un développeur. Avec Sanity, chaque évolution du front se code. Ce n'est pas un coût caché, c'est la ligne budgétaire à assumer dès le départ.

Plateforme de contenu multi-canal : Sanity, sans hésiter

Site web, application mobile, newsletter, portail partenaire, affichage en boutique : si le même contenu doit sortir par plusieurs portes, Sanity est fait pour ça. Une source de vérité, des API qui servent les mêmes données à tous les fronts. Le match Webflow vs Sanity se termine ici : Webflow ne sait pas le faire nativement, et le contournement par duplication finit toujours par produire des versions divergentes.

E-commerce : ni l'un ni l'autre, souvent

Sois honnête sur ce point. Webflow propose une offre e-commerce, mais un catalogue complexe, des déclinaisons, des promotions et de la logistique la mettent vite à l'étroit. Sanity, de son côté, n'est pas une boutique : c'est un CMS. Il lui faut un moteur de vente branché à côté.

Le montage qui tient la route : la vente chez un spécialiste, le contenu éditorial chez Sanity, et un front qui affiche les deux. Tu gardes une boutique solide et des fiches produit enrichies, sans demander à un CMS de faire le métier d'un autre.

Et si la question qui reste est « je ne veux gérer ni le CMS, ni l'hébergement, ni les mises à jour », alors le sujet n'est plus Webflow ou Sanity. Le sujet, c'est de savoir qui s'occupe de la plomberie ensuite.