HTTPS مفعّل، فلماذا لا يزال المتصفح يعتبر الموقع غير آمن؟

ثُبتت الشهادة وظهر القفل في الرئيسية، ثم تعطلت بعض تأكيدات الدفع وظهر تحذير في صفحة داخلية. بدا الموقع HTTPS، لكن صوراً وطلب API وعنوان عودة الدفع بقيت على HTTP.

تعامل مع النقل كثلاث طبقات: الشهادة والخادم، موارد الصفحة، ثم إشارات canonical وsitemap والروابط. نجاح طبقة لا يثبت سلامة البقية.

حدّد نوع الخطأ أولاً

افحص الانتهاء واسم النطاق وسلسلة الشهادة، ثم راقب Console وNetwork بحثاً عن موارد HTTP. تجديد الشهادة لا يصلح المحتوى المختلط؛ يجب تعديل عنوان المورد.

في WordPress قد تحتفظ الإعدادات والمحتوى القديم وCSS المولد وذاكرة CDN بالرابط السابق. الاستبدال الأعمى في القاعدة قد يفسد البيانات المتسلسلة.

اختر وجهة نهائية واحدة

يجب أن تصل نسخ HTTP وHTTPS وwww وبدون www إلى المضيف المختار بخطوة واحدة. السلاسل تبطئ وتربك canonical.

ينبغي أن تستخدم الروابط الداخلية وخريطة الموقع وcanonical عناوين HTTPS. التحويل يجمع الزيارات القديمة لكنه لا ينظف البنية الداخلية.

اختبر المسارات الحساسة منفصلة

قد تملك صفحات الدخول والنماذج والرفع وAPI والويب هوك وعودة الدفع قواعد خاصة. اختبرها بالسجلات ومتصفح حقيقي بعد فرض HTTPS.

فعّل HSTS فقط بعد التأكد من سلامة HTTPS لكل نطاق فرعي مشمول؛ التراجع عن سياسة متسرعة ليس سهلاً.

الفحص النهائي

• الشهادة والاسم والسلسلة صالحة.
• لا توجد طلبات HTTP في الصفحات المهمة.
• كل نسخة نطاق تصل بخطوة واحدة.
• canonical وخريطة الموقع يستخدمان HTTPS.
• نجحت اختبارات الدخول وAPI والدفع.

مرجع رسمي: إرشادات Google لنقل عناوين URL