٣ فحوصات ما بعد النشر أقوم بها بعد كل عملية بناء في Cloudflare Pages
قضيت أسبوعين في إصلاح أخطاء لم تظهر إلا في بيئة الإنتاج.
تسببت قاعدة redirects واحدة في حظر خريطة الموقع (sitemap) الخاصة بي. كما تسببت حالة تسابق (race condition) بين رفع الصور ونشر Cloudflare في مشكلة أخرى.
الآن، أقوم بإجراء ثلاثة فحوصات محددة بعد كل عملية نشر. هذه ليست اختبارات كاملة، بل هي لحل المشكلات الدقيقة التي أواجهها مع مواقع Astro 5 SSG الخاصة بي.
الفحص ١: توفر خريطة الموقع (Sitemap Availability)
أتحقق من أن sitemap-index.xml يعيد حالة 200 على جميع النطاقات.
أتحقق أيضاً من sitemap-0.xml. يحتوي هذا الملف على الروابط (URLs) الفعلية. أتأكد من أن عدد الروابط يظل فوق رقم معين. في أحد المواقع، إذا انخفض العدد عن ١,٠٠٠، أعرف أن خط أنابيب البيانات (data pipeline) قد فشل.
أستخدم curl للتحقق من ذلك. أنا لا أتتبع عمليات إعادة التوجيه (redirects). يساعدني هذا في اكتشاف قواعد إعادة التوجيه المعطلة التي تبدو سليمة في المتصفح ولكنها تحظر برامج الزحف (crawlers).
الفحص ٢: إرسال IndexNow
بعد فحص خريطة الموقع، أقوم بتشغيل سكربت لإرسال الروابط إلى IndexNow. هذا يخطّر Bing وYandex وNaver وSeznam بالمحتوى الجديد.
إذا أعاد IndexNow خطأ 403، فهذا يعني أن ملف التحقق من المفتاح (key verification file) قد فشل في النشر. اكتشاف هذا فوراً يمنع التأخير في فهرسة محركات البحث.
أقوم بتشغيل هذا يدوياً بعد كل عملية نشر. أفعل ذلك لضمان أنني لا أرسل إلا الروابط المباشرة والمستقرة.
الفحص ٣: اتجاهات Lighthouse
أقوم بإجراء فحص Lighthouse وفق جدول زمني، وليس بعد كل عملية نشر.
أراقب ثلاثة مقاييس:
- الأداء (Performance) (أبحث عن الدرجات التي تقل عن 80)
- CLS (أبحث عن الدرجات التي تزيد عن 0.1)
- درجات إمكانية الوصول (Accessibility scores)
بما أن مواقعي تستخدم HTML وCSS ثابتين، يجب أن تظل هذه الدرجات مستقرة. إذا انخفضت، فمن المرجح أن تغييراً في إعدادات Tailwind أو في أحد المكونات قد أدى إلى كسر التنسيق (layout).
لا أستخدم هذه الدرجات لمنع عمليات النشر، بل أستخدمها لمراقبة الاتجاهات.
لماذا هذه الفحوصات الثلاثة؟
أنا لا أستخدم أدوات مراقبة وقت التشغيل (uptime monitors) أو اختبارات المستخدم الشاملة (end-to-end user tests). مواقعي هي عمليات نشر ثابتة على CDN. يتم الاستعلام من قاعدة البيانات فقط في وقت البناء (build time).
تغطي هذه الفحوصات الثلاثة المخاطر الحقيقية الوحيدة التي أواجهها مع هذا الإعداد.
المصدر: https://dev.to/morinaga/three-post-deploy-checks-i-run-after-every-cloudflare-pages-build-70b