Checklist de lancement d'un site Next.js : SEO, mesure, formulaires et CMS
La checklist de lancement d'un site marketing Next.js : métadonnées, sitemap, robots.txt, données structurées, mesure d'audience, formulaires, images, accessibilité et CMS.
Un lancement échoue rarement à cause du design. Il échoue parce qu'un formulaire tombe en panne en silence, qu'une URL canonique pointe encore vers l'environnement de test, que les données de mesure ne partent jamais, ou que le sitemap oublie la moitié des pages. Ce sont ces pannes qui font perdre des opportunités commerciales sans bruit, et elles s'évitent toutes avec une checklist que l'on déroule réellement.
Nous livrons des sites marketing Next.js en une semaine, et la dernière journée n'a rien d'une formalité. C'est le moment où l'on confirme que le système d'acquisition fonctionne. Voici la séquence que nous déroulons avant d'accueillir le moindre visiteur.
Commencer par la passe sur les métadonnées
Parcourez chaque page et vérifiez le titre, la description, l'URL canonique et les balises Open Graph et Twitter. Avec l'App Router, cela signifie contrôler ce que produit generateMetadata pour chaque page, et non supposer qu'une valeur par défaut définie au niveau de la mise en page couvre tout. Les titres en double sont l'oubli le plus fréquent, suivis des URL canoniques qui pointent encore vers un domaine de prévisualisation.
Vérifiez aussi que les images Open Graph s'affichent aux bonnes dimensions : un aperçu de partage cassé sabote chaque lien publié le jour du lancement.
Confirmer que le site est explorable et complet
Générez le fichier sitemap.xml à partir de votre liste de pages réelle, plutôt que de maintenir à la main un fichier qui finira par diverger. Vérifiez que le fichier robots.txt autorise bien l'exploration en production : un robots.txt hérité de l'environnement de test, qui bloque tout, est un classique. Soumettez ensuite le sitemap dans Search Console une fois le domaine de production en place.
Le bon moment pour le sitemap : après la bascule
Soumettez le sitemap après que le domaine de production sert la nouvelle version du site et que les redirections répondent correctement. Le soumettre depuis l'environnement de test, ou en pleine bascule, revient à faire indexer des URL qui ne correspondent pas à votre plan d'URL canoniques. Vérifiez que l'ensemble des pages indexées correspond bien à ce que vous voulez voir en canonique.
Vérifier chaque parcours de conversion
Envoyez chaque formulaire de bout en bout et confirmez que le contact arrive dans la bonne boîte mail ou dans le CRM en moins d'une minute. Testez sur un vrai mobile et sur ordinateur, avec des données réalistes. Vérifiez les courriers indésirables et toute automatisation du CRM qui pourrait écarter un envoi de test en silence. Cliquez sur chaque lien téléphonique et chaque lien mail. Un formulaire de contact qui échoue en silence peut passer inaperçu pendant des semaines : nous avons débogué exactement ce cas plus d'une fois.
Prouver que les données de mesure partent vraiment
Ne partez pas du principe que GA4 est « installé ». Déclenchez une page vue, un clic sur votre bouton d'action principal et un envoi de formulaire, puis regardez-les arriver dans le rapport temps réel. Pour ne pas polluer les chiffres de production, utilisez le DebugView avec le paramètre de débogage, ou une propriété distincte pour l'environnement de test. Confirmez trois à cinq événements utiles avant de lancer du trafic payant.
Contrôler la performance sur un vrai téléphone
Faites les contrôles sur mobile et corrigez les problèmes évidents : images d'en-tête surdimensionnées, décalages de mise en page dus à des polices chargées tardivement ou à des images sans dimensions, scripts bloquants. Next.js fournit l'optimisation des images ; assurez-vous qu'elle est bien utilisée. Ce sont les Core Web Vitals sur mobile, et non sur ordinateur, que vivent la plupart de vos acheteurs.
La publication via le CMS a ses propres vérifications
Un site rapide ne sert à rien si la chaîne de publication est cassée. Confirmez que les éditeurs peuvent publier, que les aperçus correspondent à la production, que les webhooks déclenchent bien la régénération ou la revalidation ISR, et que les brouillons ne sont pas indexés. Nous avons vu des lancements techniquement parfaits où le premier éditeur venu était incapable de mettre un article en ligne.
La checklist du lancement en un coup d'œil
| Domaine | Ce qui doit être validé |
|---|---|
| Métadonnées | Des titres uniques, des URL canoniques correctes, des images Open Graph valides |
| Exploration | Le fichier sitemap.xml est soumis et robots.txt autorise la production |
| Conversions | Chaque formulaire arrive dans la boîte mail ou le CRM |
| Mesure d'audience | Les pages vues, clics et envois de formulaire apparaissent en temps réel |
| Performance | Les Core Web Vitals mobiles sont bons et les images optimisées |
| CMS | La publication, l'aperçu et les webhooks fonctionnent, aucun brouillon n'est indexé |
Et ensuite ?
Bloquez une heure pour cette passe de vérification avant la bascule, et désignez un responsable capable de corriger vite pendant la première heure de trafic. Metamatter déroule l'intégralité de ces tests avant mise en ligne dans chaque sprint, pour que l'oubli ne se découvre pas dans une chute de courbe Search Console.
Construire une procédure de lancement réutilisable
Déroulez cette checklist une fois et vous voudrez la garder. Chaque futur lancement et chaque mise à jour majeure bénéficient de la même passe de vérification. Transformez-la en procédure que l'équipe peut suivre sans vous : un document partagé listant chaque contrôle, son responsable et une case validé ou échoué. Ajoutez-y les événements GA4 attendus, le plan d'URL canoniques visé et la liste des formulaires avec leur boîte mail de destination. C'est au premier lancement qu'une lacune coûte le plus cher ; c'est au deuxième que la procédure vous rembourse. Nous conservons une version modèle pour chaque client, afin que les vérifications qui ont protégé le lancement protègent aussi le déploiement suivant. Une checklist que l'on rejoue vaut dix checklists écrites une fois puis perdues dans un fil Slack.
FAQ
Qu'est-ce qui casse le plus souvent au lancement d'un site Next.js ?
Des formulaires qui n'acheminent pas les messages, des URL canoniques manquantes ou fausses, des événements de mesure qui ne partent jamais et des sitemaps incomplets. Le design fait rarement perdre du chiffre d'affaires le premier jour ; les parcours d'acquisition cassés, si.
Faut-il soumettre le sitemap avant ou après la bascule DNS ?
Après, une fois que le domaine de production sert bien le nouveau site. Soumettez-le dans Search Console quand les redirections fonctionnent et que le fichier robots.txt autorise l'exploration. Vérifiez ensuite que les URL indexées correspondent à votre plan d'URL canoniques.
Comment tester les événements GA4 sans polluer les données de production ?
Utilisez le DebugView de GA4 avec le paramètre de débogage, ou une propriété GA4 distincte pour l'environnement de test. Au minimum, vérifiez en temps réel la page vue, l'envoi de formulaire et le clic sur le bouton d'action principal avant de lancer du trafic payant.
La publication via le CMS mérite-t-elle ses propres vérifications ?
Oui. Les éditeurs doivent pouvoir publier, les aperçus doivent correspondre à la production, les webhooks doivent déclencher la régénération ou l'ISR, et les brouillons ne doivent pas être indexés. Un site rapide ne sert à rien si la chaîne de publication est cassée.
