Migrer vers Next.js et Sanity sansperdre ses pages en route

Vous avez un site vitrine qui arrive au bout de son outil, et quelqu'un a proposé de migrer vers Next.js avec un CMS headless comme Sanity. L'idée est bonne dans beaucoup de cas. Mais la partie risquée d'une migration n'est presque jamais le code : ce sont les pages qui disparaissent sans redirection, et les mises à jour que l'équipe voit alors que les visiteurs, eux, ne les voient pas.

J'en parle parce que j'utilise cette pile tous les jours. En mai 2026, j'ai refait le site marketing de Moonworkers, mon entreprise, en Next.js et Sanity. Ce site-ci est construit de la même façon, et ma machine de contenu y publie directement. Voici ce que je regarde avant de basculer, dans l'ordre où je le fais.

01Ce que change un site en Next.js et Sanity

Un site classique mélange contenu et mise en page dans le même outil. Avec un CMS headless, on les sépare. Sanity stocke des contenus structurés : un article a un titre, un résumé, un corps, une image, une FAQ. Next.js lit ces contenus et fabrique les pages. L'équipe qui écrit ne touche pas au code, et celui qui code ne touche pas aux textes.

Sanity fournit pour cela un paquet officiel, next-sanity, qui réunit le client, l'édition visuelle et la possibilité d'intégrer le Studio dans l'application elle-même (documentation Sanity sur Next.js). Sur ce site, le Studio vit sur /studio, dans le même projet. Je note quand même que Sanity recommande plutôt de déployer le Studio chez eux. Pour un site où j'écris seul, le Studio intégré me va bien ; pour une équipe éditoriale plus large, je suivrais leur conseil.

Ce que vous gagnez, concrètement : des gabarits sur mesure, des pages rapides, des contenus que vous pouvez réutiliser ailleurs (une application, un e-mail, une autre langue). Ce que vous perdez : la liberté de tout changer sans développeur.

02Quand la migration ne vaut pas la peine

Je préfère le dire avant le reste. Si votre équipe marketing modifie elle-même la mise en page chaque semaine, glisse des sections, teste des variantes de page d'accueil sans demander à personne, un outil visuel comme Webflow fait très bien ce travail. Passer de Webflow vers Next.js retire cette autonomie, et il faut un vrai besoin en face pour que ce soit un bon échange.

Les cas où je pense que la migration se justifie :

• le site doit porter quelque chose qui ressemble à un produit, comme les calculateurs de Moonworkers, que j'ai voulu écrire et tester comme du code (je l'ai raconté dans l'article sur les calculateurs en ligne vérifiés) ;
• le contenu est publié par un outil automatique, ce qui est mon cas, et il faut une API d'écriture propre ;
• le site existe en plusieurs langues avec des contenus liés entre eux ;
• vous avez quelqu'un, en interne ou à l'extérieur, pour maintenir le code dans la durée.

Si aucune de ces lignes ne vous parle, gardez votre outil et améliorez ce qui existe. Une migration coûte du temps, et elle fait bouger votre référencement pendant des semaines, même quand elle est bien faite.

03Lister chaque URL avant d'écrire une ligne de code

Google le dit très simplement : il indexe page par page. Dans une courte vidéo de Google Search Central, John Mueller explique qu'une adresse qui change doit transmettre ses informations à la nouvelle, sinon elles se perdent, et que tout changement d'URL est une migration, de la refonte complète au simple retrait de la barre oblique finale (Do URL structure changes affect SEO?). Il conseille d'établir la liste des anciennes et des nouvelles URL avant de commencer.

La documentation de Google sur la migration d'un site va dans le même sens : partir des pages les plus importantes et associer chacune à sa destination. C'est ce document que j'appelle la table des URL, et c'est le premier livrable d'une migration, avant la maquette.

Comment je construis la table des URL

1. J'extrais toutes les URL connues : le sitemap actuel, les pages vues dans Search Console, celles de l'outil d'analyse, et les liens trouvés par un crawl du site.
2. Je les mets dans un tableur, une ligne par URL, avec une colonne « nouvelle adresse » et une colonne « décision » (garder, rediriger, supprimer).
3. Je garde l'adresse telle quelle chaque fois que c'est possible. Une URL qui ne change pas n'a besoin d'aucune redirection.
4. Pour chaque page supprimée, je cherche la page la plus proche par le sujet, pas la page d'accueil.
5. Je fais relire la table par la personne qui connaît le contenu, parce qu'elle sait quelles pages comptent pour les clients.

