𝟯 Controlli Post-Deployment che Eseguo dopo Ogni Build di Cloudflare Pages
Ho passato due settimane a correggere bug in produzione. Una regola di reindirizzamento errata ha bloccato la mia sitemap. Il caricamento di un'immagine è fallito a causa del ritardo nel deployment.
Ora eseguo tre controlli specifici dopo ogni build di Cloudflare Pages. Non utilizzo una suite di test completa. Uso controlli rapidi che mirano ai miei reali punti di fallimento.
Utilizzo Astro 5 SSG su tre siti: aiappdex.com, findindiegame.com e ossfind.com.
Ecco i tre controlli:
- Verifica della sitemap Verifico che sitemap-index.xml restituisca uno stato 200 su tutti i domini. Controllo anche sitemap-0.xml. Mi assicuro che il conteggio degli URL rimanga al di sopra di una soglia prestabilita. Per aiappdex.com, mi aspetto almeno 1.000 URL. Se il conteggio scende, significa che la mia pipeline di dati si è interrotta.
Uso curl senza seguire i reindirizzamenti. Questo permette di individuare errori in cui una regola di reindirizzamento fa apparire la sitemap corretta in un browser, ma la blocca per i crawler.
- Invio a IndexNow Dopo il superamento dei controlli della sitemap, eseguo uno script per inviare gli URL a IndexNow. Questo notifica Bing, Yandex, Naver e Seznam riguardo ai nuovi contenuti.
Eseguo questa operazione manualmente dopo il deployment. Ciò garantisce che io invii URL che sono effettivamente online. Se IndexNow restituisce un errore 403, so che il mio file di verifica della chiave è mancante o che una regola di reindirizzamento è errata. Individuare il problema precocemente evita ritardi nell'indicizzazione.
- Audit settimanali con Lighthouse Eseguo un controllo Lighthouse ogni lunedì alle 04:30 UTC. Controllo una homepage e una pagina interna per ogni sito.
Monitoro queste metriche:
- Performance inferiori a 80
- CLS superiore a 0,1
- Calo del punteggio di accessibilità
Poiché i miei siti utilizzano HTML e CSS statici, i punteggi dovrebbero rimanere stabili. Se calano, è probabile che un recente cambiamento in Tailwind o in un componente abbia rotto il layout. Uso questi risultati per monitorare i trend piuttosto che per bloccare le build.
Non monitoro l'uptime o la disponibilità delle API. I miei siti sono statici. Il database viene eseguito solo al momento della build. Per un deployment su CDN statica, questi tre controlli coprono i miei rischi principali.
Fonte: https://dev.to/morinaga/three-post-deploy-checks-i-run-after-every-cloudflare-pages-build-39h6