Sudah Pasang SSL tapi Browser Masih "Not Secure": Cara Melacak Mixed Content di WordPress

Sertifikat SSL sudah terpasang, statusnya valid, tapi browser tetap menulis "Not secure" di address bar — dan beberapa gambar atau ikon malah hilang setelah situs dipindah ke HTTPS. Penyebabnya hampir selalu sama: halaman dimuat lewat HTTPS, tapi di dalamnya masih ada aset yang dipanggil lewat http://. Itu yang disebut mixed content.

Kenapa browser rewel soal ini

Kalau halaman HTTPS memuat file lewat HTTP biasa, jaminan keamanannya bocor: file itu bisa dibaca atau diubah di tengah jalan, padahal pengunjung melihat situs Anda seolah-olah aman seluruhnya.

Dokumentasi MDN membagi mixed content jadi dua kategori:

• Upgradable content — permintaan yang seharusnya otomatis di-upgrade browser dari http:// ke https://.
• Blockable content — permintaan yang diblokir browser, tidak dimuat sama sekali.

Istilah lama "passive/active content" yang masih sering Anda temui di blog-blog lawas sudah ditinggalkan MDN; kalau ingin memeriksa perilaku satu elemen tertentu, lihat tabel upgradable vs blockable di dokumentasi MDN, bukan artikel pihak ketiga.

Efek praktisnya untuk Anda: aset yang diblokir membuat gambar, ikon font, atau script hilang; aset yang ter-upgrade mungkin tetap tampil, tapi gagal dimuat kalau server asal tidak melayani HTTPS. Keduanya bisa bikin indikator gembok hilang.

Satu lagi yang jarang disadari: mixed download, yaitu tautan unduhan (PDF, ZIP, invoice) yang dimulai dari halaman aman tapi file-nya diambil lewat koneksi tidak aman. Risikonya sama — file terlihat berasal dari situs yang aman padahal tidak.

Langkah 1: pastikan dulu sertifikatnya memang menutup domain yang dipakai

Sebelum mengubah apa pun di WordPress, pastikan masalahnya benar-benar mixed content dan bukan sertifikat yang tidak mencakup hostname yang diakses pengunjung.

1. Login ke cPanel.
2. Buka SSL/TLS Status (ada di bagian Security; letak dan penamaan menu bisa sedikit berbeda antarversi cPanel dan antarhosting).
3. Periksa apakah domain dan varian www sama-sama tercantum sebagai terlindungi.

Kalau salah satunya belum tercakup, perbaiki itu dulu. Mengarahkan semua trafik ke HTTPS saat sertifikat belum menutup www hanya akan menghasilkan peringatan jenis lain.

Langkah 2: temukan aset yang bermasalah

Jangan menebak. Cari sumbernya satu per satu.

1. Buka halaman yang bermasalah di Chrome.
2. Tekan F12 untuk membuka DevTools, lalu pilih tab Console.
3. Muat ulang halaman dengan Ctrl+Shift+R.
4. Cari pesan yang diawali Mixed Content: The page at ... was loaded over HTTPS, but requested an insecure .... URL lengkap aset yang bermasalah ada di pesan itu — catat semuanya.

Firefox juga punya pemblokiran mixed content sendiri dan menampilkan peringatannya di Console; membuka halaman di dua browser sering membantu, karena perlakuan tiap browser terhadap jenis konten tertentu bisa berbeda.

Cara kedua yang cepat: klik kanan → View Page Source, lalu tekan Ctrl+F dan cari http://. Ini menangkap URL yang tertanam di HTML, termasuk di atribut gambar responsif yang dihasilkan WordPress — tempat yang sering terlewat kalau Anda hanya melihat gambar di layar desktop.

Ulangi di beberapa jenis halaman: beranda, satu artikel, satu halaman produk, dan halaman yang dibuat dengan page builder. Page builder biasanya menyimpan URL di dalam database dalam bentuk JSON, jadi halaman buatan builder sering masih kotor meski beranda sudah bersih.

Langkah 3: backup dulu, selalu

Langkah berikutnya menyentuh database. Sebelum itu:

1. Di cPanel, gunakan fitur backup yang tersedia untuk mengunduh salinan database (menu backup bisa berbeda nama antarversi), atau
2. Buka phpMyAdmin, pilih database situs, lalu klik tab Export dan simpan hasilnya di komputer Anda.

Simpan juga salinan file tema kalau Anda berencana menyuntingnya.

Langkah 4: bereskan URL di WordPress

a. Alamat situs. Masuk ke dashboard WordPress, buka Settings → General, dan pastikan WordPress Address (URL) serta Site Address (URL) sudah memakai https://. Simpan.

