Ce qui se passe probablement
La requête Sanity reste mise en cache dans App Router
Selon la configuration de la récupération des données et de la route, Next.js peut continuer à utiliser une réponse antérieure jusqu’à une nouvelle génération ou une révalidation explicite.
La page statique ou ISR n’est pas révalidée
Le document Sanity est à jour, mais la sortie générée par Next.js reste inchangée parce que le mécanisme de révalidation prévu pour cette route ne s’exécute pas ou ne cible pas la bonne ressource.
Le webhook Sanity ne déclenche pas l’invalidation attendue
Le webhook peut être absent, échouer, appeler un mauvais environnement ou transmettre une information qui ne correspond pas au chemin ou à l’étiquette utilisés par Next.js.
L’invalidation ne couvre qu’une partie des pages dépendantes
Un document Sanity peut être repris sur une page principale, une liste et plusieurs contenus liés. Révalider une seule route laisse les autres versions générées avec des données anciennes.
La production n’interroge pas la version Sanity attendue
Les paramètres ou la requête utilisés en production peuvent différer de ceux testés dans l’éditeur ou en local. Next.js reçoit alors une autre représentation du contenu que celle prise comme référence.
Une couche Vercel, navigateur ou client conserve l’ancienne réponse
Même si la donnée Sanity et le rendu serveur sont corrects, une réponse déjà conservée par la couche de diffusion, le navigateur ou la navigation App Router peut entretenir le symptôme.
Cas que l'on retrouve sur des comptes réels
Compare chaque scénario au comportement observé dans SEO technique, GEO et performance web et conserve une preuve vérifiable avant de retenir la cause.
Sanity est à jour, mais le HTML Next.js reste ancien
Le champ modifié apparaît bien dans le document publié et dans la réponse Sanity, tandis que le HTML Next.js conserve l’ancienne valeur. Ce cas oriente le diagnostic vers la mise en cache de la requête, la génération statique ou la révalidation de la route.
Next.js est à jour localement, mais Vercel sert l’ancienne version
La même requête Sanity affiche le nouveau contenu dans l’environnement local, alors que la page déployée sur Vercel reste obsolète. Cet écart rend prioritaire la vérification de la configuration de production, de la génération de la route et du cache de diffusion.
Une route Next.js actualise Sanity, une autre reste obsolète
Un même document Sanity peut alimenter plusieurs pages Next.js. Si une route se met à jour et qu’une autre conserve l’ancien contenu, l’invalidation par chemin, étiquette ou dépendance ne couvre probablement pas toutes les pages concernées.
La page Vercel est à jour, mais Google montre encore l’ancien contenu
Lorsque le HTML servi par Vercel contient déjà la nouvelle version Sanity, un ancien titre ou extrait dans Google ne prouve pas que le cache Next.js est bloqué. Il faut alors distinguer la version publique actuelle de celle que le moteur a explorée ou indexée.
Comment vérifier sans casser la configuration
Identifiez la page Next.js, le document Sanity, le champ modifié, l’environnement concerné et l’heure précise de la publication.
Vérifiez dans Sanity que la modification appartient bien à la version publiée utilisée par le site, et pas seulement à une version de travail.
Exécutez la même requête Sanity que celle de la production et comparez sa réponse avec la valeur attendue.
Inspectez le HTML initial renvoyé par la route Next.js, sans vous limiter au contenu visible après l’exécution du JavaScript.
Relevez la configuration de cache, de génération statique et de révalidation appliquée à la route et aux requêtes Sanity associées.
Contrôlez que le webhook Sanity est bien exécuté après publication, qu’il atteint le bon environnement et qu’il cible le chemin ou l’étiquette approprié.
Comparez la réponse obtenue en local avec celle du déploiement Vercel afin d’isoler une différence de configuration de production.
Testez un chargement direct, une navigation via App Router, une actualisation complète et une session sans cache pour repérer une version conservée côté client.
Recensez toutes les routes Next.js qui dépendent du même document Sanity et vérifiez leur mise à jour séparément.
Si le HTML public est à jour, comparez-le à la version observée par Google ou Bing avant d’attribuer le décalage au cache Vercel.
Signaux qui décident la prochaine action
Ces signaux séparent le symptôme visible, le premier passage cassé et le résultat final à valider dans SEO technique, GEO et performance web.
Valeur et heure de publication dans Sanity
La valeur exacte du champ Sanity et l’heure de sa dernière modification publiée constituent le point de référence. Elles permettent de vérifier que le changement existe bien dans la version destinée à la production.
Réponse Sanity comparée au HTML Next.js
Comparer la réponse de la requête Sanity avec le HTML généré par Next.js localise la rupture. Une API à jour avec un HTML ancien désigne la couche de rendu ou de cache, plutôt qu’un problème éditorial.
Comportement du cache App Router et de Vercel
Les en-têtes de réponse, le mode de génération de la route et le comportement observé après actualisation indiquent si Next.js ou Vercel continue de servir le contenu Sanity obsolète.
Exécution de la révalidation après publication Sanity
La trace du webhook Sanity, sa réponse et la route ou l’étiquette qu’il doit invalider montrent si la publication déclenche réellement la révalidation attendue dans Next.js et Vercel.
Comment je le résoudrais étape par étape
Établir une chaîne de comparaison reproductible
Consignez la valeur du document Sanity, la réponse de la requête, le HTML Next.js et la page Vercel pour un même champ. Cette séquence montre exactement où l’ancienne version réapparaît.
Aligner la stratégie de cache sur la fraîcheur attendue
Ajustez la configuration de récupération des données, de génération et de révalidation de la route concernée. L’objectif n’est pas de supprimer tous les caches, mais d’éviter qu’une page éditoriale reste figée après une publication Sanity.
Relier la publication Sanity à une invalidation précise
Vérifiez que le webhook appelle le bon environnement et invalide les chemins ou étiquettes réellement utilisés par Next.js. Contrôlez ensuite son exécution avec une nouvelle modification identifiable.
Couvrir toutes les routes dépendantes du document
Répertoriez les pages, listes et blocs qui réutilisent le contenu Sanity. Étendez la révalidation aux sorties concernées plutôt que de corriger uniquement l’URL où le problème a été remarqué.
Valider la correction sur la version publique
Après la modification, comparez de nouveau Sanity, la requête, le HTML Next.js et la réponse Vercel. Si ces couches concordent, traitez séparément un éventuel retard d’exploration ou d’indexation.
Si cela devient technique
Tu peux suivre cette démarche seul. Si le diagnostic de SEO technique, GEO et performance web révèle un écart entre systèmes, une implémentation délicate ou un blocage qui exige plus de contexte, Lia conserve les vérifications et les transmet à CreatikLab sans repartir de zéro.
Ce que je ne ferais pas
Republier plusieurs fois le document Sanity sans vérifier quelle couche conserve réellement l’ancienne valeur.
Désactiver globalement le cache Next.js comme première réponse, sans distinguer la requête, la route et la couche Vercel.
Considérer qu’un résultat correct en local prouve que le déploiement Vercel utilise la même configuration.
Redéployer le site, voir le contenu revenir, puis conclure que le mécanisme de révalidation fonctionne durablement.
Révalider une seule URL alors que le même document Sanity alimente plusieurs routes Next.js.
Confondre un ancien extrait dans Google avec une page encore obsolète sur Vercel, sans contrôler le HTML public.
Questions fréquentes
La publication dans Sanity invalide-t-elle automatiquement le cache Next.js ou Vercel ?
Pas dans toutes les architectures. La publication doit être reliée au mécanisme de fraîcheur prévu par l’application, par exemple une révalidation configurée pour les routes ou données concernées. Il faut vérifier cette chaîne dans le déploiement réel.
Faut-il redéployer Next.js pour afficher le nouveau contenu Sanity ?
Pas nécessairement. Une route correctement configurée pour se réactualiser peut recevoir le nouveau contenu sans reconstruction complète. Un redéploiement peut aider à isoler le cache, mais il ne remplace pas une révalidation fiable.
Comment savoir si le problème vient de Sanity, de Next.js ou de Vercel ?
Comparez successivement le document publié, la réponse de la requête Sanity, le HTML généré par Next.js et la réponse publique Vercel. La première version qui diffère de la précédente désigne la couche à examiner.
Pourquoi certaines pages Next.js se mettent-elles à jour et pas les autres ?
Les routes peuvent utiliser des requêtes, des dépendances ou des règles de révalidation différentes. Une invalidation limitée à un chemin ne met pas nécessairement à jour toutes les pages qui réutilisent le même document Sanity.
Pourquoi Google affiche-t-il encore l’ancien texte alors que Vercel est à jour ?
Si le HTML public contient déjà la nouvelle version, le cache applicatif n’est plus le principal suspect. Il faut alors vérifier la version récemment explorée ou indexée par le moteur, sans modifier de nouveau le contenu Sanity.
Quand utiliser Lia pour poursuivre ce diagnostic ?
Lia peut vous guider lorsque les versions Sanity, Next.js et Vercel se contredisent ou lorsque la révalidation semble réussir sans actualiser toutes les routes. Préparez l’URL, le champ modifié, l’heure de publication et les résultats de chaque comparaison.
