𝟯 vérifications post-déploiement que j'effectue après chaque build Cloudflare Pages

J'ai passé deux semaines à déboguer des problèmes qui n'apparaissaient qu'en production.

Une règle bloquait mon sitemap. Un autre problème concernait une condition de concurrence lors du téléchargement d'images. Ces erreurs m'ont coûté du temps.

Désormais, j'effectue trois vérifications spécifiques après chaque déploiement Cloudflare Pages. J'utilise Astro 5 SSG sur trois sites : aiappdex.com, findindiegame.com et ossfind.com.

Ces vérifications se concentrent sur des échecs réels auxquels j'ai été confronté.

  1. Vérification du sitemap

Je vérifie si sitemap-index.xml renvoie un code d'état 200 sur tous les domaines.

Je vérifie également sitemap-0.xml. Je m'assure qu'il contient un nombre minimum d'URL. Pour aiappdex.com, ce nombre est de 1 000. Si le décompte chute, cela signifie que mon pipeline de données a échoué.

Une mauvaise règle de redirection a un jour caché mon sitemap aux robots d'indexation pendant cinq jours. Tout semblait correct dans un navigateur, mais le test curl a échoué. Cette vérification permet de détecter ces erreurs immédiatement.

  1. Soumission IndexNow

Après la vérification du sitemap, j'exécute un script pour soumettre les URL à IndexNow. Cela informe Bing, Yandex, Naver et Seznam de la présence de nouveaux contenus.

Si IndexNow renvoie une erreur 403, mon fichier de vérification de clé est manquant ou une règle de redirection est défectueuse. Détecter cela tôt permet d'éviter les retards d'indexation.

J'exécute cela manuellement après le déploiement. Cela garantit que je ne soumets que des URL qui sont en ligne et stables.

  1. Audits Lighthouse hebdomadaires

J'effectue un contrôle Lighthouse tous les lundis à 04h30 UTC. Je vérifie une page d'accueil et une page profonde par site.

Je surveille trois métriques :

  • Performance (Cible : supérieure à 80)
  • CLS (Cible : inférieure à 0,1)
  • Scores d'accessibilité

J'utilise Lighthouse comme outil de suivi des tendances. Je ne bloque pas les builds si un score chute légèrement. J'utilise ces résultats pour repérer des régressions dans ma configuration Tailwind ou dans mes composants de mise en page.

Je n'utilise pas de surveillance de la disponibilité ni de tests de bout en bout. Ces sites sont statiques. Mon environnement d'exécution complet est constitué de HTML et CSS pré-construits. Ces trois vérifications couvrent mes risques réels.

Source : https://dev.to/morinaga/three-post-deploy-checks-i-run-after-every-cloudflare-pages-build-3fi0