3 בדיקות פוסט-פריסה (Post-Deploy) שאני מריץ אחרי בניית Cloudflare Pages
ביליתי שבועיים בפתרון באגים (debugging) בבעיות פרודקשן.
כלל הפניה (redirect) של ה-sitemap חסם את קבצי ה-sitemap שלי. העלאת תמונה נכשלה בגלל עיכוב בפריסה (deployment lag). הטעויות האלו עלו לי בזמן.
עכשיו, אני משתמש בשלוש בדיקות ספציפיות אחרי כל פריסה ב-Cloudflare Pages. אני לא משתמש בחבילת בדיקות (test suite) מלאה. אני משתמש בשלוש הבדיקות המהירות האלו כדי לתפוס את השגיאות שאני באמת נתקל בהן.
אני מריץ אותן על שלושה אתרים שנבנו עם Astro 5 SSG.
1. אימות sitemap
אני בודק אם sitemap-index.xml מחזיר קוד סטטוס 200 בכל הדומיינים. אני בודק גם את sitemap-0.xml.
אני מוודא שמספר ה-URLs עומד בסף מינימלי. לדוגמה, ל-aiappdex.com חייב להיות לפחות 1,000 URLs. אם המספר יורד, זה אומר שצינור הנתונים (data pipeline) שלי נכשל.
אני משתמש ב-curl ללא מעקב אחרי הפניות (redirects). זה עוזר לי לתפוס כללי הפניה שבורים שמסתירים שגיאות מהדפדפנים.
2. שליחה ל-IndexNow
אחרי בדיקת ה-sitemap, אני מריץ סקריפט ששולח URLs ל-IndexNow עבור Bing, Yandex, Naver ו-Seznam.
הסקריפט קורא את ה-sitemap החי ושולח את ה-URLs. אם IndexNow מחזיר שגיאת 403, זה אומר שקובץ אימות המפתח שלי חסר או שכלל הפניה שבור.
אני מריץ את זה ידנית אחרי הפריסה. זה מבטיח שאני שולח URLs שהם חיים ויציבים.
3. ניטור ביצועים ב-Lighthouse
אני מריץ את הבדיקה הזו כ-cron job שבועי במקום אחרי כל פריסה. זה עוקב אחר מגמות ביצועים.
אני עוקב אחר:
- ציוני ביצועים מתחת ל-80
- CLS מעל 0.1
- נסיגות (regressions) בנגישות
מכיוון שהאתרים שלי משתמשים ב-Astro SSG ללא JS בצד הלקוח (client-side), הציונים האלו אמורים להישאר יציבים. אם הם יורדים, סביר להניח ששינוי ב-CSS שבר את הפריסה (layout). אני מתייחס לציונים האלו כאל ניטור מגמות, ולא כדרך לחסום פריסות.
סיכום
אני לא משתמש בניטור uptime או בבדיקות משתמש מקצה לקצה (end-to-end). עבור פריסת CDN סטטית, שלוש הבדיקות האלו מכסות את הסיכונים העיקריים שלי. הן מגנות על ה-SEO ועל שלמות הפריסה (layout integrity) שלי מבלי להוסיף מורכבות מיותרת.
מקור: https://dev.to/morinaga/three-post-deploy-checks-i-run-after-every-cloudflare-pages-build-48b4