b. URL lama di dalam konten. Ini bagian terbesarnya. Konten lama menyimpan URL gambar dan tautan internal lengkap dengan http://. Jangan menjalankan UPDATE ... REPLACE() lewat phpMyAdmin: banyak data WordPress disimpan dalam bentuk terserialisasi, dan penggantian mentah bisa merusaknya.

Kalau hosting Anda menyediakan akses SSH atau Terminal di cPanel dan WP-CLI tersedia (tanyakan ke hosting Anda — ini tidak selalu aktif), jalankan uji coba dulu:

wp search-replace 'http://domainanda.com' 'https://domainanda.com' --dry-run

--dry-run hanya melaporkan berapa banyak yang akan berubah tanpa mengubah apa pun. Baca dokumentasi resmi WP-CLI untuk opsi lain yang relevan dengan kasus Anda, lalu jalankan ulang perintahnya tanpa --dry-run kalau hasilnya sudah masuk akal.

Tanpa SSH, gunakan plugin search-replace yang punya mode "dry run" dan mengerti data terserialisasi. Prinsipnya sama: jalankan simulasi dulu, periksa jumlah perubahannya, baru eksekusi.

c. URL yang di-hardcode. Cek file tema atau child theme, widget HTML kustom, dan kode iframe lama (video, peta, formulir pihak ketiga). Ganti http:// jadi https:// — atau, kalau sumbernya tidak melayani HTTPS sama sekali, unduh asetnya dan simpan di hosting Anda sendiri, atau cari penggantinya.

d. Aset dari situs lain. Gambar yang di-hotlink dari situs orang lain yang hanya punya HTTP tidak bisa Anda perbaiki dari sisi mana pun. Satu-satunya jalan: host sendiri atau hapus.

Langkah 5: arahkan trafik ke HTTPS

Setelah console bersih, barulah paksa semua kunjungan lewat HTTPS.

Di cPanel versi yang mendukungnya, buka antarmuka Domains, lalu aktifkan toggle Force HTTPS Redirect untuk domain terkait. Toggle ini hanya bisa dipakai kalau SSL yang valid sudah terpasang, dan ketersediaannya berbeda antarversi cPanel — kalau tidak ada di akun Anda, tanyakan ke hosting.

Alternatif manual lewat .htaccess di folder root situs, diletakkan sebelum blok aturan WordPress:

RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

Jangan mengaktifkan dua mekanisme redirect sekaligus di tempat berbeda. Itu penyebab paling umum ERR_TOO_MANY_REDIRECTS.

Jebakan yang sering bikin kerja ulang

• Cloudflare mode Flexible. Dengan mode ini Cloudflare menghubungi server Anda lewat HTTP, sementara server Anda memaksa HTTPS — hasilnya loop redirect. Periksa mode SSL/TLS di dashboard Cloudflare dan samakan dengan kondisi sertifikat di server.
• Cache. Setelah perbaikan, bersihkan cache plugin (misalnya LiteSpeed Cache), cache CDN, dan cache browser. Tanpa itu Anda masih melihat versi lama dan mengira perbaikannya gagal.
• HSTS. Jangan memasang header Strict-Transport-Security sebelum semua aset benar-benar bersih dan HTTPS stabil. Browser mengingat kebijakan ini, jadi kesalahan di sini sulit dibatalkan dengan cepat.
• Direktif CSP block-all-mixed-content sudah usang. Jangan dipakai lagi. upgrade-insecure-requests bisa jadi jaring pengaman, tapi ingat: direktif itu tidak menyulap aset yang memang tidak tersedia lewat HTTPS menjadi ada.
• Memperbaiki gejala, bukan sebabnya. Plugin yang menulis ulang output HTML on-the-fly memang bisa menyembunyikan gembok yang hilang, tapi URL http:// di database tetap ada dan akan muncul lagi saat plugin dimatikan.

Checklist singkat

1. Sertifikat mencakup domain dan www.
2. Console DevTools bersih dari pesan Mixed Content di beranda, artikel, halaman builder, dan halaman checkout.
3. Settings → General sudah https://.
4. Database sudah di-search-replace dengan metode yang aman untuk data terserialisasi.
5. Redirect HTTPS aktif di satu tempat saja.
6. Semua cache sudah dibersihkan.

Kalau Anda sedang mempertimbangkan pindah hosting

Pekerjaan membersihkan mixed content paling rapi dikerjakan sekali, dengan backup di tangan dan akses penuh ke cPanel. Kalau Anda sedang berpikir untuk memindahkan situs, Gocelerus adalah cPanel web hosting untuk Asia Tenggara dengan server di Singapura, dan pemindahan situs yang sudah ada dikerjakan tim secara gratis. Detail paketnya ada di https://gocelerus.com/pricing.

Sumber

• Mixed content - Security - MDN Web Docs - Mozilla
• Content-Security-Policy: block-all-mixed-content directive - HTTP
• Mixed Content
• Mixed content blocking in Firefox - Mozilla Support