Apa Itu Mixed Content dan Kenapa Situs WordPress Anda Kena?
Anda baru saja memasang HTTPS lewat Cloudflare, gembok di address bar sudah muncul, tapi sebagian halaman terlihat rusak: ada gambar yang hilang, tampilan (CSS) berantakan, menu tidak berfungsi, atau browser menampilkan peringatan konten tidak aman. Kemungkinan besar penyebabnya adalah mixed content: halaman utama dimuat lewat HTTPS, tetapi sebagian aset di dalamnya — gambar, stylesheet, skrip, font, atau iframe — masih dimuat lewat HTTP.
Daftar Isi
- Apa Itu Mixed Content dan Kenapa Situs WordPress Anda Kena?
- Jawaban Singkat: Cara Mengatasi Mixed Content WordPress
- Bagaimana Browser Menangani Mixed Content
- Tabel Diagnosis: Dari Gejala ke Sumber Masalah
- Persiapan Sebelum Memperbaiki
- Langkah 1: Pastikan Alamat WordPress Sudah HTTPS
- Langkah 2: Temukan Semua URL HTTP yang Tersisa
- Langkah 3: Perbaiki URL di Database dengan WP-CLI (Cara Utama)
- Langkah 4: Perbaiki Sumber di Tema, Widget, dan Embed
- Langkah 5: Aktifkan Automatic HTTPS Rewrites di Cloudflare (Jaring Pengaman)
- Verifikasi: Bagaimana Tahu Masalah Sudah Beres?
- Troubleshooting: Bila Masih Bermasalah
- Alternatif Bila Tidak Ada Akses WP-CLI
- FAQ
- Kesimpulan
Perlu dibedakan dengan jelas: artikel ini bukan tentang mode SSL Cloudflare (Flexible, Full, atau Full Strict) dan bukan tentang error 525/526. Mode SSL mengatur bagaimana Cloudflare terhubung ke server origin Anda. Mixed content mengatur sesuatu yang berbeda: isi halaman itu sendiri — URL aset yang tertulis di HTML, database, tema, atau widget Anda. Bahkan dengan mode SSL yang sudah benar, mixed content tetap muncul selama masih ada URL http:// yang tertinggal di konten.
Mengapa browser begitu ketat? Karena aset HTTP bisa dibaca atau diubah di tengah jalan, dan skrip yang diubah bisa mengubah seluruh halaman. Karena itu browser modern tidak lagi sekadar memberi peringatan — mereka bertindak.
Jawaban Singkat: Cara Mengatasi Mixed Content WordPress
Urutannya: (1) pastikan alamat WordPress di Settings > General sudah memakai https://, (2) temukan URL HTTP yang tersisa lewat Console browser (F12), (3) perbaiki sumbernya — ganti URL di database dengan WP-CLI search-replace dari http://domainanda.com ke https://domainanda.com setelah backup dan dry-run, atau perbaiki manual di tema/widget bila hanya sedikit, (4) aktifkan Automatic HTTPS Rewrites di Cloudflare sebagai jaring pengaman, bukan sebagai satu-satunya perbaikan, (5) bersihkan semua cache, lalu verifikasi sampai Console bersih dan gembok tampil penuh di semua jenis halaman.
Jangan mengandalkan Automatic HTTPS Rewrites saja. Cloudflare sendiri menyatakan fitur itu hanya menulis ulang URL yang memang tersedia lewat HTTPS, dan tidak bisa menulis ulang semua sumber — terutama yang dimuat lewat JavaScript atau CSS. Perbaikan permanen selalu di sumbernya: database, tema, dan pengaturan plugin.
Bagaimana Browser Menangani Mixed Content
Menurut dokumentasi MDN tentang mixed content, browser membagi konten campuran menjadi dua kelompok. Memahami pembagian ini membantu Anda membaca gejala dengan tepat, bukan menebak-nebak.
| Kelompok | Contoh | Perilaku browser | Gejala yang Anda lihat |
|---|---|---|---|
| Upgradable (dapat ditingkatkan) | Gambar (img src), audio, video | Browser mencoba memuat ulang lewat HTTPS secara otomatis | Gambar tampil bila tersedia lewat HTTPS; hilang bila tidak tersedia |
| Blockable (diblokir) | Skrip, stylesheet, iframe, font, permintaan fetch | Diblokir langsung, tidak dimuat | Tampilan berantakan, widget/formulir mati, kotak embed kosong |
Catatan penting dari MDN: permintaan yang seharusnya bisa ditingkatkan tetap diblokir bila host-nya berupa alamat IP, bukan nama domain. Jadi gambar dari http://93.184.215.14/gambar.png tidak akan diselamatkan oleh mekanisme upgrade otomatis, sedangkan gambar dari domain yang sama biasanya dicoba lewat HTTPS dulu.
Dokumentasi Cloudflare tentang mixed content menegaskan gejala yang sama: browser modern memblokir permintaan HTTP di halaman HTTPS, dan konten yang diblokir bisa berupa gambar, JavaScript, CSS, atau konten lain yang memengaruhi tampilan dan perilaku halaman.
Tabel Diagnosis: Dari Gejala ke Sumber Masalah
| Gejala | Kemungkinan sumber | Cara memastikan |
|---|---|---|
| Gembok hilang / ada segitiga peringatan, tapi tampilan normal | Satu-dua gambar HTTP yang berhasil di-upgrade atau peringatan pasif | Buka Console, cari baris mixed content dan catat URL-nya |
| CSS berantakan, situs seperti tanpa tema | Stylesheet tema/plugin masih HTTP | Console menampilkan stylesheet yang diblokir; periksa URL tema |
| Menu, slider, atau formulir tidak berfungsi | Skrip JavaScript HTTP diblokir | Console menampilkan skrip yang diblokir |
| Gambar lama hilang, gambar baru tampil | URL gambar lama di database masih HTTP | Klik kanan gambar yang hilang > Inspect, lihat atribut src-nya |
| Embed peta/video kosong | Iframe pihak ketiga masih HTTP | Periksa kode embed di postingan/widget |
| Hanya halaman tertentu bermasalah | Konten per halaman: embed, widget, atau shortcode lama | Buka halaman itu saja, ulangi pemeriksaan Console |
| Masalah muncul setelah ganti tema/plugin | Tema/plugin baru menulis URL absolut HTTP | Nonaktifkan sementara, bandingkan Console sebelum/sesudah |
Persiapan Sebelum Memperbaiki
Langkah ini singkat, tapi jangan dilewati. Perbaikan database tidak bisa dibatalkan dengan tombol undo.
- Backup lengkap. Cadangkan database dan file WordPress. Bila memakai WP-CLI, jalankan
wp db exportdari root instalasi WordPress dan simpan berkas hasilnya di tempat aman. - Catat kondisi awal. Buka beranda, satu artikel bergambar, dan satu halaman dengan formulir/embed. Screenshot atau catat URL yang dilaporkan Console di masing-masing halaman.
- Siapkan akses. Anda perlu akses dashboard WordPress, dan idealnya akses SSH/terminal ke server untuk WP-CLI. Bila tidak ada WP-CLI, perbaikan tetap bisa dilakukan manual untuk kasus yang sedikit — lihat bagian alternatif.
- Jangan ubah mode SSL dulu. Bila situs sudah bisa dibuka lewat HTTPS dan hanya asetnya yang bermasalah, jangan mengutak-atik mode SSL di tengah perbaikan mixed content. Satu perubahan dalam satu waktu membuat penyebab mudah dilacak.
Langkah 1: Pastikan Alamat WordPress Sudah HTTPS
Ini sumber mixed content paling umum pada situs yang baru pindah ke HTTPS: WordPress masih menganggap alamatnya HTTP, sehingga semua URL yang dibuat otomatis — termasuk URL aset — ikut HTTP.
- Masuk ke dashboard WordPress, buka Settings > General.
- Periksa WordPress Address (URL) dan Site Address (URL). Keduanya harus diawali
https://, misalnyahttps://domainanda.com. - Bila masih
http://, ubah keduanya kehttps://lalu simpan. - Bila kedua kolom tidak bisa diedit (terkunci), biasanya nilainya dikunci lewat
wp-config.php. Dalam kasus itu, perbaiki nilai diwp-config.phpsesuai dokumentasi WordPress, atau minta bantuan penyedia hosting Anda — jangan memaksa mengubah lewat database tanpa memahami kenapa kolom itu terkunci. - Setelah menyimpan, buka Settings > Permalinks dan tekan Save Changes (tanpa mengubah struktur) untuk menyegarkan aturan permalink.
Perubahan ini menghentikan lahirnya URL HTTP baru. URL HTTP lama yang sudah tersimpan di konten lama tetap harus diperbaiki pada langkah berikutnya.
Langkah 2: Temukan Semua URL HTTP yang Tersisa
Jangan menebak. Browser memberi tahu Anda persis URL mana yang bermasalah.
- Buka situs di jendela penyamaran (incognito) agar cache lama tidak menipu Anda.
- Tekan F12 untuk membuka DevTools, lalu buka tab Console.
- Muat ulang halaman. Setiap peringatan mixed content menampilkan URL lengkapnya dan keterangan apakah URL itu di-upgrade atau diblokir.
- Ulangi untuk tiap jenis halaman: beranda, satu artikel, satu halaman statis, halaman arsip/kategori, dan halaman kontak/formulir. Mixed content sering bersembunyi di halaman lama yang jarang dibuka.
- Kelompokkan temuan Anda: (a) URL domain sendiri, (b) URL pihak ketiga (font, widget, embed), (c) URL dari tema/plugin tertentu. Pengelompokan ini menentukan langkah perbaikan yang tepat.
- Sebagai pemeriksaan silang, Anda juga bisa melihat page source (klik kanan > View Page Source) dan mencari
http://. Cara ini membantu menemukan URL yang tidak sempat tercatat di Console.
Langkah 3: Perbaiki URL di Database dengan WP-CLI (Cara Utama)
Bila URL HTTP yang tersisa ada di konten lama — postingan, halaman, widget, atau pengaturan — cara paling bersih adalah search-replace di database. WP-CLI menangani data terserialisasi (serialized data) dengan benar, sesuatu yang tidak dilakukan oleh perintah SQL REPLACE mentah. Karena itu jangan menjalankan UPDATE ... REPLACE() langsung ke database WordPress: data terserialisasi menyimpan panjang string, dan mengubah string tanpa menyesuaikan panjangnya akan merusak data tersebut.
Jalankan dari root instalasi WordPress, ganti domainanda.com dengan domain Anda sendiri:
cd /var/www/html
wp db export backup-sebelum-https.sql
wp search-replace 'http://domainanda.com' 'https://domainanda.com' --dry-run --skip-columns=guid
Perintah --dry-run hanya menampilkan apa yang akan diubah, tanpa mengubah apa pun. Periksa laporannya: tabel mana yang kena, berapa penggantian di tiap kolom. Bila angkanya masuk akal, jalankan perintah sebenarnya:
wp search-replace 'http://domainanda.com' 'https://domainanda.com' --skip-columns=guid
Catatan tentang --skip-columns=guid: kolom GUID di WordPress secara desain adalah pengenal permanen, bukan URL yang harus diubah. Melewatinya adalah praktik yang dianjurkan dalam banyak panduan migrasi. Bila Anda memakai varian domain www dan non-www, ulangi proses yang sama untuk varian tersebut setelah memeriksa mana yang benar-benar dipakai di konten.
Setelah search-replace selesai, jangan lupa membersihkan cache: cache plugin WordPress, cache server bila ada, dan cache Cloudflare (Purge Cache). Tanpa langkah ini, halaman lama yang tersimpan di cache akan terus menampilkan URL HTTP lama dan membuat Anda mengira perbaikan gagal.
Langkah 4: Perbaiki Sumber di Tema, Widget, dan Embed
Search-replace database tidak memperbaiki URL yang ditulis langsung di berkas tema, di CSS, atau di kode embed pihak ketiga. Untuk kelompok ini, perbaiki di sumbernya:
- Tema: cari URL absolut
http://di berkas tema (header, footer, functions) dan ubah kehttps://atau ke URL relatif. Bila tema dibuat pihak lain dan diperbarui berkala, gunakan child theme agar perubahan tidak hilang saat update. - Widget dan kustomisasi: periksa widget teks/HTML, logo di Customizer, dan tautan media sosial. URL lama sering tertinggal di sini karena tidak tersimpan di konten postingan.
- CSS: periksa
background-imagedan@font-faceyang merujuk ke URL HTTP. Menurut MDN, semua pemakaianurl()di CSS termasuk konten yang bisa diblokir. - Embed pihak ketiga: bila penyedia embed (peta, video, formulir) sudah mendukung HTTPS, ganti kode embed dengan versi HTTPS-nya. Bila penyedia tidak mendukung HTTPS sama sekali, ganti penyedia atau hapus embed tersebut — tidak ada perbaikan di sisi Anda yang bisa membuat sumber HTTP menjadi aman.
- Gambar dengan srcset: perhatikan bahwa menurut MDN, gambar yang memakai
srcsetatau elemenpicturetermasuk konten yang diblokir, bukan yang di-upgrade. Jadi gambar responsif lama patut diperiksa ekstra teliti.
Langkah 5: Aktifkan Automatic HTTPS Rewrites di Cloudflare (Jaring Pengaman)
Setelah sumber diperbaiki, aktifkan fitur ini sebagai lapisan tambahan, bukan pengganti perbaikan:
- Masuk ke dashboard Cloudflare, pilih domain Anda.
- Buka SSL/TLS > Edge Certificates.
- Aktifkan Automatic HTTPS Rewrites.
Menurut dokumentasi Cloudflare, fitur ini menulis ulang URL dari http ke https untuk sumber yang bisa dilayani lewat HTTPS, dan tersedia di semua paket (Free, Pro, Business, Enterprise). Namun dokumentasi yang sama juga menyatakan batasannya dengan jujur: sebelum menulis ulang, Cloudflare memeriksa apakah sumber tersebut memang tersedia lewat HTTPS; bila tidak tersedia, URL tidak ditulis ulang. Selain itu, sumber yang dimuat lewat JavaScript atau CSS saat halaman dirender bisa lolos dari penulisan ulang, dan untuk zona yang tidak ada di daftar HTTPS Everywhere atau HSTS preload, hanya konten aktif yang ditulis ulang — gambar pasif bisa tetap bermasalah. Itulah alasan fitur ini tidak boleh menjadi satu-satunya perbaikan.
Sebagai alternatif di sisi server, Anda juga bisa menambahkan header Content-Security-Policy: upgrade-insecure-requests. Header ini meminta browser meng-upgrade sendiri semua permintaan HTTP ke HTTPS. Ini berguna sebagai pengaman tambahan, tetapi sama seperti Automatic HTTPS Rewrites, ia tidak memperbaiki URL yang tersimpan di database Anda.
Verifikasi: Bagaimana Tahu Masalah Sudah Beres?
Perbaikan dinyatakan berhasil bila semua pemeriksaan berikut lolos, bukan hanya karena gembok muncul di beranda:
- Buka beranda, satu artikel bergambar, satu halaman formulir/embed, dan satu halaman arsip di jendela penyamaran.
- Di tiap halaman, Console (F12) tidak lagi menampilkan peringatan atau error mixed content.
- Ikon gembok tampil penuh di address bar di semua halaman yang diperiksa.
- Gambar, stylesheet, skrip, dan embed tampil dan berfungsi seperti seharusnya — bukan sekadar gembok yang muncul sementara konten tetap rusak.
- Ulangi pemeriksaan setelah membersihkan cache plugin, cache server, dan cache Cloudflare. Cache adalah penyebab paling umum dari "sudah diperbaiki tapi masih rusak" yang sebenarnya hanya halaman lama.
Bila satu halaman masih bermasalah, kembali ke Console halaman itu dan catat URL-nya — itulah sumber yang belum diperbaiki, bukan pertanda seluruh perbaikan gagal.
Troubleshooting: Bila Masih Bermasalah
| Gejala setelah perbaikan | Penyebab yang mungkin | Yang dilakukan |
|---|---|---|
| Console bersih di penyamaran, tapi gembok hilang di browser biasa | Cache browser lama | Hapus cache browser atau uji di perangkat lain |
| Semua halaman bersih kecuali satu artikel lama | URL HTTP tertinggal di konten artikel itu | Edit artikel itu, periksa tab Text/HTML dan cari http:// |
| Gambar hilang setelah search-replace | Perintah search-replace salah sasaran (misalnya domain www vs non-www tertukar) | Kembalikan dari backup database, ulangi dengan dry-run dan periksa laporannya |
| Widget pihak ketiga tetap kosong | Penyedia tidak mendukung HTTPS atau URL ditulis lewat JavaScript | Ganti kode embed ke versi HTTPS atau ganti penyedia |
| Situs redirect berulang setelah mengubah alamat | Aturan redirect HTTPS ganda (plugin + server + Cloudflare) | Nonaktifkan satu lapis redirect, uji satu per satu; ini masalah redirect, bukan mixed content, dan ditangani terpisah |
| Automatic HTTPS Rewrites aktif tapi gambar tertentu tetap HTTP | Sumber tidak tersedia lewat HTTPS atau hanya konten aktif yang ditulis ulang | Perbaiki URL di sumbernya; jangan menunggu fitur Cloudflare memperbaikinya |
Alternatif Bila Tidak Ada Akses WP-CLI
Bila Anda tidak punya akses terminal, opsi berikut tetap tersedia, dengan batasan masing-masing:
- Perbaiki manual per konten. Cocok bila URL HTTP hanya ada di sedikit postingan atau widget. Edit lewat editor WordPress, periksa mode HTML, dan ganti URL-nya satu per satu.
- Plugin search-replace khusus. Ada plugin yang melakukan search-replace dengan penanganan serialized data. Pilih plugin yang masih dipelihara dan teruji dengan versi WordPress Anda, jalankan setelah backup, dan nonaktifkan setelah selesai bila tidak diperlukan lagi.
- Automatic HTTPS Rewrites + upgrade-insecure-requests. Kombinasi ini bisa menyembunyikan gejala di banyak halaman, tetapi ingat: ini menutupi masalah, bukan memperbaikinya. Gunakan sebagai jembatan sementara sambil memperbaiki sumber, bukan sebagai solusi permanen.
Yang tidak dianjurkan: menjalankan SQL REPLACE mentah ke database, dan mengedit berkas inti WordPress. Keduanya berisiko merusak data atau hilang saat update.
FAQ
Apakah mixed content sama dengan error 525 atau 526?
Tidak. Error 525/526 adalah kegagalan handshake SSL antara Cloudflare dan server origin — situs tidak bisa dibuka sama sekali atau menampilkan halaman error Cloudflare. Mixed content terjadi saat situs sudah terbuka lewat HTTPS, tetapi sebagian asetnya masih HTTP. Keduanya berhubungan dengan HTTPS, tetapi penyebab dan perbaikannya berbeda.
Apakah mengganti mode SSL Cloudflare ke Full Strict memperbaiki mixed content?
Tidak secara langsung. Mode SSL mengatur koneksi Cloudflare ke origin, sedangkan mixed content berasal dari URL aset di halaman Anda. Mengganti mode SSL tidak mengubah URL yang tertulis di database atau tema. Perbaiki URL-nya; mode SSL ditangani sebagai topik terpisah.
Kenapa gambar lama hilang tapi gambar baru tampil normal?
Karena gambar baru dibuat setelah alamat WordPress diubah ke HTTPS, sehingga URL-nya sudah benar sejak awal. Gambar lama menyimpan URL HTTP dari masa sebelum pindah ke HTTPS. Itulah yang diperbaiki oleh search-replace.
Apakah Automatic HTTPS Rewrites cukup tanpa search-replace?
Belum tentu. Fitur itu hanya menulis ulang sumber yang memang tersedia lewat HTTPS, dan tidak mencakup semua sumber — terutama yang dimuat lewat JavaScript/CSS dan zona yang tidak ada di daftar referensi Cloudflare. Anggap fitur itu sebagai jaring pengaman, dan search-replace sebagai perbaikan utama.
Apakah saya harus mengubah GUID saat search-replace?
Tidak. GUID adalah pengenal permanen postingan, bukan URL yang ditampilkan. Melewati kolom GUID dengan --skip-columns=guid adalah praktik yang umum dipakai dalam migrasi dan tidak memengaruhi tampilan situs.
Setelah semua bersih, apakah perlu memeriksa lagi nanti?
Ya, secara berkala — terutama setelah menginstal tema/plugin baru atau menempel embed dari pihak ketiga. Satu embed HTTP di artikel baru sudah cukup untuk mengembalikan peringatan di halaman itu. Jadikan pemeriksaan Console bagian dari checklist sebelum mempublikasikan artikel yang memakai embed.
Kesimpulan
Mixed content bukan kerusakan sertifikat dan bukan kesalahan mode SSL — ini soal URL aset yang tertinggal di HTTP setelah situs pindah ke HTTPS. Urutan perbaikannya: pastikan alamat WordPress sudah HTTPS, temukan URL bermasalah lewat Console, perbaiki sumbernya dengan search-replace yang aman setelah backup, perbaiki tema/widget/embed yang tidak tercakup database, lalu pakai Automatic HTTPS Rewrites sebagai pengaman tambahan. Verifikasi di semua jenis halaman dalam jendela penyamaran, setelah semua cache dibersihkan. Bila satu halaman masih bermasalah, Console halaman itu akan menunjukkan sumbernya — dan itulah satu-satunya tempat yang masih perlu diperbaiki.
Langkah berikutnya yang masuk akal: bila Anda juga memakai Cloudflare, pastikan mode SSL dan Always Use HTTPS Anda sudah konsisten dengan konfigurasi origin, dan simpan backup database sebelum dan sesudah search-replace sebagai arsip perbaikan.