Liste de vérification de lancement de site

Une liste de vérification de lancement de site est un contrôle QA pré-mise en ligne de l’exploration, des redirections, de la performance, de l’analytique, de l’accessibilité, des métadonnées et des données structurées. Elle réduit le risque qu’un lancement visuellement terminé parte en production avec des problèmes de mesure ou de visibilité.

Indexation et exploration

• Retirer les directives noindex de préproduction et la protection par mot de passe. C’est l’erreur de lancement la plus coûteuse, parce qu’aucune vérification visuelle ne la révèle. Un noindex oublié garde les pages hors de l’index jusqu’à son retrait et un nouveau passage des robots, ce qui peut prendre des semaines sur un site à faible autorité.
• Vérifier que le robots.txt et le sitemap XML sont corrects et soumis. Un Disallow: / de préproduction expédié en production bloque toute exploration. Le sitemap ne doit lister que des URL canoniques — ni redirections, ni pages en noindex — car un sitemap rempli d’URL non indexables ralentit la découverte de celles qui comptent.
• Définir les URL canoniques et résoudre les chemins en double. Choisissez une seule forme pour la barre oblique finale, les majuscules, le www et le protocole, puis redirigez le reste au lieu de le canoniser. Les paramètres de campagne et de filtre sont la source habituelle de doublons imprévus.
• Cartographier et tester les redirections 301 depuis les anciennes URL. Redirigez vers la page équivalente la plus proche, pas vers l’accueil : une redirection vers une destination sans rapport est traitée comme un soft 404 et ne transmet rien. Testez la liste complète après le déploiement, et surveillez les chaînes — chaque saut ajoute de la latence et une chaîne trop longue peut ne pas être suivie.

Performance et Core Web Vitals

• Optimiser les images et servir des formats modernes. L’image est le plus souvent l’élément LCP. Déclarez explicitement largeur et hauteur pour que le navigateur réserve l’espace — leur absence est une cause majeure de décalage de mise en page — et préchargez l’image principale au lieu de la charger en différé.
• Vérifier LCP, CLS et INP sur des gabarits représentatifs. Les seuils sont LCP sous 2,5 s, INP sous 200 ms et CLS sous 0,1, mesurés au 75e centile. Testez une page de chaque gabarit, pas seulement l’accueil : les Core Web Vitals sont évalués par groupe d’URL, donc un accueil rapide masque un gabarit produit ou article lent.
• Confirmer le comportement de la mise en cache et du CDN en production. Les en-têtes de cache qui fonctionnaient en préproduction diffèrent souvent derrière un CDN de production. Vérifiez que le HTML n’est pas mis en cache plus longtemps que prévu et qu’une purge se propage réellement, sinon la première correction de contenu semblera sans effet.

Mesure

• Confirmer que l’analytique, le gestionnaire de balises et les conversions se déclenchent en production. Testez dans l’environnement réel, pas en mode aperçu. L’aperçu contourne le consentement, les bloqueurs de publicité et les en-têtes CSP de production — trois mécanismes qui suppriment silencieusement des balises pour une part réelle du trafic.
• Vérifier que la gestion du consentement est active et appliquée. Contrôlez l’état refusé aussi soigneusement que l’état accordé. La défaillance à détecter est une balise qui se déclenche avant le consentement : c’est un problème de conformité, pas de données.
• Concilier les conversions clés avec les systèmes sources. Comparez une journée de conversions analytiques au CRM ou au système de commandes. Un écart inférieur à environ 5 % correspond à l’attrition normale due aux bloqueurs et au consentement ; un écart plus grand ou unidirectionnel signale une anomalie. Faites-le avant que quiconque publie un rapport, pas après.

Contenu et accessibilité

• Valider les titres, méta-descriptions et données structurées. Cherchez les valeurs par défaut des gabarits qui ont survécu : titres dupliqués et descriptions restées à l’état d’espace réservé. Validez les données structurées avec le test des résultats enrichis, et assurez-vous qu’elles décrivent ce que la page montre réellement.
• Vérifier les titres, le texte alternatif et la navigation au clavier. Un seul H1 par page dans un ordre logique, un texte alternatif qui transmet la fonction plutôt que le nom de fichier, et chaque élément interactif accessible au clavier avec un focus visible.
• Tester les formulaires, les états d’erreur et les pages de confirmation. Testez les chemins d’échec : soumission invalide, doublon, expiration. Les états d’erreur sont la partie la moins testée d’un lancement et la plus susceptible de perdre une conversion sans le signaler.

Surveillance après lancement

• Surveiller la Search Console pour les erreurs d’exploration et d’indexation. Attendez-vous à des variations de positions pendant quelques semaines après un changement d’URL : c’est le réexploration et le retraitement, pas nécessairement un problème. Ce qui mérite une action, c’est la hausse des pages exclues comme explorées-non-indexées ou découvertes-non-indexées.
• Suivre la disponibilité, les 404 et les chaînes de redirection. Surveillez les référents des 404 pour repérer les liens entrants qui pointent vers des URL oubliées par le plan de redirection : ce sont celles qui coûtent du trafic.
• Revérifier les Core Web Vitals avec des données terrain après quelques semaines. Les outils de laboratoire mesurent une exécution sur une connexion. Les données terrain reflètent les appareils et réseaux réels, et le rapport d’expérience utilisateur Chrome demande environ 28 jours de collecte avant que les chiffres post-lancement aient un sens.

Si un lancement fait partie d’un changement de plateforme, le guide de décision sur le CMS headless ci-dessous couvre les compromis d’architecture.