٣ فحوصات ما بعد النشر أقوم بها بعد كل عملية بناء في Cloudflare Pages

قضيت أسبوعين في تصحيح أخطاء مشاكل الإنتاج. تسببت إحدى قواعد إعادة التوجيه الخاصة بملف sitemap في حظر فهرس sitemap الخاص بي. وتعلقت مشكلة أخرى بتأخر رفع الصور.

أنا لا أستخدم مجموعات اختبار شاملة (end-to-end). بدلاً من ذلك، أستخدم ثلاثة فحوصات محددة تركز على أنماط الفشل التي أواجهها بالفعل.

أقوم بتشغيل هذه الفحوصات على ثلاثة مواقع تعمل بتقنية Astro 5: aiappdex.com، و findindiegame.com، و ossfind.com.

١. التحقق من ملف Sitemap

أتحقق مما إذا كان sitemap-index.xml يعيد رمز الحالة 200 في جميع النطاقات.

كما أتحقق من sitemap-0.xml؛ حيث أتأكد من أنه يحتوي على الحد الأدنى من الروابط (URLs). بالنسبة لموقع aiappdex.com، هذا العدد هو 1,000. إذا انخفض العدد، فهذا يعني أن خط معالجة البيانات (data pipeline) الخاص بي قد فشل.

لقد تعلمت هذا بالطريقة الصعبة؛ حيث تسببت قاعدة إعادة توجيه ذات مرة في تعطل ملف sitemap الخاص بي لمدة خمسة أيام. كان يبدو سليماً في المتصفح ولكنه فشل بالنسبة لمحركات الزحف (crawlers). يساعد استخدام curl في اكتشاف ذلك على الفور.

٢. الإرسال عبر IndexNow

بعد التحقق من ملف sitemap، أقوم بتشغيل سكربت لإرسال الروابط إلى IndexNow. هذا يخطّر Bing و Yandex و Naver و Seznam بالمحتوى الجديد.

إذا أعاد الموقع خطأ 403، فهذا يعني أن ملف التحقق مفقود أو أن قاعدة إعادة التوجيه معطلة. أقوم باكتشاف ذلك مباشرة بعد النشر لتجنب تأخير الفهرسة.

أقوم بتشغيل هذا يدوياً بعد النشر، مما يضمن إرسال الروابط التي تعمل بالفعل على الـ CDN.

٣. عمليات تدقيق Lighthouse الأسبوعية

أقوم بإجراء تدقيق مجدول كل يوم اثنين. يستغرق هذا الفحص بضع دقائق لكل موقع.

أراقب ثلاثة مقاييس:

  • درجات الأداء (Performance) أقل من 80
  • CLS أعلى من 0.1
  • تراجع درجات إمكانية الوصول (Accessibility)

أستخدم هذه النتائج لمراقبة الاتجاهات. أنا لا أمنع عمليات النشر إذا انخفضت الدرجة قليلاً. بالنسبة للمواقع الثابتة (static sites)، تغطي هذه الفحوصات الثلاثة مخاطري الرئيسية.

أنا لا أستخدم مراقبة وقت التشغيل (uptime monitoring) أو فحوصات API. مواقعي ثابتة، وكل شيء يتم بناؤه مسبقاً. تحمي هذه الفحوصات أجزاء التقنيات (stack) الخاصة بي التي تتغير بالفعل.

المصدر: https://dev.to/morinaga/three-post-deploy-checks-i-run-after-every-cloudflare-pages-build-408k