Cette table sert ensuite trois fois : pour écrire les redirections, pour la recette, et pour la surveillance après la bascule.

04Écrire les redirections permanentes dans Next.js

Google recommande des redirections permanentes côté serveur, en 301 ou en 308, et déconseille les redirections en JavaScript quand le serveur peut faire le travail (Google Search Central, redirections d'URL). Next.js permet de les déclarer dans son fichier de configuration, avec la clé « redirects » (documentation Next.js). Chaque redirection tient en trois champs :

• « source », l'ancienne adresse, par exemple /a-propos ;
• « destination », la nouvelle, par exemple /fr/a-propos ;
• « permanent », à mettre sur vrai pour une redirection définitive.

Avec « permanent » sur vrai, Next.js renvoie un code 308, que les navigateurs et les moteurs gardent en mémoire. Pas de panique si vous ne voyez pas de 301 : pour Google, 301 et 308 signalent tous deux un déplacement permanent. Un motif comme /blog/:slug vers /fr/blog/:slug évite d'écrire une ligne par article quand toute une rubrique change de préfixe.

Trois erreurs que je vérifie à chaque fois. Les chaînes, où A renvoie vers B qui renvoie vers C : je fais pointer chaque ancienne URL directement vers sa destination finale. Les redirections en masse vers la page d'accueil, que la documentation de Google déconseille. Et la durée : Google demande de garder les redirections aussi longtemps que possible, au moins un an. Dans un fichier de configuration versionné, elles ne coûtent rien à conserver.

05Le cache, ou pourquoi l'équipe ne voit pas ce que voit le visiteur

C'est la partie que les cahiers des charges oublient. Next.js garde en cache les pages qu'il a déjà produites. Quand quelqu'un publie dans Sanity, la page en ligne ne change pas tant que ce cache n'a pas été rafraîchi.

Sur une mission, j'ai vu un site qui semblait normal à l'équipe connectée et qui était cassé pour les visiteurs, à cause d'un cache. Depuis, je vérifie toujours comme un visiteur : navigation privée, sans session, sur l'adresse publique.

Next.js fournit une fonction pour rafraîchir un chemin à la demande, revalidatePath, que l'on peut appeler depuis une route du site (documentation Next.js). Appelée depuis une route, elle marque la page, qui est régénérée à la visite suivante. Sanity décrit de son côté plusieurs stratégies, par durée, par tag ou par chemin, et des webhooks pour déclencher la revalidation à chaque publication.

Sur ce blog, j'ai choisi la plus simple à vérifier. Ma machine de contenu publie l'article dans Sanity, appelle une route de revalidation protégée par un secret, puis charge la page une fois. Ensuite, je contrôle la page publique, en français et en anglais : réponse 200, image, intertitres, sources. J'ai décrit ce goulot de publication dans automatiser la publication avant de produire plus.

06Par où commencer votre migration

Si vous envisagez de migrer vers Next.js et Sanity, voici l'ordre que je suivrais lundi :

1. Écrire en une page pourquoi vous migrez. Si la raison tient en « le site est vieux », reprenez la section sur les cas où ça ne vaut pas la peine.
2. Construire la table des URL et la faire relire.
3. Modéliser les contenus dans Sanity à partir des pages réelles, pas d'une maquette idéale.
4. Écrire les redirections à partir de la table, et décider comment le cache se rafraîchit à chaque publication.
5. Faire la recette sur l'adresse de préproduction, avec la table en main ; ma checklist de recette et de mise en production peut servir de base.
6. Après la bascule, suivre les pages dans Search Console pendant plusieurs semaines. Google prévient que les classements peuvent fluctuer ; un reporting SEO automatique évite d'oublier de regarder.

Je ne promets pas qu'une migration se passe sans aucune baisse : même bien préparée, elle demande à Google de tout revoir. La préparation réduit ce qui peut casser, c'est déjà beaucoup. Si vous voulez qu'on regarde votre cas ensemble, la page services dit comment je travaille ; on peut en parler.